From jpv@cisco.com Sun Apr 1 18:28:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747A321F8883 for ; Sun, 1 Apr 2012 18:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.577 X-Spam-Level: X-Spam-Status: No, score=-110.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B38ToXdL2mvJ for ; Sun, 1 Apr 2012 18:28:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAC21F8882 for ; Sun, 1 Apr 2012 18:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5371; q=dns/txt; s=iport; t=1333330096; x=1334539696; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=p1ExzkZS1xiaurszcXwyJBeAqi1BwudXpl2yE8Vihyw=; b=LKATD6fxKi8rfD651xkvm5nZhT+rJGec4wC3x9zrYYOqQ0jsV0V6Xqsp VyA/F87DrIteHVKuNPHAUHuqD9HT5lwgTgLOcjdrMEo9Ou90kJi5IUvI+ O8FXTLqSc+97KRZjfdyWzlVq1VGCwbZEudEDk0dF+lCduej0h+59+jMgS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAEwAeU+rRDoH/2dsb2JhbABDgxy1boEHggkBAQEDAQEBAQ8BJzQLEAsYLicwBhMih2IEAQugFpYVBJA5YwSIWI0JhXCIV4FogweBPA X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="38522139" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 01:28:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q321SGMw017716; Mon, 2 Apr 2012 01:28:16 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:16 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:15 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <595EA675-4482-4362-A873-F1C130536AF9@cisco.com> Date: Sun, 1 Apr 2012 18:28:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <595EA675-4482-4362-A873-F1C130536AF9@cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:28:15.0813 (UTC) FILETIME=[E0896F50:01CD106F] Cc: Emmanuel Baccelli , "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:28:17 -0000 On Apr 1, 2012, at 12:59 PM, JP Vasseur wrote: >=20 > On Mar 30, 2012, at 2:31 AM, Teco Boot wrote: >=20 >> Before we (MANET WG) take a look to LOADng, we should discuss=20 >> options for getting progress on decisions being made before. If=20 >> the outcome is that we should look for alternatives for DYMO (or=20 >> AODVv2, if WG accepts the name change as suggested and already=20 >> effected by current WG doc editor). >>=20 >> Don't take me wrong, I do in no way say LOADng is not relevant. >> I say: lets try to focus on what we decided to do, or discuss >> new options if we need to. In that order. >=20 > Makes total sense to me too. >=20 > JP. >=20 >>=20 >> Teco >>=20 >>=20 >> Op 30 mrt. 2012, om 11:19 heeft Ulrich Herberg het volgende = geschreven: >>=20 >>> Teco, >>>=20 >>> I don't think we compete with ROLL in this regards. >>>=20 >>> MANET is chartered to come up with a reactive protocol (and largely >>> behind schedule). LOADng is a reactive protocol, and has many >>> industrial, large-scale deployments and implementations. I believe = the >>> specification is in a very good shape, and close to being ready >>> besides minors nits (and missing security considerations section). = But >>> we have already assigned the different tasks to the different = authors, >>> so I believe we will submit a new revision very soon with these = issues >>> fixed. >>>=20 >>> Of course, if the WG is interested in LOADng, editorial things (such >>> as the word "MANET" or "LLN") may likely have to be changed, to make >>> clear it is a MANET protocol. >>>=20 >>> We will certainly have a discussion amongst the authors to see if we >>> can accommodate RFC5444. My personal believe is (strictly as >>> individual WG member, not as opinion of the collective of the LOADng >>> authors) that any reactive document in MANET should be RFC5444 >>> compliant. >>>=20 >>> Regards >>> Ulrich >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 5:16 PM, Teco Boot wrote: >>>> OK. >>>>=20 >>>> My message is that we (MANET) should not compete with ROLL. If = someone >>>> thinks it makes sense, or not, to use RFC 5444 for LLN, post it in = ROLL. >>>>=20 >>>> If someone has idea's how to get the reactive manet protocol doc = published >>>> soon, great. I saw someone spending cycles on it. My turn to say = thanks. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>>>=20 >>>> Hi Teco, >>>> maybe I was not clear enough in my previous email: there is no = suggestion to >>>> use packetBB in any ROLL draft I am aware of. >>>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default >>>> supposed to use packetBB, whereas other protocols may not have to = use packet >>>> BB. >>>> Emmanuel >>>>=20 >>>>=20 >>>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >>>>>=20 >>>>> I saw someone presenting a reactive p2p routing protocol in ROLL. = I was >>>>> not aware of a suggestion on using packetBB. If you think it is = useful, you >>>>> could post it over there. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>>>=20 >>>>> Hi Teco, >>>>> that is a good question. Actually, as far as I can see, LOADng = mainly >>>>> derives from AODV, and so does AODVv2, obviously. >>>>> Maybe there is a way to simply "reconcile" the two approaches and = have >>>>> just one protocol (as I tried to express on the mic today). >>>>> At first sight the main difference between the two approaches is = probably >>>>> the use of packetBB, so far mandatory in MANET. >>>>> Hence my question about the advantages of NOT using packetBB: I = suppose it >>>>> has to do with the size of packets being bigger, and maybe more = difficult to >>>>> fit into small frames such as radio frames used in some LLNs, = indeed? >>>>> Emmanuel >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = wrote: >>>>>>=20 >>>>>> For the record, I repeat a remark I made on the mic. >>>>>> It looks to me LOADnd is targetted for the LLN use case >>>>>> and IETF has a wonderful WG for this. It is not MANET. >>>>>>=20 >>>>>> Teco >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From jpv@cisco.com Sun Apr 1 18:28:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCE21F888F for ; Sun, 1 Apr 2012 18:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.579 X-Spam-Level: X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDBF6wTIOIB3 for ; Sun, 1 Apr 2012 18:28:40 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DC30021F888C for ; Sun, 1 Apr 2012 18:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=11780; q=dns/txt; s=iport; t=1333330121; x=1334539721; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=/e03ImAQxmgcZ6aCaIxvmA3ZrYOgXNlg/j7yLCkX1LI=; b=c9BaQILlRtJ3cYHx5zUaZ5LrJs3HumwyONNW28iygRvPAjm+vYm1Ruu3 GxYvL8MTQmYQB1I3JWq81yZjJaJ51MCL986c2Wc8H7b5NYDeTjlnzw6Yz zJ5faLNB8zPrrSkHLujFMrX2InrT4/zshyIGOOmZk9xHtrGQv/BTW5rrW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAOf/eE+rRDoH/2dsb2JhbABDgxy1boEHggkBAQEDAQEBAQ8BWwsQCxEEAQEBLicoCAYTIodiBAELoBaWFASQOWMEiFiNCYVwiFeBaIMHgTw X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="36034956" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 01:28:39 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q321SdEt017949; Mon, 2 Apr 2012 01:28:39 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:39 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:39 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_978FB9BC-9FA5-48BD-BB77-9C161131F91F" From: JP Vasseur In-Reply-To: <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> Date: Sun, 1 Apr 2012 18:28:38 -0700 Message-Id: References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:28:39.0312 (UTC) FILETIME=[EE8B1900:01CD106F] Cc: manet@ietf.org, Emmanuel Baccelli Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:28:41 -0000 --Apple-Mail=_978FB9BC-9FA5-48BD-BB77-9C161131F91F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 1, 2012, at 12:57 PM, JP Vasseur wrote: >=20 > On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: >=20 >> For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. >=20 > Agree Stan. And I'd like to point out that LLN is not a type of mobile = network =85 the fact that links are lossy and thus the > topology is dynamic is not equivalent to a MANET=20 >=20 > Cheers. >=20 > JP. >=20 >> =20 >> Regards, >> Stan >>=20 >> From: manet-bounces@ietf.org on behalf of Teco Boot >> Sent: Thu 3/29/2012 11:16 AM >> To: Emmanuel Baccelli >> Cc: manet@ietf.org IETF >> Subject: Re: [manet] LOADng and handling this in LLN >>=20 >> OK. >>=20 >> My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL. >>=20 >> If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >>=20 >> Teco >>=20 >>=20 >> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>=20 >>> Hi Teco, >>> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >>> Emmanuel >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >>> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>=20 >>>> Hi Teco, >>>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>>> Emmanuel >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >>>> For the record, I repeat a remark I made on the mic. >>>> It looks to me LOADnd is targetted for the LLN use case >>>> and IETF has a wonderful WG for this. It is not MANET. >>>>=20 >>>> Teco >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_978FB9BC-9FA5-48BD-BB77-9C161131F91F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Mar 29, 2012, = at 8:23 AM, Stan Ratliff (sratliff) wrote:

For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 

Cheers.

JP.<= /div>
 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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


= --Apple-Mail=_978FB9BC-9FA5-48BD-BB77-9C161131F91F-- From jpv@cisco.com Sun Apr 1 18:28:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58A21F8897 for ; Sun, 1 Apr 2012 18:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3Jkj0Mkmuex for ; Sun, 1 Apr 2012 18:28:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F821F8895 for ; Sun, 1 Apr 2012 18:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2218; q=dns/txt; s=iport; t=1333330127; x=1334539727; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dxQPf3/WenMr+EmZAGZ3iA4Knjjh16AV3+7uq2FGRc4=; b=gE8bvA/bJeCwZbAjMkNdwXgkIjyHmmE14jocSqfEz2mbjnFkC84wZYFT nKCDxAjIGU845PHd7CTRgu/nZa7r504fgovFBfHcSBwvv2PMUT2ZO9GrU EjVXD2aTGkoGD8pJyS160dcM4WcbkeGckkjO2AD5TV67HDTvHMeQIXBRV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAOf/eE+rRDoH/2dsb2JhbABDgxy1boEHggkBAQEDAQEBAQ8BJzQLBQsLGC4nMBkbB4diBAELoBaWFASNeIJBYwSIWI0JhXCIV4Fogwc X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="36034965" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 01:28:47 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q321SluW018025; Mon, 2 Apr 2012 01:28:47 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:47 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:47 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <95EC49B5-F6C7-47F9-AE19-C03BD83CFD8F@cisco.com> Date: Sun, 1 Apr 2012 18:28:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <70EC8E80-9A98-4A95-A362-2A3F65131AB5@cisco.com> References: <4F74722A.6060703@computer.org> <95EC49B5-F6C7-47F9-AE19-C03BD83CFD8F@cisco.com> To: charliep@computer.org X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:28:47.0234 (UTC) FILETIME=[F343E620:01CD106F] Cc: Manet Subject: Re: [manet] A view on packet-BB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:28:48 -0000 On Apr 1, 2012, at 12:55 PM, JP Vasseur wrote: > Hi Charlie, > > On Mar 29, 2012, at 7:31 AM, Charles E. Perkins wrote: > >> >> Hello folks, >> >> I have not participated very much in any discussions about >> packet-BB other than to encourage header size reduction and >> offer a few suggestions about how to achieve it. During that >> time, it was claimed that for many networks of interest, the >> use of packet-BB would *decrease* header size, perhaps >> especially for proactive protocols. This is a question >> very suitable for resolution by way of simulation. >> >> If, as I suspect, packet-BB does (on average) introduce >> header enlargement on some networks that cannot afford it, >> I would be in favor to introduce the option to run AODV >> (or OLSR, for that matter) with some sort of "reduced" >> header. This should only be deployed in networks where >> otherwise there would be no feasible deployment of an >> ad-hoc networking protocol. From that perspective, it's >> almost a no brainer -- either deploy the standard stripped- >> down version, or deploy something else nonstandard that >> looks exactly like the stripped-down version. >> >> In summary, if there are cases where the [manet] protocols >> can only be deployed without packet-BB header overhead, >> then I think we should provide a solution for those cases. >> >> To be clear, I am happy either way, whether or not packet-BB >> headers are mandates in all cases. >> >> Also, to be clear, we can standardize AODVv2 *with* packet-BB >> right now, and submit for consideration another document for >> AODVv2 that does not require packet-BB. Or, we can enable both >> ways in the next revision. Or, we can standardize AODVv2 >> that does NOT use packet-BB, and then submit for consideration >> another document that DOES use packet-BB. All cases are just >> fine with me, depending on what the working group wants. > > Completely sharing your view. > > Cheers. > > JP. > >> >> Regards, >> Charlie P. >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From jpv@cisco.com Sun Apr 1 18:28:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D15F21F88A2 for ; Sun, 1 Apr 2012 18:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF0Uyz+ltxgq for ; Sun, 1 Apr 2012 18:28:55 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDFA21F88A0 for ; Sun, 1 Apr 2012 18:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6957; q=dns/txt; s=iport; t=1333330135; x=1334539735; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=AMMn+OkJIevm48yU1gF2dBXra12lx6q50YKyMfdEcfs=; b=BsApgpgQISR77bId20mGl3cGkQMevUoY7GtDBbGlKwmY2azqNKIMEDGP 3RSD4LrHEZWcV7ALysPrJ48PRcYkK+IAOv8cuwVu/XA/41JB1pzTKtZ78 p6F+bpq7Yl2iPwuYslu8i/ODJ1JsklcAUZ1dJMAofZtj6XWa2sSVL+zZr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAIoAeU+rRDoH/2dsb2JhbABEgw+1boEHggkBAQEDAQEBAQ8BWwsFCwsYLicwBhMih2IEAQubUZ17BJA5YwSIWI0JhXCIV4FogweBPA X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="35497734" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 01:28:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q321StfH018131; Mon, 2 Apr 2012 01:28:55 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:54 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:54 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_27172AA4-2CEB-4E09-8949-BDA049D361DA" From: JP Vasseur In-Reply-To: <23CCB64C-FEEA-439A-83F0-9633B0124A4D@cisco.com> Date: Sun, 1 Apr 2012 18:28:54 -0700 Message-Id: <375009B2-ABB3-4E6B-9EEA-05B289728B9A@cisco.com> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <23CCB64C-FEEA-439A-83F0-9633B0124A4D@cisco.com> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:28:54.0796 (UTC) FILETIME=[F7C5C4C0:01CD106F] Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:28:56 -0000 --Apple-Mail=_27172AA4-2CEB-4E09-8949-BDA049D361DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 1, 2012, at 12:56 PM, JP Vasseur wrote: > Hi, >=20 > On Mar 29, 2012, at 8:00 AM, Emmanuel Baccelli wrote: >=20 >> Hi Teco, >> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >=20 > Correct. >=20 > JP. >=20 >> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >> Emmanuel >>=20 >>=20 >> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>=20 >> Teco >>=20 >>=20 >> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>=20 >>> Hi Teco, >>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>> Emmanuel >>>=20 >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >>> For the record, I repeat a remark I made on the mic. >>> It looks to me LOADnd is targetted for the LLN use case >>> and IETF has a wonderful WG for this. It is not MANET. >>>=20 >>> Teco >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_27172AA4-2CEB-4E09-8949-BDA049D361DA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Apr 1, 2012, at 12:56 PM, JP Vasseur wrote:

Hi,

On Mar 29, 2012, at 8:00 AM, Emmanuel Baccelli wrote:

Hi Teco,
maybe I was not clear enough in my previous email: there is no suggestion to use packetBB in any ROLL draft I am aware of.

Correct.

JP.

I meant that, so far, a MANET protocol (and thus AODVv2) is by default supposed to use packetBB, whereas other protocols may not have to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot <teco@inf-net.nl> wrote:
I saw someone presenting a reactive p2p routing protocol in ROLL. I was not aware of a suggestion on using packetBB. If you think it is useful, you could post it over there.

Teco


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende geschreven:

Hi Teco,
that is a good question. Actually, as far as I can see, LOADng mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using packetBB: I suppose it has to do with the size of packets being bigger, and maybe more difficult to fit into small frames such as radio frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

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

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


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


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


--Apple-Mail=_27172AA4-2CEB-4E09-8949-BDA049D361DA-- From jpv@cisco.com Sun Apr 1 18:29:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8BC21F88A8 for ; Sun, 1 Apr 2012 18:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P5Yy8W-T784 for ; Sun, 1 Apr 2012 18:29:00 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 017E921F88B0 for ; Sun, 1 Apr 2012 18:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5027; q=dns/txt; s=iport; t=1333330140; x=1334539740; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=1cyqNm1/vBu2bRWOPgcLoKU4IFMgE3Ok4pCTSxW9jnE=; b=dYmoyww6irmd+Mg80SVKWYAHZGhp0gIc/6q8uWjZian/q0nB5OeE6dZ7 qr+jwgbH6N8E7xFR1+KkPY/wf+hRxIVMoNV6xucgr0K4JZZW6P0IHYBgE SnJE15obH24tD7aJUuBqrqdGbZEDNv/VnzeN1DJmFZ3jMjCMG69zGVTjw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGABkAeU+rRDoH/2dsb2JhbABEgw+1boEHggkBAQEDAQEBAQ8BWwsFCwsEFC4nMAYTIodiBAELm1GdewSQOWMEiFiNCYVwiFeBaIMH X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="38613266" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 02 Apr 2012 01:28:59 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q321SxAq018193; Mon, 2 Apr 2012 01:28:59 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:59 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:28:59 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_17DDCEB9-0060-4B20-AC9B-C9603E88783E" From: JP Vasseur In-Reply-To: <46BB7D3F-6080-4CCC-B8E9-6936B73CA6EE@cisco.com> Date: Sun, 1 Apr 2012 18:28:58 -0700 Message-Id: References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <46BB7D3F-6080-4CCC-B8E9-6936B73CA6EE@cisco.com> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:28:59.0265 (UTC) FILETIME=[FA6FAF10:01CD106F] Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:29:00 -0000 --Apple-Mail=_17DDCEB9-0060-4B20-AC9B-C9603E88783E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 1, 2012, at 12:54 PM, JP Vasseur wrote: > Hi Emanuel, >=20 > On Mar 29, 2012, at 6:59 AM, Emmanuel Baccelli wrote: >=20 >> Hi Teco, >> that is a good question. Actually, as far as I can see, LOADng mainly = derives from AODV, and so does AODVv2, obviously. >> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >=20 > JP> Absolutely ! I would have made the same comment, sorry I did not = know that the discussion was at the agenda. >=20 >> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >=20 > JP> Not sure =85 if targeted for LLNs, we have one protocol with two = flavors already, one being reactive for environments > where Load-ng seems to operate =85 >=20 > Thanks. >=20 > JP. >=20 >> Emmanuel >>=20 >>=20 >>=20 >> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >> For the record, I repeat a remark I made on the mic. >> It looks to me LOADnd is targetted for the LLN use case >> and IETF has a wonderful WG for this. It is not MANET. >>=20 >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_17DDCEB9-0060-4B20-AC9B-C9603E88783E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Emanuel,

On Mar 29, 2012, at 6:59 AM, Emmanuel = Baccelli wrote:

Hi Teco,
that is a good question. Actually, as far as = I can see, LOADng mainly derives from AODV, and so does AODVv2, = obviously.
Maybe there is a way to simply "reconcile" the two = approaches and have just one protocol (as I tried to express on the mic = today).

JP> Absolutely ! I = would have made the same comment, sorry I did not know that the = discussion was at the agenda.

At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence = my question about the advantages of NOT using packetBB: I suppose = it has to do with the size of packets being bigger, and maybe more = difficult to fit into small frames such as radio frames used in some = LLNs, indeed?

JP> Not sure =85 = if targeted for LLNs, we have one protocol with two flavors already, one = being reactive for environments
where Load-ng seems to operate = =85

Thanks.

JP.
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <teco@inf-net.nl> wrote:
For the = record, I repeat a remark I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

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

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


= --Apple-Mail=_17DDCEB9-0060-4B20-AC9B-C9603E88783E-- From jpv@cisco.com Sun Apr 1 18:29:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AEA21F88B4 for ; Sun, 1 Apr 2012 18:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4HurqLGu19u for ; Sun, 1 Apr 2012 18:29:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C23D021F88B1 for ; Sun, 1 Apr 2012 18:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=932; q=dns/txt; s=iport; t=1333330144; x=1334539744; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/8waPVss8eTobKb3lckeRXMIrvbOeWW7b/595RXasxU=; b=FqZ+si6Ixcwa8xdNgnrtpzqIfRZKA7js2EhaIDABRL9mzzmawOQzQiKq Q65tbxvzybf0nQa62DtFp1mMSgql41oNGA1wzjpmnqYQSo2XUpEy5g2nr BDoRXVyKnWzmAN5z1DeL60VrQrwO95zCDWyDRMR8MShXm80W/IBqgcOwY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAIoAeU+rRDoI/2dsb2JhbABEgw+1boEHggkBAQEDAQEBAQ8BWwsFCwsYLicwBhMih2IEAQubUZ17BJA5YwSIWI0JhXCIV4Fogwc X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="35497739" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 01:29:04 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q321T4xL010619; Mon, 2 Apr 2012 01:29:04 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:29:04 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 18:29:04 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <1A232E7D-2BAF-43FC-B855-82E135CF8072@cisco.com> Date: Sun, 1 Apr 2012 18:29:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13B1742A-69AB-4099-8D87-49BBFA9E9C83@cisco.com> References: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> <1A232E7D-2BAF-43FC-B855-82E135CF8072@cisco.com> To: Teco Boot X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 01:29:04.0359 (UTC) FILETIME=[FD78F770:01CD106F] Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:29:05 -0000 On Apr 1, 2012, at 12:51 PM, JP Vasseur wrote: > Hi Teco, >=20 > On Mar 29, 2012, at 6:37 AM, Teco Boot wrote: >=20 >> For the record, I repeat a remark I made on the mic. >> It looks to me LOADnd is targetted for the LLN use case=20 >> and IETF has a wonderful WG for this. It is not MANET. >>=20 >=20 > I cannot agree more -- The positioning of Load-ng is quite confusing = too =85 Is it targeted for LLNs or is it a reactive > protocol for MANET. In the former case, the ROLL WG has specified a = protocol RPL (pro-active, with a reactive=20 > version) for LLN, in the later case, then it would be interesting to = understand whether MANET specifies one routing > reactive protocol and which one (AODV, DYMO, =85). >=20 > Cheers. >=20 > JP. >=20 >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From teco@inf-net.nl Sun Apr 1 21:57:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ABB11E80A3 for ; Sun, 1 Apr 2012 21:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtWai7dpJ+xD for ; Sun, 1 Apr 2012 21:56:59 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C4DF711E8085 for ; Sun, 1 Apr 2012 21:56:57 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2136944wib.1 for ; Sun, 01 Apr 2012 21:56:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OhJnRmLjY4Dmho+15acR8fr2uhGTK83yF2tSXxJhlS0=; b=Opa5CzY1qo7yEw8UmK8mltscfmaGqb7p1eb+C32vxh+z/P50k0QVASLHirl9fnp4tb ZWRrpnOtC0nZ1Tu5+4ww9OgnWxGbFElgQ5Ti9yjymCVxhxW5riG5gPM3WWUnZrBewM3A GgSLzabHdCSQxuk2ueGRmPC8bHhn91fqNtBFGffHk4QwT8o9FL9PbvGRFROJfyarTZH+ JIzgu3ZVBIbu4wGOFoloBv9Z1h9Zkc9MJ1ZrX/17qr+yvUKZda67Tc2FUYSRurcnInG2 EcVmoTwYsUTtHj8Rlx3Z4MB+8tDiTFNOFqzLjboBI3S+glpDzjO6LT9L5wICVeFMiXd7 U2tA== Received: by 10.180.82.136 with SMTP id i8mr20893587wiy.19.1333342617034; Sun, 01 Apr 2012 21:56:57 -0700 (PDT) Received: from [10.87.66.174] ([80.187.201.33]) by mx.google.com with ESMTPS id fl2sm50269069wib.4.2012.04.01.21.56.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 21:56:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Mon, 2 Apr 2012 06:56:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2E5FF88B-9A64-4997-AE4C-8F55A276CC66@inf-net.nl> References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl/wPXQXghxDxhkqgzcVP7o8a63JM2D0CNTA64kGd5FiK76kNJYrWPO4uksVDmCrvAbByoV Cc: "manet@ietf.org IETF" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 04:57:00 -0000 Op 31 mrt. 2012, om 09:46 heeft Henning Rogge het volgende geschreven: > On Fri, Mar 30, 2012 at 18:38, Teco Boot wrote: >> Stan, >> >> Seen the discussion on hop-count and probably lots of other >> nice to haves, an employee of a random router vender would >> easily get crazy to get all of this in a useful metric for >> the routing protocols. >> >> I suggest to define a new metric type, to be used by modems, >> to provide a dimensionless value that is used directly in the >> routing protocol. After a bit of discussion, we have a nice >> outcome of a 12-bit compressed form of a link metric OLSRv2. >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 >> >> You may have a need for a 16-bit uncompressed dimensionless value >> for OSPF. You could opt for a / 256 of the decompressed value >> or go for another metric type. Important: OSPF needs the metric >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers >> it to neighbor with hello). >> >> You could use the Neighbor Incoming / Outgoing Metric bits, you >> have the 4-bit placeholder already. > If Layer-2 data is available, it should be exported in "raw" format by > the DLEP service/server. Especially data that cannot be easily > calculated by the connected computer like "Throughput" (real one, not > just hardware transmission speed), Transmission loss and transmission > attempts. The real throughput is a nice metric. But it is not "raw", it is computed from modulation data rate, loss ratio and set of delays. CDR could be used for throughput (at sender). > And for Radios we definitely need Frequency and Bandwidth (width of > the radio channel in Hz). These two values are also interesting to use > in the "request link characteristic" message to reconfigure a radio. At the end we have a complete configuration tool. Is that the target? >> With MAC address-block TLVs, assuming a 6-byte MAC address with >> first 3 bytes mostly being equivalent, the space per neighbor >> would be 5 bytes. Not that bad. But to make use of this, you >> may need to have repeatedly having send this info instead of >> having a reliable transport inside DLEP. This needs validity >> timers, so it is not a minor change. > > You mean space including your dimensionless metric TLV? Yes. > Something different, is the addition of IPs to the DLEP messages > really a common usecase? DLEP defines the radio to be a layer-2 bridge > to the ethernet (most likely VLAN tagged to separate it from the > control stream), so the radio/modem does not need any IP address > except for some linklocal one on the control interface. I would use non-linklocals also, for managing the radio/modem. Teco > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From rick.taylor@cassidian.com Mon Apr 2 03:21:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04221F87AE for ; Mon, 2 Apr 2012 03:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HERZNvN149Ot for ; Mon, 2 Apr 2012 03:21:33 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C15821F8670 for ; Mon, 2 Apr 2012 03:21:20 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 02 Apr 2012 12:21:18 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 2 Apr 2012 12:21:18 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:21:17 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:21:17 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 11:21:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Apr 2012 11:20:54 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035664A4@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0QjUFuwaUemU/3T6GKm5SP66g/ywAJXfIg References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> From: "Rick Taylor" To: "Teco Boot" , "Henning Rogge" X-OriginalArrivalTime: 02 Apr 2012 10:21:22.0403 (UTC) FILETIME=[5A07BB30:01CD10BA] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18812.006 X-TM-AS-Result: No--16.773600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:21:34 -0000 Sorry to top post, but I want to summarise my responses to several threads 1) Teco, The metric you propose is a routing metric, and DLEP is about reporting link metrics. OLSR and other routing protocols can/will generate your metric for their own use. It is not the business of the radio to do this. 2) But, Teco's metric does highlight one missing piece of DLEP metric TLV's: No direction indication. Can we have some flags with each metric indicating direction (up/downstream) and the 'rawness' of the metric (smoothed, live, ...)=20 3) IP addressing is not really needed when DLEP refers to neighbours. Layer 2 MAC will identify neighbours correctly, and I would recommend using it with RFC5444 address blocks. Any associated layer 3 addresses are already covered by the DLEP address TLVs, or can be discovered by routers (ARP etc) 4) Hop-count - As a number of people have said, smart layer 2 meshing and layer 3 routing will fight if the layer 3 routers cannot discover the connectivity between radio devices. There must be some mechanism in DLEP for a smart radio mesh to describe the topology in enough detail to prevent a layer 3 routing protocol from making incorrect decisions about connectivity. Ideas include a hop-count TLV or a Via TLV for neighbours. This information is about connectivity, not about 'metrics' or 'routes'. Rick Taylor -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot Sent: 02 April 2012 05:57 To: Henning Rogge Cc: manet@ietf.org IETF; Stan Ratliff (sratliff) Subject: Re: [manet] DLEP: request for new metric type Op 31 mrt. 2012, om 09:46 heeft Henning Rogge het volgende geschreven: > On Fri, Mar 30, 2012 at 18:38, Teco Boot wrote: >> Stan, >>=20 >> Seen the discussion on hop-count and probably lots of other >> nice to haves, an employee of a random router vender would >> easily get crazy to get all of this in a useful metric for >> the routing protocols. >>=20 >> I suggest to define a new metric type, to be used by modems, >> to provide a dimensionless value that is used directly in the >> routing protocol. After a bit of discussion, we have a nice >> outcome of a 12-bit compressed form of a link metric OLSRv2. >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 >>=20 >> You may have a need for a 16-bit uncompressed dimensionless value >> for OSPF. You could opt for a / 256 of the decompressed value >> or go for another metric type. Important: OSPF needs the metric >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers >> it to neighbor with hello). >>=20 >> You could use the Neighbor Incoming / Outgoing Metric bits, you >> have the 4-bit placeholder already. > If Layer-2 data is available, it should be exported in "raw" format by > the DLEP service/server. Especially data that cannot be easily > calculated by the connected computer like "Throughput" (real one, not > just hardware transmission speed), Transmission loss and transmission > attempts. The real throughput is a nice metric. But it is not "raw", it is computed from modulation data rate, loss ratio and set of delays. CDR could be used for throughput (at sender). > And for Radios we definitely need Frequency and Bandwidth (width of > the radio channel in Hz). These two values are also interesting to use > in the "request link characteristic" message to reconfigure a radio. At the end we have a complete configuration tool. Is that the target? >> With MAC address-block TLVs, assuming a 6-byte MAC address with >> first 3 bytes mostly being equivalent, the space per neighbor >> would be 5 bytes. Not that bad. But to make use of this, you >> may need to have repeatedly having send this info instead of >> having a reliable transport inside DLEP. This needs validity >> timers, so it is not a minor change. >=20 > You mean space including your dimensionless metric TLV? Yes. > Something different, is the addition of IPs to the DLEP messages > really a common usecase? DLEP defines the radio to be a layer-2 bridge > to the ethernet (most likely VLAN tagged to separate it from the > control stream), so the radio/modem does not need any IP address > except for some linklocal one on the control interface. I would use non-linklocals also, for managing the radio/modem. Teco >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Mon Apr 2 03:27:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3521F889B for ; Mon, 2 Apr 2012 03:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SitHd5eASsmV for ; Mon, 2 Apr 2012 03:27:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4263121F8896 for ; Mon, 2 Apr 2012 03:27:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="198688108" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Apr 2012 11:27:21 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q32ARLoC029080; Mon, 2 Apr 2012 11:27:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 11:27:20 +0100 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 Date: Mon, 2 Apr 2012 11:27:20 +0100 Message-ID: In-Reply-To: <4F74722A.6060703@computer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] A view on packet-BB Thread-Index: Ac0NuJeG3V9YXbHORuaRV6+mmIvVwwDAicxQ References: <4F74722A.6060703@computer.org> From: "Dearlove, Christopher (UK)" To: , "Manet" X-OriginalArrivalTime: 02 Apr 2012 10:27:20.0979 (UTC) FILETIME=[2FC21630:01CD10BB] Subject: Re: [manet] A view on packet-BB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:27:30 -0000 Before commenting, could you provide examples please. I would also note that RFC 5498 mandates use of RFC 5444 on the UDP port an= d IP protocol that it reserves. This is necessary for interoperability of t= hose protocols that do use those. Other ports/protocols are of course anoth= er issue. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 29 March 2012 15:31 To: Manet Subject: [manet] A view on packet-BB ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello folks, I have not participated very much in any discussions about packet-BB other than to encourage header size reduction and offer a few suggestions about how to achieve it. During that time, it was claimed that for many networks of interest, the use of packet-BB would *decrease* header size, perhaps especially for proactive protocols. This is a question very suitable for resolution by way of simulation. If, as I suspect, packet-BB does (on average) introduce header enlargement on some networks that cannot afford it, I would be in favor to introduce the option to run AODV (or OLSR, for that matter) with some sort of "reduced" header. This should only be deployed in networks where otherwise there would be no feasible deployment of an ad-hoc networking protocol. From that perspective, it's almost a no brainer -- either deploy the standard stripped- down version, or deploy something else nonstandard that looks exactly like the stripped-down version. In summary, if there are cases where the [manet] protocols can only be deployed without packet-BB header overhead, then I think we should provide a solution for those cases. To be clear, I am happy either way, whether or not packet-BB headers are mandates in all cases. Also, to be clear, we can standardize AODVv2 *with* packet-BB right now, and submit for consideration another document for AODVv2 that does not require packet-BB. Or, we can enable both ways in the next revision. Or, we can standardize AODVv2 that does NOT use packet-BB, and then submit for consideration another document that DOES use packet-BB. All cases are just fine with me, depending on what the working group wants. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Apr 2 03:45:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0921F8970 for ; Mon, 2 Apr 2012 03:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe2XAp3Jo-EW for ; Mon, 2 Apr 2012 03:45:51 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 823CD21F896E for ; Mon, 2 Apr 2012 03:45:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="198694583" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 02 Apr 2012 11:45:51 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q32AjoZb008959; Mon, 2 Apr 2012 11:45:50 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 11:45:50 +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: 7bit Date: Mon, 2 Apr 2012 11:45:49 +0100 Message-ID: In-Reply-To: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0OpfQhKBEpz3oaQyaJAlvN3gXR6QCFaIMw References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 02 Apr 2012 10:45:50.0253 (UTC) FILETIME=[C4EFDDD0:01CD10BD] Cc: manet@ietf.org, thomas@thomasclausen.org Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:45:52 -0000 Teco > we have a nice > outcome of a 12-bit compressed form of a link metric OLSRv2. > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 Because this detail is not fully explained in any published document (it should be in an update of the metrics draft to be converted to a rationale document) I'd like to provide a thumbnail sketch as to how this came about. In OLSRv2, the 12 bits have 4 more bits added to them that indicate the nature of the metric. It might therefore be supposed that we picked 12 bits so as to fit into two octets. Actually, no. That this happened was a very fortuitous result. I don't know what we would have done otherwise, but never had to find out. The 12 bits arose from that we had a modified mantissa/exponent form that met people's request for one that started 1,2,3, ... The actual pattern (possibly hidden in the maths) is 2^m increments by 1, then 2^m increments by 2, then 2^m increments by 4 etc., for 2^e sets of increments, where e is the number of "exponent" bits, and m is the number of "mantissa" bits (quotes because these are not a true mantissa/exponent form, but are close to one). Now to pick m and e. And they were picked to satisfy the desire for a range of values that spanned a range up to (just under) 2^24. Why 2^24? Because largest possible route metric is summing 255 of these link metric values, and 2^24 then keeps route metrics less than 2^32. And m=8, e=4 works for this, which is 12 bits. (Incidentally if anyone wants to check the maths has these properties, that's what WGLCs are for.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jpv@cisco.com Sun Apr 1 17:32:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7256F21F8739 for ; Sun, 1 Apr 2012 17:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RtR23HW9-G5 for ; Sun, 1 Apr 2012 17:32:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A580E21F8738 for ; Sun, 1 Apr 2012 17:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=825; q=dns/txt; s=iport; t=1333326739; x=1334536339; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=O4ca90SG3sUE6qvz2OSMfyBuT//k5SX4LENTqHEOA3A=; b=SjCE+fO+C2QpiZcGCUU2IfAHYwfzM0Ep5C3Qo4qB4g0jS7YFQhyFve+A O+wzgn/l9rgqAc5gtRsmu0Ivy3YA0krbxo7s1dkvynmkTdOnaK+Godmjw 0Q8oLGDf8yXEvDv99tSQuAvhzHBSzcQ5qToGZZw5lErmPriAu4g+pXaWW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8MAGfyeE+rRDoH/2dsb2JhbABDJoJ2tW6BB4IJAQEBAwEBAQEPAVsLBQsLRicwBhMih2IEAQugFpYUBJA5YwSIWI0JhXCIV4Fogwc X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="35494908" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 00:32:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q320WJVN021737; Mon, 2 Apr 2012 00:32:19 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:19 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:19 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> Date: Sun, 1 Apr 2012 12:51:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A232E7D-2BAF-43FC-B855-82E135CF8072@cisco.com> References: <00B690D5-A990-409E-A1DB-5E22F81B4BFD@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:19.0133 (UTC) FILETIME=[0FCCB6D0:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:20 -0000 Hi Teco, On Mar 29, 2012, at 6:37 AM, Teco Boot wrote: > For the record, I repeat a remark I made on the mic. > It looks to me LOADnd is targetted for the LLN use case=20 > and IETF has a wonderful WG for this. It is not MANET. >=20 I cannot agree more -- The positioning of Load-ng is quite confusing too = =85 Is it targeted for LLNs or is it a reactive protocol for MANET. In the former case, the ROLL WG has specified a = protocol RPL (pro-active, with a reactive=20 version) for LLN, in the later case, then it would be interesting to = understand whether MANET specifies one routing reactive protocol and which one (AODV, DYMO, =85). Cheers. JP. > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpv@cisco.com Sun Apr 1 17:32:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3B221F873D for ; Sun, 1 Apr 2012 17:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkiqn9KVGcML for ; Sun, 1 Apr 2012 17:32:21 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3822F21F8739 for ; Sun, 1 Apr 2012 17:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4559; q=dns/txt; s=iport; t=1333326741; x=1334536341; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=cBNqbQ9DFWCvQPULVlwkU5Z9Ufy4g82E4/H+uyY79Yc=; b=O0J7CLPo2YkPArmMQC7ezz3kDOQC8lvapP+9/VHCZwId7d63p3KZaVHU lPxG340ZSo19z7I0/ECTQpjgg0HYbBDV6apwoCi6ysKQ/Jj0C0Q1TOk1U ZO3PFkbNidSPOY0fN9dqNqnFrgwW7rBd1pVHxT8su1IJzEDzI9O0BxhOZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAMAGfyeE+rRDoH/2dsb2JhbABDJoJ2tW6BB4IJAQEBAwEBAQEPAVsLBQsLBBQuJzAGEyKHYgQBC6AWlhQEkDljBIhYjQmFcIhXgWiDBw X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="35494909" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 00:32:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q320WKUo021748; Mon, 2 Apr 2012 00:32:21 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:20 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:20 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B80C0151-BE6B-4997-909A-2DE4A12BB07C" From: JP Vasseur In-Reply-To: Date: Sun, 1 Apr 2012 12:54:19 -0700 Message-Id: <46BB7D3F-6080-4CCC-B8E9-6936B73CA6EE@cisco.com> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:20.0508 (UTC) FILETIME=[109E85C0:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:22 -0000 --Apple-Mail=_B80C0151-BE6B-4997-909A-2DE4A12BB07C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Emanuel, On Mar 29, 2012, at 6:59 AM, Emmanuel Baccelli wrote: > Hi Teco, > that is a good question. Actually, as far as I can see, LOADng mainly = derives from AODV, and so does AODVv2, obviously. > Maybe there is a way to simply "reconcile" the two approaches and have = just one protocol (as I tried to express on the mic today). JP> Absolutely ! I would have made the same comment, sorry I did not = know that the discussion was at the agenda. > At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. > Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? JP> Not sure =85 if targeted for LLNs, we have one protocol with two = flavors already, one being reactive for environments where Load-ng seems to operate =85 Thanks. JP. > Emmanuel >=20 >=20 >=20 > On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: > For the record, I repeat a remark I made on the mic. > It looks to me LOADnd is targetted for the LLN use case > and IETF has a wonderful WG for this. It is not MANET. >=20 > Teco > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_B80C0151-BE6B-4997-909A-2DE4A12BB07C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Emanuel,

On Mar 29, 2012, at 6:59 AM, Emmanuel = Baccelli wrote:

Hi Teco,
that is a good question. Actually, as far as = I can see, LOADng mainly derives from AODV, and so does AODVv2, = obviously.
Maybe there is a way to simply "reconcile" the two = approaches and have just one protocol (as I tried to express on the mic = today).

JP> Absolutely ! I = would have made the same comment, sorry I did not know that the = discussion was at the agenda.

At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence = my question about the advantages of NOT using packetBB: I suppose = it has to do with the size of packets being bigger, and maybe more = difficult to fit into small frames such as radio frames used in some = LLNs, indeed?

JP> Not sure =85 = if targeted for LLNs, we have one protocol with two flavors already, one = being reactive for environments
where Load-ng seems to operate = =85

Thanks.

JP.
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <teco@inf-net.nl> wrote:
For the = record, I repeat a remark I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

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

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

= --Apple-Mail=_B80C0151-BE6B-4997-909A-2DE4A12BB07C-- From jpv@cisco.com Sun Apr 1 17:32:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE29421F873B for ; Sun, 1 Apr 2012 17:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFoCxRAsr4qc for ; Sun, 1 Apr 2012 17:32:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3318121F8737 for ; Sun, 1 Apr 2012 17:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2093; q=dns/txt; s=iport; t=1333326742; x=1334536342; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XfeaeD7OLnH6LJy+z75NdpYYdoUHpKkwjlbO38GoDYk=; b=J1wXeR2prmzBsyRHFyrMV+8xpsbyty/AwzCYIb9LPz6PbvNrAR1DKWSY KU+D+Qq/EZ5EBClch8IROw31EXc+0XAPtdr+FO+amkSFNCfFL79lCWGhq S9VORwyNvNq2EXwsh6kUBm0KX+FeZorAwK5vpbsqqh7y1TFTZDxSI3BX+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8MAPbyeE+rRDoJ/2dsb2JhbABEJoJptW6BB4IJAQEBAwEBAQEPASc0CxALRicwGRsHh2IEAQubUJ16BI14gkFjBIhYjQmFcIhXgWiDBw X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="36032157" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 00:32:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q320WLue022230; Mon, 2 Apr 2012 00:32:21 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:21 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:21 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <4F74722A.6060703@computer.org> Date: Sun, 1 Apr 2012 12:55:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <95EC49B5-F6C7-47F9-AE19-C03BD83CFD8F@cisco.com> References: <4F74722A.6060703@computer.org> To: charliep@computer.org X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:21.0383 (UTC) FILETIME=[11240970:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: Manet Subject: Re: [manet] A view on packet-BB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:22 -0000 Hi Charlie, On Mar 29, 2012, at 7:31 AM, Charles E. Perkins wrote: > > Hello folks, > > I have not participated very much in any discussions about > packet-BB other than to encourage header size reduction and > offer a few suggestions about how to achieve it. During that > time, it was claimed that for many networks of interest, the > use of packet-BB would *decrease* header size, perhaps > especially for proactive protocols. This is a question > very suitable for resolution by way of simulation. > > If, as I suspect, packet-BB does (on average) introduce > header enlargement on some networks that cannot afford it, > I would be in favor to introduce the option to run AODV > (or OLSR, for that matter) with some sort of "reduced" > header. This should only be deployed in networks where > otherwise there would be no feasible deployment of an > ad-hoc networking protocol. From that perspective, it's > almost a no brainer -- either deploy the standard stripped- > down version, or deploy something else nonstandard that > looks exactly like the stripped-down version. > > In summary, if there are cases where the [manet] protocols > can only be deployed without packet-BB header overhead, > then I think we should provide a solution for those cases. > > To be clear, I am happy either way, whether or not packet-BB > headers are mandates in all cases. > > Also, to be clear, we can standardize AODVv2 *with* packet-BB > right now, and submit for consideration another document for > AODVv2 that does not require packet-BB. Or, we can enable both > ways in the next revision. Or, we can standardize AODVv2 > that does NOT use packet-BB, and then submit for consideration > another document that DOES use packet-BB. All cases are just > fine with me, depending on what the working group wants. Completely sharing your view. Cheers. JP. > > Regards, > Charlie P. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpv@cisco.com Sun Apr 1 17:32:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018DF21F8740 for ; Sun, 1 Apr 2012 17:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX6TSG9O-t-m for ; Sun, 1 Apr 2012 17:32:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC821F8739 for ; Sun, 1 Apr 2012 17:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6504; q=dns/txt; s=iport; t=1333326742; x=1334536342; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Q904sbw8TANf2d5weIyD/LXL60oJOETbQYDfM+hNLJw=; b=nIXLEuf3VzidVgnp5LM+BU4rpixy1qDCU9zEAtbi9rxQi3KhscdkLZr+ 8bc7CXNzM9qoQ6CCsv7lawqk2t8Wdj7ahZVyuNYeWMMNZON+ELEq2S5rB DJomJ0pjCluxBcxt+K4Z243AAoal4awsrACbr6jeLOELDBhLmfdqYmnh1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAMAPbyeE+rRDoJ/2dsb2JhbABEJoJptW6BB4IJAQEBAwEBAQEPAVsLBQsLGC4nMAYTIodiBAELm1CdegSQOWMEiFiNCYVwiFeBaIMHgTw X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="36032158" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 00:32:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q320WMb8022236; Mon, 2 Apr 2012 00:32:22 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:22 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:21 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B1D1CA30-26B1-49C0-B715-860D3AF79E04" From: JP Vasseur In-Reply-To: Date: Sun, 1 Apr 2012 12:56:10 -0700 Message-Id: <23CCB64C-FEEA-439A-83F0-9633B0124A4D@cisco.com> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> To: Emmanuel Baccelli X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:21.0852 (UTC) FILETIME=[116B99C0:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:23 -0000 --Apple-Mail=_B1D1CA30-26B1-49C0-B715-860D3AF79E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Mar 29, 2012, at 8:00 AM, Emmanuel Baccelli wrote: > Hi Teco, > maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. Correct. JP. > I meant that, so far, a MANET protocol (and thus AODVv2) is by default = supposed to use packetBB, whereas other protocols may not have to use = packet BB. > Emmanuel >=20 >=20 > On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: > I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >=20 > Teco >=20 >=20 > Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >=20 >> Hi Teco, >> that is a good question. Actually, as far as I can see, LOADng mainly = derives from AODV, and so does AODVv2, obviously. >> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >> Emmanuel >>=20 >>=20 >>=20 >> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >> For the record, I repeat a remark I made on the mic. >> It looks to me LOADnd is targetted for the LLN use case >> and IETF has a wonderful WG for this. It is not MANET. >>=20 >> Teco >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_B1D1CA30-26B1-49C0-B715-860D3AF79E04 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi,

On Mar 29, 2012, at 8:00 AM, Emmanuel Baccelli wrote:

Hi Teco,
maybe I was not clear enough in my previous email: there is no suggestion to use packetBB in any ROLL draft I am aware of.

Correct.

JP.

I meant that, so far, a MANET protocol (and thus AODVv2) is by default supposed to use packetBB, whereas other protocols may not have to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot <teco@inf-net.nl> wrote:
I saw someone presenting a reactive p2p routing protocol in ROLL. I was not aware of a suggestion on using packetBB. If you think it is useful, you could post it over there.

Teco


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende geschreven:

Hi Teco,
that is a good question. Actually, as far as I can see, LOADng mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using packetBB: I suppose it has to do with the size of packets being bigger, and maybe more difficult to fit into small frames such as radio frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to me LOADnd is targetted for the LLN use case
and IETF has a wonderful WG for this. It is not MANET.

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

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


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


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

--Apple-Mail=_B1D1CA30-26B1-49C0-B715-860D3AF79E04-- From jpv@cisco.com Sun Apr 1 17:32:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5A21F874A for ; Sun, 1 Apr 2012 17:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BHy7ANdEgNK for ; Sun, 1 Apr 2012 17:32:23 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FB21F873B for ; Sun, 1 Apr 2012 17:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=11271; q=dns/txt; s=iport; t=1333326743; x=1334536343; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=1ElM/e561BhlEV9Oyj7uVhNQZ/ETj7kOZTc6W9KLjog=; b=ieUIpYdmmxC1LP0lQcCIgDMdF37q56Qp9IMb/J3Sb59SkgbNXwXXKvc6 e4JlpC2dJX+c4RcVw0ZxKGweVnrn3kR6F0Sf2Xt+i6HEdBSNbBq9CGXhb 2/fqxHTeyWv62MVE2U0M5Np6VzYKejWgyI/A4nyYX05coGaiZ14+uQDN1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAMAGHzeE+rRDoH/2dsb2JhbABDJoJ2tW6BB4IJAQEBAwEBAQEPAVsLBQsLEQQBAQEuJygIBhMih2IEAQugFZYUBJA5YwSIWI0JhXCIV4FogweBPA X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="38519393" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 00:32:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q320WN8I021769; Mon, 2 Apr 2012 00:32:23 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:23 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:22 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D19AAA7-A8DB-49ED-BD63-EAFCF521CF85" From: JP Vasseur In-Reply-To: Date: Sun, 1 Apr 2012 12:57:54 -0700 Message-Id: <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:22.0821 (UTC) FILETIME=[11FF7550:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: manet@ietf.org, Emmanuel Baccelli Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:24 -0000 --Apple-Mail=_1D19AAA7-A8DB-49ED-BD63-EAFCF521CF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: > For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. Agree Stan. And I'd like to point out that LLN is not a type of mobile = network =85 the fact that links are lossy and thus the topology is dynamic is not equivalent to a MANET=20 Cheers. JP. > =20 > Regards, > Stan >=20 > From: manet-bounces@ietf.org on behalf of Teco Boot > Sent: Thu 3/29/2012 11:16 AM > To: Emmanuel Baccelli > Cc: manet@ietf.org IETF > Subject: Re: [manet] LOADng and handling this in LLN >=20 > OK. >=20 > My message is that we (MANET) should not compete with ROLL. If someone = thinks it makes sense, or not, to use RFC 5444 for LLN, post it in ROLL. >=20 > If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >=20 > Teco >=20 >=20 > Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >=20 >> Hi Teco, >> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >> Emmanuel >>=20 >>=20 >> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>=20 >> Teco >>=20 >>=20 >> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>=20 >>> Hi Teco, >>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>> Emmanuel >>>=20 >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >>> For the record, I repeat a remark I made on the mic. >>> It looks to me LOADnd is targetted for the LLN use case >>> and IETF has a wonderful WG for this. It is not MANET. >>>=20 >>> Teco >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_1D19AAA7-A8DB-49ED-BD63-EAFCF521CF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 

Cheers.

JP.<= /div>
 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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

= --Apple-Mail=_1D19AAA7-A8DB-49ED-BD63-EAFCF521CF85-- From jpv@cisco.com Sun Apr 1 17:32:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069AE21F8737 for ; Sun, 1 Apr 2012 17:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLJ3VdBZrhoV for ; Sun, 1 Apr 2012 17:32:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAF21F8743 for ; Sun, 1 Apr 2012 17:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5151; q=dns/txt; s=iport; t=1333326744; x=1334536344; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=juQCA9eHMeuW7rT8Se9fyGSonxsmunf7LCgjCkyWhMs=; b=IxdPDoIVQjEkYvQEeZg7iTP1Pgbcfn6UjToLc2V5XfPRWFMlOiXy2KS1 ydTTHzrjv1GnQNEQcZd+Me1TpjA81SzWXfzjz4ER5YwrW7eL7v2XeFEhi XzllxAmFkRBXAk6jhNFrBKTZkgw/6kZKsNV2yIIs9HBtvtp0psMbcFBxI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAMAPbyeE+rRDoI/2dsb2JhbABEJoJptW6BB4IJAQEBAwEBAQEPASc0CwULCxguJzAGEyKHYgQBC5tQnXoEkDljBIhYjQmFcIhXgWiDB4E8 X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="36032160" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 00:32:24 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q320WOfn021084; Mon, 2 Apr 2012 00:32:24 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:24 -0700 Received: from [192.168.1.132] ([10.21.68.45]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:32:23 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Sun, 1 Apr 2012 12:59:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <595EA675-4482-4362-A873-F1C130536AF9@cisco.com> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr> <79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 00:32:23.0633 (UTC) FILETIME=[127B5C10:01CD1068] X-Mailman-Approved-At: Mon, 02 Apr 2012 08:26:34 -0700 Cc: Emmanuel Baccelli , "manet@ietf.org IETF" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 00:32:25 -0000 On Mar 30, 2012, at 2:31 AM, Teco Boot wrote: > Before we (MANET WG) take a look to LOADng, we should discuss=20 > options for getting progress on decisions being made before. If=20 > the outcome is that we should look for alternatives for DYMO (or=20 > AODVv2, if WG accepts the name change as suggested and already=20 > effected by current WG doc editor). >=20 > Don't take me wrong, I do in no way say LOADng is not relevant. > I say: lets try to focus on what we decided to do, or discuss > new options if we need to. In that order. Makes total sense to me too. JP. >=20 > Teco >=20 >=20 > Op 30 mrt. 2012, om 11:19 heeft Ulrich Herberg het volgende = geschreven: >=20 >> Teco, >>=20 >> I don't think we compete with ROLL in this regards. >>=20 >> MANET is chartered to come up with a reactive protocol (and largely >> behind schedule). LOADng is a reactive protocol, and has many >> industrial, large-scale deployments and implementations. I believe = the >> specification is in a very good shape, and close to being ready >> besides minors nits (and missing security considerations section). = But >> we have already assigned the different tasks to the different = authors, >> so I believe we will submit a new revision very soon with these = issues >> fixed. >>=20 >> Of course, if the WG is interested in LOADng, editorial things (such >> as the word "MANET" or "LLN") may likely have to be changed, to make >> clear it is a MANET protocol. >>=20 >> We will certainly have a discussion amongst the authors to see if we >> can accommodate RFC5444. My personal believe is (strictly as >> individual WG member, not as opinion of the collective of the LOADng >> authors) that any reactive document in MANET should be RFC5444 >> compliant. >>=20 >> Regards >> Ulrich >>=20 >>=20 >> On Thu, Mar 29, 2012 at 5:16 PM, Teco Boot wrote: >>> OK. >>>=20 >>> My message is that we (MANET) should not compete with ROLL. If = someone >>> thinks it makes sense, or not, to use RFC 5444 for LLN, post it in = ROLL. >>>=20 >>> If someone has idea's how to get the reactive manet protocol doc = published >>> soon, great. I saw someone spending cycles on it. My turn to say = thanks. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>>=20 >>> Hi Teco, >>> maybe I was not clear enough in my previous email: there is no = suggestion to >>> use packetBB in any ROLL draft I am aware of. >>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default >>> supposed to use packetBB, whereas other protocols may not have to = use packet >>> BB. >>> Emmanuel >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >>>>=20 >>>> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was >>>> not aware of a suggestion on using packetBB. If you think it is = useful, you >>>> could post it over there. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>>=20 >>>> Hi Teco, >>>> that is a good question. Actually, as far as I can see, LOADng = mainly >>>> derives from AODV, and so does AODVv2, obviously. >>>> Maybe there is a way to simply "reconcile" the two approaches and = have >>>> just one protocol (as I tried to express on the mic today). >>>> At first sight the main difference between the two approaches is = probably >>>> the use of packetBB, so far mandatory in MANET. >>>> Hence my question about the advantages of NOT using packetBB: I = suppose it >>>> has to do with the size of packets being bigger, and maybe more = difficult to >>>> fit into small frames such as radio frames used in some LLNs, = indeed? >>>> Emmanuel >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >>>>>=20 >>>>> For the record, I repeat a remark I made on the mic. >>>>> It looks to me LOADnd is targetted for the LLN use case >>>>> and IETF has a wonderful WG for this. It is not MANET. >>>>>=20 >>>>> Teco >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Mon Apr 2 08:41:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE8C21F852E for ; Mon, 2 Apr 2012 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipGdIKt9T7vs for ; Mon, 2 Apr 2012 08:41:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 233F221F8516 for ; Mon, 2 Apr 2012 08:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1699; q=dns/txt; s=iport; t=1333381283; x=1334590883; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=HEnUNKbqT5aTUbRbtuiG8510HVWmNmyOXulnznlD9z0=; b=FDahkbMMOnlKkr3LJXbyKCw6MO6QBXgUhjx90Q6/GaZV99sZ0s1OYCgJ emO/QoqoyyyvMa1tsrGAnRrwcqK+OFFk37XIY7p79GVs228prd7Ee99qW QjEpiXEXedQfvKtvixe1i9yQfMUYb8WOJtvHwAJirOJQhn8oB62cKd7/U k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE3HeU+tJV2d/2dsb2JhbABFuRCBB4IJAQEBAwEBAQEPASUCNAsFCwtGJzAGCgkih2IFC5tGnnaQOWMElWGBEY02gWiDAw X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="71356659" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 02 Apr 2012 15:41:22 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q32FfME7028406; Mon, 2 Apr 2012 15:41:22 GMT Message-Id: <68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> From: Stan Ratliff To: Teco Boot In-Reply-To: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Apr 2012 11:41:44 -0400 References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:41:42 -0000 Teco, Hmmmm...... a dimensionless value used in the routing protocol..... Please see "Radio Link Quality", currently in the DLEP spec. Regards, Stan On Mar 30, 2012, at 11:38 AM, Teco Boot wrote: > Stan, > > Seen the discussion on hop-count and probably lots of other > nice to haves, an employee of a random router vender would > easily get crazy to get all of this in a useful metric for > the routing protocols. > > I suggest to define a new metric type, to be used by modems, > to provide a dimensionless value that is used directly in the > routing protocol. After a bit of discussion, we have a nice > outcome of a 12-bit compressed form of a link metric OLSRv2. > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 > > You may have a need for a 16-bit uncompressed dimensionless value > for OSPF. You could opt for a / 256 of the decompressed value > or go for another metric type. Important: OSPF needs the metric > for outgoing traffic, OLSR for incoming traffic (OLSR transfers > it to neighbor with hello). > > You could use the Neighbor Incoming / Outgoing Metric bits, you > have the 4-bit placeholder already. > > With MAC address-block TLVs, assuming a 6-byte MAC address with > first 3 bytes mostly being equivalent, the space per neighbor > would be 5 bytes. Not that bad. But to make use of this, you > may need to have repeatedly having send this info instead of > having a reliable transport inside DLEP. This needs validity > timers, so it is not a minor change. > > Teco > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Mon Apr 2 08:42:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA06821F85C0 for ; Mon, 2 Apr 2012 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWALCyPnZf-e for ; Mon, 2 Apr 2012 08:42:50 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5B21F85B1 for ; Mon, 2 Apr 2012 08:42:49 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 90611558434 for ; Mon, 2 Apr 2012 08:42:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 40F091BC930B; Mon, 2 Apr 2012 08:42:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2C6541BC930F; Mon, 2 Apr 2012 08:42:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D581674-AF22-43F6-88B4-AC9E009CEA02" From: Thomas Heide Clausen In-Reply-To: <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> Date: Mon, 2 Apr 2012 17:42:45 +0200 Message-Id: <2E639806-EDE6-4C3D-93A1-F3B0BEE06957@thomasclausen.org> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: Emmanuel Baccelli , manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:42:51 -0000 --Apple-Mail=_3D581674-AF22-43F6-88B4-AC9E009CEA02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi JP, On Apr 1, 2012, at 21:57 , JP Vasseur wrote: >=20 > On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: >=20 >> For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. >=20 > Agree Stan. And I'd like to point out that LLN is not a type of mobile = network =85 the fact that links are lossy and thus the > topology is dynamic is not equivalent to a MANET=20 >=20 I think that it is clear that LOADng works well for scenarios where RPL = doesn't - which is the whole raison d'etre for LOADng.=20 I do not really believe that this has anything to do with "mobility", = though, although supporting also that is a nice benefit and a reason for = discussing this also in MANET. Best, Thomas > Cheers. >=20 > JP. >=20 >> =20 >> Regards, >> Stan >>=20 >> From: manet-bounces@ietf.org on behalf of Teco Boot >> Sent: Thu 3/29/2012 11:16 AM >> To: Emmanuel Baccelli >> Cc: manet@ietf.org IETF >> Subject: Re: [manet] LOADng and handling this in LLN >>=20 >> OK. >>=20 >> My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL. >>=20 >> If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >>=20 >> Teco >>=20 >>=20 >> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>=20 >>> Hi Teco, >>> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >>> Emmanuel >>>=20 >>>=20 >>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >>> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>=20 >>>> Hi Teco, >>>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>>> Emmanuel >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot wrote: >>>> For the record, I repeat a remark I made on the mic. >>>> It looks to me LOADnd is targetted for the LLN use case >>>> and IETF has a wonderful WG for this. It is not MANET. >>>>=20 >>>> Teco >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_3D581674-AF22-43F6-88B4-AC9E009CEA02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = JP,

On Apr 1, 2012, at 21:57 , JP Vasseur = wrote:


On Mar 29, = 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote:

For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 


I think that it is clear that LOADng works well for scenarios where = RPL doesn't - which is the whole raison d'etre for = LOADng. 

I do not really believe that this = has anything to do with "mobility", though, although supporting also = that is a nice benefit and a reason for discussing this also in = MANET.

Best,

Thomas

Cheers.

JP.

 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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

_______________= ________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_3D581674-AF22-43F6-88B4-AC9E009CEA02-- From jpv@cisco.com Mon Apr 2 08:54:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B73C21F863F for ; Mon, 2 Apr 2012 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.489 X-Spam-Level: X-Spam-Status: No, score=-109.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL4nVusB8-ai for ; Mon, 2 Apr 2012 08:54:06 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 516A021F85E7 for ; Mon, 2 Apr 2012 08:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=14721; q=dns/txt; s=iport; t=1333382046; x=1334591646; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DC+6CsAvZAH+OVmiyqq9Vbn35Xq8EyVNXOjxYIxtCP8=; b=JlQPGdD5sav2rFoy61k3znJ96/Y92lQ9VxOCmQ/dHWrzaoz7J1t+OQl7 2iGcpiYOa0tECr6jWosauyCbxbhK0yOfIk4HiuNxlKFWQUOSG/D/pKz1R T+ZaLE+aU/zih4XhUr8tJ4Yb+nonkLqLMiSFbNgS7pMuN5DZIu6knFVBr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUGANDKeU+rRDoJ/2dsb2JhbABFgw+2A4EHggkBAQEDAQEBAQ8BWwsFCwsRBAEBAS4nKAgGEyKHYgQBC5tMnnYEkDljBIhYjQmFcIhXgWiDB4E8 X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208,217";a="36118857" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 15:54:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q32Fs5tl013955; Mon, 2 Apr 2012 15:54:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 08:54:05 -0700 Received: from [10.154.203.4] ([10.154.203.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 08:54:04 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBB8426F-76DA-45B8-8F7B-E5C652101CB7" From: JP Vasseur In-Reply-To: <2E639806-EDE6-4C3D-93A1-F3B0BEE06957@thomasclausen.org> Date: Mon, 2 Apr 2012 08:54:04 -0700 Message-Id: References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> <2E639806-EDE6-4C3D-93A1-F3B0BEE06957@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 15:54:04.0779 (UTC) FILETIME=[D48893B0:01CD10E8] Cc: Emmanuel Baccelli , manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:54:07 -0000 --Apple-Mail=_EBB8426F-76DA-45B8-8F7B-E5C652101CB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Thomas, On Apr 2, 2012, at 8:42 AM, Thomas Heide Clausen wrote: > Hi JP, >=20 > On Apr 1, 2012, at 21:57 , JP Vasseur wrote: >=20 >>=20 >> On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: >>=20 >>> For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. >>=20 >> Agree Stan. And I'd like to point out that LLN is not a type of = mobile network =85 the fact that links are lossy and thus the >> topology is dynamic is not equivalent to a MANET=20 >>=20 >=20 > I think that it is clear Could you elaborate a bit more ? > that LOADng works well for scenarios where RPL doesn't - which is the = whole raison d'etre for LOADng.=20 >=20 And provide more data ? > I do not really believe that this has anything to do with "mobility", = though, although supporting also that is a nice benefit and a reason for = discussing this also in MANET. So that we all understand, is Load-ng a MANET protocol or a reactive = protocol for LLN ? Thanks. JP. >=20 > Best, >=20 > Thomas >=20 >> Cheers. >>=20 >> JP. >>=20 >>> =20 >>> Regards, >>> Stan >>>=20 >>> From: manet-bounces@ietf.org on behalf of Teco Boot >>> Sent: Thu 3/29/2012 11:16 AM >>> To: Emmanuel Baccelli >>> Cc: manet@ietf.org IETF >>> Subject: Re: [manet] LOADng and handling this in LLN >>>=20 >>> OK. >>>=20 >>> My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL. >>>=20 >>> If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >>>=20 >>> Teco >>>=20 >>>=20 >>> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>>=20 >>>> Hi Teco, >>>> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >>>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >>>> Emmanuel >>>>=20 >>>>=20 >>>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot wrote: >>>> I saw someone presenting a reactive p2p routing protocol in ROLL. I = was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>>=20 >>>>> Hi Teco, >>>>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>>>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>>>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>>>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>>>> Emmanuel >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = wrote: >>>>> For the record, I repeat a remark I made on the mic. >>>>> It looks to me LOADnd is targetted for the LLN use case >>>>> and IETF has a wonderful WG for this. It is not MANET. >>>>>=20 >>>>> Teco >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail=_EBB8426F-76DA-45B8-8F7B-E5C652101CB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Thomas,

On Apr 2, 2012, at 8:42 AM, Thomas Heide = Clausen wrote:

Hi = JP,

On Apr 1, 2012, at 21:57 , JP Vasseur = wrote:


On Mar 29, = 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote:

For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 


I think that it is clear =

Could you = elaborate a bit more ?

that LOADng = works well for scenarios where RPL doesn't - which is the whole raison = d'etre for = LOADng. 


=
And provide more data ?

I do not really = believe that this has anything to do with "mobility", though, although = supporting also that is a nice benefit and a reason for discussing this = also in = MANET.

So that = we all understand, is Load-ng a MANET protocol or a reactive protocol = for LLN = ?

Thanks.

JP.

<= blockquote type=3D"cite">
Cheers.

JP.

 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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

_______________= ________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


= --Apple-Mail=_EBB8426F-76DA-45B8-8F7B-E5C652101CB7-- From ietf@thomasclausen.org Mon Apr 2 08:56:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56E21F863F for ; Mon, 2 Apr 2012 08:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-xDKbotJehW for ; Mon, 2 Apr 2012 08:56:05 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id CAFFE21F85E7 for ; Mon, 2 Apr 2012 08:56:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id BC923557F1E for ; Mon, 2 Apr 2012 08:56:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 837011C0ED0; Mon, 2 Apr 2012 08:56:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 344881C072A; Mon, 2 Apr 2012 08:56:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A4C09377-2988-4019-A616-6022CD3B0929" From: Thomas Heide Clausen In-Reply-To: Date: Mon, 2 Apr 2012 17:55:59 +0200 Message-Id: <3EC6E685-2723-40C5-8593-B8AC4D9AA6F2@thomasclausen.org> References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> <2E639806-EDE6-4C3D-93A1-F3B0BEE06957@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: Emmanuel Baccelli , manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:56:10 -0000 --Apple-Mail=_A4C09377-2988-4019-A616-6022CD3B0929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi JP, On Apr 2, 2012, at 17:54 , JP Vasseur wrote: > Hi Thomas, >=20 > On Apr 2, 2012, at 8:42 AM, Thomas Heide Clausen wrote: >=20 >> Hi JP, >>=20 >> On Apr 1, 2012, at 21:57 , JP Vasseur wrote: >>=20 >>>=20 >>> On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: >>>=20 >>>> For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. >>>=20 >>> Agree Stan. And I'd like to point out that LLN is not a type of = mobile network =85 the fact that links are lossy and thus the >>> topology is dynamic is not equivalent to a MANET=20 >>>=20 >>=20 >> I think that it is clear >=20 > Could you elaborate a bit more ? >=20 >> that LOADng works well for scenarios where RPL doesn't - which is the = whole raison d'etre for LOADng.=20 >>=20 >=20 > And provide more data ? For example, it does avoid many of the inconveniences listed in the = RPL-Experiences draft. >> I do not really believe that this has anything to do with "mobility", = though, although supporting also that is a nice benefit and a reason for = discussing this also in MANET. >=20 > So that we all understand, is Load-ng a MANET protocol or a reactive = protocol for LLN ? Yes - to both. Best, Thomas > Thanks. >=20 > JP. >=20 >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Cheers. >>>=20 >>> JP. >>>=20 >>>> =20 >>>> Regards, >>>> Stan >>>>=20 >>>> From: manet-bounces@ietf.org on behalf of Teco Boot >>>> Sent: Thu 3/29/2012 11:16 AM >>>> To: Emmanuel Baccelli >>>> Cc: manet@ietf.org IETF >>>> Subject: Re: [manet] LOADng and handling this in LLN >>>>=20 >>>> OK. >>>>=20 >>>> My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL. >>>>=20 >>>> If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>>>=20 >>>>> Hi Teco, >>>>> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >>>>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >>>>> Emmanuel >>>>>=20 >>>>>=20 >>>>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = wrote: >>>>> I saw someone presenting a reactive p2p routing protocol in ROLL. = I was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>>>=20 >>>>>> Hi Teco, >>>>>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>>>>> Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today). >>>>>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>>>>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>>>>> Emmanuel >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = wrote: >>>>>> For the record, I repeat a remark I made on the mic. >>>>>> It looks to me LOADnd is targetted for the LLN use case >>>>>> and IETF has a wonderful WG for this. It is not MANET. >>>>>>=20 >>>>>> Teco >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 --Apple-Mail=_A4C09377-2988-4019-A616-6022CD3B0929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = JP,

On Apr 2, 2012, at 17:54 , JP Vasseur = wrote:

Hi = Thomas,

On Apr 2, 2012, at 8:42 AM, Thomas Heide = Clausen wrote:

Hi = JP,

On Apr 1, 2012, at 21:57 , JP Vasseur = wrote:


On Mar 29, = 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote:

For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 


I think that it is clear =

Could you = elaborate a bit more ?

that LOADng = works well for scenarios where RPL doesn't - which is the whole raison = d'etre for = LOADng. 


=
And provide more data = ?

For example, it = does avoid many of the inconveniences listed in the RPL-Experiences = draft.

I do not really = believe that this has anything to do with "mobility", though, although = supporting also that is a nice benefit and a reason for discussing this = also in = MANET.

So that = we all understand, is Load-ng a MANET protocol or a reactive protocol = for LLN ?

Yes - to = both.

Best,

Thomas
=

Thanks.

JP.

Cheers.

JP.

 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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

_______________= ________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet



= --Apple-Mail=_A4C09377-2988-4019-A616-6022CD3B0929-- From jpv@cisco.com Mon Apr 2 12:50:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8D21F85F9 for ; Mon, 2 Apr 2012 12:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8hlQNTrpVEX for ; Mon, 2 Apr 2012 12:50:37 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9D321F8707 for ; Mon, 2 Apr 2012 12:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=18105; q=dns/txt; s=iport; t=1333396237; x=1334605837; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=iuIdRVjAscWTEJ5+mTgqmEzzwEerjwtC839ioNUhXUA=; b=ZJQP3FKOdZiXQt1m+ukOR4b2uFiUeVYeagUMhXOT4sR4w4JPxkEtuAij Bk3UfmMn7zNqzYbKXzQLK6ChEWCsI/1xDqXWmSvajBstne/Jmnm9+TV69 w+7h2n0b4y7quAZa/juNaMD/MX30D9iii+RMog7urjdjhR47sQQO2b2kv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUGAHz4eU+rRDoH/2dsb2JhbABFgw+0bYEHggkBAQEDAQEBAQ8BWwsFCwsRBAEBAS4nKAgGEyKHYgQBC5tJnwsEkAtjBIhYjQmFcIhXgWiDB4E8 X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208,217";a="36158427" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2012 19:50:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32JoaCM015582; Mon, 2 Apr 2012 19:50:36 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:50:36 -0700 Received: from [10.154.203.4] ([10.154.203.4]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 12:50:36 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E30BAAAF-9CA3-4B1A-BB16-0783706EB09D" From: JP Vasseur In-Reply-To: <3EC6E685-2723-40C5-8593-B8AC4D9AA6F2@thomasclausen.org> Date: Mon, 2 Apr 2012 12:46:04 -0700 Message-Id: References: <22217684.145665.1333028291920.JavaMail.root@zmbs1.inria.fr><79A031FE-09CC-49FD-8243-726B667441D5@inf-net.nl> <7FFABE29-694C-497E-A6F2-8190F0C3264F@cisco.com> <2E639806-EDE6-4C3D-93A1-F3B0BEE06957@thomasclausen.org> <3EC6E685-2723-40C5-8593-B8AC4D9AA6F2@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 02 Apr 2012 19:50:36.0189 (UTC) FILETIME=[DF45E4D0:01CD1109] Cc: Emmanuel Baccelli , manet@ietf.org, "Stan Ratliff \(sratliff\)" Subject: Re: [manet] LOADng and handling this in LLN X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:50:38 -0000 --Apple-Mail=_E30BAAAF-9CA3-4B1A-BB16-0783706EB09D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Thomas, On Apr 2, 2012, at 8:55 AM, Thomas Heide Clausen wrote: > Hi JP, >=20 > On Apr 2, 2012, at 17:54 , JP Vasseur wrote: >=20 >> Hi Thomas, >>=20 >> On Apr 2, 2012, at 8:42 AM, Thomas Heide Clausen wrote: >>=20 >>> Hi JP, >>>=20 >>> On Apr 1, 2012, at 21:57 , JP Vasseur wrote: >>>=20 >>>>=20 >>>> On Mar 29, 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote: >>>>=20 >>>>> For the record, we're not trying to compete with ROLL. We have a = charter item to produce a reactive routing protocol for MANET's. Work = had effectively stopped on said reactive protocol for some time. We need = to either (1) continue work on a reactive MANET protocol, or (2) go back = to the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good question. >>>>=20 >>>> Agree Stan. And I'd like to point out that LLN is not a type of = mobile network =85 the fact that links are lossy and thus the >>>> topology is dynamic is not equivalent to a MANET=20 >>>>=20 >>>=20 >>> I think that it is clear >>=20 >> Could you elaborate a bit more ? >>=20 >>> that LOADng works well for scenarios where RPL doesn't - which is = the whole raison d'etre for LOADng.=20 >>>=20 >>=20 >> And provide more data ? >=20 > For example, it does avoid many of the inconveniences listed in the = RPL-Experiences draft. But as you know, introducing a reactive routing protocol in LLNs = introduces a number of issues, listed in various papers. This is the reason why the ROLL WG ended up electing a pro-active for = LLN after years of work and discussion in the WG group, just wanted to share it with the MANET WG. >=20 >>> I do not really believe that this has anything to do with = "mobility", though, although supporting also that is a nice benefit and = a reason for discussing this also in MANET. >>=20 >> So that we all understand, is Load-ng a MANET protocol or a reactive = protocol for LLN ? >=20 > Yes - to both. In the former case, then discussion should be taken place here (talking = under the control of the MANET WG's chairs of course). In the later case, ROLL is the place to discuss it but already made a = decision on this ... Best Regards. JP. >=20 > Best, >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>> Cheers. >>>>=20 >>>> JP. >>>>=20 >>>>> =20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>> From: manet-bounces@ietf.org on behalf of Teco Boot >>>>> Sent: Thu 3/29/2012 11:16 AM >>>>> To: Emmanuel Baccelli >>>>> Cc: manet@ietf.org IETF >>>>> Subject: Re: [manet] LOADng and handling this in LLN >>>>>=20 >>>>> OK. >>>>>=20 >>>>> My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL. >>>>>=20 >>>>> If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks. >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>> Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven: >>>>>=20 >>>>>> Hi Teco, >>>>>> maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of. >>>>>> I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB. >>>>>> Emmanuel >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = wrote: >>>>>> I saw someone presenting a reactive p2p routing protocol in ROLL. = I was not aware of a suggestion on using packetBB. If you think it is = useful, you could post it over there. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven: >>>>>>=20 >>>>>>> Hi Teco, >>>>>>> that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously. >>>>>>> Maybe there is a way to simply "reconcile" the two approaches = and have just one protocol (as I tried to express on the mic today). >>>>>>> At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET. >>>>>>> Hence my question about the advantages of NOT using packetBB: I = suppose it has to do with the size of packets being bigger, and maybe = more difficult to fit into small frames such as radio frames used in = some LLNs, indeed? >>>>>>> Emmanuel >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = wrote: >>>>>>> For the record, I repeat a remark I made on the mic. >>>>>>> It looks to me LOADnd is targetted for the LLN use case >>>>>>> and IETF has a wonderful WG for this. It is not MANET. >>>>>>>=20 >>>>>>> Teco >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 --Apple-Mail=_E30BAAAF-9CA3-4B1A-BB16-0783706EB09D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = Thomas,

On Apr 2, 2012, at 8:55 AM, Thomas Heide = Clausen wrote:

Hi = JP,

On Apr 2, 2012, at 17:54 , JP Vasseur = wrote:

Hi = Thomas,

On Apr 2, 2012, at 8:42 AM, Thomas Heide = Clausen wrote:

Hi = JP,

On Apr 1, 2012, at 21:57 , JP Vasseur = wrote:


On Mar 29, = 2012, at 8:23 AM, Stan Ratliff (sratliff) wrote:

For = the record, we're not trying to compete with ROLL. We have a charter = item to produce a reactive routing protocol for MANET's. Work had = effectively stopped on said reactive protocol for some time. We need to = either (1) continue work on a reactive MANET protocol, or (2) go back to = the AD's and tell them we've decided against it. So, I think it's = logical to look at current reactive protocols like LOADng to see if they = fit the MANET space. I've looked at RPL, and speaking as a working group = membet (taking my co-chair hat off for a second), I don't believe RPL = fits in the networks we deploy. Does LOADng? Good = question.

Agree = Stan. And I'd like to point out that LLN is not a type of mobile network = =85 the fact that links are lossy and thus the
topology is = dynamic is not equivalent to a = MANET 


I think that it is clear =

Could you = elaborate a bit more ?

that LOADng = works well for scenarios where RPL doesn't - which is the whole raison = d'etre for = LOADng. 


=
And provide more data = ?

For example, it = does avoid many of the inconveniences listed in the RPL-Experiences = draft.

But as you = know, introducing a reactive routing protocol in LLNs introduces a = number of issues, listed in various papers.
This is the reason = why the ROLL WG ended up electing a pro-active for LLN after years of = work and discussion in the WG
group, just wanted to share it = with the MANET WG.


I do not = really believe that this has anything to do with "mobility", though, = although supporting also that is a nice benefit and a reason for = discussing this also in = MANET.

So that = we all understand, is Load-ng a MANET protocol or a reactive protocol = for LLN ?

Yes - to = both.

In the former = case, then discussion should be taken place here (talking under the = control of the MANET WG's chairs of course).
In the later = case, ROLL is the place to discuss it but already made a decision on = this ...

Best = Regards.

JP.

Thanks.

JP.

Cheers.

JP.

 
Regards,
Stan

From: manet-bounces@ietf.org on = behalf of Teco Boot
Sent: Thu 3/29/2012 11:16 AM
To: = Emmanuel Baccelli
Cc: manet@ietf.org = IETF
Subject: Re: [manet] LOADng and handling this in = LLN

OK.=20

My message is that we (MANET) should not compete with ROLL. If = someone thinks it makes sense, or not, to use RFC 5444 for LLN, post it = in ROLL.

If someone has idea's how to get the reactive manet protocol doc = published soon, great. I saw someone spending cycles on it. My turn to = say thanks.

Teco


Op 29 mrt. 2012, om 17:00 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
maybe I was not clear enough in my previous email: there is no = suggestion to use packetBB in any ROLL draft I am aware of.
I meant that, so far, a MANET protocol (and thus AODVv2) is by = default supposed to use packetBB, whereas other protocols may not have = to use packet BB.
Emmanuel


On Thu, Mar 29, 2012 at 4:36 PM, Teco Boot = <teco@inf-net.nl> = wrote:
I saw someone presenting a reactive p2p routing = protocol in ROLL. I was not aware of a suggestion on using packetBB. If = you think it is useful, you could post it over there.=20

Teco
=


Op 29 mrt. 2012, om 15:59 heeft Emmanuel Baccelli het volgende = geschreven:

Hi Teco,=20
that is a good question. Actually, as far as I can see, LOADng = mainly derives from AODV, and so does AODVv2, obviously.
Maybe there is a way to simply "reconcile" the two approaches and = have just one protocol (as I tried to express on the mic today).
At first sight the main difference between the two approaches is = probably the use of packetBB, so far mandatory in MANET.
Hence my question about the advantages of NOT using = packetBB: I suppose it has to do with the size of packets being = bigger, and maybe more difficult to fit into small frames such as radio = frames used in some LLNs, indeed?
Emmanuel



On Thu, Mar 29, 2012 at 3:38 PM, Teco Boot = <teco@inf-net.nl> wrote:
For the record, I repeat a remark I made on the mic.
It looks to = me LOADnd is targetted for the LLN use case
and IETF has a wonderful = WG for this. It is not = MANET.

Teco
_______________________________________________
m= anet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

______________________________________= _________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


________________= _______________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

<= /blockquote>

______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

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

_______________= ________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet



=
= --Apple-Mail=_E30BAAAF-9CA3-4B1A-BB16-0783706EB09D-- From teco@inf-net.nl Mon Apr 2 13:04:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E353A21F85CE for ; Mon, 2 Apr 2012 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsCN-d0oKNVl for ; Mon, 2 Apr 2012 13:04:16 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E91E521F85FF for ; Mon, 2 Apr 2012 13:04:15 -0700 (PDT) Received: by eaaq11 with SMTP id q11so916238eaa.31 for ; Mon, 02 Apr 2012 13:04:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DzWW7nffyyo3GLHaxP6Ans95nEW0s1szIsgM6pm7HvM=; b=ShVbPFgVJSkRNOV1VnD+1Ub4F6hCN0/eZDQU2hqwwcbvXqDr/EbH940ppffJFGXMpo m9CnFjL+BlgrplCSsC03HXOA7vmL6XsG07wxc1k5JGR6hoZ360/SemsQ1LBktknvWZoS EJ+gpo6NNh5AogGlOSrGOQyk3zFGZV/8ybDEi9A1KS1raKUs3IJb0J2SBM5VZd/pWglK GyAmUwN+oZMZYJEKTZTbigCqbK8KGBa8aTHaPzwsBiXMM/IhFTOuCrAZCD0yLGghAX/E drg06DbdoLdG2vMwZU8RbljncTXDDz/ei0dSo9EiFrEW5a9iX9J5PbNC/T4a1kmoMXge IUuQ== Received: by 10.213.28.66 with SMTP id l2mr803626ebc.8.1333397051170; Mon, 02 Apr 2012 13:04:11 -0700 (PDT) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r44sm66363636eef.2.2012.04.02.13.04.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:04:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> Date: Mon, 2 Apr 2012 22:04:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28B3CD58-816B-49C0-9889-BEDA7EEDAB89@inf-net.nl> References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> <68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkZKwiDBx4YbvfCmi0jpCL3aS9oyux34wLqO+alzWRx5UZWfC9PIxJBD1XVXwZ8ra0A2YWh Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:04:17 -0000 Op 2 apr. 2012, om 17:41 heeft Stan Ratliff het volgende geschreven: > Teco, >=20 > Hmmmm...... a dimensionless value used in the routing protocol..... = Please see "Radio Link Quality", currently in the DLEP spec. Echo hmmmmm... I think there are semantics for this metric. And I dislike the limits on = its range. More thoughts: there could be modem devices that are very capable to = provide the link metric for MANET routing. For example, the device could = run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2 = derivate). It would be nice having the (multi-L2-hop-path) link costs = available at L3. Another deployment model is plug&play interfaces (e.g. USB wifi stick), = where DLEP manages this device. Then we need the rich set of attributes, = including channel/power/ssid/keys etc. as Henning mentioned.=20 Teco >=20 > Regards, > Stan >=20 > On Mar 30, 2012, at 11:38 AM, Teco Boot wrote: >=20 >> Stan, >>=20 >> Seen the discussion on hop-count and probably lots of other >> nice to haves, an employee of a random router vender would >> easily get crazy to get all of this in a useful metric for >> the routing protocols. >>=20 >> I suggest to define a new metric type, to be used by modems, >> to provide a dimensionless value that is used directly in the >> routing protocol. After a bit of discussion, we have a nice >> outcome of a 12-bit compressed form of a link metric OLSRv2. >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 >>=20 >> You may have a need for a 16-bit uncompressed dimensionless value >> for OSPF. You could opt for a / 256 of the decompressed value >> or go for another metric type. Important: OSPF needs the metric >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers >> it to neighbor with hello). >>=20 >> You could use the Neighbor Incoming / Outgoing Metric bits, you >> have the 4-bit placeholder already. >>=20 >> With MAC address-block TLVs, assuming a 6-byte MAC address with >> first 3 bytes mostly being equivalent, the space per neighbor >> would be 5 bytes. Not that bad. But to make use of this, you >> may need to have repeatedly having send this info instead of >> having a reliable transport inside DLEP. This needs validity >> timers, so it is not a minor change. >>=20 >> Teco >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From rick.taylor@cassidian.com Tue Apr 3 01:45:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ADA21F8525 for ; Tue, 3 Apr 2012 01:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0ywwtwqRTK4 for ; Tue, 3 Apr 2012 01:45:08 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id DE82721F84D2 for ; Tue, 3 Apr 2012 01:45:06 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 10:45:03 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 10:45:03 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:45:02 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:45:02 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 09:45:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 09:44:44 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0RC/DBMd0aafjoR66Fcjedpch2jAAaK1aw References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl><68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> From: "Rick Taylor" To: "Teco Boot" , "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 08:45:09.0516 (UTC) FILETIME=[1388D4C0:01CD1176] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.005 X-TM-AS-Result: No--24.022500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:45:09 -0000 > Op 2 apr. 2012, om 17:41 heeft Stan Ratliff het volgende geschreven: >=20 > > Teco, > > > > Hmmmm...... a dimensionless value used in the routing protocol..... > Please see "Radio Link Quality", currently in the DLEP spec. >=20 > Echo hmmmmm... > I think there are semantics for this metric. And I dislike the limits on > its range. I take Stan's point that RLQ is a catch-all, I would propose rationalising the set of standard metrics to include a 32bit dimensionless 'value', as well as some SHOULD support metrics, and specify default handling for vendor-specific metric TLVs. I have some thoughts about 'namespacing' the sub-TLVs, particularly for metrics, that I will post separately. > More thoughts: there could be modem devices that are very capable to > provide the link metric for MANET routing. For example, the device could > run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2 > derivate). It would be nice having the (multi-L2-hop-path) link costs > available at L3. Even if the modems were performing layer 2 routing via an OLSRv2 derivative, there is still a need for the layer 3 routing to be told about the connectivity of links via DLEP to prevent fighting, particularly if the modems are running an advanced protocol. > Another deployment model is plug&play interfaces (e.g. USB wifi stick), > where DLEP manages this device. Then we need the rich set of attributes, > including channel/power/ssid/keys etc. as Henning mentioned. Yes, see my comment above. Rick Taylor >=20 > Teco >=20 > > > > Regards, > > Stan > > > > On Mar 30, 2012, at 11:38 AM, Teco Boot wrote: > > > >> Stan, > >> > >> Seen the discussion on hop-count and probably lots of other > >> nice to haves, an employee of a random router vender would > >> easily get crazy to get all of this in a useful metric for > >> the routing protocols. > >> > >> I suggest to define a new metric type, to be used by modems, > >> to provide a dimensionless value that is used directly in the > >> routing protocol. After a bit of discussion, we have a nice > >> outcome of a 12-bit compressed form of a link metric OLSRv2. > >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 > >> > >> You may have a need for a 16-bit uncompressed dimensionless value > >> for OSPF. You could opt for a / 256 of the decompressed value > >> or go for another metric type. Important: OSPF needs the metric > >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers > >> it to neighbor with hello). > >> > >> You could use the Neighbor Incoming / Outgoing Metric bits, you > >> have the 4-bit placeholder already. > >> > >> With MAC address-block TLVs, assuming a 6-byte MAC address with > >> first 3 bytes mostly being equivalent, the space per neighbor > >> would be 5 bytes. Not that bad. But to make use of this, you > >> may need to have repeatedly having send this info instead of > >> having a reliable transport inside DLEP. This needs validity > >> timers, so it is not a minor change. > >> > >> Teco > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Apr 3 02:01:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAEB21F8648 for ; Tue, 3 Apr 2012 02:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsqw3wnf2B2J for ; Tue, 3 Apr 2012 02:00:59 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9721F8647 for ; Tue, 3 Apr 2012 02:00:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="198949093" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 10:00:56 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3390nJW029344; Tue, 3 Apr 2012 10:00:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:00:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 10:00:39 +0100 Message-ID: In-Reply-To: <7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0RC/DBMd0aafjoR66Fcjedpch2jAAaK1awAAC3I+A= References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl><68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> <7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Rick Taylor" , "Teco Boot" , "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 09:00:54.0697 (UTC) FILETIME=[46E80190:01CD1178] Cc: manet@ietf.org Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:01:01 -0000 I think a 24 bit value is better than a 32 bit value if this is to be used = as a link metric by a routing algorithm (not the only possible case of cour= se) as you will have to accumulate them along routes. Admittedly the likeli= hood of the worst case (255 hops with maximal metric each) is low, but the = ability to add up within a 32 bit total without having to perform any form = of overflow checks is useful. An uncompressed 3 octet value could be later converted to another represent= ation (e.g. as in OLSRv2) easily. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= ick Taylor Sent: 03 April 2012 09:45 To: Teco Boot; Stan Ratliff Cc: manet@ietf.org Subject: Re: [manet] DLEP: request for new metric type ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > Op 2 apr. 2012, om 17:41 heeft Stan Ratliff het volgende geschreven: >=20 > > Teco, > > > > Hmmmm...... a dimensionless value used in the routing protocol..... > Please see "Radio Link Quality", currently in the DLEP spec. >=20 > Echo hmmmmm... > I think there are semantics for this metric. And I dislike the limits on > its range. I take Stan's point that RLQ is a catch-all, I would propose rationalising the set of standard metrics to include a 32bit dimensionless 'value', as well as some SHOULD support metrics, and specify default handling for vendor-specific metric TLVs. I have some thoughts about 'namespacing' the sub-TLVs, particularly for metrics, that I will post separately. > More thoughts: there could be modem devices that are very capable to > provide the link metric for MANET routing. For example, the device could > run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2 > derivate). It would be nice having the (multi-L2-hop-path) link costs > available at L3. Even if the modems were performing layer 2 routing via an OLSRv2 derivative, there is still a need for the layer 3 routing to be told about the connectivity of links via DLEP to prevent fighting, particularly if the modems are running an advanced protocol. > Another deployment model is plug&play interfaces (e.g. USB wifi stick), > where DLEP manages this device. Then we need the rich set of attributes, > including channel/power/ssid/keys etc. as Henning mentioned. Yes, see my comment above. Rick Taylor >=20 > Teco >=20 > > > > Regards, > > Stan > > > > On Mar 30, 2012, at 11:38 AM, Teco Boot wrote: > > > >> Stan, > >> > >> Seen the discussion on hop-count and probably lots of other > >> nice to haves, an employee of a random router vender would > >> easily get crazy to get all of this in a useful metric for > >> the routing protocols. > >> > >> I suggest to define a new metric type, to be used by modems, > >> to provide a dimensionless value that is used directly in the > >> routing protocol. After a bit of discussion, we have a nice > >> outcome of a 12-bit compressed form of a link metric OLSRv2. > >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 > >> > >> You may have a need for a 16-bit uncompressed dimensionless value > >> for OSPF. You could opt for a / 256 of the decompressed value > >> or go for another metric type. Important: OSPF needs the metric > >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers > >> it to neighbor with hello). > >> > >> You could use the Neighbor Incoming / Outgoing Metric bits, you > >> have the 4-bit placeholder already. > >> > >> With MAC address-block TLVs, assuming a 6-byte MAC address with > >> first 3 bytes mostly being equivalent, the space per neighbor > >> would be 5 bytes. Not that bad. But to make use of this, you > >> may need to have repeatedly having send this info instead of > >> having a reliable transport inside DLEP. This needs validity > >> timers, so it is not a minor change. > >> > >> Teco > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Tue Apr 3 02:16:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8983321F863F for ; Tue, 3 Apr 2012 02:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oUMJ84ftacy for ; Tue, 3 Apr 2012 02:16:06 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id EE44921F8629 for ; Tue, 3 Apr 2012 02:16:05 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 11:16:00 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 11:16:00 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:15:59 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:15:59 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:16:06 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 10:15:38 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC103566C60@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0ReEinNf6ei++hQbqeQ2NlQtk0agAAKlqA References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl><68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> <7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Teco Boot" , "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 09:16:06.0564 (UTC) FILETIME=[666BDE40:01CD117A] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--37.137000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:16:07 -0000 >=20 > I think a 24 bit value is better than a 32 bit value if this is to be = used > as a link metric by a routing algorithm (not the only possible case of > course) as you will have to accumulate them along routes. Admittedly = the > likelihood of the worst case (255 hops with maximal metric each) is = low, > but the ability to add up within a 32 bit total without having to = perform > any form of overflow checks is useful. I am not proposing that RLQ be used as a routing metric, only as a = metric that is available via DLEP. 24/32/64bit I don't really care, I = was just agreeing with Teco that a [0..100] seemed a little limited, but = in retrospect, as Stan pointed out, it's just a number with no = associated semantic information. Really I would like RLQ dropped as I = would prefer DLEP to only report live data concerning the links: = latency, bandwidth, USB info, ssid, etc. Anything that can be = calculated or is dimensionless should generated by the consumer of the = DLEP metrics. I would also like to separate the RLQ from any TLV describing topology. = I understand that in OLSRv2, the single metric encapsulates the = hop-count information, but pushing that through DLEP as RLQ and changing = the meaning of RLQ to "OLSRv2 metric" is just confusing. I am keen to underline the point that DLEP is about informing layer 3 = processes of layer 2 metrics and connectivity. Whether the layer 3 = processes perform routing or just draw a pretty graph with coloured = lines is irrelevant to DLEP. Rick Taylor >=20 > An uncompressed 3 octet value could be later converted to another > representation (e.g. as in OLSRv2) easily. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Rick Taylor > Sent: 03 April 2012 09:45 > To: Teco Boot; Stan Ratliff > Cc: manet@ietf.org > Subject: Re: [manet] DLEP: request for new metric type >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > > Op 2 apr. 2012, om 17:41 heeft Stan Ratliff het volgende geschreven: > > > > > Teco, > > > > > > Hmmmm...... a dimensionless value used in the routing = protocol..... > > Please see "Radio Link Quality", currently in the DLEP spec. > > > > Echo hmmmmm... > > I think there are semantics for this metric. And I dislike the = limits > on > > its range. >=20 > I take Stan's point that RLQ is a catch-all, I would propose > rationalising the set of standard metrics to include a 32bit > dimensionless 'value', as well as some SHOULD support metrics, and > specify default handling for vendor-specific metric TLVs. >=20 > I have some thoughts about 'namespacing' the sub-TLVs, particularly = for > metrics, that I will post separately. >=20 > > More thoughts: there could be modem devices that are very capable to > > provide the link metric for MANET routing. For example, the device > could > > run a MANET protocol itself, maybe at sub-IP layer (could be OLSRv2 > > derivate). It would be nice having the (multi-L2-hop-path) link = costs > > available at L3. >=20 > Even if the modems were performing layer 2 routing via an OLSRv2 > derivative, there is still a need for the layer 3 routing to be told > about the connectivity of links via DLEP to prevent fighting, > particularly if the modems are running an advanced protocol. >=20 > > Another deployment model is plug&play interfaces (e.g. USB wifi > stick), > > where DLEP manages this device. Then we need the rich set of > attributes, > > including channel/power/ssid/keys etc. as Henning mentioned. >=20 > Yes, see my comment above. >=20 > Rick Taylor >=20 > > > > Teco > > > > > > > > Regards, > > > Stan > > > > > > On Mar 30, 2012, at 11:38 AM, Teco Boot wrote: > > > > > >> Stan, > > >> > > >> Seen the discussion on hop-count and probably lots of other > > >> nice to haves, an employee of a random router vender would > > >> easily get crazy to get all of this in a useful metric for > > >> the routing protocols. > > >> > > >> I suggest to define a new metric type, to be used by modems, > > >> to provide a dimensionless value that is used directly in the > > >> routing protocol. After a bit of discussion, we have a nice > > >> outcome of a 12-bit compressed form of a link metric OLSRv2. > > >> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-14#section-6.2 > > >> > > >> You may have a need for a 16-bit uncompressed dimensionless value > > >> for OSPF. You could opt for a / 256 of the decompressed value > > >> or go for another metric type. Important: OSPF needs the metric > > >> for outgoing traffic, OLSR for incoming traffic (OLSR transfers > > >> it to neighbor with hello). > > >> > > >> You could use the Neighbor Incoming / Outgoing Metric bits, you > > >> have the 4-bit placeholder already. > > >> > > >> With MAC address-block TLVs, assuming a 6-byte MAC address with > > >> first 3 bytes mostly being equivalent, the space per neighbor > > >> would be 5 bytes. Not that bad. But to make use of this, you > > >> may need to have repeatedly having send this info instead of > > >> having a reliable transport inside DLEP. This needs validity > > >> timers, so it is not a minor change. > > >> > > >> Teco > > >> > > >> _______________________________________________ > > >> manet mailing list > > >> manet@ietf.org > > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** From henning.rogge@fkie.fraunhofer.de Tue Apr 3 02:16:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC621F84CE for ; Tue, 3 Apr 2012 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKVvDPzDXn+6 for ; Tue, 3 Apr 2012 02:16:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06321F8455 for ; Tue, 3 Apr 2012 02:16:43 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SEzr0-0002x8-FL for manet@ietf.org; Tue, 03 Apr 2012 11:16:42 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SEzr0-0007ox-D4 for manet@ietf.org; Tue, 03 Apr 2012 11:16:42 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:16:42 +0200 Message-ID: <4F7ABFF9.4000303@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 11:16:41 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net> <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040009010502010505090200" X-OriginalArrivalTime: 03 Apr 2012 09:16:42.0220 (UTC) FILETIME=[7BAC8AC0:01CD117A] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a8bb361c08068357dcb389a69381f4e8 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:16:44 -0000 This is a cryptographically signed message in MIME format. --------------ms040009010502010505090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 03/31/2012 05:59 PM, Das, Subir wrote: > I do not think that Radio or client interface is considered as a L3 rou= ter but Server is. > Also draft says: "DLEP is independent of the underlying link type and t= opology." Yes (especially the type of connection between DLEP client and server=20 can be anything), but I think the main goal of DLEP is to connect a=20 radio/modem/layer-2 device with a router without loosing access to the=20 layer-2 data. If the radio already contains a full layer-3 router, then I am not sure=20 DLEP is necessary. Henning Rogge > _Subir > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: Saturday, March 31, 2012 11:28 AM > To: Das, Subir > Cc: Cole, Robert G CIV USARMY CERDEC (US); manet@ietf.org; sratliff@cis= co.com > Subject: Re: [manet] DLEP and multi-hop neighbours > > From the draft: > >> DLEP assumes that participating clients appear to the server as a >> transparent bridge - specifically, the assumption is that the >> destination MAC address for data traffic in any frame emitted by the >> server should be the MAC address of the next-hop router or end- >> device, and not the MAC address of any of the intervening clients. > > If the "Server/Radio/Interface" is a layer 3 router, why should it need= DLEP? --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040009010502010505090200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMwOTE2NDFaMCMGCSqGSIb3DQEJBDEWBBRclYzntaLjgrbbuGWAB3ywJJayFzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQDGK6vH/BAZi5p8MAgA7lpJ0N9hlibH0giD7NUxRp9dTKKWNVRhIxm6Z20mAqtk 4SrbeKoTn/uPvxTApvJptBo3kGcDIL4V+BkLh6c2KHgLIUP7WnXuQ6/utaFyVpArzUrnRMh3 SDuCR+WldFcdOYIQYfiEawnxUYyyAbn4KrRCJCRNgxW+AKNv2jaIQ7n8/HTr12lBLmyGPehZ 1Z/8NOawfODKCM+l4KZuFAGMfsv1NUoYCU2RkX0DF/rqJCQ1plgi0A06tQEiU2gfdHfxnsYC tk+n/ZBt438L5Sjo1RPzos6koWZHfVZDDWoVPwJMdw52bYr31GI1aKEIknTeZy7aAAAAAAAA --------------ms040009010502010505090200-- From henning.rogge@fkie.fraunhofer.de Tue Apr 3 02:18:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7521F8514 for ; Tue, 3 Apr 2012 02:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt0Szz6IsU0P for ; Tue, 3 Apr 2012 02:18:46 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4621F84CE for ; Tue, 3 Apr 2012 02:18:45 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SEzsz-00030g-18 for manet@ietf.org; Tue, 03 Apr 2012 11:18:45 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SEzsy-0007q7-Uk for manet@ietf.org; Tue, 03 Apr 2012 11:18:44 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:18:44 +0200 Message-ID: <4F7AC073.2010109@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 11:18:43 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl><68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com> <7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080309000804000807050802" X-OriginalArrivalTime: 03 Apr 2012 09:18:44.0783 (UTC) FILETIME=[C4BA2BF0:01CD117A] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:18:46 -0000 This is a cryptographically signed message in MIME format. --------------ms080309000804000807050802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 11:00 AM, Dearlove, Christopher (UK) wrote: > I think a 24 bit value is better than a 32 bit value if this is to be u= sed as a link metric by a routing algorithm (not the only possible case o= f course) as you will have to accumulate them along routes. Admittedly th= e likelihood of the worst case (255 hops with maximal metric each) is low= , but the ability to add up within a 32 bit total without having to perfo= rm any form of overflow checks is useful. > > An uncompressed 3 octet value could be later converted to another repre= sentation (e.g. as in OLSRv2) easily. I agree, if the DLEP-server already creates some "relative estimate" of=20 the link quality, giving it the same range (24 bits) than the OLSRv2=20 routing metric is a good idea. Of course its still the decision of the routing protocol how it use the=20 different values delivered by DLEP to construct its metric. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080309000804000807050802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMwOTE4NDNaMCMGCSqGSIb3DQEJBDEWBBTV+4sxp59oNUq0er3/KE+GbTmzwzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQDA7pTlwDmM0B/OYgR8YsPh+vvCePzprusTCcsu7CU2nvYnG3/eAYJqzNfZgbR/ YXWPOhfmhO41em8Qqy8DmTeVjJciPudxwjNWdqKUl1IaeVJac8670nr3DeQBn8uSyvCpRgrk oksAB1ekmP/rLAK7LrBSpDPfeSNOkfaYEUp9b/DG2rE+GyDlaAHfq6at+Tek2LJuCAP03bsl 7r/Wx3Omau9d9huLr2yOKM00goO9tmcYtvEkHTcDvhI+TEOrv7WD47uLDw6KD7abu21nzBLu W4pgKx0bX+su9UwTnFBTvyI7Gcwk6+gI1dXmTS36RYPPIoiBmvICgdPU4pl1o1OTAAAAAAAA --------------ms080309000804000807050802-- From henning.rogge@fkie.fraunhofer.de Tue Apr 3 02:24:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A37E21F85CD for ; Tue, 3 Apr 2012 02:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMwUny0ORizS for ; Tue, 3 Apr 2012 02:24:33 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2C13321F85AA for ; Tue, 3 Apr 2012 02:24:33 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SEzya-0003FW-Gp for manet@ietf.org; Tue, 03 Apr 2012 11:24:32 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SEzya-00080n-ED for manet@ietf.org; Tue, 03 Apr 2012 11:24:32 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:24:32 +0200 Message-ID: <4F7AC1CF.8000805@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 11:24:31 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl> <2E5FF88B-9A64-4997-AE4C-8F55A276CC66@inf-net.nl> In-Reply-To: <2E5FF88B-9A64-4997-AE4C-8F55A276CC66@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010407070309050701050506" X-OriginalArrivalTime: 03 Apr 2012 09:24:32.0285 (UTC) FILETIME=[93DAC4D0:01CD117B] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 43fe4b22ce746091c894ec5715882e1d Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:24:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010407070309050701050506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/02/2012 06:56 AM, Teco Boot wrote: >> If Layer-2 data is available, it should be exported in "raw" format by= >> the DLEP service/server. Especially data that cannot be easily >> calculated by the connected computer like "Throughput" (real one, not >> just hardware transmission speed), Transmission loss and transmission >> attempts. > The real throughput is a nice metric. But it is not "raw", it is > computed from modulation data rate, loss ratio and set of delays. > CDR could be used for throughput (at sender). The real throughput can be difficult to calculate on the router, even=20 with access to statistics on the radio. But its often much easier to=20 calculate with the rate-control algorithm on a radio. Thats why an=20 (optional) TLV for throughput would be a good idea. If the information=20 is available on the radio, DLEP should share it with the clients. >> And for Radios we definitely need Frequency and Bandwidth (width of >> the radio channel in Hz). These two values are also interesting to use= >> in the "request link characteristic" message to reconfigure a radio. > At the end we have a complete configuration tool. Is that the target? Frequency and (radio-)bandwidth is also interesting for calculating=20 collision groups of radio interfaces. Even if we decide to drop the=20 "Request Link Characteristic" message, this data is useful for a routing = agent. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010407070309050701050506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMwOTI0MzFaMCMGCSqGSIb3DQEJBDEWBBTxuU1F8FtapkbfEYCX05E69dDsDTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQA6l7zTmc1h9krL08hwRrQ+uyz7TkFvYCDXgn7hzU+i0Lsd61XDe+nE3JBSpREN 5BLHkKXCO2kM53O8ktIRNmVI1WucVLfG0mVdCij+LKWqhf237nSnksCnZOa4OvCrCZYtrNCc m8dGaHmyc7pkOYv0x0ncJahtGZ04fPqlWSGYfvwA/aXNN1wAUfkeK23VJKtYEjbNZWaCtMYC bDc6dhI6zXCSuf2eOatmHJDxwRaqs9uwmVQ1KShOJIdvNL7UVxa8UY8/FzfvcD5FeUB/IIVY gLwxpLDsGkgA8stKEIqsv5UGsu3rnrWwl2fD3mh9DKDIXRguwJevjDFjfve03N69AAAAAAAA --------------ms010407070309050701050506-- From Chris.Dearlove@baesystems.com Tue Apr 3 02:27:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652D021F8514 for ; Tue, 3 Apr 2012 02:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9XQuXv6krYJ for ; Tue, 3 Apr 2012 02:27:27 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4734021F84D5 for ; Tue, 3 Apr 2012 02:27:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="198960010" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 10:27:26 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q339RPnI015039; Tue, 3 Apr 2012 10:27:26 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:27:25 +0100 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 Date: Tue, 3 Apr 2012 10:27:24 +0100 Message-ID: In-Reply-To: <4F7AC073.2010109@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP: request for new metric type Thread-Index: Ac0ResjfXlIdsja0Q4iA775/rq0xQwAAMNAA References: <181CA2B2-909B-4BC9-A129-0CB7B8E70A8A@inf-net.nl><68A2D3B1-1F7D-49E5-8E97-39A694D3AD26@cisco.com><7B31B0093014224A843C10C0CCE92AC103566BCC@SUKNPT8106.cogent-dsn.local> <4F7AC073.2010109@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 03 Apr 2012 09:27:25.0968 (UTC) FILETIME=[FB60B100:01CD117B] Subject: Re: [manet] DLEP: request for new metric type X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:27:28 -0000 I wouldn't say that giving it the same range as OLSRv2 is what matters, OLS= Rv2 is just one protocol. Rather that there's logic in why OLSRv2 picked 24= bits (when uncompressed) and that logic may (I put it no stronger) be wort= h considering as an option in DLEP. All the physically relevant information= is of course also important in many contexts. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 03 April 2012 10:19 To: manet@ietf.org Subject: Re: [manet] DLEP: request for new metric type On 04/03/2012 11:00 AM, Dearlove, Christopher (UK) wrote: > I think a 24 bit value is better than a 32 bit value if this is to be use= d as a link metric by a routing algorithm (not the only possible case of co= urse) as you will have to accumulate them along routes. Admittedly the like= lihood of the worst case (255 hops with maximal metric each) is low, but th= e ability to add up within a 32 bit total without having to perform any for= m of overflow checks is useful. > > An uncompressed 3 octet value could be later converted to another represe= ntation (e.g. as in OLSRv2) easily. I agree, if the DLEP-server already creates some "relative estimate" of=20 the link quality, giving it the same range (24 bits) than the OLSRv2=20 routing metric is a good idea. Of course its still the decision of the routing protocol how it use the=20 different values delivered by DLEP to construct its metric. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From john.dowdell@cassidian.com Tue Apr 3 02:42:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA821F853C for ; Tue, 3 Apr 2012 02:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay2E1UsZgaeE for ; Tue, 3 Apr 2012 02:42:55 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6321F8539 for ; Tue, 3 Apr 2012 02:42:54 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 11:42:53 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 11:42:53 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:42:53 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:42:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 10:45:57 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0ResUQ6/mPi6mwTyWvQZZ7asd1mAAAwZmw References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> From: "John Dowdell" To: X-OriginalArrivalTime: 03 Apr 2012 09:42:52.0962 (UTC) FILETIME=[23E8C020:01CD117E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--19.992800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:42:56 -0000 If the radio implementation contains the radio function and the routing = function, then I believe that DLEP is still necessary to allow the radio = function to send radio metrics to the routing function. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: 03 April 2012 10:17 To: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours On 03/31/2012 05:59 PM, Das, Subir wrote: > I do not think that Radio or client interface is considered as a L3 = router but Server is. > Also draft says: "DLEP is independent of the underlying link type and = topology." Yes (especially the type of connection between DLEP client and server=20 can be anything), but I think the main goal of DLEP is to connect a=20 radio/modem/layer-2 device with a router without loosing access to the=20 layer-2 data. If the radio already contains a full layer-3 router, then I am not sure=20 DLEP is necessary. Henning Rogge > _Subir > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: Saturday, March 31, 2012 11:28 AM > To: Das, Subir > Cc: Cole, Robert G CIV USARMY CERDEC (US); manet@ietf.org; = sratliff@cisco.com > Subject: Re: [manet] DLEP and multi-hop neighbours > > From the draft: > >> DLEP assumes that participating clients appear to the server as a >> transparent bridge - specifically, the assumption is that the >> destination MAC address for data traffic in any frame emitted by the >> server should be the MAC address of the next-hop router or end- >> device, and not the MAC address of any of the intervening clients. > > If the "Server/Radio/Interface" is a layer 3 router, why should it = need DLEP? --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Tue Apr 3 02:44:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7924B21F855F for ; Tue, 3 Apr 2012 02:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyfy-4sDhGMa for ; Tue, 3 Apr 2012 02:44:32 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5877221F853C for ; Tue, 3 Apr 2012 02:44:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF0Hv-0004JY-ND for manet@ietf.org; Tue, 03 Apr 2012 11:44:31 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF0Hv-0000Fx-Kd for manet@ietf.org; Tue, 03 Apr 2012 11:44:31 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:44:31 +0200 Message-ID: <4F7AC67E.8080607@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 11:44:30 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> <1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030809080305030402010801" X-OriginalArrivalTime: 03 Apr 2012 09:44:31.0481 (UTC) FILETIME=[5EA18E90:01CD117E] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:44:33 -0000 This is a cryptographically signed message in MIME format. --------------ms030809080305030402010801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 11:45 AM, John Dowdell wrote: > If the radio implementation contains the radio function and the routing= function, then I believe that DLEP is still necessary to allow the radio= function to send radio metrics to the routing function. Yes, thats right. But would this also mean IP addresses to be transfered? Most likely they = are known by the routing function, not the radio one. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030809080305030402010801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMwOTQ0MzBaMCMGCSqGSIb3DQEJBDEWBBSK1XnOTApsM7WzIwfIQRvbRAiPqjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAIQ3XFod1lYecJrHNdYLd+CT9DACws0EGo2nZ4Yj4b95IeKWKEM5Dnykl+1ucr Xl+VH2nf1Dr8kpBwDBZk7TLYvm4KClrPKmaDli/2g2KahjVZUgMfloHY/7c+Pu8TNG/CBZB9 WsJq8QsDLd6Gx5JB6oZgv1KRIZwRJB+y9Luoev2MCS2tbvKNFdJyNjwZDj6YN+QuZXyzfK58 7GWObpSIiontWsg4hEA44ylfIofg9DvTZRIyojOBMv7ohyFfmw7N8QKXR0Mplxl0RdLUt56a GXLP2C55I7zkEaMurEhBLS99WqVZ6NkcWX4sMRJIyW4aeXASzPyh0JC0/ssmjHPKAAAAAAAA --------------ms030809080305030402010801-- From rick.taylor@cassidian.com Tue Apr 3 02:49:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431FC21F863C for ; Tue, 3 Apr 2012 02:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvtvepu64YvK for ; Tue, 3 Apr 2012 02:49:02 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3121F8633 for ; Tue, 3 Apr 2012 02:48:55 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 03 Apr 2012 11:48:53 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 11:48:53 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:48:53 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:48:53 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:49:00 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 10:48:32 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RfpJz1Hmlu35YTgCqwuVvBG9lvwAAEaxg References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> From: "Rick Taylor" To: X-OriginalArrivalTime: 03 Apr 2012 09:49:00.0427 (UTC) FILETIME=[FEEF75B0:01CD117E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--16.113700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:49:03 -0000 >=20 > On 04/03/2012 11:45 AM, John Dowdell wrote: > > If the radio implementation contains the radio function and the = routing > function, then I believe that DLEP is still necessary to allow the = radio > function to send radio metrics to the routing function. >=20 > Yes, thats right. >=20 > But would this also mean IP addresses to be transfered? Most likely = they > are known by the routing function, not the radio one. >=20 They are still of use to the DLEP peer, as it might just be using the = DLEP association for analysis purposes, rather than routing. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Henning Rogge > Sent: 03 April 2012 10:45 > To: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > On 04/03/2012 11:45 AM, John Dowdell wrote: > > If the radio implementation contains the radio function and the = routing > function, then I believe that DLEP is still necessary to allow the = radio > function to send radio metrics to the routing function. >=20 > Yes, thats right. >=20 > But would this also mean IP addresses to be transfered? Most likely = they > are known by the routing function, not the radio one. >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Tue Apr 3 04:51:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EB521F8539 for ; Tue, 3 Apr 2012 04:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKDYx04nNSzv for ; Tue, 3 Apr 2012 04:51:21 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0062F21F84A0 for ; Tue, 3 Apr 2012 04:51:20 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF2Gd-0002Eu-I0 for manet@ietf.org; Tue, 03 Apr 2012 13:51:19 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF2Gd-0003pu-FM for manet@ietf.org; Tue, 03 Apr 2012 13:51:19 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 13:51:19 +0200 Message-ID: <4F7AE432.9080409@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 13:51:14 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040404060007060306040201" X-OriginalArrivalTime: 03 Apr 2012 11:51:19.0279 (UTC) FILETIME=[153B67F0:01CD1190] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:51:23 -0000 This is a cryptographically signed message in MIME format. --------------ms040404060007060306040201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 11:48 AM, Rick Taylor wrote: >> >> On 04/03/2012 11:45 AM, John Dowdell wrote: >>> If the radio implementation contains the radio function and the routi= ng >> function, then I believe that DLEP is still necessary to allow the rad= io >> function to send radio metrics to the routing function. >> >> Yes, thats right. >> >> But would this also mean IP addresses to be transfered? Most likely th= ey >> are known by the routing function, not the radio one. >> > > They are still of use to the DLEP peer, as it might just be using the D= LEP association for analysis purposes, rather than routing. What is the DLEP peer? Does DLEP communicate over the radio link? If it=20 does not, how does it get the IP addresses? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040404060007060306040201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMTUxMTdaMCMGCSqGSIb3DQEJBDEWBBSx7DjMFc0mveLYWXNbAuf3rZSXMzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAT4V5Yt/skERFeNhEDN/7Zhl75cs4O6mjY24ffXEwWCL+wFLIc6gX10M+uH6Po LTFH97osKWoSHh4WVJDAa1bht7aWLR5kSiA2Fd2NwY4DNQ9iaz8girV4qqw7z771diNM44sO hdXE5XqiLK/+jEDASblDRcadU2N5qg3Wsbiw2UAGf/rqFzeOnToCvQfQSgENC5ygRoPGd6JF ivGibYhCvtjCTAxPHjxq+JIFNdcXwI7HnUz2m87jAubE6cqWSylLO3jdcmpWGKJ2Ul41zsNH unP0MqnVUuGu0Ik6Ehd3F1hFwo6UzJI1J9GspietVigqSzodXcRkKlDb8zIJs2ZOAAAAAAAA --------------ms040404060007060306040201-- From rick.taylor@cassidian.com Tue Apr 3 05:11:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E53821F8772 for ; Tue, 3 Apr 2012 05:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-ZxzLtGzbhd for ; Tue, 3 Apr 2012 05:11:05 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7799521F8770 for ; Tue, 3 Apr 2012 05:11:03 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 03 Apr 2012 14:11:01 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 14:11:01 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:11:00 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:10:59 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 13:11:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 13:10:38 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RkDyTsn/mLfMlS0KE3iUtsvHmHwAAmqZQ References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 03 Apr 2012 12:11:07.0239 (UTC) FILETIME=[D94FB770:01CD1192] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--18.286000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:11:06 -0000 By DLEP peer, I meant the DLEP server/router (rather than the radio). = Of course the DLEP server/router may not actually be doing any routing, = just reporting. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Henning Rogge > Sent: 03 April 2012 12:51 > To: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > On 04/03/2012 11:48 AM, Rick Taylor wrote: > >> > >> On 04/03/2012 11:45 AM, John Dowdell wrote: > >>> If the radio implementation contains the radio function and the > routing > >> function, then I believe that DLEP is still necessary to allow the > radio > >> function to send radio metrics to the routing function. > >> > >> Yes, thats right. > >> > >> But would this also mean IP addresses to be transfered? Most likely > they > >> are known by the routing function, not the radio one. > >> > > > > They are still of use to the DLEP peer, as it might just be using = the > DLEP association for analysis purposes, rather than routing. >=20 > What is the DLEP peer? Does DLEP communicate over the radio link? If = it > does not, how does it get the IP addresses? >=20 > Henning Rogge >=20 >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Tue Apr 3 05:16:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D8621F8770 for ; Tue, 3 Apr 2012 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK3PTN2ukKDI for ; Tue, 3 Apr 2012 05:16:09 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26421F8767 for ; Tue, 3 Apr 2012 05:16:09 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF2ee-0003SO-2s; Tue, 03 Apr 2012 14:16:08 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF2ee-0004Vr-0B; Tue, 03 Apr 2012 14:16:08 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:16:07 +0200 Message-ID: <4F7AEA06.4080609@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 14:16:06 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Rick Taylor References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030109020000070608020507" X-OriginalArrivalTime: 03 Apr 2012 12:16:07.0773 (UTC) FILETIME=[8C7190D0:01CD1193] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:16:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030109020000070608020507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 02:10 PM, Rick Taylor wrote: > By DLEP peer, I meant the DLEP server/router (rather than the radio). = Of course the DLEP server/router may not actually be doing any routing, j= ust reporting. If I remember the DLEP draft right, the radio (client) is the=20 information producer and the router (server) is the information consumer.= > In order to implement discovery in the DLEP protocol (thereby > avoiding some configuration), we have defined a first-speaker and a > passive-listener scheme. Borrowing from existing terminology, this > document refers to the first-speaker as the 'client', and the passive > listener as the 'server', even though there is no client/server > relationship in the classic sense. In a typical deployment, a router > would appear as the DLEP 'server', and an attached modem device would > act as the 'client' (e.g. the initiator for discovery). If this is right, I still would like to see a use-case where the radio=20 knows about IP addresses and has to tell them the router. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030109020000070608020507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMjE2MDZaMCMGCSqGSIb3DQEJBDEWBBTo7bimdrwvh5X7eqhJloB3hcmW8DBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCFqMrw9bO8ltcpto1hTUWN/Yrh6VukG+VrJxGa15H64Dfy55TtCxj1pKNNsG+g 1M54yA+8mRNPdMNAQfeATJ1xiRHR9NUvhsBRRX1pqgaBHrSQWT0KfKnS800w6h564JsPtb7Y rgB0rcENX41wTVi5lUDuzAFQd+tZXsQ1y92Git+DA/5e3yAzLKvognD7fL4VODM4U+M5bTFs ULa7Jt5+Jw3I2bfcWc8y+8sMXzL6ubrfB7co2wTX0qJcqAByUHkl/XrWnfYlf0kZvG0fzoCo PC5NG7dIR+cArvzmTDd4ZEhmBJHWWQSp5VmSpbUpaEJg98EV206ReTc2rWFX6UOJAAAAAAAA --------------ms030109020000070608020507-- From henning.rogge@fkie.fraunhofer.de Tue Apr 3 05:23:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0FC21F85D6 for ; Tue, 3 Apr 2012 05:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJFPvyJedMh6 for ; Tue, 3 Apr 2012 05:23:46 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7224821F85B8 for ; Tue, 3 Apr 2012 05:23:45 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF2lz-0003lU-K7 for manet@ietf.org; Tue, 03 Apr 2012 14:23:43 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF2lz-0004hf-HS for manet@ietf.org; Tue, 03 Apr 2012 14:23:43 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:23:43 +0200 Message-ID: <4F7AEBCE.6070405@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 14:23:42 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: manet@ietf.org References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <4F7AEA06.4080609@fkie.fraunhofer.de> In-Reply-To: <4F7AEA06.4080609@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090500060801090702090504" X-OriginalArrivalTime: 03 Apr 2012 12:23:43.0354 (UTC) FILETIME=[9BFDB5A0:01CD1194] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c9c66f32f18f586296172d92028f39d6 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:23:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090500060801090702090504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 02:16 PM, Henning Rogge wrote: > If this is right, I still would like to see a use-case where the radio > knows about IP addresses and has to tell them the router. Just to clarify this... I really do NOT want to remove anything from=20 DLEP that is useful. But at the moment I lack the knowledge about the=20 common usecase for IP-addresses in DLEP. Maybe someone can explain his=20 usecase. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms090500060801090702090504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMjIzNDJaMCMGCSqGSIb3DQEJBDEWBBTimFjY32H9AdYLedK8CC+7zoKy2jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAr96sEnvPgGqOMKbAhzlyK4V5rbg694wD5CmHmKQk0e+PXZ/lwvFlr3cZ3+ncj 7YQti455zRqRIDcmJm8p/m7YArsKah1MBzhi5n1r4zkM7E14A+KEQSD72Pp/khvCWfqujXoO RLUfVpvAiXVAyK6G8eVmVt/aV/+hW7Jy54DJPMS6K+Cbzo8QkEINteL2h0M5ZhlSV8Xvl5My XCzhiYSofFFdFRCdFauQGsO0bjmA1+zpSzmAIQXqkbztYS16xK5tqtyKqe3DvhS8/mF18iJS ddDD6UTV9uPN2PQo/Aa1AfTpgBTyb4OkLuNCVDPSW2GxSiz4l75DgdLT3oWLuM1mAAAAAAAA --------------ms090500060801090702090504-- From rick.taylor@cassidian.com Tue Apr 3 05:33:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE89221F877B for ; Tue, 3 Apr 2012 05:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdO3p2AqZk0z for ; Tue, 3 Apr 2012 05:33:21 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36AA621F8762 for ; Tue, 3 Apr 2012 05:33:04 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 14:33:03 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 14:33:02 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:33:02 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:33:02 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 13:33:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 13:32:41 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rk81jMB7QNZ1LTY64zCcaaPlwgwAAXOaQ References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 12:33:09.0934 (UTC) FILETIME=[EDB2F4E0:01CD1195] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--31.732800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:33:22 -0000 The use-case as I see it is: =20 1) A new (unknown) neighbour (modem+router pair) joins the radio net. 2) Each existing modem informs its associated router (server) via a = NeighbourUp message of the new arrival. Included in this message is the = layer 2 and layer 3 IP addresses of the new *router*. 3) The routing protocol can now use the new router as a peer for = whatever routing protocol it is running without resorting to neighbour = discovery (as it is already discovered). If the IP address is not included in the NeighbourUp message (but the = layer 2 address is) then each existing router must perform some kind of = discovery (ARP, or IPv6 equivalent) increasing control traffic across = the radio net, before any useful router to router communication can be = performed. I hope that helps? Rick Taylor > -----Original Message----- > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > Sent: 03 April 2012 13:16 > To: Rick Taylor > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > On 04/03/2012 02:10 PM, Rick Taylor wrote: > > By DLEP peer, I meant the DLEP server/router (rather than the = radio). > Of course the DLEP server/router may not actually be doing any = routing, > just reporting. >=20 > If I remember the DLEP draft right, the radio (client) is the > information producer and the router (server) is the information = consumer. >=20 > > In order to implement discovery in the DLEP protocol (thereby > > avoiding some configuration), we have defined a first-speaker and a > > passive-listener scheme. Borrowing from existing terminology, this > > document refers to the first-speaker as the 'client', and the = passive > > listener as the 'server', even though there is no client/server > > relationship in the classic sense. In a typical deployment, a = router > > would appear as the DLEP 'server', and an attached modem device = would > > act as the 'client' (e.g. the initiator for discovery). >=20 > If this is right, I still would like to see a use-case where the radio > knows about IP addresses and has to tell them the router. >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Tue Apr 3 05:38:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCFA21F85F0 for ; Tue, 3 Apr 2012 05:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj+bBoEDZWCa for ; Tue, 3 Apr 2012 05:38:20 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5621F852B for ; Tue, 3 Apr 2012 05:38:20 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF307-0004TM-FN; Tue, 03 Apr 2012 14:38:19 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF307-00057N-Ci; Tue, 03 Apr 2012 14:38:19 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:38:19 +0200 Message-ID: <4F7AEF3A.2090206@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 14:38:18 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Rick Taylor References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080608000200080203090905" X-OriginalArrivalTime: 03 Apr 2012 12:38:19.0188 (UTC) FILETIME=[A6075F40:01CD1196] X-Virus-Scanned: yes (ClamAV 0.97.3/14735/Mon Apr 2 23:36:23 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:38:21 -0000 This is a cryptographically signed message in MIME format. --------------ms080608000200080203090905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 02:32 PM, Rick Taylor wrote: > The use-case as I see it is: > > 1) A new (unknown) neighbour (modem+router pair) joins the radio net. > 2) Each existing modem informs its associated router (server) via a Nei= ghbourUp message of the new arrival. Included in this message is the lay= er 2 and layer 3 IP addresses of the new *router*. Where does the modem of the other side get the IP address? Why is the=20 exchange of IP addresses not done between the routing daemons? If I understand you right you added a custom "layer-3 IP" field into the = layer-2 network announcement of your radio. In this case, forwarding=20 this layer-3 data makes sense. Does this mean that your layer-2 beacon/announcement contain ALL IP=20 addresses of your router? Or just one IP that allows you to contact the=20 router over the radio/modem? > I hope that helps? Yes, I think it did. We are getting to the important part of my problem. = :) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080608000200080203090905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMjM4MThaMCMGCSqGSIb3DQEJBDEWBBR/Av1ltn1/WEWtpFQcHQwsZopcPzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAQakVxuqxMSvEDtOhKIgr9eTuoSJPtMB24c1o0Tpg4fb08gLFq84e5Ckvus6O3 iYLIbEzJfnlrarPOAH18zIsza/cBBZb5NtLvrM1v5WnWJioZiwswu6/lvFJQtpYjJ6B6nD+f N6jY3Eovq8Z2k2c/yPelfyzaseG4AYPFF2AnqGXOee0Oise+HPdQVqsJXbNKgkiS9YBlu6wG 2QFq2VxRpw92P0qGM+laF5uS0Np1M3wt9hgu8kUAGxuiIEzGm7BzqOVrTH3gn74uDAyOb0Qw Zi2bwwGkUral743sDF9R1VJ4qz90b85tHFCFaw33GxnaXlJgbvGQp3ghdS3A+8HDAAAAAAAA --------------ms080608000200080203090905-- From rick.taylor@cassidian.com Tue Apr 3 05:54:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3705521F879B for ; Tue, 3 Apr 2012 05:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkdncXnuNaUC for ; Tue, 3 Apr 2012 05:54:37 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id B0C9921F8762 for ; Tue, 3 Apr 2012 05:54:36 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 03 Apr 2012 14:54:35 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 14:54:35 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:54:35 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:54:34 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 13:54:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 13:54:14 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RlsQo6AP1/McZS7uq0Czqpf96QgAABHVA References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 12:54:42.0107 (UTC) FILETIME=[EFE4E8B0:01CD1198] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--22.621400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 12:54:38 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/03/2012 02:32 PM, Rick Taylor wrote: > > The use-case as I see it is: > > > > 1) A new (unknown) neighbour (modem+router pair) joins the radio = net. > > 2) Each existing modem informs its associated router (server) via a > NeighbourUp message of the new arrival. Included in this message is = the > layer 2 and layer 3 IP addresses of the new *router*. >=20 > Where does the modem of the other side get the IP address? Why is the > exchange of IP addresses not done between the routing daemons? It does not matter where the IP address is from, possibly DHCP, = Autodiscovery, static assignment, etc..., but it is expected that the = address will be valid within the context of the radio net. Of course, the neighbour IP address is an optional TLV, and we have some = radios that do report it on NeighbourUp and some that don't. The exchange of addresses can be done between the routers, but it may = not be needed, and it is more efficient to not do it. Currently on IPv4 = networks I have to send specially crafted ICMP ping packets to populate = both routers ARP tables, and this has to be done between each neighbour. = (There may be a better way but InARP isn't well-supported!) >=20 > If I understand you right you added a custom "layer-3 IP" field into = the > layer-2 network announcement of your radio. In this case, forwarding > this layer-3 data makes sense. As before, when IP addresses are available at the layer-2 control plane, = the "radio magic" layer as Stan describes it, then it makes sense to = report this via DLEP >=20 > Does this mean that your layer-2 beacon/announcement contain ALL IP > addresses of your router? Or just one IP that allows you to contact = the > router over the radio/modem? Only the IP addresses of the interface directly attached to the modem, = i.e. the addresses accessible via the layer-2 network of the radios. >=20 > > I hope that helps? >=20 > Yes, I think it did. We are getting to the important part of my = problem. > :) >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Tue Apr 3 06:02:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5896121F8629 for ; Tue, 3 Apr 2012 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovCF0yEiKrkY for ; Tue, 3 Apr 2012 06:02:24 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5838921F8613 for ; Tue, 3 Apr 2012 06:02:24 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF3NP-0005gW-Jq; Tue, 03 Apr 2012 15:02:23 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF3NP-0005pE-HA; Tue, 03 Apr 2012 15:02:23 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:02:23 +0200 Message-ID: <4F7AF4DA.6040407@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 15:02:18 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Rick Taylor References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040400040701040309050003" X-OriginalArrivalTime: 03 Apr 2012 13:02:23.0322 (UTC) FILETIME=[02CCBBA0:01CD119A] X-Virus-Scanned: yes (ClamAV 0.97.3/14736/Tue Apr 3 14:04:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 90edfc314e3c23e7293fd49106c104bf Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:02:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040400040701040309050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 02:54 PM, Rick Taylor wrote: > It does not matter where the IP address is from, possibly DHCP, > Autodiscovery, static assignment, etc..., but it is expected that > the address will be valid within the context of the radio net. > > Of course, the neighbour IP address is an optional TLV, and we have > some radios that do report it on NeighbourUp and some that don't. > > The exchange of addresses can be done between the routers, but it may > not be needed, and it is more efficient to not do it. Currently on > IPv4 networks I have to send specially crafted ICMP ping packets to > populate both routers ARP tables, and this has to be done between > each neighbour. (There may be a better way but InARP isn't > well-supported!) Okay. >> If I understand you right you added a custom "layer-3 IP" field >> into the layer-2 network announcement of your radio. In this case, >> forwarding this layer-3 data makes sense. > > As before, when IP addresses are available at the layer-2 control > plane, the "radio magic" layer as Stan describes it, then it makes > sense to report this via DLEP Especially in the context of bandwidth restrained radios this makes sense= =2E >> Does this mean that your layer-2 beacon/announcement contain ALL >> IP addresses of your router? Or just one IP that allows you to >> contact the router over the radio/modem? > > Only the IP addresses of the interface directly attached to the > modem, i.e. the addresses accessible via the layer-2 network of the > radios. What would you think about having an address-TLV for this interface IP? It would only be necessary if the IP is not equals to the mac generated IPv6 linklocal IP. If this resolves the usecase for IP addresses in DLEP messages, we could use normal PacketBB addresses for all the MAC addresses. Which would us to allow address compression for them. And it would easily resolve the problem of "attaching" the addresses to each other... and we would not need multi-length addresses. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040400040701040309050003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMzAyMjFaMCMGCSqGSIb3DQEJBDEWBBRqApC4a+aBDtL5j2Cv7HSLzxAn7DBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQARpBIMqFSAc4i57tXy6Fr2YOe+8X4C3cHZdW0Je7o2Q3imlPXFYYZ+rANivT2n EOMTKFiuCaagIr4B3Gs6pAqLvj4E1Rls7HTpo0zMhsNzQlBH1ZI46RkIxkDgmIezjffylnVM boV9RtXBk09J9Qls0jAgoGnDSGZi3C5+wyP0FxGXh9LTes5jzvqu5Gu63w4CHMOjXNGUzNGu OOMGpulvAeFr82Z0PiX9UniOlldH1v7DQZazBbYeZW9v0olD8ABNktIco1i/208yi1zgDpAz UeTuz1uQ0vyaKm7y/eg8nPQn0ynXZWCYbImUcA49cBv+0/Zy0asjI9Ve1zB8bEdeAAAAAAAA --------------ms040400040701040309050003-- From rick.taylor@cassidian.com Tue Apr 3 06:20:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A2011E8091 for ; Tue, 3 Apr 2012 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx0wfC3WW+nT for ; Tue, 3 Apr 2012 06:20:58 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id E546D11E808F for ; Tue, 3 Apr 2012 06:20:55 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 03 Apr 2012 15:20:55 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 15:20:54 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:20:54 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:20:54 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:21:01 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 14:20:33 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rmkuv+UU2Ji16RgiyeCOKO9tBWgAAEDuw References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 13:21:01.0406 (UTC) FILETIME=[9D3ACFE0:01CD119C] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--12.788400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:20:59 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > What would you think about having an address-TLV for this interface = IP? There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) and = IPv6 Address Sub-TLV (10.6, page 15) These SHOULD be used when layer-3 addresses are known by the modem. = (There has been some talk of generalizing them into a Layer-3 Address = Sub-TLV of a sockets style [addr_family, addr_len, addr_octets] tuple, = but I'm personally not bothered either way). > It would only be necessary if the IP is not equals to the mac = generated > IPv6 linklocal IP. Yes, one could calculate the IPv6 address from the neighbours MAC = address and the receiver's prefix if an IPv6 address is not provided. =20 > If this resolves the usecase for IP addresses in DLEP messages, we = could > use normal PacketBB addresses for all the MAC addresses. Which would = us > to allow address compression for them. >=20 > And it would easily resolve the problem of "attaching" the addresses = to > each other... and we would not need multi-length addresses. Yes, yes, yes! This is what I have been trying to get across (badly!). = The Address-Block TLV's are all associated with layer-2 (MAC) addresses, = with optional sub-TLV's in the block carrying layer-3 addresses when = known. Of course these Address-Block TLV's only apply to Neighbour* messages. = Any 'local' router<->modem messages (Peer*) should be Message TLV's as = they do not have an address context that has any real meaning. I hope that helps? Rick Taylor >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From william.d.ivancic@nasa.gov Tue Apr 3 06:26:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3578621F84B6 for ; Tue, 3 Apr 2012 06:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BUrGXTA-eQS for ; Tue, 3 Apr 2012 06:26:30 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 935DE21F846D for ; Tue, 3 Apr 2012 06:26:29 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id B168D182D8F; Tue, 3 Apr 2012 08:26:28 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q33DQSK4002283; Tue, 3 Apr 2012 08:26:28 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 3 Apr 2012 08:26:28 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Rick Taylor Date: Tue, 3 Apr 2012 08:26:27 -0500 Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RnV/uz6AQS2drQaaT383NhbzSkA== Message-ID: <61C319D1-E820-466F-87AD-8B2D1E6C48C3@nasa.gov> References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_61C319D1E820466F87AD8B2D1E6C48C3nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-03_04:2012-04-03, 2012-04-03, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:26:31 -0000 --_000_61C319D1E820466F87AD8B2D1E6C48C3nasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think a picture would help - multiple radios and multiple routers with mu= ltiple LAN and WAN where the WAN is the radio net. - Will On Apr 3, 2012, at 9:20 AM, Rick Taylor wrote: From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] What would you think about having an address-TLV for this interface IP? There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) and IPv= 6 Address Sub-TLV (10.6, page 15) These SHOULD be used when layer-3 addresses are known by the modem. (There = has been some talk of generalizing them into a Layer-3 Address Sub-TLV of a= sockets style [addr_family, addr_len, addr_octets] tuple, but I'm personal= ly not bothered either way). It would only be necessary if the IP is not equals to the mac generated IPv6 linklocal IP. Yes, one could calculate the IPv6 address from the neighbours MAC address a= nd the receiver's prefix if an IPv6 address is not provided. If this resolves the usecase for IP addresses in DLEP messages, we could use normal PacketBB addresses for all the MAC addresses. Which would us to allow address compression for them. And it would easily resolve the problem of "attaching" the addresses to each other... and we would not need multi-length addresses. Yes, yes, yes! This is what I have been trying to get across (badly!). Th= e Address-Block TLV's are all associated with layer-2 (MAC) addresses, with= optional sub-TLV's in the block carrying layer-3 addresses when known. Of course these Address-Block TLV's only apply to Neighbour* messages. Any= 'local' router<->modem messages (Peer*) should be Message TLV's as they do= not have an address context that has any real meaning. I hope that helps? Rick Taylor Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_61C319D1E820466F87AD8B2D1E6C48C3nasagov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think a picture would he= lp - multiple radios and multiple routers with multiple LAN and WAN where t= he WAN is the radio net.

- Will


On Apr 3, 2012, at 9:20 AM, Rick Taylor wrote:

From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=

What would you think about having an address-TLV for this interf= ace IP?

There are 2 already: IPv4 Address Sub-TLV (draf= t-02, 10.5, page 14) and IPv6 Address Sub-TLV (10.6, page 15)

These = SHOULD be used when layer-3 addresses are known by the modem. (There has be= en some talk of generalizing them into a Layer-3 Address Sub-TLV of a socke= ts style [addr_family, addr_len, addr_octets] tuple, but I'm personally not= bothered either way).

It would only be ne= cessary if the IP is not equals to the mac generated
IPv6 linklocal IP.

Yes, one could c= alculate the IPv6 address from the neighbours MAC address and the receiver'= s prefix if an IPv6 address is not provided.

If this resolves the usecase for IP addresses in DLEP messages, we could=
use normal PacketBB addresses fo= r all the MAC addresses. Which would us
to allow address compression for them.

And it would easily= resolve the problem of "attaching" the addresses to
each other... and we would not need multi-length addres= ses.

Yes, yes, yes!  This is what I have been tryi= ng to get across (badly!).  The Address-Block TLV's are all associated= with layer-2 (MAC) addresses, with optional sub-TLV's in the block carryin= g layer-3 addresses when known.

Of course these Address-Block TLV's = only apply to Neighbour* messages.  Any 'local' router<->modem m= essages (Peer*) should be Message TLV's as they do not have an address cont= ext that has any real meaning.

I hope that helps?

Rick Taylor=


Henning Rogge

=
--
Dipl= om-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
<= blockquote type=3D"cite">Kommunikation, Informationsverarbeitung und Ergono= mie FKIE
Kommunikationssysteme (K= OM)
Neuenahrer Stra=DFe 20, 53343= Wachtberg, Germany
Telefon +49 2= 28 9435-961,   Fax +49 228 9435 685
mailto:hen= ning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
_______________________________________________
manet mailing list
= manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne= tworking Lab 216-433-2620
Mobile = 440-503-4892
http://roland.grc.nasa.gov/~ivancic

= --_000_61C319D1E820466F87AD8B2D1E6C48C3nasagov_-- From henning.rogge@fkie.fraunhofer.de Tue Apr 3 06:28:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F0411E8093 for ; Tue, 3 Apr 2012 06:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7PURwpwPRmx for ; Tue, 3 Apr 2012 06:28:53 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id CE36711E8089 for ; Tue, 3 Apr 2012 06:28:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF3n2-00070U-2B; Tue, 03 Apr 2012 15:28:52 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF3n1-0006b7-Vm; Tue, 03 Apr 2012 15:28:51 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:28:51 +0200 Message-ID: <4F7AFB12.4070907@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 15:28:50 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Rick Taylor References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080509050705040008070208" X-OriginalArrivalTime: 03 Apr 2012 13:28:51.0770 (UTC) FILETIME=[B596A9A0:01CD119D] X-Virus-Scanned: yes (ClamAV 0.97.3/14736/Tue Apr 3 14:04:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9fba06858ea504e244212894029289c9 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:28:54 -0000 This is a cryptographically signed message in MIME format. --------------ms080509050705040008070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 03:20 PM, Rick Taylor wrote: >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> >> What would you think about having an address-TLV for this interface >> IP? > > There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) > and IPv6 Address Sub-TLV (10.6, page 15) Yes, but I think most of the discussion is about getting rid of the=20 concept of sub-TLVs and only use what PacketBB does provide. > These SHOULD be used when layer-3 addresses are known by the modem. > (There has been some talk of generalizing them into a Layer-3 Address > Sub-TLV of a sockets style [addr_family, addr_len, addr_octets] > tuple, but I'm personally not bothered either way). I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), one=20 for IPv4 and one for IPv6 would be okay. >> It would only be necessary if the IP is not equals to the mac >> generated IPv6 linklocal IP. > > Yes, one could calculate the IPv6 address from the neighbours MAC > address and the receiver's prefix if an IPv6 address is not > provided. And we could also do this calculation already in the DLEP client, so we=20 do not need a special TLV for it. >> If this resolves the usecase for IP addresses in DLEP messages, we >> could use normal PacketBB addresses for all the MAC addresses. >> Which would us to allow address compression for them. >> >> And it would easily resolve the problem of "attaching" the >> addresses to each other... and we would not need multi-length >> addresses. > > Yes, yes, yes! This is what I have been trying to get across > (badly!). The Address-Block TLV's are all associated with layer-2 > (MAC) addresses, with optional sub-TLV's in the block carrying > layer-3 addresses when known. I hope you are still considering switching to normal (DLEP specific)=20 TLVs... and using address TLVs for neighbor specific data (and not=20 sub-tlvs at all). > Of course these Address-Block TLV's only apply to Neighbour* > messages. Any 'local' router<->modem messages (Peer*) should be > Message TLV's as they do not have an address context that has any > real meaning. Of course. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080509050705040008070208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxMzI4NTBaMCMGCSqGSIb3DQEJBDEWBBS3qg8gJrVLB4FQrVu3IGOMVJp/1jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAw7koHcUOQ4+vZcNZRCXEnAksElrUv6sF1lP9GATWWmFlUvICciiC1uYCDE7k+ fcNPCw11+0lRMB0VnNaJKZmw3xXIqlXBxfslBNc8J246ego+3Bgt+zCz0swSBkEGh1JMWh02 GfOt/v1+TbK/OkiSjnhvi3U+gTjsvuvU3X+uQFUrtUE0EjBTbKhAsumgCECEus1xWLWDXBZ5 0ngNdbPozJyWqS6em6VUuySQuGyUoN+/9ZzPIbwqLOTeMmDsbYDYqzhD2Z+RVZeGg6AstW4X 9RPSuctCIfQ9hnQO2zajVH9mEdi9sbaZtTpC0kzhwrB2SUMX9yMvBd4Lzuli5aPZAAAAAAAA --------------ms080509050705040008070208-- From rick.taylor@cassidian.com Tue Apr 3 06:51:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588D621F84F1 for ; Tue, 3 Apr 2012 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b5sBkIjJUmq for ; Tue, 3 Apr 2012 06:51:39 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E88F21F84F0 for ; Tue, 3 Apr 2012 06:51:38 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 15:51:37 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 15:51:37 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:51:36 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:51:36 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 14:51:43 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 14:51:16 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RndmeKqFf3dx5T3uqqyP13714cAAAU+2w References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 13:51:43.0828 (UTC) FILETIME=[E7661940:01CD11A0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--36.876000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:51:40 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/03/2012 03:20 PM, Rick Taylor wrote: > >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > >> > >> What would you think about having an address-TLV for this interface > >> IP? > > > > There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) > > and IPv6 Address Sub-TLV (10.6, page 15) >=20 > Yes, but I think most of the discussion is about getting rid of the > concept of sub-TLVs and only use what PacketBB does provide. Do you mean: Do not use one message TLV-type for DLEP, with individual = TLV's in the payload, but use 'top-level' TLV types for each DLEP TLV? I can see the available numbers running out quickly, particularly with = vendor-specific metric TLVs. Can the (RFC5444, section 5.4.1, page 15) help here? Can = we use 1 top-level DLEP TLV-type and move the sub-TLV's to tlv-type-ext? I'm not a packetBB guru, but I can see both sides of the argument, but I = am worried about lack of space in the numbering. > > These SHOULD be used when layer-3 addresses are known by the modem. > > (There has been some talk of generalizing them into a Layer-3 = Address > > Sub-TLV of a sockets style [addr_family, addr_len, addr_octets] > > tuple, but I'm personally not bothered either way). >=20 > I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), = one > for IPv4 and one for IPv6 would be okay. I agree, but someone might start shouting about ATM, who knows? > >> It would only be necessary if the IP is not equals to the mac > >> generated IPv6 linklocal IP. > > > > Yes, one could calculate the IPv6 address from the neighbours MAC > > address and the receiver's prefix if an IPv6 address is not > > provided. >=20 > And we could also do this calculation already in the DLEP client, so = we > do not need a special TLV for it. Hmmm... not always true, what if one neighbour had a shorter IPv6 prefix = than the other. Not ideal I know, but possible. Remember in MANETs = configurations often end up wrong. >=20 > >> If this resolves the usecase for IP addresses in DLEP messages, we > >> could use normal PacketBB addresses for all the MAC addresses. > >> Which would us to allow address compression for them. > >> > >> And it would easily resolve the problem of "attaching" the > >> addresses to each other... and we would not need multi-length > >> addresses. > > > > Yes, yes, yes! This is what I have been trying to get across > > (badly!). The Address-Block TLV's are all associated with layer-2 > > (MAC) addresses, with optional sub-TLV's in the block carrying > > layer-3 addresses when known. >=20 > I hope you are still considering switching to normal (DLEP specific) > TLVs... and using address TLVs for neighbor specific data (and not > sub-tlvs at all). I'd like to hear Stan's opinion, as DLEP is his draft, not mine! >=20 > > Of course these Address-Block TLV's only apply to Neighbour* > > messages. Any 'local' router<->modem messages (Peer*) should be > > Message TLV's as they do not have an address context that has any > > real meaning. >=20 > Of course. >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From dsatterw@cisco.com Tue Apr 3 06:53:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BBC11E8091 for ; Tue, 3 Apr 2012 06:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cR8fVOQQG9d for ; Tue, 3 Apr 2012 06:53:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6882E11E8089 for ; Tue, 3 Apr 2012 06:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3451; q=dns/txt; s=iport; t=1333461197; x=1334670797; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=vF10bDUWTAyH7ibruYDSQ635LA1+K+DnGaUnLD6RAeY=; b=QXhQMq9tLVcZi3DnY+S/06rBVOCP5eRLchKhsV0IhOCMKcf+vJaI45sf mw8h9OFN6jtPlLAnj1nCYw8ef8g3IcWwAg61dE3FuKnJpj83SKm2kkEjU 4vqaVtWduLgqlGHgLzp4o//BU/aH3UMwO9m4w9IB28Z8tGQe8e5FQXNvC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcJAJgAe0+tJV2a/2dsb2JhbABFt28CgQeCCQEBAQMBEgEnAgE8BQ0BCBgVcAEBBAENBSKHYgWcC58WjTaDMASVY45HgWmDAw X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="68657636" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 03 Apr 2012 13:53:04 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q33Dr4I1001436; Tue, 3 Apr 2012 13:53:04 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 08:53:04 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 13:53:04 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 09:53:03 -0400 From: Darryl Satterwhite To: Henning Rogge , Rick Taylor Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RoRaW16Bjfzc3N0yCfYaEOkgB3Q== In-Reply-To: <4F7AF4DA.6040407@fkie.fraunhofer.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 13:53:04.0741 (UTC) FILETIME=[17A07150:01CD11A1] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:53:23 -0000 Rick and others, I would like to go back to the original discussion of reporting multi-hop topologies within the radio net with DLEP. It has always been the authors intent that DLEP would only be used to report events(Up/Down) and link metrics for neighbors that are one hop away. If the radio net happens to be a layer2 mesh network, that should be transparent to routers running DLEP. If the radios associated with this layer2 mesh choose to report, via DLEP, neighbors that are 2 or more hops away in their layer2 mesh then that should be transparent to the DLEP routers. The radio, with its knowledge of its own layer2 mesh topology, should craft the DLEP neighbor metrics to account for neighbors being multiple hops away. Also I saw where it was mentioned that it would be nice if DLEP could report link metrics in both directions. The original purpose for DLEP was reporting up/down and link metrics to provide routing protocols with addition information to make quicker and more informed decisions on how to reach one-hop neighbors on a radio net. With that said, I don't understand how a router would use an inbound traffic link metric. Help me understand the use case. Darryl Satterwhite Cisco Systems On 4/3/12 9:02 AM, "Henning Rogge" wrote: > On 04/03/2012 02:54 PM, Rick Taylor wrote: > >> It does not matter where the IP address is from, possibly DHCP, >> Autodiscovery, static assignment, etc..., but it is expected that >> the address will be valid within the context of the radio net. >> >> Of course, the neighbour IP address is an optional TLV, and we have >> some radios that do report it on NeighbourUp and some that don't. >> >> The exchange of addresses can be done between the routers, but it may >> not be needed, and it is more efficient to not do it. Currently on >> IPv4 networks I have to send specially crafted ICMP ping packets to >> populate both routers ARP tables, and this has to be done between >> each neighbour. (There may be a better way but InARP isn't >> well-supported!) > > Okay. > >>> If I understand you right you added a custom "layer-3 IP" field >>> into the layer-2 network announcement of your radio. In this case, >>> forwarding this layer-3 data makes sense. >> >> As before, when IP addresses are available at the layer-2 control >> plane, the "radio magic" layer as Stan describes it, then it makes >> sense to report this via DLEP > > Especially in the context of bandwidth restrained radios this makes sense. > >>> Does this mean that your layer-2 beacon/announcement contain ALL >>> IP addresses of your router? Or just one IP that allows you to >>> contact the router over the radio/modem? >> >> Only the IP addresses of the interface directly attached to the >> modem, i.e. the addresses accessible via the layer-2 network of the >> radios. > > What would you think about having an address-TLV for this interface IP? > It would only be necessary if the IP is not equals to the mac generated > IPv6 linklocal IP. > > If this resolves the usecase for IP addresses in DLEP messages, we could > use normal PacketBB addresses for all the MAC addresses. Which would us > to allow address compression for them. > > And it would easily resolve the problem of "attaching" the addresses to > each other... and we would not need multi-length addresses. > > Henning Rogge From henning.rogge@fkie.fraunhofer.de Tue Apr 3 07:02:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1656E11E8085 for ; Tue, 3 Apr 2012 07:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMHX84FMRPoy for ; Tue, 3 Apr 2012 07:02:34 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 17E7811E8079 for ; Tue, 3 Apr 2012 07:02:34 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF4Jc-0000DE-3p; Tue, 03 Apr 2012 16:02:32 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF4Jc-0007XW-19; Tue, 03 Apr 2012 16:02:32 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:02:31 +0200 Message-ID: <4F7B02F1.9080108@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 16:02:25 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Rick Taylor References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060905080501020107030901" X-OriginalArrivalTime: 03 Apr 2012 14:02:31.0814 (UTC) FILETIME=[69A0EA60:01CD11A2] X-Virus-Scanned: yes (ClamAV 0.97.3/14736/Tue Apr 3 14:04:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8875d4c9fcbcf3dc5ce5a7a09af9f425 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:02:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060905080501020107030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 03:51 PM, Rick Taylor wrote: >> Yes, but I think most of the discussion is about getting rid of >> the concept of sub-TLVs and only use what PacketBB does provide. > > Do you mean: Do not use one message TLV-type for DLEP, with > individual TLV's in the payload, but use 'top-level' TLV types for > each DLEP TLV? > > I can see the available numbers running out quickly, particularly > with vendor-specific metric TLVs. > > Can the (RFC5444, section 5.4.1, page 15) help here? > Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to > tlv-type-ext? You do not need to use the extension type for this. Each Message type defined for PacketBB can have up to 96 message-type=20 specific TLVs (the ids between 128 and 223 including all of their=20 extension types). Unless you say that 96 TLVs are not enough for DLEP,=20 we should be fine. See RFC 5444, Section 6.4. >> I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), >> one for IPv4 and one for IPv6 would be okay. > > I agree, but someone might start shouting about ATM, who knows? > >> And we could also do this calculation already in the DLEP client, >> so we do not need a special TLV for it. > > Hmmm... not always true, what if one neighbour had a shorter IPv6 > prefix than the other. Not ideal I know, but possible. Remember in > MANETs configurations often end up wrong. the point is that DLEP does not care about the efficient transport over the radio metric, it just can assume that the radio can decode it. DLEP is only local traffic (not over radio), so we do not need to look at compression that much. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060905080501020107030901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxNDAyMjlaMCMGCSqGSIb3DQEJBDEWBBRo0MBJBMtv6lOXvErSL+hpwv+7jjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCw86V4MnQRC7v16Rrsaz5avbf0iAbTcvS6NnNf54l0M0bXhXVVwAc39pnlzOrG VIldSm/5s96FMXeS5Fol8Vxb9jt/cMYSfYk4CVYHwH/drxO5yaO5MdiIVvouZ/8cRs7+Eyik S1gJnT1AhskZ2gBp0bnaa+KaQB/H5pbXMnHAeTzjzh/j5ZKPfiAjaYz/wjw4jQmqgkBhCNWa Oq4cQLlmRqja4RFPbtQfKuHxe4UYPxWt7T3z6GuluNuN2BhB/bRp1LJouDGQBRf/0+ef9AD5 zIPCV4GytAJe3XcHjPnpcHJyOKBxJ6uRKdYsaW+qRifags8kkfscexc8KwpxhXspAAAAAAAA --------------ms060905080501020107030901-- From henning.rogge@fkie.fraunhofer.de Tue Apr 3 07:09:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A507421F84F9 for ; Tue, 3 Apr 2012 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryBl740E47RU for ; Tue, 3 Apr 2012 07:09:30 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55F21F84F5 for ; Tue, 3 Apr 2012 07:09:29 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SF4QK-0000WP-Ui; Tue, 03 Apr 2012 16:09:28 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SF4QK-0007gY-S0; Tue, 03 Apr 2012 16:09:28 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:09:28 +0200 Message-ID: <4F7B0497.309@fkie.fraunhofer.de> Date: Tue, 03 Apr 2012 16:09:27 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Darryl Satterwhite References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020302030709040507020706" X-OriginalArrivalTime: 03 Apr 2012 14:09:28.0645 (UTC) FILETIME=[62144750:01CD11A3] X-Virus-Scanned: yes (ClamAV 0.97.3/14736/Tue Apr 3 14:04:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 209e4906e65bf60adc8fc3e5a3b0b088 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:09:30 -0000 This is a cryptographically signed message in MIME format. --------------ms020302030709040507020706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/03/2012 03:53 PM, Darryl Satterwhite wrote: > Rick and others, > > I would like to go back to the original discussion of reporting multi-h= op > topologies within the radio net with DLEP. I am not really happy with this usecase, but I agree that it exists and=20 we need a good solution for this. > It has always been the authors > intent that DLEP would only be used to report events(Up/Down) and link > metrics for neighbors that are one hop away. If the radio net happens t= o be > a layer2 mesh network, that should be transparent to routers running DL= EP. > If the radios associated with this layer2 mesh choose to report, via DL= EP, > neighbors that are 2 or more hops away in their layer2 mesh then that s= hould > be transparent to the DLEP routers. The radio, with its knowledge of it= s own > layer2 mesh topology, should craft the DLEP neighbor metrics to account= for > neighbors being multiple hops away. I do not like this solution because it would hide parts of what is going = on from the routing protocol. Even if we do it the way you describe,=20 DLEP would not be able to push out its full topology. What do you think about this? Instead of pushing out ALL the topology in a single DLEP message, we use = the Originator field of the message for defining a "reference point" for = the following neighbor data (no originator address means "this radio"). This means that the DLEP agent which has a full knowledge of the=20 topology of the mesh below creates one Neighbor-Message for every node=20 in the network, each containing the neighbors of this node and the known = metric data. I think this might solve the full mesh usecase. (I would still like to have the option to switch off the meshing=20 capability of the radio. Running a layer-3 mesh routing protocol over a=20 layer-2 mesh routing protocol is a recipe for a disaster.) > Also I saw where it was mentioned that it would be nice if DLEP could r= eport > link metrics in both directions. The original purpose for DLEP was repo= rting > up/down and link metrics to provide routing protocols with addition > information to make quicker and more informed decisions on how to reach= > one-hop neighbors on a radio net. With that said, I don't understand ho= w a > router would use an inbound traffic link metric. Help me understand the= use > case. Yes, having asymmetric values for the same metric is a common use case.=20 Maybe we could do this by using an extension type for "explicit reverse=20 metric value" for all link metric address-TLVs ? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020302030709040507020706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDMxNDA5MjdaMCMGCSqGSIb3DQEJBDEWBBSex5HZvCaGLzZgbW/X0ZJcgL/TnDBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQDBHQkcMwkxxhL1VWa/L9XD1Of+wbPEE8t9GoDYtq2lEgPZFg7Q4Mp50kGBR2YX Z3EP8xe4B+NgCQfa6TH5Zs6sqjb8KxyKuqEfqWMXf/Z/ZvDXd+GdVg1VPV4m3osirxFsYj5Z tmq4BnOAJpPHjRohN/omD5S0v9oDKOyO5NVEd7Ze0sFyn1soFve21lChvUm/GTv2TtpZg8lq s9aeuu2xWVuU1/C/fY6igjpbo8HkX7PhEifqCJs7voJwgpWHOkkpu6RyGsuDViPNMhBMJIMp RjTfTbrcFyanyiIW8IWU+S6VbV7w2BwYYZiUE7Z1RTZ9QPFXx63nPTUH5jkACoGeAAAAAAAA --------------ms020302030709040507020706-- From rick.taylor@cassidian.com Tue Apr 3 07:24:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBAE11E80AC for ; Tue, 3 Apr 2012 07:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkoNGghenUWc for ; Tue, 3 Apr 2012 07:24:03 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6811E80A6 for ; Tue, 3 Apr 2012 07:24:02 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 16:24:01 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 16:24:00 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:24:00 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:24:00 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 15:24:07 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 15:23:39 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RoqzyPh5ppHczSuCvJsrUFiM8pAAAfZUg References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 14:24:07.0550 (UTC) FILETIME=[6DF289E0:01CD11A5] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--17.795400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:24:04 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/03/2012 03:51 PM, Rick Taylor wrote: > >> Yes, but I think most of the discussion is about getting rid of > >> the concept of sub-TLVs and only use what PacketBB does provide. > > > > Do you mean: Do not use one message TLV-type for DLEP, with > > individual TLV's in the payload, but use 'top-level' TLV types for > > each DLEP TLV? > > > > I can see the available numbers running out quickly, particularly > > with vendor-specific metric TLVs. > > > > Can the (RFC5444, section 5.4.1, page 15) help here? > > Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to > > tlv-type-ext? >=20 > You do not need to use the extension type for this. >=20 > Each Message type defined for PacketBB can have up to 96 message-type > specific TLVs (the ids between 128 and 223 including all of their > extension types). Unless you say that 96 TLVs are not enough for DLEP, > we should be fine. >=20 > See RFC 5444, Section 6.4. Aah, I was demonstrating my lack of knowledge of packetBB. Having re-read section 6.4, I think 96 DLEP specific TLVs is plenty! Hopefully we have convinced the authors? >=20 > >> I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), > >> one for IPv4 and one for IPv6 would be okay. > > > > I agree, but someone might start shouting about ATM, who knows? > > > >> And we could also do this calculation already in the DLEP client, > >> so we do not need a special TLV for it. > > > > Hmmm... not always true, what if one neighbour had a shorter IPv6 > > prefix than the other. Not ideal I know, but possible. Remember in > > MANETs configurations often end up wrong. >=20 > the point is that DLEP does not care about the efficient transport over > the radio metric, it just can assume that the radio can decode it. DLEP > is only local traffic (not over radio), so we do not need to look at > compression that much. Agreed I still need to propose grouping the metric TLV ids to carry extra semantic information, much like SCTP chunk type id assignments carry extra information about the handling of the chunk. But I'll start a new thread for that. Rick Taylor From dsatterw@cisco.com Tue Apr 3 07:42:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4040B21F86E3 for ; Tue, 3 Apr 2012 07:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.232 X-Spam-Level: X-Spam-Status: No, score=-8.232 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Ut0fbYH0Ny for ; Tue, 3 Apr 2012 07:42:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5621921F86DF for ; Tue, 3 Apr 2012 07:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=3295; q=dns/txt; s=iport; t=1333464166; x=1334673766; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=GieMpYY2yLW/iqnZa8cBw3CCCLTvKSRB8jlGl3ymkF8=; b=XhFVmNOQvEJjMezkhPlILfqp8tgQF0Ne+Oxg1p5zHDOzESJlaLHVlUBI BlkRF8OvC6NZ/7jGaBo/6+KOYlA/XzTX9fNWMd5r93FOcUmG/f/wox6my EqZEPHSpWLpdEhcGpdHrCBsmFhdA7MHpUqczxXNJ6RRd8XrDlWv6LNVMN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcJAO0Le0+tJV2Z/2dsb2JhbABFt3ACgQeCCQEBAQMBEgEnAgE8BQ0BCBgVcAEBBA4FGweHYgWbfJ8NjTaDMASVY45HgWmDAw X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71662502" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 03 Apr 2012 14:42:46 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33EgjjH011603; Tue, 3 Apr 2012 14:42:45 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 09:42:45 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 14:42:45 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 10:42:44 -0400 From: Darryl Satterwhite To: Henning Rogge Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RqAdnLMTO2nxTj0C7DW8Li2YIkw== In-Reply-To: <4F7B0497.309@fkie.fraunhofer.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 14:42:45.0691 (UTC) FILETIME=[086950B0:01CD11A8] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:42:47 -0000 On 4/3/12 10:09 AM, "Henning Rogge" wrote: > On 04/03/2012 03:53 PM, Darryl Satterwhite wrote: >> Rick and others, >> >> I would like to go back to the original discussion of reporting multi-hop >> topologies within the radio net with DLEP. > > I am not really happy with this usecase, but I agree that it exists and > we need a good solution for this. > >> It has always been the authors >> intent that DLEP would only be used to report events(Up/Down) and link >> metrics for neighbors that are one hop away. If the radio net happens to be >> a layer2 mesh network, that should be transparent to routers running DLEP. >> If the radios associated with this layer2 mesh choose to report, via DLEP, >> neighbors that are 2 or more hops away in their layer2 mesh then that should >> be transparent to the DLEP routers. The radio, with its knowledge of its own >> layer2 mesh topology, should craft the DLEP neighbor metrics to account for >> neighbors being multiple hops away. > > I do not like this solution because it would hide parts of what is going > on from the routing protocol. Even if we do it the way you describe, > DLEP would not be able to push out its full topology. > > What do you think about this? > > Instead of pushing out ALL the topology in a single DLEP message, we use > the Originator field of the message for defining a "reference point" for > the following neighbor data (no originator address means "this radio"). > > This means that the DLEP agent which has a full knowledge of the > topology of the mesh below creates one Neighbor-Message for every node > in the network, each containing the neighbors of this node and the known > metric data. > > I think this might solve the full mesh usecase. > > (I would still like to have the option to switch off the meshing > capability of the radio. Running a layer-3 mesh routing protocol over a > layer-2 mesh routing protocol is a recipe for a disaster.) > I feel that any bleeding of the layer 2 radio topology into the router's layer 3 routing domain is recipe for disaster. The radio network should be transparent to DLEP routers. The DLEP routers should only be aware of neighbors that can be reached over this radio network and the metrics for those neighbors which is used to calculate a route cost to reach those neighbors. >> Also I saw where it was mentioned that it would be nice if DLEP could report >> link metrics in both directions. The original purpose for DLEP was reporting >> up/down and link metrics to provide routing protocols with addition >> information to make quicker and more informed decisions on how to reach >> one-hop neighbors on a radio net. With that said, I don't understand how a >> router would use an inbound traffic link metric. Help me understand the use >> case. > > Yes, having asymmetric values for the same metric is a common use case. > Maybe we could do this by using an extension type for "explicit reverse > metric value" for all link metric address-TLVs ? I understand that there could be asymmetric links but I question how a router would use this information. How would a router use a metric for traffic ingress'ing its interface? > > Henning Rogge From hrogge@googlemail.com Tue Apr 3 08:01:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A66411E80B5 for ; Tue, 3 Apr 2012 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClPDUVoqZ0dE for ; Tue, 3 Apr 2012 08:01:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 489D211E809D for ; Tue, 3 Apr 2012 08:01:07 -0700 (PDT) Received: by lagj5 with SMTP id j5so5468405lag.31 for ; Tue, 03 Apr 2012 08:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KpMRkalJCyekp6N1BsKW71KwRIlmazsWdmn0Wl7JMkc=; b=dBVMZ1mHkRcdqR+txrxli+A+ntFOGE+6NVoVJIlQsIiski2No4CEW3AXdMdp7iT7R+ CT1fpA7CyUfh8cxa7hymIGzWv1yOcTAdtJmUWkqia7LEssIwECB/uwgTryK4+/XHg6Mc Y1DJBWE6afCYZuoyZ4VMFoM/jRmIBK5CVVnepH4Z1hAv5JsGuzEvZjan7xiEJXjH6BEL yTUrSkI+GcXhpC0oYtJ3DzOMpuBV06gpEhD2nNsTRQCkUI7XWRjW2JxI6jz0Zc2M2tR1 weL471/I6Im03eqd/qsnSeVkvlna+VoPX+aWU2uGx1t9Ia7Io6xXHncVR2hCMPdna8Qi 3fPQ== Received: by 10.152.123.229 with SMTP id md5mr14387132lab.34.1333465266037; Tue, 03 Apr 2012 08:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:00:44 -0700 (PDT) In-Reply-To: References: <4F7B0497.309@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 3 Apr 2012 17:00:44 +0200 Message-ID: To: Darryl Satterwhite Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:01:08 -0000 On Tue, Apr 3, 2012 at 16:42, Darryl Satterwhite wrote: >> I think this might solve the full mesh usecase. >> >> (I would still like to have the option to switch off the meshing >> capability of the radio. Running a layer-3 mesh routing protocol over a >> layer-2 mesh routing protocol is a recipe for a disaster.) >> > I feel that any bleeding of the layer 2 radio topology into the router's > layer 3 routing domain is recipe for disaster. The radio network should be > transparent to DLEP routers. The DLEP routers should only be aware of > neighbors that can be reached over this radio network and the metrics for > those neighbors which is used to calculate a route cost to reach those > neighbors. I agree with you if the layer-2 mesh is just a "border network" with a single connection to the layer-3 mesh, but not in the general case. The layer-2 mesh design cannot know what kind of policies and restrictions are being used on the layer-3 mesh. There might be information that should only travel over a subset of the nodes. A special way to combine the routing metrics of multiple hops into a single one. Or something different. The point is that there is no real advantage of hiding the details of the layer-2 mesh, except for restricting the ways the layer-3 mesh works. The accumulated data can be calculated from the full topology, not the other way around. With access to the layer-2 mesh data, the layer-3 might consider skipping the problem of layering two mesh protocols on top of each other and just use the layer-2 mesh as an incredible fast layer-2 neighbor/2-hop-neighbor detection. Or it might just offload all the work on the layer-2 and only consider accumulated total costs for transit links. But at least all this choices are available. > I understand that there could be asymmetric links but I question how a > router would use this information. How would a router use a metric for > traffic ingress'ing its interface? OLSRv2 use directional link metrics, so hiding one of them from it would just make it necessary to relay the directional metric values to the other side with HELLOs. An example for really using both links might be a quality of service policy that demands that the traffic only flows over very symmetric links. Again, I don't see a reason for hiding this information if it is available on layer-2. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From rick.taylor@cassidian.com Tue Apr 3 08:05:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8245D21F853A for ; Tue, 3 Apr 2012 08:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ10P+90q5BW for ; Tue, 3 Apr 2012 08:04:59 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F121F850D for ; Tue, 3 Apr 2012 08:04:46 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 03 Apr 2012 17:04:44 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 17:04:43 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:04:43 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:04:43 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:04:50 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 16:04:22 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB49B@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Ro4B5+nzU+d/HS5eUO5gO+TiX3QABCnZQ References: From: "Rick Taylor" To: "Henning Rogge" , "Darryl Satterwhite" X-OriginalArrivalTime: 03 Apr 2012 15:04:50.0503 (UTC) FILETIME=[1E0F9570:01CD11AB] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--31.820000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:05:00 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/03/2012 03:53 PM, Darryl Satterwhite wrote: > > Rick and others, > > > > I would like to go back to the original discussion of reporting multi- > hop > > topologies within the radio net with DLEP. >=20 > I am not really happy with this usecase, but I agree that it exists and > we need a good solution for this. It does exist and the radio vendors are moving towards increasing smart meshing radios. All we can hope to do is add sufficient information to DLEP to allow us to access the topology information. > > It has always been the authors > > intent that DLEP would only be used to report events(Up/Down) and link > > metrics for neighbors that are one hop away. If the radio net happens to > be > > a layer2 mesh network, that should be transparent to routers running > DLEP. > > If the radios associated with this layer2 mesh choose to report, via > DLEP, > > neighbors that are 2 or more hops away in their layer2 mesh then that > should > > be transparent to the DLEP routers. The radio, with its knowledge of its > own > > layer2 mesh topology, should craft the DLEP neighbor metrics to account > for > > neighbors being multiple hops away. >=20 > I do not like this solution because it would hide parts of what is going > on from the routing protocol. Even if we do it the way you describe, > DLEP would not be able to push out its full topology. >=20 > What do you think about this? I agree with Henning on this. Hiding topology information will only cause problems, and leave routing users of DLEP constantly wondering if the metrics they receive are true. > Instead of pushing out ALL the topology in a single DLEP message, we use > the Originator field of the message for defining a "reference point" for > the following neighbor data (no originator address means "this radio"). =20 This seems to be a clever alternative to my proposed Via TLV or a hop-count. Of course, it does increase the calculation cost on the receiving router, but the chances are that the router is already trying to map the relationships between neighbours. > This means that the DLEP agent which has a full knowledge of the > topology of the mesh below creates one Neighbor-Message for every node > in the network, each containing the neighbors of this node and the known > metric data. >=20 > I think this might solve the full mesh usecase. I think it might, but I'll have to think on it. > (I would still like to have the option to switch off the meshing > capability of the radio. Running a layer-3 mesh routing protocol over a > layer-2 mesh routing protocol is a recipe for a disaster.) I don't think radio vendors will like having this option available. Anyway, I imagine this should be a radio configuration action, not part of DLEP. I agree on your point about a disaster, but if we can get some indication of the topology then we can attempt to mitigate it. > > Also I saw where it was mentioned that it would be nice if DLEP could > report > > link metrics in both directions. The original purpose for DLEP was > reporting > > up/down and link metrics to provide routing protocols with addition > > information to make quicker and more informed decisions on how to reach > > one-hop neighbors on a radio net. With that said, I don't understand how > a > > router would use an inbound traffic link metric. Help me understand the > use > > case. >=20 > Yes, having asymmetric values for the same metric is a common use case. > Maybe we could do this by using an extension type for "explicit reverse > metric value" for all link metric address-TLVs ? Asymmetric links are a problem, but I think the simplest way to approach them might be for each neighbour to report its relevant metric for inbound only - I mean the metric value the neighbour can receive, i.e. how much data can flow out of the receiving router, "receiver-egress". I have described this poorly, I'm happy to try my hand at ASCII art if it will help. On an asymmetric link, each neighbour should receive a different value (and any routing protocol that cares can exchange such information in the routing protocol). The neighbour ingress metric is the critical metric for routing (as Darryl pointed out) but I think it is worth explicitly stating it in the DLEP protocol to dissuade radio vendors from averaging asymmetric link metrics. Darryl, a possible use of inbound metrics might be a DLEP server/router that just reports/displays the topology of the radio net rather than routing, basically a diagnostic tool. Focusing DLEP purely on enabling layer-3 routing alone I think reduces its usefulness in currently unforeseen applications. That said, I'm not sure, now, that we need to report inbound metrics. Rick Taylor From sratliff@cisco.com Tue Apr 3 08:06:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8A11E80C7 for ; Tue, 3 Apr 2012 08:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rclCgYst1zuZ for ; Tue, 3 Apr 2012 08:06:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA6611E80BE for ; Tue, 3 Apr 2012 08:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3011; q=dns/txt; s=iport; t=1333465574; x=1334675174; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=wBfceomoLNmU+BzfRTLTZTvzM1LnO9KKG6cUlVHiyrI=; b=Jcb7+2Wt0hHOr2LqxMW8VrVDz5i4Omaojk36Ni3LAMyE1TpTYM1hQFsA yyPsIAA9J5OX38y5YUziI7UHE5JoxojZcIOhRJ+s67TY31Vx2ubXQi8UG Mx5uuEUqZYgGyX30uUg29O0dsKDg4P44Vncn6qdNjIB0hivUXTzYDX/Bu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMEQe0+tJXHA/2dsb2JhbABFt3OBB4IJAQEBAwEBAQEPASUCNAsQCxUDJwcnHxEGEyKHYgULm22fAwSQA2MElWOOR4FpgwM X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71720718" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2012 15:06:12 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q33F6BvF009861; Tue, 3 Apr 2012 15:06:11 GMT Message-Id: <01173FD3-4E44-49A5-85B3-0E1103987962@cisco.com> From: Stan Ratliff To: "Rick Taylor" In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 11:06:12 -0400 References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:06:15 -0000 On Apr 3, 2012, at 10:23 AM, Rick Taylor wrote: >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> >> On 04/03/2012 03:51 PM, Rick Taylor wrote: >>>> Yes, but I think most of the discussion is about getting rid of >>>> the concept of sub-TLVs and only use what PacketBB does provide. >>> >>> Do you mean: Do not use one message TLV-type for DLEP, with >>> individual TLV's in the payload, but use 'top-level' TLV types for >>> each DLEP TLV? >>> >>> I can see the available numbers running out quickly, particularly >>> with vendor-specific metric TLVs. >>> >>> Can the (RFC5444, section 5.4.1, page 15) help here? >>> Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to >>> tlv-type-ext? >> >> You do not need to use the extension type for this. >> >> Each Message type defined for PacketBB can have up to 96 message-type >> specific TLVs (the ids between 128 and 223 including all of their >> extension types). Unless you say that 96 TLVs are not enough for >> DLEP, >> we should be fine. >> >> See RFC 5444, Section 6.4. > > Aah, I was demonstrating my lack of knowledge of packetBB. Having > re-read section 6.4, I think 96 DLEP specific TLVs is plenty! > > Hopefully we have convinced the authors? > Not sure you've convinced the authors... ;-) This is why I said in Paris that at least part of this is semantics - what we're currently calling "sub-TLV's" can easily be re-named to "message-type specific TLV's".... and if that simple name change (notice there's no other packet format changes) makes everyone happy, then I'm good to go.... If we're talking about shuffling the packet formats around, and I never have been clear on that, then I've still got a problem. Regards, Stan >> >>>> I think using two DLEP-specific Address-TLVs (instead of > sub-tlvs), >>>> one for IPv4 and one for IPv6 would be okay. >>> >>> I agree, but someone might start shouting about ATM, who knows? >>> >>>> And we could also do this calculation already in the DLEP client, >>>> so we do not need a special TLV for it. >>> >>> Hmmm... not always true, what if one neighbour had a shorter IPv6 >>> prefix than the other. Not ideal I know, but possible. Remember > in >>> MANETs configurations often end up wrong. >> >> the point is that DLEP does not care about the efficient transport > over >> the radio metric, it just can assume that the radio can decode it. > DLEP >> is only local traffic (not over radio), so we do not need to look at >> compression that much. > > Agreed > > I still need to propose grouping the metric TLV ids to carry extra > semantic information, much like SCTP chunk type id assignments carry > extra information about the handling of the chunk. But I'll start a > new > thread for that. > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Tue Apr 3 08:22:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4D11E80B8 for ; Tue, 3 Apr 2012 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuEg6NkbXwaa for ; Tue, 3 Apr 2012 08:22:41 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B45D11E8093 for ; Tue, 3 Apr 2012 08:22:38 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 03 Apr 2012 17:22:37 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 3 Apr 2012 17:22:35 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:22:35 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:22:35 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:22:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 16:22:13 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rq4oUOF2dQa34QWCtmXiAl/kuvQAAC9cA References: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 15:22:42.0343 (UTC) FILETIME=[9CED6370:01CD11AD] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18814.006 X-TM-AS-Result: No--38.017000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:22:43 -0000 > From: Stan Ratliff [mailto:sratliff@cisco.com] >=20 > On Apr 3, 2012, at 10:23 AM, Rick Taylor wrote: >=20 > >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > >> > >> On 04/03/2012 03:51 PM, Rick Taylor wrote: > >>>> Yes, but I think most of the discussion is about getting rid of > >>>> the concept of sub-TLVs and only use what PacketBB does provide. > >>> > >>> Do you mean: Do not use one message TLV-type for DLEP, with > >>> individual TLV's in the payload, but use 'top-level' TLV types for > >>> each DLEP TLV? > >>> > >>> I can see the available numbers running out quickly, particularly > >>> with vendor-specific metric TLVs. > >>> > >>> Can the (RFC5444, section 5.4.1, page 15) help here? > >>> Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to > >>> tlv-type-ext? > >> > >> You do not need to use the extension type for this. > >> > >> Each Message type defined for PacketBB can have up to 96 message-type > >> specific TLVs (the ids between 128 and 223 including all of their > >> extension types). Unless you say that 96 TLVs are not enough for > >> DLEP, > >> we should be fine. > >> > >> See RFC 5444, Section 6.4. > > > > Aah, I was demonstrating my lack of knowledge of packetBB. Having > > re-read section 6.4, I think 96 DLEP specific TLVs is plenty! > > > > Hopefully we have convinced the authors? > > >=20 > Not sure you've convinced the authors... ;-) "Bother!" said Pooh. > > This is why I said in Paris that at least part of this is semantics - > what we're currently calling "sub-TLV's" can easily be re-named to > "message-type specific TLV's".... and if that simple name change > (notice there's no other packet format changes) makes everyone happy, > then I'm good to go.... If we're talking about shuffling the packet > formats around, and I never have been clear on that, then I've still > got a problem. I think there are 2 issues here concerning packetBB and DLEP. 1) Sub-TLVs 2) Address blocks As I understand it, the change request for 1, is to move the sub-TLV ids into the message-private TLV space, a minimal change. The change request for 2 is more of a "Keeping in the spirit of packetBB" request. The proposal is to move the Neighbour* messages from the Message-TLV block to the per-message Address Block TLVs, indexed by the layer-2 (MAC) address of the neighbour. This is a compatible change with 1, but requires more document changes. The question really is, does change 2 reduce the message size noticeably, or is the proposal just about making the packets look nicer? packetBB gurus, please enlighten me? Rick Taylor From sratliff@cisco.com Tue Apr 3 08:24:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD811E80D0 for ; Tue, 3 Apr 2012 08:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfB1MvC3K1Op for ; Tue, 3 Apr 2012 08:24:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4F11E80DF for ; Tue, 3 Apr 2012 08:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2509; q=dns/txt; s=iport; t=1333466699; x=1334676299; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=jW3Idvo9iBC/eRecNHIIf6Nw7H0aF3R8jTiO5WpbKw8=; b=PF3QIUihOLSzkAsjCUywLLPHYNJx0fkw36klEzTfire18dVSHVBFzaOF FyJEn0lMeY7M0tuO8W9er03+c5Au+Gj26pWnEYZrQ7X87ZpzUH8LD6uVx +soeSbV1N6zxWFFFHg+gCNiepcFxBrz8k9mXxDQbNtjnZjCF463HORBk2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHYVe0+tJV2Z/2dsb2JhbABDuAuBB4IJAQEBAwEBAQEPASU2CwULCxgnBycfEQYTIodiBQufdZcjkANjBJVjjkeBaYMD X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71709932" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2012 15:24:58 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33FOwKT009855; Tue, 3 Apr 2012 15:24:58 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: <4F7AEBCE.6070405@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 11:24:59 -0400 References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <4F7AEA06.4080609@fkie.fraunhofer.de> <4F7AEBCE.6070405@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:25:00 -0000 I'll attempt to explain the use case for radio knowledge of IP =20 addresses: =46rom a Layer 3 perspective, metrics are *useless* unless they are in =20= the context of a next-hop (or destination) address - for example it's =20= all well and good to say "I've got 54Mbps of bandwidth on that 802.11g =20= device hanging off of interface FastEthernet0/1", but if the router =20 doesn't know what traffic might be sent out said interface, what good =20= does it do you? Yes, I know - the standard response to that is "well, =20= we can ARP, or use IPv6 ND to figure out the Layer 3 addresses". =20 Problem is, that takes time. Time some of these networks don't have. Some of my deployments (not all, but some) are in the military space. =20= Putting routers and radios on military vehicles is interesting. =20 Putting routers and radios on military airplanes is even MORE =20 interesting. Sometimes, you don't have 60 seconds for the link to =20 stabilize, and discovery protocols to run, and routing protocols to =20 converge - you have a relatively short amount of time to recognize the =20= asset overhead, determine metrics to it (and possibly through it), and =20= push data while you can. So having nice, neat, interesting things like =20= a Layer 2 MAC address, AND all of the associated Layer 3 addresses =20 right up front (like in a Neighbor Up message) helps that out a bunch. Regards, Stan On Apr 3, 2012, at 8:23 AM, Henning Rogge wrote: > On 04/03/2012 02:16 PM, Henning Rogge wrote: >> If this is right, I still would like to see a use-case where the =20 >> radio >> knows about IP addresses and has to tell them the router. > > Just to clarify this... I really do NOT want to remove anything from =20= > DLEP that is useful. But at the moment I lack the knowledge about =20 > the common usecase for IP-addresses in DLEP. Maybe someone can =20 > explain his usecase. > > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Apr 3 08:28:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28E821F865C for ; Tue, 3 Apr 2012 08:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+N7hFpfHVfb for ; Tue, 3 Apr 2012 08:28:14 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3874321F8595 for ; Tue, 3 Apr 2012 08:28:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="199102264" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 16:28:13 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33FSCgb027172; Tue, 3 Apr 2012 16:28:12 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:28:12 +0100 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 Date: Tue, 3 Apr 2012 16:28:11 +0100 Message-ID: In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RndmeKqFf3dx5T3uqqyP13714cAAAU+2wAAOj0LA= References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Rick Taylor" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 15:28:12.0517 (UTC) FILETIME=[61B9F150:01CD11AE] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:28:15 -0000 There are in effect 65536 different TLVs. OK, some are experimental, and so= me fall in a category I'll get to in a minute. But fundamentally the only t= hing special about the 256 with type extension zero is that they save an oc= tet when sent. That said, it makes sense not to treat them completely independently. And u= sing one type for metric, with up to 256 different variants, is exactly wha= t does make sense. Take a look at OLSRv2 for that approach. And the case I mentioned above? A range of message type specific TLV types.= If all else fails, or because that's your preference, use some of those. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= ick Taylor Sent: 03 April 2012 14:51 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/03/2012 03:20 PM, Rick Taylor wrote: > >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > >> > >> What would you think about having an address-TLV for this interface > >> IP? > > > > There are 2 already: IPv4 Address Sub-TLV (draft-02, 10.5, page 14) > > and IPv6 Address Sub-TLV (10.6, page 15) >=20 > Yes, but I think most of the discussion is about getting rid of the > concept of sub-TLVs and only use what PacketBB does provide. Do you mean: Do not use one message TLV-type for DLEP, with individual TLV'= s in the payload, but use 'top-level' TLV types for each DLEP TLV? I can see the available numbers running out quickly, particularly with vend= or-specific metric TLVs. Can the (RFC5444, section 5.4.1, page 15) help here? Can we= use 1 top-level DLEP TLV-type and move the sub-TLV's to tlv-type-ext? I'm not a packetBB guru, but I can see both sides of the argument, but I am= worried about lack of space in the numbering. > > These SHOULD be used when layer-3 addresses are known by the modem. > > (There has been some talk of generalizing them into a Layer-3 Address > > Sub-TLV of a sockets style [addr_family, addr_len, addr_octets] > > tuple, but I'm personally not bothered either way). >=20 > I think using two DLEP-specific Address-TLVs (instead of sub-tlvs), one > for IPv4 and one for IPv6 would be okay. I agree, but someone might start shouting about ATM, who knows? > >> It would only be necessary if the IP is not equals to the mac > >> generated IPv6 linklocal IP. > > > > Yes, one could calculate the IPv6 address from the neighbours MAC > > address and the receiver's prefix if an IPv6 address is not > > provided. >=20 > And we could also do this calculation already in the DLEP client, so we > do not need a special TLV for it. Hmmm... not always true, what if one neighbour had a shorter IPv6 prefix th= an the other. Not ideal I know, but possible. Remember in MANETs configur= ations often end up wrong. >=20 > >> If this resolves the usecase for IP addresses in DLEP messages, we > >> could use normal PacketBB addresses for all the MAC addresses. > >> Which would us to allow address compression for them. > >> > >> And it would easily resolve the problem of "attaching" the > >> addresses to each other... and we would not need multi-length > >> addresses. > > > > Yes, yes, yes! This is what I have been trying to get across > > (badly!). The Address-Block TLV's are all associated with layer-2 > > (MAC) addresses, with optional sub-TLV's in the block carrying > > layer-3 addresses when known. >=20 > I hope you are still considering switching to normal (DLEP specific) > TLVs... and using address TLVs for neighbor specific data (and not > sub-tlvs at all). I'd like to hear Stan's opinion, as DLEP is his draft, not mine! >=20 > > Of course these Address-Block TLV's only apply to Neighbour* > > messages. Any 'local' router<->modem messages (Peer*) should be > > Message TLV's as they do not have an address context that has any > > real meaning. >=20 > Of course. >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Tue Apr 3 08:30:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572AA11E80E9 for ; Tue, 3 Apr 2012 08:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSCPxuyZJv9H for ; Tue, 3 Apr 2012 08:30:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E611E80EA for ; Tue, 3 Apr 2012 08:30:47 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1212631eaa.31 for ; Tue, 03 Apr 2012 08:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=nKXIVxL7MSbFpBVRirWnsF0DyBP0GHehGXvEqxlMC+0=; b=ot49ZdGuDyHO9sj2Nls6rg9n4R7AeYAgvty2FRJ3teD+lXLwk456OoSGXYQjdz/NlR r5sQMEW9iIQ+stBLK2OfpiDsEYjy+s4DALw5KMopijhhd1ufhnHSvApxDRRkQqmKruml nmWLbMNlXkVHovD4H8TSaQsTu60VbRwg1+vWYBw+Nv77ZHJ/i1bmZ5uFfElSOQdxlJzi 4J1zUU4bznpi0sHAF4YlqClnO5cwC0bdHz3iXputGTKmEQ241nPaSzKQd2GfD6OCz6/p HwiJribFoSHxCqulrqdMJiIL+iyMHN13sYHX64agU50Uvu1PYfiF06ijEx25jdQEB2bI pOXw== Received: by 10.152.135.104 with SMTP id pr8mr14524045lab.27.1333467046478; Tue, 03 Apr 2012 08:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:30:25 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB49B@SUKNPT8106.cogent-dsn.local> References: <7B31B0093014224A843C10C0CCE92AC1035AB49B@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Tue, 3 Apr 2012 17:30:25 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:30:48 -0000 Maybe we can do both without extending the data format of DLEP too much. If a radio layer-2 mesh wants to hide its internal structure (or is configured to do so), it just produce a single "Neighbor update" message for itself with all to targets in the whole mesh and accumulated metric values attached to the neighbor MACs. An optional hopcount TLV at each neighbor gives the layer-3 routing protocol some idea about being on a mesh, but even that is optional. If a radio layer-2 mesh can provide the full topology, it will send out multiple "Neighbor update" messages to push the link state of all nodes in the mesh, all of them (except the one for its own neighbors) using the originator address to tell the router which neighbors linkstate they are sending. Both systems use the same semantic, the first one would just look like a pure "one hop" network (if you don't care for the hopcount TLV). This would make this "full topology dump" a feature, so the manufacturer of the device can decide what is supported. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Tue Apr 3 08:31:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428E111E80E2 for ; Tue, 3 Apr 2012 08:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTiOsEgAal2C for ; Tue, 3 Apr 2012 08:31:08 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9074C11E80F3 for ; Tue, 3 Apr 2012 08:31:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="199103167" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 16:31:06 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33FV5UV029103; Tue, 3 Apr 2012 16:31:05 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:31: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 16:31:04 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RoRaW16Bjfzc3N0yCfYaEOkgB3QADUx8Q References: <4F7AF4DA.6040407@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Darryl Satterwhite" , "Henning Rogge" , "Rick Taylor" X-OriginalArrivalTime: 03 Apr 2012 15:31:05.0000 (UTC) FILETIME=[C888C280:01CD11AE] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:31:09 -0000 See OLSRv2 (and the discussion in draft-dearlove-metrics, currently expired= , for why) for use of inbound metrics. In short, although the ultimate rout= e uses outbound metrics, inbound metrics are used for MPR selection, becaus= e links (other than the first) in routes go from MPR to MPR selector. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= arryl Satterwhite Sent: 03 April 2012 14:53 To: Henning Rogge; Rick Taylor Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Rick and others, I would like to go back to the original discussion of reporting multi-hop topologies within the radio net with DLEP. It has always been the authors intent that DLEP would only be used to report events(Up/Down) and link metrics for neighbors that are one hop away. If the radio net happens to be a layer2 mesh network, that should be transparent to routers running DLEP. If the radios associated with this layer2 mesh choose to report, via DLEP, neighbors that are 2 or more hops away in their layer2 mesh then that shoul= d be transparent to the DLEP routers. The radio, with its knowledge of its ow= n layer2 mesh topology, should craft the DLEP neighbor metrics to account for neighbors being multiple hops away. Also I saw where it was mentioned that it would be nice if DLEP could repor= t link metrics in both directions. The original purpose for DLEP was reportin= g up/down and link metrics to provide routing protocols with addition information to make quicker and more informed decisions on how to reach one-hop neighbors on a radio net. With that said, I don't understand how a router would use an inbound traffic link metric. Help me understand the use case. Darryl Satterwhite Cisco Systems On 4/3/12 9:02 AM, "Henning Rogge" wrote= : > On 04/03/2012 02:54 PM, Rick Taylor wrote: >=20 >> It does not matter where the IP address is from, possibly DHCP, >> Autodiscovery, static assignment, etc..., but it is expected that >> the address will be valid within the context of the radio net. >>=20 >> Of course, the neighbour IP address is an optional TLV, and we have >> some radios that do report it on NeighbourUp and some that don't. >>=20 >> The exchange of addresses can be done between the routers, but it may >> not be needed, and it is more efficient to not do it. Currently on >> IPv4 networks I have to send specially crafted ICMP ping packets to >> populate both routers ARP tables, and this has to be done between >> each neighbour. (There may be a better way but InARP isn't >> well-supported!) >=20 > Okay. >=20 >>> If I understand you right you added a custom "layer-3 IP" field >>> into the layer-2 network announcement of your radio. In this case, >>> forwarding this layer-3 data makes sense. >>=20 >> As before, when IP addresses are available at the layer-2 control >> plane, the "radio magic" layer as Stan describes it, then it makes >> sense to report this via DLEP >=20 > Especially in the context of bandwidth restrained radios this makes sense= . >=20 >>> Does this mean that your layer-2 beacon/announcement contain ALL >>> IP addresses of your router? Or just one IP that allows you to >>> contact the router over the radio/modem? >>=20 >> Only the IP addresses of the interface directly attached to the >> modem, i.e. the addresses accessible via the layer-2 network of the >> radios. >=20 > What would you think about having an address-TLV for this interface IP? > It would only be necessary if the IP is not equals to the mac generated > IPv6 linklocal IP. >=20 > If this resolves the usecase for IP addresses in DLEP messages, we could > use normal PacketBB addresses for all the MAC addresses. Which would us > to allow address compression for them. >=20 > And it would easily resolve the problem of "attaching" the addresses to > each other... and we would not need multi-length addresses. >=20 > Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Tue Apr 3 08:33:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903C411E80F4 for ; Tue, 3 Apr 2012 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC6W68s5zW7Y for ; Tue, 3 Apr 2012 08:32:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3A11E80E6 for ; Tue, 3 Apr 2012 08:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4238; q=dns/txt; s=iport; t=1333467170; x=1334676770; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=e/loluf4NoQanTz/FncgYqPGRo6V2M00ggsDijuYd4Y=; b=k0Szqci6OTqh5X+wtJqDWzbzZfQOH1Ren82bneNajhYs5f57kBMgkOit kpkXDLk75Gu/pfNN8UJ+Y7Dsgk4XjUBLzYl3yPI4cjDYf0QXZkeU8So+h R3vjAPMckYCdTq9ZIIWlQY9bbTEI3c/DOsR7uh+aAQ1whWKuYHfaJApjW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGAXe0+tJV2Z/2dsb2JhbABFt36BB4IJAQEBAwESASUCPwULCxUDJwdGEQYTIodiBZt6nwWQA2MElWOOR4FpgwM X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71717536" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Apr 2012 15:32:49 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33FWnM0014233; Tue, 3 Apr 2012 15:32:49 GMT Message-Id: <6A3D56E4-BB73-4A8E-B17B-16EC9BC470C9@cisco.com> From: Stan Ratliff To: "Rick Taylor" In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 11:32:49 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:33:00 -0000 On Apr 3, 2012, at 11:22 AM, Rick Taylor wrote: >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> >> On Apr 3, 2012, at 10:23 AM, Rick Taylor wrote: >> >>>> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >>>> >>>> On 04/03/2012 03:51 PM, Rick Taylor wrote: >>>>>> Yes, but I think most of the discussion is about getting rid of >>>>>> the concept of sub-TLVs and only use what PacketBB does provide. >>>>> >>>>> Do you mean: Do not use one message TLV-type for DLEP, with >>>>> individual TLV's in the payload, but use 'top-level' TLV types for >>>>> each DLEP TLV? >>>>> >>>>> I can see the available numbers running out quickly, particularly >>>>> with vendor-specific metric TLVs. >>>>> >>>>> Can the (RFC5444, section 5.4.1, page 15) help > here? >>>>> Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to >>>>> tlv-type-ext? >>>> >>>> You do not need to use the extension type for this. >>>> >>>> Each Message type defined for PacketBB can have up to 96 > message-type >>>> specific TLVs (the ids between 128 and 223 including all of their >>>> extension types). Unless you say that 96 TLVs are not enough for >>>> DLEP, >>>> we should be fine. >>>> >>>> See RFC 5444, Section 6.4. >>> >>> Aah, I was demonstrating my lack of knowledge of packetBB. Having >>> re-read section 6.4, I think 96 DLEP specific TLVs is plenty! >>> >>> Hopefully we have convinced the authors? >>> >> >> Not sure you've convinced the authors... ;-) > > "Bother!" said Pooh. > >> >> This is why I said in Paris that at least part of this is semantics - >> what we're currently calling "sub-TLV's" can easily be re-named to >> "message-type specific TLV's".... and if that simple name change >> (notice there's no other packet format changes) makes everyone happy, >> then I'm good to go.... If we're talking about shuffling the packet >> formats around, and I never have been clear on that, then I've still >> got a problem. > > I think there are 2 issues here concerning packetBB and DLEP. > > 1) Sub-TLVs > 2) Address blocks > > As I understand it, the change request for 1, is to move the sub-TLV > ids > into the message-private TLV space, a minimal change. > > The change request for 2 is more of a "Keeping in the spirit of > packetBB" request. The proposal is to move the Neighbour* messages > from > the Message-TLV block to the per-message Address Block TLVs, indexed > by > the layer-2 (MAC) address of the neighbour. This is a compatible > change > with 1, but requires more document changes. > Ah, we've reached the crux of my concern. What I've HEARD (not necessarily what's been said) about use of address blocks is basically "well, since you can hold an IPv4 address in 128 bits, with "appropriate" padding, and you can hold a MAC address in 128 bits, with appropriate padding, then we can somehow encode IPv4 addresses and MAC addresses into these larger entities, and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That allows DLEP to use RFC 5444 address blocks." My pain with that is that it is a hack. Pure and simple. It's also DLEP specific. I'm opposed to doing anything like that. It's also been said that one route to resolve the issue is to effectively open up discussions on "RFC 5444 bis", to "fix it right". My position is that if there's something that needs to be "fixed", then we SHOULD (perhaps, we MUST?) "fix it right"... ;-) The current fact of the matter is that DLEP needs visibility to multiple address types, both at Layer 2 and Layer 3. RFC 5444 doesn't provide a clean mechanism to do so. So, we put in a series of OPTIONAL TLV's to do it in an efficient manner. If there is sufficient entropy in the WG to fix the problem the right way, then OK. If not, we're just trying to force-fit a square peg farther down into a round hole, and I fail to see the rationale behind doing that. Regards, Stan > The question really is, does change 2 reduce the message size > noticeably, or is the proposal just about making the packets look > nicer? > > packetBB gurus, please enlighten me? > > Rick Taylor From Chris.Dearlove@baesystems.com Tue Apr 3 08:36:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7014011E80FF for ; Tue, 3 Apr 2012 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1PGdqHuv-IQ for ; Tue, 3 Apr 2012 08:36:02 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 294F611E80F6 for ; Tue, 3 Apr 2012 08:35:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="199104824" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 16:35:55 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33FZtYf031838; Tue, 3 Apr 2012 16:35:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:35:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 16:35:53 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RqAdnLMTO2nxTj0C7DW8Li2YIkwABw1Og References: <4F7B0497.309@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Darryl Satterwhite" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 15:35:54.0842 (UTC) FILETIME=[754B23A0:01CD11AF] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:36:03 -0000 As discussion in I think autoconf considered, a critical question is whethe= r the L2 forwarding decrements IP packet hop limit (TTL). If it does then u= npleasantness results, but if it doesn't then L2 can be hidden. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= arryl Satterwhite Sent: 03 April 2012 15:43 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On 4/3/12 10:09 AM, "Henning Rogge" wrote: > On 04/03/2012 03:53 PM, Darryl Satterwhite wrote: >> Rick and others, >>=20 >> I would like to go back to the original discussion of reporting multi-ho= p >> topologies within the radio net with DLEP. >=20 > I am not really happy with this usecase, but I agree that it exists and > we need a good solution for this. >=20 >> It has always been the authors >> intent that DLEP would only be used to report events(Up/Down) and link >> metrics for neighbors that are one hop away. If the radio net happens to= be >> a layer2 mesh network, that should be transparent to routers running DLE= P. >> If the radios associated with this layer2 mesh choose to report, via DLE= P, >> neighbors that are 2 or more hops away in their layer2 mesh then that sh= ould >> be transparent to the DLEP routers. The radio, with its knowledge of its= own >> layer2 mesh topology, should craft the DLEP neighbor metrics to account = for >> neighbors being multiple hops away. >=20 > I do not like this solution because it would hide parts of what is going > on from the routing protocol. Even if we do it the way you describe, > DLEP would not be able to push out its full topology. >=20 > What do you think about this? >=20 > Instead of pushing out ALL the topology in a single DLEP message, we use > the Originator field of the message for defining a "reference point" for > the following neighbor data (no originator address means "this radio"). >=20 > This means that the DLEP agent which has a full knowledge of the > topology of the mesh below creates one Neighbor-Message for every node > in the network, each containing the neighbors of this node and the known > metric data. >=20 > I think this might solve the full mesh usecase. >=20 > (I would still like to have the option to switch off the meshing > capability of the radio. Running a layer-3 mesh routing protocol over a > layer-2 mesh routing protocol is a recipe for a disaster.) >=20 I feel that any bleeding of the layer 2 radio topology into the router's layer 3 routing domain is recipe for disaster. The radio network should be transparent to DLEP routers. The DLEP routers should only be aware of neighbors that can be reached over this radio network and the metrics for those neighbors which is used to calculate a route cost to reach those neighbors. >> Also I saw where it was mentioned that it would be nice if DLEP could re= port >> link metrics in both directions. The original purpose for DLEP was repor= ting >> up/down and link metrics to provide routing protocols with addition >> information to make quicker and more informed decisions on how to reach >> one-hop neighbors on a radio net. With that said, I don't understand how= a >> router would use an inbound traffic link metric. Help me understand the = use >> case. >=20 > Yes, having asymmetric values for the same metric is a common use case. > Maybe we could do this by using an extension type for "explicit reverse > metric value" for all link metric address-TLVs ? I understand that there could be asymmetric links but I question how a router would use this information. How would a router use a metric for traffic ingress'ing its interface? >=20 > Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Tue Apr 3 08:36:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2611E8105 for ; Tue, 3 Apr 2012 08:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-X2PbuU+8c8 for ; Tue, 3 Apr 2012 08:36:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD63911E8103 for ; Tue, 3 Apr 2012 08:36:06 -0700 (PDT) Received: by lagj5 with SMTP id j5so5509734lag.31 for ; Tue, 03 Apr 2012 08:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iB05FVOhBw+JkAgMq2GJyqHlMs7hSOy2SUhFkR+LLj8=; b=ce4HmTIgTmygl6iNcPXxKvvOGzPPWjMg55L+Z5gV1f9Lg8zKsF2UEig5aeVV1Zc5A+ +rECIuy0UrtzD+4qGvh2eNtyf02I1XgQ6yO4OBl/HJ2B15czJS93FdupgMfJnHu6qsy5 eb0pysgVYruHsU8B0Zkj0hoSa8iX4j4842ABvME6s6NfvFB4s0yp2qvitg1veZcloTTf y0hlsfkglyIVQMF1KsPDMfPYu2SmihCoK7ii06FBhPzk8qy09RbKoNz2cupffyggl59n fuV06SP9dRiVA7dO5KIxJTGhhgyW3OCjlgvVbRV1lI9lnzobFYXtn+QucPrDGpJ1oowF QpEA== Received: by 10.152.131.9 with SMTP id oi9mr14608583lab.6.1333467365790; Tue, 03 Apr 2012 08:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:35:45 -0700 (PDT) In-Reply-To: References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net> <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> <1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <4F7AEA06.4080609@fkie.fraunhofer.de> <4F7AEBCE.6070405@fkie.fraunhofer.de> From: Henning Rogge Date: Tue, 3 Apr 2012 17:35:45 +0200 Message-ID: To: Stan Ratliff , Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:36:08 -0000 On Tue, Apr 3, 2012 at 17:22, Rick Taylor wrote: > I think there are 2 issues here concerning packetBB and DLEP. > > 1) Sub-TLVs > 2) Address blocks Yes. > As I understand it, the change request for 1, is to move the sub-TLV ids > into the message-private TLV space, a minimal change. > > The change request for 2 is more of a "Keeping in the spirit of > packetBB" request. The proposal is to move the Neighbour* messages from > the Message-TLV block to the per-message Address Block TLVs, indexed by > the layer-2 (MAC) address of the neighbour. This is a compatible change > with 1, but requires more document changes. > > The question really is, does change 2 reduce the message size > noticeably, or is the proposal just about making the packets look nicer? Yes, it should do so. First, if you have multiple Neighbors inside your Neighbor-Update message, you can share the metric TLV headers between them. You also can compress the MAC addresses down to 3 bytes if they are from the same block because they are from the same manufacturer. On Tue, Apr 3, 2012 at 17:24, Stan Ratliff wrote: > I'll attempt to explain the use case for radio knowledge of IP addresses: > > From a Layer 3 perspective, metrics are *useless* unless they are in the > context of a next-hop (or destination) address - for example it's all well > and good to say "I've got 54Mbps of bandwidth on that 802.11g device hanging > off of interface FastEthernet0/1", but if the router doesn't know what > traffic might be sent out said interface, what good does it do you? Yes, I > know - the standard response to that is "well, we can ARP, or use IPv6 ND to > figure out the Layer 3 addresses". Problem is, that takes time. Time some of > these networks don't have. Most Layer-3 routing protocols use Linklayer multicasts to communicate with each other. So they just have to look into the mac addresses of the received protocol messages to detect the MAC. No network traffic necessary at all. We have a plugin in our OLSR.org implementation that use this strategy to fill the ARP cache even before you get traffic, which makes the whole ARP unnecessary. > Some of my deployments (not all, but some) are in the military space. > Putting routers and radios on military vehicles is interesting. Putting > routers and radios on military airplanes is even MORE interesting. > Sometimes, you don't have 60 seconds for the link to stabilize, and > discovery protocols to run, and routing protocols to converge - you have a > relatively short amount of time to recognize the asset overhead, determine > metrics to it (and possibly through it), and push data while you can. So > having nice, neat, interesting things like a Layer 2 MAC address, AND all of > the associated Layer 3 addresses right up front (like in a Neighbor Up > message) helps that out a bunch. Using the Layer-2 as the (2-hop?) neighbor detection for a layer-3 routing protocol might be an interesting choice. Most TDMA-MACs have to learn their two-hop neighbors anyway. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Tue Apr 3 08:38:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35A21F8559 for ; Tue, 3 Apr 2012 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhzV8oDuGsK1 for ; Tue, 3 Apr 2012 08:38:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 358E421F8582 for ; Tue, 3 Apr 2012 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3792; q=dns/txt; s=iport; t=1333467486; x=1334677086; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Z5m9XhZgH5cqmCy5e90M6PhbfR/EHmSHQKDwIvwE67U=; b=ag5o7A8lZTuFYSzf8+M29AMFalZGaL54k/iUiQd0pop7UNNXdJ0sexKZ r3RFObYSo+keI3S2ITD6llOObeaJ9Ewlwe6g8vOo1QZOKxDnEAXEK5Y2z MxN5ZE6Cj9yrKAft1ss+bnRQ4nTYA5ADjHVvErTQHo3xrdBUdJGZVFaiP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM0Ye0+tJV2d/2dsb2JhbABFt36BB4IJAQEBAwESASUCPwULCw4KLlcGEyKHYgWbe58BkANjBJVjgRGNNoFpgwM X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71703665" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 03 Apr 2012 15:38:05 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q33Fc5SN022039; Tue, 3 Apr 2012 15:38:05 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 11:38:05 -0400 References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net> <0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com> <1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <4F7AEA06.4080609@fkie.fraunhofer.de> <4F7AEBCE.6070405@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:38:13 -0000 On Apr 3, 2012, at 11:35 AM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 17:22, Rick Taylor > wrote: >> I think there are 2 issues here concerning packetBB and DLEP. >> >> 1) Sub-TLVs >> 2) Address blocks > Yes. > >> As I understand it, the change request for 1, is to move the sub- >> TLV ids >> into the message-private TLV space, a minimal change. >> >> The change request for 2 is more of a "Keeping in the spirit of >> packetBB" request. The proposal is to move the Neighbour* messages >> from >> the Message-TLV block to the per-message Address Block TLVs, >> indexed by >> the layer-2 (MAC) address of the neighbour. This is a compatible >> change >> with 1, but requires more document changes. >> >> The question really is, does change 2 reduce the message size >> noticeably, or is the proposal just about making the packets look >> nicer? > Yes, it should do so. > > First, if you have multiple Neighbors inside your Neighbor-Update > message, you can share the metric TLV headers between them. > > You also can compress the MAC addresses down to 3 bytes if they are > from the same block because they are from the same manufacturer. > > On Tue, Apr 3, 2012 at 17:24, Stan Ratliff wrote: >> I'll attempt to explain the use case for radio knowledge of IP >> addresses: >> >> From a Layer 3 perspective, metrics are *useless* unless they are >> in the >> context of a next-hop (or destination) address - for example it's >> all well >> and good to say "I've got 54Mbps of bandwidth on that 802.11g >> device hanging >> off of interface FastEthernet0/1", but if the router doesn't know >> what >> traffic might be sent out said interface, what good does it do you? >> Yes, I >> know - the standard response to that is "well, we can ARP, or use >> IPv6 ND to >> figure out the Layer 3 addresses". Problem is, that takes time. >> Time some of >> these networks don't have. > Most Layer-3 routing protocols use Linklayer multicasts to communicate > with each other. So they just have to look into the mac addresses of > the received protocol messages to detect the MAC. No network traffic > necessary at all. > > We have a plugin in our OLSR.org implementation that use this strategy > to fill the ARP cache even before you get traffic, which makes the > whole ARP unnecessary. > Cool. In that case, you could actually use the DLEP information to fill the ARP cache in... ;-) Yet another use case for radios that OPTIONALLY know about the Layer 3 addresses. Regards, Stan >> Some of my deployments (not all, but some) are in the military space. >> Putting routers and radios on military vehicles is interesting. >> Putting >> routers and radios on military airplanes is even MORE interesting. >> Sometimes, you don't have 60 seconds for the link to stabilize, and >> discovery protocols to run, and routing protocols to converge - you >> have a >> relatively short amount of time to recognize the asset overhead, >> determine >> metrics to it (and possibly through it), and push data while you >> can. So >> having nice, neat, interesting things like a Layer 2 MAC address, >> AND all of >> the associated Layer 3 addresses right up front (like in a Neighbor >> Up >> message) helps that out a bunch. > Using the Layer-2 as the (2-hop?) neighbor detection for a layer-3 > routing protocol might be an interesting choice. Most TDMA-MACs have > to learn their two-hop neighbors anyway. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Tue Apr 3 08:42:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9193211E80B5 for ; Tue, 3 Apr 2012 08:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SD-9DfIKDeG for ; Tue, 3 Apr 2012 08:42:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 939E811E80AE for ; Tue, 3 Apr 2012 08:42:52 -0700 (PDT) Received: by lagj5 with SMTP id j5so5517372lag.31 for ; Tue, 03 Apr 2012 08:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c/QMHEugT+1JGNT7VSXFT7AsL25FxkVTzpKdasAuQto=; b=IuU77KxXxIRr+5qTnMKrmy2VZTA0nFwGo7f9IFBatUPgpMkX7hi8GWrUXLWbSZMb5a iSAW0/fzqVDvhxRyHZnKsyHww1RI0tq+fHCI+U9PtF9gG+xG+X7hQV5bxP1w4/QMk4iF 1ftYXsHbRQnUdpxYOXwOLWkK3k1d9SU1aHaPWB6uolR7AKzCbwpeX4zkEEGadUvlQ1Ns b/w216tigK8ixfv6VRAihifovgpKIf/MdoknM7C32GZXlT5HHj3y9roNYGzvgi+pj1BS Qu4rpdL0TcslXhBxcckBbhMhOpJ3iIvzlncQKHKteoW/Mt9mI1Z+Bm5YWQw0OsDuZReq AOwQ== Received: by 10.152.135.104 with SMTP id pr8mr14571944lab.27.1333467771536; Tue, 03 Apr 2012 08:42:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:42:31 -0700 (PDT) In-Reply-To: <6A3D56E4-BB73-4A8E-B17B-16EC9BC470C9@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> <6A3D56E4-BB73-4A8E-B17B-16EC9BC470C9@cisco.com> From: Henning Rogge Date: Tue, 3 Apr 2012 17:42:31 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:42:53 -0000 On Tue, Apr 3, 2012 at 17:32, Stan Ratliff wrote: > Ah, we've reached the crux of my concern. What I've HEARD (not necessarily > what's been said) about use of address blocks is basically "well, since you > can hold an IPv4 address in 128 bits, with "appropriate" padding, and you > can hold a MAC address in 128 bits, with appropriate padding, then we can > somehow encode IPv4 addresses and MAC addresses into these larger entities, > and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That allows > DLEP to use RFC 5444 address blocks." My pain with that is that it is a > hack. Pure and simple. It's also DLEP specific. I'm opposed to doing > anything like that. It's also been said that one route to resolve the issue > is to effectively open up discussions on "RFC 5444 bis", to "fix it right". > My position is that if there's something that needs to be "fixed", then we > SHOULD (perhaps, we MUST?) "fix it right"... ;-) > The current fact of the matter is that DLEP needs visibility to multiple > address types, both at Layer 2 and Layer 3. RFC 5444 doesn't provide a clean > mechanism to do so. So, we put in a series of OPTIONAL TLV's to do it in an > efficient manner. If there is sufficient entropy in the WG to fix the > problem the right way, then OK. If not, we're just trying to force-fit a > square peg farther down into a round hole, and I fail to see the rationale > behind doing that. Most MAC-Layers do not even know about Layer-3 addresses, so they are a special case. The typical DLEP messages might only contain MAC addresses. Think about DLEP for IEEE 802.11 for example. I think use a special TLV for a special MAC-Layer is okay. > Cool. In that case, you could actually use the DLEP information to fill the ARP cache in... > Yet another use case for radios that OPTIONALLY know about the Layer 3 addresses. Thats why I think the "IPv4 Interface address" and "IPv6 Interface address" TLV is a necessary addition for this radios. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Tue Apr 3 08:46:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E61E11E80FF for ; Tue, 3 Apr 2012 08:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3a6aBKIvI3j for ; Tue, 3 Apr 2012 08:46:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 517BB11E80AE for ; Tue, 3 Apr 2012 08:46:13 -0700 (PDT) Received: by lagj5 with SMTP id j5so5521394lag.31 for ; Tue, 03 Apr 2012 08:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XoW5xLZanop/1Cgi3P+oLbPu6qR9s8JHVrss7zaA14k=; b=qb1Sqwx0qro4FBh9ilSTTozmOFeMZxKvRw2NGFGHW2Go0m4YwGJU7ASW/uCAMc5vW2 bpD2Tjx1FcIL9NmYQjkcnddwi+GLlSQrCsPss+WWWCbc/UY0g84rQh84ds7ZZtXGtTIL OheGiPM3gU4ymfx5Mo78ays0t9G5T1DQ/TMRquEmnDly2eM70z/EGe8f/Xy2gPEC/O2y +JrhrEr/SUbvevwI3sZC1B5giPDCDpf09gye2Mp07CQSC+vri1+XHoHqxOzDTi/puNy1 wEQw0OlGq0qOcvYFdA/ybzt47TzenX0FZeZ7As6CoZAArEuoUZpV23yleau1XdZKP4bs ZsRg== Received: by 10.152.129.137 with SMTP id nw9mr14530397lab.48.1333467972251; Tue, 03 Apr 2012 08:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:45:52 -0700 (PDT) In-Reply-To: <6A3D56E4-BB73-4A8E-B17B-16EC9BC470C9@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> <6A3D56E4-BB73-4A8E-B17B-16EC9BC470C9@cisco.com> From: Henning Rogge Date: Tue, 3 Apr 2012 17:45:52 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:46:15 -0000 Forgot something in my last post... On Tue, Apr 3, 2012 at 17:32, Stan Ratliff wrote: > Ah, we've reached the crux of my concern. What I've HEARD (not necessarily > what's been said) about use of address blocks is basically "well, since you > can hold an IPv4 address in 128 bits, with "appropriate" padding, and you > can hold a MAC address in 128 bits, with appropriate padding, then we can > somehow encode IPv4 addresses and MAC addresses into these larger entities, > and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That allows > DLEP to use RFC 5444 address blocks." My pain with that is that it is a > hack. Pure and simple. It's also DLEP specific. I'm opposed to doing > anything like that. It's also been said that one route to resolve the issue > is to effectively open up discussions on "RFC 5444 bis", to "fix it right". > My position is that if there's something that needs to be "fixed", then we > SHOULD (perhaps, we MUST?) "fix it right"... ;-) The concept I (developed and) discussed in the discussion with Rick was to use 6 byte addresses in DLEP so you can put in MACs in a clean way. If you have IPs available, add them with two special address TLVs. DLEP is about the layer-2, so its not unreasonable to give the MAC addresses a special place. And it would also sidestep the problem with padding. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Tue Apr 3 08:50:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0840511E80ED for ; Tue, 3 Apr 2012 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONYzAhnjl2CU for ; Tue, 3 Apr 2012 08:50:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE4F11E80AE for ; Tue, 3 Apr 2012 08:50:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199110003" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 16:50:40 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33Fo6l5008440; Tue, 3 Apr 2012 16:50:39 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:50:31 +0100 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 Date: Tue, 3 Apr 2012 16:50:30 +0100 Message-ID: In-Reply-To: <01173FD3-4E44-49A5-85B3-0E1103987962@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rq2OfaISot8T6QI2MP/drsTS9ZAABMw5g References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB224@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB26E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB2ED@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB35C@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> <01173FD3-4E44-49A5-85B3-0E1103987962@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Rick Taylor" X-OriginalArrivalTime: 03 Apr 2012 15:50:31.0558 (UTC) FILETIME=[7FDB6260:01CD11B1] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:50:42 -0000 I really need to read DLEP properly. But I just quickly skimmed trying to l= ook at sub-TLVs. And I don't see that term used. I do see a lot of normal l= ooking TLVs in a TLV block. But what I need to look more carefully at is ad= dresses and their handling. What isn't correct, at least for normal use of 5444, is packets. As define= d in 5444/5498, DLEP doesn't get to define a packet, it just defines one o= r more messages. Packets are owned by 5444 and allowed to include messages = of different types, from different protocols, piggybacked together. The more precious resource is messages. There are only 256 (minus private/e= xperimental) of these, and DLEP appears to be rather profligate with these,= claiming 17. NHDP and OLSRv2 manage with one apiece. I don't believe 17 ca= n be justified, and that (agreed, at a cost of a small number of extra byte= s) this could, and should, be reduced a lot. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 03 April 2012 16:06 To: Rick Taylor Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 3, 2012, at 10:23 AM, Rick Taylor wrote: >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> >> On 04/03/2012 03:51 PM, Rick Taylor wrote: >>>> Yes, but I think most of the discussion is about getting rid of >>>> the concept of sub-TLVs and only use what PacketBB does provide. >>> >>> Do you mean: Do not use one message TLV-type for DLEP, with >>> individual TLV's in the payload, but use 'top-level' TLV types for >>> each DLEP TLV? >>> >>> I can see the available numbers running out quickly, particularly >>> with vendor-specific metric TLVs. >>> >>> Can the (RFC5444, section 5.4.1, page 15) help here? >>> Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to >>> tlv-type-ext? >> >> You do not need to use the extension type for this. >> >> Each Message type defined for PacketBB can have up to 96 message-type >> specific TLVs (the ids between 128 and 223 including all of their >> extension types). Unless you say that 96 TLVs are not enough for =20 >> DLEP, >> we should be fine. >> >> See RFC 5444, Section 6.4. > > Aah, I was demonstrating my lack of knowledge of packetBB. Having > re-read section 6.4, I think 96 DLEP specific TLVs is plenty! > > Hopefully we have convinced the authors? > Not sure you've convinced the authors... ;-) This is why I said in Paris that at least part of this is semantics - =20 what we're currently calling "sub-TLV's" can easily be re-named to =20 "message-type specific TLV's".... and if that simple name change =20 (notice there's no other packet format changes) makes everyone happy, =20 then I'm good to go.... If we're talking about shuffling the packet =20 formats around, and I never have been clear on that, then I've still =20 got a problem. Regards, Stan >> >>>> I think using two DLEP-specific Address-TLVs (instead of > sub-tlvs), >>>> one for IPv4 and one for IPv6 would be okay. >>> >>> I agree, but someone might start shouting about ATM, who knows? >>> >>>> And we could also do this calculation already in the DLEP client, >>>> so we do not need a special TLV for it. >>> >>> Hmmm... not always true, what if one neighbour had a shorter IPv6 >>> prefix than the other. Not ideal I know, but possible. Remember > in >>> MANETs configurations often end up wrong. >> >> the point is that DLEP does not care about the efficient transport > over >> the radio metric, it just can assume that the radio can decode it. > DLEP >> is only local traffic (not over radio), so we do not need to look at >> compression that much. > > Agreed > > I still need to propose grouping the metric TLV ids to carry extra > semantic information, much like SCTP chunk type id assignments carry > extra information about the handling of the chunk. But I'll start a =20 > new > thread for that. > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From dsatterw@cisco.com Tue Apr 3 08:52:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3662511E80B8 for ; Tue, 3 Apr 2012 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.382 X-Spam-Level: X-Spam-Status: No, score=-8.382 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXsyfs+DZD1U for ; Tue, 3 Apr 2012 08:52:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BE31111E80D0 for ; Tue, 3 Apr 2012 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=1750; q=dns/txt; s=iport; t=1333468332; x=1334677932; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=PuzfG0FB4mpJjz56ljC5oxNn9afMOT9zf17lhzsI5qs=; b=kVdDK9i7gRJi6/i9kqWWDm8RAP4FoAvsCtq7tJM7Uyl+2Jcfl6kFPrZC +TAzUBQR2T9dlLFxG0aM7CP4CeYeXTavcKsZvtSnq69b9zAfpxFVvWts9 uxSuhOK00+JTND5SR6+1ccHbTqYlgVAgKHbk/S3lMWQmX9RCZ7AmKtnJJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4IAFIce0+tJV2c/2dsb2JhbABFt38CgQeCCQEBAQMBEgEnAgEuDgUNAQgOCoEFAQEEAQ0FIodiBZt1nwCKDoZYBJVjjkeBaYMD X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71686481" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 03 Apr 2012 15:52:12 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q33FqCeL008549; Tue, 3 Apr 2012 15:52:12 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:52:12 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.63.12]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 15:52:11 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 11:52:10 -0400 From: Darryl Satterwhite To: Henning Rogge , Stan Ratliff Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RsbqIEJyo7ZtBMEOz0fU78h3pzQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 15:52:12.0085 (UTC) FILETIME=[BBC69650:01CD11B1] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:52:17 -0000 Henning, I'm beginning to get lost with what you are proposing as an alternative to the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us non-RFC5444 experts, can you clarify? Darryl Satterwhite Cisco Systems On 4/3/12 11:45 AM, "Henning Rogge" wrote: > Forgot something in my last post... > > On Tue, Apr 3, 2012 at 17:32, Stan Ratliff wrote: >> Ah, we've reached the crux of my concern. What I've HEARD (not necessarily >> what's been said) about use of address blocks is basically "well, since you >> can hold an IPv4 address in 128 bits, with "appropriate" padding, and you >> can hold a MAC address in 128 bits, with appropriate padding, then we can >> somehow encode IPv4 addresses and MAC addresses into these larger entities, >> and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That allows >> DLEP to use RFC 5444 address blocks." My pain with that is that it is a >> hack. Pure and simple. It's also DLEP specific. I'm opposed to doing >> anything like that. It's also been said that one route to resolve the issue >> is to effectively open up discussions on "RFC 5444 bis", to "fix it right". >> My position is that if there's something that needs to be "fixed", then we >> SHOULD (perhaps, we MUST?) "fix it right"... ;-) > > The concept I (developed and) discussed in the discussion with Rick > was to use 6 byte addresses in DLEP so you can put in MACs in a clean > way. If you have IPs available, add them with two special address > TLVs. > > DLEP is about the layer-2, so its not unreasonable to give the MAC > addresses a special place. And it would also sidestep the problem with > padding. > > Henning Rogge From Chris.Dearlove@baesystems.com Tue Apr 3 08:54:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D926F11E80F4 for ; Tue, 3 Apr 2012 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjKOPu1WfXbm for ; Tue, 3 Apr 2012 08:54:07 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF4E11E80F0 for ; Tue, 3 Apr 2012 08:53:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199111159" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 16:53:47 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33FrkIK010467; Tue, 3 Apr 2012 16:53:47 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 16:53:46 +0100 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 Date: Tue, 3 Apr 2012 16:53:45 +0100 Message-ID: In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rq4oUOF2dQa34QWCtmXiAl/kuvQAAC9cAAAF2p9A= References: <7B31B0093014224A843C10C0CCE92AC1035AB3EB@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB4DB@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Rick Taylor" , "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 15:53:46.0726 (UTC) FILETIME=[F42FA860:01CD11B1] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:54:08 -0000 As I've said, what we need is a good example, one showing the features. Thi= s should be of the form indicating what advertising, and what information (= addresses, metrics etc.) for those. In particular this needs to be a compli= cated case (though a simpler, typical, case as well wouldn't hurt), so if t= here may be multiple address types in one message, the example needs to inc= lude that, etc. (Possibly more than one example is needed, I don't know.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= ick Taylor Sent: 03 April 2012 16:22 To: Stan Ratliff Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > From: Stan Ratliff [mailto:sratliff@cisco.com] >=20 > On Apr 3, 2012, at 10:23 AM, Rick Taylor wrote: >=20 > >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] > >> > >> On 04/03/2012 03:51 PM, Rick Taylor wrote: > >>>> Yes, but I think most of the discussion is about getting rid of > >>>> the concept of sub-TLVs and only use what PacketBB does provide. > >>> > >>> Do you mean: Do not use one message TLV-type for DLEP, with > >>> individual TLV's in the payload, but use 'top-level' TLV types for > >>> each DLEP TLV? > >>> > >>> I can see the available numbers running out quickly, particularly > >>> with vendor-specific metric TLVs. > >>> > >>> Can the (RFC5444, section 5.4.1, page 15) help here? > >>> Can we use 1 top-level DLEP TLV-type and move the sub-TLV's to > >>> tlv-type-ext? > >> > >> You do not need to use the extension type for this. > >> > >> Each Message type defined for PacketBB can have up to 96 message-type > >> specific TLVs (the ids between 128 and 223 including all of their > >> extension types). Unless you say that 96 TLVs are not enough for > >> DLEP, > >> we should be fine. > >> > >> See RFC 5444, Section 6.4. > > > > Aah, I was demonstrating my lack of knowledge of packetBB. Having > > re-read section 6.4, I think 96 DLEP specific TLVs is plenty! > > > > Hopefully we have convinced the authors? > > >=20 > Not sure you've convinced the authors... ;-) "Bother!" said Pooh. > > This is why I said in Paris that at least part of this is semantics - > what we're currently calling "sub-TLV's" can easily be re-named to > "message-type specific TLV's".... and if that simple name change > (notice there's no other packet format changes) makes everyone happy, > then I'm good to go.... If we're talking about shuffling the packet > formats around, and I never have been clear on that, then I've still > got a problem. I think there are 2 issues here concerning packetBB and DLEP. 1) Sub-TLVs 2) Address blocks As I understand it, the change request for 1, is to move the sub-TLV ids into the message-private TLV space, a minimal change. The change request for 2 is more of a "Keeping in the spirit of packetBB" request. The proposal is to move the Neighbour* messages from the Message-TLV block to the per-message Address Block TLVs, indexed by the layer-2 (MAC) address of the neighbour. This is a compatible change with 1, but requires more document changes. The question really is, does change 2 reduce the message size noticeably, or is the proposal just about making the packets look nicer? packetBB gurus, please enlighten me? Rick Taylor _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Tue Apr 3 08:57:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2711E80F5 for ; Tue, 3 Apr 2012 08:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqG75R6VXsGr for ; Tue, 3 Apr 2012 08:57:38 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABAC11E80EF for ; Tue, 3 Apr 2012 08:57:36 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3878884bku.31 for ; Tue, 03 Apr 2012 08:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GhoXSoggKJ7hZHQVOVgb7jzAPYEWRADt5a28fuDRGeI=; b=RKW32BghqTPm49z0AlxijfCER9/LY5KuD9xX/x9QhrmiZ8xgk0UInqYWSDvjIeUAKf I3jf8ZhBQAasRnUzaemAG4rosDwHEtnxmhkUL/LZvCrIP2r37qtNT2izhDQdSEHv1tAO 7dYdhlHUDJeEEk6WYW9veO3hCRjYj42xnUn2HlLqf6r+qndX9DIE+qi91j2mNuh8TYGF fzLnXWdYybuxsDi/8ac77SchxT+iAeN1vBke3RO/aEhl/aUbX/Y6WB1k3JEFEfEdxhdw U2xXaGCyB0lv2V8BHkggxoiQw0RG7v5/ZDhcv2HQra9M90tVDpkgELvwjhtf4LFLDL0d 8lfw== Received: by 10.152.103.239 with SMTP id fz15mr14586844lab.42.1333468655584; Tue, 03 Apr 2012 08:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 08:57:15 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 3 Apr 2012 17:57:15 +0200 Message-ID: To: Darryl Satterwhite Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:57:38 -0000 On Tue, Apr 3, 2012 at 17:52, Darryl Satterwhite wrote: > Henning, > > I'm beginning to get lost with what you are proposing as an alternative to > the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us > non-RFC5444 experts, can you clarify? I talked with Rick Taylor today quite a lot to understand the need of IPv4/IPv6 and I think we got to a better solution than my earlier proposal. The new idea is to set the address length field in the message header to 6, so we can put neighbor MAC addresses into the message in a proper way. We then can add metrics as TLVs to this addresses. We can also compress the MAC addresses as described in RFC 5444. If the Mac-Layer had additional knowledge about IPv4 and IPv6 address of the interface of the other side, we put this in a special address TLV attached to the MAC address. This way we don't waste space with padding. This "add IP as TLV to a MAC address" is special for DLEP, but so is layer-3 knowledge in layer-2 radios. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From dsatterw@cisco.com Tue Apr 3 08:59:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C788111E8120 for ; Tue, 3 Apr 2012 08:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.432 X-Spam-Level: X-Spam-Status: No, score=-8.432 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukG45wKTt2oJ for ; Tue, 3 Apr 2012 08:59:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A411E80F5 for ; Tue, 3 Apr 2012 08:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=1369; q=dns/txt; s=iport; t=1333468789; x=1334678389; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=lgsrE1iVN6rhmECipaIs36HqYxVsqboXC55Qffcw/vA=; b=k5pHSYo6hzHHZ0pOECZeLLPTxQehX2IMF22Q/Pbwd9PS5qFGzmcRUVyV Dn3DB+rix24o5B2tmCi7RDT5OI7kYG0M9AtckoB9WrWLgn+PSz48DBGbo 1rUEVXew+8AXmjN4PRfEEARsBvH+7ZQDT0nHou+1E3nJC92eSI1CGb1j0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0IAK0de0+tJV2b/2dsb2JhbABDuAwCgQeCCQEBAQMBEgEnAgE8BQ0BCIEdAQEEAQ0FIodiBZ93lxeQZgSVY45HgWmDAw X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71721349" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2012 15:59:48 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q33FxmMG003253; Tue, 3 Apr 2012 15:59:48 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:59:48 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 15:59:48 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 11:59:46 -0400 From: Darryl Satterwhite To: "Dearlove, Christopher (UK)" , Stan Ratliff , Rick Taylor Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rq2OfaISot8T6QI2MP/drsTS9ZAABMw5gAACmnzM= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 15:59:48.0437 (UTC) FILETIME=[CBC86050:01CD11B2] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:59:49 -0000 On 4/3/12 11:50 AM, "Dearlove, Christopher (UK)" wrote: > I really need to read DLEP properly. But I just quickly skimmed trying to look > at sub-TLVs. And I don't see that term used. I do see a lot of normal looking > TLVs in a TLV block. But what I need to look more carefully at is addresses > and their handling. > > What isn't correct, at least for normal use of 5444, is packets. As defined > in 5444/5498, DLEP doesn't get to define a packet, it just defines one or > more messages. Packets are owned by 5444 and allowed to include messages of > different types, from different protocols, piggybacked together. > > The more precious resource is messages. There are only 256 (minus > private/experimental) of these, and DLEP appears to be rather profligate with > these, claiming 17. NHDP and OLSRv2 manage with one apiece. I don't believe 17 > can be justified, and that (agreed, at a cost of a small number of extra > bytes) this could, and should, be reduced a lot. I don't believe this to be the case. We, I thought, were only using 1 to specify the it's a DLEP message and all other type definitions are done within the context of a DLEP message. This was something that we did as part of recommendations that were made when we submitted DLEP version 1. Darryl Satterwhite Cisco Systems From sratliff@cisco.com Tue Apr 3 09:00:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1B11E8128 for ; Tue, 3 Apr 2012 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63R6-ypb4+76 for ; Tue, 3 Apr 2012 09:00:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A302511E812B for ; Tue, 3 Apr 2012 09:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1750; q=dns/txt; s=iport; t=1333468849; x=1334678449; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=BUgCRybg+gg20qkN28JiYn6wB/f9pebdVOz3kWZ3mPw=; b=E+fdc+ZnviG30pf/hnkTe0oRpeL/6nSgVXa6b5QcLVaB2gQ93/JLBUgg Uq1T9Jckda5991KdX3wN4VP0n0N+6+nyREILrOZ18wq9s/pldaY5zXYQX a0XPMsq6vMy4i8F/3NtJzRqPbSELQWty1hlvQK+q766zhtJYNDy5WJ12+ 8=; X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71711185" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 03 Apr 2012 16:00:49 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q33G0meo022086; Tue, 3 Apr 2012 16:00:49 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 12:00:49 -0400 References: X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:00:52 -0000 I think MAC address compression is a red herring. You can't assume a single vendor, so I doubt whether that will be usefull. Also, remember that DLEP traffic (99% of it, anyway) only occurs on the link between the router and its "local" radio. Regards, Stan On Apr 3, 2012, at 11:57 AM, Henning Rogge w > On Tue, Apr 3, 2012 at 17:52, Darryl Satterwhite > wrote: >> Henning, >> >> I'm beginning to get lost with what you are proposing as an >> alternative to >> the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us >> non-RFC5444 experts, can you clarify? > I talked with Rick Taylor today quite a lot to understand the need of > IPv4/IPv6 and I think we got to a better solution than my earlier > proposal. > > The new idea is to set the address length field in the message header > to 6, so we can put neighbor MAC addresses into the message in a > proper way. We then can add metrics as TLVs to this addresses. We can > also compress the MAC addresses as described in RFC 5444. > > If the Mac-Layer had additional knowledge about IPv4 and IPv6 address > of the interface of the other side, we put this in a special address > TLV attached to the MAC address. This way we don't waste space with > padding. > > This "add IP as TLV to a MAC address" is special for DLEP, but so is > layer-3 knowledge in layer-2 radios. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Apr 3 09:01:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBE511E812C for ; Tue, 3 Apr 2012 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXf-3bfmjJrW for ; Tue, 3 Apr 2012 09:01:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 168C211E812D for ; Tue, 3 Apr 2012 09:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1730; q=dns/txt; s=iport; t=1333468914; x=1334678514; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=m7OirxP0Pt1+YeLXAPMJdpHZCbV26q1YIOFuHUTsrkQ=; b=fik9+gfauyLW7TgTKoZm+e1Ubkgp2/r5RgXVTwiYYyT0oIqhDfosdbr1 jwFCD4znIEu8G7dNDWnI2VYB1hUqZD/hjrYBSOn/kR+CJQwhTXKdL5xWc XHX1LTT6e00kFXAkTEV6oq7tJb03zYR4Njv/4CeIPNthwJX7B97D6jUeV I=; X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71739251" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2012 16:01:54 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q33G1r1v010623; Tue, 3 Apr 2012 16:01:53 GMT Message-Id: <76369CE4-1C1C-4947-99FC-BFF190D66CC2@cisco.com> From: Stan Ratliff To: Darryl Satterwhite In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 12:01:54 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:01:55 -0000 Yeah, I'll add my voice to that as well. We tried to get DLEP to the point where it only uses 1 RFC 5444 message TLV. If that's not the case, then I need to understand. Regards, Stan On Apr 3, 2012, at 11:59 AM, Darryl Satterwhite wrote: > > > > On 4/3/12 11:50 AM, "Dearlove, Christopher (UK)" > wrote: > >> I really need to read DLEP properly. But I just quickly skimmed >> trying to look >> at sub-TLVs. And I don't see that term used. I do see a lot of >> normal looking >> TLVs in a TLV block. But what I need to look more carefully at is >> addresses >> and their handling. >> >> What isn't correct, at least for normal use of 5444, is packets. >> As defined >> in 5444/5498, DLEP doesn't get to define a packet, it just defines >> one or >> more messages. Packets are owned by 5444 and allowed to include >> messages of >> different types, from different protocols, piggybacked together. >> >> The more precious resource is messages. There are only 256 (minus >> private/experimental) of these, and DLEP appears to be rather >> profligate with >> these, claiming 17. NHDP and OLSRv2 manage with one apiece. I don't >> believe 17 >> can be justified, and that (agreed, at a cost of a small number of >> extra >> bytes) this could, and should, be reduced a lot. > > I don't believe this to be the case. We, I thought, were only using > 1 to > specify the it's a DLEP message and all other type definitions are > done > within the context of a DLEP message. This was something that we did > as part > of recommendations that were made when we submitted DLEP version 1. > > Darryl Satterwhite > Cisco Systems > From hrogge@googlemail.com Tue Apr 3 09:04:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73B911E8134 for ; Tue, 3 Apr 2012 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtbbu6ViTyqt for ; Tue, 3 Apr 2012 09:04:49 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02711E812F for ; Tue, 3 Apr 2012 09:04:46 -0700 (PDT) Received: by eeke51 with SMTP id e51so1259998eek.31 for ; Tue, 03 Apr 2012 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qUwTqv+IjvITq++SbRb2qjdEhNtpvdH1wfroXMbYIgc=; b=hJKcnSDswYk2YEQHgalVZRYh5KX/molvJL303j5SqAsG/a1Us8yb0ufg1w33+qaoho Fk2/t/nUJ1xlIiB7yW25VTIFi95BkZ70RDkWRRI/PMPZiV5EaXWK0yboHsm0SdvgvHH/ Dyv+1R62FC284BTJ5UJWVLRhK3G0dAM353UwpgnijSNSLWbbFTPJ7b19r/FVGUJYc5aX NnCGHfaxQ6UiLG4o2Izv1ZST9GJTH3CUuUpPEOatrl9dcjx+IYcLrpvlc4BMnFF1zLsA Do4KiTcMMUdGSvgH0uIL1Qc5olJ03pdE9IaQBAjvlyEwRXBTKJCQCD5EKeS3Wv+F6bW5 2g4A== Received: by 10.152.123.229 with SMTP id md5mr14648797lab.34.1333469085344; Tue, 03 Apr 2012 09:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 09:04:24 -0700 (PDT) In-Reply-To: <76369CE4-1C1C-4947-99FC-BFF190D66CC2@cisco.com> References: <76369CE4-1C1C-4947-99FC-BFF190D66CC2@cisco.com> From: Henning Rogge Date: Tue, 3 Apr 2012 18:04:24 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:04:50 -0000 On Tue, Apr 3, 2012 at 18:01, Stan Ratliff wrote: > Yeah, I'll add my voice to that as well. We tried to get DLEP to the point > where it only uses 1 RFC 5444 message TLV. If that's not the case, then I > need to understand. > > Regards, > Stan We can still do this, we just need a TLV to carry the "order" of the DLEP message. I see the most advantage of using "only" RFC 5444 encoding that you can use a common parser/generator for DLEP. At the moment DLEP is not using RFC 5444... its just a wrapper around a partly proprietary encoding. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Tue Apr 3 09:04:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5247A11E812E for ; Tue, 3 Apr 2012 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rckD6LPZyHg for ; Tue, 3 Apr 2012 09:04:51 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 99A3811E8130 for ; Tue, 3 Apr 2012 09:04:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199114279" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 17:04:50 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33G4n2g016917; Tue, 3 Apr 2012 17:04:49 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:04:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 17:04:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RsbqIEJyo7ZtBMEOz0fU78h3pzQAAKblA References: From: "Dearlove, Christopher (UK)" To: "Darryl Satterwhite" , "Henning Rogge" , "Stan Ratliff" X-OriginalArrivalTime: 03 Apr 2012 16:04:49.0362 (UTC) FILETIME=[7F25E320:01CD11B3] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:04:52 -0000 I don't know what Henning is proposing. I know I'm not proposing anything. = I didn't raise the "let's make it more 5444 natural" point, though I have d= efinite sympathies with it. But I also see the multiple address types probl= em. Personally, I couldn't make a good suggestion (whether to change to X, = or leaves things as they are) without specific examples to think about, and= ones derived by someone else from DLEP. For example (not DLEP, rather the sort of thing that might be said). I want to advertise a number, let's say 3 for example, of entities. The fir= st has a MAC address and an IPv4 address, the second has a MAC address and = an IPv6 address (derived from the MAC address) and the third has a MAC addr= ess and an IP address (not derived from the MAC address). All have metric t= ypes A, B and C, the first two also have metrics of type D, the last two al= so have metrics of type E. Then one could think about it (and that example is, deliberately, nasty - t= he question is whether real DLEP messages are that nasty). --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= arryl Satterwhite Sent: 03 April 2012 16:52 To: Henning Rogge; Stan Ratliff Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Henning, I'm beginning to get lost with what you are proposing as an alternative to the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us non-RFC5444 experts, can you clarify? Darryl Satterwhite Cisco Systems On 4/3/12 11:45 AM, "Henning Rogge" wrote: > Forgot something in my last post... >=20 > On Tue, Apr 3, 2012 at 17:32, Stan Ratliff wrote: >> Ah, we've reached the crux of my concern. What I've HEARD (not necessari= ly >> what's been said) about use of address blocks is basically "well, since = you >> can hold an IPv4 address in 128 bits, with "appropriate" padding, and yo= u >> can hold a MAC address in 128 bits, with appropriate padding, then we ca= n >> somehow encode IPv4 addresses and MAC addresses into these larger entiti= es, >> and 'pretend' they are IPv6 addresses, for purposes of RFC 5444. That al= lows >> DLEP to use RFC 5444 address blocks." My pain with that is that it is a >> hack. Pure and simple. It's also DLEP specific. I'm opposed to doing >> anything like that. It's also been said that one route to resolve the is= sue >> is to effectively open up discussions on "RFC 5444 bis", to "fix it righ= t". >> My position is that if there's something that needs to be "fixed", then = we >> SHOULD (perhaps, we MUST?) "fix it right"... ;-) >=20 > The concept I (developed and) discussed in the discussion with Rick > was to use 6 byte addresses in DLEP so you can put in MACs in a clean > way. If you have IPs available, add them with two special address > TLVs. >=20 > DLEP is about the layer-2, so its not unreasonable to give the MAC > addresses a special place. And it would also sidestep the problem with > padding. >=20 > Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From prvs=044012f9eb=npowell@harris.com Tue Apr 3 09:11:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4856721F84D1 for ; Tue, 3 Apr 2012 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRVO8bYlAG1n for ; Tue, 3 Apr 2012 09:11:21 -0700 (PDT) Received: from mlbefw1.harris.com (mlbefw1.ngenready.com [192.52.233.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC9021F85EF for ; Tue, 3 Apr 2012 09:11:04 -0700 (PDT) From: "Powell lll, Nelson" To: Stan Ratliff , Henning Rogge Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RkDyTlxUrjbJdSvCFQoX4+0t8iQAAmqZQAAia0gAAAEPzAAAGVM2AAAcIidA= Date: Tue, 3 Apr 2012 16:10:57 +0000 Message-ID: <13044204616BFB43BC7F6B4EC6B01512206D0E57@ROCMXUS20.cs.myharris.net> References: <13044204616BFB43BC7F6B4EC6B01512206C3758@ROCMXUS20.cs.myharris.net><0B87CF47-DE4E-43BB-946B-7D280D93A2D8@appcomsci.com><1B40484159234F4FB6FE11D4C2F408DEE7C1A3@SUKNPT8108.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC103566CEF@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035AB1D5@SUKNPT8106.cogent-dsn.local> <4F7AEA06.4080609@fkie.fraunhofer.de> <4F7AEBCE.6070405@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:11:22 -0000 I apologize for not keeping up with all of the discussions, but to provide = a "future" use case in concurrence with what Stan has said, I took a stab a= t some ASCII art. =20 Radio =20 +------------------------------+ =20 | | =20 +--------+ | +--------+ +---------+ | =20 | | | | host | | | | =20 | router |-------------|--| or |-----| modem |--|<-- RF -- > | | (PPP) | | rtr? | | | | =20 +--------+ (Ethernet) | +--------+ +---------+ | =20 (USB) | | =20 +------------------------------+ =20 In other postings, I saw mention of 802 based waveforms as the use case; bu= t moving into military, public safety, and other private radio use cases, m= ore advanced devices may incorporate a host or routing capabilities within = the radio that allows for waveform specific optimizations. I do not want to relegate the use of 802 based waveforms. I would like, how= ever, to ensure the compatibility of forward looking waveforms that provide= event driven metrics in association with end point routing information. I= f a Layer-2 MESH can provide the end-point information initially and merely= update metrics as event occur, this will greatly reduce the overhead of a = layer 3 routing protocol traversing the wireless space, and thus returning = throughput to the user. Nelson -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: Tuesday, April 03, 2012 11:25 AM To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours I'll attempt to explain the use case for radio knowledge of IP =20 addresses: From a Layer 3 perspective, metrics are *useless* unless they are in =20 the context of a next-hop (or destination) address - for example it's =20 all well and good to say "I've got 54Mbps of bandwidth on that 802.11g =20 device hanging off of interface FastEthernet0/1", but if the router =20 doesn't know what traffic might be sent out said interface, what good =20 does it do you? Yes, I know - the standard response to that is "well, =20 we can ARP, or use IPv6 ND to figure out the Layer 3 addresses". =20 Problem is, that takes time. Time some of these networks don't have. Some of my deployments (not all, but some) are in the military space. =20 Putting routers and radios on military vehicles is interesting. =20 Putting routers and radios on military airplanes is even MORE =20 interesting. Sometimes, you don't have 60 seconds for the link to =20 stabilize, and discovery protocols to run, and routing protocols to =20 converge - you have a relatively short amount of time to recognize the =20 asset overhead, determine metrics to it (and possibly through it), and =20 push data while you can. So having nice, neat, interesting things like =20 a Layer 2 MAC address, AND all of the associated Layer 3 addresses =20 right up front (like in a Neighbor Up message) helps that out a bunch. Regards, Stan On Apr 3, 2012, at 8:23 AM, Henning Rogge wrote: > On 04/03/2012 02:16 PM, Henning Rogge wrote: >> If this is right, I still would like to see a use-case where the =20 >> radio >> knows about IP addresses and has to tell them the router. > > Just to clarify this... I really do NOT want to remove anything from =20 > DLEP that is useful. But at the moment I lack the knowledge about =20 > the common usecase for IP-addresses in DLEP. Maybe someone can =20 > explain his usecase. > > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Tue Apr 3 09:11:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3511E8116 for ; Tue, 3 Apr 2012 09:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcPcSAXHiD7F for ; Tue, 3 Apr 2012 09:11:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BC5BB11E8140 for ; Tue, 3 Apr 2012 09:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1287; q=dns/txt; s=iport; t=1333469513; x=1334679113; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=M5ikxMfVOvm7fPljNAtflPQg/iVGJ7VFslwd+WqSJtU=; b=Bo74w6PvyxuGCdSIlMlnJUFnwQNT4Av2GdVAY22qJ3/Acfbjv376XNqi hhBm2MZ3kpKV9zN0vCB3SqjraYSygTZpD/IG/FnuZG7c2aHyq2c7/CeK8 dXleSJK6uE0SfXrWOX8KtPjEEqXaan1KxwT8Dj9npQu52yKtzjkqXD4xj 0=; X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71728873" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 03 Apr 2012 16:11:52 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q33GBqNS019624; Tue, 3 Apr 2012 16:11:52 GMT Message-Id: <21625A10-BB1A-493B-9FF8-479ADEEED598@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 12:11:52 -0400 References: <76369CE4-1C1C-4947-99FC-BFF190D66CC2@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:11:59 -0000 My point is that DLEP ALREADY does that - it ALREADY uses just 1 TLV code point from the 5444 perspective. At least I believe it does. Please show me where I'm wrong. And as far as the encoding, OK - I think the benefit is minimal. But if the encoding requires us to "pretend" that addresses aren't in different families when they really are, then it's time for RFC 5444 bis. Regards, Stan On Apr 3, 2012, at 12:04 PM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 18:01, Stan Ratliff wrote: >> Yeah, I'll add my voice to that as well. We tried to get DLEP to >> the point >> where it only uses 1 RFC 5444 message TLV. If that's not the case, >> then I >> need to understand. >> >> Regards, >> Stan > > We can still do this, we just need a TLV to carry the "order" of the > DLEP message. > > I see the most advantage of using "only" RFC 5444 encoding that you > can use a common parser/generator for DLEP. At the moment DLEP is not > using RFC 5444... its just a wrapper around a partly proprietary > encoding. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From Chris.Dearlove@baesystems.com Tue Apr 3 09:14:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934A11E811A for ; Tue, 3 Apr 2012 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3vdEi4FR1rP for ; Tue, 3 Apr 2012 09:14:17 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05411E8116 for ; Tue, 3 Apr 2012 09:14:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199116392" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 17:14:16 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33GEDxf022487; Tue, 3 Apr 2012 17:14:16 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:14: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 17:14:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RsveexEcQSrblRKGXBBjxiXhWjQAAKueA References: From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 16:14:14.0933 (UTC) FILETIME=[D0412C50:01CD11B4] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:14:18 -0000 Address compression (head and tails) was certainly designed for common IPv4= and IPv6 scenarios. Any gain with MAC addresses would be, as Stan indicate= s, fortuitous. But going back to Henning's model of all have MAC addresses, some have IPv4= /6 addresses, is this correct? Do all entities have a MAC address? Do we ge= t both IPv4 and IPv6 addresses together? How many addresses is typical/maxi= mal? (there's a lot of difference designing for one, occasionally two, than= for normal average is half a dozen or more). But if it's MAC address always etc. then Henning's proposal makes some sens= e in that it allows parsing to associate information with entities, entitie= s defined by MAC address, less painful than some alternatives. It gets no a= ddress compression. If all entities had an IP address then using that as th= e address block and MAC addresses as a TLV would work more cleanly (especia= lly if there are subnet lengths). If there were lots of entities then there= are ideas that could save space, but (not having counted bytes) I suspect = the saving is too small for the complexity. (And I also don't see a 5444bis= - something that would be painful for other reasons - helping either in th= e case of small numbers of addresses, some with IP addresses, some without.= ) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 03 April 2012 17:01 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I think MAC address compression is a red herring. You can't assume a =20 single vendor, so I doubt whether that will be usefull. Also, remember =20 that DLEP traffic (99% of it, anyway) only occurs on the link between =20 the router and its "local" radio. Regards, Stan On Apr 3, 2012, at 11:57 AM, Henning Rogge w > On Tue, Apr 3, 2012 at 17:52, Darryl Satterwhite =20 > wrote: >> Henning, >> >> I'm beginning to get lost with what you are proposing as an =20 >> alternative to >> the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For us >> non-RFC5444 experts, can you clarify? > I talked with Rick Taylor today quite a lot to understand the need of > IPv4/IPv6 and I think we got to a better solution than my earlier > proposal. > > The new idea is to set the address length field in the message header > to 6, so we can put neighbor MAC addresses into the message in a > proper way. We then can add metrics as TLVs to this addresses. We can > also compress the MAC addresses as described in RFC 5444. > > If the Mac-Layer had additional knowledge about IPv4 and IPv6 address > of the interface of the other side, we put this in a special address > TLV attached to the MAC address. This way we don't waste space with > padding. > > This "add IP as TLV to a MAC address" is special for DLEP, but so is > layer-3 knowledge in layer-2 radios. > > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Apr 3 09:16:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B70621F858A for ; Tue, 3 Apr 2012 09:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrhgFwfsdtU3 for ; Tue, 3 Apr 2012 09:16:04 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 97AB821F855F for ; Tue, 3 Apr 2012 09:16:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199116781" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 17:16:03 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33GG3go023606; Tue, 3 Apr 2012 17:16:03 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:16:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 17:16:01 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Rq2OfaISot8T6QI2MP/drsTS9ZAABMw5gAACmnzMAAInmEA== References: From: "Dearlove, Christopher (UK)" To: "Darryl Satterwhite" , "Stan Ratliff" , "Rick Taylor" X-OriginalArrivalTime: 03 Apr 2012 16:16:03.0105 (UTC) FILETIME=[10BAE910:01CD11B5] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:16:05 -0000 I said I'd skimmed, I appear to have skimmed too lightly in this case. Apol= ogies. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Darryl Satterwhite [mailto:dsatterw@cisco.com]=20 Sent: 03 April 2012 17:00 To: Dearlove, Christopher (UK); Stan Ratliff; Rick Taylor Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On 4/3/12 11:50 AM, "Dearlove, Christopher (UK)" wrote: > I really need to read DLEP properly. But I just quickly skimmed trying to= look > at sub-TLVs. And I don't see that term used. I do see a lot of normal loo= king > TLVs in a TLV block. But what I need to look more carefully at is address= es > and their handling. >=20 > What isn't correct, at least for normal use of 5444, is packets. As defi= ned > in 5444/5498, DLEP doesn't get to define a packet, it just defines one o= r > more messages. Packets are owned by 5444 and allowed to include messages = of > different types, from different protocols, piggybacked together. >=20 > The more precious resource is messages. There are only 256 (minus > private/experimental) of these, and DLEP appears to be rather profligate = with > these, claiming 17. NHDP and OLSRv2 manage with one apiece. I don't belie= ve 17 > can be justified, and that (agreed, at a cost of a small number of extra > bytes) this could, and should, be reduced a lot. I don't believe this to be the case. We, I thought, were only using 1 to specify the it's a DLEP message and all other type definitions are done within the context of a DLEP message. This was something that we did as par= t of recommendations that were made when we submitted DLEP version 1. Darryl Satterwhite Cisco Systems ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Tue Apr 3 09:17:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49E011E8134 for ; Tue, 3 Apr 2012 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygovW5svJjHd for ; Tue, 3 Apr 2012 09:17:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id E103B11E80EE for ; Tue, 3 Apr 2012 09:17:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="199117214" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 03 Apr 2012 17:17:56 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q33GHtLX024372; Tue, 3 Apr 2012 17:17:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 17:17:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 17:17:54 +0100 Message-ID: In-Reply-To: <21625A10-BB1A-493B-9FF8-479ADEEED598@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RtIOedI5Z0DpHTKGW99odrVgnhQAAKm0Q References: <76369CE4-1C1C-4947-99FC-BFF190D66CC2@cisco.com> <21625A10-BB1A-493B-9FF8-479ADEEED598@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 03 Apr 2012 16:17:55.0493 (UTC) FILETIME=[53B7F550:01CD11B5] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:17:57 -0000 That's also suggesting a mis-skimming by me. But as I've said, what I'd rat= her do is start from "this is what we are trying to communicate" and design= from there. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 03 April 2012 17:12 To: Henning Rogge Cc: Darryl Satterwhite; Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- My point is that DLEP ALREADY does that - it ALREADY uses just 1 TLV =20 code point from the 5444 perspective. At least I believe it does. =20 Please show me where I'm wrong. And as far as the encoding, OK - I =20 think the benefit is minimal. But if the encoding requires us to =20 "pretend" that addresses aren't in different families when they really =20 are, then it's time for RFC 5444 bis. Regards, Stan On Apr 3, 2012, at 12:04 PM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 18:01, Stan Ratliff wrote: >> Yeah, I'll add my voice to that as well. We tried to get DLEP to =20 >> the point >> where it only uses 1 RFC 5444 message TLV. If that's not the case, =20 >> then I >> need to understand. >> >> Regards, >> Stan > > We can still do this, we just need a TLV to carry the "order" of the > DLEP message. > > I see the most advantage of using "only" RFC 5444 encoding that you > can use a common parser/generator for DLEP. At the moment DLEP is not > using RFC 5444... its just a wrapper around a partly proprietary > encoding. > > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Tue Apr 3 09:23:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F5A11E8151 for ; Tue, 3 Apr 2012 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH33+lPUeXIW for ; Tue, 3 Apr 2012 09:23:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91C11E8154 for ; Tue, 3 Apr 2012 09:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5288; q=dns/txt; s=iport; t=1333470188; x=1334679788; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=A4seE/1wPcRz9otQqz2o7kbCl/WWT7n2qeaVBaI0los=; b=EUZaOU/XmAWf+fd4i8h7Q90gjV4DgF+swz5poQnyo/N9cR706z1/2GJ9 Ah0jPdeMzfNKkFk4CvXdycx0VJxNLWn+bgLm1lvtQITO2jeUGLablqt9O AnX3nGT2LMz528ZtZSBxI9nDgWM90mRI0WuRTIwf0Rw9OT3+jnBACgwlr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ8ie0+tJXG9/2dsb2JhbABFuASBB4IJAQEBAwEBAQEPASUCGxYBAgMFAwUHBAsRBAEBAScHJx8JCAYTGweHYgULm2qef4sCDIR1YwSVY45HgWmDA4E4CA X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="68708931" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 03 Apr 2012 16:23:06 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33GN60u006813; Tue, 3 Apr 2012 16:23:06 GMT Message-Id: <2E26F86B-6D29-46BE-B38E-F4E18D89A349@cisco.com> From: Stan Ratliff To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 12:23:05 -0400 References: X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:23:13 -0000 The problem with that approach is what I mentioned earlier - Neighbors have an associated MAC, but the DLEP "Peers" (e.g. the radio itself) doesn't, and therefore, doesn't fit the model. Regards, Stan On Apr 3, 2012, at 12:14 PM, Dearlove, Christopher (UK) wrote: > Address compression (head and tails) was certainly designed for > common IPv4 and IPv6 scenarios. Any gain with MAC addresses would > be, as Stan indicates, fortuitous. > > But going back to Henning's model of all have MAC addresses, some > have IPv4/6 addresses, is this correct? Do all entities have a MAC > address? Do we get both IPv4 and IPv6 addresses together? How many > addresses is typical/maximal? (there's a lot of difference designing > for one, occasionally two, than for normal average is half a dozen > or more). > > But if it's MAC address always etc. then Henning's proposal makes > some sense in that it allows parsing to associate information with > entities, entities defined by MAC address, less painful than some > alternatives. It gets no address compression. If all entities had an > IP address then using that as the address block and MAC addresses as > a TLV would work more cleanly (especially if there are subnet > lengths). If there were lots of entities then there are ideas that > could save space, but (not having counted bytes) I suspect the > saving is too small for the complexity. (And I also don't see a > 5444bis - something that would be painful for other reasons - > helping either in the case of small numbers of addresses, some with > IP addresses, some without.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf Of Stan Ratliff > Sent: 03 April 2012 17:01 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > I think MAC address compression is a red herring. You can't assume a > single vendor, so I doubt whether that will be usefull. Also, remember > that DLEP traffic (99% of it, anyway) only occurs on the link between > the router and its "local" radio. > > Regards, > Stan > > On Apr 3, 2012, at 11:57 AM, Henning Rogge w > >> On Tue, Apr 3, 2012 at 17:52, Darryl Satterwhite >> wrote: >>> Henning, >>> >>> I'm beginning to get lost with what you are proposing as an >>> alternative to >>> the way the DLEP reports neighbor addresses (MAC, IPv4, IPv6). For >>> us >>> non-RFC5444 experts, can you clarify? >> I talked with Rick Taylor today quite a lot to understand the need of >> IPv4/IPv6 and I think we got to a better solution than my earlier >> proposal. >> >> The new idea is to set the address length field in the message header >> to 6, so we can put neighbor MAC addresses into the message in a >> proper way. We then can add metrics as TLVs to this addresses. We can >> also compress the MAC addresses as described in RFC 5444. >> >> If the Mac-Layer had additional knowledge about IPv4 and IPv6 address >> of the interface of the other side, we put this in a special address >> TLV attached to the MAC address. This way we don't waste space with >> padding. >> >> This "add IP as TLV to a MAC address" is special for DLEP, but so is >> layer-3 knowledge in layer-2 radios. >> >> Henning Rogge >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From hrogge@googlemail.com Tue Apr 3 09:26:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A911E8164 for ; Tue, 3 Apr 2012 09:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UX+NAUq53PE for ; Tue, 3 Apr 2012 09:26:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5372711E8161 for ; Tue, 3 Apr 2012 09:26:16 -0700 (PDT) Received: by lagj5 with SMTP id j5so5567034lag.31 for ; Tue, 03 Apr 2012 09:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mV2CjkrRFY67osv/SNK/IT0dCpzDxINMPKRtF0QndeE=; b=aoFdD23s22dZGnZ4BYAMvQrxDFH5Ndro/JgLV2uyGGwMjLQirKDOZcddLd6EqzVZtJ c/zG8iUV1cl6MSVvL4qp4t3V4PQP5OXtbVqt4uQOL5ZalONXDeJdJfzeky5DlFL0Axof TBXUwaE5i0pEuGYDprsIv22QFG9lmr6ptuxHWwhMMqaJXzqhlNni6yHpkS41fETrWYub gugzhKunFmQpc+G3MyTIVTWYRWCovm7ZAE7vjCPJHu2fD5E6EHcRV/rf/Dxgf2b9kpPK adI1xM9+pQE2ZeX7OgHOjII/WhL9sjgH3W/uvPHWlJ4pS8G5lFEFt1EgDtcNK3i/Wc5n AY7A== Received: by 10.152.103.134 with SMTP id fw6mr3124070lab.20.1333470375146; Tue, 03 Apr 2012 09:26:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 09:25:52 -0700 (PDT) In-Reply-To: <2E26F86B-6D29-46BE-B38E-F4E18D89A349@cisco.com> References: <2E26F86B-6D29-46BE-B38E-F4E18D89A349@cisco.com> From: Henning Rogge Date: Tue, 3 Apr 2012 18:25:52 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:26:17 -0000 On Tue, Apr 3, 2012 at 18:23, Stan Ratliff wrote: > The problem with that approach is what I mentioned earlier - Neighbors have > an associated MAC, but the DLEP "Peers" (e.g. the radio itself) doesn't, and > therefore, doesn't fit the model. > > Regards, > Stan Why does the radio itself has no MAC? I am certain it has a MAC, it might even make sense to use this MAC as the "server-id". Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From william.d.ivancic@nasa.gov Tue Apr 3 10:05:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C65F21F8724 for ; Tue, 3 Apr 2012 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM2oJB750RVT for ; Tue, 3 Apr 2012 10:05:37 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDA721F85F7 for ; Tue, 3 Apr 2012 10:05:37 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B4AC6A8679; Tue, 3 Apr 2012 12:05:36 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q33H5aof027683; Tue, 3 Apr 2012 12:05:36 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 3 Apr 2012 12:05:36 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Rick Taylor Date: Tue, 3 Apr 2012 12:05:35 -0500 Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Ru/yRXxXHiAOqRKq2cp8OGVz/gA== Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1035AB49B@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035AB49B@SUKNPT8106.cogent-dsn.local> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-03_06:2012-04-03, 2012-04-03, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:05:38 -0000 >=20 > Asymmetric links are a problem, but I think the simplest way to approach > them might be for each neighbour to report its relevant metric for > inbound only - I mean the metric value the neighbour can receive, i.e. > how much data can flow out of the receiving router, "receiver-egress". > I have described this poorly, I'm happy to try my hand at ASCII art if > it will help. Very nice if you every need to do ASCII art. http://www.jave.de/ Of course, other drawing packages and post URL to some web site works too. - Will From dsatterw@cisco.com Tue Apr 3 10:30:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB121F866D for ; Tue, 3 Apr 2012 10:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.457 X-Spam-Level: X-Spam-Status: No, score=-8.457 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMzO7AehAO9k for ; Tue, 3 Apr 2012 10:30:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F2E8021F8644 for ; Tue, 3 Apr 2012 10:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=2110; q=dns/txt; s=iport; t=1333474234; x=1334683834; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=1tVMM2iEn0S6ixmxdJSdbvrfAkA+tUW8jaKURwHd3fM=; b=eI7tSrIfMIPj9rRQK6iZdFjuB7nWN+o1gO5ieFoBRzeKwzG4x+xTm9bE 04rtoAlZ34aMVPByX6qHR2WQY5EfVD+5SBl35iYf+z/8Ew0F1HcCxDh1c 4sY7nVmetXDVk/cc7dtuKIIvb741pPwrG9VPI0Qa63D4z2j4x917naVY2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4IALQye0+tJXG+/2dsb2JhbAA7CrgGAoEHggkBAQEDARIBJwIBLwoDBQ0BCIEdAQEEAQ0FIodiBZtbnnqKfoVoBJVjjkeBaYMD X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71740489" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 03 Apr 2012 17:30:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q33HUWwO026507; Tue, 3 Apr 2012 17:30:33 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 12:30:33 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 17:30:32 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 13:30:32 -0400 From: Darryl Satterwhite To: "Dearlove, Christopher (UK)" , Stan Ratliff , Henning Rogge Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RsveexEcQSrblRKGXBBjxiXhWjQAAKueAAAL1S6M= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 17:30:33.0357 (UTC) FILETIME=[79353BD0:01CD11BF] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:30:34 -0000 A DLEP neighbor always has a MAC address in the DLEP messages that correspond to "neighbor up", "neighbor down", and "neighbor metric" exchanges to uniquely identify the neighbor that the radio has discovered. IPv4 and Ipv6 addresses are optional in the "neighbor up" exchange to speed layer 3 address discovery for the layer 3 routing protocols when radios have that knowledge. Without these optional layer 3 address TLV, address discovery occurs using the normal ARP and ND mechanisms. So a neighbor up event will have a MAC address and one or all of the following: 1) IPv4 address 2) IPv6 Link Local 3) 1 or more IPv6 Global addresses Darryl Satterwhite Cisco Systems On 4/3/12 12:14 PM, "Dearlove, Christopher (UK)" wrote: > Address compression (head and tails) was certainly designed for common IPv4 > and IPv6 scenarios. Any gain with MAC addresses would be, as Stan indicates, > fortuitous. > > But going back to Henning's model of all have MAC addresses, some have IPv4/6 > addresses, is this correct? Do all entities have a MAC address? Do we get both > IPv4 and IPv6 addresses together? How many addresses is typical/maximal? > (there's a lot of difference designing for one, occasionally two, than for > normal average is half a dozen or more). > > But if it's MAC address always etc. then Henning's proposal makes some sense > in that it allows parsing to associate information with entities, entities > defined by MAC address, less painful than some alternatives. It gets no > address compression. If all entities had an IP address then using that as the > address block and MAC addresses as a TLV would work more cleanly (especially > if there are subnet lengths). If there were lots of entities then there are > ideas that could save space, but (not having counted bytes) I suspect the > saving is too small for the complexity. (And I also don't see a 5444bis - > something that would be painful for other reasons - helping either in the case > of small numbers of addresses, some with IP addresses, some without.) From hrogge@googlemail.com Tue Apr 3 10:48:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57AA11E8075 for ; Tue, 3 Apr 2012 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkukQhPB-Am for ; Tue, 3 Apr 2012 10:48:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1550911E8072 for ; Tue, 3 Apr 2012 10:48:31 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1280543eaa.31 for ; Tue, 03 Apr 2012 10:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=obw/SaL0QpaUtRe908AwQycq8liTsyrQGNCHBIYgY4c=; b=kBEONhwsioSxsK/E9hG0XKUCpfLpWqHBgKt945pR8jrOw2DT1WFr3lGNJcksZ1wOum ELsNz8ty39Ou/r1pHoOTHt2SgcVlnLyRMLI0PvkBDbitFf8MKNGSmrtulAL8hn2zgjmH MBUxPhAmj/GkbipctQTL2upNiWyvMtHfWsd2qwaVvizsL9OnmfzcSgHGXyiEIseM+D0O C/DtgftPBrkwTrpkgypEdX+P9rgXXn4zCNNiX61OG0KBABMKFisxh3SmaTb+/k+wi9Ua YQZFVM/gpYD4aUX1cdcxvY8uD+SE5TnogqBXUh/PbzCal/NGbj8p/H4vv4umKXGkTNXf zLzg== Received: by 10.152.112.161 with SMTP id ir1mr10466551lab.13.1333475311086; Tue, 03 Apr 2012 10:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 10:48:10 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 3 Apr 2012 19:48:10 +0200 Message-ID: To: Darryl Satterwhite Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:48:32 -0000 On Tue, Apr 3, 2012 at 19:30, Darryl Satterwhite wrote: > So a neighbor up event will have a MAC address and one or all of the > following: > 1) IPv4 address > 2) IPv6 Link Local > 3) 1 or more IPv6 Global addresses Does a Neighbor Up event needs to contain any IP address? I assume the "just the mac" would be a valid option, right? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From dsatterw@cisco.com Tue Apr 3 10:57:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAD311E8074 for ; Tue, 3 Apr 2012 10:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.472 X-Spam-Level: X-Spam-Status: No, score=-8.472 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4pwyI-xl8Jo for ; Tue, 3 Apr 2012 10:57:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A50DB11E8073 for ; Tue, 3 Apr 2012 10:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=871; q=dns/txt; s=iport; t=1333475837; x=1334685437; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=lQ0KJBfcRm+FsMRqJClNfSvI7AxFCtmhjnnupMCvMCo=; b=NJRtG1fYDSJD1pHpHEyTZ4QaEkSvyJwl0hTn3NZbFRCzWKBQgZzOyMTM MGHU73011VTVhFAzrmg7N0hXFYcOMV/jxyub6tDT1gBnnY0nDtNILMxoh SdteMh7HX5G6MJ3cZvazP/u4h/t+WJHvfiQciH18eRAwYzL8AYqa2eco/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0IADs5e0+tJV2a/2dsb2JhbABFuAYCgQeCCQEBAQMBEgEnAgE8BQ0BCA4KgQUBAQQOBSKHYgWbUp57ig6GWASVY45HgWmDAw X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71549510" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 03 Apr 2012 17:57:17 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q33HvHeE017553; Tue, 3 Apr 2012 17:57:17 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 12:57:17 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.137]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 Apr 2012 17:57:16 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 03 Apr 2012 13:57:16 -0400 From: Darryl Satterwhite To: Henning Rogge Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0RwzR1ZQjp1iqdHk6oJ/r7aUPGoA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Apr 2012 17:57:17.0068 (UTC) FILETIME=[35181CC0:01CD11C3] Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:57:18 -0000 On 4/3/12 1:48 PM, "Henning Rogge" wrote: > On Tue, Apr 3, 2012 at 19:30, Darryl Satterwhite wrote: >> So a neighbor up event will have a MAC address and one or all of the >> following: >> 1) IPv4 address >> 2) IPv6 Link Local >> 3) 1 or more IPv6 Global addresses > > Does a Neighbor Up event needs to contain any IP address? I assume the > "just the mac" would be a valid option, right? Yes that is correct, and in most cases layer 3 addresses will NOT be present. But to reiterate what Stan mentioned earlier, there is also a peer session between the radio and router which exchanges global information and maintains heartbeats for local client(radio) to server(router) sanity. Current implementations use Ethernet so adding a MAC address to peer messages is unnecessary. > > Henning Rogge From hrogge@googlemail.com Tue Apr 3 11:26:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE92D21F85CC for ; Tue, 3 Apr 2012 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um-WhLIyPTo1 for ; Tue, 3 Apr 2012 11:26:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1421F8602 for ; Tue, 3 Apr 2012 11:26:27 -0700 (PDT) Received: by lagj5 with SMTP id j5so1772lag.31 for ; Tue, 03 Apr 2012 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WaJxJIW3E/y+UtSJLBzr5ZvsfhEX+9I12IdzgzQCNb4=; b=B58ihpeV2K8JC9/PrFvUamHSkLmGGnFln9jVuRm3doTbz9HiluMOUPK9mLUtEJ+OkX e3iVz1S97TEvSFD3hSoJPhrpvaVmsY1sFHHQw87jHD0WDJaptgfOsvTyDz3IG4YxGQ7V PV+W+Ky7PvgGZjiiJQcIc0yVzpQabGqAuVTX6PNEFSURKHS9bTtzKAHF0NFwpx5NK6da VhGIZN1/ftqgPj9ZcdvmJSsnIE3qjzAHeBybRglpkqqcENDTdSjHIyG70Jtvf2Ey6Cxy DudRAZxqSHgtbsHfL/+V3aWj4FwAD/dhyVTvujIPSp2F5cluaHr9xWNP1tN4V8Y8of7e zlZg== Received: by 10.152.131.9 with SMTP id oi9mr15272077lab.6.1333477586594; Tue, 03 Apr 2012 11:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 11:26:05 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 3 Apr 2012 20:26:05 +0200 Message-ID: To: Darryl Satterwhite Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 18:26:33 -0000 On Tue, Apr 3, 2012 at 19:57, Darryl Satterwhite wrote: >> Does a Neighbor Up event needs to contain any IP address? I assume the >> "just the mac" would be a valid option, right? > Yes that is correct, and in most cases layer 3 addresses will NOT be > present. Just wanted to be sure, thanks. > But to reiterate what Stan mentioned earlier, there is also a peer session > between the radio and router which exchanges global information and > maintains heartbeats for local client(radio) to server(router) sanity. > Current implementations use Ethernet so adding a MAC address to peer > messages is unnecessary. Not necessarily. The communication from the radio might get the MAC of the ethernet device, not the one of the radio interface. But if the transport protocol guarantees the right MAC, it will be unnecessary to add the MAC to the DLEP message. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Tue Apr 3 11:55:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B334B11E80E0 for ; Tue, 3 Apr 2012 11:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbp-1AZlRuy0 for ; Tue, 3 Apr 2012 11:55:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E273911E8075 for ; Tue, 3 Apr 2012 11:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1958; q=dns/txt; s=iport; t=1333479315; x=1334688915; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ytQTRfwl/gYqRNz869XO5VFsbJPfEg8Iu5CUIETTX4E=; b=G/XgUBveWpuzhtwcBN9Rsn6ofmZ0PehiuPI/v//cZnGp4OXXopMursmw DtZunzKF7iW8wpcGEIUFmAehkJJO5IoCNlXnoelyl59vKJwukH1DuBlJa 9zeFruovwaJOxhrAw/P8czgtPq91nJEkybmtHTwC27czwiw7NCbsN0C/C M=; X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71804404" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2012 18:55:14 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q33ItEA5022770; Tue, 3 Apr 2012 18:55:14 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 14:55:14 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 18:55:15 -0000 I'm not necessarily OK with the notion that a Neighbor Up will "normally" be just a MAC. With the radio implementation we have right now, that's the case. But I would hope as DLEP matures, and more implementations come online, then there should be more of a use for Layer 3 addressing on the Neighbor Up. Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we worked to get DLEP running over RFC 5444 was for transport independence. So now we're going to *assume* a Layer 2 MAC address? What if the implementation is a radio card in a chassis - I can see using a 5444 packet transfer, but doing that over some Bus-passing scheme. I don't want to create "phantom" MAC addresses for that... Regards, Stan On Apr 3, 2012, at 2:26 PM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 19:57, Darryl Satterwhite > wrote: >>> Does a Neighbor Up event needs to contain any IP address? I assume >>> the >>> "just the mac" would be a valid option, right? >> Yes that is correct, and in most cases layer 3 addresses will NOT be >> present. > Just wanted to be sure, thanks. > >> But to reiterate what Stan mentioned earlier, there is also a peer >> session >> between the radio and router which exchanges global information and >> maintains heartbeats for local client(radio) to server(router) >> sanity. >> Current implementations use Ethernet so adding a MAC address to peer >> messages is unnecessary. > > Not necessarily. The communication from the radio might get the MAC of > the ethernet device, not the one of the radio interface. But if the > transport protocol guarantees the right MAC, it will be unnecessary to > add the MAC to the DLEP message. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From james.huy.nguyen@gmail.com Tue Apr 3 12:09:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3884A21F864F for ; Tue, 3 Apr 2012 12:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwi9uUZsj0Lj for ; Tue, 3 Apr 2012 12:09:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1912121F863E for ; Tue, 3 Apr 2012 12:09:47 -0700 (PDT) Received: by yenm5 with SMTP id m5so31212yen.31 for ; Tue, 03 Apr 2012 12:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FnNk4WaLS9VosQ2P4fXPPDDt5h8XPv61UjnAYUF2L9A=; b=BuKk1b0Oux6+cKvjBVKeSidEVJOc/S90LT11kgu4GGQHMdWhUqGts/Cd57XuL7fOPQ +cYZn5la6/SeTsBNqs0x+wboUSz+8NulCkRIF4wXg4kV3bDW9nhLj5kwbJgNjMo344kf sjBo3CaiffKapvXTaWdwqgG6Rqa3Y7Qn0+xxetCCAFldMxwAG1WGZFukMP2WkmWXZ/s0 A8DYeBeG96BwSIlfD97c80x9XKulbzXbO1xfSJ7imU3BLWeWAgOyLipKaXp7TZ9Imryz 7HxiS46DuZWOFOqoYlKkGsMXpgunAVDTmxn88bj+dYrUEYyFF5kRFj772gzFNF8OZEab Z3gg== MIME-Version: 1.0 Received: by 10.236.154.233 with SMTP id h69mr12063104yhk.86.1333480187668; Tue, 03 Apr 2012 12:09:47 -0700 (PDT) Received: by 10.101.52.7 with HTTP; Tue, 3 Apr 2012 12:09:47 -0700 (PDT) Date: Tue, 3 Apr 2012 15:09:47 -0400 Message-ID: From: James Nguyen To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf303f69c2e6aaac04bccb0c31 Subject: [manet] New Version Notification for draft-nguyen-manet-ecds-mib-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:09:49 -0000 --20cf303f69c2e6aaac04bccb0c31 Content-Type: text/plain; charset=UTF-8 http://datatracker.ietf.org/doc/draft-nguyen-manet-ecds-mib/ -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, April 03, 2012 9:49 AM To: Nguyen, James H CIV (US) Cc: Cole, Robert G CIV USARMY CERDEC (US) Subject: New Version Notification for draft-nguyen-manet-ecds-mib-00.txt A new version of I-D, draft-nguyen-manet-ecds-mib-00.txt has been successfully submitted by James H. Nguyen and posted to the IETF repository. Filename: draft-nguyen-manet-ecds-mib Revision: 00 Title: Definition of Managed Objects for the Manet Essential Connected Dominating Set (E-CDS) Process Creation date: 2012-04-03 WG ID: Individual Submission Number of pages: 15 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Essential Connected Dominating Set (E-CDS) Process for Mobile Ad-Hoc Networks (MANETs). The ECDS-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The IETF Secretariat -- James Nguyen Email: james.huy.nguyen@gmail.com --20cf303f69c2e6aaac04bccb0c31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


http://datatracke= r.ietf.org/doc/draft-nguyen-manet-ecds-mib/=C2=A0



-----Origin= al Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, April 03, 2012 9:49 AM
To: Nguyen, James H CIV (US)
Cc: Cole, Robert G CIV USARMY CERDEC (US)
Subject: New Version Notification for draft-nguyen-manet-ecds-mib-00.txt

=C2=A0

A new version of I-D, draft-nguyen-manet-ecds-mib= -00.txt has been successfully submitted by James H. Nguyen and posted to the IETF repository.

=C2=A0

Filename:=C2=A0=C2=A0=20 draft-nguyen-manet-ecds-mib

Revision:=C2=A0=C2=A0 00

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 Definition of Managed Objects for the Manet Essential Connected Dominating = Set (E-CDS) Process

Creation date:=C2=A0=C2=A0=C2=A0=20 2012-04-03

WG ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 Individual Submission

Number of pages: 15

=C2=A0

Abstract:

=C2=A0=C2=A0 This memo defines a portion of the Management Information Base (MIB)

=C2=A0=C2=A0 for use with network management protocols in the Internet community.

=C2=A0=C2=A0 In particular, it describes objects for configuring aspects of the

=C2=A0=C2=A0 Essential Connected Dominating Set (E-CDS) Process for Mobile Ad-Hoc

=C2=A0=C2=A0 Networks (MANETs).=C2=A0 The ECDS-MIB also reports state information,

=C2=A0=C2=A0 performance metrics, and notifications.=C2=A0 In addition to

=C2=A0=C2=A0 configuration, the additional state and performance information is

=C2=A0=C2=A0 useful to operators troubleshooting multicast forwarding problems.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

=C2=A0

The IETF Secretariat


--
Jam= es Nguyen
Email: james.huy= .nguyen@gmail.com
--20cf303f69c2e6aaac04bccb0c31-- From hrogge@googlemail.com Tue Apr 3 12:14:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6621211E8157 for ; Tue, 3 Apr 2012 12:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS05ORV-DKCY for ; Tue, 3 Apr 2012 12:14:28 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7321C11E80E7 for ; Tue, 3 Apr 2012 12:14:28 -0700 (PDT) Received: by lagj5 with SMTP id j5so53632lag.31 for ; Tue, 03 Apr 2012 12:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d770j7Ijt3+ny2283nwzpcoCui2sC+o1I++LN3GWAKc=; b=sxNpwB17tUHEBsn5yCLCWHozMJ4IBM0VGx3MfMlKx7zYkocDOzMyJlG4WX0iwrWe6o /HweQlbtG/ASwkOglB3JujjU6brFp+SGeb4S30R4Udg7hT2BMPiwlsaeH9GReDcpuxlQ M/aHHUBSgdAUF4EHpx7TDUo19OyOK3sxrI4VG54f0YO1Jhfxrkultwmy4RUCniMn3Ujy ZdBgBOwBASTPZp7Ou8/+1R2HmX62/5dsg0C27qB3COPRK4gumHWlJRYEx1MKKtRHHARz DuWZ87fWvfycJ7eSJSpMhxwoF1Lpn4r1q05R6lIFST26mI2qkRjwjyDNrNLUDBfdYm/6 Ag1A== Received: by 10.152.103.239 with SMTP id fz15mr15338928lab.42.1333480467321; Tue, 03 Apr 2012 12:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 12:14:07 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 3 Apr 2012 21:14:07 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:14:29 -0000 On Tue, Apr 3, 2012 at 20:55, Stan Ratliff wrote: > I'm not necessarily OK with the notion that a Neighbor Up will "normally" be > just a MAC. With the radio implementation we have right now, that's the > case. But I would hope as DLEP matures, and more implementations come > online, then there should be more of a use for Layer 3 addressing on the > Neighbor Up. If the DLEP-equipped radio just bridges its interface to the datapath towards the users OS, it doesn't need to have an IP. The user of the radio can set the IP on his side of the connection. > Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we > worked to get DLEP running over RFC 5444 was for transport independence. So > now we're going to *assume* a Layer 2 MAC address? What if the > implementation is a radio card in a chassis - I can see using a 5444 packet > transfer, but doing that over some Bus-passing scheme. I don't want to > create "phantom" MAC addresses for that... As long as the radio interface has a MAC it use to set up the data path with the user I am fine. The control plane between the DLEP connection of radio and router does not necessarily need a MAC. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Tue Apr 3 12:26:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D1311E8104 for ; Tue, 3 Apr 2012 12:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2nDOrIsm1Aw for ; Tue, 3 Apr 2012 12:26:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9CE11E81A6 for ; Tue, 3 Apr 2012 12:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2072; q=dns/txt; s=iport; t=1333481182; x=1334690782; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=0hDzPxYlUgdhf5siZrm7jN4wblQN8tIf+DBhfrgutsI=; b=SB3ar1D+vKkEuVXEvD4LAAMFt9Dg7yjCXvq75Pj/DlpY29S5TCP01bA9 HzanBY48U0X8fZr79gCjbUJuXxiIlwP0l4W0PTiBPsEDg/FvkJOdplWsq nDlCXemNgNTS23P3ovHWKBDYSj+BfGQLoCKW/tWUIblvGGvJHiSJa0lVw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPxNe0+tJXHB/2dsb2JhbABFuBGBB4IJAQEBAwEBAQEPASUCNAsFCwsOCi4nMAYKCSKHYgULmyueeQSQA2MElWOOR4FpgwM X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="71799595" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 03 Apr 2012 19:26:22 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q33JQL4I006828; Tue, 3 Apr 2012 19:26:21 GMT Message-Id: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Apr 2012 15:26:21 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:26:33 -0000 One of us has this backwards.... and at this point, it's probably me. ;-) On Apr 3, 2012, at 3:14 PM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 20:55, Stan Ratliff wrote: >> I'm not necessarily OK with the notion that a Neighbor Up will >> "normally" be >> just a MAC. With the radio implementation we have right now, that's >> the >> case. But I would hope as DLEP matures, and more implementations come >> online, then there should be more of a use for Layer 3 addressing >> on the >> Neighbor Up. > If the DLEP-equipped radio just bridges its interface to the datapath > towards the users OS, it doesn't need to have an IP. The user of the > radio can set the IP on his side of the connection. > What? The IP addresses I'm referring to are the ones on the *far end* of the connection - the addresses of the neighbor. Bridging to the datapath doesn't matter. >> Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons >> we >> worked to get DLEP running over RFC 5444 was for transport >> independence. So >> now we're going to *assume* a Layer 2 MAC address? What if the >> implementation is a radio card in a chassis - I can see using a >> 5444 packet >> transfer, but doing that over some Bus-passing scheme. I don't want >> to >> create "phantom" MAC addresses for that... > > As long as the radio interface has a MAC it use to set up the data > path with the user I am fine. The control plane between the DLEP > connection of radio and router does not necessarily need a MAC. > Again... What? In the environment I'm envisioning, the far-end devices have a MAC. The radios themselves wouldn't. Regards, Stan > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Tue Apr 3 13:01:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9311E8131 for ; Tue, 3 Apr 2012 13:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh9ldqeSiINS for ; Tue, 3 Apr 2012 13:01:09 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6811E80C6 for ; Tue, 3 Apr 2012 13:01:08 -0700 (PDT) Received: by eaaq11 with SMTP id q11so23320eaa.31 for ; Tue, 03 Apr 2012 13:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rM5NXwNIyHUsGRWHe3r4td/KBOIltyhSHmIEmxresig=; b=iu4bpeRp25M5k1+XD6S32G/lZ/G+hSZEGsqtXZmjmE/M/zWrlIbiWEzfHnCvMlcWu7 b6RHmOLyfUvTzSr8ft+bUCIslJ5X9iZNBtD0VZYraLZqQTbUatKlXqVDPQogNTg9Proq oGPpm/OTdNU673P2ZXOXFuNx+/PesYz9HOlTpeAyMLDPF1rDnVjvYnCalioo+AAsQqxn WYjtMTx3up+Lo7mZXoqxbT2qHEnCi3gMjx7U8oRvFf5me+hclHcnTJihoW3uy+EFyAre 6Epggx/zOyp63EXSSi0NBiiN0uzuuMRQZAdgqMTMxcGeIh+FLFV04vXszm0KFGthnQxT Le2w== Received: by 10.14.194.8 with SMTP id l8mr2690643een.123.1333483267832; Tue, 03 Apr 2012 13:01:07 -0700 (PDT) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z47sm77308329een.5.2012.04.03.13.01.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 13:01:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> Date: Tue, 3 Apr 2012 22:01:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlxbsW4xZr0A1CQ1WKxV3BJY8/8+wrbSbCnF+72c1AF9cS/t0IMpnnmgi+zuxvdxZaHcOE9 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:01:11 -0000 Op 3 apr. 2012, om 21:26 heeft Stan Ratliff het volgende geschreven: > One of us has this backwards.... and at this point, it's probably me. = ;-) >=20 > On Apr 3, 2012, at 3:14 PM, Henning Rogge wrote: >=20 >> On Tue, Apr 3, 2012 at 20:55, Stan Ratliff = wrote: >>> I'm not necessarily OK with the notion that a Neighbor Up will = "normally" be >>> just a MAC. With the radio implementation we have right now, that's = the >>> case. But I would hope as DLEP matures, and more implementations = come >>> online, then there should be more of a use for Layer 3 addressing on = the >>> Neighbor Up. >> If the DLEP-equipped radio just bridges its interface to the datapath >> towards the users OS, it doesn't need to have an IP. The user of the >> radio can set the IP on his side of the connection. >>=20 >=20 > What? The IP addresses I'm referring to are the ones on the *far end* = of the connection - the addresses of the neighbor. Bridging to the = datapath doesn't matter. >=20 >=20 >>> Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons = we >>> worked to get DLEP running over RFC 5444 was for transport = independence. So >>> now we're going to *assume* a Layer 2 MAC address? What if the >>> implementation is a radio card in a chassis - I can see using a 5444 = packet >>> transfer, but doing that over some Bus-passing scheme. I don't want = to >>> create "phantom" MAC addresses for that... >>=20 >> As long as the radio interface has a MAC it use to set up the data >> path with the user I am fine. The control plane between the DLEP >> connection of radio and router does not necessarily need a MAC. >>=20 >=20 > Again... What? In the environment I'm envisioning, the far-end devices = have a MAC. The radios themselves wouldn't. Interesting. How works L2 next hop resolving? IP packets have SA and DA, = not a next_hop_IP. L2-headers would have the router MAC addresses. = Modems could spoof router MAC address, or use its own addresses for TA = and RA (transmitter/receiver addresses, like 802.11 WDS). I don't like = spoofed addresses, it brings limitations. Teco >=20 > Regards, > Stan >=20 >=20 >> Henning Rogge >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Tue Apr 3 13:04:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA811E8188 for ; Tue, 3 Apr 2012 13:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+CkUPn5MvuF for ; Tue, 3 Apr 2012 13:04:48 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF33111E80E3 for ; Tue, 3 Apr 2012 13:04:47 -0700 (PDT) Received: by lagj5 with SMTP id j5so113246lag.31 for ; Tue, 03 Apr 2012 13:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lxol0QGFQ7E91kaJxFmRUPSBupqU2m/thBOFys7ziJQ=; b=XnUi7GLcUSNNX9/DB3rUnpo7mf/L9hkey7rxiAspVApQ2TrxLjMWuOYuKgB/gsbpFM 6tO9nFSar1DEaRn1rNImb+qcDYErnQIZDFzvnOqBSXhZXQaKFhuApVp1ZDNzIhxO7X3c C5NBU4Uot2XQ1whJHE53uVs4gNKcjBdC2ic8bTF6dI372447/yC01hRQzQdw4ZS3DM57 N/1XhVopoq1/hggDolqzNqKcsYLjkR7XxZX162OHMoyz6wA3tdxOA928uhPen0IOnHn4 xO8lKw/rkNWBAatFkOjfdYsZC6TlxiBSdvsXySFPA2uvNZ+RKVQN7V1AMWPax00DJ4I3 71BQ== Received: by 10.152.123.229 with SMTP id md5mr15553113lab.34.1333483486654; Tue, 03 Apr 2012 13:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 3 Apr 2012 13:04:25 -0700 (PDT) In-Reply-To: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> References: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> From: Henning Rogge Date: Tue, 3 Apr 2012 22:04:25 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:04:48 -0000 On Tue, Apr 3, 2012 at 21:26, Stan Ratliff wrote: > One of us has this backwards.... and at this point, it's probably me. ;-) maybe just too much work by me with thinking about the radios as a linux device itself. > On Apr 3, 2012, at 3:14 PM, Henning Rogge wrote: > What? The IP addresses I'm referring to are the ones on the *far end* of the > connection - the addresses of the neighbor. Bridging to the datapath doesn't > matter. I think it does matter. If the IP is set on a device outside the DLEP-client equipped radio, DLEP should neither know nor care about the IP in the default case. Unless the IP is configured/sent into the radio too for delivering it with some special MAC-layer. > Again... What? In the environment I'm envisioning, the far-end devices have > a MAC. The radios themselves wouldn't. That depends on the design of the radio. If it contains a full operation system (with a radio driver and an ethernet driver), its might have one MAC address for each of them, just to make it easier to handle them internally. And if the DLEP-client is connected to the DLEP-server via UDP, the radios ethernet will most likely need a MAC for its ethernet too. For the DLEP message content, only the MAC used to transmit data over the radio is important, be it on the far-end device or on the radio. This is a sketch how I would see one possible DLEP-capable radio device based on a normal OS: +-----------------------------------------+ \ | | \ | +--------+ VLAN1 | --+----------------+ bridge +----------------+ | / | radio-if +--------+ ethernet | | / | | | | +---------- | | | | +-------------+ VLAN2 | | | | DLEP-Client +---------------+ | | +-------------+ ethernet | | | +-----------------------------------------+ The VLAN1-ethernet interface has no IP address, its only used to connect on layer-2 directly to the radio interface. The VLAN2-ethernet interface will have an IP address to allow communication between the DLEP-Client (and maybe other radio services) with the outside (could be an IPv6 linklocal based on the ethernets MAC). In this example the other end of the VLAN1-ethernet (in the router device) should have the same MAC as the radio-if, the "bridge" is a kernel module that just copies packets between two interfaces without caring about their MAC. We tested this bridging last week on linux with a standard WIFI-card. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Tue Apr 3 13:29:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138D921F86D1 for ; Tue, 3 Apr 2012 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMahtoSbwwOV for ; Tue, 3 Apr 2012 13:29:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C363021F86D9 for ; Tue, 3 Apr 2012 13:29:51 -0700 (PDT) Received: by eeke51 with SMTP id e51so28178eek.31 for ; Tue, 03 Apr 2012 13:29:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7FkLzWDUSwiuSSJ2m+wdHJtK2aHYrmXpV5hXjoaSNxE=; b=AD4D7+ncnnlkdGscBO+MMdNERdsEBz01qjQ9PdLrc83yj9wkYXb2Q7kHbphnaM40sd dw7P+MgBrV8+OzLzZy3LCY+urTj5huGBYyjgIpg5tdz1iSoWlTM41hcWt7Fx0ZeRc0nn 4+54SKP7cYfc3hDFyOulSvnbzcfvvhCo3h4LmyNVr33CocrbFW6r0GrqJMWLp95gCiZL 4W1Q9jb/ZOzbTeWy8a361Gy7CepPOpTJ+TuhLn59qDNCTmOLQ01BbbVq+nMeX/myQCmG p6Ce5m1HDGHzPCYTGGEJYvgy6ls3NV7d9pdWoX0X28jbXUGEejdPnHjTLcz4AgMBBEkK CLkA== Received: by 10.14.130.202 with SMTP id k50mr2727345eei.113.1333484990915; Tue, 03 Apr 2012 13:29:50 -0700 (PDT) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id d54sm77500887eei.9.2012.04.03.13.29.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 13:29:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 3 Apr 2012 22:29:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F80643A-EE67-40EA-8BCB-075A3C1549D5@inf-net.nl> References: <91DB1555-4FEC-4B9D-9662-7ED66FBDEFD3@cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlh+5lO2esdp8HuvzHYvfadHXNPqsCl4zbB8YL6+rVIAroGl43ogpSw+9laPM+nsl0n+022 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:29:53 -0000 Op 3 apr. 2012, om 22:04 heeft Henning Rogge het volgende geschreven: > On Tue, Apr 3, 2012 at 21:26, Stan Ratliff wrote: >> One of us has this backwards.... and at this point, it's probably me. = ;-) > maybe just too much work by me with thinking about the radios as a > linux device itself. >=20 >> On Apr 3, 2012, at 3:14 PM, Henning Rogge wrote: >=20 >> What? The IP addresses I'm referring to are the ones on the *far end* = of the >> connection - the addresses of the neighbor. Bridging to the datapath = doesn't >> matter. >=20 > I think it does matter. >=20 > If the IP is set on a device outside the DLEP-client equipped radio, > DLEP should neither know nor care about the IP in the default case. > Unless the IP is configured/sent into the radio too for delivering it > with some special MAC-layer. >=20 >> Again... What? In the environment I'm envisioning, the far-end = devices have >> a MAC. The radios themselves wouldn't. >=20 > That depends on the design of the radio. If it contains a full > operation system (with a radio driver and an ethernet driver), its > might have one MAC address for each of them, just to make it easier to > handle them internally. And if the DLEP-client is connected to the > DLEP-server via UDP, the radios ethernet will most likely need a MAC > for its ethernet too. >=20 > For the DLEP message content, only the MAC used to transmit data over > the radio is important, be it on the far-end device or on the radio. >=20 > This is a sketch how I would see one possible DLEP-capable radio > device based on a normal OS: >=20 > +-----------------------------------------+ > \ | | > \ | +--------+ VLAN1 | > --+----------------+ bridge +----------------+ | > / | radio-if +--------+ ethernet | | > / | | | > | +---------- > | | | > | +-------------+ VLAN2 | | > | | DLEP-Client +---------------+ | > | +-------------+ ethernet | > | | > +-----------------------------------------+ >=20 > The VLAN1-ethernet interface has no IP address, its only used to > connect on layer-2 directly to the radio interface. > The VLAN2-ethernet interface will have an IP address to allow > communication between the DLEP-Client (and maybe other radio services) > with the outside (could be an IPv6 linklocal based on the ethernets > MAC). >=20 > In this example the other end of the VLAN1-ethernet (in the router > device) should have the same MAC as the radio-if, the "bridge" is a > kernel module that just copies packets between two interfaces without > caring about their MAC. We tested this bridging last week on linux > with a standard WIFI-card. As I understand, this is cloning. Can be used if only one "other" device is on VLAN1. The bridge function is in fact a repeater: no address learning and no filtering. FYI, cloning-mode or 4-addr-mode should be transparent for the DLEP=20 protocol. The neighbors are the far-end router MAC addresses. It=20 is up to the near DLEP modem to get metrics for each L3 peer behind the far-end DLEP modem. With 4-addr-mode, multiple routers behind a far-end would have same metrics. We might need to support privacy addresses, also at L2. How to=20 support this with DLEP is an open question, I think. Teco >=20 > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Apr 4 02:11:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538FA21F8685 for ; Wed, 4 Apr 2012 02:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiGBJD0WI2g9 for ; Wed, 4 Apr 2012 02:11:57 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 190B121F867F for ; Wed, 4 Apr 2012 02:11:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="199233518" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 10:11:56 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q349Bt5b030458; Wed, 4 Apr 2012 10:11:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 10:11:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 10:11:50 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Ry0+aXucKbVXMTfyADadyDRCtxwAd070Q References: From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 04 Apr 2012 09:11:55.0740 (UTC) FILETIME=[FB54E9C0:01CD1242] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 09:11:58 -0000 It's going to be impossible to make a sensible suggestion as to how DLEP me= ssages should be formatted until all these sorts of questions are answered. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 03 April 2012 19:55 To: Henning Rogge Cc: Darryl Satterwhite; Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I'm not necessarily OK with the notion that a Neighbor Up will =20 "normally" be just a MAC. With the radio implementation we have right =20 now, that's the case. But I would hope as DLEP matures, and more =20 implementations come online, then there should be more of a use for =20 Layer 3 addressing on the Neighbor Up. Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we =20 worked to get DLEP running over RFC 5444 was for transport =20 independence. So now we're going to *assume* a Layer 2 MAC address? =20 What if the implementation is a radio card in a chassis - I can see =20 using a 5444 packet transfer, but doing that over some Bus-passing =20 scheme. I don't want to create "phantom" MAC addresses for that... Regards, Stan On Apr 3, 2012, at 2:26 PM, Henning Rogge wrote: > On Tue, Apr 3, 2012 at 19:57, Darryl Satterwhite =20 > wrote: >>> Does a Neighbor Up event needs to contain any IP address? I assume =20 >>> the >>> "just the mac" would be a valid option, right? >> Yes that is correct, and in most cases layer 3 addresses will NOT be >> present. > Just wanted to be sure, thanks. > >> But to reiterate what Stan mentioned earlier, there is also a peer =20 >> session >> between the radio and router which exchanges global information and >> maintains heartbeats for local client(radio) to server(router) =20 >> sanity. >> Current implementations use Ethernet so adding a MAC address to peer >> messages is unnecessary. > > Not necessarily. The communication from the radio might get the MAC of > the ethernet device, not the one of the radio interface. But if the > transport protocol guarantees the right MAC, it will be unnecessary to > add the MAC to the DLEP message. > > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Wed Apr 4 05:44:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8121F8592 for ; Wed, 4 Apr 2012 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCfMV3aw+qRF for ; Wed, 4 Apr 2012 05:44:20 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2A121F8462 for ; Wed, 4 Apr 2012 05:44:17 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 04 Apr 2012 14:44:14 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 4 Apr 2012 14:44:13 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 14:44:13 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 14:44:13 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 13:44:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2012 13:43:53 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Ry0+aXucKbVXMTfyADadyDRCtxwAd070QAAcOYyA= References: From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 04 Apr 2012 12:44:22.0368 (UTC) FILETIME=[A8E9FE00:01CD1260] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18816.006 X-TM-AS-Result: No--61.398400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:44:26 -0000 I think what might be getting lost in all this discussion about packet = formatting is that all DLEP communication happens between a modem and a = directly connected router. That's a direct wire link, probably = Ethernet. So the whole discussion of compression of packet size is = irrelevant in the grand scheme of things. No DLEP packets are going over = the air or across lossy or multi-hop links. The *only* reason for using packetBB for DLEP is that DLEP is a MANET = RFC, and all MANET RFC's must use packetBB. Discussions about how to fit DLEP messages into packetBB packets is = purely about 'correctness', any discussion about performance is largely = pointless. DLEP would operate perfectly well as an XML SOAP service over HTTP. In = fact, I haven't thought of a good reason why DLEP doesn't use a TCP = connection between router and modem and dispense with heartbeats and = sequence numbers altogether. To answer a previous question, all Neighbour* messages in DLEP refer to = that neighbours MAC address + extra information. My reading of RFC5444 = is that an Address-Block address may be of arbitrary length (i.e. 6 = octets for MAC) avoiding any need to cludge a MAC into an IP address, = but I stand by my first point that this is all just about the = 'prettiness' of the fit of DLEP semantics to the packetBB format. Can we split the DLEP discussions into 2 threads: 1) What is the = information that needs to be communicated between router and modem. 2) = How this information is encapsulated in packetBB/RFC5444? Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Dearlove, Christopher (UK) > Sent: 04 April 2012 10:12 > To: Stan Ratliff; Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > It's going to be impossible to make a sensible suggestion as to how = DLEP > messages should be formatted until all these sorts of questions are > answered. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 03 April 2012 19:55 > To: Henning Rogge > Cc: Darryl Satterwhite; Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I'm not necessarily OK with the notion that a Neighbor Up will > "normally" be just a MAC. With the radio implementation we have right > now, that's the case. But I would hope as DLEP matures, and more > implementations come online, then there should be more of a use for > Layer 3 addressing on the Neighbor Up. >=20 > Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we > worked to get DLEP running over RFC 5444 was for transport > independence. So now we're going to *assume* a Layer 2 MAC address? > What if the implementation is a radio card in a chassis - I can see > using a 5444 packet transfer, but doing that over some Bus-passing > scheme. I don't want to create "phantom" MAC addresses for that... >=20 > Regards, > Stan >=20 > On Apr 3, 2012, at 2:26 PM, Henning Rogge wrote: >=20 > > On Tue, Apr 3, 2012 at 19:57, Darryl Satterwhite > > wrote: > >>> Does a Neighbor Up event needs to contain any IP address? I assume > >>> the > >>> "just the mac" would be a valid option, right? > >> Yes that is correct, and in most cases layer 3 addresses will NOT = be > >> present. > > Just wanted to be sure, thanks. > > > >> But to reiterate what Stan mentioned earlier, there is also a peer > >> session > >> between the radio and router which exchanges global information and > >> maintains heartbeats for local client(radio) to server(router) > >> sanity. > >> Current implementations use Ethernet so adding a MAC address to = peer > >> messages is unnecessary. > > > > Not necessarily. The communication from the radio might get the MAC = of > > the ethernet device, not the one of the radio interface. But if the > > transport protocol guarantees the right MAC, it will be unnecessary = to > > add the MAC to the DLEP message. > > > > Henning Rogge > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Apr 4 05:46:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132A421F8738 for ; Wed, 4 Apr 2012 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkbuLGvLgyly for ; Wed, 4 Apr 2012 05:46:14 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id BEBCB21F8462 for ; Wed, 4 Apr 2012 05:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,367,1330905600"; d="scan'208";a="199323974" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 13:46:13 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q34CkCZ7010984; Wed, 4 Apr 2012 13:46:12 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 13:46:12 +0100 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 Date: Wed, 4 Apr 2012 13:46:11 +0100 Message-ID: In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Ry0+aXucKbVXMTfyADadyDRCtxwAd070QAAcOYyAAAILNIA== References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Rick Taylor" , "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 04 Apr 2012 12:46:12.0008 (UTC) FILETIME=[EA43BA80:01CD1260] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:46:15 -0000 I agree the 1/2 split makes sense, but you really need to answer 1 = before answering 2. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com]=20 Sent: 04 April 2012 13:44 To: Dearlove, Christopher (UK); Stan Ratliff; Henning Rogge Cc: manet@ietf.org Subject: RE: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I think what might be getting lost in all this discussion about packet = formatting is that all DLEP communication happens between a modem and a = directly connected router. That's a direct wire link, probably = Ethernet. So the whole discussion of compression of packet size is = irrelevant in the grand scheme of things. No DLEP packets are going over = the air or across lossy or multi-hop links. The *only* reason for using packetBB for DLEP is that DLEP is a MANET = RFC, and all MANET RFC's must use packetBB. Discussions about how to fit DLEP messages into packetBB packets is = purely about 'correctness', any discussion about performance is largely = pointless. DLEP would operate perfectly well as an XML SOAP service over HTTP. In = fact, I haven't thought of a good reason why DLEP doesn't use a TCP = connection between router and modem and dispense with heartbeats and = sequence numbers altogether. To answer a previous question, all Neighbour* messages in DLEP refer to = that neighbours MAC address + extra information. My reading of RFC5444 = is that an Address-Block address may be of arbitrary length (i.e. 6 = octets for MAC) avoiding any need to cludge a MAC into an IP address, = but I stand by my first point that this is all just about the = 'prettiness' of the fit of DLEP semantics to the packetBB format. Can we split the DLEP discussions into 2 threads: 1) What is the = information that needs to be communicated between router and modem. 2) = How this information is encapsulated in packetBB/RFC5444? Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Dearlove, Christopher (UK) > Sent: 04 April 2012 10:12 > To: Stan Ratliff; Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > It's going to be impossible to make a sensible suggestion as to how = DLEP > messages should be formatted until all these sorts of questions are > answered. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 03 April 2012 19:55 > To: Henning Rogge > Cc: Darryl Satterwhite; Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I'm not necessarily OK with the notion that a Neighbor Up will > "normally" be just a MAC. With the radio implementation we have right > now, that's the case. But I would hope as DLEP matures, and more > implementations come online, then there should be more of a use for > Layer 3 addressing on the Neighbor Up. >=20 > Now, as to the MAC for the "peer" (e.g. radio) - One of the reasons we > worked to get DLEP running over RFC 5444 was for transport > independence. So now we're going to *assume* a Layer 2 MAC address? > What if the implementation is a radio card in a chassis - I can see > using a 5444 packet transfer, but doing that over some Bus-passing > scheme. I don't want to create "phantom" MAC addresses for that... >=20 > Regards, > Stan >=20 > On Apr 3, 2012, at 2:26 PM, Henning Rogge wrote: >=20 > > On Tue, Apr 3, 2012 at 19:57, Darryl Satterwhite > > wrote: > >>> Does a Neighbor Up event needs to contain any IP address? I assume > >>> the > >>> "just the mac" would be a valid option, right? > >> Yes that is correct, and in most cases layer 3 addresses will NOT = be > >> present. > > Just wanted to be sure, thanks. > > > >> But to reiterate what Stan mentioned earlier, there is also a peer > >> session > >> between the radio and router which exchanges global information and > >> maintains heartbeats for local client(radio) to server(router) > >> sanity. > >> Current implementations use Ethernet so adding a MAC address to = peer > >> messages is unnecessary. > > > > Not necessarily. The communication from the radio might get the MAC = of > > the ethernet device, not the one of the radio interface. But if the > > transport protocol guarantees the right MAC, it will be unnecessary = to > > add the MAC to the DLEP message. > > > > Henning Rogge > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Wed Apr 4 05:51:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9C21F860D for ; Wed, 4 Apr 2012 05:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r0mP-spuEps for ; Wed, 4 Apr 2012 05:51:17 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5913F21F84AA for ; Wed, 4 Apr 2012 05:51:17 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SFPgB-0000a3-Gd; Wed, 04 Apr 2012 14:51:15 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SFPgB-0003pT-EK; Wed, 04 Apr 2012 14:51:15 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 14:51:15 +0200 Message-ID: <4F7C43BC.3010204@fkie.fraunhofer.de> Date: Wed, 04 Apr 2012 14:51:08 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301050609040004080406" X-OriginalArrivalTime: 04 Apr 2012 12:51:15.0255 (UTC) FILETIME=[9F038C70:01CD1261] X-Virus-Scanned: yes (ClamAV 0.97.3/14739/Wed Apr 4 05:06:21 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:51:18 -0000 This is a cryptographically signed message in MIME format. --------------ms000301050609040004080406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/04/2012 02:43 PM, Rick Taylor wrote: > Can we split the DLEP discussions into 2 threads: 1) What is the > information that needs to be communicated between router and modem. > 2) How this information is encapsulated in packetBB/RFC5444? I think that sounds like a reasonable approach to resolve this thread,=20 lets start with point 1). If we have a consensus about WHAT information we need in DLEP to fulfill = the use-cases, we can move to 2). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms000301050609040004080406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDQxMjUxMTNaMCMGCSqGSIb3DQEJBDEWBBSGY3VOVGUAW6B1ucaao30z+EUhCjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQB0W/VlBicGIlK6MWjRw7fBrRombCemLPNInmrGDcv4v2rBNqP86bU7VRsHjBzt o8DxD6w8wn3wb/dwzHyHDwWOwxz8qKMTy9MiAvgqHYogaqybC4jPEKW9bBGW0gY5c4BJwHZh 4IIWjZBwHyq0V3/OdNSX0SIgAsBChQ1ZSAH6mqufid2sD41beGhRkspvf3vRLBa8yEv8AGaN HvY189JbcKMnjvh5DoZVLNcO8Ig6FKjKFBnXuRs8SyZLthwFAXrulTdgswKKdrhbDZcSiDC5 alrppzaME+Sl5xWQ9Hu9Jz+Yjg5hDmfWpgGwYF9URKsaOYhS6kMUNh6B8U/9FiOdAAAAAAAA --------------ms000301050609040004080406-- From dsatterw@cisco.com Wed Apr 4 06:54:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F403421F84C4 for ; Wed, 4 Apr 2012 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.482 X-Spam-Level: X-Spam-Status: No, score=-8.482 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr2ciFmgy+Go for ; Wed, 4 Apr 2012 06:54:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3D421F8470 for ; Wed, 4 Apr 2012 06:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=850; q=dns/txt; s=iport; t=1333547653; x=1334757253; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=DNn1rUXDQrY+ODsF9KLbGqAPMn9jiql8ravESXX0T7w=; b=HE9vpOmiZF2b8dHHalUTeS/mOsdQuIMhDj95uYqrNeGyMX3U1pBxLOGe M6U0zdJLTukhvK/VxoYhSwH8aFtpwDF6gYbk2uZ/fXyh8uLrqtpIZB95Q 1L6hzcA6zvdBhMdbaTPdmpivdt/DeWGUYbeNRAweBO3YfZ0uPIlngmqLR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQIABpSfE+tJXHA/2dsb2JhbABFihGuCgKBB4IJAQEBAwESAScCAUENAQgYgQUBAQQBEiKHYgWbJJ5mkFQElWOOR4FpgwM X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="71974824" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 04 Apr 2012 13:54:13 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q34DsCYt020085; Wed, 4 Apr 2012 13:54:12 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 08:54:12 -0500 Received: from 64.102.54.231 ([64.102.54.231]) by XMB-RCD-201.cisco.com ([72.163.62.208]) via Exchange Front-End Server email.cisco.com ([72.163.62.204]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 13:54:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 04 Apr 2012 09:54:12 -0400 From: Darryl Satterwhite To: Henning Rogge , Message-ID: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Samoh6mURuzSdy0uxH5H4iS4yLw== In-Reply-To: <4F7C43BC.3010204@fkie.fraunhofer.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 13:54:12.0699 (UTC) FILETIME=[6A8BC2B0:01CD126A] Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 13:54:14 -0000 If we are targeting "1)", then all that I remember hearing are: 1) A dimensionless Metric (We currently have RLQ which is dimensionless) 2) A way to report metrics in both directions for asymmetric links. Were there others? Darryl Satterwhite Cisco Systems On 4/4/12 8:51 AM, "Henning Rogge" wrote: > On 04/04/2012 02:43 PM, Rick Taylor wrote: >> Can we split the DLEP discussions into 2 threads: 1) What is the >> information that needs to be communicated between router and modem. >> 2) How this information is encapsulated in packetBB/RFC5444? > > I think that sounds like a reasonable approach to resolve this thread, > lets start with point 1). > > If we have a consensus about WHAT information we need in DLEP to fulfill > the use-cases, we can move to 2). > > Henning Rogge From Chris.Dearlove@baesystems.com Wed Apr 4 07:07:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC1521F87B1 for ; Wed, 4 Apr 2012 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqkFz29dLzXW for ; Wed, 4 Apr 2012 07:07:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFA521F87A7 for ; Wed, 4 Apr 2012 07:07:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="199355547" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 15:07:53 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q34E7rJi032202; Wed, 4 Apr 2012 15:07:53 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 15:07:53 +0100 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 Date: Wed, 4 Apr 2012 15:07:51 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Samoh6mURuzSdy0uxH5H4iS4yLwAATtOg References: <4F7C43BC.3010204@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Darryl Satterwhite" , "Henning Rogge" , X-OriginalArrivalTime: 04 Apr 2012 14:07:53.0007 (UTC) FILETIME=[537CD3F0:01CD126C] Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:07:55 -0000 How are entities about which information (metrics etc.) identified? What ki= nds of addresses do they always/sometimes have? This is fundamental to how to include information in a 5444 message, the ba= sic design of which is that a message contains two sorts of information: (a= ) information specific to the message, (b) information specific to an entit= y identified by an address. There may be ways to use 5444 more creatively t= han that, but that was the original design logic. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= arryl Satterwhite Sent: 04 April 2012 14:54 To: Henning Rogge; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- If we are targeting "1)", then all that I remember hearing are: 1) A dimensionless Metric (We currently have RLQ which is dimensionless) 2) A way to report metrics in both directions for asymmetric links. Were there others? Darryl Satterwhite Cisco Systems On 4/4/12 8:51 AM, "Henning Rogge" wrote= : > On 04/04/2012 02:43 PM, Rick Taylor wrote: >> Can we split the DLEP discussions into 2 threads: 1) What is the >> information that needs to be communicated between router and modem. >> 2) How this information is encapsulated in packetBB/RFC5444? >=20 > I think that sounds like a reasonable approach to resolve this thread, > lets start with point 1). >=20 > If we have a consensus about WHAT information we need in DLEP to fulfill > the use-cases, we can move to 2). >=20 > Henning Rogge _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Wed Apr 4 07:09:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065221F87B5 for ; Wed, 4 Apr 2012 07:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-AV33Va0s41 for ; Wed, 4 Apr 2012 07:09:06 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92921F87B1 for ; Wed, 4 Apr 2012 07:09:06 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SFQtV-0004Jg-JG; Wed, 04 Apr 2012 16:09:05 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SFQtV-0005xE-Ga; Wed, 04 Apr 2012 16:09:05 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 16:09:05 +0200 Message-ID: <4F7C55F9.9060408@fkie.fraunhofer.de> Date: Wed, 04 Apr 2012 16:08:57 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Darryl Satterwhite References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020407000704020501040702" X-OriginalArrivalTime: 04 Apr 2012 14:09:05.0364 (UTC) FILETIME=[7E9DA140:01CD126C] X-Virus-Scanned: yes (ClamAV 0.97.3/14741/Wed Apr 4 15:16:24 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 63d11b563531d75ada9d42d73b6da78e Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:09:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020407000704020501040702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/04/2012 03:54 PM, Darryl Satterwhite wrote: > If we are targeting "1)", then all that I remember hearing are: > > 1) A dimensionless Metric (We currently have RLQ which is dimensionless= ) > 2) A way to report metrics in both directions for asymmetric links. > > Were there others? I would add a few things: - the MAC address of every neighbor for identification of links - IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol of=20 the radio - an identification string for radio and router - timing information how often radio and router announce their presence=20 in the DLEP session - the MAC address of the radio/connected interface for identification of = the DLEP-Client (instead of the current 32bit server id)? - a way to report metric data of links not directly connected to the=20 local radio (if known to the radio)? We most likely could add quite a few more metric related data like: - current transmission speed of broadcasts - link throughput - signal strength - signal/noise ratio - frequency - packet loss and other link specific layer-2 statistics easily gathered = by the link layer. I would also consider splitting our list into the "passive" and "active" = part of DLEP. The passive DLEP part is just about querying data, the=20 active one is about controlling the interface (Link Characteristic=20 Request) and traffic shaping (Credit messages). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020407000704020501040702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDQxNDA5MDNaMCMGCSqGSIb3DQEJBDEWBBQPWqyKYfnL0e9cm65Sj/m2aE7HpTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBgtEV5WWlYUE5YwgamFvzJszJ4M//SjppMJeCy2GR+5Qd2PIKeLTpE487b5get lFP9UQyDxSG2eFtN3WQlNr1x3YiA4uTZfv6DxVlQ8WGb+238FRZ/YeYf3k405Hz5MuTw8Vgx MheEA64fRoY9Ht5rtCaE+BCe3zyUVQ3pIE7YRBm68KIIoHlE8vByAdoL1IWUIgVFrOK3IdxR hmv67ntNl9w+Z+FNuoRkGevLIVSP4seMaj/CFbSuTYjWPrhrBVI0Hb9f5VBOsW4s92Q0UKfA 4+8LEkR0MzU+lZ32/KYFIyNK1ykLbyjwEH50cAXL/eCLY0rLwJWkgIKHx/wDGlH8AAAAAAAA --------------ms020407000704020501040702-- From teco@inf-net.nl Wed Apr 4 07:28:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFB21F871A for ; Wed, 4 Apr 2012 07:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukZkjgPxIuSu for ; Wed, 4 Apr 2012 07:28:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4921F8711 for ; Wed, 4 Apr 2012 07:28:24 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so219393wgb.13 for ; Wed, 04 Apr 2012 07:28:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Nd09rYu4FFIVAU7BFRdWZ8NfPJWhIjbK53hG23eZHN8=; b=diG1dwZkTKY0r0Zhs/fSTUTxxSZVt9CuL8/0kGL4kC9LNnt9+675Ch/bzXN+gqGYQ3 FUcf19egQaBm4FH3SHmE3wejw9ZlZ8wgr/SxKVOEsu0K6rbrSPsFfHzRqk0v1cqqFXLn A2EqiCRchrLenWnpp5/o6V6iiKHFUexXGfvlMXY1OA0+CbogTlTyHlxWYg7UrgbiGJTt vbaV0fb6Kwzv1cEwdir29ITdi0Ehc4Lh/U3/859V1VhyxNypmBbhiIT7XrhfKRldrwpo xGZxANdAfd6/j/Qj3HRGGi5svJSIZ/3Z8vFcGUyC26LL5z35Wm0r0lbHpqiN5gpHtCFR pEpg== Received: by 10.216.135.103 with SMTP id t81mr1588388wei.113.1333549704036; Wed, 04 Apr 2012 07:28:24 -0700 (PDT) Received: from [172.16.4.76] ([188.205.88.52]) by mx.google.com with ESMTPS id fl2sm3401989wib.4.2012.04.04.07.28.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 07:28:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <4F7C55F9.9060408@fkie.fraunhofer.de> Date: Wed, 4 Apr 2012 16:28:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7C55F9.9060408@fkie.fraunhofer.de> To: Henning Rogge , Darryl Satterwhite X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk1dWbjG0x/pKNufTXoJLK72z1cAhMb7GoKJ2YUut7iK1pXSL3WipLIquj2lYse5DFubYjq Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:28:26 -0000 I remember the static micro-wave serial link and satcom bended bit-pipe=20= use cases, where the p2p link (also uni-directional receiver in the = satcom=20 use case) had a TX and RX clock. It was hard to get this info into the router / routing protocol. The modems had ethernet management ports, but there wasn't a standard protocol implemented (or so to say, routers do not poll MIBs). This problem still exists. DLEP could be used, but it has some new requirements: no sub-IP protocol, the modems are only aware of link speed and signal strength & quality @ local node. There could be EOW, but I am not aware this is used for DLEP-related info exchange. This is still used in static ad hoc networks (SANET?).=20 Teco Op 4 apr. 2012, om 16:08 heeft Henning Rogge het volgende geschreven: > On 04/04/2012 03:54 PM, Darryl Satterwhite wrote: >> If we are targeting "1)", then all that I remember hearing are: >>=20 >> 1) A dimensionless Metric (We currently have RLQ which is = dimensionless) >> 2) A way to report metrics in both directions for asymmetric links. >>=20 >> Were there others? >=20 > I would add a few things: > - the MAC address of every neighbor for identification of links > - IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol of = the radio > - an identification string for radio and router > - timing information how often radio and router announce their = presence in the DLEP session > - the MAC address of the radio/connected interface for identification = of the DLEP-Client (instead of the current 32bit server id)? > - a way to report metric data of links not directly connected to the = local radio (if known to the radio)? >=20 > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily = gathered by the link layer. >=20 > I would also consider splitting our list into the "passive" and = "active" part of DLEP. The passive DLEP part is just about querying = data, the active one is about controlling the interface (Link = Characteristic Request) and traffic shaping (Credit messages). >=20 > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jomullen@ad.nmsu.edu Wed Apr 4 07:30:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76821F871A for ; Wed, 4 Apr 2012 07:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtwNCTvyreE9 for ; Wed, 4 Apr 2012 07:30:05 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-02.nmsu.edu [128.123.34.236]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1E21F8711 for ; Wed, 4 Apr 2012 07:30:05 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-02.ACN.ad.nmsu.edu ([128.123.34.236]) with mapi; Wed, 4 Apr 2012 08:30:00 -0600 From: Dr John P Mullen To: "manet@ietf.org" Date: Wed, 4 Apr 2012 08:30:00 -0600 Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0SbJw539nD0OqZRTO7nCjxq3H40AAAVwkw Message-ID: References: <4F7C55F9.9060408@fkie.fraunhofer.de> In-Reply-To: <4F7C55F9.9060408@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:30:06 -0000 Hi, Concerning: ------------------------ We most likely could add quite a few more metric related data like: - current transmission speed of broadcasts - link throughput - signal strength - signal/noise ratio - frequency - packet loss and other link specific layer-2 statistics easily gathered by= the link layer. ------------------ I think it is good to keep in mind that almost all of these characteristics= are random variables. If we try to circulate too many details, we may end = up circulating more sampling error than information. This would be especial= ly true of a situation in which the nodes are moving fairly rapidly, relati= ve to transmission range. Also, it is possible that different estimates of = these parameters will arrive via different routes, leaving the receiving no= de with the problem of justifying the conflicts. Additionally, as the numbe= r of hops increases, the latency also increases, making information less cu= rrent/reliable. In this case, I think less is more. It would seem better to provide a singl= e metric, say p(reception), about nearby nodes with further detail possibly= available through a specific query about a specific node. This would reduc= e the load on the channel and simplify the process of dealing with informat= ion. John Mullen -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: Wednesday, April 04, 2012 8:09 AM To: Darryl Satterwhite Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours On 04/04/2012 03:54 PM, Darryl Satterwhite wrote: > If we are targeting "1)", then all that I remember hearing are: > > 1) A dimensionless Metric (We currently have RLQ which is=20 > dimensionless) > 2) A way to report metrics in both directions for asymmetric links. > > Were there others? I would add a few things: - the MAC address of every neighbor for identification of links - IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol of the = radio - an identification string for radio and router - timing information how often radio and router announce their presence in = the DLEP session - the MAC address of the radio/connected interface for identification of th= e DLEP-Client (instead of the current 32bit server id)? - a way to report metric data of links not directly connected to the local = radio (if known to the radio)? We most likely could add quite a few more metric related data like: - current transmission speed of broadcasts - link throughput - signal strength - signal/noise ratio - frequency - packet loss and other link specific layer-2 statistics easily gathered by= the link layer. I would also consider splitting our list into the "passive" and "active"=20 part of DLEP. The passive DLEP part is just about querying data, the active= one is about controlling the interface (Link Characteristic Request) and traffic shaping (Credit messages). Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation= , Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) N= euenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From sratliff@cisco.com Wed Apr 4 07:33:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17C21F861E for ; Wed, 4 Apr 2012 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB6P+DK-0Lh2 for ; Wed, 4 Apr 2012 07:33:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BC39F21F85CE for ; Wed, 4 Apr 2012 07:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2619; q=dns/txt; s=iport; t=1333549980; x=1334759580; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=+7VGBe579YknMYya18vwip5VYgc+SkVb/s+E1i0l1sE=; b=k7Es3RwjgPDp+qel61Y7tkvFqurS0eLeGe/Y+IFne8GQ6YzG/g4z4UtQ XsmjKYNLqE2RaQvuRv2eLaWklrsUb06p0F/3QQRNgzWsTopISWTM4sdHe 1W3nw6cByR+s5Uz5D+cZgncpEe6H6ebNKbd7qFInrfKBPyaeDnTO1Pg2y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAExbfE+tJXG+/2dsb2JhbABDuCqBB4IJAQEBAwEBAQEPASU2CwULCxgnBycfEQYKCSKHYgULn2WWfI9xYwSVY45HgWmDAw X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="72024488" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 04 Apr 2012 14:33:00 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q34EWxx6030184; Wed, 4 Apr 2012 14:33:00 GMT Message-Id: <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: <4F7C43BC.3010204@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Apr 2012 10:33:01 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:33:05 -0000 Wow. Just. Wow. I'm trying to figure out how we got this far off into the weeds - =20 specifically, how we're on the 02 version of a working group draft =20 (with the individual submission versions before that), and all of a =20 sudden there's supposedly no consensus about "WHAT information we need =20= in DLEP to fulfill the use-cases"????? Seriously? Did no one read the =20= other versions of the draft? To be honest, I really don't know how to respond to where this tread =20 has wound up. It almost looks like the participants in the thread have =20= suddenly come to the conclusion of "Hey, maybe we need a way for a =20 radio to transfer "some" data to a locally attached router! Brilliant! =20= I wonder what data we need?" The current DLEP draft is an attempt to =20 articulate JUST THAT - what data is needed. It is based on the =20 experiences of the co-authors in deploying these networks. So, draft-=20 ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT =20= is needed. It also represents the notions of the co-authors as to HOW =20= the data should be transmitted. The packets fit into RFC 5444 format, =20= as required by the MANET working group. Past that, this discussion is =20= devolving into something that simply isn't useful, IMO. To camp out on =20= this and spin several iterations doesn't do anyone any good - =20 especially those that are trying to actually put products into the =20 field to help customers. Regards, Stan On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: > On 04/04/2012 02:43 PM, Rick Taylor wrote: >> Can we split the DLEP discussions into 2 threads: 1) What is the >> information that needs to be communicated between router and modem. >> 2) How this information is encapsulated in packetBB/RFC5444? > > I think that sounds like a reasonable approach to resolve this =20 > thread, lets start with point 1). > > If we have a consensus about WHAT information we need in DLEP to =20 > fulfill the use-cases, we can move to 2). > > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Wed Apr 4 07:37:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7258921F8657 for ; Wed, 4 Apr 2012 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzd1TVYE6T5Y for ; Wed, 4 Apr 2012 07:37:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB121F8656 for ; Wed, 4 Apr 2012 07:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4460; q=dns/txt; s=iport; t=1333550255; x=1334759855; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=fKdUwuo7nEKPLa/RsojBCjyGqboBr+Wgrb6bvYNs1ec=; b=DFiDAYSdejaD/2ZgfOoB7OtCeM2TdUcnlWO4+LROPB4fCGSRo19NLSLQ H2BW1ypyAneYFsPKjreoPFRSjfG+kn8TOWfWTmCwh3+bCvA/JtS7zTsEv pji+tU5RiFMGSa1AYI2tqEyPeSTqQvEZBsCzU/CuNlxSAeT6wR5YMwqsA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFVcfE+tJV2c/2dsb2JhbABFDrgPgQeCCQEBAQMBAQEBDwElNgsFBwQLEQQBAQEnBycfCQgGEyKHYgULmyeeYo9xYwSVY45HgWmCMFM X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="71808047" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 04 Apr 2012 14:37:34 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q34EbYmf015149; Wed, 4 Apr 2012 14:37:34 GMT Message-Id: From: Stan Ratliff To: Dr John P Mullen In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Apr 2012 10:37:35 -0400 References: <4F7C55F9.9060408@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:37:36 -0000 Adding specific metric types like this is a fairly straightforward =20 exercise, provided there is consensus in the working group to do so. =20 That is, in the current packet format... Having said that, the current draft also allows for a number space of =20= "experimental TLV's". Those could be used to initially transport =20 values such as this for experimentation, with a subsequent revision of =20= the DLEP draft to incorporate them if they are seen as universally =20 beneficial. So, I'll leave it to the WG to determine consensus on adding the items =20= below. Regards, Stan On Apr 4, 2012, at 10:30 AM, Dr John P Mullen wrote: > Hi, > > Concerning: > ------------------------ > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily =20 > gathered by the link layer. > ------------------ > I think it is good to keep in mind that almost all of these =20 > characteristics are random variables. If we try to circulate too =20 > many details, we may end up circulating more sampling error than =20 > information. This would be especially true of a situation in which =20 > the nodes are moving fairly rapidly, relative to transmission range. =20= > Also, it is possible that different estimates of these parameters =20 > will arrive via different routes, leaving the receiving node with =20 > the problem of justifying the conflicts. Additionally, as the number =20= > of hops increases, the latency also increases, making information =20 > less current/reliable. > > In this case, I think less is more. It would seem better to provide =20= > a single metric, say p(reception), about nearby nodes with further =20 > detail possibly available through a specific query about a specific =20= > node. This would reduce the load on the channel and simplify the =20 > process of dealing with information. > > John Mullen > > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 > Behalf Of Henning Rogge > Sent: Wednesday, April 04, 2012 8:09 AM > To: Darryl Satterwhite > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > On 04/04/2012 03:54 PM, Darryl Satterwhite wrote: >> If we are targeting "1)", then all that I remember hearing are: >> >> 1) A dimensionless Metric (We currently have RLQ which is >> dimensionless) >> 2) A way to report metrics in both directions for asymmetric links. >> >> Were there others? > > I would add a few things: > - the MAC address of every neighbor for identification of links > - IPv4/IPv6 addresses of neighbors if known by the layer-2 protocol =20= > of the radio > - an identification string for radio and router > - timing information how often radio and router announce their =20 > presence in the DLEP session > - the MAC address of the radio/connected interface for =20 > identification of the DLEP-Client (instead of the current 32bit =20 > server id)? > - a way to report metric data of links not directly connected to the =20= > local radio (if known to the radio)? > > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily =20 > gathered by the link layer. > > I would also consider splitting our list into the "passive" and =20 > "active" > part of DLEP. The passive DLEP part is just about querying data, the =20= > active one is about controlling the interface (Link Characteristic > Request) and traffic shaping (Credit messages). > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr =20 > Kommunikation, Informationsverarbeitung und Ergonomie FKIE =20 > Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, =20= > Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Apr 4 07:55:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2802721F8685 for ; Wed, 4 Apr 2012 07:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL77+GBnxDTx for ; Wed, 4 Apr 2012 07:55:00 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id C228D21F8674 for ; Wed, 4 Apr 2012 07:54:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="199371761" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 15:54:59 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q34Esrjh030630; Wed, 4 Apr 2012 15:54:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 15:54: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 15:54:57 +0100 Message-ID: In-Reply-To: <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Sb9vo64oAFVN2Sa2bdnTpKgQ3nwAAUlMw References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 04 Apr 2012 14:54:58.0740 (UTC) FILETIME=[E7C17740:01CD1272] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:55:01 -0000 I've been trying to consider the issue of 5444 fit, having an interest as a= n author of 5444. And despite several requests, I haven't seen a clear stat= ement and good example(s) of what that information is. And having to dig th= rough the draft is not the answer to that. I'm actually not worried (in thi= s context) about the details of how many link metric types there are, for e= xample, what matters is that there may be several pieces of information and= whether in a given message each reported entity may have different subsets= of associated data, or all will have the same? But how those entities are = identified - by what sort of addresses and whether any are always present e= tc. - is critical. And if there is information not associated with addresse= d entities, is that one-of or multiple, and if the latter how they identifi= ed? These are the critical questions with regard to formatting, and they ar= en't being clearly and simply answered. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 04 April 2012 15:33 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Wow. Just. Wow. I'm trying to figure out how we got this far off into the weeds - =20 specifically, how we're on the 02 version of a working group draft =20 (with the individual submission versions before that), and all of a =20 sudden there's supposedly no consensus about "WHAT information we need =20 in DLEP to fulfill the use-cases"????? Seriously? Did no one read the =20 other versions of the draft? To be honest, I really don't know how to respond to where this tread =20 has wound up. It almost looks like the participants in the thread have =20 suddenly come to the conclusion of "Hey, maybe we need a way for a =20 radio to transfer "some" data to a locally attached router! Brilliant! =20 I wonder what data we need?" The current DLEP draft is an attempt to =20 articulate JUST THAT - what data is needed. It is based on the =20 experiences of the co-authors in deploying these networks. So, draft-=20 ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT =20 is needed. It also represents the notions of the co-authors as to HOW =20 the data should be transmitted. The packets fit into RFC 5444 format, =20 as required by the MANET working group. Past that, this discussion is =20 devolving into something that simply isn't useful, IMO. To camp out on =20 this and spin several iterations doesn't do anyone any good - =20 especially those that are trying to actually put products into the =20 field to help customers. Regards, Stan On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: > On 04/04/2012 02:43 PM, Rick Taylor wrote: >> Can we split the DLEP discussions into 2 threads: 1) What is the >> information that needs to be communicated between router and modem. >> 2) How this information is encapsulated in packetBB/RFC5444? > > I think that sounds like a reasonable approach to resolve this =20 > thread, lets start with point 1). > > If we have a consensus about WHAT information we need in DLEP to =20 > fulfill the use-cases, we can move to 2). > > Henning Rogge > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Wed Apr 4 08:04:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345F21F87FD for ; Wed, 4 Apr 2012 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxYk0YmTJ5N2 for ; Wed, 4 Apr 2012 08:04:19 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69B21F87F3 for ; Wed, 4 Apr 2012 08:04:11 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so246767wgb.13 for ; Wed, 04 Apr 2012 08:04:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=APR71MAok13qfn3/e2VdrGD4q/IdKVO7qG+kKZGksBE=; b=QGBK7moDchLQ2Ca8dGBA9Qwwa/8/fNiQxnzbxqkchFxPsuDSWhgfygyXPjLACteumH p3JN1In+eVcjsas4VzlAPZeLPYTiunEe41H/nf6PT7eSUvpWvigQUD04m+g2tqOOxoir Ax0hXYCyAWYqWU82eGJEEazyQJyzRbKllwG13uk6jZlNMR9oj1m2m8zDukm9/nVwXCMg 7wvAkRankZyPlY5SD/lU/NAyE60Srou4qJmtNeOUc5dOUUA/0AURdlXzKMCxvHeP14gC 5bYZfZ2nfBXopBYtMmYzbuoLjnWGGST1FxFXW3GizdkKUJAI7BP43/3IeXZcxL/OQdyz 5i1Q== Received: by 10.216.210.138 with SMTP id u10mr1677243weo.11.1333551850403; Wed, 04 Apr 2012 08:04:10 -0700 (PDT) Received: from [172.16.4.76] ([188.205.88.52]) by mx.google.com with ESMTPS id bx13sm5443151wib.10.2012.04.04.08.04.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 08:04:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> Date: Wed, 4 Apr 2012 17:04:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38C0B162-D63E-4353-9C6B-5565E30D500E@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkiPcRS1jmU8UGnTFdobS5lXGpcNqAXTkyl17xjMuWFu/ss1wb/Ujcn9GTddsSu/Zu6mWz+ Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:04:20 -0000 Also important: having running code. Op 4 apr. 2012, om 16:33 heeft Stan Ratliff het volgende geschreven: > Wow. Just. Wow. At least you have attention :-) >=20 > I'm trying to figure out how we got this far off into the weeds - = specifically, how we're on the 02 version of a working group draft (with = the individual submission versions before that), and all of a sudden = there's supposedly no consensus about "WHAT information we need in DLEP = to fulfill the use-cases"????? Seriously? Did no one read the other = versions of the draft? Some did. >=20 > To be honest, I really don't know how to respond to where this tread = has wound up. It almost looks like the participants in the thread have = suddenly come to the conclusion of "Hey, maybe we need a way for a radio = to transfer "some" data to a locally attached router! Brilliant! I = wonder what data we need?" The current DLEP draft is an attempt to = articulate JUST THAT - what data is needed. Needed for the protocols you work with. Good starting point, no one = suggested to throw away something. I could easily miss a posting. But I have some opinions on parts of the protocol. We (IETF) have = already STD TRACK protocols for for example L2 address resolving. And I = dislike the flow control part being part of the STD TRACK DLEP protocol. = Just me and a couple of others. > It is based on the experiences of the co-authors in deploying these = networks. So, draft-ietf-manet-dlep-02 represents the notions of the = co-authors as to WHAT is needed. Thanks for sharing your experiences. Thanks publishing. Now *we* (MANET = GW) come into the difficult part going forward with it. > It also represents the notions of the co-authors as to HOW the data = should be transmitted. The packets fit into RFC 5444 format, as required = by the MANET working group. I am not so sure on this "required". If it makes sense, yes. If not, = select a better transport protocol for the data. There were some postings on DLEP messages and packets. DLEP messages = cannot be carried in packets for MANET routing protocols. The source & = destinations are different. > Past that, this discussion is devolving into something that simply = isn't useful, IMO. To camp out on this and spin several iterations = doesn't do anyone any good - especially those that are trying to = actually put products into the field to help customers. Accepted. Although active members on this thread may have these goals. I = have. I do put products into the field. Back to what this thread is about. Subject is "DLEP and multi-hop = neighbours". This is a somewhat inaccurate subscription. For the router, = neighbors are neighbors and they are 1-hop away. 2-hop neighbors are = neighbor neighbors, so not real neighbors. DLEP is about link metrics to = (L3) neighbors. I think I came up with a requirement for a metric, from sub-IP-layer, = directly to be used by L3 routing. Then sub-IP and IP routing has = exactly the same info for the topology. Makes live more easy for those = that deploy such. Teco. >=20 > Regards, > Stan >=20 > On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: >=20 >> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>> Can we split the DLEP discussions into 2 threads: 1) What is the >>> information that needs to be communicated between router and modem. >>> 2) How this information is encapsulated in packetBB/RFC5444? >>=20 >> I think that sounds like a reasonable approach to resolve this = thread, lets start with point 1). >>=20 >> If we have a consensus about WHAT information we need in DLEP to = fulfill the use-cases, we can move to 2). >>=20 >> Henning Rogge >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From dyoung@pixotech.com Wed Apr 4 07:58:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18D21F86AA for ; Wed, 4 Apr 2012 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ncwp3foWLj5 for ; Wed, 4 Apr 2012 07:58:03 -0700 (PDT) Received: from elmendorf.ojctech.com (elmendorf.ojctech.com [IPv6:2002:4cbf:1101:1:20e:cff:febc:8cc]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09E21F86A6 for ; Wed, 4 Apr 2012 07:58:01 -0700 (PDT) Received: by elmendorf.ojctech.com (Postfix, from userid 1000) id 5D8BC1BF666; Wed, 4 Apr 2012 09:57:58 -0500 (CDT) Date: Wed, 4 Apr 2012 09:57:58 -0500 From: David Young To: manet@ietf.org Message-ID: <20120404145757.GE27907@pixotech.com> Mail-Followup-To: manet@ietf.org References: <4F7C55F9.9060408@fkie.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:14:47 -0000 On Wed, Apr 04, 2012 at 08:30:00AM -0600, Dr John P Mullen wrote: > Hi, > > Concerning: > ------------------------ > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily gathered by the link layer. > ------------------ > I think it is good to keep in mind that almost all of these > characteristics are random variables. If we try to circulate too > many details, we may end up circulating more sampling error than > information. This would be especially true of a situation in which the > nodes are moving fairly rapidly, relative to transmission range. Also, > it is possible that different estimates of these parameters will > arrive via different routes, leaving the receiving node with the > problem of justifying the conflicts. Additionally, as the number of > hops increases, the latency also increases, making information less > current/reliable. Apropos the latency problem, more important than plumping the set of metrics may be adding a timestamp telling the time when the metrics were recorded, the units (ms, us, ns) of time, the time source & origin (GPS & GMT), and the time itself. In this way a router can discard data that is old or superseded by data. Dave -- David Young dyoung@pobox.com Urbana, IL (217) 721-9981 From hrogge@googlemail.com Wed Apr 4 08:19:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B710521F879C for ; Wed, 4 Apr 2012 08:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT6SBGE7k0Yg for ; Wed, 4 Apr 2012 08:18:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9626021F861D for ; Wed, 4 Apr 2012 08:18:59 -0700 (PDT) Received: by bkuw5 with SMTP id w5so440435bku.31 for ; Wed, 04 Apr 2012 08:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qcXx8YfOy/+fy/SpfSXiw0HtRVIGMZ7taVgoYqGWmWM=; b=H7O5DC1eWqBgmb4NklmIGFXM6hpooJW7SVj0/We8Y+LDrroBlYngRg3FDSVr7IZABk zylMFCJoSuQeygh7ZErY2lyxAvqr/xEuVAOtLbvniQDoiHjkpHovPwViwYyx7TeZccd1 llrBuQACfPymfeG9xvAZuge7pkF6MKzftv3cMPk3hs1fJ4nhdIEpWa2TDjzcmmPnENAt bFEsPTYjkzwnhUFyNPlrY5HXwYfxS6RjSQi9jZunMBG+bsMHY97HdYzxpPrUm6BTgfE/ lEnj67jLJvk2J879YeKrsidEw/WWcyV7ppO3oUMqGwHOK9N3vhk28NMNmkN956+FnJts /m2g== Received: by 10.152.131.9 with SMTP id oi9mr19162788lab.6.1333552738602; Wed, 04 Apr 2012 08:18:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 4 Apr 2012 08:18:38 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> From: Henning Rogge Date: Wed, 4 Apr 2012 17:18:38 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:19:00 -0000 On Wed, Apr 4, 2012 at 16:54, Dearlove, Christopher (UK) wrote: > I've been trying to consider the issue of 5444 fit, having an interest as= an author of 5444. And despite several requests, I haven't seen a clear st= atement and good example(s) of what that information is. And having to dig = through the draft is not the answer to that. I'm actually not worried (in t= his context) about the details of how many link metric types there are, for= example, what matters is that there may be several pieces of information a= nd whether in a given message each reported entity may have different subse= ts of associated data, or all will have the same? But how those entities ar= e identified - by what sort of addresses and whether any are always present= etc. - is critical. And if there is information not associated with addres= sed entities, is that one-of or multiple, and if the latter how they identi= fied? These are the critical questions with regard to formatting, and they = aren't being clearly and simply answered. Let me try to describe what I see in DLEP in a more general way. DLEP (mostly) is about transporting data from a layer-2 device to a layer-3 agent (for example radio to routing agent). DLEP should allow the layer-3 agent to discover the DLEP-capable interfaces without explicitly configuring them one by one. DLEP should provide a list of other layer-2 participants behinds its local interface identified by their MAC address. DLEP provide both data about layer-2 participants (addresses, local resources,...) and data about connection between layer-2 participants (link-metrics, statistics, ...). As long as they are known to the MAC layer of course. ----- Some Layer-2 MACs are aware of link data beyond their direct neighborhood. Especially TDMA implementations often keep track of at least the two-hop neighborhood (had a long talk with the Software Defined Radio group in our institute). In fact, a lot of them are running something similar to NHDP on layer-2. Exporting this collected link data would be interesting for layer-3 too. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Wed Apr 4 08:22:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C733421F87C8 for ; Wed, 4 Apr 2012 08:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp8X9K8zI8MT for ; Wed, 4 Apr 2012 08:22:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC95021F87B6 for ; Wed, 4 Apr 2012 08:22:14 -0700 (PDT) Received: by lagj5 with SMTP id j5so560993lag.31 for ; Wed, 04 Apr 2012 08:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rpfF78PiEJQMgj1nZcySrL82+SXMt48sf1gO1JzQnuA=; b=lBIoJOCJyygx8W+ZAgWOiVCcWiC/ZBDkzwTVgSN7R8cYqTAhDwiAv8+iy5LxvwgV/a IgLjfYlQZWuBnts72Fwy7S3VnZBpG4/iWLghlDHImzJn8Cum//MYn04e4zPc//mJSIB/ GZMJyYWkPmyfXsrZZeWHv/T6khdNfOP/7muaDT3JEZ/0Wvv/xayvI60/yMy7TyEeJc+x 9chiNwfuycdPEOSlK/16df7TFFr5Nu1iBE7GxJAhK2zkY7hxta9MwNqV7u098GedxFL7 Bi/sLvkPki+Ab80hVG9zqgVGFjkv9S8krxOSrs/wsbdauhQ3Bjj7zhA7MPg6mQZxptFl Bp0A== Received: by 10.152.112.161 with SMTP id ir1mr14509320lab.13.1333552933715; Wed, 04 Apr 2012 08:22:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 4 Apr 2012 08:21:52 -0700 (PDT) In-Reply-To: References: <4F7C55F9.9060408@fkie.fraunhofer.de> From: Henning Rogge Date: Wed, 4 Apr 2012 17:21:52 +0200 Message-ID: To: Dr John P Mullen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:22:16 -0000 On Wed, Apr 4, 2012 at 16:30, Dr John P Mullen wrote= : > Hi, > > Concerning: > ------------------------ > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily gathered = by the link layer. > ------------------ > I think it is good to keep in mind that almost all of these characteristi= cs are random variables. If we try to circulate too many details, we may en= d up circulating more sampling error than information. This would be especi= ally true of a situation in which the nodes are moving fairly rapidly, rela= tive to transmission range. Also, it is possible that different estimates o= f these parameters will arrive via different routes, leaving the receiving = node with the problem of justifying the conflicts. Additionally, as the num= ber of hops increases, the latency also increases, making information less = current/reliable. > > In this case, I think less is more. It would seem better to provide a sin= gle metric, say p(reception), about nearby nodes with further detail possib= ly available through a specific query about a specific node. This would red= uce the load on the channel and simplify the process of dealing with inform= ation. I totally disagree with this. Access to layer-2 data is important for good routing metrics, but the layer-2 cannot know what kind of routing metric the layer-3 is using. Mixing everything together on layer-2 and only providing some "dimensionless" metric value would be a total disaster, because the layer-3 doesn't even know what it mean. Or it might not fit the global metric the routing is using. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Wed Apr 4 08:23:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4082021F87E0 for ; Wed, 4 Apr 2012 08:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+QZMDaZsqjE for ; Wed, 4 Apr 2012 08:23:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7E33721F879B for ; Wed, 4 Apr 2012 08:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=7201; q=dns/txt; s=iport; t=1333553005; x=1334762605; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Z8uB9dHypADYmlFlUZdj7LEI0F/cayMie1wGNdKAtBs=; b=DXgq8gaEr1OxbpgHVw2YxCR4OASVDMOzN7jBF0Z8fiwsNtftxMm2ynnc 00TRoZTvEMApaYexKLPghaleMKfwX2iGygHs+EdpWU9FQdrnIEoood++D w2j92zWEMrluHGhS8iA0xzLLdWY5v6WB/84QERm1LxQgdPqHigGOlF+OV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM5mfE+tJV2Y/2dsb2JhbAA7CrgggQeCCQEBAQMBAQEBDwElHRkDAQcFBwQLEQQBAQEnBycfCQgGCgcCFA6HYgULmyueZIsJBAyEWGMElWOOR4FpgwMigRYI X-IronPort-AV: E=Sophos;i="4.75,369,1330905600"; d="scan'208";a="71824799" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 04 Apr 2012 15:23:25 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q34FNOvZ006907; Wed, 4 Apr 2012 15:23:24 GMT Message-Id: <291ABF54-9012-485C-832C-428A387C055D@cisco.com> From: Stan Ratliff To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Apr 2012 11:23:26 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:23:31 -0000 On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote: > I've been trying to consider the issue of 5444 fit, having an =20 > interest as an author of 5444. And despite several requests, I =20 > haven't seen a clear statement and good example(s) of what that =20 > information is. And having to dig through the draft is not the =20 > answer to that. I'm actually not worried (in this context) about the =20= > details of how many link metric types there are, for example, Actually, digging through the draft *is* the answer to that, given =20 that your knowledge & experience with RFC 5444 formatting (being a co-=20= author) is better than mine. By definition, relying on my synopsis of =20= what's going on may lead you down an incorrect path - but I'm willing =20= to try. > what matters is that there may be several pieces of information and =20= > whether in a given message each reported entity may have different =20 > subsets of associated data, or all will have the same? But how those =20= > entities are identified - by what sort of addresses and whether any =20= > are always present etc. - is critical. And if there is information =20 > not associated with addressed entities, is that one-of or multiple, =20= > and if the latter how they identified? These are the critical =20 > questions with regard to formatting, and they aren't being clearly =20 > and simply answered. > The goal is to identify *both* the radio device (it doesn't *have* to =20= be a radio, BTW) *and* the community of devices that the radio come =20 into contact with. The devices that a given RF net might come into =20 contact with WILL have associated Layer 2 addresses, they will =20 certainly have at least 1 flavor of Layer 3 address, but in my =20 deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH =20 Link-Local and Global IPv6 addresses). As mentioned in an earlier =20 post, metrics don't have meaning from a routing perspective unless/=20 until said metrics can be associated with addresses - destinations. =20 The idea is for the RF device to tell the router when it "sees" =20 another device over the RF (Neighbor Up), and when it "goes =20 away" (Neighbor Down). Upon seeing a device, there may (or may not) be =20= metrics associated with it. Those metrics may change whilst the device =20= is in RF range, hence the need for Neighbor Update. Also, Layer 3 =20 addressing could theoretically change (via modifying configuration =20 from a console, for example) whilst the device is in RF range. So the =20= ability to change the Layer 2/Layer 3 relationships, quickly, needs to =20= be there - that's why we have address ADD and DROP orders. Regards, Stan > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 > Behalf Of Stan Ratliff > Sent: 04 April 2012 15:33 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Wow. Just. Wow. > > I'm trying to figure out how we got this far off into the weeds - > specifically, how we're on the 02 version of a working group draft > (with the individual submission versions before that), and all of a > sudden there's supposedly no consensus about "WHAT information we need > in DLEP to fulfill the use-cases"????? Seriously? Did no one read the > other versions of the draft? > > To be honest, I really don't know how to respond to where this tread > has wound up. It almost looks like the participants in the thread have > suddenly come to the conclusion of "Hey, maybe we need a way for a > radio to transfer "some" data to a locally attached router! Brilliant! > I wonder what data we need?" The current DLEP draft is an attempt to > articulate JUST THAT - what data is needed. It is based on the > experiences of the co-authors in deploying these networks. So, draft- > ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT > is needed. It also represents the notions of the co-authors as to HOW > the data should be transmitted. The packets fit into RFC 5444 format, > as required by the MANET working group. Past that, this discussion is > devolving into something that simply isn't useful, IMO. To camp out on > this and spin several iterations doesn't do anyone any good - > especially those that are trying to actually put products into the > field to help customers. > > Regards, > Stan > > On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: > >> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>> Can we split the DLEP discussions into 2 threads: 1) What is the >>> information that needs to be communicated between router and modem. >>> 2) How this information is encapsulated in packetBB/RFC5444? >> >> I think that sounds like a reasonable approach to resolve this >> thread, lets start with point 1). >> >> If we have a consensus about WHAT information we need in DLEP to >> fulfill the use-cases, we can move to 2). >> >> Henning Rogge >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From sratliff@cisco.com Wed Apr 4 08:30:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A80E21F8830 for ; Wed, 4 Apr 2012 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBJhEnUPlHot for ; Wed, 4 Apr 2012 08:30:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7718821F882F for ; Wed, 4 Apr 2012 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=5284; q=dns/txt; s=iport; t=1333553451; x=1334763051; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=LfmEYHAYbCwW/tffrGhXuvbpARp0c/U+9Opud7I2ENA=; b=DLX+fbcA9boavH+fsgo20zdfmy5Jn/AXJKAcUBnAjS6FpoeZVi+J+EnZ EP+nioe7AFOcKn0UfIfkKV7KfJnw9EsxLuUUb3HqZNvCLFnUYyKgpy9EO rfNfqZJMTSNuzAgEo7eHOcG6+lXvSz/ljQTc2O4DHrn3g4gso4xk0do9M 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIlofE+tJV2a/2dsb2JhbABFuB+BB4IJAQEBAwEBAQEPASURHgcLEAsYDRoHJx8RBgoJIodiBQubHZ5kj3FjBJVjjkeBaYMD X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="72008238" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 04 Apr 2012 15:30:51 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q34FUoXV019484; Wed, 4 Apr 2012 15:30:50 GMT Message-Id: <1E814D09-F001-4896-B3AB-04CA6C7582D6@cisco.com> From: Stan Ratliff To: Teco Boot In-Reply-To: <38C0B162-D63E-4353-9C6B-5565E30D500E@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Apr 2012 11:30:52 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <38C0B162-D63E-4353-9C6B-5565E30D500E@inf-net.nl> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:30:52 -0000 On Apr 4, 2012, at 11:04 AM, Teco Boot wrote: > > Also important: having running code. > > Op 4 apr. 2012, om 16:33 heeft Stan Ratliff het volgende geschreven: > >> Wow. Just. Wow. > At least you have attention :-) > >> >> I'm trying to figure out how we got this far off into the weeds - =20 >> specifically, how we're on the 02 version of a working group draft =20= >> (with the individual submission versions before that), and all of a =20= >> sudden there's supposedly no consensus about "WHAT information we =20 >> need in DLEP to fulfill the use-cases"????? Seriously? Did no one =20= >> read the other versions of the draft? > Some did. > >> >> To be honest, I really don't know how to respond to where this =20 >> tread has wound up. It almost looks like the participants in the =20 >> thread have suddenly come to the conclusion of "Hey, maybe we need =20= >> a way for a radio to transfer "some" data to a locally attached =20 >> router! Brilliant! I wonder what data we need?" The current DLEP =20 >> draft is an attempt to articulate JUST THAT - what data is needed. > Needed for the protocols you work with. Good starting point, no one =20= > suggested to throw away something. I could easily miss a posting. > > But I have some opinions on parts of the protocol. We (IETF) have =20 > already STD TRACK protocols for for example L2 address resolving. =20 > And I dislike the flow control part being part of the STD TRACK DLEP =20= > protocol. Just me and a couple of others. The rough consensus about the flow control seems to be to leave it in =20= there. At least I haven't seen push-back from anywhere else. > >> It is based on the experiences of the co-authors in deploying these =20= >> networks. So, draft-ietf-manet-dlep-02 represents the notions of =20 >> the co-authors as to WHAT is needed. > Thanks for sharing your experiences. Thanks publishing. Now *we* =20 > (MANET GW) come into the difficult part going forward with it. Yes, and last I looked, I *AM* at part of that WG... > >> It also represents the notions of the co-authors as to HOW the data =20= >> should be transmitted. The packets fit into RFC 5444 format, as =20 >> required by the MANET working group. > I am not so sure on this "required". If it makes sense, yes. If not, =20= > select a better transport protocol for the data. > > There were some postings on DLEP messages and packets. DLEP messages =20= > cannot be carried in packets for MANET routing protocols. The source =20= > & destinations are different. > >> Past that, this discussion is devolving into something that simply =20= >> isn't useful, IMO. To camp out on this and spin several iterations =20= >> doesn't do anyone any good - especially those that are trying to =20 >> actually put products into the field to help customers. > Accepted. Although active members on this thread may have these =20 > goals. I have. I do put products into the field. > > Back to what this thread is about. Subject is "DLEP and multi-hop =20 > neighbours". This is a somewhat inaccurate subscription. For the =20 > router, neighbors are neighbors and they are 1-hop away. 2-hop =20 > neighbors are neighbor neighbors, so not real neighbors. DLEP is =20 > about link metrics to (L3) neighbors. > > I think I came up with a requirement for a metric, from sub-IP-=20 > layer, directly to be used by L3 routing. Then sub-IP and IP routing =20= > has exactly the same info for the topology. Makes live more easy for =20= > those that deploy such. And your question has already been asked and answered - RLQ. As far as =20= the "directly to be used by L3 routing" part, that's out of scope for =20= DLEP, as we've said time & time again - DLEP is about getting the data =20= across the chasm, NOT about what you do with it once you get it there. Regards, Stan > > Teco. > >> >> Regards, >> Stan >> >> On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: >> >>> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>>> Can we split the DLEP discussions into 2 threads: 1) What is the >>>> information that needs to be communicated between router and modem. >>>> 2) How this information is encapsulated in packetBB/RFC5444? >>> >>> I think that sounds like a reasonable approach to resolve this =20 >>> thread, lets start with point 1). >>> >>> If we have a consensus about WHAT information we need in DLEP to =20 >>> fulfill the use-cases, we can move to 2). >>> >>> Henning Rogge >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://=20 >>> www.fkie.fraunhofer.de >>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From jomullen@ad.nmsu.edu Wed Apr 4 09:06:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE73E21F8445 for ; Wed, 4 Apr 2012 09:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJQ+kEc2TqSm for ; Wed, 4 Apr 2012 09:06:21 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-01.nmsu.edu [128.123.34.211]) by ietfa.amsl.com (Postfix) with ESMTP id A9BE921F87E1 for ; Wed, 4 Apr 2012 09:06:16 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-01.ACN.ad.nmsu.edu ([128.123.34.211]) with mapi; Wed, 4 Apr 2012 10:06:13 -0600 From: Dr John P Mullen To: "manet@ietf.org" Date: Wed, 4 Apr 2012 10:06:13 -0600 Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0SdvcHWOouuK+kR9yiy/6cPAuUcgABAV8Q Message-ID: References: <4F7C55F9.9060408@fkie.fraunhofer.de> In-Reply-To: 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 Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:06:22 -0000 Hi, True, but a node can request further information as needed. What concerns me is a node in a dense network which might have 10 or 20 one= - or two- hop neighbors. Circulating detailed information about will add si= gnificantly to the load on the channel. If a node is interested in getting = to a specific other node which is a two-hop neighbor, it only really needs = information about the path to that node. Selection might involve a number o= f different paths through one-hop neighbors, but probably not all. A summar= y metric can rule out bad choices so the protocol can focus on better ones.= Given that the processes are random, point estimates are not enough for go= od decision-making. So providing information as needed will help reduce the= demand on the channel and simplify the overall process. =20 John Mullen -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: Wednesday, April 04, 2012 9:22 AM To: Dr John P Mullen Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours On Wed, Apr 4, 2012 at 16:30, Dr John P Mullen wrote= : > Hi, > > Concerning: > ------------------------ > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily gathered = by the link layer. > ------------------ > I think it is good to keep in mind that almost all of these characteristi= cs are random variables. If we try to circulate too many details, we may en= d up circulating more sampling error than information. This would be especi= ally true of a situation in which the nodes are moving fairly rapidly, rela= tive to transmission range. Also, it is possible that different estimates o= f these parameters will arrive via different routes, leaving the receiving = node with the problem of justifying the conflicts. Additionally, as the num= ber of hops increases, the latency also increases, making information less = current/reliable. > > In this case, I think less is more. It would seem better to provide a sin= gle metric, say p(reception), about nearby nodes with further detail possib= ly available through a specific query about a specific node. This would red= uce the load on the channel and simplify the process of dealing with inform= ation. I totally disagree with this. Access to layer-2 data is important for good = routing metrics, but the layer-2 cannot know what kind of routing metric th= e layer-3 is using. Mixing everything together on layer-2 and only providin= g some "dimensionless" metric value would be a total disaster, because the = layer-3 doesn't even know what it mean. Or it might not fit the global metr= ic the routing is using. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billion= s of percent in a tiny fraction of a second. Of course, that was before the= present government." From hrogge@googlemail.com Wed Apr 4 09:17:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A9E21F878E for ; Wed, 4 Apr 2012 09:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kdqFIRBTFoI for ; Wed, 4 Apr 2012 09:17:35 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D37E21F877A for ; Wed, 4 Apr 2012 09:17:35 -0700 (PDT) Received: by lagj5 with SMTP id j5so626043lag.31 for ; Wed, 04 Apr 2012 09:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=x9bHN4VXP2veh2kJQEhnekb4FMbvcWklEJ7MQZR2WQ8=; b=R9InNFk4wdd32CSo3fOXcrXpwJN80LhRCpqDJh4qVyQq+lA2vVjRs0AqBr4eM9fuv+ I2Pqmpy/Bw7THi1p2Gfw+ro1A/wJqz5F1eAQR9he0kqCTH/I5fsif6sIKviNV4Z2W5O2 kwXTk9ikhDj/wrjoreRds4i0K/zc5rb7zjDfF6l6RmSwjNmrC+lUVho0pSShg58LGpjt RkaQRcrPsKdG4ker4jkiqORBGdMJF8jaPcHz8HyfaKxysQVbBIrXtOhJ4TINiCyRDI4z JzBs+5yR9AlyO0k1L5bNooiuN63e5ctEXvG1UozrSTWLS/rA6OIGKtWilKJv3ZuqZefv /xgg== Received: by 10.152.103.134 with SMTP id fw6mr7689950lab.20.1333556254435; Wed, 04 Apr 2012 09:17:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 4 Apr 2012 09:17:14 -0700 (PDT) In-Reply-To: References: <4F7C55F9.9060408@fkie.fraunhofer.de> From: Henning Rogge Date: Wed, 4 Apr 2012 18:17:14 +0200 Message-ID: To: Dr John P Mullen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:17:36 -0000 On Wed, Apr 4, 2012 at 18:06, Dr John P Mullen wrote= : > Hi, > > True, but a node can request further information as needed. > > What concerns me is a node in a dense network which might have 10 or 20 o= ne- or two- hop neighbors. Circulating detailed information about will add = significantly to the load on the channel. If a node is interested in gettin= g to a specific other node which is a two-hop neighbor, it only really need= s information about the path to that node. Selection might involve a number= of different paths through one-hop neighbors, but probably not all. A summ= ary metric can rule out bad choices so the protocol can focus on better one= s. Given that the processes are random, point estimates are not enough for = good decision-making. So providing information as needed will help reduce t= he demand on the channel and simplify the overall process. I think a node should only offer the data it has available over DLEP, nothing more. If the MAC-layer runs a TDMA which informs it about the link metrics of 1-hop to 2-hop neighbors, DLEP should offer this data. Some radios might only a few metrics, other many more. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Wed Apr 4 09:46:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACC321F86B1 for ; Wed, 4 Apr 2012 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGzWiblPMUtG for ; Wed, 4 Apr 2012 09:46:06 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id B149F21F85DF for ; Wed, 4 Apr 2012 09:46:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="199402535" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 17:46:03 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q34Gk28O032438; Wed, 4 Apr 2012 17:46:02 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 17:46:02 +0100 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 Date: Wed, 4 Apr 2012 17:46:01 +0100 Message-ID: In-Reply-To: <291ABF54-9012-485C-832C-428A387C055D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0SduPQNZMaS+H0RPufIq5bQ2C6yQACqBwA References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" X-OriginalArrivalTime: 04 Apr 2012 16:46:02.0474 (UTC) FILETIME=[6BA694A0:01CD1282] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:46:07 -0000 That says that a device will have a MAC address. However I'm sure I've = seen a post in this thread saying that a device might not have a MAC = address. But assuming that a MAC address is always present, then the 5444 natural = thing to do would be to use the MAC addresses as the addresses in the = address block. No address compression advantages, but now it's = straightforward to associate information with those addresses, in an = indexed way, with metrics etc. being normal TLVs. A good generic 5444 = parser will then produce some sort of MAC address to other information = map or other data structure. That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put them = in an address block. So they need to go in another normal TLV. That's a = shame, but I don't see a way round it. (I can't even see a good way = round it allowing a 5444bis, unless you have many addresses and = efficiency really matters. Of course if someone can see a way they think = is better, I'm listening.) That will automatically handle the "only some = entities have type of address X issue". (There are run-time tradeoffs to = be made there, but that's another issue.) There are some different ways = to design such a TLV, or TLVs, and that would depend I think on two = things. One is the relative priorities of simplicity and efficiency. = Another is how you are going to create and use the addresses. Let's start with the simple case. An ADDRESS TLV that can contain IPv4 = or IPv6 addresses. Any given instance of the TLV can only contain one or = the other, but you can have more than one instance, even attached to the = same MAC address. (You can thank the IESG for that.) You can tell which = type of address from the length field. Or you could have two TLVs that = also redundantly told you this in the TLV type. Now if efficiency matters, we can start reinventing aspects of address = compression. But does it? (Real question, I'm not making an assumption = either way, I'm just not investing the effort in how that might be done = unless it's a real need.) (A quick comment on the runtime tradeoff. Suppose we have MAC addresses = with and without IPv4 and/or IPv6 addresses - just one IPv6 for the = moment. We could most efficiently use the ADDRESS TLV by, for example, = sorting addresses to e.g. no IP addresses, then IPv4 only, then both, = then IPv6 only. That way you can use one each multivalue ADDRESS TLV for = IPv4 and IPv6 addresses. But DLEP spec should just advise that, and = accept whatever complicated set of ADDRESS TLVs that an implementer = chooses to send.) Metrics etc. are then just standard address block TLVs. Any information not associated with MAC addresses then has to go in the = message TLV block. If creating an ADDRESS TLV, I'd put that in the global TLV space. Metric = TLVs etc. can be discussed. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 04 April 2012 16:23 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote: > I've been trying to consider the issue of 5444 fit, having an =20 > interest as an author of 5444. And despite several requests, I =20 > haven't seen a clear statement and good example(s) of what that =20 > information is. And having to dig through the draft is not the =20 > answer to that. I'm actually not worried (in this context) about the =20 > details of how many link metric types there are, for example, Actually, digging through the draft *is* the answer to that, given =20 that your knowledge & experience with RFC 5444 formatting (being a co-=20 author) is better than mine. By definition, relying on my synopsis of =20 what's going on may lead you down an incorrect path - but I'm willing =20 to try. > what matters is that there may be several pieces of information and =20 > whether in a given message each reported entity may have different =20 > subsets of associated data, or all will have the same? But how those =20 > entities are identified - by what sort of addresses and whether any =20 > are always present etc. - is critical. And if there is information =20 > not associated with addressed entities, is that one-of or multiple, =20 > and if the latter how they identified? These are the critical =20 > questions with regard to formatting, and they aren't being clearly =20 > and simply answered. > The goal is to identify *both* the radio device (it doesn't *have* to =20 be a radio, BTW) *and* the community of devices that the radio come =20 into contact with. The devices that a given RF net might come into =20 contact with WILL have associated Layer 2 addresses, they will =20 certainly have at least 1 flavor of Layer 3 address, but in my =20 deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH =20 Link-Local and Global IPv6 addresses). As mentioned in an earlier =20 post, metrics don't have meaning from a routing perspective unless/=20 until said metrics can be associated with addresses - destinations. =20 The idea is for the RF device to tell the router when it "sees" =20 another device over the RF (Neighbor Up), and when it "goes =20 away" (Neighbor Down). Upon seeing a device, there may (or may not) be =20 metrics associated with it. Those metrics may change whilst the device =20 is in RF range, hence the need for Neighbor Update. Also, Layer 3 =20 addressing could theoretically change (via modifying configuration =20 from a console, for example) whilst the device is in RF range. So the =20 ability to change the Layer 2/Layer 3 relationships, quickly, needs to =20 be there - that's why we have address ADD and DROP orders. Regards, Stan > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 > Behalf Of Stan Ratliff > Sent: 04 April 2012 15:33 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Wow. Just. Wow. > > I'm trying to figure out how we got this far off into the weeds - > specifically, how we're on the 02 version of a working group draft > (with the individual submission versions before that), and all of a > sudden there's supposedly no consensus about "WHAT information we need > in DLEP to fulfill the use-cases"????? Seriously? Did no one read the > other versions of the draft? > > To be honest, I really don't know how to respond to where this tread > has wound up. It almost looks like the participants in the thread have > suddenly come to the conclusion of "Hey, maybe we need a way for a > radio to transfer "some" data to a locally attached router! Brilliant! > I wonder what data we need?" The current DLEP draft is an attempt to > articulate JUST THAT - what data is needed. It is based on the > experiences of the co-authors in deploying these networks. So, draft- > ietf-manet-dlep-02 represents the notions of the co-authors as to WHAT > is needed. It also represents the notions of the co-authors as to HOW > the data should be transmitted. The packets fit into RFC 5444 format, > as required by the MANET working group. Past that, this discussion is > devolving into something that simply isn't useful, IMO. To camp out on > this and spin several iterations doesn't do anyone any good - > especially those that are trying to actually put products into the > field to help customers. > > Regards, > Stan > > On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: > >> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>> Can we split the DLEP discussions into 2 threads: 1) What is the >>> information that needs to be communicated between router and modem. >>> 2) How this information is encapsulated in packetBB/RFC5444? >> >> I think that sounds like a reasonable approach to resolve this >> thread, lets start with point 1). >> >> If we have a consensus about WHAT information we need in DLEP to >> fulfill the use-cases, we can move to 2). >> >> Henning Rogge >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From Chris.Dearlove@baesystems.com Wed Apr 4 09:52:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C821F869A for ; Wed, 4 Apr 2012 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0TiNFaIPckQ for ; Wed, 4 Apr 2012 09:52:23 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DF21F8613 for ; Wed, 4 Apr 2012 09:52:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="199403629" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 04 Apr 2012 17:52:22 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q34GqLOH003275; Wed, 4 Apr 2012 17:52:21 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 17:52: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 17:52:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Sdrss9aswqVu6QLOAyqfpG4e1qAAC9DhQ References: <4F7C55F9.9060408@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Dr John P Mullen" X-OriginalArrivalTime: 04 Apr 2012 16:52:21.0319 (UTC) FILETIME=[4D75BD70:01CD1283] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:52:24 -0000 I might not use Henning's "total disaster" phrase, but perhaps "won't handl= e many real use cases". An obvious one is that I don't care if a data link = is stable, with an excellent signal to noise ratio, and virtually no latenc= y, if it offers a user data rate of 16 kbit/s and I have high quality video= to send. But if I have mission critical short messages to send, give me th= at link. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 04 April 2012 16:22 To: Dr John P Mullen Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Wed, Apr 4, 2012 at 16:30, Dr John P Mullen wrote= : > Hi, > > Concerning: > ------------------------ > We most likely could add quite a few more metric related data like: > - current transmission speed of broadcasts > - link throughput > - signal strength > - signal/noise ratio > - frequency > - packet loss and other link specific layer-2 statistics easily gathered = by the link layer. > ------------------ > I think it is good to keep in mind that almost all of these characteristi= cs are random variables. If we try to circulate too many details, we may en= d up circulating more sampling error than information. This would be especi= ally true of a situation in which the nodes are moving fairly rapidly, rela= tive to transmission range. Also, it is possible that different estimates o= f these parameters will arrive via different routes, leaving the receiving = node with the problem of justifying the conflicts. Additionally, as the num= ber of hops increases, the latency also increases, making information less = current/reliable. > > In this case, I think less is more. It would seem better to provide a sin= gle metric, say p(reception), about nearby nodes with further detail possib= ly available through a specific query about a specific node. This would red= uce the load on the channel and simplify the process of dealing with inform= ation. I totally disagree with this. Access to layer-2 data is important for good routing metrics, but the layer-2 cannot know what kind of routing metric the layer-3 is using. Mixing everything together on layer-2 and only providing some "dimensionless" metric value would be a total disaster, because the layer-3 doesn't even know what it mean. Or it might not fit the global metric the routing is using. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Wed Apr 4 10:01:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2126621F863C for ; Wed, 4 Apr 2012 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGMijvHMn86R for ; Wed, 4 Apr 2012 10:01:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7EA21F8650 for ; Wed, 4 Apr 2012 10:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12680; q=dns/txt; s=iport; t=1333558866; x=1334768466; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=KziMwFBScRewy1jZuXE9LYdAwGiW5/Hku25gvqN2AAY=; b=PVtgxO9+O7l4k//T86sf2x0x3SnOHbnZVoO6w7wq5S1ChKs2Kj1vo61A co8OCVOHkNEAp9S9Lq5oHi6ex6btbE/uLlZG0UdrJ8+3mw/hw1T3wZj5z snRrpJiK/wS59LJ0U3HrQ5OLEZGhLVdVVCpWyhTx01Sj7JBmx/AqFZvGH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPd9fE+tJV2b/2dsb2JhbAA6CrghgQeCCQEBAQMBAQEBDwElEQwZAwEHBQcECxEEAQEBJwcnHwkIBgoHAhQOh2IFC5tAnmCLCQQMhFhjBJVjjkeBaYMDIoEWCA X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="69050093" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 04 Apr 2012 17:00:59 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q34H0wbj026886; Wed, 4 Apr 2012 17:00:58 GMT Message-Id: <298CEDD0-CBAB-4A21-85C2-B5594DDCB6EA@cisco.com> From: Stan Ratliff To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Apr 2012 13:00:58 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:01:08 -0000 On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: > That says that a device will have a MAC address. However I'm sure =20 > I've seen a post in this thread saying that a device might not have =20= > a MAC address. In the current implementation, every RF partner (neighbor) will have =20 some sort of Layer 2 address. There's a bit of a side conversation =20 about how a router would communicate with it's LOCAL radio - for =20 example, if the router were a card in a chassis, and the radio was the =20= next card over in the same chassis... > > But assuming that a MAC address is always present, then the 5444 =20 > natural thing to do would be to use the MAC addresses as the =20 > addresses in the address block. No address compression advantages, =20 > but now it's straightforward to associate information with those =20 > addresses, in an indexed way, with metrics etc. being normal TLVs. A =20= > good generic 5444 parser will then produce some sort of MAC address =20= > to other information map or other data structure. > Then that leave me with "router to LOCAL radio" communication - =20 information that "my radio" wants to communicate about itself, and =20 *all* of the traffic associated with it. That's currently in DLEP - =20 the notion that a radio could quickly state "the maximum data rate on =20= all destinations via me is X". Not sure how to do that while we're =20 encoding MAC addresses into address blocks. Also, that gives the =20 metrics the notion of existing "within a context" - either they apply =20= to a single RF partner (a neighbor), or all RF partners via the radio =20= - that's what the current DLEP refers to as a "peer-level metric". Regards, Stan > That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put =20= > them in an address block. So they need to go in another normal TLV. =20= > That's a shame, but I don't see a way round it. (I can't even see a =20= > good way round it allowing a 5444bis, unless you have many addresses =20= > and efficiency really matters. Of course if someone can see a way =20 > they think is better, I'm listening.) That will automatically handle =20= > the "only some entities have type of address X issue". (There are =20 > run-time tradeoffs to be made there, but that's another issue.) =20 > There are some different ways to design such a TLV, or TLVs, and =20 > that would depend I think on two things. One is the relative =20 > priorities of simplicity and efficiency. Another is how you are =20 > going to create and use the addresses. > > Let's start with the simple case. An ADDRESS TLV that can contain =20 > IPv4 or IPv6 addresses. Any given instance of the TLV can only =20 > contain one or the other, but you can have more than one instance, =20 > even attached to the same MAC address. (You can thank the IESG for =20 > that.) You can tell which type of address from the length field. Or =20= > you could have two TLVs that also redundantly told you this in the =20 > TLV type. > > Now if efficiency matters, we can start reinventing aspects of =20 > address compression. But does it? (Real question, I'm not making an =20= > assumption either way, I'm just not investing the effort in how that =20= > might be done unless it's a real need.) > > (A quick comment on the runtime tradeoff. Suppose we have MAC =20 > addresses with and without IPv4 and/or IPv6 addresses - just one =20 > IPv6 for the moment. We could most efficiently use the ADDRESS TLV =20 > by, for example, sorting addresses to e.g. no IP addresses, then =20 > IPv4 only, then both, then IPv6 only. That way you can use one each =20= > multivalue ADDRESS TLV for IPv4 and IPv6 addresses. But DLEP spec =20 > should just advise that, and accept whatever complicated set of =20 > ADDRESS TLVs that an implementer chooses to send.) > > Metrics etc. are then just standard address block TLVs. > > Any information not associated with MAC addresses then has to go in =20= > the message TLV block. > > If creating an ADDRESS TLV, I'd put that in the global TLV space. =20 > Metric TLVs etc. can be discussed. > > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 04 April 2012 16:23 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote: > >> I've been trying to consider the issue of 5444 fit, having an >> interest as an author of 5444. And despite several requests, I >> haven't seen a clear statement and good example(s) of what that >> information is. And having to dig through the draft is not the >> answer to that. I'm actually not worried (in this context) about the >> details of how many link metric types there are, for example, > > Actually, digging through the draft *is* the answer to that, given > that your knowledge & experience with RFC 5444 formatting (being a co- > author) is better than mine. By definition, relying on my synopsis of > what's going on may lead you down an incorrect path - but I'm willing > to try. > >> what matters is that there may be several pieces of information and >> whether in a given message each reported entity may have different >> subsets of associated data, or all will have the same? But how those >> entities are identified - by what sort of addresses and whether any >> are always present etc. - is critical. And if there is information >> not associated with addressed entities, is that one-of or multiple, >> and if the latter how they identified? These are the critical >> questions with regard to formatting, and they aren't being clearly >> and simply answered. >> > > The goal is to identify *both* the radio device (it doesn't *have* to > be a radio, BTW) *and* the community of devices that the radio come > into contact with. The devices that a given RF net might come into > contact with WILL have associated Layer 2 addresses, they will > certainly have at least 1 flavor of Layer 3 address, but in my > deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH > Link-Local and Global IPv6 addresses). As mentioned in an earlier > post, metrics don't have meaning from a routing perspective unless/ > until said metrics can be associated with addresses - destinations. > The idea is for the RF device to tell the router when it "sees" > another device over the RF (Neighbor Up), and when it "goes > away" (Neighbor Down). Upon seeing a device, there may (or may not) be > metrics associated with it. Those metrics may change whilst the device > is in RF range, hence the need for Neighbor Update. Also, Layer 3 > addressing could theoretically change (via modifying configuration > from a console, for example) whilst the device is in RF range. So the > ability to change the Layer 2/Layer 3 relationships, quickly, needs to > be there - that's why we have address ADD and DROP orders. > > Regards, > Stan > > > >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf Of Stan Ratliff >> Sent: 04 April 2012 15:33 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Wow. Just. Wow. >> >> I'm trying to figure out how we got this far off into the weeds - >> specifically, how we're on the 02 version of a working group draft >> (with the individual submission versions before that), and all of a >> sudden there's supposedly no consensus about "WHAT information we =20 >> need >> in DLEP to fulfill the use-cases"????? Seriously? Did no one read =20= >> the >> other versions of the draft? >> >> To be honest, I really don't know how to respond to where this tread >> has wound up. It almost looks like the participants in the thread =20 >> have >> suddenly come to the conclusion of "Hey, maybe we need a way for a >> radio to transfer "some" data to a locally attached router! =20 >> Brilliant! >> I wonder what data we need?" The current DLEP draft is an attempt to >> articulate JUST THAT - what data is needed. It is based on the >> experiences of the co-authors in deploying these networks. So, draft- >> ietf-manet-dlep-02 represents the notions of the co-authors as to =20 >> WHAT >> is needed. It also represents the notions of the co-authors as to HOW >> the data should be transmitted. The packets fit into RFC 5444 format, >> as required by the MANET working group. Past that, this discussion is >> devolving into something that simply isn't useful, IMO. To camp out =20= >> on >> this and spin several iterations doesn't do anyone any good - >> especially those that are trying to actually put products into the >> field to help customers. >> >> Regards, >> Stan >> >> On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: >> >>> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>>> Can we split the DLEP discussions into 2 threads: 1) What is the >>>> information that needs to be communicated between router and modem. >>>> 2) How this information is encapsulated in packetBB/RFC5444? >>> >>> I think that sounds like a reasonable approach to resolve this >>> thread, lets start with point 1). >>> >>> If we have a consensus about WHAT information we need in DLEP to >>> fulfill the use-cases, we can move to 2). >>> >>> Henning Rogge >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://=20 >>> www.fkie.fraunhofer.de >>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > From rick.taylor@cassidian.com Wed Apr 4 10:08:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C2521F8762 for ; Wed, 4 Apr 2012 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqkX25hYUAxx for ; Wed, 4 Apr 2012 10:08:53 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F421F8755 for ; Wed, 4 Apr 2012 10:08:52 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 04 Apr 2012 19:08:49 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 4 Apr 2012 19:08:49 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 19:08:48 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 19:08:48 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 18:08:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2012 18:08:29 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035ABD8C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0SduPQNZMaS+H0RPufIq5bQ2C6yQACqBwAAACInYA= References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de><29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com><291ABF54-9012-485C-832C-428A387C055D@cisco.com> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" X-OriginalArrivalTime: 04 Apr 2012 17:08:58.0045 (UTC) FILETIME=[9F8E0ED0:01CD1285] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18818.000 X-TM-AS-Result: No--63.321900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:08:54 -0000 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Dearlove, Christopher (UK) >=20 > That says that a device will have a MAC address. However I'm sure I've > seen a post in this thread saying that a device might not have a MAC > address. My reading of Stan's draft agrees, all neighbour messages have a MAC = address. There are however peer messages (between local router and = modem) that do not. > But assuming that a MAC address is always present, then the 5444 = natural > thing to do would be to use the MAC addresses as the addresses in the > address block. No address compression advantages, but now it's > straightforward to associate information with those addresses, in an > indexed way, with metrics etc. being normal TLVs. A good generic 5444 > parser will then produce some sort of MAC address to other information = map > or other data structure. Yes, I think Henning and I have been proposing this. > That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put = them > in an address block. So they need to go in another normal TLV. That's = a > shame, but I don't see a way round it. (I can't even see a good way = round > it allowing a 5444bis, unless you have many addresses and efficiency > really matters. Of course if someone can see a way they think is = better, > I'm listening.) That will automatically handle the "only some entities > have type of address X issue". (There are run-time tradeoffs to be = made > there, but that's another issue.) There are some different ways to = design > such a TLV, or TLVs, and that would depend I think on two things. One = is > the relative priorities of simplicity and efficiency. Another is how = you > are going to create and use the addresses. There is already an IPv4 and IPv6 address TLV in the draft, and = consensus seems to be that they are the best way to express the = addressing information in RFC5444 terms. The IP addresses directly link = to the MAC address of the address-block they can appear in, they are not = separate. > Let's start with the simple case. An ADDRESS TLV that can contain IPv4 = or > IPv6 addresses. Any given instance of the TLV can only contain one or = the > other, but you can have more than one instance, even attached to the = same > MAC address. (You can thank the IESG for that.) You can tell which = type of > address from the length field. Or you could have two TLVs that also > redundantly told you this in the TLV type. See my comment above concerning the current draft. Yes, one could = consolidate to one standard Address TLV, using the length to determine = the address family. > Now if efficiency matters, we can start reinventing aspects of address > compression. But does it? (Real question, I'm not making an assumption > either way, I'm just not investing the effort in how that might be = done > unless it's a real need.) Efficiency is of little interest in reality - the traffic is only = flowing across a local fixed link, not across the MANET. > (A quick comment on the runtime tradeoff. Suppose we have MAC = addresses > with and without IPv4 and/or IPv6 addresses - just one IPv6 for the > moment. We could most efficiently use the ADDRESS TLV by, for example, > sorting addresses to e.g. no IP addresses, then IPv4 only, then both, = then > IPv6 only. That way you can use one each multivalue ADDRESS TLV for = IPv4 > and IPv6 addresses. But DLEP spec should just advise that, and accept > whatever complicated set of ADDRESS TLVs that an implementer chooses = to > send.) Really not needed. The MAC address is the only mandatory address used = with neighbours. Use MAC addresses in address-blocks, and carry any = additional addresses associated with that MAC as Address-block data. > Metrics etc. are then just standard address block TLVs. Yes, agreed. > Any information not associated with MAC addresses then has to go in = the > message TLV block. Yes, agreed. > If creating an ADDRESS TLV, I'd put that in the global TLV space. = Metric > TLVs etc. can be discussed. I'd rather not create them, except as 'data' TLVs in an MAC-address = Address-Block. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 04 April 2012 16:23 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote: >=20 > > I've been trying to consider the issue of 5444 fit, having an > > interest as an author of 5444. And despite several requests, I > > haven't seen a clear statement and good example(s) of what that > > information is. And having to dig through the draft is not the > > answer to that. I'm actually not worried (in this context) about the > > details of how many link metric types there are, for example, >=20 > Actually, digging through the draft *is* the answer to that, given > that your knowledge & experience with RFC 5444 formatting (being a co- > author) is better than mine. By definition, relying on my synopsis of > what's going on may lead you down an incorrect path - but I'm willing > to try. >=20 > > what matters is that there may be several pieces of information and > > whether in a given message each reported entity may have different > > subsets of associated data, or all will have the same? But how those > > entities are identified - by what sort of addresses and whether any > > are always present etc. - is critical. And if there is information > > not associated with addressed entities, is that one-of or multiple, > > and if the latter how they identified? These are the critical > > questions with regard to formatting, and they aren't being clearly > > and simply answered. > > >=20 > The goal is to identify *both* the radio device (it doesn't *have* to > be a radio, BTW) *and* the community of devices that the radio come > into contact with. The devices that a given RF net might come into > contact with WILL have associated Layer 2 addresses, they will > certainly have at least 1 flavor of Layer 3 address, but in my > deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH > Link-Local and Global IPv6 addresses). As mentioned in an earlier > post, metrics don't have meaning from a routing perspective unless/ > until said metrics can be associated with addresses - destinations. > The idea is for the RF device to tell the router when it "sees" > another device over the RF (Neighbor Up), and when it "goes > away" (Neighbor Down). Upon seeing a device, there may (or may not) be > metrics associated with it. Those metrics may change whilst the device > is in RF range, hence the need for Neighbor Update. Also, Layer 3 > addressing could theoretically change (via modifying configuration > from a console, for example) whilst the device is in RF range. So the > ability to change the Layer 2/Layer 3 relationships, quickly, needs to > be there - that's why we have address ADD and DROP orders. >=20 > Regards, > Stan >=20 >=20 >=20 > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > > Behalf Of Stan Ratliff > > Sent: 04 April 2012 15:33 > > To: Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] DLEP and multi-hop neighbours > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > Wow. Just. Wow. > > > > I'm trying to figure out how we got this far off into the weeds - > > specifically, how we're on the 02 version of a working group draft > > (with the individual submission versions before that), and all of a > > sudden there's supposedly no consensus about "WHAT information we = need > > in DLEP to fulfill the use-cases"????? Seriously? Did no one read = the > > other versions of the draft? > > > > To be honest, I really don't know how to respond to where this tread > > has wound up. It almost looks like the participants in the thread = have > > suddenly come to the conclusion of "Hey, maybe we need a way for a > > radio to transfer "some" data to a locally attached router! = Brilliant! > > I wonder what data we need?" The current DLEP draft is an attempt to > > articulate JUST THAT - what data is needed. It is based on the > > experiences of the co-authors in deploying these networks. So, = draft- > > ietf-manet-dlep-02 represents the notions of the co-authors as to = WHAT > > is needed. It also represents the notions of the co-authors as to = HOW > > the data should be transmitted. The packets fit into RFC 5444 = format, > > as required by the MANET working group. Past that, this discussion = is > > devolving into something that simply isn't useful, IMO. To camp out = on > > this and spin several iterations doesn't do anyone any good - > > especially those that are trying to actually put products into the > > field to help customers. > > > > Regards, > > Stan > > > > On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: > > > >> On 04/04/2012 02:43 PM, Rick Taylor wrote: > >>> Can we split the DLEP discussions into 2 threads: 1) What is the > >>> information that needs to be communicated between router and = modem. > >>> 2) How this information is encapsulated in packetBB/RFC5444? > >> > >> I think that sounds like a reasonable approach to resolve this > >> thread, lets start with point 1). > >> > >> If we have a consensus about WHAT information we need in DLEP to > >> fulfill the use-cases, we can move to 2). > >> > >> Henning Rogge > >> -- > >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE > >> Kommunikationssysteme (KOM) > >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > >> Telefon +49 228 9435-961, Fax +49 228 9435 685 > >> mailto:henning.rogge@fkie.fraunhofer.de = http://www.fkie.fraunhofer.de > >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Wed Apr 4 10:14:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADACC21F87EB for ; Wed, 4 Apr 2012 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB1IdlEj4Pui for ; Wed, 4 Apr 2012 10:14:25 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id A275D21F87E8 for ; Wed, 4 Apr 2012 10:14:24 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 04 Apr 2012 19:14:23 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 4 Apr 2012 19:14:22 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 19:14:22 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 19:14:22 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 18:14:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2012 18:14:03 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0ShMwZ7PdGdPfPSP6Eot8zTq7bmQAASlpg References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de><29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com><291ABF54-9012-485C-832C-428A387C055D@cisco.com> From: "Rick Taylor" To: "Stan Ratliff" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 04 Apr 2012 17:14:31.0319 (UTC) FILETIME=[6633A270:01CD1286] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18818.000 X-TM-AS-Result: No--30.501200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:14:25 -0000 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Stan Ratliff >=20 > On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >=20 > > That says that a device will have a MAC address. However I'm sure > > I've seen a post in this thread saying that a device might not have > > a MAC address. >=20 > In the current implementation, every RF partner (neighbor) will have > some sort of Layer 2 address. There's a bit of a side conversation > about how a router would communicate with it's LOCAL radio - for > example, if the router were a card in a chassis, and the radio was the > next card over in the same chassis... I always imagined these LOCAL messages would remain as is specified in the draft: Message-Block TLVs... =20 >=20 > > > > But assuming that a MAC address is always present, then the 5444 > > natural thing to do would be to use the MAC addresses as the > > addresses in the address block. No address compression advantages, > > but now it's straightforward to associate information with those > > addresses, in an indexed way, with metrics etc. being normal TLVs. A > > good generic 5444 parser will then produce some sort of MAC address > > to other information map or other data structure. > > > Then that leave me with "router to LOCAL radio" communication - > information that "my radio" wants to communicate about itself, and > *all* of the traffic associated with it. That's currently in DLEP - > the notion that a radio could quickly state "the maximum data rate on > all destinations via me is X". Not sure how to do that while we're > encoding MAC addresses into address blocks. Also, that gives the > metrics the notion of existing "within a context" - either they apply > to a single RF partner (a neighbor), or all RF partners via the radio > - that's what the current DLEP refers to as a "peer-level metric". No association with a neighbour, no Address-Block TLVs, just Message-Block TLVs. Rick Taylor ********* snip *********** From hrogge@googlemail.com Wed Apr 4 10:23:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D483521F8732 for ; Wed, 4 Apr 2012 10:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yoDQje4AhIP for ; Wed, 4 Apr 2012 10:23:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E62AF21F862F for ; Wed, 4 Apr 2012 10:23:21 -0700 (PDT) Received: by lagj5 with SMTP id j5so700418lag.31 for ; Wed, 04 Apr 2012 10:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8G3V0hrwndew0o8XHPZ3eJZU2REqVsoYqynlpYjM748=; b=Mw0ib4kilK65Hm98PyfHyIJtar6+T1kupZ/AfqzF9gYTGLfBedNCCA5zBQKOkouxRN 7mHnT0+r8XRxc+umeE1O1feqPn2bTJgrE5Jcllx3XM5JHP5GGzco/1vfHI5astFblP/Y sPRMykhbaX0eAlzFTd2Z7rZdka2afb0576ZDlMQXF39XSJjeV93HEnOWq396PJNI49Xz qmlWYpoldfEVMqiN4qTOW1Nu2gCdgji+07vI3iGRhKE/QhMigenCC8BPHwHEEKcwRwno G3/bKAAJWyp7wwNjh2SAgP0gbV+98o1C8Muioq+glxxMDzI3UsET9Vu3A2uiqyQr52rg pi8A== Received: by 10.152.148.234 with SMTP id tv10mr19530778lab.41.1333560200813; Wed, 04 Apr 2012 10:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 4 Apr 2012 10:23:00 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Wed, 4 Apr 2012 19:23:00 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:23:23 -0000 On Wed, Apr 4, 2012 at 19:14, Rick Taylor wrote: >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of >> Stan Ratliff >> >> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >> >> > That says that a device will have a MAC address. However I'm sure >> > I've seen a post in this thread saying that a device might not have >> > a MAC address. >> >> In the current implementation, every RF partner (neighbor) will have >> some sort of Layer 2 address. There's a bit of a side conversation >> about how a router would communicate with it's LOCAL radio - for >> example, if the router were a card in a chassis, and the radio was the >> next card over in the same chassis... > > I always imagined these LOCAL messages would remain as is specified in > the draft: Message-Block TLVs... Or a series of Message-TLVs, one for each parameter we need. This makes it very easy to leave out parameters that are not necessary and even add optional data to DLEP orders later. >> > But assuming that a MAC address is always present, then the 5444 >> > natural thing to do would be to use the MAC addresses as the >> > addresses in the address block. No address compression advantages, >> > but now it's straightforward to associate information with those >> > addresses, in an indexed way, with metrics etc. being normal TLVs. A >> > good generic 5444 parser will then produce some sort of MAC address >> > to other information map or other data structure. >> > >> Then that leave me with "router to LOCAL radio" communication - >> information that "my radio" wants to communicate about itself, and >> *all* of the traffic associated with it. That's currently in DLEP - >> the notion that a radio could quickly state "the maximum data rate on >> all destinations via me is X". Not sure how to do that while we're >> encoding MAC addresses into address blocks. Also, that gives the >> metrics the notion of existing "within a context" - either they apply >> to a single RF partner (a neighbor), or all RF partners via the radio >> - that's what the current DLEP refers to as a "peer-level metric". > > No association with a neighbour, no Address-Block TLVs, just > Message-Block TLVs. Yes, message TLVs are a good solution to transport information about the whole radio. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Thu Apr 5 02:02:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C320321F85D4 for ; Thu, 5 Apr 2012 02:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqCqageLBUBo for ; Thu, 5 Apr 2012 02:02:21 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9C47121F8572 for ; Thu, 5 Apr 2012 02:02:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="199512936" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 10:02:19 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3592J4w015728; Thu, 5 Apr 2012 10:02:19 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 10:02:19 +0100 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 Date: Thu, 5 Apr 2012 10:01:39 +0100 Message-ID: In-Reply-To: <298CEDD0-CBAB-4A21-85C2-B5594DDCB6EA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0ShIf9G3nG1C9lTiWjMxU4GNSyGgAhbEBg References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <298CEDD0-CBAB-4A21-85C2-B5594DDCB6EA@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" X-OriginalArrivalTime: 05 Apr 2012 09:02:19.0068 (UTC) FILETIME=[CE057FC0:01CD130A] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:02:22 -0000 The local information could go in the message TLV block. If it's of a = similar nature to the non-local information, then you need to duplicate = the TLVs, but that's just paperwork (and IANA are encouraged to give it = the same number by some text in 5444, IIRC). That's fine as long as any = DLEP message has a well-defined (by source IP address if nothing else, = but there's also originator IP address, or you could invent a TLV) local = entity that the message TLV block refers to. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 04 April 2012 18:01 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: > That says that a device will have a MAC address. However I'm sure =20 > I've seen a post in this thread saying that a device might not have =20 > a MAC address. In the current implementation, every RF partner (neighbor) will have =20 some sort of Layer 2 address. There's a bit of a side conversation =20 about how a router would communicate with it's LOCAL radio - for =20 example, if the router were a card in a chassis, and the radio was the =20 next card over in the same chassis... > > But assuming that a MAC address is always present, then the 5444 =20 > natural thing to do would be to use the MAC addresses as the =20 > addresses in the address block. No address compression advantages, =20 > but now it's straightforward to associate information with those =20 > addresses, in an indexed way, with metrics etc. being normal TLVs. A =20 > good generic 5444 parser will then produce some sort of MAC address =20 > to other information map or other data structure. > Then that leave me with "router to LOCAL radio" communication - =20 information that "my radio" wants to communicate about itself, and =20 *all* of the traffic associated with it. That's currently in DLEP - =20 the notion that a radio could quickly state "the maximum data rate on =20 all destinations via me is X". Not sure how to do that while we're =20 encoding MAC addresses into address blocks. Also, that gives the =20 metrics the notion of existing "within a context" - either they apply =20 to a single RF partner (a neighbor), or all RF partners via the radio =20 - that's what the current DLEP refers to as a "peer-level metric". Regards, Stan > That leaves the IPv4 and IPv6 addresses. Unfortunately we can't put =20 > them in an address block. So they need to go in another normal TLV. =20 > That's a shame, but I don't see a way round it. (I can't even see a =20 > good way round it allowing a 5444bis, unless you have many addresses =20 > and efficiency really matters. Of course if someone can see a way =20 > they think is better, I'm listening.) That will automatically handle =20 > the "only some entities have type of address X issue". (There are =20 > run-time tradeoffs to be made there, but that's another issue.) =20 > There are some different ways to design such a TLV, or TLVs, and =20 > that would depend I think on two things. One is the relative =20 > priorities of simplicity and efficiency. Another is how you are =20 > going to create and use the addresses. > > Let's start with the simple case. An ADDRESS TLV that can contain =20 > IPv4 or IPv6 addresses. Any given instance of the TLV can only =20 > contain one or the other, but you can have more than one instance, =20 > even attached to the same MAC address. (You can thank the IESG for =20 > that.) You can tell which type of address from the length field. Or =20 > you could have two TLVs that also redundantly told you this in the =20 > TLV type. > > Now if efficiency matters, we can start reinventing aspects of =20 > address compression. But does it? (Real question, I'm not making an =20 > assumption either way, I'm just not investing the effort in how that =20 > might be done unless it's a real need.) > > (A quick comment on the runtime tradeoff. Suppose we have MAC =20 > addresses with and without IPv4 and/or IPv6 addresses - just one =20 > IPv6 for the moment. We could most efficiently use the ADDRESS TLV =20 > by, for example, sorting addresses to e.g. no IP addresses, then =20 > IPv4 only, then both, then IPv6 only. That way you can use one each =20 > multivalue ADDRESS TLV for IPv4 and IPv6 addresses. But DLEP spec =20 > should just advise that, and accept whatever complicated set of =20 > ADDRESS TLVs that an implementer chooses to send.) > > Metrics etc. are then just standard address block TLVs. > > Any information not associated with MAC addresses then has to go in =20 > the message TLV block. > > If creating an ADDRESS TLV, I'd put that in the global TLV space. =20 > Metric TLVs etc. can be discussed. > > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 04 April 2012 16:23 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Apr 4, 2012, at 10:54 AM, Dearlove, Christopher (UK) wrote: > >> I've been trying to consider the issue of 5444 fit, having an >> interest as an author of 5444. And despite several requests, I >> haven't seen a clear statement and good example(s) of what that >> information is. And having to dig through the draft is not the >> answer to that. I'm actually not worried (in this context) about the >> details of how many link metric types there are, for example, > > Actually, digging through the draft *is* the answer to that, given > that your knowledge & experience with RFC 5444 formatting (being a co- > author) is better than mine. By definition, relying on my synopsis of > what's going on may lead you down an incorrect path - but I'm willing > to try. > >> what matters is that there may be several pieces of information and >> whether in a given message each reported entity may have different >> subsets of associated data, or all will have the same? But how those >> entities are identified - by what sort of addresses and whether any >> are always present etc. - is critical. And if there is information >> not associated with addressed entities, is that one-of or multiple, >> and if the latter how they identified? These are the critical >> questions with regard to formatting, and they aren't being clearly >> and simply answered. >> > > The goal is to identify *both* the radio device (it doesn't *have* to > be a radio, BTW) *and* the community of devices that the radio come > into contact with. The devices that a given RF net might come into > contact with WILL have associated Layer 2 addresses, they will > certainly have at least 1 flavor of Layer 3 address, but in my > deployments, they will have BOTH IPv4 and IPv6 addresses (and BOTH > Link-Local and Global IPv6 addresses). As mentioned in an earlier > post, metrics don't have meaning from a routing perspective unless/ > until said metrics can be associated with addresses - destinations. > The idea is for the RF device to tell the router when it "sees" > another device over the RF (Neighbor Up), and when it "goes > away" (Neighbor Down). Upon seeing a device, there may (or may not) be > metrics associated with it. Those metrics may change whilst the device > is in RF range, hence the need for Neighbor Update. Also, Layer 3 > addressing could theoretically change (via modifying configuration > from a console, for example) whilst the device is in RF range. So the > ability to change the Layer 2/Layer 3 relationships, quickly, needs to > be there - that's why we have address ADD and DROP orders. > > Regards, > Stan > > > >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf Of Stan Ratliff >> Sent: 04 April 2012 15:33 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Wow. Just. Wow. >> >> I'm trying to figure out how we got this far off into the weeds - >> specifically, how we're on the 02 version of a working group draft >> (with the individual submission versions before that), and all of a >> sudden there's supposedly no consensus about "WHAT information we =20 >> need >> in DLEP to fulfill the use-cases"????? Seriously? Did no one read =20 >> the >> other versions of the draft? >> >> To be honest, I really don't know how to respond to where this tread >> has wound up. It almost looks like the participants in the thread =20 >> have >> suddenly come to the conclusion of "Hey, maybe we need a way for a >> radio to transfer "some" data to a locally attached router! =20 >> Brilliant! >> I wonder what data we need?" The current DLEP draft is an attempt to >> articulate JUST THAT - what data is needed. It is based on the >> experiences of the co-authors in deploying these networks. So, draft- >> ietf-manet-dlep-02 represents the notions of the co-authors as to =20 >> WHAT >> is needed. It also represents the notions of the co-authors as to HOW >> the data should be transmitted. The packets fit into RFC 5444 format, >> as required by the MANET working group. Past that, this discussion is >> devolving into something that simply isn't useful, IMO. To camp out =20 >> on >> this and spin several iterations doesn't do anyone any good - >> especially those that are trying to actually put products into the >> field to help customers. >> >> Regards, >> Stan >> >> On Apr 4, 2012, at 8:51 AM, Henning Rogge wrote: >> >>> On 04/04/2012 02:43 PM, Rick Taylor wrote: >>>> Can we split the DLEP discussions into 2 threads: 1) What is the >>>> information that needs to be communicated between router and modem. >>>> 2) How this information is encapsulated in packetBB/RFC5444? >>> >>> I think that sounds like a reasonable approach to resolve this >>> thread, lets start with point 1). >>> >>> If we have a consensus about WHAT information we need in DLEP to >>> fulfill the use-cases, we can move to 2). >>> >>> Henning Rogge >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://=20 >>> www.fkie.fraunhofer.de >>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > From Chris.Dearlove@baesystems.com Thu Apr 5 02:07:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88A21F8656 for ; Thu, 5 Apr 2012 02:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bIGhYxrGIsY for ; Thu, 5 Apr 2012 02:07:16 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4363E21F8653 for ; Thu, 5 Apr 2012 02:07:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="199515555" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 10:07:15 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q35972fI018815; Thu, 5 Apr 2012 10:07:14 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 10:06:34 +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: 7bit Date: Thu, 5 Apr 2012 10:06:17 +0100 Message-ID: In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035ABD8C@SUKNPT8106.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0SduPQNZMaS+H0RPufIq5bQ2C6yQACqBwAAACInYAAId2pUA== References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de><29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com><291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD8C@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Rick Taylor" , "Stan Ratliff" X-OriginalArrivalTime: 05 Apr 2012 09:06:34.0202 (UTC) FILETIME=[6617DBA0:01CD130B] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:07:17 -0000 Rick > Me >> (A quick comment on the runtime tradeoff. Suppose we have MAC addresses >> with and without IPv4 and/or IPv6 addresses - just one IPv6 for the >> moment. We could most efficiently use the ADDRESS TLV by, for example, >> sorting addresses to e.g. no IP addresses, then IPv4 only, then both, then >> IPv6 only. That way you can use one each multivalue ADDRESS TLV for IPv4 >> and IPv6 addresses. But DLEP spec should just advise that, and accept >> whatever complicated set of ADDRESS TLVs that an implementer chooses to >> send.) > Really not needed. The MAC address is the only mandatory address used with > neighbours. Use MAC addresses in address-blocks, and carry any additional > addresses associated with that MAC as Address-block data. I think that's missing my point. But it's secondary and we can get back to it later. >> If creating an ADDRESS TLV, I'd put that in the global TLV space. Metric >> TLVs etc. can be discussed. > I'd rather not create them, except as 'data' TLVs in an MAC-address Address-Block. I'm not sure what you mean that's different to what I mean. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Apr 5 02:15:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D0F21F8692 for ; Thu, 5 Apr 2012 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbV0sbwSit5x for ; Thu, 5 Apr 2012 02:15:26 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75B21F8691 for ; Thu, 5 Apr 2012 02:15:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="199518794" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 10:15:16 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q359FEx3024085; Thu, 5 Apr 2012 10:15:15 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 10:15: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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 10:15:10 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0Sh6T3ZpVAletiTtue2nyaB2RSlQAg8f0A References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Rick Taylor" X-OriginalArrivalTime: 05 Apr 2012 09:15:14.0985 (UTC) FILETIME=[9C810990:01CD130C] Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:15:26 -0000 I had in mind separate TLVs, both address block and message, for each meani= ngful piece of data. Thus, for example, we might have a TLV for data rate, a TLV for delay etc. = These might use different subtypes of a single TLV type, which we might use= the collective term metric for. There mcould be message and address block = versions of the TLV, identical except for the TLV space. Those in an addres= s block TLV block then indicate which MAC address they apply to, implicitly= a neighbour, and those in the message TLV block apply locally. If we have = a data rate but not a delay for a neighbour then there is no TLV of the del= ay type associated with that MAC address.=20 (Actually, in another secondary point, it might make things easier if the m= etric value allowed an "unknown" option, probably coded zero, to allow mult= ivalue TLVs to span over ranges including some addresses with known e.g. de= lays and some without. But let's not get hung up on this point now.) IP addresses are then another meaningful piece of data in the sense of my f= irst paragraph above. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: 04 April 2012 18:23 To: Rick Taylor Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Wed, Apr 4, 2012 at 19:14, Rick Taylor wrote= : >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of >> Stan Ratliff >> >> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >> >> > That says that a device will have a MAC address. However I'm sure >> > I've seen a post in this thread saying that a device might not have >> > a MAC address. >> >> In the current implementation, every RF partner (neighbor) will have >> some sort of Layer 2 address. There's a bit of a side conversation >> about how a router would communicate with it's LOCAL radio - for >> example, if the router were a card in a chassis, and the radio was the >> next card over in the same chassis... > > I always imagined these LOCAL messages would remain as is specified in > the draft: Message-Block TLVs... Or a series of Message-TLVs, one for each parameter we need. This makes it very easy to leave out parameters that are not necessary and even add optional data to DLEP orders later. >> > But assuming that a MAC address is always present, then the 5444 >> > natural thing to do would be to use the MAC addresses as the >> > addresses in the address block. No address compression advantages, >> > but now it's straightforward to associate information with those >> > addresses, in an indexed way, with metrics etc. being normal TLVs. A >> > good generic 5444 parser will then produce some sort of MAC address >> > to other information map or other data structure. >> > >> Then that leave me with "router to LOCAL radio" communication - >> information that "my radio" wants to communicate about itself, and >> *all* of the traffic associated with it. That's currently in DLEP - >> the notion that a radio could quickly state "the maximum data rate on >> all destinations via me is X". Not sure how to do that while we're >> encoding MAC addresses into address blocks. Also, that gives the >> metrics the notion of existing "within a context" - either they apply >> to a single RF partner (a neighbor), or all RF partners via the radio >> - that's what the current DLEP refers to as a "peer-level metric". > > No association with a neighbour, no Address-Block TLVs, just > Message-Block TLVs. Yes, message TLVs are a good solution to transport information about the whole radio. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Apr 5 02:26:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832EA21F8528 for ; Thu, 5 Apr 2012 02:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LQDkFzDNbn6 for ; Thu, 5 Apr 2012 02:26:38 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCB621F84F0 for ; Thu, 5 Apr 2012 02:26:38 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SFixg-0004Ez-BZ; Thu, 05 Apr 2012 11:26:36 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SFixg-0006OS-8s; Thu, 05 Apr 2012 11:26:36 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 11:26:36 +0200 Message-ID: <4F7D654B.4020909@fkie.fraunhofer.de> Date: Thu, 05 Apr 2012 11:26:35 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <298CEDD0-CBAB-4A21-85C2-B5594DDCB6EA@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030707030701060906060908" X-OriginalArrivalTime: 05 Apr 2012 09:26:36.0112 (UTC) FILETIME=[327CC500:01CD130E] X-Virus-Scanned: yes (ClamAV 0.97.3/14744/Thu Apr 5 03:59:59 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9fba06858ea504e244212894029289c9 Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:26:39 -0000 This is a cryptographically signed message in MIME format. --------------ms030707030701060906060908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/05/2012 11:01 AM, Dearlove, Christopher (UK) wrote: > The local information could go in the message TLV block. If it's of a > similar nature to the non-local information, then you need to > duplicate the TLVs, but that's just paperwork (and IANA are > encouraged to give it the same number by some text in 5444, IIRC). agreed. > That's fine as long as any DLEP message has a well-defined (by source > IP address if nothing else, but there's also originator IP address, > or you could invent a TLV) local entity that the message TLV block > refers to. Source-IP doesn't work, because DLEP should be transport protocol=20 independent. DLEP over USB would have no IPs on both ends for example. But instead of originator-IP (DLEP will most likely use 6 byte=20 addresses, so no IP as originator), we could use the radios MAC (which=20 must exist somewhere to allow it working in an IP network) as the=20 originator-address of the RFC5444 message. On 04/05/2012 11:15 AM, Dearlove, Christopher (UK) wrote: > I had in mind separate TLVs, both address block and message, for each = meaningful piece of data. > > Thus, for example, we might have a TLV for data rate, a TLV for delay = etc. These might use different subtypes of a single TLV type, which we=20 might use the collective term metric for. There mcould be message and=20 address block versions of the TLV, identical except for the TLV space.=20 Those in an address block TLV block then indicate which MAC address they = apply to, implicitly a neighbour, and those in the message TLV block=20 apply locally. If we have a data rate but not a delay for a neighbour=20 then there is no TLV of the delay type associated with that MAC address. Using one TLV-type for each kind data format might work too. One TLV=20 tpye for all kind of "data rates" (always x bytes measured in bits/s),=20 one for counters, one for signal strength, ... > (Actually, in another secondary point, it might make things easier if = the metric value allowed an "unknown" option, probably coded zero, to=20 allow multivalue TLVs to span over ranges including some addresses with=20 known e.g. delays and some without. But let's not get hung up on this=20 point now.) I think we do not need the "unknown" encoding. In most radio=20 implementations we have a certain metric type for each of the neighbors=20 or for none. If we want a "unknown" encoding, it should not be a value that is also=20 included in the valid range of the metric. Otherwise we could not see=20 the difference between "not measured" and a metric that is accidentally=20 the 'default value'. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030707030701060906060908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MDUwOTI2MzVaMCMGCSqGSIb3DQEJBDEWBBSFzqh1ZR9+M6gTi7wOXbh5rpjztjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBFjf7N7Q1Oj7ipq14vsWhT9f/DafLjAPF73sTFjAgNGBYvwyZoykf7FSCCVLO6 8bxvNR2eynozIN1Gvi1ciKDCnbgNrzHEEKLzrK4vahZ/oq8JCz7uxaooFuugEVer8bjVQfnJ csES6axKYcNFYeIr4vRGmD8+IbVLJYpMD0edOTxx7DI0DDuC0d7x+YQ7Ps9UMvxTKgk+qqiC ZZmaEpJXkEA6JvgEAQ9jx72BJipFDp4dVAlb8TYR8Fg9i5MfW5a9Nfa1HzNNt7t/g58i2Ddi J7P1bzu39WQ4NKPhewa2cmx0KIzgGnWHc1gd7O2XVyoWhJycyQNRyfQAT11nKPnLAAAAAAAA --------------ms030707030701060906060908-- From Chris.Dearlove@baesystems.com Thu Apr 5 02:31:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1C721F85D4 for ; Thu, 5 Apr 2012 02:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6El+RAV+XhZz for ; Thu, 5 Apr 2012 02:31:18 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6079E21F8554 for ; Thu, 5 Apr 2012 02:31:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208";a="199524835" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 10:31:14 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q359VDt5001897; Thu, 5 Apr 2012 10:31:13 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 10:31:13 +0100 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 Date: Thu, 5 Apr 2012 10:31:11 +0100 Message-ID: In-Reply-To: <4F7D654B.4020909@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0TDjVe87+HRtRRRwuJwnrqingidgAAIvxw References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local><4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <298CEDD0-CBAB-4A21-85C2-B5594DDCB6EA@cisco.com> <4F7D654B.4020909@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" X-OriginalArrivalTime: 05 Apr 2012 09:31:13.0698 (UTC) FILETIME=[D7F10820:01CD130E] Cc: manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:31:19 -0000 I will defer to Stan on the question of whether the scenario "collecting me= tric X, know it for neighbours A, B, C but not D, E, F" is one DLEP needs. Absolutely agree with that if we include unknown then it needs to be an out= of band value. Zero usually is, or all bits set may be reserved for that p= urpose. But let's address the point above first, and before that the basic = concept. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 05 April 2012 10:27 To: Dearlove, Christopher (UK) Cc: Stan Ratliff; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours On 04/05/2012 11:01 AM, Dearlove, Christopher (UK) wrote: > The local information could go in the message TLV block. If it's of a > similar nature to the non-local information, then you need to > duplicate the TLVs, but that's just paperwork (and IANA are > encouraged to give it the same number by some text in 5444, IIRC). agreed. > That's fine as long as any DLEP message has a well-defined (by source > IP address if nothing else, but there's also originator IP address, > or you could invent a TLV) local entity that the message TLV block > refers to. Source-IP doesn't work, because DLEP should be transport protocol=20 independent. DLEP over USB would have no IPs on both ends for example. But instead of originator-IP (DLEP will most likely use 6 byte=20 addresses, so no IP as originator), we could use the radios MAC (which=20 must exist somewhere to allow it working in an IP network) as the=20 originator-address of the RFC5444 message. On 04/05/2012 11:15 AM, Dearlove, Christopher (UK) wrote: > I had in mind separate TLVs, both address block and message, for each=20 meaningful piece of data. > > Thus, for example, we might have a TLV for data rate, a TLV for delay=20 etc. These might use different subtypes of a single TLV type, which we=20 might use the collective term metric for. There mcould be message and=20 address block versions of the TLV, identical except for the TLV space.=20 Those in an address block TLV block then indicate which MAC address they=20 apply to, implicitly a neighbour, and those in the message TLV block=20 apply locally. If we have a data rate but not a delay for a neighbour=20 then there is no TLV of the delay type associated with that MAC address. Using one TLV-type for each kind data format might work too. One TLV=20 tpye for all kind of "data rates" (always x bytes measured in bits/s),=20 one for counters, one for signal strength, ... > (Actually, in another secondary point, it might make things easier if=20 the metric value allowed an "unknown" option, probably coded zero, to=20 allow multivalue TLVs to span over ranges including some addresses with=20 known e.g. delays and some without. But let's not get hung up on this=20 point now.) I think we do not need the "unknown" encoding. In most radio=20 implementations we have a certain metric type for each of the neighbors=20 or for none. If we want a "unknown" encoding, it should not be a value that is also=20 included in the valid range of the metric. Otherwise we could not see=20 the difference between "not measured" and a metric that is accidentally=20 the 'default value'. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Thu Apr 5 06:57:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD57021F85F7 for ; Thu, 5 Apr 2012 06:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUsOpwIuwva9 for ; Thu, 5 Apr 2012 06:57:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA6C21F85F4 for ; Thu, 5 Apr 2012 06:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6316; q=dns/txt; s=iport; t=1333634249; x=1334843849; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=l74DU09is25sLlnSB9wm26v5WcL8GWb+ppcn9azTfag=; b=TLcZBTwW7cjOMXt5CIU3G4ft3hSg5Ee1esyhA1MEW8z6Oi+55CaZ1SYX kQOVycbNbbZcMeW+j61VMHSd1FhqURwTzUgZZ8+5BPoFLD8ehPBmugqbb Em0OyeEwP178g/whT4i22MknTkdBjM5rzOAuPmujwWIjpuaampgHnVbP8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFmkfU+tJXHB/2dsb2JhbABFuGyBB4IJAQEBAwESASUCGxwIBQcECxEEAQEBJwdGCQgGExsHh14DBgWbG5YcDYlTiiF3DIRTYwSVa45LgWmDA4E4CA X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="72357647" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 05 Apr 2012 13:57:29 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q35DvS1q014950; Thu, 5 Apr 2012 13:57:28 GMT Message-Id: From: Stan Ratliff To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Apr 2012 09:57:30 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 13:57:30 -0000 My apologies for being dense... So, we've gone from a set of sub-TLV's that are common in all cases to a notion where it's entirely possible (wording in 5444 notwithstanding) where Latency could be known by 2 different TLV's? One referencing an Address block, and the other a Message TLV? And this is supposed to make the protocol "better"? And how many 5444 TLV's are we talking about consuming? One of the biggest complaints about the earlier versions of the protocol (specifically, from Justin Dean) was that we were consuming too much of the TLV number space in 5444. So, we went to an implementation where we consumed exactly 1. I don't see how this makes anything better... Regards, Stan On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote: > I had in mind separate TLVs, both address block and message, for > each meaningful piece of data. > > Thus, for example, we might have a TLV for data rate, a TLV for > delay etc. These might use different subtypes of a single TLV type, > which we might use the collective term metric for. There mcould be > message and address block versions of the TLV, identical except for > the TLV space. Those in an address block TLV block then indicate > which MAC address they apply to, implicitly a neighbour, and those > in the message TLV block apply locally. If we have a data rate but > not a delay for a neighbour then there is no TLV of the delay type > associated with that MAC address. > > (Actually, in another secondary point, it might make things easier > if the metric value allowed an "unknown" option, probably coded > zero, to allow multivalue TLVs to span over ranges including some > addresses with known e.g. delays and some without. But let's not get > hung up on this point now.) > > IP addresses are then another meaningful piece of data in the sense > of my first paragraph above. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 04 April 2012 18:23 > To: Rick Taylor > Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Wed, Apr 4, 2012 at 19:14, Rick Taylor > wrote: >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>> Behalf >> Of >>> Stan Ratliff >>> >>> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >>> >>>> That says that a device will have a MAC address. However I'm sure >>>> I've seen a post in this thread saying that a device might not have >>>> a MAC address. >>> >>> In the current implementation, every RF partner (neighbor) will have >>> some sort of Layer 2 address. There's a bit of a side conversation >>> about how a router would communicate with it's LOCAL radio - for >>> example, if the router were a card in a chassis, and the radio was >>> the >>> next card over in the same chassis... >> >> I always imagined these LOCAL messages would remain as is specified >> in >> the draft: Message-Block TLVs... > > Or a series of Message-TLVs, one for each parameter we need. This > makes it very easy to leave out parameters that are not necessary and > even add optional data to DLEP orders later. > >>>> But assuming that a MAC address is always present, then the 5444 >>>> natural thing to do would be to use the MAC addresses as the >>>> addresses in the address block. No address compression advantages, >>>> but now it's straightforward to associate information with those >>>> addresses, in an indexed way, with metrics etc. being normal >>>> TLVs. A >>>> good generic 5444 parser will then produce some sort of MAC address >>>> to other information map or other data structure. >>>> >>> Then that leave me with "router to LOCAL radio" communication - >>> information that "my radio" wants to communicate about itself, and >>> *all* of the traffic associated with it. That's currently in DLEP - >>> the notion that a radio could quickly state "the maximum data rate >>> on >>> all destinations via me is X". Not sure how to do that while we're >>> encoding MAC addresses into address blocks. Also, that gives the >>> metrics the notion of existing "within a context" - either they >>> apply >>> to a single RF partner (a neighbor), or all RF partners via the >>> radio >>> - that's what the current DLEP refers to as a "peer-level metric". >> >> No association with a neighbour, no Address-Block TLVs, just >> Message-Block TLVs. > Yes, message TLVs are a good solution to transport information about > the whole radio. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From Chris.Dearlove@baesystems.com Thu Apr 5 07:22:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4F21F87A3 for ; Thu, 5 Apr 2012 07:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4PGe0D+lfKE for ; Thu, 5 Apr 2012 07:22:51 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 482F821F86F8 for ; Thu, 5 Apr 2012 07:22:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="199631709" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 15:22:50 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q35EMnDp024554; Thu, 5 Apr 2012 15:22:49 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 15:22:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 15:22:48 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0TNAwS2A5nyl8QRLmVDvjs0cz4IAAAiDLQ References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" X-OriginalArrivalTime: 05 Apr 2012 14:22:49.0581 (UTC) FILETIME=[944CE9D0:01CD1337] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:22:53 -0000 Message TLVs and address block TLVs are independent spaces. So we're not = really here talking about two different TLVs, but the same TLV, existing = in two spaces. As an example look at RFC 5497 which defines validity and = interval time TLVs. These were wanted by OLSRv2 (and NHDP) as message = TLVs, but some people wanted them also defined as address block TLVs for = possible per-address use (though no one has yet done so). But you just = describe once, and IANA allocates twice. It's just paperwork, not a real = addition in complexity. (It's slightly more complicated in 5497, as even = the two TLVs have much in common, so there are two layers of = description.) And as has been previously said, you can consume 0 TLVs from the global = space if you want to, by making the TLVs message type specific. And = allowing that types are really 16 bit numbers (half is called a type = extension, but it is in effect 8 bits of the overall type) there are = quite a lot of TLVs. Obviously you'd logically organise the selected = types. The point would be to allow a generic 5444 parser, such as that several = people already have, to be able to fully parse a DLEP message into some = sort of associative data structure without any new code needing to be = written for DLEP alone. And the overall DLEP code could be simpler. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 05 April 2012 14:58 To: Dearlove, Christopher (UK) Cc: Henning Rogge; Rick Taylor; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- My apologies for being dense... So, we've gone from a set of sub-TLV's that are common in all cases to =20 a notion where it's entirely possible (wording in 5444 =20 notwithstanding) where Latency could be known by 2 different TLV's? =20 One referencing an Address block, and the other a Message TLV? And =20 this is supposed to make the protocol "better"? And how many 5444 =20 TLV's are we talking about consuming? One of the biggest complaints =20 about the earlier versions of the protocol (specifically, from Justin =20 Dean) was that we were consuming too much of the TLV number space in =20 5444. So, we went to an implementation where we consumed exactly 1. I =20 don't see how this makes anything better... Regards, Stan On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote: > I had in mind separate TLVs, both address block and message, for =20 > each meaningful piece of data. > > Thus, for example, we might have a TLV for data rate, a TLV for =20 > delay etc. These might use different subtypes of a single TLV type, =20 > which we might use the collective term metric for. There mcould be =20 > message and address block versions of the TLV, identical except for =20 > the TLV space. Those in an address block TLV block then indicate =20 > which MAC address they apply to, implicitly a neighbour, and those =20 > in the message TLV block apply locally. If we have a data rate but =20 > not a delay for a neighbour then there is no TLV of the delay type =20 > associated with that MAC address. > > (Actually, in another secondary point, it might make things easier =20 > if the metric value allowed an "unknown" option, probably coded =20 > zero, to allow multivalue TLVs to span over ranges including some =20 > addresses with known e.g. delays and some without. But let's not get =20 > hung up on this point now.) > > IP addresses are then another meaningful piece of data in the sense =20 > of my first paragraph above. > > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 04 April 2012 18:23 > To: Rick Taylor > Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Wed, Apr 4, 2012 at 19:14, Rick Taylor =20 > wrote: >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 >>> Behalf >> Of >>> Stan Ratliff >>> >>> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >>> >>>> That says that a device will have a MAC address. However I'm sure >>>> I've seen a post in this thread saying that a device might not have >>>> a MAC address. >>> >>> In the current implementation, every RF partner (neighbor) will have >>> some sort of Layer 2 address. There's a bit of a side conversation >>> about how a router would communicate with it's LOCAL radio - for >>> example, if the router were a card in a chassis, and the radio was =20 >>> the >>> next card over in the same chassis... >> >> I always imagined these LOCAL messages would remain as is specified =20 >> in >> the draft: Message-Block TLVs... > > Or a series of Message-TLVs, one for each parameter we need. This > makes it very easy to leave out parameters that are not necessary and > even add optional data to DLEP orders later. > >>>> But assuming that a MAC address is always present, then the 5444 >>>> natural thing to do would be to use the MAC addresses as the >>>> addresses in the address block. No address compression advantages, >>>> but now it's straightforward to associate information with those >>>> addresses, in an indexed way, with metrics etc. being normal =20 >>>> TLVs. A >>>> good generic 5444 parser will then produce some sort of MAC address >>>> to other information map or other data structure. >>>> >>> Then that leave me with "router to LOCAL radio" communication - >>> information that "my radio" wants to communicate about itself, and >>> *all* of the traffic associated with it. That's currently in DLEP - >>> the notion that a radio could quickly state "the maximum data rate =20 >>> on >>> all destinations via me is X". Not sure how to do that while we're >>> encoding MAC addresses into address blocks. Also, that gives the >>> metrics the notion of existing "within a context" - either they =20 >>> apply >>> to a single RF partner (a neighbor), or all RF partners via the =20 >>> radio >>> - that's what the current DLEP refers to as a "peer-level metric". >> >> No association with a neighbour, no Address-Block TLVs, just >> Message-Block TLVs. > Yes, message TLVs are a good solution to transport information about > the whole radio. > > Henning Rogge > > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From sratliff@cisco.com Thu Apr 5 07:43:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5838821F8656 for ; Thu, 5 Apr 2012 07:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzANMBEboqfe for ; Thu, 5 Apr 2012 07:43:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1E04421F8648 for ; Thu, 5 Apr 2012 07:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=10211; q=dns/txt; s=iport; t=1333636997; x=1334846597; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=IMBPgCSG3dfW59gnzI6cpkstSLEtmTD2ts8T+1q7sbE=; b=Fnhu1rtfPyJdSNnNE00e+2ckeOvrrHtB8QyZ5SKOGLmMwORye7ibAUu4 mhCHrNG2Gu4q2DZB4xjfxwvdLlFPeQaoFpnbdlCoiCBk3qrHmLJPqT0+y LnCwXWBeRMBE+hljlZWtPR2I/CKZgJHHJNK+oCkTNiS4DxL7p0tLpyRSl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJKufU+tJXHB/2dsb2JhbABDuHmBB4IJAQEBAwESASUCGxwIBQcECxEEAQEBJwdGCQgGExsHh14DBgWfVJYbDYFriiF3DIRTYwSVa45LgWmDA4E4CA X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="72362288" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Apr 2012 14:43:16 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q35EhFZa008873; Thu, 5 Apr 2012 14:43:15 GMT Message-Id: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> From: Stan Ratliff To: "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Apr 2012 10:43:16 -0400 References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 14:43:18 -0000 But the fact that they're in two different spaces means that, by definition, they could wind up numbered differently. Even if the initial allocation is done "correctly", when considering follow-on additions (as mentioned by Tom Henderson), you can't guarantee the same code point will be available in both spaces. The way we've currently done it, if at some point in the future, there is a need for a "Size-of-tin-can to length-of-string ratio" metric, then fine. It gets allocated - ONCE - out of the DLEP defined space. Not TWICE - and *hopefully* that same one - out of two different spaces. As to the utility of a generic 5444 parser, I see that this may save someone a few lines of code - but at what cost? IMO, this makes the protocol MUCH more complex. And while we're on the topic of code, as I mentioned in Paris, there are 3 *existing* implementations of DLEP code. I feel Thomas' pain when mentioning "running code" - or have we changed the IETF mantra to "rough consensus, and to hell with the running code"??? Regards, Stan On Apr 5, 2012, at 10:22 AM, Dearlove, Christopher (UK) wrote: > Message TLVs and address block TLVs are independent spaces. So we're > not really here talking about two different TLVs, but the same TLV, > existing in two spaces. As an example look at RFC 5497 which defines > validity and interval time TLVs. These were wanted by OLSRv2 (and > NHDP) as message TLVs, but some people wanted them also defined as > address block TLVs for possible per-address use (though no one has > yet done so). But you just describe once, and IANA allocates twice. > It's just paperwork, not a real addition in complexity. (It's > slightly more complicated in 5497, as even the two TLVs have much in > common, so there are two layers of description.) > > And as has been previously said, you can consume 0 TLVs from the > global space if you want to, by making the TLVs message type > specific. And allowing that types are really 16 bit numbers (half is > called a type extension, but it is in effect 8 bits of the overall > type) there are quite a lot of TLVs. Obviously you'd logically > organise the selected types. > > The point would be to allow a generic 5444 parser, such as that > several people already have, to be able to fully parse a DLEP > message into some sort of associative data structure without any new > code needing to be written for DLEP alone. And the overall DLEP code > could be simpler. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 05 April 2012 14:58 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; Rick Taylor; manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > My apologies for being dense... > > So, we've gone from a set of sub-TLV's that are common in all cases to > a notion where it's entirely possible (wording in 5444 > notwithstanding) where Latency could be known by 2 different TLV's? > One referencing an Address block, and the other a Message TLV? And > this is supposed to make the protocol "better"? And how many 5444 > TLV's are we talking about consuming? One of the biggest complaints > about the earlier versions of the protocol (specifically, from Justin > Dean) was that we were consuming too much of the TLV number space in > 5444. So, we went to an implementation where we consumed exactly 1. I > don't see how this makes anything better... > > Regards, > Stan > > On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote: > >> I had in mind separate TLVs, both address block and message, for >> each meaningful piece of data. >> >> Thus, for example, we might have a TLV for data rate, a TLV for >> delay etc. These might use different subtypes of a single TLV type, >> which we might use the collective term metric for. There mcould be >> message and address block versions of the TLV, identical except for >> the TLV space. Those in an address block TLV block then indicate >> which MAC address they apply to, implicitly a neighbour, and those >> in the message TLV block apply locally. If we have a data rate but >> not a delay for a neighbour then there is no TLV of the delay type >> associated with that MAC address. >> >> (Actually, in another secondary point, it might make things easier >> if the metric value allowed an "unknown" option, probably coded >> zero, to allow multivalue TLVs to span over ranges including some >> addresses with known e.g. delays and some without. But let's not get >> hung up on this point now.) >> >> IP addresses are then another meaningful piece of data in the sense >> of my first paragraph above. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 04 April 2012 18:23 >> To: Rick Taylor >> Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Wed, Apr 4, 2012 at 19:14, Rick Taylor >> wrote: >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>>> Behalf >>> Of >>>> Stan Ratliff >>>> >>>> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >>>> >>>>> That says that a device will have a MAC address. However I'm sure >>>>> I've seen a post in this thread saying that a device might not >>>>> have >>>>> a MAC address. >>>> >>>> In the current implementation, every RF partner (neighbor) will >>>> have >>>> some sort of Layer 2 address. There's a bit of a side conversation >>>> about how a router would communicate with it's LOCAL radio - for >>>> example, if the router were a card in a chassis, and the radio was >>>> the >>>> next card over in the same chassis... >>> >>> I always imagined these LOCAL messages would remain as is specified >>> in >>> the draft: Message-Block TLVs... >> >> Or a series of Message-TLVs, one for each parameter we need. This >> makes it very easy to leave out parameters that are not necessary and >> even add optional data to DLEP orders later. >> >>>>> But assuming that a MAC address is always present, then the 5444 >>>>> natural thing to do would be to use the MAC addresses as the >>>>> addresses in the address block. No address compression advantages, >>>>> but now it's straightforward to associate information with those >>>>> addresses, in an indexed way, with metrics etc. being normal >>>>> TLVs. A >>>>> good generic 5444 parser will then produce some sort of MAC >>>>> address >>>>> to other information map or other data structure. >>>>> >>>> Then that leave me with "router to LOCAL radio" communication - >>>> information that "my radio" wants to communicate about itself, and >>>> *all* of the traffic associated with it. That's currently in DLEP - >>>> the notion that a radio could quickly state "the maximum data rate >>>> on >>>> all destinations via me is X". Not sure how to do that while we're >>>> encoding MAC addresses into address blocks. Also, that gives the >>>> metrics the notion of existing "within a context" - either they >>>> apply >>>> to a single RF partner (a neighbor), or all RF partners via the >>>> radio >>>> - that's what the current DLEP refers to as a "peer-level metric". >>> >>> No association with a neighbour, no Address-Block TLVs, just >>> Message-Block TLVs. >> Yes, message TLVs are a good solution to transport information about >> the whole radio. >> >> Henning Rogge >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > From Chris.Dearlove@baesystems.com Thu Apr 5 08:31:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F187521F861E for ; Thu, 5 Apr 2012 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poFq393bPAOq for ; Thu, 5 Apr 2012 08:31:28 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3421F85B1 for ; Thu, 5 Apr 2012 08:31:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,375,1330905600"; d="scan'208";a="199654497" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 05 Apr 2012 16:31:02 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q35FUMmw001866; Thu, 5 Apr 2012 16:31:00 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 16:30:48 +0100 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 Date: Thu, 5 Apr 2012 16:30:46 +0100 Message-ID: In-Reply-To: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and multi-hop neighbours Thread-Index: Ac0TOnHzg0xatXkzS22P1TM1E/PvDQAA5NMA References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> From: "Dearlove, Christopher (UK)" To: "Stan Ratliff" X-OriginalArrivalTime: 05 Apr 2012 15:30:48.0956 (UTC) FILETIME=[13CC23C0:01CD1341] Cc: manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:31:30 -0000 There is IIRC, a comment in the expert review/IANA section that advises = the same numbering (each has its own complete set of numbers). And if in = the private numbering space, that is easy, as you are starting from a = clean sheet (in effect) and the common numbering can be mandated. (Not = that different numbering need actually be difficult. The point of = generic 5444 parsing code is that it doesn't need to know. But agreed = that it would be stupid.) I think the difference between allocated once = and twice is trivial, it's a trivially more complicated instruction to = IANA is all. Note that I'm mainly engaged in this as a "this is how to do it best = fitting 5444". I admit that's my natural preference. But I don't = currently have a basis/need to make a tradeoff between "better" and = "running code". We don't do votes, but if we did I'd probably abstain. = However I would want the debate to be fully informed, which is my = intention here. Coding also cuts two ways. With changes suggested I = already have a DLEP parser - it's my generic 5444 parser, it just needs = a few trivial callback functions added. With sub-TLVs I would need new = code. I'm just an example that doesn't matter here, but are there = others? I definitely do not agree with that this makes the protocol much more = complex. In the eye of this beholder, it makes it simpler. (Which is = simpler, using TLVs as already defined, or inventing a whole new concept = of sub-TLVs to be parsed? Loaded wording, but accurate.) It depends = where you are starting from. (If we cared about efficiency - we don't = seem to - that could also be assessed, and I have no idea which would = win there - probably neither.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 05 April 2012 15:43 To: Dearlove, Christopher (UK) Cc: Henning Rogge; Rick Taylor; manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- But the fact that they're in two different spaces means that, by =20 definition, they could wind up numbered differently. Even if the =20 initial allocation is done "correctly", when considering follow-on =20 additions (as mentioned by Tom Henderson), you can't guarantee the =20 same code point will be available in both spaces. The way we've =20 currently done it, if at some point in the future, there is a need for =20 a "Size-of-tin-can to length-of-string ratio" metric, then fine. It =20 gets allocated - ONCE - out of the DLEP defined space. Not TWICE - and =20 *hopefully* that same one - out of two different spaces. As to the utility of a generic 5444 parser, I see that this may save =20 someone a few lines of code - but at what cost? IMO, this makes the =20 protocol MUCH more complex. And while we're on the topic of code, as I =20 mentioned in Paris, there are 3 *existing* implementations of DLEP =20 code. I feel Thomas' pain when mentioning "running code" - or have we =20 changed the IETF mantra to "rough consensus, and to hell with the =20 running code"??? Regards, Stan On Apr 5, 2012, at 10:22 AM, Dearlove, Christopher (UK) wrote: > Message TLVs and address block TLVs are independent spaces. So we're =20 > not really here talking about two different TLVs, but the same TLV, =20 > existing in two spaces. As an example look at RFC 5497 which defines =20 > validity and interval time TLVs. These were wanted by OLSRv2 (and =20 > NHDP) as message TLVs, but some people wanted them also defined as =20 > address block TLVs for possible per-address use (though no one has =20 > yet done so). But you just describe once, and IANA allocates twice. =20 > It's just paperwork, not a real addition in complexity. (It's =20 > slightly more complicated in 5497, as even the two TLVs have much in =20 > common, so there are two layers of description.) > > And as has been previously said, you can consume 0 TLVs from the =20 > global space if you want to, by making the TLVs message type =20 > specific. And allowing that types are really 16 bit numbers (half is =20 > called a type extension, but it is in effect 8 bits of the overall =20 > type) there are quite a lot of TLVs. Obviously you'd logically =20 > organise the selected types. > > The point would be to allow a generic 5444 parser, such as that =20 > several people already have, to be able to fully parse a DLEP =20 > message into some sort of associative data structure without any new =20 > code needing to be written for DLEP alone. And the overall DLEP code =20 > could be simpler. > > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 05 April 2012 14:58 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; Rick Taylor; manet@ietf.org > Subject: Re: [manet] DLEP and multi-hop neighbours > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > My apologies for being dense... > > So, we've gone from a set of sub-TLV's that are common in all cases to > a notion where it's entirely possible (wording in 5444 > notwithstanding) where Latency could be known by 2 different TLV's? > One referencing an Address block, and the other a Message TLV? And > this is supposed to make the protocol "better"? And how many 5444 > TLV's are we talking about consuming? One of the biggest complaints > about the earlier versions of the protocol (specifically, from Justin > Dean) was that we were consuming too much of the TLV number space in > 5444. So, we went to an implementation where we consumed exactly 1. I > don't see how this makes anything better... > > Regards, > Stan > > On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote: > >> I had in mind separate TLVs, both address block and message, for >> each meaningful piece of data. >> >> Thus, for example, we might have a TLV for data rate, a TLV for >> delay etc. These might use different subtypes of a single TLV type, >> which we might use the collective term metric for. There mcould be >> message and address block versions of the TLV, identical except for >> the TLV space. Those in an address block TLV block then indicate >> which MAC address they apply to, implicitly a neighbour, and those >> in the message TLV block apply locally. If we have a data rate but >> not a delay for a neighbour then there is no TLV of the delay type >> associated with that MAC address. >> >> (Actually, in another secondary point, it might make things easier >> if the metric value allowed an "unknown" option, probably coded >> zero, to allow multivalue TLVs to span over ranges including some >> addresses with known e.g. delays and some without. But let's not get >> hung up on this point now.) >> >> IP addresses are then another meaningful piece of data in the sense >> of my first paragraph above. >> >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 04 April 2012 18:23 >> To: Rick Taylor >> Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Wed, Apr 4, 2012 at 19:14, Rick Taylor >> wrote: >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >>>> Behalf >>> Of >>>> Stan Ratliff >>>> >>>> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >>>> >>>>> That says that a device will have a MAC address. However I'm sure >>>>> I've seen a post in this thread saying that a device might not =20 >>>>> have >>>>> a MAC address. >>>> >>>> In the current implementation, every RF partner (neighbor) will =20 >>>> have >>>> some sort of Layer 2 address. There's a bit of a side conversation >>>> about how a router would communicate with it's LOCAL radio - for >>>> example, if the router were a card in a chassis, and the radio was >>>> the >>>> next card over in the same chassis... >>> >>> I always imagined these LOCAL messages would remain as is specified >>> in >>> the draft: Message-Block TLVs... >> >> Or a series of Message-TLVs, one for each parameter we need. This >> makes it very easy to leave out parameters that are not necessary and >> even add optional data to DLEP orders later. >> >>>>> But assuming that a MAC address is always present, then the 5444 >>>>> natural thing to do would be to use the MAC addresses as the >>>>> addresses in the address block. No address compression advantages, >>>>> but now it's straightforward to associate information with those >>>>> addresses, in an indexed way, with metrics etc. being normal >>>>> TLVs. A >>>>> good generic 5444 parser will then produce some sort of MAC =20 >>>>> address >>>>> to other information map or other data structure. >>>>> >>>> Then that leave me with "router to LOCAL radio" communication - >>>> information that "my radio" wants to communicate about itself, and >>>> *all* of the traffic associated with it. That's currently in DLEP - >>>> the notion that a radio could quickly state "the maximum data rate >>>> on >>>> all destinations via me is X". Not sure how to do that while we're >>>> encoding MAC addresses into address blocks. Also, that gives the >>>> metrics the notion of existing "within a context" - either they >>>> apply >>>> to a single RF partner (a neighbor), or all RF partners via the >>>> radio >>>> - that's what the current DLEP refers to as a "peer-level metric". >>> >>> No association with a neighbour, no Address-Block TLVs, just >>> Message-Block TLVs. >> Yes, message TLVs are a good solution to transport information about >> the whole radio. >> >> Henning Rogge >> >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > From jmh@joelhalpern.com Fri Apr 6 08:58:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9854F21F84E4; Fri, 6 Apr 2012 08:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XGhbB9he5yN; Fri, 6 Apr 2012 08:58:23 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id F303821F84DC; Fri, 6 Apr 2012 08:58:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id B0835A652C; Fri, 6 Apr 2012 08:58:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 57FBC1C5B3F; Fri, 6 Apr 2012 08:58:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2F1DA1C08DC; Fri, 6 Apr 2012 08:58:21 -0700 (PDT) Message-ID: <4F7F12CA.9010009@joelhalpern.com> Date: Fri, 06 Apr 2012 11:59:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: gen-art@ietf.org References: <4F7E279C.3030707@nostrum.com> In-Reply-To: <4F7E279C.3030707@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Apr 2012 09:48:51 -0700 Cc: manet@ietf.org, "A. Jean Mahoney" , sratliff@cisco.com Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:58:23 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-manet-nhdp-mib-12 Definition of Managed Objects for the Neighborhood Discovery Protocol Reviewer: Joel M. Halpern Review Date: 6-April-2012 IETF LC End Date: 16-April-2012 IESG Telechat date: (if known) Summary: This document is almost ready for publication as a Proposed Standard. Major issues: Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very reasonable thing, namely suppress notifications for activity which is expected. The text references RFC 4750 as precedent. RFC 4750 is clear that the suppress window is tied to specific events (interface up and election as a DR.) Section 5.1.3.1 does not specify which condition(s) start(s) the suppress window. If, as seems likely, it is Interface Up which starts the window, please state that explicitly in the text. In section 5.4, in addition to describing objects which are defined in the MIB, the text describes, under the heading "The following objects return statistics related to HELLO messages:", a number of what it refers to as "Derived Objects". These do not appear to be actual elements of the MIB. They appear rather to be descriptions of calculations which the manager can perform using the information from the MIB. It is not at all clear why they are here. If I am understanding their role properly, and if they belong in this document, they belong in some other section, as they are NOT objects which return statistics related to HELLO messages. They appear not to be returned by the managed device at all. Minor issues: I can not find the object that corresponds to the setting for Ignoring the Initial Activity. I presume this is my error. The document would be helped if the object were named in section 5.1.3.1. I believe section 5.1.3.2 on Throttling Traps is intended to refer to the StateChange Threshold and StateChangeWindow objects. It would be very helpful if these were actually named in section 5.1.3.2. Most MIBs I review have a description of the tables they contain, how the tables relate to each other, and how they are indexed, in the front matter that is roughly equivalent to section 5.2, 5.3, and 5.4. As I am not a MIB Doctor, I do not know if that is formally required, but I find it very helpful, and am surprised not to see it here. In looking at the fields in the NhdpInterfaceEntry, some of the field definitions include some of the constraints from RFC 6130 section 5 in their DESCRIPTION clauses. Some do not. (For exampple, REFRESH_INTERVAL >= HELLO_INTERVAL is captured in nhdbpRefreshInterval, but not in nhdpHelloInterval. The requirement that nhdpHelloInterval be greater than 0 is not captured anywhere. Neither is H_HOLD_TIME >= REFRESH_INTERVAL captured.) Some elements have a statement that the object is persistent, while others do not, but these do not seem to correspond to a difference in RFC 6130. It is possible that there is a good reason for this apparent variation. Is there? Particularly for top-level objects such as nhdpNHoldTime and NhdpIHoldTime I would really like to see a better description than just this is object from section 5 of RFC 6130. Someone who is using the MIB, who is looking at the description clause for assistance, really needs something more than the name of the field in the MIB. (I think better descriptions would be a good idea through much of the MIB.) Nits/editorial comments: The tracker claims this is "In WG Last Call (manet), but also seems to indicate that it is in IETF Last Call. Are the two happening at the same time? From prvs=54438f2d1a=veytser@ll.mit.edu Fri Apr 6 11:32:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3556621F852E for ; Fri, 6 Apr 2012 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqNT2Ap-Q16O for ; Fri, 6 Apr 2012 11:32:55 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0121F851D for ; Fri, 6 Apr 2012 11:32:55 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q36IWrtX017403 for ; Fri, 6 Apr 2012 14:32:53 -0400 From: "Veytser, Leonid - 0665 - MITLL" To: "manet@ietf.org" Date: Fri, 6 Apr 2012 14:32:50 -0400 Thread-Topic: DLEP and different control and data interfaces Thread-Index: Ac0UI611xijOVoZxTx6md6uytBG1yA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416567571_35857340" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-06_03:2012-04-05, 2012-04-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204060200 Subject: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:32:56 -0000 --B_3416567571_35857340 Content-type: multipart/alternative; boundary="B_3416567570_35814208" --B_3416567570_35814208 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit There are some radio systems that have separate interfaces for data and control. Please correct me if I am wrong, but it looks like currently DLEP only handles the case where both DLEP control packets and data packets are sent in-band (i.e. over the same interface). If two different interfaces are used for control and data, the IPv4 and IPv6 addresses provided by Peer Offer message would refer to the control interface of the router and the radio would have no knowledge of the router's data interface addressing information. However, the addressing information of the data interface would be needed for the neighbor session messages (e.g. Neighbor Up). Has there been any interest in supporting separate data and control interfaces? It seems that if the Peer Offer message added optional fields to specify some of the addressing information of the data interface that this capability would now be supported. Thanks, Lenny ------------------------------------------------------------ Leonid Veytser Airborne Networks Group MIT Lincoln Laboratory 244 Wood St Lexington, MA 02420 781-981-1395 --B_3416567570_35814208 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
There are some rad= io systems that have separate interfaces for data and control. Please correc= t me if I am wrong, but it looks like currently DLEP only handles the case&n= bsp;where both DLEP control packets and data packets are sent in-band (i.e. = over the same interface). If two different interfaces are used for control a= nd data, the IPv4 and IPv6 addresses provided by Peer Offer message would re= fer to the control interface of the router and the radio would have no knowl= edge of the router's data interface addressing information. However, the add= ressing information of the data interface would be needed for the neighbor s= ession messages (e.g. Neighbor Up).

Has there been = any interest in supporting separate data and control interfaces? It see= ms that if the Peer Offer message added optional fields to specify some of t= he addressing information of the data interface that this capability would n= ow be supported.

Thanks,

L= enny

----------------------------------= --------------------------
Leonid Veytser
Airborne Networks GroupMIT Lincoln Laboratory
244 Wood= St
Lexington, MA 02420
781-981-1395
--B_3416567570_35814208-- --B_3416567571_35857340 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUCAYJKoZIhvcNAQcCoIIT+TCCE/UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeswggTPMIIDt6ADAgECAgpihG8cAAAAAC1rMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTExMjI3MTYyODU1WhcNMTIxMjI2MTYyODU1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdWZXl0c2VyLkxlb25pZC41MDAwNzQxNTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANBF4Y0/hZ3+J/npN95KyvuhQb2eS9tWnzI40+tJEiPTPMki Ivme5U+lZKdLqKlKGDF9YwzqlT9Sf9LGuOuVNm7SyZKtEoGLymG0KbEsqF/XSRfA6vXC1wP8 BT9lmtX5E0QPoD41gUVXBZI8PhHJzaUKNa7oQXV01e2Dm3BZPx/xA1FtB6ycimaUkR3C3HrD SVwqTVAYu8Lc7zKnHX7j6iRcARq+LpvZmP9bPTpUshTdNchpeDNXyGX8Ya92taY+ci1RSYue eIqXPYzIzAYsqC9099pMNqbpsjh9fXY962bvN0zBhUU3b0pVwmDb7pXQkCUGecnVn6atCQih Fs2pCNUCAwEAAaOCAZcwggGTMB0GA1UdDgQWBBRBKF2lUtWmcUSlOs2zp7qyw6qtzDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEnZleXRzZXJAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAJfyjis+AWozNXIgISFdBUk+FH/th+XP67xOtELyZ9ehBLzpCs8qxdHHV5okK N61UQXzOuCxhJAoQ01EYE0RaSiOaJztQ9mQvft88O2dz5RLzAn43A8uaL6+WGazwYvv27Cdr Ex/wR+EcT8WwG7dYEDsulHdfy/FehYYj4X2Rro/g97qFi3pGrldull2k2E7srJ2NzF16hUHl ncP6VDHmY7y0KOL5JtYV3jEH0aAa2Wh+KkNkEy5koaU+UNPepe8qc4qa0r2QSuoxkILfOKPv ByR6HJGXgdfr4AqCPkNuPvCtWJlFRKXm24lByx2yhHseK0dyIEaetcsWyqfVAYrS4zCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIE0jCCA7qgAwIBAgIKYoW3/gAAAAAtbTANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTExMTIyNzE2MzA0NVoXDTEyMTIyNjE2MzA0NVowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXVmV5dHNlci5MZW9uaWQuNTAwMDc0MTUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDwMmGDau9vm9YxzGp2R79H7zzdooLgHdRVLa/Gr3mv79C3 q4pjsSy1dFZZbEHq9Yqv2x/sPtA0mT3vsDGc+gwVoICu14TdLT1Ymv33b/XrwtC4PmoJlf0Z Ar5Re4uCKv7vLL9GU5xzeslALq25hGHye6aFNAUmKWR/MAcG+TQfwbj7tuiqnl4ChA13aPnb S0KQ6iutjpQ6J4qMA3j2DBxI27SBu7xaLPEQeYkyDqYT4KCr60l6Oxw7OhOkAfegZUzrp1SL 2nknDSoHdnRHugHciIFRApD2JxW1+F1fVI+vNbMBrGBtJ7bLr5VbkgO1UBQ/y1/15kIxppFe O2s1z9FfAgMBAAGjggGaMIIBljAdBgNVHQ4EFgQU0OGl4rKn6M4U+3c0zGwTJdtGgrQwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAdBgNVHREEFjAUgRJ2ZXl0c2VyQGxsLm1pdC5lZHUwDQYJKoZI hvcNAQELBQADggEBAJ0pbow7ESnEEOIIe83aZpbFO2YWH7kpwqVC8OgciZmiqvFSiGebToMv XpB6yXzbaPK5XTuM6Jx1v2GPmHDD6kNspV0R4I5X56ouRt2Hodkl+p7NCTfW6sBaKI4ku1Cl L1Zbgg72kYizfqioISB4DFZFYg7YReSvbiKVqQP+VN9kALAEOfAEG2Z1Hqr8+gHN38CgN/49 /Lp8j+d9kJ3mV1ssZMmR/6aDUDihgv09+e72XQhP24khFLdecSpV6qQ3W+Fc+9KtpnnI61U4 vzHdaOfCRZdzOoQ0t0Y9uOMaxtuV4iXA0na9ACIO6JNIKTE0IUtcuCH0pkv4TmifMIk1pUAx ggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTICCmKEbxwAAAAALWsw CQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR0oNQJEzOqIxyE+5suvHdFVxoP2TAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MDYxODMyNTBaMA0G CSqGSIb3DQEBAQUABIIBAH2vZBARLStw3ouKoMZQZRe31ZG1eeQ6hUNqA7MIZNdNUrCznrCE ICN9Syzh85VfUjv+ol9rYLIGRyP+AebH28ghqg+4fX0zoeK0o+DcQUg2dKQVeo6SA5XnxPgF tUgAlwxz61ShmMEmeez+P/nf5+WSGBoXn/cJPINfNclYImMmCCR1CxzlQ3zfx4eK10bIUVr1 k5U/6HGr7z+G51LT5ffEV7cTmb0o8NkJ3OKJf00Yy3rlng/4eVu55oYj/iO4wTNRrT7Ih2cF ERKQs1BOjnFjifaRa1rblxdDxoN+ooozZnjtIIDZOfT4G4x9tO+TC3L0i8KssoL4SkGOzH+O JeA= --B_3416567571_35857340-- From hrogge@googlemail.com Fri Apr 6 11:36:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAB21F848C for ; Fri, 6 Apr 2012 11:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMpcIukNzcA9 for ; Fri, 6 Apr 2012 11:36:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE33321F8478 for ; Fri, 6 Apr 2012 11:36:29 -0700 (PDT) Received: by lagj5 with SMTP id j5so1150034lag.31 for ; Fri, 06 Apr 2012 11:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vdWnhVPHu7EMw0KCjrJlJyFSkO0pX/cLeT62+56RTSw=; b=bcQp5gwW01I/JWUiyhIENQtafm1hco/OG9chF4qPFZg38vEnAYZGTc9iRzjNJZQxM7 +1evJ1D0C4IE6p1HWq7fFRbNuZ+MQCwflrVBm9GfF+p8siS9bwKgzmqdIlDkma/DLfAT MnTMGIdPHC7/ARs0Xdz8r8v1x/2cHLQog/0FjNCHb1jkn2ZJgP/QKcgcP2vM4PhY0YLT Gcu2lgdoZ00BnrUMJTdYYvPjjHYBO0TbrOEZKQX9XW2CB9BC/4jQZ4JjqIUf0WaRiimB hpR7QflnFnA1A99/Gf5YXm1LArwM/zf1hMAaxO44XJjxQfkI/hfSVEbX80jE6fPy2uLY pOVA== Received: by 10.152.148.234 with SMTP id tv10mr9880920lab.41.1333737388868; Fri, 06 Apr 2012 11:36:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 6 Apr 2012 11:36:08 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 6 Apr 2012 20:36:08 +0200 Message-ID: To: "Veytser, Leonid - 0665 - MITLL" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:36:31 -0000 I don't think DLEP makes any assumptions over which interface it is running or on what kind of transport. Sending it "out of band" would even be preferred in most cases, because its easier to keep the DLEP packets from reaching the radio interface. Henning Rogge On Fri, Apr 6, 2012 at 20:32, Veytser, Leonid - 0665 - MITLL wrote: > There are some radio systems that have separate interfaces for data and > control. Please correct me if I am wrong, but it looks like currently DLE= P > only handles the case=A0where both DLEP control packets and data packets = are > sent in-band (i.e. over the same interface). If two different interfaces = are > used for control and data, the IPv4 and IPv6 addresses provided by Peer > Offer message would refer to the control interface of the router and the > radio would have no knowledge of the router's data interface addressing > information. However, the addressing information of the data interface wo= uld > be needed for the neighbor session messages (e.g. Neighbor Up). > > Has there been any interest in supporting separate data and control > interfaces?=A0It seems that if the Peer Offer message added optional fiel= ds to > specify some of the addressing information of the data interface that thi= s > capability would now be supported. > > Thanks, > > Lenny > > ------------------------------------------------------------ > Leonid Veytser > Airborne Networks Group > MIT Lincoln Laboratory > 244 Wood St > Lexington, MA 02420 > 781-981-1395 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Fri Apr 6 11:50:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5999721F85B9 for ; Fri, 6 Apr 2012 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB13oCaCMEEt for ; Fri, 6 Apr 2012 11:50:29 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5B6021F85A0 for ; Fri, 6 Apr 2012 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2518; q=dns/txt; s=iport; t=1333738228; x=1334947828; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Uj9IfEq5jkZM3CaOZpOXD0NAoYIXPIWe076sAddoziM=; b=A9hZbjZgEEYst3w3YSzbclk9mvHHdZbipppJetmzSjcge9GDHhCO9dYo 8mLw0kGWODlJhzbVjSlbTVhDTtrzAnWvmfh1DH/ECGzcOCxLPN76zec1V b/htRLc+CY7MCNfPsEVmpRPWLUtO99tpOToNTEi+AeaQoS2r4msjpOa4l Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPY5f0+tJV2Z/2dsb2JhbABCA7kigQeCCQEBAQMBAQEBDwElAjQLBQsLDgouJzAGEyKHZwULml+fZQSNJ4JGYwSVbI5NgWmDAw X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="scan'208";a="69689023" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 06 Apr 2012 18:50:28 +0000 Received: from rtp-sratliff-8713.cisco.com (rtp-sratliff-8713.cisco.com [10.116.179.212]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q36IoRad003070; Fri, 6 Apr 2012 18:50:27 GMT Message-Id: <4FAFD83C-5D3C-4244-8476-437A9D5B351C@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Apr 2012 14:50:27 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:50:30 -0000 Actually, from the router's perspective, the assumption is that the neighbor exists "on this interface". This is just one opinion, but introducing the notion of separate interfaces for the control plane and the data traffic *from the router's perspective* really explodes the complexity of the implementation. Regards, Stan On Apr 6, 2012, at 2:36 PM, Henning Rogge wrote: > I don't think DLEP makes any assumptions over which interface it is > running or on what kind of transport. Sending it "out of band" would > even be preferred in most cases, because its easier to keep the DLEP > packets from reaching the radio interface. > > Henning Rogge > > On Fri, Apr 6, 2012 at 20:32, Veytser, Leonid - 0665 - MITLL > wrote: >> There are some radio systems that have separate interfaces for data >> and >> control. Please correct me if I am wrong, but it looks like >> currently DLEP >> only handles the case where both DLEP control packets and data >> packets are >> sent in-band (i.e. over the same interface). If two different >> interfaces are >> used for control and data, the IPv4 and IPv6 addresses provided by >> Peer >> Offer message would refer to the control interface of the router >> and the >> radio would have no knowledge of the router's data interface >> addressing >> information. However, the addressing information of the data >> interface would >> be needed for the neighbor session messages (e.g. Neighbor Up). >> >> Has there been any interest in supporting separate data and control >> interfaces? It seems that if the Peer Offer message added optional >> fields to >> specify some of the addressing information of the data interface >> that this >> capability would now be supported. >> >> Thanks, >> >> Lenny >> >> ------------------------------------------------------------ >> Leonid Veytser >> Airborne Networks Group >> MIT Lincoln Laboratory >> 244 Wood St >> Lexington, MA 02420 >> 781-981-1395 >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Fri Apr 6 11:56:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2894521F8491 for ; Fri, 6 Apr 2012 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE+9NPDc-BcY for ; Fri, 6 Apr 2012 11:56:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA57121F8483 for ; Fri, 6 Apr 2012 11:56:40 -0700 (PDT) Received: by lbok13 with SMTP id k13so890806lbo.31 for ; Fri, 06 Apr 2012 11:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+3w1Hsaf9GUDLeB+UDXC1yoFYLkr+rWrI1J4mtMc4oo=; b=pNoYHSijOUJ9IWVn6B/dfvwzMnZOg4xVLgKwcaBTnU6m/EiIJDtKHiC9J8LOJ9F36F 4/caevCbKeZMBr5ceZpMaDXe5Zv3KilP9FbEtG08eTVsn0AiEpay/QuYM3nK+1Fj2VII Y6Zw+W/OtYbht8b+b+W4ol/7vTKYZzoHCMgbh2nA6LlM0oS39h1m5KaQZ4O2/x9rmTym hqnlW44Qi31zosireQGiX4Wk1EWkl7mg6NTIsbKCpBTBGLm4MDPIyBs4UDPnoIIkTqCU KsvwD2mlpuKtaSADIV/Ea/7htwV7HDWM+BxQcW82b7J4d7DUyKRNRn6zjhnls+63ELTv vONA== Received: by 10.152.135.104 with SMTP id pr8mr9980331lab.27.1333738599618; Fri, 06 Apr 2012 11:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 6 Apr 2012 11:56:16 -0700 (PDT) In-Reply-To: <4FAFD83C-5D3C-4244-8476-437A9D5B351C@cisco.com> References: <4FAFD83C-5D3C-4244-8476-437A9D5B351C@cisco.com> From: Henning Rogge Date: Fri, 6 Apr 2012 20:56:16 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:56:42 -0000 Separating might be VLAN tags in case of ethernet... but it might be something completely different for USB or direct PCI-Express stuff. Would a DLEP-over-UDP implementation even care about which interface it can reach a modems/radios DLEP-service? Henning Rogge On Fri, Apr 6, 2012 at 20:50, Stan Ratliff wrote: > Actually, from the router's perspective, the assumption is that the neigh= bor > exists "on this interface". =A0This is just one opinion, but introducing = the > notion of separate interfaces for the control plane and the data traffic > *from the router's perspective* really explodes the complexity of the > implementation. > > Regards, > Stan > > > On Apr 6, 2012, at 2:36 PM, Henning Rogge wrote: > >> I don't think DLEP makes any assumptions over which interface it is >> running or on what kind of transport. Sending it "out of band" would >> even be preferred in most cases, because its easier to keep the DLEP >> packets from reaching the radio interface. >> >> Henning Rogge >> >> On Fri, Apr 6, 2012 at 20:32, Veytser, Leonid - 0665 - MITLL >> wrote: >>> >>> There are some radio systems that have separate interfaces for data and >>> control. Please correct me if I am wrong, but it looks like currently >>> DLEP >>> only handles the case where both DLEP control packets and data packets >>> are >>> sent in-band (i.e. over the same interface). If two different interface= s >>> are >>> used for control and data, the IPv4 and IPv6 addresses provided by Peer >>> Offer message would refer to the control interface of the router and th= e >>> radio would have no knowledge of the router's data interface addressing >>> information. However, the addressing information of the data interface >>> would >>> be needed for the neighbor session messages (e.g. Neighbor Up). >>> >>> Has there been any interest in supporting separate data and control >>> interfaces? It seems that if the Peer Offer message added optional fiel= ds >>> to >>> specify some of the addressing information of the data interface that >>> this >>> capability would now be supported. >>> >>> Thanks, >>> >>> Lenny >>> >>> ------------------------------------------------------------ >>> Leonid Veytser >>> Airborne Networks Group >>> MIT Lincoln Laboratory >>> 244 Wood St >>> Lexington, MA 02420 >>> 781-981-1395 >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From prvs=54438f2d1a=veytser@ll.mit.edu Fri Apr 6 12:34:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549B111E8093 for ; Fri, 6 Apr 2012 12:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biS0-Y68q3mX for ; Fri, 6 Apr 2012 12:34:13 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9721F844D for ; Fri, 6 Apr 2012 12:33:24 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q36JXLOk019897; Fri, 6 Apr 2012 15:33:22 -0400 From: "Veytser, Leonid - 0665 - MITLL" To: Stan Ratliff , Henning Rogge Date: Fri, 6 Apr 2012 15:33:17 -0400 Thread-Topic: [manet] DLEP and different control and data interfaces Thread-Index: Ac0ULB8k1QmhC21nQAG9+sGuA5ep+Q== Message-ID: In-Reply-To: <4FAFD83C-5D3C-4244-8476-437A9D5B351C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3416571197_36026603" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-06_03:2012-04-05, 2012-04-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204060219 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:34:14 -0000 --B_3416571197_36026603 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit It seems that on the router end there will now need to be a mapping maintained between each control interface to its respective data interface and the Peer Offer/Peer Update messages modified to include data interface's addressing information? Or I am missing more potential complexity? Lenny On 4/6/12 2:50 PM, "Stan Ratliff" wrote: >Actually, from the router's perspective, the assumption is that the >neighbor exists "on this interface". This is just one opinion, but >introducing the notion of separate interfaces for the control plane >and the data traffic *from the router's perspective* really explodes >the complexity of the implementation. > >Regards, >Stan > >On Apr 6, 2012, at 2:36 PM, Henning Rogge wrote: > >> I don't think DLEP makes any assumptions over which interface it is >> running or on what kind of transport. Sending it "out of band" would >> even be preferred in most cases, because its easier to keep the DLEP >> packets from reaching the radio interface. >> >> Henning Rogge >> >> On Fri, Apr 6, 2012 at 20:32, Veytser, Leonid - 0665 - MITLL >> wrote: >>> There are some radio systems that have separate interfaces for data >>> and >>> control. Please correct me if I am wrong, but it looks like >>> currently DLEP >>> only handles the case where both DLEP control packets and data >>> packets are >>> sent in-band (i.e. over the same interface). If two different >>> interfaces are >>> used for control and data, the IPv4 and IPv6 addresses provided by >>> Peer >>> Offer message would refer to the control interface of the router >>> and the >>> radio would have no knowledge of the router's data interface >>> addressing >>> information. However, the addressing information of the data >>> interface would >>> be needed for the neighbor session messages (e.g. Neighbor Up). >>> >>> Has there been any interest in supporting separate data and control >>> interfaces? It seems that if the Peer Offer message added optional >>> fields to >>> specify some of the addressing information of the data interface >>> that this >>> capability would now be supported. >>> >>> Thanks, >>> >>> Lenny >>> >>> ------------------------------------------------------------ >>> Leonid Veytser >>> Airborne Networks Group >>> MIT Lincoln Laboratory >>> 244 Wood St >>> Lexington, MA 02420 >>> 781-981-1395 >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > --B_3416571197_36026603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUCAYJKoZIhvcNAQcCoIIT+TCCE/UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeswggTPMIIDt6ADAgECAgpihG8cAAAAAC1rMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTExMjI3MTYyODU1WhcNMTIxMjI2MTYyODU1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdWZXl0c2VyLkxlb25pZC41MDAwNzQxNTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANBF4Y0/hZ3+J/npN95KyvuhQb2eS9tWnzI40+tJEiPTPMki Ivme5U+lZKdLqKlKGDF9YwzqlT9Sf9LGuOuVNm7SyZKtEoGLymG0KbEsqF/XSRfA6vXC1wP8 BT9lmtX5E0QPoD41gUVXBZI8PhHJzaUKNa7oQXV01e2Dm3BZPx/xA1FtB6ycimaUkR3C3HrD SVwqTVAYu8Lc7zKnHX7j6iRcARq+LpvZmP9bPTpUshTdNchpeDNXyGX8Ya92taY+ci1RSYue eIqXPYzIzAYsqC9099pMNqbpsjh9fXY962bvN0zBhUU3b0pVwmDb7pXQkCUGecnVn6atCQih Fs2pCNUCAwEAAaOCAZcwggGTMB0GA1UdDgQWBBRBKF2lUtWmcUSlOs2zp7qyw6qtzDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMB0GA1UdEQQWMBSBEnZleXRzZXJAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAJfyjis+AWozNXIgISFdBUk+FH/th+XP67xOtELyZ9ehBLzpCs8qxdHHV5okK N61UQXzOuCxhJAoQ01EYE0RaSiOaJztQ9mQvft88O2dz5RLzAn43A8uaL6+WGazwYvv27Cdr Ex/wR+EcT8WwG7dYEDsulHdfy/FehYYj4X2Rro/g97qFi3pGrldull2k2E7srJ2NzF16hUHl ncP6VDHmY7y0KOL5JtYV3jEH0aAa2Wh+KkNkEy5koaU+UNPepe8qc4qa0r2QSuoxkILfOKPv ByR6HJGXgdfr4AqCPkNuPvCtWJlFRKXm24lByx2yhHseK0dyIEaetcsWyqfVAYrS4zCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIE0jCCA7qgAwIBAgIKYoW3/gAAAAAtbTANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTExMTIyNzE2MzA0NVoXDTEyMTIyNjE2MzA0NVowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXVmV5dHNlci5MZW9uaWQuNTAwMDc0MTUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDwMmGDau9vm9YxzGp2R79H7zzdooLgHdRVLa/Gr3mv79C3 q4pjsSy1dFZZbEHq9Yqv2x/sPtA0mT3vsDGc+gwVoICu14TdLT1Ymv33b/XrwtC4PmoJlf0Z Ar5Re4uCKv7vLL9GU5xzeslALq25hGHye6aFNAUmKWR/MAcG+TQfwbj7tuiqnl4ChA13aPnb S0KQ6iutjpQ6J4qMA3j2DBxI27SBu7xaLPEQeYkyDqYT4KCr60l6Oxw7OhOkAfegZUzrp1SL 2nknDSoHdnRHugHciIFRApD2JxW1+F1fVI+vNbMBrGBtJ7bLr5VbkgO1UBQ/y1/15kIxppFe O2s1z9FfAgMBAAGjggGaMIIBljAdBgNVHQ4EFgQU0OGl4rKn6M4U+3c0zGwTJdtGgrQwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAdBgNVHREEFjAUgRJ2ZXl0c2VyQGxsLm1pdC5lZHUwDQYJKoZI hvcNAQELBQADggEBAJ0pbow7ESnEEOIIe83aZpbFO2YWH7kpwqVC8OgciZmiqvFSiGebToMv XpB6yXzbaPK5XTuM6Jx1v2GPmHDD6kNspV0R4I5X56ouRt2Hodkl+p7NCTfW6sBaKI4ku1Cl L1Zbgg72kYizfqioISB4DFZFYg7YReSvbiKVqQP+VN9kALAEOfAEG2Z1Hqr8+gHN38CgN/49 /Lp8j+d9kJ3mV1ssZMmR/6aDUDihgv09+e72XQhP24khFLdecSpV6qQ3W+Fc+9KtpnnI61U4 vzHdaOfCRZdzOoQ0t0Y9uOMaxtuV4iXA0na9ACIO6JNIKTE0IUtcuCH0pkv4TmifMIk1pUAx ggHlMIIB4QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTICCmKEbxwAAAAALWsw CQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTamSeE+R0d8RXgem24eageftXffTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA0MDYxOTMzMTdaMA0G CSqGSIb3DQEBAQUABIIBAA5zyUwO1gLJYiDEbGudv8bPhgBDEx4LMwBHCiGUAehWWRNAr019 p3CVF6MCTOUmgQe6e5Igcw56FgpvDkE/nK3VBNglBtf7/MLza+fDbnFYm//IqqRTpKz5QY1x MdneKUOLPaEKTezdIIGl4RC6rMzvLSDBoqUX/V/jqbZAUnhzsKaGgumfdN/zSpWTdxmOikgC cr1bx+zuRJwAOa6qqVDa3Di0+AcXxL3+8q7haqkEZlWqbSYzTyQbZi/spD7dn9IvA0PtFeT0 rz6bYgBwdIDN1juRuV1H3b6DKW1tkk13TKuBom55gRRfVo4Jrk8cHvZuxg26sq8i2bGFYjgV wlQ= --B_3416571197_36026603-- From sratliff@cisco.com Fri Apr 6 17:43:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB5411E80A0 for ; Fri, 6 Apr 2012 17:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PZyf0QIkjFO for ; Fri, 6 Apr 2012 17:43:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 080FF11E8086 for ; Fri, 6 Apr 2012 17:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3260; q=dns/txt; s=iport; t=1333759431; x=1334969031; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=FalbUT8wn323FBZHuHptQc+2cRp65QfO2qmGIlNSHhU=; b=mP4+1IbKgfH6B6VQkp2+WikYsRlJBrblj5b4WBnt0L6TCq/lhEjNeuoB 0poi/LyPXtpd0rmv1hOt3sPx9ude7mBAj6cG5tUQnzF0HhoIqou1ikNVd BZX8z6+1izKcAjjgSEbiWlTSxb+ZxxVzS4XoME0NvLpeIAIq/IFmDz8ve s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEmNf0+tJXG8/2dsb2JhbABAAw65I4EHggkBAQEDAQEBAQ8BJQI0CwULCxguJzAGEyKHZwULnmKXZQSNJ4JGYwSVbI5NgWmCMFM X-IronPort-AV: E=Sophos;i="4.75,384,1330905600"; d="scan'208";a="72545092" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 07 Apr 2012 00:43:50 +0000 Received: from rtp-sratliff-8713.cisco.com (rtp-sratliff-8713.cisco.com [10.116.179.212]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q370hnGX028332; Sat, 7 Apr 2012 00:43:50 GMT Message-Id: <580486CC-4222-47B8-B19C-F294F74B5664@cisco.com> From: Stan Ratliff To: "Veytser, Leonid - 0665 - MITLL" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Apr 2012 20:43:49 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and different control and data interfaces X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 00:43:51 -0000 Use of different control/data planes effects basically all messages.... I really don;t think it's worth the added complexity. Regards, Stan On Apr 6, 2012, at 3:33 PM, Veytser, Leonid - 0665 - MITLL wrote: > It seems that on the router end there will now need to be a mapping > maintained between each control interface to its respective data > interface > and the Peer Offer/Peer Update messages modified to include data > interface's addressing information? Or I am missing more potential > complexity? > > Lenny > > > On 4/6/12 2:50 PM, "Stan Ratliff" wrote: > >> Actually, from the router's perspective, the assumption is that the >> neighbor exists "on this interface". This is just one opinion, but >> introducing the notion of separate interfaces for the control plane >> and the data traffic *from the router's perspective* really explodes >> the complexity of the implementation. >> >> Regards, >> Stan >> >> On Apr 6, 2012, at 2:36 PM, Henning Rogge wrote: >> >>> I don't think DLEP makes any assumptions over which interface it is >>> running or on what kind of transport. Sending it "out of band" would >>> even be preferred in most cases, because its easier to keep the DLEP >>> packets from reaching the radio interface. >>> >>> Henning Rogge >>> >>> On Fri, Apr 6, 2012 at 20:32, Veytser, Leonid - 0665 - MITLL >>> wrote: >>>> There are some radio systems that have separate interfaces for data >>>> and >>>> control. Please correct me if I am wrong, but it looks like >>>> currently DLEP >>>> only handles the case where both DLEP control packets and data >>>> packets are >>>> sent in-band (i.e. over the same interface). If two different >>>> interfaces are >>>> used for control and data, the IPv4 and IPv6 addresses provided by >>>> Peer >>>> Offer message would refer to the control interface of the router >>>> and the >>>> radio would have no knowledge of the router's data interface >>>> addressing >>>> information. However, the addressing information of the data >>>> interface would >>>> be needed for the neighbor session messages (e.g. Neighbor Up). >>>> >>>> Has there been any interest in supporting separate data and control >>>> interfaces? It seems that if the Peer Offer message added optional >>>> fields to >>>> specify some of the addressing information of the data interface >>>> that this >>>> capability would now be supported. >>>> >>>> Thanks, >>>> >>>> Lenny >>>> >>>> ------------------------------------------------------------ >>>> Leonid Veytser >>>> Airborne Networks Group >>>> MIT Lincoln Laboratory >>>> 244 Wood St >>>> Lexington, MA 02420 >>>> 781-981-1395 >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> From john.dowdell@cassidian.com Mon Apr 9 08:05:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A398921F874F for ; Mon, 9 Apr 2012 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYpW7Gg+O8+m for ; Mon, 9 Apr 2012 08:05:15 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id D819E21F874A for ; Mon, 9 Apr 2012 08:05:13 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 09 Apr 2012 17:05:09 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 9 Apr 2012 17:05:09 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 17:05:08 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 17:05:08 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1662.3228A1C4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Apr 2012 16:08:11 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DEE7CE18@SUKNPT8108.cogent-dsn.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DLEP draft 2 TOC typo Thread-Index: Ac0WYpRV/6U6ecqITrecJgl8L1Lfrw== From: "John Dowdell" To: X-OriginalArrivalTime: 09 Apr 2012 15:05:08.0776 (UTC) FILETIME=[276E5280:01CD1662] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18828.000 X-TM-AS-Result: No--5.331200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [manet] DLEP draft 2 TOC typo X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:05:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1662.3228A1C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that there is a typo in the table of contents in draft-ietf-manet-dlep-02. TOC entry 10.13 on page 3 reads Peer Termination sub-TLV, but section 10.13 is actually titled Status sub-TLV. =20 Regards John =20 =20 ------_=_NextPart_001_01CD1662.3228A1C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that there is a typo in the table of = contents in draft-ietf-manet-dlep-02. TOC entry 10.13 on page 3 reads Peer Termination sub-TLV, but section = 10.13 is actually titled Status sub-TLV.

 

Regards

John

 

 

------_=_NextPart_001_01CD1662.3228A1C4-- From ulrich@herberg.name Mon Apr 9 10:36:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3521F8736 for ; Mon, 9 Apr 2012 10:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjmn5B2gTjAo for ; Mon, 9 Apr 2012 10:36:39 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id A934C21F869E for ; Mon, 9 Apr 2012 10:36:39 -0700 (PDT) Received: by dady13 with SMTP id y13so7652394dad.27 for ; Mon, 09 Apr 2012 10:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N2vEQhT6v9dNOxKGAgyK/2NTJN+RLRe7bTswNW09CfM=; b=JrNGAqlT9nHpho5HP2Q77xrT3Y3ll7ddJVNgjww0ZS7jk6OjbnVxd3Seu1+xAlaW71 eedmo2F/A0f1q7ukuO7Vkwx+kOKQ7l9vnx2FsZwizzZADYA++m1ARpor/yHAJoapCDXa GDb9X0xowBEEyC8aU8+6u7+KJpPCm+Y2CySvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=N2vEQhT6v9dNOxKGAgyK/2NTJN+RLRe7bTswNW09CfM=; b=CD+5bV72cAr01+FXGp1WF34UGIXtXvobfIo7JE3z8K+0kNFDLgFWbR7V3FMtPEDYXK gbEqEFz/kkI5qDGgO2Kfor4VHqMnOFNNBWUp+aJlsPvHgJ6pR9pNxM9qXCmDalAjPi3o f2x9zamG0RwC/DsJz8ytwCUIQZLb0uMsL8xflS138WVoxX60Ty7r+dRC9T4ryxxXolnG zotwDrpMUj+UZIjr/jNK7VrYzLo4CL4e9GE1mj1yXkw3p/GwB9fzBULO/i7M6vEVWP+Z Wb02Re+oS3csynAiKBfSEjE4zGoxmqYiBIwOjoS7Pk28ebgnK02uD3ZrK0KkA9j1mPvX tyCg== MIME-Version: 1.0 Received: by 10.68.222.165 with SMTP id qn5mr21129360pbc.88.1333992994828; Mon, 09 Apr 2012 10:36:34 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Mon, 9 Apr 2012 10:36:34 -0700 (PDT) In-Reply-To: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> Date: Mon, 9 Apr 2012 10:36:34 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=047d7b2ee03d96f1ae04bd42724a X-Gm-Message-State: ALoCoQm3ele8CQawKX8vo3Z+Qx443Q0y5uskAi7wpnYghIiPN0qDEfK5zQVFAcWbNTTjMfIclI6g Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and multi-hop neighbours X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:36:41 -0000 --047d7b2ee03d96f1ae04bd42724a Content-Type: text/plain; charset=ISO-8859-1 Hi, I agree with Chris' position. Using message/address block TLVs instead of sub-TLVs would not waste space from the registry when using message specific TLVs. And with the type extension, there are plenty of available TLVs anyway. Henning mentioned in one of the previous emails that currently DLEP does not really use the 5444 message format, but rather a 5444-wrap-around of a proprietary format. I somewhat agree with that. A common RFC5444 parser could not deal with DLEP messages, an additional parser would need to be implemented, leading to additional code. Thus my desire to use address blocks and address/message TLVs rather than sub-TLVs and addresses in TLVs. I don't see why this would lead to additional complexity, assuming that an RFC5444 parser is required anyway for the L3 routing protocol. >From skimming through the 100 emails that have been exchanged during my one-week vacation, it seems that there is some consensus that using MAC addresses in address blocks and IP addresses in TLVs seems to be a reasonable compromise. (at least it sounds reasonable to me, but not being a DLEP specialist, I might miss something). Since there are existing implementations and deployments, it could be helpful for this discussion to see some examples of typically exchanged messages (with real MAC/IP addresses and metrics etc) in a human-readable format. This would allow for better understanding what the messages look like (e.g. how many IP addresses, what kind of metric information is associated with which addresses etc). That could be even added to the DLEP appendix, similar to RFC6130/OLSRv2. Regards Ulrich On Thu, Apr 5, 2012 at 7:43 AM, Stan Ratliff wrote: > But the fact that they're in two different spaces means that, by > definition, they could wind up numbered differently. Even if the initial > allocation is done "correctly", when considering follow-on additions (as > mentioned by Tom Henderson), you can't guarantee the same code point will > be available in both spaces. The way we've currently done it, if at some > point in the future, there is a need for a "Size-of-tin-can to > length-of-string ratio" metric, then fine. It gets allocated - ONCE - out > of the DLEP defined space. Not TWICE - and *hopefully* that same one - out > of two different spaces. > > As to the utility of a generic 5444 parser, I see that this may save > someone a few lines of code - but at what cost? IMO, this makes the > protocol MUCH more complex. And while we're on the topic of code, as I > mentioned in Paris, there are 3 *existing* implementations of DLEP code. I > feel Thomas' pain when mentioning "running code" - or have we changed the > IETF mantra to "rough consensus, and to hell with the running code"??? > > Regards, > Stan > > > On Apr 5, 2012, at 10:22 AM, Dearlove, Christopher (UK) wrote: > > Message TLVs and address block TLVs are independent spaces. So we're not >> really here talking about two different TLVs, but the same TLV, existing in >> two spaces. As an example look at RFC 5497 which defines validity and >> interval time TLVs. These were wanted by OLSRv2 (and NHDP) as message TLVs, >> but some people wanted them also defined as address block TLVs for possible >> per-address use (though no one has yet done so). But you just describe >> once, and IANA allocates twice. It's just paperwork, not a real addition in >> complexity. (It's slightly more complicated in 5497, as even the two TLVs >> have much in common, so there are two layers of description.) >> >> And as has been previously said, you can consume 0 TLVs from the global >> space if you want to, by making the TLVs message type specific. And >> allowing that types are really 16 bit numbers (half is called a type >> extension, but it is in effect 8 bits of the overall type) there are quite >> a lot of TLVs. Obviously you'd logically organise the selected types. >> >> The point would be to allow a generic 5444 parser, such as that several >> people already have, to be able to fully parse a DLEP message into some >> sort of associative data structure without any new code needing to be >> written for DLEP alone. And the overall DLEP code could be simpler. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> Sent: 05 April 2012 14:58 >> To: Dearlove, Christopher (UK) >> Cc: Henning Rogge; Rick Taylor; manet@ietf.org >> Subject: Re: [manet] DLEP and multi-hop neighbours >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> ------------------------------**-------------------------- >> >> My apologies for being dense... >> >> So, we've gone from a set of sub-TLV's that are common in all cases to >> a notion where it's entirely possible (wording in 5444 >> notwithstanding) where Latency could be known by 2 different TLV's? >> One referencing an Address block, and the other a Message TLV? And >> this is supposed to make the protocol "better"? And how many 5444 >> TLV's are we talking about consuming? One of the biggest complaints >> about the earlier versions of the protocol (specifically, from Justin >> Dean) was that we were consuming too much of the TLV number space in >> 5444. So, we went to an implementation where we consumed exactly 1. I >> don't see how this makes anything better... >> >> Regards, >> Stan >> >> On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote: >> >> I had in mind separate TLVs, both address block and message, for >>> each meaningful piece of data. >>> >>> Thus, for example, we might have a TLV for data rate, a TLV for >>> delay etc. These might use different subtypes of a single TLV type, >>> which we might use the collective term metric for. There mcould be >>> message and address block versions of the TLV, identical except for >>> the TLV space. Those in an address block TLV block then indicate >>> which MAC address they apply to, implicitly a neighbour, and those >>> in the message TLV block apply locally. If we have a data rate but >>> not a delay for a neighbour then there is no TLV of the delay type >>> associated with that MAC address. >>> >>> (Actually, in another secondary point, it might make things easier >>> if the metric value allowed an "unknown" option, probably coded >>> zero, to allow multivalue TLVs to span over ranges including some >>> addresses with known e.g. delays and some without. But let's not get >>> hung up on this point now.) >>> >>> IP addresses are then another meaningful piece of data in the sense >>> of my first paragraph above. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: Henning Rogge [mailto:hrogge@googlemail.com] >>> Sent: 04 April 2012 18:23 >>> To: Rick Taylor >>> Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org >>> Subject: Re: [manet] DLEP and multi-hop neighbours >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> ------------------------------**-------------------------- >>> >>> On Wed, Apr 4, 2012 at 19:14, Rick Taylor >>> wrote: >>> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org**] On >>>>> Behalf >>>>> >>>> Of >>>> >>>>> Stan Ratliff >>>>> >>>>> On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote: >>>>> >>>>> That says that a device will have a MAC address. However I'm sure >>>>>> I've seen a post in this thread saying that a device might not have >>>>>> a MAC address. >>>>>> >>>>> >>>>> In the current implementation, every RF partner (neighbor) will have >>>>> some sort of Layer 2 address. There's a bit of a side conversation >>>>> about how a router would communicate with it's LOCAL radio - for >>>>> example, if the router were a card in a chassis, and the radio was >>>>> the >>>>> next card over in the same chassis... >>>>> >>>> >>>> I always imagined these LOCAL messages would remain as is specified >>>> in >>>> the draft: Message-Block TLVs... >>>> >>> >>> Or a series of Message-TLVs, one for each parameter we need. This >>> makes it very easy to leave out parameters that are not necessary and >>> even add optional data to DLEP orders later. >>> >>> But assuming that a MAC address is always present, then the 5444 >>>>>> natural thing to do would be to use the MAC addresses as the >>>>>> addresses in the address block. No address compression advantages, >>>>>> but now it's straightforward to associate information with those >>>>>> addresses, in an indexed way, with metrics etc. being normal >>>>>> TLVs. A >>>>>> good generic 5444 parser will then produce some sort of MAC address >>>>>> to other information map or other data structure. >>>>>> >>>>>> Then that leave me with "router to LOCAL radio" communication - >>>>> information that "my radio" wants to communicate about itself, and >>>>> *all* of the traffic associated with it. That's currently in DLEP - >>>>> the notion that a radio could quickly state "the maximum data rate >>>>> on >>>>> all destinations via me is X". Not sure how to do that while we're >>>>> encoding MAC addresses into address blocks. Also, that gives the >>>>> metrics the notion of existing "within a context" - either they >>>>> apply >>>>> to a single RF partner (a neighbor), or all RF partners via the >>>>> radio >>>>> - that's what the current DLEP refers to as a "peer-level metric". >>>>> >>>> >>>> No association with a neighbour, no Address-Block TLVs, just >>>> Message-Block TLVs. >>>> >>> Yes, message TLVs are a good solution to transport information about >>> the whole radio. >>> >>> Henning Rogge >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> >>> >>> ************************************************************************ >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ************************************************************************ >>> >>> >> >> > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --047d7b2ee03d96f1ae04bd42724a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I agree with Chris' position. Using message/address block TL= Vs instead of sub-TLVs would not waste space from the registry when using m= essage specific TLVs. And with the type extension, there are plenty of avai= lable TLVs anyway.

Henning mentioned in one of the previous emails that currently DLEP doe= s not really use the 5444 message format, but rather a 5444-wrap-around of = a proprietary format. I somewhat agree with that. A common RFC5444 parser c= ould not deal with DLEP messages, an additional parser would need to be imp= lemented, leading to additional code. Thus my desire to use address blocks = and address/message TLVs rather than sub-TLVs and addresses in TLVs. I don&= #39;t see why this would lead to additional complexity, assuming that an RF= C5444 parser is required anyway for the L3 routing protocol.

From skimming through the 100 emails that have been exchanged during my= one-week vacation, it seems that there is some consensus that using MAC ad= dresses in address blocks and IP addresses in TLVs seems to be a reasonable= compromise. (at least it sounds reasonable to me, but not being a DLEP spe= cialist, I might miss something).

Since there are existing implementations and deployments, it could be h= elpful for this discussion to see some examples of typically exchanged mess= ages (with real MAC/IP addresses and metrics etc) in a human-readable forma= t. This would allow for better understanding what the messages look like (e= .g. how many IP addresses, what kind of metric information is associated wi= th which addresses etc). That could be even added to the DLEP appendix, sim= ilar to RFC6130/OLSRv2.

Regards
Ulrich

On Thu, Apr 5, 2012= at 7:43 AM, Stan Ratliff <sratliff@cisco.com> wrote:
But the fact that they're in two different spaces means that, by defini= tion, they could wind up numbered differently. Even if the initial allocati= on is done "correctly", when considering follow-on additions (as = mentioned by Tom Henderson), you can't guarantee the same code point wi= ll be available in both spaces. The way we've currently done it, if at = some point in the future, there is a need for a "Size-of-tin-can to le= ngth-of-string ratio" metric, then fine. It gets allocated - ONCE - ou= t of the DLEP defined space. Not TWICE - and *hopefully* that same one - ou= t of two different spaces.

As to the utility of a generic 5444 parser, I see that this may save someon= e a few lines of code - but at what cost? IMO, this makes the protocol MUCH= more complex. And while we're on the topic of code, as I mentioned in = Paris, there are 3 *existing* implementations of DLEP code. I feel Thomas&#= 39; pain when mentioning "running code" - or have we changed the = IETF mantra to "rough consensus, and to hell with the running code&quo= t;???

Regards,
Stan


On Apr 5, 2012, at 10:22 AM, Dearlove, Christopher (UK) wrote:

Message TLVs and address block TLVs are independent spaces. So we're no= t really here talking about two different TLVs, but the same TLV, existing = in two spaces. As an example look at RFC 5497 which defines validity and in= terval time TLVs. These were wanted by OLSRv2 (and NHDP) as message TLVs, b= ut some people wanted them also defined as address block TLVs for possible = per-address use (though no one has yet done so). But you just describe once= , and IANA allocates twice. It's just paperwork, not a real addition in= complexity. (It's slightly more complicated in 5497, as even the two T= LVs have much in common, so there are two layers of description.)

And as has been previously said, you can consume 0 TLVs from the global spa= ce if you want to, by making the TLVs message type specific. And allowing t= hat types are really 16 bit numbers (half is called a type extension, but i= t is in effect 8 bits of the overall type) there are quite a lot of TLVs. O= bviously you'd logically organise the selected types.

The point would be to allow a generic 5444 parser, such as that several peo= ple already have, to be able to fully parse a DLEP message into some sort o= f associative data structure without any new code needing to be written for= DLEP alone. And the overall DLEP code could be simpler.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
chris.de= arlove@baesystems.com | http://www.baesystems.com

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


-----Original Message-----
From: Stan Ratliff [mailto:sratliff@cisco.com]
Sent: 05 April 2012 14:58
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; Rick Taylor; manet@ietf.org
Subject: Re: [manet] DLEP and multi-hop neighbours

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

My apologies for being dense...

So, we've gone from a set of sub-TLV's that are common in all cases= to
a notion where it's entirely possible (wording in 5444
notwithstanding) where Latency could be known by 2 different TLV's?
One referencing an Address block, and the other a Message TLV? And
this is supposed to make the protocol "better"? =A0And how many 5= 444
TLV's are we talking about consuming? One of the biggest complaints
about the earlier versions of the protocol (specifically, from Justin
Dean) was that we were consuming too much of the TLV number space in
5444. So, we went to an implementation where we consumed exactly 1. I
don't see how this makes anything better...

Regards,
Stan

On Apr 5, 2012, at 5:15 AM, Dearlove, Christopher (UK) wrote:

I had in mind separate TLVs, both address block and message, for
each meaningful piece of data.

Thus, for example, we might have a TLV for data rate, a TLV for
delay etc. These might use different subtypes of a single TLV type,
which we might use the collective term metric for. There mcould be
message and address block versions of the TLV, identical except for
the TLV space. Those in an address block TLV block then indicate
which MAC address they apply to, implicitly a neighbour, and those
in the message TLV block apply locally. If we have a data rate but
not a delay for a neighbour then there is no TLV of the delay type
associated with that MAC address.

(Actually, in another secondary point, it might make things easier
if the metric value allowed an "unknown" option, probably coded zero, to allow multivalue TLVs to span over ranges including some
addresses with known e.g. delays and some without. But let's not get hung up on this point now.)

IP addresses are then another meaningful piece of data in the sense
of my first paragraph above.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | =A0Fax: +44 1245 242124
chris.de= arlove@baesystems.com | http://www.baesystems.com

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


-----Original Message-----
From: Henning Rogge [mailto:hrogge@googlemail.com]
Sent: 04 April 2012 18:23
To: Rick Taylor
Cc: Stan Ratliff; Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] DLEP and multi-hop neighbours

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Wed, Apr 4, 2012 at 19:14, Rick Taylor
<Rick.Tay= lor@cassidian.com> wrote:
From: manet-bou= nces@ietf.org [mailto:manet-bounces@ietf.org] On
Behalf
Of
Stan Ratliff

On Apr 4, 2012, at 12:46 PM, Dearlove, Christopher (UK) wrote:

That says that a device will have a MAC address. However I'm sure
I've seen a post in this thread saying that a device might not have
a MAC address.

In the current implementation, every RF partner (neighbor) will have
some sort of Layer 2 address. There's a bit of a side conversation
about how a router would communicate with it's LOCAL radio - for
example, if the router were a card in a chassis, and the radio was
the
next card over in the same chassis...

I always imagined these LOCAL messages would remain as is specified
in
the draft: Message-Block TLVs...

Or a series of Message-TLVs, one for each parameter we need. This
makes it very easy to leave out parameters that are not necessary and
even add optional data to DLEP orders later.

But assuming that a MAC address is always present, then the 5444
natural thing to do would be to use the MAC addresses as the
addresses in the address block. No address compression advantages,
but now it's straightforward to associate information with those
addresses, in an indexed way, with metrics etc. being normal
TLVs. A
good generic 5444 parser will then produce some sort of MAC address
to other information map or other data structure.

Then that leave me with "router to LOCAL radio" communication - information that "my radio" wants to communicate about itself, an= d
*all* of the traffic associated with it. That's currently in DLEP -
the notion that a radio could quickly state "the maximum data rate
on
all destinations via me is X". Not sure how to do that while we're=
encoding MAC addresses into address blocks. Also, that gives the
metrics the notion of existing "within a context" - either they apply
to a single RF partner (a neighbor), or all RF partners via the
radio
- that's what the current DLEP refers to as a "peer-level metric&q= uot;.

No association with a neighbour, no Address-Block TLVs, just
Message-Block TLVs.
Yes, message TLVs are a good solution to transport information about
the whole radio.

Henning Rogge

--
Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that
was before the present government."


*************************************************************= *******
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
h= ttps://www.ietf.org/mailman/listinfo/manet

--047d7b2ee03d96f1ae04bd42724a-- From internet-drafts@ietf.org Mon Apr 9 11:51:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D09221F87B2; Mon, 9 Apr 2012 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS-cQxBBvsjG; Mon, 9 Apr 2012 11:51:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DC521F8777; Mon, 9 Apr 2012 11:51:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120409185103.15464.99873.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 11:51:03 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:51:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Security Threats for NHDP Author(s) : Ulrich Herberg Jiazi Yi Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-threats-00.txt Pages : 15 Date : 2012-04-09 This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-00.txt From pars.mutaf@gmail.com Mon Apr 9 22:25:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3990E21F86F6 for ; Mon, 9 Apr 2012 22:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJUFH-q3EWMe for ; Mon, 9 Apr 2012 22:25:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A731121F86F3 for ; Mon, 9 Apr 2012 22:25:39 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7635914obb.31 for ; Mon, 09 Apr 2012 22:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Uz7dzCrm7WoNJKtY31QsBv4rlRENNGKxdcAZfO6DB/M=; b=Uzf+xbOX2gIgMYSi1NeagDIHts7+L8Zncti3g5Rcw9D/xJP4x5IDoZvO+5ktB0LkTy gSgJyYoEiBGI+BHILJ5J8civWytI90f3JTGmiQ6CKuDP0t0Mnz6UdZ5ACOMUQx9iRF0k xBJffH8AC30wpdayh2nZZ92Q2gnf9XKRhRbKHQ2IwHzPzQS9PwiEjKsLzt0KyLBv/U3v OqzF9/XB9rIilASNwdN2yQ/7TWohTOcYkLg5ynMIft1E76aakanK4yOeHheXKRPkAmJQ /VCK0B7dKNGUkG656FMqsSJENKzcQb7ks64hCPiT1UNZLUKjyKM2XZFvQXwFhJsa3CNY iFuQ== MIME-Version: 1.0 Received: by 10.182.114.70 with SMTP id je6mr14284024obb.30.1334035539279; Mon, 09 Apr 2012 22:25:39 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Mon, 9 Apr 2012 22:25:39 -0700 (PDT) Date: Tue, 10 Apr 2012 08:25:39 +0300 Message-ID: From: Pars Mutaf To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d0444746b6fbf8004bd4c5abb Subject: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:25:40 -0000 --f46d0444746b6fbf8004bd4c5abb Content-Type: text/plain; charset=ISO-8859-1 In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. --f46d0444746b6fbf8004bd4c5abb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In a disaster scenario, the base stations are down, everything is broken.= =A0

Just find a big balloon, attach the antennas to it, = send it to the air with an=A0electric=A0cable connected to a power generato= r on the ground.=A0

You have a base station in 1 hour.

=
Why spend=A0millions=A0of dollars/euros for this MANET effort?

Pars Mutaf
Asst. Prof.
--f46d0444746b6fbf8004bd4c5abb-- From henning.rogge@fkie.fraunhofer.de Mon Apr 9 23:04:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C572611E80A4 for ; Mon, 9 Apr 2012 23:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZroxcfX81v7 for ; Mon, 9 Apr 2012 23:04:28 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id ABCC521F844E for ; Mon, 9 Apr 2012 23:04:27 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHUBl-0005Ct-U7 for manet@ietf.org; Tue, 10 Apr 2012 08:04:25 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHUBl-0005YS-RX for manet@ietf.org; Tue, 10 Apr 2012 08:04:25 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:04:25 +0200 Message-ID: <4F83CD62.4030003@fkie.fraunhofer.de> Date: Tue, 10 Apr 2012 08:04:18 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050906070806010300060505" X-OriginalArrivalTime: 10 Apr 2012 06:04:25.0670 (UTC) FILETIME=[C83EF660:01CD16DF] X-Virus-Scanned: yes (ClamAV 0.97.3/14765/Tue Apr 10 07:33:00 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e1416103c0dc32859b3a1b60dee92644 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 06:04:28 -0000 This is a cryptographically signed message in MIME format. --------------ms050906070806010300060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 07:25, Pars Mutaf wrote: > In a disaster scenario, the base stations are down, everything is=20 broken. > > Just find a big balloon, attach the antennas to it, send it to the=20 air with > an electric cable connected to a power generator on the ground. > > You have a base station in 1 hour. I remember some people doing this in Japan, it was called "BallonNet" or = something like this. It works well for a backbone network as long as you = have Helium and nearly no wind. > Why spend millions of dollars/euros for this MANET effort? Communication in a MANET is bidirectional. With your high altitude=20 Baloon-Antenna it will be easy to transmit to a lot of people, but=20 getting replies is difficult because your collision domain is very large = (everyone in your range has to coordinate while transmitting data) and=20 the mobile nodes don't have that much transmission power. Still, I think your solution is not very useful in an urban environment=20 with high buildings (or with people going INTO the buildings), because=20 the line of sight will be blocked even for the Baloon Antenna. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050906070806010300060505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTAwNjA0MjNaMCMGCSqGSIb3DQEJBDEWBBQaFvOB0EKxIx3VWp6k6a14FOXZEzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBcDwweUmVaIjJWarOTG/wxyaJiABuokoxC4xEVuLDArOEiSV+TbLdi/CJOnn25 XJIhr9ICXpT+7p17e9B+3FwOMxtXLov5g87QQn6ebxibBrU++aHsKm/WHb7gibQMwmdir8Oe 06gVV+VU7iKgwnlmJxbokUZ2rdxfjUcB9HPzGyTUUwZ0tkFChQQCuiu6tMys4GrZhY4tIuGJ VaUGwRA4vVko0Of0K+8OsRUeKNCipCo4qEpaOZKb7Ggba/doHxjB9xYF9SXF7ZkEzK60G2Pj oS3IxPeO3+yLbthvkvimuZ/Kk4nNpd8/YA96Vd6VQaej1Zg1UtmEKoBZ6qEqsWvmAAAAAAAA --------------ms050906070806010300060505-- From pars.mutaf@gmail.com Tue Apr 10 00:47:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58821F8749 for ; Tue, 10 Apr 2012 00:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOvMyGyIFNSW for ; Tue, 10 Apr 2012 00:47:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC77721F8741 for ; Tue, 10 Apr 2012 00:47:12 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7788145obb.31 for ; Tue, 10 Apr 2012 00:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0aT900nM7mBhEcX23gr1jnbXPCcDhP853Sa2uju4XAo=; b=qbSKy2R9Uw2bIx2HQlYhE7pA7sRq0zsRu9tRKJSeTAd0gd2BywDkAuv1YaviBoGVpl rDiHsm6WMooSk1H/ECSxKtDTV7wROC0wcy87CvNdHsF1IG4u0BIbTIH3Ebts4pEPBwAG viE3n8wDwNgh6W+eaXK2rjlVTMBiPvDFBX6sF3c29Ky0kUmRXnYqKevU7824dscDntfm KyK4PuUo6BBgcDfDUojRINZ+naMbFcHgjv/20CgSu0+dF0gZ07fJWriDWJhwnYMYCLSo xeHYlrDmfNExDD3mMhXQO9M3laW+PfyCXP3TSgQa+QXuBazcYWUG+4IKFBRa6pL+I+jf QazA== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr14549614obw.10.1334044032260; Tue, 10 Apr 2012 00:47:12 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 00:47:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 10:47:12 +0300 Message-ID: From: Pars Mutaf To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d04447213a85a4004bd4e54e7 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:47:13 -0000 --f46d04447213a85a4004bd4e54e7 Content-Type: text/plain; charset=ISO-8859-1 More precisely, Just use a balloon at the same height as the previous base station and satellite... The same phones can be used. The balloon will make the interface to the satellite. To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground. On Tue, Apr 10, 2012 at 8:25 AM, Pars Mutaf wrote: > In a disaster scenario, the base stations are down, everything is broken. > > Just find a big balloon, attach the antennas to it, send it to the air > with an electric cable connected to a power generator on the ground. > > You have a base station in 1 hour. > > Why spend millions of dollars/euros for this MANET effort? > > Pars Mutaf > Asst. Prof. > --f46d04447213a85a4004bd4e54e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable More precisely,

Just use a balloon at the same height as the previo= us base station and satellite...

The same phones can be used. The b= alloon will make the interface to the satellite.

To solve the wind = problem (not sure if it is that important) we can use 3 cables to attach th= e balloon to the ground.



On Tue, Apr 10, 2012 at 8:25 AM, Par= s Mutaf <pars.= mutaf@gmail.com> wrote:
In a disaster scenario, the base stations are down, everything is broken.= =A0

Just find a big balloon, attach the antennas to it, = send it to the air with an=A0electric=A0cable connected to a power generato= r on the ground.=A0

You have a base station in 1 hour.

=
Why spend=A0millions=A0of dollars/euros for this MANET effort?

Pars Mutaf=
Asst. Prof.

--f46d04447213a85a4004bd4e54e7-- From henning.rogge@fkie.fraunhofer.de Tue Apr 10 01:13:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BEA21F87BA for ; Tue, 10 Apr 2012 01:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4U+f+CDEs+6 for ; Tue, 10 Apr 2012 01:13:38 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44421F8782 for ; Tue, 10 Apr 2012 01:13:38 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHWCn-0002ux-PK for manet@ietf.org; Tue, 10 Apr 2012 10:13:37 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHWCn-0000bh-Mg for manet@ietf.org; Tue, 10 Apr 2012 10:13:37 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 10:13:37 +0200 Message-ID: <4F83EBB0.7000704@fkie.fraunhofer.de> Date: Tue, 10 Apr 2012 10:13:36 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050206060308060509090004" X-OriginalArrivalTime: 10 Apr 2012 08:13:37.0485 (UTC) FILETIME=[D4B00FD0:01CD16F1] X-Virus-Scanned: yes (ClamAV 0.97.3/14765/Tue Apr 10 07:33:00 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:13:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050206060308060509090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/10/2012 09:47 AM, Pars Mutaf wrote: > More precisely, > > Just use a balloon at the same height as the previous base station and > satellite... Satellite connections are bandwidth limited (especially with compact=20 ground stations), expensive and have a high delay. > The same phones can be used. If you have a copy of the database of the cellphone providers. > The balloon will make the interface to the satellite. This would make it impossible to use directional antennas towards the=20 satellite, which will decrease your bandwidth even more. > To solve the wind problem (not sure if it is that important) we can use= 3 > cables to attach the balloon to the ground. Even with multiple cables the stability of a balloon depends on distance = between the cable attachment on the ground compared to wind speed. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050206060308060509090004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTAwODEzMzZaMCMGCSqGSIb3DQEJBDEWBBRYRjXidAEGwxiUa9pG+feWUJe0tjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBtT9o9i+hrllig82uE8Rywyfy/BxsR3S/3zXiheA8Tv7nfLCN7e2z/6KmhTz4c 213LyCx0NU+CMSfcENSaBWBtR76/1H0YJOvs4ZqCkJgC/m+t4/Y0WxiAIybui07pxdz8+s8Y PR6ZMJv1KWWQjey45j+/eVfWSzC7VBBfOlq1sRoTB/URUTALS6fGFG2LM4OHXoaohJSsxakr 6TmQQdITWcedx7/+Dke7ZaY1atTlrBI6ca9erM7ToyXnKW4E9SkHqkM1KLcLdga0uRgMcgUd slG9Fx5Bcj3TETJOx0McUbvcLPp5qdZB4qu0iog0viFNYF8GBoGPoyUiKb5I9vsKAAAAAAAA --------------ms050206060308060509090004-- From pars.mutaf@gmail.com Tue Apr 10 02:49:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE98F21F8826 for ; Tue, 10 Apr 2012 02:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adJR3dp5clYU for ; Tue, 10 Apr 2012 02:49:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF81321F8824 for ; Tue, 10 Apr 2012 02:49:53 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7945152obb.31 for ; Tue, 10 Apr 2012 02:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aPHFA5XUnL+ZK9sv1BZ/wEPW3+aA6XuZV3tFKkoo3GI=; b=N8kJhTNDbhPl5yMG1C8j0kZqMM3LTEWE6SNlAkIjlkJwwowGfxHb/Y+ivyzoaF4W3e Q1yNuqDZom7G9CRoK72psu7RB9saJw4KtDJYppWVPjE362IjOlLv2479/5Wy1pEwp/k4 boi6nUc+L/pBKkBvXl1my5H5aFzFeLB7SN2fLAaFqHNnG3raimgSIDeR6jARRgrVzhZa D4GDfnmUUJD1GNsrN7w97pceCW95D+3WM7Va4XiOE38eVDfITyQFlqr3MgZe38kTz8U5 2D5fyFnlDW4ZNOQOv53fwlRoBa15kuUej+dsnaN9dUs1s2rt5AUFGJXro7M1d7cJCqTZ BrUQ== MIME-Version: 1.0 Received: by 10.60.20.100 with SMTP id m4mr15568678oee.10.1334051393477; Tue, 10 Apr 2012 02:49:53 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 02:49:53 -0700 (PDT) In-Reply-To: <4F83EBB0.7000704@fkie.fraunhofer.de> References: <4F83EBB0.7000704@fkie.fraunhofer.de> Date: Tue, 10 Apr 2012 12:49:53 +0300 Message-ID: From: Pars Mutaf To: Henning Rogge Content-Type: multipart/alternative; boundary=e89a8fb1ef4c6b9e3704bd500bc7 Cc: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:49:54 -0000 --e89a8fb1ef4c6b9e3704bd500bc7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1. This solution can be developed. It is clearly better. Nodes forwarding others' packets doesn't seem realistic. 2. I don't know how limited the satellite connection bandwdith. I am not sure if high bandwidth is the real problem in the disaster scenario where people are dying. 3. Why not question MANET and accept it as if it were the absolute truth. What if everybody is dead, or I am the only one with cell phone? On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 04/10/2012 09:47 AM, Pars Mutaf wrote: > >> More precisely, >> >> Just use a balloon at the same height as the previous base station and >> satellite... >> > Satellite connections are bandwidth limited (especially with compact > ground stations), expensive and have a high delay. > > > The same phones can be used. >> > If you have a copy of the database of the cellphone providers. > > > The balloon will make the interface to the satellite. >> > This would make it impossible to use directional antennas towards the > satellite, which will decrease your bandwidth even more. > > > To solve the wind problem (not sure if it is that important) we can use = 3 >> cables to attach the balloon to the ground. >> > Even with multiple cables the stability of a balloon depends on distance > between the cable attachment on the ground compared to wind speed. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --e89a8fb1ef4c6b9e3704bd500bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1. This solution can be developed. It is clearly better. Nodes = forwarding others' packets doesn't seem realistic.=A0
2. I don't know how limited the satellite connection ban= dwdith. I am not sure if high bandwidth is the real problem in the disaster= scenario where people are dying.=A0
3. Why not question MANET and accept it as if it were the absol= ute truth. What if everybody is dead, or I am the only one with cell phone?=

On Tue, Apr 10, 2012 at 11:13 AM,= Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 04/10/2012 09:47 AM, Pa= rs Mutaf wrote:
More precisely,

Just use a balloon at the same height as the previous base station and
satellite...
Satellite connections are bandwidth limited (especially with compact ground= stations), expensive and have a high delay.


The same phones can be used.
If you have a copy of the database of the cellphone providers.


The balloon will make the interface to the satellite.
This would make it impossible to use directional antennas towards the satel= lite, which will decrease your bandwidth even more.


To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground.
Even with multiple cables the stability of a balloon depends on distance be= tween the cable attachment on the ground compared to wind speed.


Henning Rogge

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

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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


--e89a8fb1ef4c6b9e3704bd500bc7-- From D.He@surrey.ac.uk Tue Apr 10 03:29:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EF321F869E for ; Tue, 10 Apr 2012 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSOWuH+SbnGu for ; Tue, 10 Apr 2012 03:29:49 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1621F86A2 for ; Tue, 10 Apr 2012 03:29:49 -0700 (PDT) Received: from [195.245.230.131:56959] by server-9.bemta-3.messagelabs.com id 41/C3-10923-C9B048F4; Tue, 10 Apr 2012 10:29:48 +0000 X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-3.tower-78.messagelabs.com!1334053787!24912123!1 X-Originating-IP: [131.227.200.39] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3039 invoked from network); 10 Apr 2012 10:29:48 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-3.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 10 Apr 2012 10:29:48 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.208]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 10 Apr 2012 11:29:47 +0100 From: To: , Importance: high X-Priority: 1 Date: Tue, 10 Apr 2012 11:29:47 +0100 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0W/2iLtrWn1jsCTw+XZDbqylBnEwABGuE9 Message-ID: References: <4F83EBB0.7000704@fkie.fraunhofer.de>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org, andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:29:53 -0000 Hi Pars and Henning, one IST project called MONET (http://monet.tekever.com/) is innovative to i= nvestigate the possibility of using MANET in disaster relief communication scenarios. and the network = architecture=20 uses the satellite, high-attitude platform(plane, balloon) as a bridge or r= elay for disconnected areas of MANET for disaster scenarios. for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, rece= nt years 10MB bandwidth satellite links are also available on the martket (in uk). regard= ing delay, satellite may introduce the round trip delay however, does it really impact the VoIP = or video communications? it is relied on the quality of service if you get down the streaming bandwi= dth. satellite is a perfect solution to relay MANET traffics. at least it is better than n= othing.=20 Cheers, Dan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dan He Centre of Communication Systems Research University of Surrey Guildford GU2 7XH UK Tel:+44-1483-68-6016 fax:+44-1483-68-6011(attn: Dan He) ________________________________________ From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Pars Mut= af [pars.mutaf@gmail.com] Sent: 10 April 2012 10:49 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution 1. This solution can be developed. It is clearly better. Nodes forwarding o= thers' packets doesn't seem realistic. 2. I don't know how limited the satellite connection bandwdith. I am not su= re if high bandwidth is the real problem in the disaster scenario where peo= ple are dying. 3. Why not question MANET and accept it as if it were the absolute truth. W= hat if everybody is dead, or I am the only one with cell phone? On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge > wrote: On 04/10/2012 09:47 AM, Pars Mutaf wrote: More precisely, Just use a balloon at the same height as the previous base station and satellite... Satellite connections are bandwidth limited (especially with compact ground= stations), expensive and have a high delay. The same phones can be used. If you have a copy of the database of the cellphone providers. The balloon will make the interface to the satellite. This would make it impossible to use directional antennas towards the satel= lite, which will decrease your bandwidth even more. To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground. Even with multiple cables the stability of a balloon depends on distance be= tween the cable attachment on the ground compared to wind speed. Henning Rogge -- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 68= 5 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From pars.mutaf@gmail.com Tue Apr 10 03:39:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1FD21F8768 for ; Tue, 10 Apr 2012 03:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHO+70FeH04v for ; Tue, 10 Apr 2012 03:39:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0321F8683 for ; Tue, 10 Apr 2012 03:39:32 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8009911obb.31 for ; Tue, 10 Apr 2012 03:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/fU1MhoSlHQEtYZtpvPMEIYVlu2uNHFqeini2ctDeeY=; b=oiSzGrGBAOF4fIEkb4b2v1TGGz+QSsmqCWry6gjJqp/TLr/Dlw8OOiB45/A/VJT9Dt x76asdV3lwwBfidYwMQdyxBrE75mnl6Zc/cqj8+g0ZpSUw6IVOXq7bThVYhSXOZFx+N/ U+y/Qv7bxw+UkyxVOK4KlGvnzK1Bw82IeJKQaVvjLAVZ8PYbhGW5Jn5WES+KPLUZTWbd vBIFrmKHo96Ct+UwfFw3eHTERfhGMRC0y8SY5zqcNALgGjHTlJEsL/w+Ua/WzGonZll4 U5DtRmUp0lnZbYg8mNAXQapzU03GM03btbwKltXQoRtK7kV/fmA038gu1MFTLsgoocTT K7xg== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr15226672obw.10.1334054371737; Tue, 10 Apr 2012 03:39:31 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 03:39:31 -0700 (PDT) In-Reply-To: References: <4F83EBB0.7000704@fkie.fraunhofer.de> Date: Tue, 10 Apr 2012 13:39:31 +0300 Message-ID: From: Pars Mutaf To: D.He@surrey.ac.uk Content-Type: multipart/alternative; boundary=f46d04447213f03fbc04bd50bc50 Cc: manet@ietf.org, andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:39:33 -0000 --f46d04447213f03fbc04bd50bc50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 1:29 PM, wrote: > Hi Pars and Henning, > > one IST project called MONET (http://monet.tekever.com/) is innovative to > investigate the possibility > of using MANET in disaster relief communication scenarios. and the networ= k > architecture > uses the satellite, high-attitude platform(plane, balloon) as a bridge or > relay for disconnected > areas of MANET for disaster scenarios. > > for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, > recent years 10MB > bandwidth satellite links are also available on the martket (in uk). > regarding delay, satellite > may introduce the round trip delay however, does it really impact the VoI= P > or video communications? > it is relied on the quality of service if you get down the streaming > bandwidth. satellite > is a perfect solution to relay MANET traffics. at least it is better than > nothing. > Hi Dan, Why use MANET? Balloon+Satellite is enough. I understand if people wish to work on it as an exercise but there is no utility. Is there any? Pars > Cheers, > > Dan > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Centre of Communication Systems Research > University of Surrey > Guildford > GU2 7XH > UK > Tel:+44-1483-68-6016 > fax:+44-1483-68-6011(attn: Dan He) > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Pars > Mutaf [pars.mutaf@gmail.com] > Sent: 10 April 2012 10:49 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Replacing MANET with a simple solution > > 1. This solution can be developed. It is clearly better. Nodes forwarding > others' packets doesn't seem realistic. > 2. I don't know how limited the satellite connection bandwdith. I am not > sure if high bandwidth is the real problem in the disaster scenario where > people are dying. > 3. Why not question MANET and accept it as if it were the absolute truth. > What if everybody is dead, or I am the only one with cell phone? > > On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de= > > wrote: > On 04/10/2012 09:47 AM, Pars Mutaf wrote: > More precisely, > > Just use a balloon at the same height as the previous base station and > satellite... > Satellite connections are bandwidth limited (especially with compact > ground stations), expensive and have a high delay. > > > The same phones can be used. > If you have a copy of the database of the cellphone providers. > > > The balloon will make the interface to the satellite. > This would make it impossible to use directional antennas towards the > satellite, which will decrease your bandwidth even more. > > > To solve the wind problem (not sure if it is that important) we can use 3 > cables to attach the balloon to the ground. > Even with multiple cables the stability of a balloon depends on distance > between the cable attachment on the ground compared to wind speed. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 > 685 > mailto:henning.rogge@fkie.fraunhofer.de henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.de > > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --f46d04447213f03fbc04bd50bc50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 1:29 PM, <D.He@surrey.ac.uk&= gt; wrote:
Hi Pars and Henning,

one IST project called MONET (http://monet.tekever.com/) is innovative to investigate the= possibility
of using MANET in disaster relief communication scenarios. and the network = architecture
uses the satellite, high-attitude platform(plane, balloon) as a bridge or r= elay for disconnected
areas of MANET for disaster scenarios.

for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, rece= nt years 10MB
bandwidth satellite links are also available on the martket (in uk). regard= ing delay, satellite
may introduce the round trip delay however, does it really impact the VoIP = or video communications?
it is relied on the quality of service if you get down the streaming bandwi= dth. satellite
is a perfect solution to relay MANET traffics. at least it is better than n= othing.

Hi Dan,=A0

=
Why use MANET?

Balloon+Satellite is enough.

I understand if people wish to work on it as an exercis= e but there is no utility. Is there any?

Pars


Cheers,

Dan




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dan He
Centre of Communication Systems Research
University of Surrey
Guildford
GU2 7XH
UK
Tel:+44-1483-68-= 6016
fax:+44-1483-68-= 6011(attn: Dan He)
________________________________________
From: manet-bounces@ietf.org = [manet-bounces@ietf.org] On B= ehalf Of Pars Mutaf [pars.mutaf@gma= il.com]
Sent: 10 April 2012 10:49
To: Henning Rogge
Cc: manet@ietf.org
Subject: Re: [manet] Replacing MANET with a simple soluti= on

1. This solution can be developed. It is clearly be= tter. Nodes forwarding others' packets doesn't seem realistic.
2. I don't know how limited the satellite connection bandwdith. I am no= t sure if high bandwidth is the real problem in the disaster scenario where= people are dying.
3. Why not question MANET and accept it as if it were the absolute truth. W= hat if everybody is dead, or I am the only one with cell phone?

On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge <= ;henning.rogge@fkie.fra= unhofer.de<mailto:henning.rogge@fkie.fraunhofer.de>> wrote:
On 04/10/2012 09:47 AM, Pars Mutaf wrote:
More precisely,

Just use a balloon at the same height as the previous base station and
satellite...
Satellite connections are bandwidth limited (especially with compact ground= stations), expensive and have a high delay.


The same phones can be used.
If you have a copy of the database of the cellphone providers.


The balloon will make the interface to the satellite.
This would make it impossible to use directional antennas towards the satel= lite, which will decrease your bandwidth even more.


To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground.
Even with multiple cables the stability of a balloon depends on distance be= tween the cable attachment on the ground compared to wind speed.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961<tel:%2B49%20228%209435-961>, =A0 Fax +49 228 9435 685<= /a><tel:%2B49%20228%209435%20685>
mailto:henning.rogge@fk= ie.fraunhofer.de<mailto:henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.de

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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



--f46d04447213f03fbc04bd50bc50-- From teco@inf-net.nl Tue Apr 10 03:57:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90611E8087 for ; Tue, 10 Apr 2012 03:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rF4wQmIZmvH for ; Tue, 10 Apr 2012 03:57:12 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABCE411E8072 for ; Tue, 10 Apr 2012 03:57:10 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3383071wgb.13 for ; Tue, 10 Apr 2012 03:57:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=rgE6g3yWABYcXF7xRyfb/B2aCR8/9fs6MKXebjMikPU=; b=Mwf9grHIGMyeH9t0tmZQM8PR7E6pBidFr6kN3ykJLAzFc0SoRGUdhrbH07Nke90Wa0 Z3IIlnNuU/7hgzeP1Tqgjfa82Nf7kcNheKVQpbNV+O/EIrc8lWQ9cGUgP/qApVBAyIS0 W1Wgp4RhBAA2MKwjvXWBFUDfoopT4khj+csRwHh5nQsntrPwSiqm3W3v7brcdl3bHCJw wh9Z6uEGIUy9QsWVDDFgR1nHqx2UlL2nF2mAuc48KFxFvjU89iHmAvUrzOFt9Soq7IjO 8/SUu7eeMXmGIWTqNgLzEipPHMEmra8ZXCW4bjDB96eboNw0T2Hw1l3qTYXsgysDRGAW onNg== Received: by 10.180.92.228 with SMTP id cp4mr5998278wib.2.1334055429734; Tue, 10 Apr 2012 03:57:09 -0700 (PDT) Received: from [172.16.4.85] ([188.205.88.52]) by mx.google.com with ESMTPS id ff9sm36924055wib.2.2012.04.10.03.57.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 03:57:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_D220F32F-98DF-4C16-B57C-9023A8880326" From: Teco Boot In-Reply-To: Date: Tue, 10 Apr 2012 12:57:07 +0200 Message-Id: <57C7B9F2-7201-4556-9DD3-5C3DCA727D55@inf-net.nl> References: <4F83EBB0.7000704@fkie.fraunhofer.de> To: Pars Mutaf X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQky9L+WoWmS81IrW2IyBup2pdaAoYBmNLKffGzds3RLn4QQJ6viB/df30My5FdYhq8bmOoq Cc: manet@ietf.org, andre.oliveira@tekever.com, D.He@surrey.ac.uk Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 10:57:13 -0000 --Apple-Mail=_D220F32F-98DF-4C16-B57C-9023A8880326 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 If you are not interested in MANET, why not unsubscribe? Teco Op 10 apr. 2012, om 12:39 heeft Pars Mutaf het volgende geschreven: >=20 >=20 > On Tue, Apr 10, 2012 at 1:29 PM, wrote: > Hi Pars and Henning, >=20 > one IST project called MONET (http://monet.tekever.com/) is innovative = to investigate the possibility > of using MANET in disaster relief communication scenarios. and the = network architecture > uses the satellite, high-attitude platform(plane, balloon) as a bridge = or relay for disconnected > areas of MANET for disaster scenarios. >=20 > for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, = recent years 10MB > bandwidth satellite links are also available on the martket (in uk). = regarding delay, satellite > may introduce the round trip delay however, does it really impact the = VoIP or video communications? > it is relied on the quality of service if you get down the streaming = bandwidth. satellite > is a perfect solution to relay MANET traffics. at least it is better = than nothing. >=20 > Hi Dan,=20 >=20 > Why use MANET? >=20 > Balloon+Satellite is enough. >=20 > I understand if people wish to work on it as an exercise but there is = no utility. Is there any? >=20 > Pars >=20 >=20 > Cheers, >=20 > Dan >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Centre of Communication Systems Research > University of Surrey > Guildford > GU2 7XH > UK > Tel:+44-1483-68-6016 > fax:+44-1483-68-6011(attn: Dan He) > ________________________________________ > From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of = Pars Mutaf [pars.mutaf@gmail.com] > Sent: 10 April 2012 10:49 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] Replacing MANET with a simple solution >=20 > 1. This solution can be developed. It is clearly better. Nodes = forwarding others' packets doesn't seem realistic. > 2. I don't know how limited the satellite connection bandwdith. I am = not sure if high bandwidth is the real problem in the disaster scenario = where people are dying. > 3. Why not question MANET and accept it as if it were the absolute = truth. What if everybody is dead, or I am the only one with cell phone? >=20 > On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge = = > wrote: > On 04/10/2012 09:47 AM, Pars Mutaf wrote: > More precisely, >=20 > Just use a balloon at the same height as the previous base station and > satellite... > Satellite connections are bandwidth limited (especially with compact = ground stations), expensive and have a high delay. >=20 >=20 > The same phones can be used. > If you have a copy of the database of the cellphone providers. >=20 >=20 > The balloon will make the interface to the satellite. > This would make it impossible to use directional antennas towards the = satellite, which will decrease your bandwidth even more. >=20 >=20 > To solve the wind problem (not sure if it is that important) we can = use 3 > cables to attach the balloon to the ground. > Even with multiple cables the stability of a balloon depends on = distance between the cable attachment on the ground compared to wind = speed. >=20 >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 = 9435 685 > = mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_D220F32F-98DF-4C16-B57C-9023A8880326 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 If = you are not interested in MANET, why not = unsubscribe?
Teco

Op 10 apr. 2012, om 12:39 = heeft Pars Mutaf het volgende geschreven:



On Tue, Apr 10, 2012 at 1:29 PM, <D.He@surrey.ac.uk> = wrote:
Hi Pars and Henning,

one IST project called MONET (http://monet.tekever.com/) is innovative to = investigate the possibility
of using MANET in disaster relief communication scenarios. and the = network architecture
uses the satellite, high-attitude platform(plane, balloon) as a bridge = or relay for disconnected
areas of MANET for disaster scenarios.

for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, = recent years 10MB
bandwidth satellite links are also available on the martket (in uk). = regarding delay, satellite
may introduce the round trip delay however, does it really impact the = VoIP or video communications?
it is relied on the quality of service if you get down the streaming = bandwidth. satellite
is a perfect solution to relay MANET traffics. at least it is better = than nothing.

Hi = Dan, 

Why use = MANET?

Balloon+Satellite is enough.

I understand if people wish to work on it as an = exercise but there is no utility. Is there = any?

Pars


Cheers,

Dan




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dan He
Centre of Communication Systems Research
University of Surrey
Guildford
GU2 7XH
UK
Tel:+44-1483-68-6016
fax:+44-1483-68-6011(attn: Dan He)
________________________________________
From: manet-bounces@ietf.org= [manet-bounces@ietf.org] = On Behalf Of Pars Mutaf [pars.mutaf@gmail.com]
Sent: 10 April 2012 10:49
To: Henning Rogge
Cc: manet@ietf.org
Subject: Re: [manet] Replacing MANET with a simple = solution

1. This solution can be developed. It is clearly = better. Nodes forwarding others' packets doesn't seem realistic.
2. I don't know how limited the satellite connection bandwdith. I am not = sure if high bandwidth is the real problem in the disaster scenario = where people are dying.
3. Why not question MANET and accept it as if it were the absolute = truth. What if everybody is dead, or I am the only one with cell = phone?

On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge = <henning.rogge@fkie.fraunh= ofer.de<mailto:henning.rogge@fkie.fraunh= ofer.de>> wrote:
On 04/10/2012 09:47 AM, Pars Mutaf wrote:
More precisely,

Just use a balloon at the same height as the previous base station = and
satellite...
Satellite connections are bandwidth limited (especially with compact = ground stations), expensive and have a high delay.


The same phones can be used.
If you have a copy of the database of the cellphone providers.


The balloon will make the interface to the satellite.
This would make it impossible to use directional antennas towards the = satellite, which will decrease your bandwidth even more.


To solve the wind problem (not sure if it is that important) we can use = 3
cables to attach the balloon to the ground.
Even with multiple cables the stability of a balloon depends on distance = between the cable attachment on the ground compared to wind speed.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 = 9435-961<tel:%2B49%20228%209435-961>,   Fax +49 228 = 9435 685<tel:%2B49%20228%209435%20685>
mailto:henning.rogge@fkie.fraunh= ofer.de<mailto:henning.rogge@fkie.fraunh= ofer.de> http://www.fkie.fraunhofer.de

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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



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

= --Apple-Mail=_D220F32F-98DF-4C16-B57C-9023A8880326-- From D.He@surrey.ac.uk Tue Apr 10 04:02:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1911E809D for ; Tue, 10 Apr 2012 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgi+Q1H-NZEs for ; Tue, 10 Apr 2012 04:02:57 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id AC5CF11E8072 for ; Tue, 10 Apr 2012 04:02:56 -0700 (PDT) Received: from [195.245.230.131:33287] by server-9.bemta-3.messagelabs.com id 65/19-10923-F53148F4; Tue, 10 Apr 2012 11:02:55 +0000 X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-16.tower-78.messagelabs.com!1334055775!25025186!1 X-Originating-IP: [131.227.200.43] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30820 invoked from network); 10 Apr 2012 11:02:55 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-16.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 10 Apr 2012 11:02:55 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.208]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Tue, 10 Apr 2012 12:02:54 +0100 From: To: Date: Tue, 10 Apr 2012 11:58:43 +0100 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0XBjjBwq+TjDHhSsq9narWkoy69wAAqx8q Message-ID: References: <4F83EBB0.7000704@fkie.fraunhofer.de> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org, andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:02:57 -0000 Hi Pars, there is no simple solution to use balloon+satellite because 1) link quality is not stable for combination of balloon+satellite. 2) expensive cost.=20 in the ground communication (except from long distance division), MANET is= =20 good enough for a group communications. if every connection goes up to sate= llite(balloon) and down to another peer, this is too expensive, and too large latency. I a= m sure your sat-phone will use up your battery just for few minutes communications= . Cheers, Dan=20 >Hi Dan, >Why use MANET? >Balloon+Satellite is enough. >I understand if people wish to work on it as an exercise but there is no u= tility. Is there any? >Pars _______________________________________________ manet mailing list manet@ietf.org> https://www.ietf.org/mailman/listinfo/manet From pars.mutaf@gmail.com Tue Apr 10 04:42:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9C221F848F for ; Tue, 10 Apr 2012 04:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7oVo0baYy7S for ; Tue, 10 Apr 2012 04:42:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBBBA21F848C for ; Tue, 10 Apr 2012 04:42:54 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8093932obb.31 for ; Tue, 10 Apr 2012 04:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AoelMl0Z3FZFLb/4183neWMF6BMdi3RWBXb1W33xRyQ=; b=B7839CXxbqp8X3ZUxpWTIGQQM9Tb/X8YvWr6AhRi99AXZbO82OTfiCBrI/t5bv/cbf V4sH3qFdkETRSFOXDUSp29JtMyVVG833ZTUd+gH2koHXzjh9Lp2I62W8UM0aqLbm78Iu XMfWvKpVc1poQhRWArJnndEgvrgyJTNlKagcfAf3l1Y+Uz1J8MfW8F6PXHU7yz19g3oQ bTQAFHJgTPkQmmKd5eYnxFgHKxsEqHgyjCF4lfBSUuSOrAI5X0vENvhbYg8Mh40QP2N5 3E3f8NrFa6pAEvwXXwR2UFiSvzz9cG6GALbf5aOJdtQErbtYeEAXlLXAvQ1vF3Z12sA7 Yr0w== MIME-Version: 1.0 Received: by 10.182.174.101 with SMTP id br5mr15795516obc.0.1334058174331; Tue, 10 Apr 2012 04:42:54 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 04:42:54 -0700 (PDT) In-Reply-To: <57C7B9F2-7201-4556-9DD3-5C3DCA727D55@inf-net.nl> References: <4F83EBB0.7000704@fkie.fraunhofer.de> <57C7B9F2-7201-4556-9DD3-5C3DCA727D55@inf-net.nl> Date: Tue, 10 Apr 2012 14:42:54 +0300 Message-ID: From: Pars Mutaf To: Teco Boot Content-Type: multipart/alternative; boundary=e89a8f64672997398404bd519f3d Cc: manet@ietf.org, andre.oliveira@tekever.com, D.He@surrey.ac.uk Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:42:56 -0000 --e89a8f64672997398404bd519f3d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am here to question. Not judge. On Tue, Apr 10, 2012 at 1:57 PM, Teco Boot wrote: > If you are not interested in MANET, why not unsubscribe? > Teco > > Op 10 apr. 2012, om 12:39 heeft Pars Mutaf het volgende geschreven: > > > > On Tue, Apr 10, 2012 at 1:29 PM, wrote: > >> Hi Pars and Henning, >> >> one IST project called MONET (http://monet.tekever.com/) is innovative >> to investigate the possibility >> of using MANET in disaster relief communication scenarios. and the >> network architecture >> uses the satellite, high-attitude platform(plane, balloon) as a bridge o= r >> relay for disconnected >> areas of MANET for disaster scenarios. >> >> for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, >> recent years 10MB >> bandwidth satellite links are also available on the martket (in uk). >> regarding delay, satellite >> may introduce the round trip delay however, does it really impact the >> VoIP or video communications? >> it is relied on the quality of service if you get down the streaming >> bandwidth. satellite >> is a perfect solution to relay MANET traffics. at least it is better tha= n >> nothing. >> > > Hi Dan, > > Why use MANET? > > Balloon+Satellite is enough. > > I understand if people wish to work on it as an exercise but there is no > utility. Is there any? > > Pars > > >> Cheers, >> >> Dan >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Dan He >> Centre of Communication Systems Research >> University of Surrey >> Guildford >> GU2 7XH >> UK >> Tel:+44-1483-68-6016 >> fax:+44-1483-68-6011(attn: Dan He) >> ________________________________________ >> From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Pars >> Mutaf [pars.mutaf@gmail.com] >> Sent: 10 April 2012 10:49 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] Replacing MANET with a simple solution >> >> 1. This solution can be developed. It is clearly better. Nodes forwardin= g >> others' packets doesn't seem realistic. >> 2. I don't know how limited the satellite connection bandwdith. I am not >> sure if high bandwidth is the real problem in the disaster scenario wher= e >> people are dying. >> 3. Why not question MANET and accept it as if it were the absolute truth= . >> What if everybody is dead, or I am the only one with cell phone? >> >> On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge < >> henning.rogge@fkie.fraunhofer.de> >> wrote: >> On 04/10/2012 09:47 AM, Pars Mutaf wrote: >> More precisely, >> >> Just use a balloon at the same height as the previous base station and >> satellite... >> Satellite connections are bandwidth limited (especially with compact >> ground stations), expensive and have a high delay. >> >> >> The same phones can be used. >> If you have a copy of the database of the cellphone providers. >> >> >> The balloon will make the interface to the satellite. >> This would make it impossible to use directional antennas towards the >> satellite, which will decrease your bandwidth even more. >> >> >> To solve the wind problem (not sure if it is that important) we can use = 3 >> cables to attach the balloon to the ground. >> Even with multiple cables the stability of a balloon depends on distance >> between the cable attachment on the ground compared to wind speed. >> >> >> Henning Rogge >> >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 >> 685 >> mailto:henning.rogge@fkie.fraunhofer.de> henning.rogge@fkie.fraunhofer.de> http://www.fkie.fraunhofer.de >> >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --e89a8f64672997398404bd519f3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am here to question. Not judge.=A0

On T= ue, Apr 10, 2012 at 1:57 PM, Teco Boot <teco@inf-net.nl> wrote:
If you are not interested in MANET, why= not unsubscribe?
Teco

Op 10 apr. 2012, om 12:3= 9 heeft Pars Mutaf het volgende geschreven:



On Tue, Apr 10, 2= 012 at 1:29 PM, <D.He@surrey.ac.uk> wrote:
Hi Pars and Henning,

one IST project called MONET (http://monet.tekever.com/) is innovative to investigate the= possibility
of using MANET in disaster relief communication scenarios. and the network = architecture
uses the satellite, high-attitude platform(plane, balloon) as a bridge or r= elay for disconnected
areas of MANET for disaster scenarios.

for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, rece= nt years 10MB
bandwidth satellite links are also available on the martket (in uk). regard= ing delay, satellite
may introduce the round trip delay however, does it really impact the VoIP = or video communications?
it is relied on the quality of service if you get down the streaming bandwi= dth. satellite
is a perfect solution to relay MANET traffics. at least it is better than n= othing.

Hi Dan,=A0

=
Why use MANET?

Balloon+Satellite is enough.

I understand if people wish to work on it as an exercis= e but there is no utility. Is there any?

Pars


Cheers,

Dan




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dan He
Centre of Communication Systems Research
University of Surrey
Guildford
GU2 7XH
UK
Tel:+44-1483-68-6016
fax:+44-1483-68-6011(attn: Dan He)
________________________________________
From: manet-bou= nces@ietf.org [manet-bounces@ietf.org] On Behalf Of Pars Mutaf [pars.mutaf@gmail.com]
Sent: 10 April 2012 10:49
To: Henning Rogge
Cc: manet@ietf.org<= br>
Subject: Re: [manet] Replacing MANET with a simple solution

1. This solution can be developed. It is clearly better. Nodes f= orwarding others' packets doesn't seem realistic.
2. I don't know how limited the satellite connection bandwdith. I am no= t sure if high bandwidth is the real problem in the disaster scenario where= people are dying.
3. Why not question MANET and accept it as if it were the absolute truth. W= hat if everybody is dead, or I am the only one with cell phone?

On Tue, Apr 10, 2012 at 11:13 AM, Henning Rogge <henning.rogge@fki= e.fraunhofer.de<mailto:henning.rogge@fkie.fraunhofer.de>> wrote= :
On 04/10/2012 09:47 AM, Pars Mutaf wrote:
More precisely,

Just use a balloon at the same height as the previous base station and
satellite...
Satellite connections are bandwidth limited (especially with compact ground= stations), expensive and have a high delay.


The same phones can be used.
If you have a copy of the database of the cellphone providers.


The balloon will make the interface to the satellite.
This would make it impossible to use directional antennas towards the satel= lite, which will decrease your bandwidth even more.


To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground.
Even with multiple cables the stability of a balloon depends on distance be= tween the cable attachment on the ground compared to wind speed.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961<tel:%2B49%20228%209435-961>,= =A0 Fax +49 228 9435 685<tel:%2B49%20228%209435%20685> mailto:henning.rogge@fkie.fraunhofer.de<mailto:henning.rogge@fkie.fraunhofer.d= e> http= ://www.fkie.fraunhofer.de

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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



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


--e89a8f64672997398404bd519f3d-- From marshall.eubanks@gmail.com Tue Apr 10 04:50:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76C521F8570 for ; Tue, 10 Apr 2012 04:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5WJP1HR4zBm for ; Tue, 10 Apr 2012 04:50:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3CC21F855F for ; Tue, 10 Apr 2012 04:50:13 -0700 (PDT) Received: by lagj5 with SMTP id j5so2979627lag.31 for ; Tue, 10 Apr 2012 04:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NWyt6aDqwSiARtdR2pj0Z13oLg7KuIEGeFaGDqLlrco=; b=iHl4DpraWkPVfzpEPxzv20vWyXfH/aFQm/JAnRSlVHCKDFtwxL/Sg1lGfJjr5mTYRq w2mvW6NwvfzayKTBr2T9VT4VWdhAW5JYXrS/bIAJNZqfCVvsVQYW2HXPRnXAnr4AkHil lgguLRPUn/RwMK9YGN9cjHOuBjkbyoQPOoQMgB3f6gACvt178UpSlEcYDhB7RR5tzfas ZLHISuFSgm/Ms0sQZfYhRZyQFUp3bUrsWpWf0NmR+IA3p0QPiJhvm7ovI1eiWOwCH41Q yfCFTOBms/PIPk+/3tMUdPt8+rvZ4ScSdGw+koDKkkxQevby6LNNqtmnIXKYXJtAlE5O 4fGQ== MIME-Version: 1.0 Received: by 10.152.104.80 with SMTP id gc16mr14586825lab.46.1334058612190; Tue, 10 Apr 2012 04:50:12 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Tue, 10 Apr 2012 04:50:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 07:50:12 -0400 Message-ID: From: Marshall Eubanks To: Pars Mutaf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:50:16 -0000 On Tue, Apr 10, 2012 at 1:25 AM, Pars Mutaf wrote: > In a disaster scenario, the base stations are down, everything is broken. > > Just find a big balloon, attach the antennas to it, send it to the air wi= th > an=A0electric=A0cable connected to a power generator on the ground. > > You have a base station in 1 hour. > > Why spend=A0millions=A0of dollars/euros for this MANET effort? Because you might need more than one balloon. Regards Marshall > > Pars Mutaf > Asst. Prof. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From pars.mutaf@gmail.com Tue Apr 10 04:50:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172F21F857F for ; Tue, 10 Apr 2012 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CrQ0ZjKJm5X for ; Tue, 10 Apr 2012 04:50:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15F21F857D for ; Tue, 10 Apr 2012 04:50:45 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8104214obb.31 for ; Tue, 10 Apr 2012 04:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WvomEIj/f9XWpOqCM0EkILpef0NvZP/kEUREE3dariI=; b=sphpYIFDzqgI7ku/Yy/1Sthjf78Uu+6/zQf49SishgZJLIihLWmDwR5mHsMsx6TAKA Cbc8Dv/06MskdasQf3dbFQq0v6XlWnBL+7pSiv8VPpLKiQCzDRz3L5DlEm2rSGutMY43 1RKohzoR8z/S2V7TmJ1dBvgrwR2jKiOVyz2HuhsnV302e36O26XwfpGNm2aXY3VJ8Cm/ Xww9tUIYa4xrVp8A184vLt2p/HU0xypqTB/7TGFCgjIicbPy9N7wlTgaePz2zohBt8FZ LhJczjhj8zq0ZktRh8D3KS+FdmYbB4ZeFZiFb3y7S9/OlzMcHzYRkIW+yVxa9VszibRa GNCA== MIME-Version: 1.0 Received: by 10.60.27.38 with SMTP id q6mr16143470oeg.20.1334058645274; Tue, 10 Apr 2012 04:50:45 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 04:50:45 -0700 (PDT) In-Reply-To: References: <4F83EBB0.7000704@fkie.fraunhofer.de> Date: Tue, 10 Apr 2012 14:50:45 +0300 Message-ID: From: Pars Mutaf To: D.He@surrey.ac.uk Content-Type: multipart/alternative; boundary=e89a8ff1c634a941d304bd51bb98 Cc: manet@ietf.org, andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:50:46 -0000 --e89a8ff1c634a941d304bd51bb98 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 1:58 PM, wrote: > Hi Pars, > > there is no simple solution to use balloon+satellite because > 1) link quality is not stable for combination of balloon+satellite. > > I don't understand. > 2) expensive cost. > in the ground communication (except from long distance division), MANET is > good enough for a group communications. if every connection goes up to > satellite(balloon) > and down to another peer, this is too expensive, and too large latency. I > am sure > your sat-phone will use up your battery just for few minutes > communications. > > For a group communication, the balloon can handle it, we do not need the satellite. For long distance, the balloon will forward traffic to the satellite. It is not a sat-phone.. You talk to the balloon which forwards traffic to the satellite. You use your standard cell phone. MANET is not a solution. There is a great risk of partitioned network. In a disaster scenario we don't want to take risks. MANET just makes no sense to me. It may not work *at all* for many people in a disaster scenario. > Cheers, > Dan > > >Hi Dan, > > >Why use MANET? > > >Balloon+Satellite is enough. > > >I understand if people wish to work on it as an exercise but there is no > utility. Is there any? > > >Pars > > > _______________________________________________ > manet mailing list > manet@ietf.org manet@ietf.org>> > https://www.ietf.org/mailman/listinfo/manet > > > > --e89a8ff1c634a941d304bd51bb98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 1:58 PM, <D.He@surrey.ac.uk&= gt; wrote:
Hi Pars,

there is no simple solution to use balloon+satellite because
1) link quality is not stable for combination of balloon+satellite.


I don't understand.=A0
= =A0
2) expensive cost.
in the ground communication (except from long distance division), MANET is<= br> good enough for a group communications. if every connection goes up to sate= llite(balloon)
and down to another peer, this is too expensive, and too large latency. I a= m sure
your sat-phone will use up your battery just for few minutes communications= .


For a group communication, the balloon= can handle it, we do not need the satellite.=A0

F= or long distance, the balloon will forward traffic to the satellite.=A0

It is not a sat-phone.. You talk to the balloon which f= orwards traffic to the satellite. You use your standard
cell phon= e.=A0

MANET is not a solution. There is a great ri= sk of partitioned network. In a disaster scenario
we don't want to take risks. MANET just makes no sense to me. It m= ay not work *at all* for many people
in a disaster scenario.

=A0
Cheers,
Dan

>Hi Dan,

>Why use MANET?

>Balloon+Satellite is enough.

>I understand if people wish to work on it as an exercise but there is n= o utility. Is there any?

>Pars


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




--e89a8ff1c634a941d304bd51bb98-- From jomullen@ad.nmsu.edu Tue Apr 10 05:24:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B8B21F854D for ; Tue, 10 Apr 2012 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnxeHXDIvm33 for ; Tue, 10 Apr 2012 05:24:52 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-02.nmsu.edu [128.123.34.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1674421F854C for ; Tue, 10 Apr 2012 05:24:51 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-02.ACN.ad.nmsu.edu ([128.123.34.236]) with mapi; Tue, 10 Apr 2012 06:24:47 -0600 From: Dr John P Mullen To: Pars Mutaf , "D.He@surrey.ac.uk" Date: Tue, 10 Apr 2012 06:24:46 -0600 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0XECwagzuOOxrpThOEYZg1AW0F/QABL6j1 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F9A5F0DF0BBF2547A0E94FC12263712E84260DFEF9EXCHANGEMBX01_" MIME-Version: 1.0 Cc: "manet@ietf.org" , "andre.oliveira@tekever.com" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:24:52 -0000 --_000_F9A5F0DF0BBF2547A0E94FC12263712E84260DFEF9EXCHANGEMBX01_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What you are proposing is an alternate solution to a communication problem,= which may work in some situations, but not all. For example, if the weather is nasty enough, it could blow the balloon away= , in the case of fighting forest fires, the balloon might burn up, in the c= ase of military action, the enemy might destroy the balloon, etc. Additionally, you would need a lot of baloons in an urban setting, mountain= ous area, or large geographic area. So, your idea might work in some cases, but for the others, we would still = need manets. John Mullen ________________________________ From: Pars Mutaf Sent: Tuesday, April 10, 2012 5:50 AM To: D.He@surrey.ac.uk Cc: manet@ietf.org ; andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution On Tue, Apr 10, 2012 at 1:58 PM, > wrote: Hi Pars, there is no simple solution to use balloon+satellite because 1) link quality is not stable for combination of balloon+satellite. I don't understand. 2) expensive cost. in the ground communication (except from long distance division), MANET is good enough for a group communications. if every connection goes up to sate= llite(balloon) and down to another peer, this is too expensive, and too large latency. I a= m sure your sat-phone will use up your battery just for few minutes communications= . For a group communication, the balloon can handle it, we do not need the sa= tellite. For long distance, the balloon will forward traffic to the satellite. It is not a sat-phone.. You talk to the balloon which forwards traffic to t= he satellite. You use your standard cell phone. MANET is not a solution. There is a great risk of partitioned network. In a= disaster scenario we don't want to take risks. MANET just makes no sense to me. It may not wo= rk *at all* for many people in a disaster scenario. Cheers, Dan >Hi Dan, >Why use MANET? >Balloon+Satellite is enough. >I understand if people wish to work on it as an exercise but there is no u= tility. Is there any? >Pars _______________________________________________ manet mailing list manet@ietf.org>>> https://www.ietf.org/mailman/listinfo/manet --_000_F9A5F0DF0BBF2547A0E94FC12263712E84260DFEF9EXCHANGEMBX01_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wh= at you are proposing is an alternate solution to a communication problem, w= hich may work in some situations, but not all.

For example, if the weather is nasty enough, it could blow the balloon away= , in the case of fighting forest fires, the balloon might burn up, in the c= ase of military action, the enemy might destroy the balloon, etc.

Additionally, you would need a lot of baloons in an urban setting, mountain= ous area, or large geographic area.

So, your idea might work in some cases, but for the others, we would still = need manets.

John Mullen

From: <= /span>Sent: <= /span>To: = D.He@surrey.ac.uk <D.He@surrey.ac.uk>
Cc: = manet@ietf.org <manet@ietf.org>; andre.oliveira@tekever.com <andre= .oliveira@tekever.com>
Subject= : Re: = [manet] Replacing MANET with a simple solution


On Tue, Apr 10, 2012 at 1:58 PM, <D.He@surrey.ac.uk> wrote:
Hi Pars,

there is no simple solution to use balloon+satellite because
1) link quality is not stable for combination of balloon+satellite.


I don't understand. 
 
2) expensive cost.
in the ground communication (except from long distance division), MANET is<= br> good enough for a group communications. if every connection goes up to sate= llite(balloon)
and down to another peer, this is too expensive, and too large latency. I a= m sure
your sat-phone will use up your battery just for few minutes communications= .


For a group communication, the balloon can handle it, we do not need t= he satellite. 

For long distance, the balloon will forward traffic to the satellite.&= nbsp;

It is not a sat-phone.. You talk to the balloon which forwards traffic= to the satellite. You use your standard
cell phone. 

MANET is not a solution. There is a great risk of partitioned network.= In a disaster scenario
we don't want to take risks. MANET just makes no sense to me. It may n= ot work *at all* for many people
in a disaster scenario.

 
Cheers,
Dan

>Hi Dan,

>Why use MANET?

>Balloon+Satellite is enough.

>I understand if people wish to work on it as an exercise but there is n= o utility. Is there any?

>Pars


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




--_000_F9A5F0DF0BBF2547A0E94FC12263712E84260DFEF9EXCHANGEMBX01_-- From william.d.ivancic@nasa.gov Tue Apr 10 05:54:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AA821F848B for ; Tue, 10 Apr 2012 05:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQytpaAmOcqB for ; Tue, 10 Apr 2012 05:54:00 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 053FE21F85D5 for ; Tue, 10 Apr 2012 05:54:00 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 47E492D839C; Tue, 10 Apr 2012 07:53:59 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3ACrxsV018162; Tue, 10 Apr 2012 07:53:59 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Tue, 10 Apr 2012 07:53:58 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Pars Mutaf Date: Tue, 10 Apr 2012 07:53:56 -0500 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0XGP6KB/96dbv8Qn2TrOf+amqE6A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AA2912D807564581B36A113DDBB8452Enasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-10_01:2012-04-10, 2012-04-09, 1970-01-01 signatures=0 Cc: "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:54:01 -0000 --_000_AA2912D807564581B36A113DDBB8452Enasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Easier said than done. Believe me. - Will On Apr 10, 2012, at 3:47 AM, Pars Mutaf wrote: More precisely, Just use a balloon at the same height as the previous base station and sate= llite... The same phones can be used. The balloon will make the interface to the sat= ellite. To solve the wind problem (not sure if it is that important) we can use 3 c= ables to attach the balloon to the ground. On Tue, Apr 10, 2012 at 8:25 AM, Pars Mutaf > wrote: In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with= an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_AA2912D807564581B36A113DDBB8452Enasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Easier said than done. &nb= sp;Believe me.

- Will
On Apr 10, 2012, at 3= :47 AM, Pars Mutaf wrote:

More precisely,

Just use a balloon at the sam= e height as the previous base station and satellite...

The same pho= nes can be used. The balloon will make the interface to the satellite.
=
To solve the wind problem (not sure if it is that important) we can use= 3 cables to attach the balloon to the ground.



On Tue, Apr 10, 2012 at 8:25 AM, Par= s Mutaf <pars.= mutaf@gmail.com> wrote:
In a disaster scenario, the base stations are down, everything is broken.&n= bsp;

Just find a big balloon, attach the antennas to it,= send it to the air with an electric cable connected to a power g= enerator on the ground. 

You have a base station in 1 hour.

=
Why spend millions of dollars/euros for this MANET effort?

Pars= Mutaf
Asst. Prof.

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

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne= tworking Lab 216-433-2620
Mobile = 440-503-4892
http://roland.grc.nasa.gov/~ivancic

= --_000_AA2912D807564581B36A113DDBB8452Enasagov_-- From pars.mutaf@gmail.com Tue Apr 10 06:00:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B021F8548 for ; Tue, 10 Apr 2012 06:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJB7PxuPbBlh for ; Tue, 10 Apr 2012 06:00:41 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1427921F852E for ; Tue, 10 Apr 2012 06:00:40 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2552236ghb.31 for ; Tue, 10 Apr 2012 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hGms+Sw3HkEDfdKgbKem4UJDYfcxdWzqm7aDFU8qe80=; b=0LHR/2nZXsel8eXkkTN02sFA2qpDIuMFOjKcthz0hzNq45fNWqHnreuz2dqFhR/WT9 jzOwsKXA3LBNyvPZOnJJetsUX90AsfX/8KRi3/9Y77PwcI7oB1+rTJeyq9vBKgLElJai wD4n34JBq14cAbRZvAudTSSykigGI9AIoYJGCr6WzEWbBwGjNpsjx8l7jQpvZm3Kps/q CuiQY0P5CK1+uCKc4ZIyDGnGUl7ZfZugu0TA3FCrdCrkZ3NWQb/3xHHRywztx73pHJuf FyGpYuoc3fLnTAMiRI1adkyd461KTIp0XajsHipSZcPdCFOtvSFJ+LvbftSKrI+q/ETA DGqQ== MIME-Version: 1.0 Received: by 10.60.27.38 with SMTP id q6mr16520145oeg.20.1334062834222; Tue, 10 Apr 2012 06:00:34 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 06:00:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 16:00:34 +0300 Message-ID: From: Pars Mutaf To: Dr John P Mullen Content-Type: multipart/alternative; boundary=e89a8ff1c63457859b04bd52b515 Cc: "manet@ietf.org" , "andre.oliveira@tekever.com" , "D.He@surrey.ac.uk" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:00:42 -0000 --e89a8ff1c63457859b04bd52b515 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 3:24 PM, Dr John P Mullen wrote: > What you are proposing is an alternate solution to a communication > problem, which may work in some situations, but not all. > > For example, if the weather is nasty enough, it could blow the balloon > away, in the case of fighting forest fires, the balloon might burn up, in > the case of military action, the enemy might destroy the balloon, etc. > > Additionally, you would need a lot of baloons in an urban setting, > mountainous area, or large geographic area. > > I don't understand this. In MANET you need ***thousands(?)*** of nodes forming a contiguous network. Why not rather question this? A number of balloons can cover the disaster area. > So, your idea might work in some cases, but for the others, we would still > need manets. > > I don't understand why it is needed. I don't understand how it could work. Pars > John Mullen > > ------------------------------ > From: Pars Mutaf > Sent: Tuesday, April 10, 2012 5:50 AM > To: D.He@surrey.ac.uk > Cc: manet@ietf.org ; andre.oliveira@tekever.com < > andre.oliveira@tekever.com> > > Subject: Re: [manet] Replacing MANET with a simple solution > > > > On Tue, Apr 10, 2012 at 1:58 PM, wrote: > >> Hi Pars, >> >> there is no simple solution to use balloon+satellite because >> 1) link quality is not stable for combination of balloon+satellite. >> >> > I don't understand. > > >> 2) expensive cost. >> in the ground communication (except from long distance division), MANET is >> good enough for a group communications. if every connection goes up to >> satellite(balloon) >> and down to another peer, this is too expensive, and too large latency. I >> am sure >> your sat-phone will use up your battery just for few minutes >> communications. >> >> > For a group communication, the balloon can handle it, we do not need the > satellite. > > For long distance, the balloon will forward traffic to the satellite. > > It is not a sat-phone.. You talk to the balloon which forwards traffic > to the satellite. You use your standard > cell phone. > > MANET is not a solution. There is a great risk of partitioned network. > In a disaster scenario > we don't want to take risks. MANET just makes no sense to me. It may not > work *at all* for many people > in a disaster scenario. > > > >> Cheers, >> Dan >> >> >Hi Dan, >> >> >Why use MANET? >> >> >Balloon+Satellite is enough. >> >> >I understand if people wish to work on it as an exercise but there is no >> utility. Is there any? >> >> >Pars >> >> >> _______________________________________________ >> manet mailing list >> >> manet@ietf.org> manet@ietf.org>> >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> > --e89a8ff1c63457859b04bd52b515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 3:24 PM, Dr John= P Mullen <jom= ullen@ad.nmsu.edu> wrote:
What yo= u are proposing is an alternate solution to a communication problem, which = may work in some situations, but not all.

For example, if the weather is nasty enough, it could blow the balloon away= , in the case of fighting forest fires, the balloon might burn up, in the c= ase of military action, the enemy might destroy the balloon, etc.

Additionally, you would need a lot of baloons in an urban setting, mountain= ous area, or large geographic area.


I don't understand th= is. In MANET you need ***thousands(?)*** of nodes forming a contiguous netw= ork. Why not rather question this?=A0

A number of = balloons can cover the disaster area.=A0

=A0
So, your idea might work in some cases, but for the others, we would still = need manets.


I don't understand wh= y it is needed.
I don't understand how it could work.=A0

Pars
=A0
John Mullen

From: P= ars Mutaf <par= s.mutaf@gmail.com>
Sent: T= uesday, April 10, 2012 5:50 AM
To: D.He@surrey.ac.uk &= lt;D.He@surrey.ac.uk= >
Cc: manet@ietf.org <manet@ietf.org>; andre.oliveir= a@tekever.com <andre.oliveira@tekever.com>

Subject:= Re: [m= anet] Replacing MANET with a simple solution


On Tue, Apr 10, 2012 at 1:58 P= M, <D.He@surrey.ac.uk> wrote:
Hi Pars,

there is no simple solution to use balloon+satellite because
1) link quality is not stable for combination of balloon+satellite.


I don't understand.=A0
=A0
2) expensive cost.
in the ground communication (except from long distance division), MANET is<= br> good enough for a group communications. if every connection goes up to sate= llite(balloon)
and down to another peer, this is too expensive, and too large latency. I a= m sure
your sat-phone will use up your battery just for few minutes communications= .


For a group communication, the balloon can handle it, we do not need t= he satellite.=A0

For long distance, the balloon will forward traffic to the satellite.= =A0

It is not a sat-phone.. You talk to the balloon which forwards traffic= to the satellite. You use your standard
cell phone.=A0

MANET is not a solution. There is a great risk of partitioned network.= In a disaster scenario
we don't want to take risks. MANET just makes no sense to me. It m= ay not work *at all* for many people
in a disaster scenario.

=A0
Cheers,
Dan

>Hi Dan,

>Why use MANET?

>Balloon+Satellite is enough.

>I understand if people wish to work on it as an exercise but there is n= o utility. Is there any?

>Pars


_______________________________________________
manet mailing list

manet@ietf.org<m= ailto:manet@ietf.org><mailto:manet@i= etf.org<mailto:m= anet@ietf.org>>
h= ttps://www.ietf.org/mailman/listinfo/manet





--e89a8ff1c63457859b04bd52b515-- From william.d.ivancic@nasa.gov Tue Apr 10 06:00:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2DF21F852E for ; Tue, 10 Apr 2012 06:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5mQoxPqNlIb for ; Tue, 10 Apr 2012 06:00:42 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65F21F8541 for ; Tue, 10 Apr 2012 06:00:42 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 56395108527; Tue, 10 Apr 2012 08:00:41 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3AD0fEL005803; Tue, 10 Apr 2012 08:00:41 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 10 Apr 2012 08:00:40 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Pars Mutaf Date: Tue, 10 Apr 2012 08:00:39 -0500 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0XGe5D4TGWxHNgSBGvFHcdZFf12g== Message-ID: <751BFD3F-22CB-44B2-A79F-AC53681DDF61@nasa.gov> References: <4F83EBB0.7000704@fkie.fraunhofer.de> <57C7B9F2-7201-4556-9DD3-5C3DCA727D55@inf-net.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_751BFD3F22CB44B2A79FAC53681DDF61nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-10_01:2012-04-10, 2012-04-09, 1970-01-01 signatures=0 Cc: "manet@ietf.org" , "andre.oliveira@tekever.com" , "D.He@surrey.ac.uk" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:00:43 -0000 --_000_751BFD3F22CB44B2A79FAC53681DDF61nasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable manet protocols are a tool like any other. It is appropriate in some cases= and not in others. Same goes for DTN which is sort of super manet. - Will On Apr 10, 2012, at 7:42 AM, Pars Mutaf wrote: I am here to question. Not judge. On Tue, Apr 10, 2012 at 1:57 PM, Teco Boot > wrote: --_000_751BFD3F22CB44B2A79FAC53681DDF61nasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable manet protocols are a tool= like any other.  It is appropriate in some cases and not in others. &= nbsp;Same goes for DTN which is sort of super manet.

- W= ill
On Apr 10, 2012, at 7:42 AM, Pars Mutaf wrote:

I am here to qu= estion. Not judge. 

On Tue, Apr 10, = 2012 at 1:57 PM, Teco Boot <teco@inf-net.nl> wrote:
=
=

= --_000_751BFD3F22CB44B2A79FAC53681DDF61nasagov_-- From pars.mutaf@gmail.com Tue Apr 10 06:02:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18221F860D for ; Tue, 10 Apr 2012 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjG8sALIGitB for ; Tue, 10 Apr 2012 06:02:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5B221F8608 for ; Tue, 10 Apr 2012 06:02:54 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2549587ggm.31 for ; Tue, 10 Apr 2012 06:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GS26irPbHJY9gxGac5a/vwaI/F1WVK6202mtcukLkC8=; b=b00tXcDzK8LjeE42ZnQnMYg9rcn4++AAaQMcHxFzYzRaagvHzdVgMWgFt/Ae1/FEqF Pzpur+T882QgmwJzvP+S9jz1Y8BpeLKsdQCo1lmwa8wrG8Xo3BQDP/hlt/I2lHElR+O+ vkL62RY8OgHfgx/RuUzsUsJXCZBmDLQBGjWieWUAqj/9OJTXnpZCqkoPXzVCXlfjTurg u+BvsQg1LVuIRP/63trYCQ8sqkeKr0b/ee+82BGdn7D1No8dcb6lcUBHZzIampWwZUvV efD/7xwDVffDvWielCMLPY8iJKuTvubILB16sqsf2lMbaCBD6tdjDN43yGCAX+xBdvMr 0zJg== MIME-Version: 1.0 Received: by 10.60.25.162 with SMTP id d2mr16497601oeg.30.1334062973959; Tue, 10 Apr 2012 06:02:53 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 06:02:53 -0700 (PDT) In-Reply-To: <751BFD3F-22CB-44B2-A79F-AC53681DDF61@nasa.gov> References: <4F83EBB0.7000704@fkie.fraunhofer.de> <57C7B9F2-7201-4556-9DD3-5C3DCA727D55@inf-net.nl> <751BFD3F-22CB-44B2-A79F-AC53681DDF61@nasa.gov> Date: Tue, 10 Apr 2012 16:02:53 +0300 Message-ID: From: Pars Mutaf To: "Ivancic, William D. (GRC-RHN0)" Content-Type: multipart/alternative; boundary=e89a8ff1c16aabbf6204bd52bdb9 Cc: "manet@ietf.org" , "andre.oliveira@tekever.com" , "D.He@surrey.ac.uk" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:02:55 -0000 --e89a8ff1c16aabbf6204bd52bdb9 Content-Type: text/plain; charset=ISO-8859-1 OK I think I will leave it here. Thanks for the discussion. Pars If interested visit: http://content-based-science.org/ On Tue, Apr 10, 2012 at 4:00 PM, Ivancic, William D. (GRC-RHN0) < william.d.ivancic@nasa.gov> wrote: > manet protocols are a tool like any other. It is appropriate in some > cases and not in others. Same goes for DTN which is sort of super manet. > > - Will > > On Apr 10, 2012, at 7:42 AM, Pars Mutaf wrote: > > I am here to question. Not judge. > > On Tue, Apr 10, 2012 at 1:57 PM, Teco Boot wrote: > > > --e89a8ff1c16aabbf6204bd52bdb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK I think I will leave it here. Thanks for the discussion.

<= div>Pars

If interested visit:=A0



On Tue, Apr 10, 2012= at 4:00 PM, Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov> wrote:
manet pr= otocols are a tool like any other. =A0It is appropriate in some cases and n= ot in others. =A0Same goes for DTN which is sort of super manet.

- Will

On Apr 10, 2012, at 7:= 42 AM, Pars Mutaf wrote:

I am here to qu= estion. Not judge.=A0

On Tue, Apr 10, 201= 2 at 1:57 PM, Teco Boot <teco@inf-net.nl> wrote:


--e89a8ff1c16aabbf6204bd52bdb9-- From radhika.r.roy.civ@mail.mil Tue Apr 10 04:36:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3730221F854B for ; Tue, 10 Apr 2012 04:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxnryFzebrgb for ; Tue, 10 Apr 2012 04:36:38 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5821F854A for ; Tue, 10 Apr 2012 04:36:38 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Apr 2012 11:36:31 +0000 Received: from UCOLHP4H.easf.csd.disa.mil ([169.254.6.50]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 11:36:30 +0000 From: "Roy, Radhika R CIV (US)" To: Pars Mutaf Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: AQHNFtpvkgXVLvQs9EK2dEw2/FnoyZaT7ftA Date: Tue, 10 Apr 2012 11:36:31 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF484B3837@ucolhp4h.easf.csd.disa.mil> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Apr 2012 08:00:46 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:36:39 -0000 Provided balloon itself can provide BLOS communications via it for all grou= nd nodes. RRR -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of P= ars Mutaf Sent: Tuesday, April 10, 2012 1:26 AM To: manet@ietf.org Subject: [manet] Replacing MANET with a simple solution In a disaster scenario, the base stations are down, everything is broken.=20 Just find a big balloon, attach the antennas to it, send it to the air with= an electric cable connected to a power generator on the ground.=20 You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. From rick.taylor@cassidian.com Tue Apr 10 08:11:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF31E21F8518 for ; Tue, 10 Apr 2012 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GZ6QXrnrPqZ for ; Tue, 10 Apr 2012 08:11:39 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF4D11E80FA for ; Tue, 10 Apr 2012 08:11:36 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 10 Apr 2012 17:11:33 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 10 Apr 2012 17:11:32 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 17:11:32 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 17:11:32 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 16:11:52 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2012 16:11:30 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0TQRvmPgTgo7WMS1WMoR3BF4O+vgD5ipMg References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" X-OriginalArrivalTime: 10 Apr 2012 15:11:52.0404 (UTC) FILETIME=[426CD140:01CD172C] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.000 X-TM-AS-Result: No--13.527500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:11:40 -0000 Following the massive debate on fitting DLEP to RFC5444/packetBB, I have started to draw up some ASCII art packets, and have immediately hit a question. I will try to provide some background... In OLSR, there are 3 Message-Types: HELLO, TC, and MID. Each has its own assigned number, and can contain TLVs either in the message-block or the address-block as is relevant. In DLEP, there are 17 potential message-types (currently). Now, in draft-02, the authors have opted to have a single message-type (DLEP_MESSAGE) and then have 17 TLVs for each 'message' with sub-TLVs to carry per-TLV extra data, some mandatory, some optional. As I see it, there are 3 choices: 1) DLEP reserves 17+ top-level message type ids, and the sub-TLVs become TLVs. 2) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and the sub-TLVs remain.=20 3) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and each DLEP message has a single mandatory message-private TLV (containing all the mandatory per-DLEP-message data) and uses the TLV-type-extension mechanism to handle optional sub-TLVs. The problem with this solution is the implicit ordering introduced between the extension TLV-types and the 'base' TLV type. Note: I am *not* discussing address-block TLVs vs message-block TLVs, as I believe there is rough consensus on that issue. As an example of option 3) Here is a DLEP Attached Peer Discovery message, with the mandatory server and client IDs, and with 1 optional ext-type TLV for version. I include the packet header as well. You might have to consult your copy of RFC5444 to check the flag-bits (and I might have got them reversed) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Packet |Packet | Msg Type =3D | Msg | Msg | Message Size ~ |Version| Flags | DLEP_MESSAGE | Flags |AddrLen| ~ | 0x0 |0 0 0 0| (value TBD) |0 0 0 1| 0 | 27 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Message Size | | TLVs length ~ ~ | Message Sequence Number | ~ ~ | | 19 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs length | DLEP Attached | TLV flags | TLV length | ~ |Peer Discovery | | | ~ | (value TBD) |0 0 0 1 0 0 0 0| 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Server ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Client ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Attached | TLV flags | TLV Ext Type | TLV length | |Peer Discovery | | 'VERSION' | | | (value TBD) |1 0 0 1 0 0 0 0| (value TBD) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Major | Minor | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Hope that is clear enough to start another round of discussion... Rick Taylor From ulrich@herberg.name Tue Apr 10 08:22:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8511E80CD for ; Tue, 10 Apr 2012 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-CQxp7HXAIZ for ; Tue, 10 Apr 2012 08:22:56 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 83A6E11E80BE for ; Tue, 10 Apr 2012 08:22:56 -0700 (PDT) Received: by dady13 with SMTP id y13so9448255dad.27 for ; Tue, 10 Apr 2012 08:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UugRFXQJRnX4xxRvrRoCBN8aG3vbIhgadslQhdVwIs=; b=Cn5CQTN+9SnUFOl5yAz6rHj79FbmzLGqaFiNz+74V/gQrNOi0YSgWGZGz/RCn3bXyU NEwZbuUjPwQCvqQutjxfsXguqcoG/pdO0BRqJ0cY/+tCAxGJyi2cKztLa0xMnE1ihMz3 AGekiPRAOJllbb1UyB2HXXnAD8iHP3c5eBclY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=1UugRFXQJRnX4xxRvrRoCBN8aG3vbIhgadslQhdVwIs=; b=h0InMW9F0xczzDybWzNBnSDvC8QiMoByaCvndMkWU/LoPWgjJ/5x3wxxaB8iNkKen/ Sff4xT7CEZX5S4GA9BBJlc0uDY7pw7unr6gd2k3nx+jwGLugh8zHJ9Vj8gPYakP9N37v Z0YmXD9diJlEWhsikWe4fAkHOAQJecegB2sMBVLF5DmmGmeqBcRqAPsNL9mtiL1c8TTQ kSZyBXAATcEgH+iHYLCIv9TCEi6lAouswYP8WwOOFY2wxNb9otjUMIOS+2xfyxsbEWQt 0A8SQGSG2DYVnrGuAvZ8Juu8Nc4+43Q5FER85oJ7zZBM7xksnMhlEcl50ScjPlwuO6RJ 2Idw== MIME-Version: 1.0 Received: by 10.68.230.8 with SMTP id su8mr23388829pbc.49.1334071376193; Tue, 10 Apr 2012 08:22:56 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Tue, 10 Apr 2012 08:22:56 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> Date: Tue, 10 Apr 2012 08:22:56 -0700 Message-ID: From: Ulrich Herberg To: Rick Taylor Content-Type: multipart/alternative; boundary=047d7b339cab7baa9a04bd54b2de X-Gm-Message-State: ALoCoQn4oNwoetDWvVJOaZ70FirSxK4UWa2DnreGb257vKChjsj+L2pBe4PAZzt5YBk1je1Q8NFV Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:22:57 -0000 --047d7b339cab7baa9a04bd54b2de Content-Type: text/plain; charset=ISO-8859-1 Hi Rick, On Tue, Apr 10, 2012 at 8:11 AM, Rick Taylor wrote: > Following the massive debate on fitting DLEP to RFC5444/packetBB, I have > started to draw up some ASCII art packets, and have immediately hit a > question. I will try to provide some background... > > In OLSR, there are 3 Message-Types: HELLO, TC, and MID. Each has its > own assigned number, and can contain TLVs either in the message-block or > the address-block as is relevant. > > In DLEP, there are 17 potential message-types (currently). Now, in > draft-02, the authors have opted to have a single message-type > (DLEP_MESSAGE) and then have 17 TLVs for each 'message' with sub-TLVs to > carry per-TLV extra data, some mandatory, some optional. > > As I see it, there are 3 choices: > > 1) DLEP reserves 17+ top-level message type ids, and the sub-TLVs become > TLVs. > That's probably not a good idea, given that we only have 255 message types for MANET protocols. > > 2) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and the > sub-TLVs remain. > For the reasons I wrote in my last email, I don't think this is a good idea either (redundant parser code). > > 3) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and each > DLEP message has a single mandatory message-private TLV (containing all > the mandatory per-DLEP-message data) and uses the TLV-type-extension > mechanism to handle optional sub-TLVs. The problem with this solution > is the implicit ordering introduced between the extension TLV-types and > the 'base' TLV type. > Isn't there a 4th possible solution: 4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV which defines the "message type" plus zero or more message-specific TLVs for the data? (i.e. no sub-TLVs, and not necessarily a type extension). Or is that what you mean? Regards Ulrich > > Note: I am *not* discussing address-block TLVs vs message-block TLVs, as > I believe there is rough consensus on that issue. > > As an example of option 3) > > Here is a DLEP Attached Peer Discovery message, with the mandatory > server and client IDs, and with 1 optional ext-type TLV for version. I > include the packet header as well. You might have to consult your copy > of RFC5444 to check the flag-bits (and I might have got them reversed) > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Packet |Packet | Msg Type = | Msg | Msg | Message Size ~ > |Version| Flags | DLEP_MESSAGE | Flags |AddrLen| ~ > | 0x0 |0 0 0 0| (value TBD) |0 0 0 1| 0 | 27 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Message Size | | TLVs length ~ > ~ | Message Sequence Number | ~ > ~ | | 19 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ TLVs length | DLEP Attached | TLV flags | TLV length | > ~ |Peer Discovery | | | > ~ | (value TBD) |0 0 0 1 0 0 0 0| 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Server ID | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Client ID | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DLEP Attached | TLV flags | TLV Ext Type | TLV length | > |Peer Discovery | | 'VERSION' | | > | (value TBD) |1 0 0 1 0 0 0 0| (value TBD) | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | > | Major | Minor | > | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Hope that is clear enough to start another round of discussion... > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b339cab7baa9a04bd54b2de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rick,

On Tue, Apr 10, 2012 at 8:11 AM,= Rick Taylor <Rick.Taylor@cassidian.com> wrote:
Following the massive debate on fitting DLEP to RFC5444/packetBB, I have started to draw up some ASCII art packets, and have immediately hit a
question. =A0I will try to provide some background...

In OLSR, there are 3 Message-Types: HELLO, TC, and MID. =A0Each has its
own assigned number, and can contain TLVs either in the message-block or the address-block as is relevant.

In DLEP, there are 17 potential message-types (currently). =A0Now, in
draft-02, the authors have opted to have a single message-type
(DLEP_MESSAGE) and then have 17 TLVs for each 'message' with sub-TL= Vs to
carry per-TLV extra data, some mandatory, some optional.

As I see it, there are 3 choices:

1) DLEP reserves 17+ top-level message type ids, and the sub-TLVs become TLVs.


That's probably not a good idea, giv= en that we only have 255 message types for MANET protocols.
=A0

2) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and the
sub-TLVs remain.

For the reasons I wrote in my las= t email, I don't think this is a good idea either (redundant parser cod= e).
=A0

3) DLEP reserves 1 top-level message type id (DLEP_MESSAGE), and each
DLEP message has a single mandatory message-private TLV (containing all
the mandatory per-DLEP-message data) and uses the TLV-type-extension
mechanism to handle optional sub-TLVs. =A0The problem with this solution is the implicit ordering introduced between the extension TLV-types and
the 'base' TLV type.


Isn't there a= 4th possible solution:
4) DLEP reserves 1 message type (DLEP_MESSAGE), = one message TLV which defines the "message type" plus zero or mor= e message-specific TLVs for the data? (i.e. no sub-TLVs, and not necessaril= y a type extension).

Or is that what you mean?

Regards
Ulrich

=A0

Note: I am *not* discussing address-block TLVs vs message-block TLVs, as I believe there is rough consensus on that issue.

As an example of option 3)

Here is a DLEP Attached Peer Discovery message, with the mandatory
server and client IDs, and with 1 optional ext-type TLV for version. =A0I include the packet header as well. =A0You might have to consult your copy of RFC5444 to check the flag-bits (and I might have got them reversed)

=A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A00 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Packet |Packet | =A0Msg Type =3D =A0 | =A0Msg =A0| =A0Msg =A0| Message Siz= e =A0~
|Version| Flags | DLEP_MESSAGE =A0| Flags |AddrLen| =A0 =A0 =A0 =A0 =A0 =A0= =A0 ~
| =A00x0 =A0|0 0 0 0| =A0(value TBD) =A0|0 0 0 1| =A0 0 =A0 | =A0 =A0 =A027= =A0 =A0 =A0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Size =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | =A0TLVs length =A0~
~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Message Sequence Number =A0 =A0| =A0= =A0 =A0 =A0 =A0 =A0 =A0 ~
~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A019 =A0 =A0 =A0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ =A0TLVs length =A0| DLEP Attached | =A0 TLV flags =A0 | =A0TLV length =A0= |
~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 |Peer Discovery | =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0(value TBD) =A0|0 0 0 1 0 0 0 0| =A0 =A0= =A0 8 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Server ID =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Client ID =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP Attached | =A0 TLV flags =A0 | TLV Ext Type =A0| =A0 TLV length =A0|=
|Peer Discovery | =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 'VERSION' =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| =A0(value TBD) =A0|1 0 0 1 0 0 0 0| =A0(value TBD) =A0| =A0 =A0 =A0 4 =A0= =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
| =A0 =A0 =A0 =A0 =A0 =A0 Major =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 Minor =A0 =A0 =A0 =A0 =A0 =A0 |
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hope that is clear enough to start another round of discussion...

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

--047d7b339cab7baa9a04bd54b2de-- From budden@nps.edu Tue Apr 10 09:11:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31021F8510 for ; Tue, 10 Apr 2012 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMuaLcXnh3kz for ; Tue, 10 Apr 2012 09:11:48 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id BD1EF21F850B for ; Tue, 10 Apr 2012 09:11:48 -0700 (PDT) X-ASG-Debug-ID: 1334074308-036c92049311f3a0001-Rp4q3q Received: from skytrain.ern.nps.edu (skytrain.ern.nps.edu [172.20.24.112]) by mule.nps.edu with ESMTP id nJ9GHsVfEiUcxAdG; Tue, 10 Apr 2012 09:11:48 -0700 (PDT) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Apr 2012 09:11:47 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] Replacing MANET with a simple solution To: In-Reply-To: References: <4F83EBB0.7000704@fkie.fraunhofer.de> , Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Apr 2012 09:11:00 -0700 Message-ID: <1334074260.22388.1042.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: skytrain.ern.nps.edu[172.20.24.112] X-Barracuda-Start-Time: 1334074308 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.93735 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: manet@ietf.org, andre.oliveira@tekever.com Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:11:51 -0000 On Tue, 2012-04-10 at 11:29 +0100, D.He@surrey.ac.uk wrote: > > for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, > recent years 10MB > bandwidth satellite links are also available on the martket (in uk). > regarding delay, satellite > may introduce the round trip delay however, does it really impact the > VoIP or video communications? > it is relied on the quality of service if you get down the streaming > bandwidth. satellite > is a perfect solution to relay MANET traffics. at least it is better > than nothing. > > Dan, Pars does have some good points. But let's get this one in perspective. The terrestrial internet has links in it provisioned at 10G (even stodgy old US Defense Information System Network has OC192 backbones). And wired LANs can be provisioned in the same territory .... all for a trip to the corner store. But carefully watch the decimal point. And use the numbers you quoted. Radio-WANs using IEEE 802.16 or LTE protocols generally yield the 10M kind of numbers you quote. Highly dependent on the amount of spectrum allocated and also dependent on the number of subscribers this spectrum has to be pro-rated across. And somewhat dependent on whether it's raining or not. This is four orders of magnitude less capacity that is readily available in the wired portion of the internet. 2M and 4M is an order of magnitude less than that. The problem here is that the current technology is approaching some physics limits (in terms of bits/Hertz). More capacity in the terrestrial internet is a matter of more WDM subchannels and more fiber in the ground -- essentially an engineering and provisioning problem. More capacity in the radio-WAN requires more spectrum ... and exploitation of multicast. This topology problem is masked if your perspective is WiFi or cellphone because those are LAN technology (radios at the fringe of the internet, not interior). We can bludgeon the capacity problems by increasing cell number (and consequent freq reuse). -- Rex Buddenberg Senior Lecturer Naval Postgraduate School 831/656-3576 From hrogge@googlemail.com Tue Apr 10 12:14:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CE11E8119 for ; Tue, 10 Apr 2012 12:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skmOlH4q6a7P for ; Tue, 10 Apr 2012 12:14:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3B0011E8117 for ; Tue, 10 Apr 2012 12:14:17 -0700 (PDT) Received: by lbok13 with SMTP id k13so121695lbo.31 for ; Tue, 10 Apr 2012 12:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yngF8d8R+GG2PYFhRcCZiLQO+g88nwmJBj6xsZ3eve4=; b=PtOIzaNUtNlVFrpOmuZopLzlJwcmnjoiF5gNuEDBDf+UbhcTF8N90vv3HGOMTLbJxZ byC056vgXlf30p+BO9Ml6RCCFQr3go5btbAoOfV46py36NopcZEQypjVxE4crsvD2Uqv BeKWWBjNXihl4oB/ypi66DcryOGjmYawLibAvPCrfzDyIva4+JX8lxFZrSZUdFgK9L4Q qtInGpDY45ykBoo9r480oDJmT9lia3S7O7QLGWBR3vFbWlaAStaHx32hOK4g9wy9Je2k AJH5t37Lv/IoT2vc9L+y/C2P3kYCQoY2Hcdip9CmZsiv5LMBzPo9wb02HTSIeVzbDnHB ilkg== Received: by 10.112.48.36 with SMTP id i4mr1772067lbn.84.1334085256900; Tue, 10 Apr 2012 12:14:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Tue, 10 Apr 2012 12:13:55 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Tue, 10 Apr 2012 21:13:55 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:14:19 -0000 On Tue, Apr 10, 2012 at 17:22, Ulrich Herberg wrote: > Isn't there a 4th possible solution: > 4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV which > defines the "message type" plus zero or more message-specific TLVs for the > data? (i.e. no sub-TLVs, and not necessarily a type extension). We could even make this "message type" TLV a generic message TLV and call it MESSAGE_EXTTYPE. It would either have a 1 byte value or an extension type itself, it would be similar to the optional extension type of normal TLVs, extending the concept to messages. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Tue Apr 10 12:28:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FEB11E80FD for ; Tue, 10 Apr 2012 12:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMrESBtSw5-2 for ; Tue, 10 Apr 2012 12:27:59 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 503EB11E80DF for ; Tue, 10 Apr 2012 12:27:59 -0700 (PDT) Received: by eeke51 with SMTP id e51so38400eek.31 for ; Tue, 10 Apr 2012 12:27:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=R0tqLPvP4zshlc9HYaRAQoWO+c7e61Rhi4EBiuS56ns=; b=gkztcVnVEIPHL7dZvBnRROcExAVFdlPFAsu5TEYYPpDdlkzhFrFrWCEeeJfWByqV54 fl2F63VckmLOa+unmPeYFv6ws+rP/ojycyj/2W1ZrwW7Rm7skFs6MrxN4x9ZolItqcpp tfXgIuiIz3KufaVhy63gSBAB/IGD3e0uKe4+ttU/DsB0sI066FRBfSSGnxJTleu06y4u vkpor4RndycD44TkokLwGZ7tZmoimjUqZoTY8ftNeIaySPAZSkTJAJZXMASZgCCzIPB1 DZMPNbMBe7gznhqI6IJ1AQEIMmcyexIf9nRc7nmFc9x4PBlVZQ5j5bI9RMxP9t3zwo99 vBgA== Received: by 10.213.26.69 with SMTP id d5mr823506ebc.61.1334086077487; Tue, 10 Apr 2012 12:27:57 -0700 (PDT) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id e56sm1134799eea.11.2012.04.10.12.27.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:27:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <1334074260.22388.1042.camel@localhost.localdomain> Date: Tue, 10 Apr 2012 21:27:56 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4F83EBB0.7000704@fkie.fraunhofer.de> , <1334074260.22388.1042.camel@localhost.localdomain> To: Rex Buddenberg X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkaD4SDwtIY7beBHyX+sM9ztbfN+tjViUQV1QR8TftBJEu47eeMAb6LkwsRaqrsxd8Fp/Mt Cc: manet@ietf.org, andre.oliveira@tekever.com, D.He@surrey.ac.uk Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:28:00 -0000 Op 10 apr. 2012, om 18:11 heeft Rex Buddenberg het volgende geschreven: > On Tue, 2012-04-10 at 11:29 +0100, D.He@surrey.ac.uk wrote: >> >> for satellite bandwidth, typical bandwidth is 2MBps or 4Mbps, however, >> recent years 10MB >> bandwidth satellite links are also available on the martket (in uk). >> regarding delay, satellite >> may introduce the round trip delay however, does it really impact the >> VoIP or video communications? >> it is relied on the quality of service if you get down the streaming >> bandwidth. satellite >> is a perfect solution to relay MANET traffics. at least it is better >> than nothing. >> >> > > Dan, Pars does have some good points. But let's get this one in > perspective. > > The terrestrial internet has links in it provisioned at 10G (even stodgy > old US Defense Information System Network has OC192 backbones). And > wired LANs can be provisioned in the same territory .... all for a trip > to the corner store. > > But carefully watch the decimal point. And use the numbers you > quoted. > Radio-WANs using IEEE 802.16 or LTE protocols generally yield the 10M > kind of numbers you quote. Highly dependent on the amount of spectrum > allocated and also dependent on the number of subscribers this spectrum > has to be pro-rated across. And somewhat dependent on whether it's > raining or not. This is four orders of magnitude less capacity that is > readily available in the wired portion of the internet. > 2M and 4M is an order of magnitude less than that. The problem here is > that the current technology is approaching some physics limits (in terms > of bits/Hertz). More capacity in the terrestrial internet is a matter > of more WDM subchannels and more fiber in the ground -- essentially an > engineering and provisioning problem. More capacity in the radio-WAN > requires more spectrum Or reduced distance / smaller cells / more cells, as you described below. > ... and exploitation of multicast. Doesn't work that well in some cases (lowest data rate, unreliable). I think it is well accepted there is room for MANET and the hub/spoke with base stations. These are complementary technologies. Short-sighted to pick one and ignore the other. Teco > > This topology problem is masked if your perspective is WiFi or cellphone > because those are LAN technology (radios at the fringe of the internet, > not interior). We can bludgeon the capacity problems by increasing cell > number (and consequent freq reuse). > > > -- > Rex Buddenberg > Senior Lecturer > Naval Postgraduate School > 831/656-3576 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From reller@cococorp.com Tue Apr 10 15:08:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C110C11E8129 for ; Tue, 10 Apr 2012 15:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXnhbHkk7QRd for ; Tue, 10 Apr 2012 15:08:30 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D611E8125 for ; Tue, 10 Apr 2012 15:08:29 -0700 (PDT) Received: from EXHUB03.exchhosting.com (192.168.11.104) by exhub05.exchhosting.com (192.168.11.101) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Apr 2012 15:08:27 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by EXHUB03.exchhosting.com ([fe80::ac41:fbe5:3959:ad64%12]) with mapi; Tue, 10 Apr 2012 15:08:26 -0700 From: "A. Riley Eller" To: Pars Mutaf Date: Tue, 10 Apr 2012 15:08:24 -0700 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0W7i1Sp1+j2kV2Sia60oQYJFWBwAAd1kyQ Message-ID: <3D05610F3AC2E047AACAA68F63DF908D362CE133AB@EXMBX13.exchhosting.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D05610F3AC2E047AACAA68F63DF908D362CE133ABEXMBX13exchho_" MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:08:30 -0000 --_000_3D05610F3AC2E047AACAA68F63DF908D362CE133ABEXMBX13exchho_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This has been built many times. Once recently by myself and a few LiftPort = volunteers at Random Hacks of Kindness Seattle 2011 (RHoKSea11). We ran a h= igh powered access point from the bottom with antennas at the top connected= via a stripped Ethernet cable. The canisters of hydrogen also made good an= chor weights and provided a fuel source for the generator. We immediately r= ealized that, for phase 2, we wanted a mesh network of balloons, running a = real routing protocol. From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of P= ars Mutaf Sent: Tuesday, April 10, 2012 12:47 AM To: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution More precisely, Just use a balloon at the same height as the previous base station and sate= llite... The same phones can be used. The balloon will make the interface to the sat= ellite. To solve the wind problem (not sure if it is that important) we can use 3 c= ables to attach the balloon to the ground. On Tue, Apr 10, 2012 at 8:25 AM, Pars Mutaf > wrote: In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with= an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. --_000_3D05610F3AC2E047AACAA68F63DF908D362CE133ABEXMBX13exchho_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This has = been built many times. Once recently by myself and a few LiftPort volunteer= s at Random Hacks of Kindness Seattle 2011 (RHoKSea11). We ran a high power= ed access point from the bottom with antennas at the top connected via a st= ripped Ethernet cable. The canisters of hydrogen also made good anchor weig= hts and provided a fuel source for the generator. We immediately realized t= hat, for phase 2, we wanted a mesh network of balloons, running a real rout= ing protocol.

 =

 

From: manet-bounces@ietf.org [mailto:manet-bounce= s@ietf.org] On Behalf Of Pars Mutaf
Sent: Tuesday, April 1= 0, 2012 12:47 AM
To: manet@ietf.org
Subject: Re: [manet= ] Replacing MANET with a simple solution

 

More precisely,

Just use a balloon at the same height a= s the previous base station and satellite...

The same phones can be= used. The balloon will make the interface to the satellite.

To sol= ve the wind problem (not sure if it is that important) we can use 3 cables = to attach the balloon to the ground.


On Tue, Apr 10, 2012 at 8:25 AM, Pars Mutaf <pars.mutaf@gmail.com> wrote:

In a disaster scenario, the base stations are down, = everything is broken. 

&n= bsp;

Just find a big balloon, atta= ch the antennas to it, send it to the air with an electric cable = connected to a power generator on the ground. 

 

You have a base station in 1 hour.

 

Why spend = millions of dollars/euros for this MANET effort?

<= div>

 

Pars = Mutaf

Asst. Prof.

 

= --_000_3D05610F3AC2E047AACAA68F63DF908D362CE133ABEXMBX13exchho_-- From cedric.adjih@inria.fr Wed Apr 11 00:31:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323AE21F841B for ; Wed, 11 Apr 2012 00:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.934 X-Spam-Level: X-Spam-Status: No, score=-9.934 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvde9FCvBUyz for ; Wed, 11 Apr 2012 00:31:51 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4485321F84F2 for ; Wed, 11 Apr 2012 00:31:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,404,1330902000"; d="scan'208";a="153509202" Received: from zmbs1.inria.fr ([128.93.142.14]) by mail1-relais-roc.national.inria.fr with ESMTP; 11 Apr 2012 09:31:48 +0200 Date: Wed, 11 Apr 2012 09:31:48 +0200 (CEST) From: Cedric Adjih To: "A. Riley Eller" Message-ID: <20500118.362.1334129682183.JavaMail.adjih@canith> In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D362CE133AB@EXMBX13.exchhosting.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.93.17.134] X-Mailer: Zimbra 6.0.15_GA_2995 (Zimbra Desktop/2.0.1_10659_Linux) Cc: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:31:52 -0000 This is indeed a nice use of a ballon for communications. Another one I know of is the SkyMesh from Niigata University, Japan, which is indeed an Ad Hoc Network with balloons for emergency networks. http://openblocks.plathome.com/casestudy/obs_niigata.html http://www2.net.ie.niigata-u.ac.jp/paper/OLSRInterrop2008.pdf And back to the original question of another practical example of use of MANET, is DUMBO-MM, where a MANET is used to extend a satellite connection http://www.interlab.ait.ac.th/myanmar/cyclone/dumbo_topology.php -- Cedric ----- Original Message ----- From: "A. Riley Eller" To: "Pars Mutaf" Cc: manet@ietf.org Sent: Wednesday, April 11, 2012 12:08:24 AM Subject: Re: [manet] Replacing MANET with a simple solution This has been built many times. Once recently by myself and a few LiftPort volunteers at Random Hacks of Kindness Seattle 2011 (RHoKSea11). We ran a high powered access point from the bottom with antennas at the top connected via a stripped Ethernet cable. The canisters of hydrogen also made good anchor weights and provided a fuel source for the generator. We immediately realized that, for phase 2, we wanted a mesh network of balloons, running a real routing protocol. From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars Mutaf Sent: Tuesday, April 10, 2012 12:47 AM To: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution More precisely, Just use a balloon at the same height as the previous base station and satellite... The same phones can be used. The balloon will make the interface to the satellite. To solve the wind problem (not sure if it is that important) we can use 3 cables to attach the balloon to the ground. On Tue, Apr 10, 2012 at 8:25 AM, Pars Mutaf < pars.mutaf@gmail.com > wrote: In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Wed Apr 11 01:56:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE56D11E8195 for ; Wed, 11 Apr 2012 01:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V-fWOuxHnDN for ; Wed, 11 Apr 2012 01:56:10 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4825511E8150 for ; Wed, 11 Apr 2012 01:56:07 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 10:56:04 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 10:56:04 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 10:56:03 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 10:56:03 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 09:56:24 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 09:56:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0XTlXLQDR7vKVxSrGn+QP24U8YfQAclLgg References: <7B31B0093014224A843C10C0CCE92AC1035ABA92@SUKNPT8106.cogent-dsn.local> <4F7C43BC.3010204@fkie.fraunhofer.de> <29C9B076-C1FA-4E34-B810-B9856B44172F@cisco.com> <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , "Ulrich Herberg" X-OriginalArrivalTime: 11 Apr 2012 08:56:24.0787 (UTC) FILETIME=[F9550230:01CD17C0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.005 X-TM-AS-Result: No--16.777700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Stan Ratliff Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:56:11 -0000 > From: Henning Rogge [mailto:hrogge@googlemail.com] >=20 > On Tue, Apr 10, 2012 at 17:22, Ulrich Herberg wrote: > > Isn't there a 4th possible solution: > > 4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV which > > defines the "message type" plus zero or more message-specific TLVs for > the > > data? (i.e. no sub-TLVs, and not necessarily a type extension). >=20 > We could even make this "message type" TLV a generic message TLV and > call it MESSAGE_EXTTYPE. It would either have a 1 byte value or an > extension type itself, it would be similar to the optional extension > type of normal TLVs, extending the concept to messages. >=20 Could you elaborate on this for me please? I don't see how this is different from Stan's sub-TLV proposal? Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 02:02:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D9621F86DC for ; Wed, 11 Apr 2012 02:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAGRyUj7U0il for ; Wed, 11 Apr 2012 02:02:22 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 071A521F86D3 for ; Wed, 11 Apr 2012 02:02:22 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHtRU-0008Ot-R8 for manet@ietf.org; Wed, 11 Apr 2012 11:02:20 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHtRU-0000Dq-OS for manet@ietf.org; Wed, 11 Apr 2012 11:02:20 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 11:02:20 +0200 Message-ID: <4F85489B.4000604@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 11:02:19 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <291ABF54-9012-485C-832C-428A387C055D@cisco.com> <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local> <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020202000708000700080907" X-OriginalArrivalTime: 11 Apr 2012 09:02:20.0562 (UTC) FILETIME=[CD63F720:01CD17C1] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8ac2e9db9cb74b112e4303f89b85ed9a Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 09:02:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020202000708000700080907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 10:56 AM, Rick Taylor wrote: >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> >> On Tue, Apr 10, 2012 at 17:22, Ulrich Herberg > wrote: >>> Isn't there a 4th possible solution: >>> 4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV > which >>> defines the "message type" plus zero or more message-specific TLVs > for >> the >>> data? (i.e. no sub-TLVs, and not necessarily a type extension). >> >> We could even make this "message type" TLV a generic message TLV and >> call it MESSAGE_EXTTYPE. It would either have a 1 byte value or an >> extension type itself, it would be similar to the optional extension >> type of normal TLVs, extending the concept to messages. >> > > Could you elaborate on this for me please? I don't see how this is > different from Stan's sub-TLV proposal? I support the same strategy Ulrich Herberg suggested, moving all subTLVs = into normal message TLVs and addresses/address-TLVs. To allow the receiver of the DLEP message to differentiate between the=20 DLEP protocol messages (called "orders" in the current draft), we add an = additional TLV that carries the order number (either as a 1-byte value=20 or as the TLV extension type). I think instead of making this TLV a DLEP-specific, we could use a TLV=20 from the "global" message TLV scope. The concept of having an "extension = type" for the message type could be useful in other future protocols too.= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020202000708000700080907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTEwOTAyMTlaMCMGCSqGSIb3DQEJBDEWBBS2GsCJa5/gYHsRWCxh31gmKD8zoTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAIroUond4jXNMASxu4LA50lrenEPCiTKH+7282/XY/Vng1WtMz0I+xCOUeKOCe oWzR+SrbsIUg901orFu6UWw4PoUKOEF7lbgOmwLG0lVdtiF2ci4eNyLeLOv6fS0UBX7eN0Ny hczMK57rgZOxbb+BErXafIwjOO1FggrI+Ul3viyHwRTCsPcHou0mSBQQfME/qHDIPuSUcyFq hm1+YAD8S1L2jFjjqaWN5Vodu/uOhk6ggGiX+ufYFIQ4k60mC9vpYKAAeaDDGiE5yjL41Gj4 99e6C6HhyVYkh+MlgvETq1DClnHlnbZeCBhwlYsXicHTodjoRo2JDbGEXmODZdEOAAAAAAAA --------------ms020202000708000700080907-- From rick.taylor@cassidian.com Wed Apr 11 03:43:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4221F85A4 for ; Wed, 11 Apr 2012 03:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, SARE_BAYES_6x6=0.4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMu4oENL5pdO for ; Wed, 11 Apr 2012 03:43:08 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 309DD21F85A3 for ; Wed, 11 Apr 2012 03:43:06 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 12:43:04 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 12:43:04 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:43:04 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:43:04 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 11:43:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 11:43:02 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0XwnCCpjSNvXD6RyiXpe+/JublygABLLAg References: <291ABF54-9012-485C-832C-428A387C055D@cisco.com><7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local><90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 11 Apr 2012 10:43:25.0706 (UTC) FILETIME=[EC7F7EA0:01CD17CF] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.006 X-TM-AS-Result: No--21.111400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:43:09 -0000 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge >=20 > On 04/11/2012 10:56 AM, Rick Taylor wrote: > >> From: Henning Rogge [mailto:hrogge@googlemail.com] > >> > >> On Tue, Apr 10, 2012 at 17:22, Ulrich Herberg > > wrote: > >>> Isn't there a 4th possible solution: > >>> 4) DLEP reserves 1 message type (DLEP_MESSAGE), one message TLV > > which > >>> defines the "message type" plus zero or more message-specific TLVs > > for > >> the > >>> data? (i.e. no sub-TLVs, and not necessarily a type extension). > >> > >> We could even make this "message type" TLV a generic message TLV and > >> call it MESSAGE_EXTTYPE. It would either have a 1 byte value or an > >> extension type itself, it would be similar to the optional extension > >> type of normal TLVs, extending the concept to messages. > >> > > > > Could you elaborate on this for me please? I don't see how this is > > different from Stan's sub-TLV proposal? >=20 > I support the same strategy Ulrich Herberg suggested, moving all subTLVs > into normal message TLVs and addresses/address-TLVs. >=20 > To allow the receiver of the DLEP message to differentiate between the > DLEP protocol messages (called "orders" in the current draft), we add an > additional TLV that carries the order number (either as a 1-byte value > or as the TLV extension type). >=20 > I think instead of making this TLV a DLEP-specific, we could use a TLV > from the "global" message TLV scope. The concept of having an "extension > type" for the message type could be useful in other future protocols too. >=20 Isn't this very similar to what I proposed? DLEP-specific TLVs that state which DLEP order is contained in the message + extra TLVs to carry additional information? >From my reading of draft-02, each 'order' carries some mandatory information, which can be placed in a single message-specific TLV, plus optional information, that can be carried in message-specific order-extension TLVs in the same message? By careful selection of extension type ids we can keep the sub-TLV concept. If I analyse the DLEP draft and assign some simple IDs, the orders are: KEY: 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type) 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY All address-block-TLVs use a of 6 and the MAC address of the neighbour. Please note the encoding of the extension types, i.e. the extension-id is constant, just the type-id changes (sort of covering the sub-TLV concept) I have also made version and status mandatory whenever specified. Attached Peer Discovery (message-block-TLVs) 0x01 Identification + Version 0x0101 Peer Type 0x0102 Heartbeat Interval 0x0103 Heartbeat Threshold 0x0104 Link Characteristics ACK Timer 0x0181 Maximum Data Rate 0x0182 Current Data Rate 0x0183 Latency 0x0184 Expected Forwarding Time 0x0185 Resources 0x0186 Relative Link Quality Detached Peer Discovery (message-block-TLVs) 0x02 Identification + Version 0x0201 Peer Type 0x0202 Heartbeat Interval 0x0203 Heartbeat Threshold 0x0204 Link Characteristics ACK Timer 0x0281 Maximum Data Rate 0x0282 Current Data Rate 0x0283 Latency 0x0284 Expected Forwarding Time 0x0285 Resources 0x0286 Relative Link Quality Peer Offer (message-block-TLVs) 0x03 Identification + Version + Status 0x0301 Peer Type 0x0302 Heartbeat Interval 0x0303 Heartbeat Threshold 0x0304 Link Characteristics ACK Timer 0x0311 IPv4 Address 0x0312 IPv6 Address Peer Update Message (message-block-TLVs) 0x04 Identification + Version 0x0401 Peer Type 0x0411 IPv4 Address 0x0412 IPv6 Address 0x0481 Maximum Data Rate 0x0482 Current Data Rate 0x0483 Latency 0x0484 Expected Forwarding Time 0x0485 Resources 0x0486 Relative Link Quality =20 Peer Update ACK Message (message-block-TLVs) 0x05 Identification + Status Peer Termination Message (message-block-TLVs) 0x06 Identification + Status Peer Termination ACK Message (message-block-TLVs) 0x07 Identification + Status Peer Heartbeat Message (message-block-TLVs) 0x08 Identification Neighbour Up Message (address-block-TLVs) 0x01 Identification 0x0101 Credit Window Status 0x0111 IPv4 Address 0x0112 IPv6 Address 0x0181 Maximum Data Rate 0x0182 Current Data Rate 0x0183 Latency 0x0184 Expected Forwarding Time 0x0185 Resources 0x0186 Relative Link Quality Neighbour Up ACK Message (address-block-TLVs) 0x02 Identification + Status 0x0201 Credit Window Status =20 Neighbour Down Message (address-block-TLVs) 0x03 Identification + Status Neighbour Down ACK Message (address-block-TLVs) 0x04 Identification + Status Neighbour Update Message (address-block-TLVs) 0x05 Identification 0x0501 Credit Window Status 0x0502 Credit Grant 0x0503 Credit Request 0x0581 Maximum Data Rate 0x0582 Current Data Rate 0x0583 Latency 0x0584 Expected Forwarding Time 0x0585 Resources 0x0586 Relative Link Quality Neighbour Address Update Message (address-block-TLVs) 0x07 Identification 0x0711 IPv4 Address 0x0712 IPv6 Address Neighbour Address Update ACK Message (address-block-TLVs) 0x08 Identification + Status Link Characteristics Request Message (address-block-TLVs) 0x09 Identification 0x0982 Current Data Rate 0x0983 Latency Link Characteristics ACK Message (address-block-TLVs) 0x0A Identification 0x0A82 Current Data Rate 0x0A83 Latency Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 03:49:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC40321F8622 for ; Wed, 11 Apr 2012 03:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SzKY0DNZb1H for ; Wed, 11 Apr 2012 03:49:02 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id EB83D21F862B for ; Wed, 11 Apr 2012 03:49:00 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHv6e-00058x-9w; Wed, 11 Apr 2012 12:48:56 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHv6e-00036n-7D; Wed, 11 Apr 2012 12:48:56 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:48:54 +0200 Message-ID: <4F856191.70208@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 12:48:49 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local><90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060607070001040701060707" X-OriginalArrivalTime: 11 Apr 2012 10:48:54.0822 (UTC) FILETIME=[B0AA9C60:01CD17D0] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8ac2e9db9cb74b112e4303f89b85ed9a Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 10:49:03 -0000 This is a cryptographically signed message in MIME format. --------------ms060607070001040701060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 12:43 PM, Rick Taylor wrote: > Isn't this very similar to what I proposed? DLEP-specific TLVs that > state which DLEP order is contained in the message + extra TLVs to carr= y > additional information? > > From my reading of draft-02, each 'order' carries some mandatory > information, which can be placed in a single message-specific TLV, plus= > optional information, that can be carried in message-specific > order-extension TLVs in the same message? By careful selection of > extension type ids we can keep the sub-TLV concept. > > If I analyse the DLEP draft and assign some simple IDs, the orders are:= > > KEY: > 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type= ) > 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY > > All address-block-TLVs use a of 6 and the MAC address of > the neighbour. > > Please note the encoding of the extension types, i.e. the extension-id > is constant, just the type-id changes (sort of covering the sub-TLV > concept) Why should we use different TLV types/exttypes for each of the orders? One TLV-type for "Peer Type" (as an example) should be enough for all=20 orders used in DLEP. The same is true for every TLV used for the data necessary for any DLEP=20 order. We should work on making the protocol SIMPLER without loosing=20 functionality, not making it even more complex. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060607070001040701060707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMDQ4NTJaMCMGCSqGSIb3DQEJBDEWBBTAQYiDGzXWw5aWb2U7iYEjhpfdizBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCjbvUh/BIE/63qySArKjtPfo7D80ItNvv/E1vztGDEU+E8RhwYjM9LzPkPxzPq krSpnUB7+noDGg5IXLzgfP1B9rTV7nLtouASzbJ6Rxq47GzVlCjPJtlnnvsdBPdyOmIzjLr8 41LLN6Z5l1rsYVY077A180UbkMIxNoZmHxvFxqG0qcx5GpgJFKzAz9ba/dTEaFVtvFflzTaX 32O6VkPwxQl4VcIgRigNDlXd2NUz5D48+K4tv9i9JY8djJ0kOX+IiAQZIFdygEmsG+CNmSsX T2QpmUlmlI4ssFiht3iKwqz+m51XME0NWIIvRoG/RHwHxFZLBSWGyLFW62LnmigHAAAAAAAA --------------ms060607070001040701060707-- From rick.taylor@cassidian.com Wed Apr 11 04:19:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6090511E808F for ; Wed, 11 Apr 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSwl2++RNidb for ; Wed, 11 Apr 2012 04:19:00 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id D740911E8075 for ; Wed, 11 Apr 2012 04:18:59 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 13:18:57 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 13:18:56 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 13:18:56 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 13:18:56 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 12:19:17 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 12:19:02 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X0PHKU4/z6gmsT3OlSRNhb1fW+wAA6y4g References: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local><90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 11 Apr 2012 11:19:17.0525 (UTC) FILETIME=[EF150450:01CD17D4] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.006 X-TM-AS-Result: No--22.589300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:19:01 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/11/2012 12:43 PM, Rick Taylor wrote: > > Isn't this very similar to what I proposed? DLEP-specific TLVs that > > state which DLEP order is contained in the message + extra TLVs to carry > > additional information? > > > > From my reading of draft-02, each 'order' carries some mandatory > > information, which can be placed in a single message-specific TLV, plus > > optional information, that can be carried in message-specific > > order-extension TLVs in the same message? By careful selection of > > extension type ids we can keep the sub-TLV concept. > > > > If I analyse the DLEP draft and assign some simple IDs, the orders are: > > > > KEY: > > 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type) > > 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY > > > > All address-block-TLVs use a of 6 and the MAC address of > > the neighbour. > > > > Please note the encoding of the extension types, i.e. the extension-id > > is constant, just the type-id changes (sort of covering the sub-TLV > > concept) >=20 > Why should we use different TLV types/exttypes for each of the orders? >=20 > One TLV-type for "Peer Type" (as an example) should be enough for all > orders used in DLEP. Then how do you handle the multiple optional parts of each DLEP order? Can you give an example please? I think I'm being stupid! > The same is true for every TLV used for the data necessary for any DLEP > order. >=20 > We should work on making the protocol SIMPLER without loosing > functionality, not making it even more complex. I completely agree. I was happy with sub-TLVs, but there has been some feedback from others that it doesn't match RFC5444 well. Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 04:38:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8721F8623 for ; Wed, 11 Apr 2012 04:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RErdTylh9KxE for ; Wed, 11 Apr 2012 04:38:06 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 86FA421F85EF for ; Wed, 11 Apr 2012 04:38:06 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHvsD-0007bT-9O; Wed, 11 Apr 2012 13:38:05 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHvsD-0004Zf-6Y; Wed, 11 Apr 2012 13:38:05 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 13:38:04 +0200 Message-ID: <4F856D1C.9070501@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 13:38:04 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local><90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060805080509050502020209" X-OriginalArrivalTime: 11 Apr 2012 11:38:04.0981 (UTC) FILETIME=[8F192650:01CD17D7] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 9702e826b3e1c879ad50220d9452afa5 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:38:07 -0000 This is a cryptographically signed message in MIME format. --------------ms060805080509050502020209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 01:19 PM, Rick Taylor wrote: >> Why should we use different TLV types/exttypes for each of the >> orders? >> >> One TLV-type for "Peer Type" (as an example) should be enough for >> all orders used in DLEP. > > Then how do you handle the multiple optional parts of each DLEP > order? RFC5444 allows you just to leave out any TLV you don't want to add. The=20 parser can recognize which TLVs are present without any overhead in the=20 message or signaling. > Can you give an example please? I think I'm being stupid! I just use TLV-types starting with 100 in the following simplified exampl= e: Message-TLVs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ORDER TLV: type=3D100, 1 byte binary value (order of this DLEP-message) PEER_TYPE TLV: type=3D101, 1-80 bytes binary value (text describing the p= eer) Address TLVs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IPV4 TLV: type 102, 5 bytes binary value (4 byte IPv4 address plus 1=20 byte prefix length) IPv6 TLV: type 103, 17 bytes binary value (16 byte IPv6 address plus 1=20 byte prefix length) Attached Peer Discovery Message: - ORDER TLV - PEER_TYPE TLV (optional) Peer Offer Message: - ORDER TLV - PEER_TYPE TLV (optional) Peer Update Message: - ORDER TLV - MAC address --- IPv4 TLV (optional) --- IPV6 TLV (optional) >> The same is true for every TLV used for the data necessary for any >> DLEP order. >> >> We should work on making the protocol SIMPLER without loosing >> functionality, not making it even more complex. > > I completely agree. I was happy with sub-TLVs, but there has been > some feedback from others that it doesn't match RFC5444 well. Yes. At the moment the complete RFC5444 generation of DLEP could be described = at: 1) Add static prefix 1 (packet header + message header before sequence number) 2) Add sequence number 3) Add static prefix (message header after sequence number and TLV header) and then add the Sub-TLVs. The receiver-part could be this: 1) Ignore static prefix 1 2) read sequence number 3) Ignore static prefix 2 4) read sub-TLVs Thats not really RFC5444. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060805080509050502020209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMTM4MDRaMCMGCSqGSIb3DQEJBDEWBBRgEvV2AV3F250YDS9g9cIHYtgJHzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBaJu00I8zmKQh1ZqxrOR5N3iQ+XaJTJSjOfJgtFzyxw31pIYp0qGEDJ7Q6qLDV HVkPhcS70pzidHQXxETasN/fVz9OrObDR+O6PpPtOPw4DApSx/R1Mfjh/fTxmx6ZHfvuh48X 9aBq17putI9AazVCGDNFepL4DYpBN4vi9aG+sZnktWfA1wM5vCemVifvdbmT3L38pGK8QFME vCcTMo/0hwrE6IKzq1DkCOUVhG2c9pNNZE58DGL9oBXcFScNdlvjn1Y6K0TdH/GXt+d2WYFr gydvaDe+nsR6YYr1XKF80B/pSOJ63yduqiDF2EHJhMorVAKdzmbgq+XrHbSqT7l4AAAAAAAA --------------ms060805080509050502020209-- From rick.taylor@cassidian.com Wed Apr 11 05:39:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B582E21F853A for ; Wed, 11 Apr 2012 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQPHJAQLhbB7 for ; Wed, 11 Apr 2012 05:39:06 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id C841A21F84DE for ; Wed, 11 Apr 2012 05:39:04 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 14:38:59 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 14:38:59 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:38:58 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:38:58 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 13:38:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 13:38:57 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X17Ma5FGv4qtpTX6+ZX/MVD58VQAB5NQg References: <7B31B0093014224A843C10C0CCE92AC1035ABD92@SUKNPT8106.cogent-dsn.local><90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 11 Apr 2012 12:38:44.0060 (UTC) FILETIME=[082889C0:01CD17E0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.007 X-TM-AS-Result: No--19.251200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:39:06 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/11/2012 01:19 PM, Rick Taylor wrote: > >> Why should we use different TLV types/exttypes for each of the > >> orders? > >> > >> One TLV-type for "Peer Type" (as an example) should be enough for > >> all orders used in DLEP. > > > > Then how do you handle the multiple optional parts of each DLEP > > order? >=20 > RFC5444 allows you just to leave out any TLV you don't want to add. The > parser can recognize which TLVs are present without any overhead in the > message or signaling. >=20 > > Can you give an example please? I think I'm being stupid! >=20 > I just use TLV-types starting with 100 in the following simplified > example: >=20 *** SNIP *** Aaah... I see now. This is very close to what I was proposing, but with a simplification (no extension types). I would add the Identification parts, etc. to the order TLV as well, just to save a bit of processing. I was just suggesting encoding some context into the id assignment. My concern would be that in the message-specific type range there are only 96 ids, and I can imagine radio vendors adding a *load* of extra metrics and consuming ids quickly... Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 05:53:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336AF21F8692 for ; Wed, 11 Apr 2012 05:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ+pGNvul5s7 for ; Wed, 11 Apr 2012 05:53:21 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D23621F86DD for ; Wed, 11 Apr 2012 05:53:21 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHx2w-00030m-Mh; Wed, 11 Apr 2012 14:53:14 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHx2w-0006fG-Jz; Wed, 11 Apr 2012 14:53:14 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:53:14 +0200 Message-ID: <4F857EB9.6040605@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 14:53:13 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020000030402040000000308" X-OriginalArrivalTime: 11 Apr 2012 12:53:14.0385 (UTC) FILETIME=[0EE99810:01CD17E2] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c51b770f3e2e0970392bce6b101b1534 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:53:22 -0000 This is a cryptographically signed message in MIME format. --------------ms020000030402040000000308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 02:38 PM, Rick Taylor wrote: > Aaah... I see now. This is very close to what I was proposing, but wit= h > a simplification (no extension types). I would add the Identification > parts, etc. to the order TLV as well, just to save a bit of processing.= > I was just suggesting encoding some context into the id assignment. I am not even sure why the "identification" and "version" TLV is a good=20 idea to include at all. In the current draft DLEP allows only a single connection between a=20 radio and a router and does not use the identification for anything. Why = do we need it? I see the reason for a "version" field in other protocols, but I think=20 we might not need it with RFC5444 as the transport format. As long as we = do not change the semantics of a DLEP order, we can easily add new TLVs=20 without breaking compatibility of old/new parsers/generators. If we=20 change the semantics, using a new "order" number might be easier (and=20 allow us to announce version incompatibilities on a message level!). > My concern would be that in the message-specific type range there are > only 96 ids, and I can imagine radio vendors adding a *load* of extra > metrics and consuming ids quickly... We could group TLVs which use the same format and semantics, which=20 should allow for a more efficient number space use. Example: TLV x "DATARATE": 8 bytes, measured in bits/s TLV x exttype 0: current outgoing datarate TLV x exttype 1: current incoming datarate TLV x exttype 2: maximum network datarate TLV x exttype 3: maximum radio hardware datarate (252 new datarates still left) TLV y "TRAFFIC": 8 bytes, measured in total bytes since connect TLV y exttype 0: outgoing traffic TLV y exttype 1: incoming traffic (254 new types of traffic counting still left) TLV z "PACKETS": 8 bytes, measured in packets since connect TLV z exttype 0: outgoing packets TLV z exttype 1: incoming packets TLV z exttype 2: retransmitted packets TLV z exttype 3: lost packets (252 new types of packet counting still left) If we start this way, most radio vendor extensions will already have=20 their TLV-type and might only need another extension type. If a radio vendor has lots of custom metrics, he might just grab a=20 single TLV and use the 256 extension type of the TLV for his "special=20 stuff". Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020000030402040000000308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMjUzMTNaMCMGCSqGSIb3DQEJBDEWBBTg3YbWg4LJDbc5vIukj0tPBHE3rjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAMufQRRKvzoWG+sjLOWmvkyxlHiz7bIMrMvPiTZrb4OHlKNnD9cbCJtnsJ2RhS EJSOtwCKeSeL9Zp8OFXfwpa82iyZc90zJmIqVj3eRv9Vy+PkEGdpMmqJROaUG1m1AvYJL1nM 68iHFmShNRgQv/W8ytLsqebkiNZcM0gi60RId11gEw+HLf+rWUvmjCtL8pgVrF1xTMqaIv4+ mQlJ+UohE9z/r3XVKKXWBwi5vjzqRTJeVuge27FIsbFrwyMaEVdOFH0NxULS6TTIvwoHE6+X Gp4kWpqrd5Yqero3hSa5HAdnWQvb3xWXGfJz5/deefod0FG/2slpRBIH9DZ4SDoDAAAAAAAA --------------ms020000030402040000000308-- From rick.taylor@cassidian.com Wed Apr 11 06:03:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0FC21F8610 for ; Wed, 11 Apr 2012 06:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2P8kvppVsCq for ; Wed, 11 Apr 2012 06:03:38 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2721F8592 for ; Wed, 11 Apr 2012 06:03:37 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 15:03:37 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 15:03:36 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:03:36 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:03:36 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:03:58 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 14:03:35 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X4kACRRgF56PfQf6YT3rheIuSfQAADVmw References: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 11 Apr 2012 13:03:58.0960 (UTC) FILETIME=[8F1BEF00:01CD17E3] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.007 X-TM-AS-Result: No--22.910500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:03:39 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/11/2012 02:38 PM, Rick Taylor wrote: > > Aaah... I see now. This is very close to what I was proposing, but with > > a simplification (no extension types). I would add the Identification > > parts, etc. to the order TLV as well, just to save a bit of processing. > > I was just suggesting encoding some context into the id assignment. >=20 > I am not even sure why the "identification" and "version" TLV is a good > idea to include at all. It is useful when there are connections from 1 router to multiple modems. It's not vital when using IP as you can use the src address to differentiate, but with USB/Firewire/etc. I'm not so sure... > In the current draft DLEP allows only a single connection between a > radio and a router and does not use the identification for anything. Why > do we need it? >=20 > I see the reason for a "version" field in other protocols, but I think > we might not need it with RFC5444 as the transport format. As long as we > do not change the semantics of a DLEP order, we can easily add new TLVs > without breaking compatibility of old/new parsers/generators. If we > change the semantics, using a new "order" number might be easier (and > allow us to announce version incompatibilities on a message level!). Yes, I agree with you, but I think the authors have the final say... > > My concern would be that in the message-specific type range there are > > only 96 ids, and I can imagine radio vendors adding a *load* of extra > > metrics and consuming ids quickly... >=20 > We could group TLVs which use the same format and semantics, which > should allow for a more efficient number space use. *** SNIP *** Yes, I was thinking along the same lines. I would like to somehow connect the status TLV to the understanding of received TLVs. Have a look at how SCTP chunk-types are numbered (RFC 6096). The high-bits of the id of a chunk specify how it should be reported in case of error or failure to parse. Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 06:20:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BFE21F85E3 for ; Wed, 11 Apr 2012 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmhv-BlPc9br for ; Wed, 11 Apr 2012 06:20:36 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A69121F85A1 for ; Wed, 11 Apr 2012 06:20:36 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHxTO-0004RK-Oh; Wed, 11 Apr 2012 15:20:34 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHxTO-0007QP-M1; Wed, 11 Apr 2012 15:20:34 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:20:34 +0200 Message-ID: <4F858521.5050205@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 15:20:33 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020500090904090500060508" X-OriginalArrivalTime: 11 Apr 2012 13:20:34.0528 (UTC) FILETIME=[E0838E00:01CD17E5] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 20b7ce53ca4bc5fdd0333c8362871ed3 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:20:38 -0000 This is a cryptographically signed message in MIME format. --------------ms020500090904090500060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 03:03 PM, Rick Taylor wrote: > It is useful when there are connections from 1 router to multiple > modems. It's not vital when using IP as you can use the src address to= > differentiate, but with USB/Firewire/etc. I'm not so sure... I agree, an identification for the radio side is usefull, but for this=20 we should have the MAC address of the radio. If the radio knows (or can=20 calculate) the MAC of every neighbor, it should also know its own MAC. We could put the MAC of the radio as the "originator address" RFC5444=20 message header field in each DLEP message. No need for a TLV of its own. It would still be transport independent (USB/Firefire/Ethernet/...), not = being used to address the radio, just as a 6 Byte unique identification. >> In the current draft DLEP allows only a single connection between a >> radio and a router and does not use the identification for anything. > Why >> do we need it? >> >> I see the reason for a "version" field in other protocols, but I think= >> we might not need it with RFC5444 as the transport format. As long as > we >> do not change the semantics of a DLEP order, we can easily add new > TLVs >> without breaking compatibility of old/new parsers/generators. If we >> change the semantics, using a new "order" number might be easier (and >> allow us to announce version incompatibilities on a message level!). > > Yes, I agree with you, but I think the authors have the final say... I would still like to get an idea what kind of behavior change the=20 protocol should support. If we can support the same thing without a=20 mandatory version field, we should consider dropping it. >>> My concern would be that in the message-specific type range there > are >>> only 96 ids, and I can imagine radio vendors adding a *load* of > extra >>> metrics and consuming ids quickly... >> >> We could group TLVs which use the same format and semantics, which >> should allow for a more efficient number space use. > > *** SNIP *** > > Yes, I was thinking along the same lines. I would like to somehow > connect the status TLV to the understanding of received TLVs. Have a > look at how SCTP chunk-types are numbered (RFC 6096). The high-bits of= > the id of a chunk specify how it should be reported in case of error or= > failure to parse. You mean using a bit in the extension type to tell the parser which TLVs = are mandatory to understand the order and which not? So it can say "oh,=20 don't worry about this one, its not mandatory?" (metric TLVs would be all non-mandatory I think) Maybe we can split the extension types used by DLEP-specific TLVs into=20 ranges... something like 0-224: TLV is not mandatory to understand DLEP order 225-255: TLV is mandatory to understand DLEP order Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020500090904090500060508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMzIwMzNaMCMGCSqGSIb3DQEJBDEWBBT3pzfHSUrTAAns6TExsIi7XUW5/jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQA3LvKprffR06dowGBqxl6B9oG04jeVsacr0sB1iYDyoclWpN3toXrp0Uj9sa9J wS+0PnRkt8NmmeGrVLLFAOkBABYCz3ShGgrdsWdmXZmQHaJzQ7yZPU0f85JJVtI6Rv7/lLR4 GG9sW52/AdKzRtm3D2Mxg2JFVpqCN0PJGpw3DkkYfrwD6MUU+pWnHY/jXHWPrBXCrJNsDuTY VrFFgQ0cshLTyFgOQ/j9RCCGbyOjpthgSGz6AS5afn9W5GabAFWgBt54aSi4cwdfJ7WxWfoP eIr5dnQlarIrIDgNFkS9/SA1fUYzCOJygbV75uMB85KjsAYLNnjKMRpkOLtZYmhkAAAAAAAA --------------ms020500090904090500060508-- From rick.taylor@cassidian.com Wed Apr 11 06:32:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA321F8523 for ; Wed, 11 Apr 2012 06:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAD_CREDIT=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT5qC1NDq6Iz for ; Wed, 11 Apr 2012 06:32:05 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 934AF11E8138 for ; Wed, 11 Apr 2012 06:31:58 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 11 Apr 2012 15:31:55 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 15:31:57 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:31:57 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:31:56 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:32:19 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 14:31:55 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X5gab/mVQW1c2SmqavENgu4z0NQAAJ0CA References: <90325FB5-A237-4621-A5BF-9B77A6E7E869@cisco.c om> <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 11 Apr 2012 13:32:19.0734 (UTC) FILETIME=[84D97360:01CD17E7] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.007 X-TM-AS-Result: No--26.117800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:32:06 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/11/2012 03:03 PM, Rick Taylor wrote: > > It is useful when there are connections from 1 router to multiple > > modems. It's not vital when using IP as you can use the src address to > > differentiate, but with USB/Firewire/etc. I'm not so sure... >=20 > I agree, an identification for the radio side is usefull, but for this > we should have the MAC address of the radio. If the radio knows (or can > calculate) the MAC of every neighbor, it should also know its own MAC. >=20 > We could put the MAC of the radio as the "originator address" RFC5444 > message header field in each DLEP message. No need for a TLV of its own. >=20 > It would still be transport independent (USB/Firefire/Ethernet/...), not > being used to address the radio, just as a 6 Byte unique identification. >=20 > >> In the current draft DLEP allows only a single connection between a > >> radio and a router and does not use the identification for anything. > > Why > >> do we need it? > >> > >> I see the reason for a "version" field in other protocols, but I think > >> we might not need it with RFC5444 as the transport format. As long as > > we > >> do not change the semantics of a DLEP order, we can easily add new > > TLVs > >> without breaking compatibility of old/new parsers/generators. If we > >> change the semantics, using a new "order" number might be easier (and > >> allow us to announce version incompatibilities on a message level!). > > > > Yes, I agree with you, but I think the authors have the final say... >=20 > I would still like to get an idea what kind of behavior change the > protocol should support. If we can support the same thing without a > mandatory version field, we should consider dropping it. I agree the version is not truly needed, but I know people get attached to version numbers in protocols... > >>> My concern would be that in the message-specific type range there > > are > >>> only 96 ids, and I can imagine radio vendors adding a *load* of > > extra > >>> metrics and consuming ids quickly... > >> > >> We could group TLVs which use the same format and semantics, which > >> should allow for a more efficient number space use. > > > > *** SNIP *** > > > > Yes, I was thinking along the same lines. I would like to somehow > > connect the status TLV to the understanding of received TLVs. Have a > > look at how SCTP chunk-types are numbered (RFC 6096). The high-bits of > > the id of a chunk specify how it should be reported in case of error or > > failure to parse. >=20 > You mean using a bit in the extension type to tell the parser which TLVs > are mandatory to understand the order and which not? So it can say "oh, > don't worry about this one, its not mandatory?" Yes. > (metric TLVs would be all non-mandatory I think) Yes. I was thinking particularly about the credit-windowing TLVs. Draft-02 is still unclear on the Status TLV contents when credit-windowing is desired by a router, but unsupported by a modem. I.e. the peering can happen, but no credit-windowing allowed. > Maybe we can split the extension types used by DLEP-specific TLVs into > ranges... something like >=20 > 0-224: TLV is not mandatory to understand DLEP order > 225-255: TLV is mandatory to understand DLEP order Only for extension types? Why not for all message-specific TLV types? How about classifying as: MUST understand (kill association), SHOULD understand (status code response), MAY understand (standard-specified value, but no status response required), OPTIONAL (must have extension type?) Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 06:39:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E8111E8151 for ; Wed, 11 Apr 2012 06:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.049, BAD_CREDIT=0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhTTDclIGhd9 for ; Wed, 11 Apr 2012 06:39:52 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1011E8153 for ; Wed, 11 Apr 2012 06:39:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHxm3-0005EA-IV; Wed, 11 Apr 2012 15:39:51 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHxm3-0007uR-Fo; Wed, 11 Apr 2012 15:39:51 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:39:51 +0200 Message-ID: <4F8589A6.3030305@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 15:39:50 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.l ocal> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010607050902060307020500" X-OriginalArrivalTime: 11 Apr 2012 13:39:51.0341 (UTC) FILETIME=[920735D0:01CD17E8] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:39:53 -0000 This is a cryptographically signed message in MIME format. --------------ms010607050902060307020500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 03:31 PM, Rick Taylor wrote: > Yes. > >> (metric TLVs would be all non-mandatory I think) > > Yes. I was thinking particularly about the credit-windowing TLVs. > Draft-02 is still unclear on the Status TLV contents when > credit-windowing is desired by a router, but unsupported by a modem. > I.e. the peering can happen, but no credit-windowing allowed. > >> Maybe we can split the extension types used by DLEP-specific TLVs into= >> ranges... something like >> >> 0-224: TLV is not mandatory to understand DLEP order >> 225-255: TLV is mandatory to understand DLEP order > > Only for extension types? Why not for all message-specific TLV types? > > How about classifying as: MUST understand (kill association), SHOULD > understand (status code response), MAY understand (standard-specified > value, but no status response required), OPTIONAL (must have extension > type?) Yes, something like this is missing in RFC 5444. Hmm, I just noticed something interesting... there are two unused bits=20 in the TLV header itself. Maybe this would be something interesting to=20 discuss as an extension of RFC5444. It would be a much cleaner solution than to hack something into the=20 extension types or message-tlv types. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010607050902060307020500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMzM5NTBaMCMGCSqGSIb3DQEJBDEWBBT2g3b/ZnKpcWOjHlRSUQ+0D86ztTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAomFgKInBQtj69e4xnBFq3tzSi4Afh9+Ndyydzq12f7B+QO4glRcmKJQrDFkUb wfBLmJJkBtM52YHxWJM3ALnBv00G+5o4skTTN3No2mhH2T/B3PQjbggT+gvCQkS8e7RWDyDG eB6m2FgoI9dKezEOcmMYBbbEzXU8UzwFNkVCVnZsC5/z4+IgcZiLofW3YihTxKhHdU9A1GO1 /O3K5GdMsn1VZ3P7Y6TvKGoQZ44WAixCGre8ZUf6xzoAmo9heN37wd02UgyasUBH36kY/Uhk zkIqHYGsrRe3eoLjgnoYQrQOS4GdwF0G8L6lKx7hG+Qygn+ATQ5pZkYGZL4v/BmEAAAAAAAA --------------ms010607050902060307020500-- From rick.taylor@cassidian.com Wed Apr 11 06:48:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7541111E8161 for ; Wed, 11 Apr 2012 06:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAD_CREDIT=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkxS-ogN0Dum for ; Wed, 11 Apr 2012 06:48:39 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7411E8160 for ; Wed, 11 Apr 2012 06:48:38 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 11 Apr 2012 15:48:37 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 11 Apr 2012 15:48:36 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:48:36 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:48:36 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 14:48:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Apr 2012 14:48:35 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10364324C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X6NvNfCtt7c6QSf6YQc/9wZY4bwAAE6/g References: <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 11 Apr 2012 13:48:59.0076 (UTC) FILETIME=[D880F040:01CD17E9] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18830.007 X-TM-AS-Result: No--25.677400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:48:39 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > On 04/11/2012 03:31 PM, Rick Taylor wrote: > > Yes. > > > >> (metric TLVs would be all non-mandatory I think) > > > > Yes. I was thinking particularly about the credit-windowing TLVs. > > Draft-02 is still unclear on the Status TLV contents when > > credit-windowing is desired by a router, but unsupported by a modem. > > I.e. the peering can happen, but no credit-windowing allowed. > > > >> Maybe we can split the extension types used by DLEP-specific TLVs into > >> ranges... something like > >> > >> 0-224: TLV is not mandatory to understand DLEP order > >> 225-255: TLV is mandatory to understand DLEP order > > > > Only for extension types? Why not for all message-specific TLV types? > > > > How about classifying as: MUST understand (kill association), SHOULD > > understand (status code response), MAY understand (standard-specified > > value, but no status response required), OPTIONAL (must have extension > > type?) >=20 > Yes, something like this is missing in RFC 5444. >=20 > Hmm, I just noticed something interesting... there are two unused bits > in the TLV header itself. Maybe this would be something interesting to > discuss as an extension of RFC5444. >=20 > It would be a much cleaner solution than to hack something into the > extension types or message-tlv types. >=20 Yes... but there was some comment on this list about not wanting to update RFC5444 (yet). And also, how do you connect that the status code response? A 'standard' RFC5444 status TLV? I wanted at some point to suggest an RFC5444 compliant way of handling ACKs, a packet-TLV with the ackno for the received packet seqno, but I need to concentrate on DLEP at the moment. Rick Taylor From henning.rogge@fkie.fraunhofer.de Wed Apr 11 06:55:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F8311E8182 for ; Wed, 11 Apr 2012 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DqqWZbW0vvG for ; Wed, 11 Apr 2012 06:55:32 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id BCDF511E815A for ; Wed, 11 Apr 2012 06:55:31 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SHy1A-00066d-Uu; Wed, 11 Apr 2012 15:55:28 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SHy1A-0008SE-SB; Wed, 11 Apr 2012 15:55:28 +0200 Received: from [128.7.5.36] ([128.7.5.36]) by mailserv1.lorien.fkie.fgan.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 15:55:28 +0200 Message-ID: <4F858D49.3010503@fkie.fraunhofer.de> Date: Wed, 11 Apr 2012 15:55:21 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rick Taylor References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> <7B31B0093014224A843C10C0CCE92AC10364324C@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10364324C@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060104020207020907080804" X-OriginalArrivalTime: 11 Apr 2012 13:55:28.0722 (UTC) FILETIME=[C0C03320:01CD17EA] X-Virus-Scanned: yes (ClamAV 0.97.3/14770/Wed Apr 11 00:28:18 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3323e5da4f65bad0ae85b235b9833247 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:55:32 -0000 This is a cryptographically signed message in MIME format. --------------ms060104020207020907080804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/11/2012 03:48 PM, Rick Taylor wrote: > Yes... but there was some comment on this list about not wanting to > update RFC5444 (yet). And if there will be an update some days, it should be forward and=20 backward compatible with the current data format of RFC 5444. > And also, how do you connect that the status code > response? A 'standard' RFC5444 status TLV? A status TLV might be a good standard addition to the TLVs, both on=20 packet and on message level. But need more thought and input for the=20 semantics of a TLV like this. At the moment DLEP would be the only use-case, OLSR/NHDP/DYMO don't need = status updates. DLEP needs it for the active parts of the draft (request link=20 characteristics, credit scheme). > I wanted at some point to suggest an RFC5444 compliant way of handling > ACKs, a packet-TLV with the ackno for the received packet seqno, but I > need to concentrate on DLEP at the moment. Maybe a "Reference" TLV, which contains the sequence number it=20 corresponds to as a 2-byte value? Could work both on packet level (for=20 link ACKs) and message level (for DLEP). Of course if a protocol wants to use this TLV, it has to activate the=20 sequence numbers on the packet/message level. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060104020207020907080804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTExMzU1MjZaMCMGCSqGSIb3DQEJBDEWBBRsNVltGGiK3F0VGZBfhTXeC3Lh2jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAfDGk+6XwKAIz5de46s/FNe0BmGH7pN8nXEo7GGYPywJd5VhzuqgA0EHmDTs6W RSCy+5K7hvIx4T5qnbZfeFP8+3fD+FrpD1BRbQheqKajRTTVvmoRR9z/m/lbMIC9bNgt6dQY YBPC3LBlqNhQReNHPWJj0golTw2pbfL1E5gvV94K2o8oLPNNRKGSAAR32MUZl3V2MQwbXlBp tTzdapx5uXYOlKpid4qLpnSGsaObrvHM9/E8jcFqsliFV2viAPXx3WKhoIMDg5gONUh0OV4M Flrq75Z6VbJTFnt8Lpfh8j/zS3KqwGOdvne0ubVpKWbKNbn7c6RYURN4mbOf0glKAAAAAAAA --------------ms060104020207020907080804-- From sratliff@cisco.com Sat Apr 14 19:05:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFD221F8697 for ; Sat, 14 Apr 2012 19:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kY7mc6RrbfH for ; Sat, 14 Apr 2012 19:05:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E279721F867E for ; Sat, 14 Apr 2012 19:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3445; q=dns/txt; s=iport; t=1334455540; x=1335665140; h=message-id:from:to:mime-version:subject:date:references; bh=xCZjLU9n3SgYjFDd54rbjO68UomimRKalhDJHCePLrU=; b=TcGZaH3O46/Xe7xe06Evc0WHfNzUWQZ/FvXvZqOaB5J4ewgGpQJRZeww 6RVK69RFy375liA5/fze8uAaFO/5+3Sjc6ot//gqv+FQgSsEJoZMBe+B3 AaD/fAVIcmx8TPaS+kpC4NdeFzHfghNm0lpvE7G8J1sxaaQ5cqog/nvT4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFgsik+tJXHB/2dsb2JhbABEgkayRYEHggkBAQEDARIBawsPDQMBAi9PCAYTIodnBZkGnwyQZmMElW2OTIFpgwM X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208,217";a="71738949" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 15 Apr 2012 02:05:39 +0000 Received: from rtp-sratliff-8717.cisco.com (rtp-sratliff-8717.cisco.com [10.116.179.216]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3F25cvT018583 for ; Sun, 15 Apr 2012 02:05:39 GMT Message-Id: From: Stan Ratliff To: "manet@ietf.org IETF" Content-Type: multipart/alternative; boundary=Apple-Mail-40--333946501 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Apr 2012 22:05:38 -0400 References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 02:05:40 -0000 --Apple-Mail-40--333946501 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All, Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day period. 2 weeks of that period have already passed, so OLSRv2 has been moved to WGLC with the last call period ending May 10, 2012. Regards, Stan Begin forwarded message: > From: IETF Secretariat > Date: April 14, 2012 10:00:57 PM EDT > > Subject: State changed for draft draft-ietf-manet-olsrv2 > > The state of document draft-ietf-manet-olsrv2 has been updated. See > more information below. > > Previous state: WG Document > Current state: In WG Last Call > Transition date: 2012-04-14 19:00 > Author of the change: Stan Ratliff > > Comment: > A 30-day WGLC was agreed to at IETF 83. WGLC will end May 10, 2012. --Apple-Mail-40--333946501 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
From: = IETF Secretariat <ietf-secretariat-reply@iet= f.org>
Date: April 14, 2012 10:00:57 PM = EDT

Subject: State changed for draft = draft-ietf-manet-olsrv2

The state of document = draft-ietf-manet-olsrv2 has been updated. See more information = below.

Previous state: WG Document
Current state: In WG Last = Call
Transition date: 2012-04-14 19:00
Author of the change: Stan = Ratliff

Comment:
A 30-day WGLC was agreed to at IETF 83. WGLC = will end May 10, = 2012.

= --Apple-Mail-40--333946501-- From mom-tigy@hotmail.com Sun Apr 15 01:46:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2121F876C for ; Sun, 15 Apr 2012 01:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.244 X-Spam-Level: **** X-Spam-Status: No, score=4.244 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_99=3.5, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+ULr4bRqvmx for ; Sun, 15 Apr 2012 01:46:05 -0700 (PDT) Received: from snt0-omc1-s17.snt0.hotmail.com (snt0-omc1-s17.snt0.hotmail.com [65.55.90.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4B021F876A for ; Sun, 15 Apr 2012 01:46:05 -0700 (PDT) Received: from SNT122-DS8 ([65.55.90.9]) by snt0-omc1-s17.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 Apr 2012 01:46:04 -0700 X-Originating-IP: [41.223.162.59] X-Originating-Email: [mom-tigy@hotmail.com] Message-ID: From: mom tigy To: Date: Sun, 15 Apr 2012 11:45:49 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CD1AFD.4DD47630" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-OriginalArrivalTime: 15 Apr 2012 08:46:04.0853 (UTC) FILETIME=[31799650:01CD1AE4] Subject: [manet] LAR Protocol Request X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 08:46:06 -0000 ------=_NextPart_000_0006_01CD1AFD.4DD47630 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I=92m looking for ns2 code for LAR protocol for my research. Thank you, ------=_NextPart_000_0006_01CD1AFD.4DD47630 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,
    I=92m looking for ns2 code for LAR protocol for = my=20 research.

Thank you,
------=_NextPart_000_0006_01CD1AFD.4DD47630-- From abdussalambaryun@gmail.com Mon Apr 16 08:12:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8621F86EE for ; Mon, 16 Apr 2012 08:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sk8LYuSC9Qx for ; Mon, 16 Apr 2012 08:12:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6291521F86EC for ; Mon, 16 Apr 2012 08:12:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4066364vbb.31 for ; Mon, 16 Apr 2012 08:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y2+NhxrkCgMRPWJtd4sooDnqK8NpTza8Xq5n1s3GQSg=; b=OkNrGVM9mOxngk3NKc4GAn/ZLq2/mwjws3xmeuAsBVpG1hAWr6yt5eeHV1WGQNW85E NRyQ0nblm5E0VwlYp+f5BbPBqKcRHI9Ro5BcHnY4G0SVQ+AbgvlTln+inqIK1js+uiHc O14eUUPHpqwtdZVW7yb9CxqyFKF0mLC70mP1Ni7gRlbBLSyK0DKmiXQBvZ5TIsk7lVls rzI69zcsGb1UI3C2Zf3ZM8w95VVZd63gCL8GVwrfbxgMYS0aySlg3X+QhN9CCBgq6a7R 8noguuP97rHzbTeiOTVNkGZq+JRMCWlgUEXZSnBHy3pqOzqqI0l/cCm6ZivSoZKC51Md dK+g== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr6737222vcw.20.1334589161695; Mon, 16 Apr 2012 08:12:41 -0700 (PDT) Received: by 10.220.7.143 with HTTP; Mon, 16 Apr 2012 08:12:41 -0700 (PDT) Date: Mon, 16 Apr 2012 17:12:41 +0200 Message-ID: From: Abdussalam Baryun To: pars.mutaf@gmail.com, manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 16 Apr 2012 09:27:56 -0700 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:12:43 -0000 Hi Pars, I think we cannot replace MANET and its techniques, we only may improve. There is no simpler than MANET. The points mentioned by Cedric, Dan, and Henning Rogge are very important, and it seems that your system is not fullfilling all requirements for public safety. The MANET solution is the best alternative for the reasons poited by them and for others: - Ad hoc networks are more flexible for users to connect to different networks systems. - Your network solution is vulnerable in disasters, because is a centralized network using satellite systems and ballons managed by centre administrators. - Using satellites as ad hoc nodes and/or ballons as ad hoc nodes is the best solution you may misunderstood. - If one node is alive, in an ad hoc network still he will be able to search all networks reachable and available at any time as long the battery is alive. On the other hand, if satellite or ballon transcievers are unreachable the one survivale will not be able to search for another network only if allowed by administrators. - In MANET it gives social service opportunity (rescue family/community system) to people to rescue theirselves without waiting (e.g. if not available, usually happens because of response delays) for a ballon/satellite connection or an agency that administrates such facilities. -There are many disaster recovery practical real-life reasons that recommend no better solution than MANET and then the assistance of other wireless Ad Hoc networks. Regards Abdussalam Baryun ICRC, University of Glamorgan, UK From pars.mutaf@gmail.com Mon Apr 16 08:54:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4B21F866A for ; Mon, 16 Apr 2012 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P25H215P1rr6 for ; Mon, 16 Apr 2012 08:54:08 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFF521F866C for ; Mon, 16 Apr 2012 08:54:08 -0700 (PDT) Received: by yenm5 with SMTP id m5so2880900yen.31 for ; Mon, 16 Apr 2012 08:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A35X2f8ApvWgqjE6LmD9MiKLuvczuT4kD2QG4kapEz4=; b=BJEXQvtE2cB9vYxwelFH+hnjHAlfkYh0TaE7b6QC1/KeN6TzUgnFPMQwPiY3OqL2hj Ly51KJP7SBb+qGBEXp+3UMRylWZP/Xo1/AJXN83Qpd/yEdLo743Fr3gkxXkRIRtC9c6X BCzgxiSpeuWwduia2If0SagjzNuJbioqNw5dWmZzS6ouSd4sfAODbbYsA+rIziXZDAEM povr2kFHdkavrEVnhJwVQSoOVbasYRqofc0P0kCrd8UtXHQrnWEbwMWT+r6XtYOAF9Ds W+TJCq6c92DayOl2k0XHgnGdfLGYdDmNpyUrTX0WAvedZ34/cdQHn7rl1gXb5zpLfQWB Ssyg== MIME-Version: 1.0 Received: by 10.60.20.100 with SMTP id m4mr17314932oee.10.1334591647796; Mon, 16 Apr 2012 08:54:07 -0700 (PDT) Received: by 10.182.30.193 with HTTP; Mon, 16 Apr 2012 08:54:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Apr 2012 18:54:07 +0300 Message-ID: From: Pars Mutaf To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=e89a8fb1ef4c16505404bdcdd5c1 X-Mailman-Approved-At: Mon, 16 Apr 2012 09:27:56 -0700 Cc: manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:54:09 -0000 --e89a8fb1ef4c16505404bdcdd5c1 Content-Type: text/plain; charset=ISO-8859-1 Hi I am not on the MANET list. I don't know if the list will accept my e-mail. Please see inline: On Mon, Apr 16, 2012 at 6:12 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Pars, > > I think we cannot replace MANET and its techniques, we only may > improve. There is no simpler than MANET. The points mentioned by > Cedric, Dan, and Henning Rogge are very important, and it seems that > your system is not fullfilling all requirements for public safety. The > MANET solution is the best alternative for the reasons poited by them > and for others: > > - Ad hoc networks are more flexible for users to connect to different > networks systems. > - Your network solution is vulnerable in disasters, because is a > centralized network using satellite systems and ballons managed by > centre administrators. > - Using satellites as ad hoc nodes and/or ballons as ad hoc nodes is > the best solution you may misunderstood. > - If one node is alive, in an ad hoc network still he will be able to > search all networks reachable and available at any time as long the > battery is alive. On the other hand, if satellite or ballon > transcievers are unreachable the one survivale will not be able to > search for another network only if allowed by administrators. > Several nodes that are not in reach of others will not be able to call using the MANET solution. The balloon can save all of them. > - In MANET it gives social service opportunity (rescue > family/community system) to people to rescue theirselves without > waiting (e.g. if not available, usually happens because of response > delays) for a ballon/satellite connection or an agency that > administrates such facilities. > This is the only valid point against my proposal so far IMO (provided that MANET works - see the above comments). But I think we can trust the rescuers. We need them for other things than communication as well. Thanks, Pars -There are many disaster recovery practical real-life reasons that > recommend no better solution than MANET and then the assistance of > other wireless Ad Hoc networks. > > Regards > > Abdussalam Baryun > ICRC, University of Glamorgan, UK > --e89a8fb1ef4c16505404bdcdd5c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0

I am not on the MANET list. I don't know if th= e list will accept my e-mail.

Please see inline:= =A0

On Mon, Apr 16, 2012 at 6:12 PM, Abdu= ssalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Pars,

I think we cannot replace MANET and its techniques, we only may
improve. There is no simpler than MANET. The points mentioned by
Cedric, Dan, and Henning Rogge are very important, and it seems that
your system is not fullfilling all requirements for public safety. The
MANET solution is the best alternative for the reasons poited by them
and for others:

- Ad hoc networks are more flexible for users to connect to different
networks systems.
- Your network solution is vulnerable in disasters, because is a
centralized network using satellite systems and ballons managed by
centre administrators.
- Using satellites as ad hoc nodes and/or ballons as ad hoc nodes is
the best solution you may misunderstood.
- If one node is alive, in an ad hoc network still he will be able to
search all networks reachable and available at any time as long the
battery is alive. On the other hand, if satellite or ballon
transcievers are unreachable the one survivale will not be able to
search for another network only if allowed by administrators.

Several nodes that are not in reach of others will n= ot be able to=A0
call using the MANET solution.=A0

The balloon can save all of them.=A0

=A0
- In MANET it gives social service opportunity (rescue
family/community system) to people to rescue theirselves without
waiting (e.g. if not available, usually happens because of response
delays) for a ballon/satellite connection or an agency that
administrates such facilities.

This is = the only valid point against my proposal so far IMO (provided that MANET wo= rks - see the above comments). But I think=A0we can trust the rescuers. We = need them for other things
than communication as well.=A0
=A0
Thanks,=A0

Pars


Abdussalam Baryun
ICRC, University of Glamorgan, UK

--e89a8fb1ef4c16505404bdcdd5c1-- From henning.rogge@fkie.fraunhofer.de Wed Apr 18 01:54:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C221F863D for ; Wed, 18 Apr 2012 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 872FumwSpE8S for ; Wed, 18 Apr 2012 01:54:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 204FD21F8617 for ; Wed, 18 Apr 2012 01:54:43 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SKQet-0005XM-KJ; Wed, 18 Apr 2012 10:54:39 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SKQet-0006k3-Hf; Wed, 18 Apr 2012 10:54:39 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Apr 2012 10:54:39 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 10:54:39 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 10:54:38 +0200 Message-ID: <4F8E8149.7040201@fkie.fraunhofer.de> Date: Wed, 18 Apr 2012 10:54:33 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030402020501060403080400" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 18 Apr 2012 08:54:39.0284 (UTC) FILETIME=[E356C740:01CD1D40] X-Virus-Scanned: yes (ClamAV 0.97.3/14812/Wed Apr 18 04:13:55 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:54:54 -0000 --------------ms030402020501060403080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/15/2012 04:05 AM, Stan Ratliff wrote: > All, > > Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day > period. 2 weeks of that period have already passed, so OLSRv2 has been > moved to WGLC with the last call period ending May 10, 2012. I have a question about the Local Attached Network Set (section 7.2) and = its usage during routing. Attached networks have both a link metric and a 'hopcount distance'. Do=20 I understand the current draft correct that the metric is used for=20 selecting the attached network the node will route to (there can be=20 multiple nodes with the same attached network!) and that the hopcount=20 field is just used to set the distance field in the kernel routing table?= Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030402020501060403080400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MTgwODU0MzZaMCMGCSqGSIb3DQEJBDEWBBQFQqxASUNb1XyQrou8IIOrJyHBjDBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCYhr48ZlfqJJCZXjrbJjggtekUdz9BlMLdLWrfDUMvT4QJTgde90CCijz752vv 6JkimnkNhnRX4oey79riV5NXVlfi4QZKaGFQ5mULBsvF8nyIPZaySHXjM8VPQbIXsIraf2Ld irawTDLRhwYUlDMsFNl8BbWVqnA5hHbLHoIMmnG7J5hI9WCan7/mleHalsC0TszakErZMASF h2nMvFqDLngRe5wiOWc+jrdgExTGxWnly9WicLd/YaM+t9XGJbA15cNKKT+FICp1yUsf90K+ F9LCw3y2ki6/w5szpyDF4cq2I8LeTxlHardEL2U1Omri0PiexiygowPsk9ehphIXAAAAAAAA --------------ms030402020501060403080400-- From ulrich@herberg.name Wed Apr 18 15:22:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E266911E808C for ; Wed, 18 Apr 2012 15:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxy+D7dJF8Ay for ; Wed, 18 Apr 2012 15:22:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 356EA11E8089 for ; Wed, 18 Apr 2012 15:22:50 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7427313pbb.31 for ; Wed, 18 Apr 2012 15:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Xg2zXsqosedj2cbSsx+dPYz04wnDKPa7WlbzakInRro=; b=y+g3VmzzVKRJw37gVSKep0kAatm0NI5Mu9QKv/lLH7QurLLOQPlvblmyz74ag6FRVR hp09kO/NuxvHDpOElj3sDW6NFqVDeKYt4EQPVIU2PNvncwU+sr7DAVExb4rj7sCL/mFm 1OY2SDyhmt9XdXmFRkD/PYJQKtzNmqEgSzAgk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Xg2zXsqosedj2cbSsx+dPYz04wnDKPa7WlbzakInRro=; b=GrCjAEzYgxHC9SXlaqI0Zhuz07Hw+qZeMdy6xYY0JlyHCPICmMJDDQqljVjbdAUTMD WhwT4jTDczWdoHqjK0dyv1Qd3oEjMHTD5IStmDkm/QRklv3Ypsu/FoTM4UT81WV0Qr19 MvYBnHONIrblIvz0L/Tzciq32KXofVbEIMXb4QZqIKtEvF2fQoXNIZkw32e+ajieMn/M JxJCWOC2Q3EyMPdqaPIbb1+IMDLgV61s614L89PoaPt4/MowYHyCK5d/2yiRWLDPuAxP QCzrWlF3O/KgckipnPW+Gp2BWB+i0beTOT7QYCA+NJLcEn1V8Jh/iDrN8xB/NeDkadir qh3w== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr9846243pbc.35.1334787769792; Wed, 18 Apr 2012 15:22:49 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Wed, 18 Apr 2012 15:22:49 -0700 (PDT) In-Reply-To: <4F8E8149.7040201@fkie.fraunhofer.de> References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> <4F8E8149.7040201@fkie.fraunhofer.de> Date: Wed, 18 Apr 2012 15:22:49 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk2R8Rw6DdnvxDsH5e7J+D9zekDNG5+knbk0z/vFcLKI7oc3jDIKsvu9wYkH1DMfjf3w/GA Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 22:22:55 -0000 Hi Henning, I think the answer to your question is "yes" :-) Ulrich On Wed, Apr 18, 2012 at 1:54 AM, Henning Rogge wrote: > On 04/15/2012 04:05 AM, Stan Ratliff wrote: >> >> All, >> >> Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day >> period. 2 weeks of that period have already passed, so OLSRv2 has been >> moved to WGLC with the last call period ending May 10, 2012. > > > I have a question about the Local Attached Network Set (section 7.2) and = its > usage during routing. > > Attached networks have both a link metric and a 'hopcount distance'. Do I > understand the current draft correct that the metric is used for selectin= g > the attached network the node will route to (there can be multiple nodes > with the same attached network!) and that the hopcount field is just used= to > set the distance field in the kernel routing table? > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From Chris.Dearlove@baesystems.com Thu Apr 19 01:51:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755CB21F85C4 for ; Thu, 19 Apr 2012 01:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv7PQgz6L+3v for ; Thu, 19 Apr 2012 01:51:10 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8422521F84C9 for ; Thu, 19 Apr 2012 01:51:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208,217";a="232428958" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Apr 2012 09:51:08 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3J8p76h002672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 09:51:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 09:51:07 +0100 From: "Dearlove, Christopher (UK)" To: Pars Mutaf , "manet@ietf.org" Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0W2mYq1o/FZDOOTkG3jDd6meSHmgHLrUPg Date: Thu, 19 Apr 2012 08:51:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DCE81GLKXM0002VGREENLNKn_" MIME-Version: 1.0 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 08:51:14 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DCE81GLKXM0002VGREENLNKn_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm not sure if I should really take this seriously, but consider the events of 7th July 2005 on the London Underground and ask (a) would a MANET have been useful? and (b) would a balloon have been useful? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars Mutaf Sent: 10 April 2012 06:26 To: manet@ietf.org Subject: [manet] Replacing MANET with a simple solution *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DCE81GLKXM0002VGREENLNKn_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I’m not sure if I should really take this seriously, but consider the events of 7th July 2005 on the London Underground and ask (a) would a MANET have been useful? and (b) would a balloon have been useful?

 

--

Christopher Dearlove

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

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

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars Mutaf
Sent: 10 April 2012 06:26
To: manet@ietf.org
Subject: [manet] Replacing MANET with a simple solution

 

 

*** WARNING ***

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

In a disaster scenario, the base stations are down, everything is broken. 

 

Just find a big balloon, attach the antennas to it, send it to the air with an electric cable connected to a power generator on the ground. 

 

You have a base station in 1 hour.

 

Why spend millions of dollars/euros for this MANET effort?

 

Pars Mutaf

Asst. Prof.


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DCE81GLKXM0002VGREENLNKn_-- From Chris.Dearlove@baesystems.com Thu Apr 19 03:04:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9221F8568 for ; Thu, 19 Apr 2012 03:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAD_CREDIT=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSb+SHb2xGXG for ; Thu, 19 Apr 2012 03:03:53 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5FD21F84A7 for ; Thu, 19 Apr 2012 03:03:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,445,1330905600"; d="scan'208";a="232465289" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Apr 2012 11:03:43 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3JA3eLU027230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 11:03:40 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 11:03:40 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Rick Taylor Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X6KBs5upA4BdvS5eDmXecFJctNwGKYYiA Date: Thu, 19 Apr 2012 10:03:39 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1035F1C5D@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> <4F8589A6.3030305@fkie.fraunhofer.de> In-Reply-To: <4F8589A6.3030305@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 10:04:00 -0000 There were discussions about encoding optional/mandatory information in wha= t became RFC 5444. These weren't used because they weren't good - and they = wouldn't have worked for DLEP as they concentrated on different aspects of = optional/mandatory-ness than DLEP would have wanted (about forwarding for e= xample). This demonstrates that design for an uncertain future is hard, and= best avoided if possible. In addition the proposals confused format and fu= nction, where 5444 was intended to provide the former not the latter. (Some= function in packet management crept in because 5498 - against the ignored = protests of the 5444 authors - dumped some of what it should have done back= on 5444.) I'm catching up elsewhere, so not planning to participate in this for a bit= . But I will just note that having a TLV type for metric, and a type extens= ion for which metric, is the poster child for the purpose of a type extensi= on. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 11 April 2012 14:40 To: Rick Taylor Cc: manet@ietf.org; sratliff@cisco.com; Dearlove, Christopher (UK) Subject: Re: [manet] DLEP and RFC5444 message types On 04/11/2012 03:31 PM, Rick Taylor wrote: > Yes. > >> (metric TLVs would be all non-mandatory I think) > > Yes. I was thinking particularly about the credit-windowing TLVs. > Draft-02 is still unclear on the Status TLV contents when > credit-windowing is desired by a router, but unsupported by a modem. > I.e. the peering can happen, but no credit-windowing allowed. > >> Maybe we can split the extension types used by DLEP-specific TLVs into >> ranges... something like >> >> 0-224: TLV is not mandatory to understand DLEP order >> 225-255: TLV is mandatory to understand DLEP order > > Only for extension types? Why not for all message-specific TLV types? > > How about classifying as: MUST understand (kill association), SHOULD > understand (status code response), MAY understand (standard-specified > value, but no status response required), OPTIONAL (must have extension > type?) Yes, something like this is missing in RFC 5444. Hmm, I just noticed something interesting... there are two unused bits=20 in the TLV header itself. Maybe this would be something interesting to=20 discuss as an extension of RFC5444. It would be a much cleaner solution than to hack something into the=20 extension types or message-tlv types. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Apr 19 06:14:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739821F854F for ; Thu, 19 Apr 2012 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVa97DLqAj+M for ; Thu, 19 Apr 2012 06:14:08 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3521F8573 for ; Thu, 19 Apr 2012 06:14:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="232558186" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Apr 2012 14:14:07 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3JDE6Y1010078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 14:14:06 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 14:14:06 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , Henning Rogge Thread-Topic: [manet] State changed for draft draft-ietf-manet-olsrv2 Thread-Index: AQHNGqucSshmBisbaEah9MjmZLVxv5abI0JlgAUYYoCAAOHUgIABCapQ Date: Thu, 19 Apr 2012 13:14:05 +0000 Message-ID: References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> <4F8E8149.7040201@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:14:12 -0000 +1 --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: 18 April 2012 23:23 To: Henning Rogge Cc: manet@ietf.org; Dearlove, Christopher (UK) Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Henning, I think the answer to your question is "yes" :-) Ulrich On Wed, Apr 18, 2012 at 1:54 AM, Henning Rogge wrote: > On 04/15/2012 04:05 AM, Stan Ratliff wrote: >> >> All, >> >> Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day >> period. 2 weeks of that period have already passed, so OLSRv2 has been >> moved to WGLC with the last call period ending May 10, 2012. > > > I have a question about the Local Attached Network Set (section 7.2) and = its > usage during routing. > > Attached networks have both a link metric and a 'hopcount distance'. Do I > understand the current draft correct that the metric is used for selectin= g > the attached network the node will route to (there can be multiple nodes > with the same attached network!) and that the hopcount field is just used= to > set the distance field in the kernel routing table? > > Henning Rogge > > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From teco@inf-net.nl Thu Apr 19 06:26:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F9A21F85C4 for ; Thu, 19 Apr 2012 06:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGtVIet+j0aW for ; Thu, 19 Apr 2012 06:26:34 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C68221F846D for ; Thu, 19 Apr 2012 06:26:33 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1406929wib.13 for ; Thu, 19 Apr 2012 06:26:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=pFY+D06EojZhzg5+ZCLKQ/Gnsm3ZV1kMAWLJ+sdP4so=; b=hNMtUiR/eqw0Rueg9IMiF1uGoFT1ce0ZSDDpBOmR6JJTcRb7oolgH1PmPw5oKNeptt wbJD8NZvstZpRFmM5dM5+/jdeKoNFYv1+730Gccxx3/Aq5lLUOlgcHTrgHAAMiIsx4ZH PVsFCIT5iX1LtsL6CyIwTBFqVWRgAKkxymvIRT4jJkr0GoHxPGPG+BU4jTGAXe8fh6GN zQ4rRl/mBsfsif0o5zvzNZP1PcDIIWthja8xOczp2m/OpouM3pPGo2D9bnfSZvbVuMNx 6eY5HT3I914ZqHwCq6/XdIh90NE36e82sMITz9Lu2lc9fcyOrZ3zJzPjAdX5ztGs2JXw TCqA== Received: by 10.216.138.5 with SMTP id z5mr1401941wei.27.1334841992643; Thu, 19 Apr 2012 06:26:32 -0700 (PDT) Received: from [172.16.4.181] ([188.205.88.52]) by mx.google.com with ESMTPS id h8sm8367130wix.4.2012.04.19.06.26.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 06:26:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Thu, 19 Apr 2012 15:26:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <919FD0E0-6C39-41FA-B478-F5B1AA5313F7@inf-net.nl> References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> <4F8E8149.7040201@fkie.fraunhofer.de> To: Ulrich Herberg , Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnWRiGvkJg8DW0CvZfLk3DEgkeUXL6LTIp2z4tlYgMTiMS22n2Za8hsDFL12x/H4gIceTgf Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org IETF" Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:26:38 -0000 I would say: yes, no. Yes: metric is used for path selection. No: hop-count is not to be used for putting in a routing table. The "distance" info in routing tables is afaik not standardized. Could be info-only, could be used as selector when multiple routing protocols provide same paths. Or whatever. Putting hop-count in a info-only attribute may be implemented. It could be used as tie-breaker for single path / limited paths. This needs no standardization. Question: add OLSR hop_count to AL_dist? OLSR hop-count is for=20 signaling, not for actual paths. Teco=20 Op 19 apr. 2012, om 00:22 heeft Ulrich Herberg het volgende geschreven: > Hi Henning, >=20 > I think the answer to your question is "yes" >=20 > :-) >=20 > Ulrich >=20 > On Wed, Apr 18, 2012 at 1:54 AM, Henning Rogge > wrote: >> On 04/15/2012 04:05 AM, Stan Ratliff wrote: >>>=20 >>> All, >>>=20 >>> Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day >>> period. 2 weeks of that period have already passed, so OLSRv2 has = been >>> moved to WGLC with the last call period ending May 10, 2012. >>=20 >>=20 >> I have a question about the Local Attached Network Set (section 7.2) = and its >> usage during routing. >>=20 >> Attached networks have both a link metric and a 'hopcount distance'. = Do I >> understand the current draft correct that the metric is used for = selecting >> the attached network the node will route to (there can be multiple = nodes >> with the same attached network!) and that the hopcount field is just = used to >> set the distance field in the kernel routing table? >>=20 >> Henning Rogge >>=20 >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Apr 19 06:41:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A221F865B for ; Thu, 19 Apr 2012 06:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaFPl23M1g6U for ; Thu, 19 Apr 2012 06:41:09 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 248DA21F8658 for ; Thu, 19 Apr 2012 06:41:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="232569264" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Apr 2012 14:41:07 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3JDf6PD030974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 14:41:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 14:41:07 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Ulrich Herberg , Henning Rogge Thread-Topic: [manet] State changed for draft draft-ietf-manet-olsrv2 Thread-Index: AQHNGqucSshmBisbaEah9MjmZLVxv5abI0JlgAUYYoCAAOHUgIAA/HwAgAARAYA= Date: Thu, 19 Apr 2012 13:41:06 +0000 Message-ID: References: <20120415020057.18887.64136.idtracker@ietfa.amsl.com> <4F8E8149.7040201@fkie.fraunhofer.de> <919FD0E0-6C39-41FA-B478-F5B1AA5313F7@inf-net.nl> In-Reply-To: <919FD0E0-6C39-41FA-B478-F5B1AA5313F7@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org IETF" Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:41:14 -0000 That's a useful qualification. The hop count is available to be put in an I= P routing table that (as at least some do) requires a hop count. OLSRv2 doe= s not (as it says) mandate what you do with the Routing Set, just that it c= reates a Routing Set, which you can do whatever you like with. But of cours= e in the real world, using the Routing Set to update the IP routing table i= s its main function. We ensure that the Routing Set has a hop count (R_dist= ) as well as a metric (R_metric) for when that's wanted. In order to have a= n R_dist, we need an AL_dist that sets the a hop count in a GATEWAY TLV, wh= ich hence sets an AN_dist in other routers, and hence R_dist. We already ha= ve all those. We also have an AL_metric and an AN_metric. Those are used fo= r shortest path selection with length R_metric. Again, it's up to the imple= mentation whether it records R_metric (which is a 32 bit value, thought wil= l almost always be well short of that value) or anything derived from it. R_dist does make a sensible, but not mandatory, tie-breaker for tied R_metr= ic values. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 19 April 2012 14:27 To: Ulrich Herberg; Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org IETF Subject: Re: [manet] State changed for draft draft-ietf-manet-olsrv2 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I would say: yes, no. Yes: metric is used for path selection. No: hop-count is not to be used for putting in a routing table. The "distance" info in routing tables is afaik not standardized. Could be info-only, could be used as selector when multiple routing protocols provide same paths. Or whatever. Putting hop-count in a info-only attribute may be implemented. It could be used as tie-breaker for single path / limited paths. This needs no standardization. Question: add OLSR hop_count to AL_dist? OLSR hop-count is for=20 signaling, not for actual paths. Teco=20 Op 19 apr. 2012, om 00:22 heeft Ulrich Herberg het volgende geschreven: > Hi Henning, >=20 > I think the answer to your question is "yes" >=20 > :-) >=20 > Ulrich >=20 > On Wed, Apr 18, 2012 at 1:54 AM, Henning Rogge > wrote: >> On 04/15/2012 04:05 AM, Stan Ratliff wrote: >>>=20 >>> All, >>>=20 >>> Per agreement in Paris, OLSRv2 was to be moved to WGLC with a 30-day >>> period. 2 weeks of that period have already passed, so OLSRv2 has been >>> moved to WGLC with the last call period ending May 10, 2012. >>=20 >>=20 >> I have a question about the Local Attached Network Set (section 7.2) and= its >> usage during routing. >>=20 >> Attached networks have both a link metric and a 'hopcount distance'. Do = I >> understand the current draft correct that the metric is used for selecti= ng >> the attached network the node will route to (there can be multiple nodes >> with the same attached network!) and that the hopcount field is just use= d to >> set the distance field in the kernel routing table? >>=20 >> Henning Rogge >>=20 >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From pars.mutaf@gmail.com Thu Apr 19 07:37:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25721F8666 for ; Thu, 19 Apr 2012 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AU4XMt3ChoO for ; Thu, 19 Apr 2012 07:37:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D714821F8644 for ; Thu, 19 Apr 2012 07:37:46 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so7819184obb.31 for ; Thu, 19 Apr 2012 07:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mXRIukqW1VSl/Q6x0s8XtrqTBOrIIMO75DXSxsm6E2Y=; b=LyS/SQC29ewvwWyuCewEIJ8mumjlFP7VxHioaDPrFOCECY37XHzZnaOxE77F8BmAvj x6P7ptAtOdqXjzkquJhYR3TFmHL9djsstpsCMC4Fr/ojB2gueMHWhYsgInfjO3BZ2pA8 ACiESZI5QBMaBrgZS76ZOsq8ST+M4M07MFjzfUQhLmQFByTtJFmbTwI8pIJ+6JZ2ZzC+ oCNcNh5otSwB+9X9mLOPh3If6v8djd7bHqvaukV6H9VL4R3mNxwI1QDBcjFrLVCXBxJ1 sd2xLO8rJDh+v25AC89GLMlpjK/E4udbd6hU0A+Y3kow3o5FTRTNiMvqb9gmLD2WoQby blbA== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr2125085obw.10.1334846264561; Thu, 19 Apr 2012 07:37:44 -0700 (PDT) Received: by 10.182.40.165 with HTTP; Thu, 19 Apr 2012 07:37:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Apr 2012 17:37:44 +0300 Message-ID: From: Pars Mutaf To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=f46d044472136dd06004be091d05 X-Mailman-Approved-At: Thu, 19 Apr 2012 08:28:13 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:37:51 -0000 --f46d044472136dd06004be091d05 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I=92m not sure if I should really take this seriously, but consider the > events of 7th July 2005 on the London Underground and ask (a) would a > MANET have been useful? and (b) would a balloon have been useful?**** > > ** > I guess you assume that cell phones do not work underground? If so why the MANET is the best solution? Is it really a solution? What if we are 5 people underground not in reach of other 4? For example I would think about increasing the cell phone's tranceiver power for emergency cases (to reach the balloon). Just an example. Pars > ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Pars Mutaf > *Sent:* 10 April 2012 06:26 > *To:* manet@ietf.org > *Subject:* [manet] Replacing MANET with a simple solution**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > In a disaster scenario, the base stations are down, everything is broken. > **** > > ** ** > > Just find a big balloon, attach the antennas to it, send it to the air > with an electric cable connected to a power generator on the ground. **** > > ** ** > > You have a base station in 1 hour.**** > > ** ** > > Why spend millions of dollars/euros for this MANET effort?**** > > ** ** > > Pars Mutaf**** > > Asst. Prof.**** > > ******************************************************************** > 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. > ******************************************************************** > > --f46d044472136dd06004be091d05 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 19, 2012 at 11:51 AM, Dearlo= ve, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

I=92m not sure if I shoul= d really take this seriously, but consider the events of 7th Jul= y 2005 on the London Underground and ask (a) would a MANET have been useful? and (b) would a balloon have been useful?<= /span>

<= /div>

I guess you assume that cell phones d= o not work underground?

If so why the MANET is the best solution?=A0
= Is it really a solution? What if we are 5 people underground not in reach o= f other 4?=A0

For example I would think about incr= easing the cell phone's tranceiver power for emergency cases (to reach = the balloon). Just an example.=A0

Pars

=A0

=A0

--

Christopher Dearlove

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

chris.dearlove@baesystems.com | http://www.baesy= stems.com

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

=A0<= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars Mutaf
Sent: 10 April 2012 06:26
To: manet@ietf.o= rg
Subject: [manet] Replacing MANET with a simple solution

=A0

=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

In a disaster scenario, the base stations are down, = everything is broken.=A0

=A0

Just find a big balloon, attach the antennas to it, = send it to the air with an=A0electric=A0cable connected to a power generato= r on the ground.=A0

=A0

You have a base station in 1 hour.

=A0

Why spend=A0millions=A0of dollars/euros for this MAN= ET effort?

=A0

Pars Mutaf

Asst. Prof.


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


--f46d044472136dd06004be091d05-- From sratliff@cisco.com Thu Apr 19 08:31:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FF621F8667 for ; Thu, 19 Apr 2012 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wJBKHLztuEY for ; Thu, 19 Apr 2012 08:31:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CEE6021F8666 for ; Thu, 19 Apr 2012 08:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12007; q=dns/txt; s=iport; t=1334849461; x=1336059061; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=OV2WYuOkIku1n5LFXvQIPWf71f8WtIdJNTrR3S/5U6c=; b=UKv6NISSqoH750psl4Qy+3uf02nn/rZDOO5wlWDQNYqbrAmd5uBOY5r1 5Qk0SOeZfnmpLzVwmCbFYVBi1YvIatl5Xaeb/YKmNK0cN8Sp+SMh4REzU dyKc89RPgH6CwVaQOmYg81khyYpXBz4zk8lBiPqI/919SykooQxbhBFvv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHEukE+tJXHA/2dsb2JhbABDgkaldokGgQeCCQEBAQIBAQEBAQ8BQhQBBAMIEAsRBAEBAScHJx8JCAYTGweHaAULmkagKIprAQyEYmMElW+BEo1AgWmDA4E4CA X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208,217";a="73080830" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Apr 2012 15:31:00 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3JFUxmb008808; Thu, 19 Apr 2012 15:30:59 GMT Message-Id: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> From: Stan Ratliff To: Pars Mutaf In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-48-59976589 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Apr 2012 11:31:01 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:31:05 -0000 --Apple-Mail-48-59976589 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable This has obviously turned into something of a "religious disussion". =20 No one's mind is going to get changed; this is just cluttering up my =20 inbox with requests to approve postings. *My* request is that we stop =20= the wanton waste of electrical power and bandwidth that is this =20 thread. In the words of Nancy Reagan long ago: "Just say no." Regards, Stan On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote: > > > On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) = > wrote: > I=92m not sure if I should really take this seriously, but consider =20= > the events of 7th July 2005 on the London Underground and ask (a) =20 > would a MANET have been useful? and (b) would a balloon have been =20 > useful? > > > > I guess you assume that cell phones do not work underground? > > If so why the MANET is the best solution? > Is it really a solution? What if we are 5 people underground not in =20= > reach of other 4? > > For example I would think about increasing the cell phone's =20 > tranceiver power for emergency cases (to reach the balloon). Just an =20= > example. > > Pars > > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace =20 > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On =20 > Behalf Of Pars Mutaf > Sent: 10 April 2012 06:26 > To: manet@ietf.org > Subject: [manet] Replacing MANET with a simple solution > > > > > > *** WARNING *** > > This message originates from outside our organisation, either from =20 > an external partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. > > In a disaster scenario, the base stations are down, everything is =20 > broken. > > > > Just find a big balloon, attach the antennas to it, send it to the =20 > air with an electric cable connected to a power generator on the =20 > ground. > > > > You have a base station in 1 hour. > > > > Why spend millions of dollars/euros for this MANET effort? > > > > Pars Mutaf > > Asst. Prof. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-48-59976589 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable This has obviously turned into = something of a "religious disussion". No one's mind is going to get = changed; this is just cluttering up my inbox with requests to approve = postings. *My* request is that we stop the wanton waste of electrical = power and bandwidth that is this thread. In the words of Nancy Reagan = long ago: "Just say = no."

Regards,
Stan

On= Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote:



On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, = Christopher (UK) <Chris.Dearlove@baesystems.co= m> wrote:
=

I=92m not sure if I should really take this = seriously, but consider the events of 7th July 2005 on the = London Underground and ask (a) would a MANET have been useful? and (b) = would a balloon have been useful?


=
I guess you assume that cell phones do not work = underground?

If so why the MANET is the best = solution? 
Is it really a solution? What if we are 5 = people underground not in reach of other = 4? 

For example I would think about = increasing the cell phone's tranceiver power for emergency cases (to = reach the balloon). Just an example. 
=

Pars

 

 

--

Christopher Dearlove

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

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

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars = Mutaf
Sent: 10 April 2012 06:26
To: manet@ietf.org
= Subject: [manet] Replacing MANET with a simple = solution

 

&nbs= p;

*** WARNING ***

=

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

In a disaster scenario, the base stations are down, = everything is broken. 

 

Just find a big balloon, attach the antennas to it, = send it to the air with an electric cable connected to a power = generator on the ground. 

 

You have a base station in 1 hour.

=

 

=

Why spend millions of = dollars/euros for this MANET effort?

 

Pars Mutaf

Asst. Prof.


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

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

= --Apple-Mail-48-59976589-- From boberry@cisco.com Thu Apr 19 08:39:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBAB21F865E for ; Thu, 19 Apr 2012 08:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbxTjTLPHeAW for ; Thu, 19 Apr 2012 08:39:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0187121F85F1 for ; Thu, 19 Apr 2012 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=4132; q=dns/txt; s=iport; t=1334849962; x=1336059562; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fUeCDcxcrixc1vMBNFKyycSVhJEc5ZAYdhNEiqWTl14=; b=OIraDABw1vbcI/fHAAaXiZes7UD+/Zc2H5N57QuL5q7EHkRU2yT36HPD MGiD/D+jGar9sEDReQWmEBhoPiWQaizR/hUQ00veMJ67Ol49jOQAq1U15 gUnp2oBfiXzCcwvzTJzRjBa7aPu+M7+zzK/1KSjG/TdSDk5+3JfiUdVf/ s=; X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="76106497" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 19 Apr 2012 15:39:21 +0000 Received: from [192.168.5.121] (ggsg-vpn2-230-85.cisco.com [10.81.230.85]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3JFdKhH003752; Thu, 19 Apr 2012 15:39:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> Date: Thu, 19 Apr 2012 11:39:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Pars Mutaf Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:39:27 -0000 +1 please can we move on. On Apr 19, 2012, at 11:31 AM, Stan Ratliff wrote: > This has obviously turned into something of a "religious disussion". = No one's mind is going to get changed; this is just cluttering up my = inbox with requests to approve postings. *My* request is that we stop = the wanton waste of electrical power and bandwidth that is this thread. = In the words of Nancy Reagan long ago: "Just say no." >=20 > Regards, > Stan >=20 > On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote: >=20 >>=20 >>=20 >> On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) = wrote: >> I=92m not sure if I should really take this seriously, but consider = the events of 7th July 2005 on the London Underground and ask (a) would = a MANET have been useful? and (b) would a balloon have been useful? >>=20 >>=20 >>=20 >> I guess you assume that cell phones do not work underground? >>=20 >> If so why the MANET is the best solution?=20 >> Is it really a solution? What if we are 5 people underground not in = reach of other 4?=20 >>=20 >> For example I would think about increasing the cell phone's = tranceiver power for emergency cases (to reach the balloon). Just an = example.=20 >>=20 >> Pars >>=20 >> =20 >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >>=20 >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>=20 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >> =20 >>=20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of Pars Mutaf >> Sent: 10 April 2012 06:26 >> To: manet@ietf.org >> Subject: [manet] Replacing MANET with a simple solution >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an = external partner or the internet. >> Keep this in mind if you answer this message. >> Please see this process on how to deal with suspicious emails. >>=20 >> In a disaster scenario, the base stations are down, everything is = broken.=20 >>=20 >> =20 >>=20 >> Just find a big balloon, attach the antennas to it, send it to the = air with an electric cable connected to a power generator on the ground.=20= >>=20 >> =20 >>=20 >> You have a base station in 1 hour. >>=20 >> =20 >>=20 >> Why spend millions of dollars/euros for this MANET effort? >>=20 >> =20 >>=20 >> Pars Mutaf >>=20 >> Asst. Prof. >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From Chris.Dearlove@baesystems.com Thu Apr 19 08:46:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B0821F8562 for ; Thu, 19 Apr 2012 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWszRfpX65CS for ; Thu, 19 Apr 2012 08:45:56 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 30BDE21F866E for ; Thu, 19 Apr 2012 08:45:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="232615199" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 19 Apr 2012 16:45:55 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3JFjs9v025814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Apr 2012 16:45:55 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Thu, 19 Apr 2012 16:45:55 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Stan Ratliff Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0W2mYq1o/FZDOOTkG3jDd6meSHmgHLrUPgAAofjgAAAdxkgAAASlsAAAJAXiA= Date: Thu, 19 Apr 2012 15:45:54 +0000 Message-ID: References: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Pars Mutaf Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:46:02 -0000 Subject only to that I think I need to observe that the assumption attribut= ed to me is completely bogus, agreed. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: 19 April 2012 16:39 To: Stan Ratliff Cc: Pars Mutaf; Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- +1 please can we move on. On Apr 19, 2012, at 11:31 AM, Stan Ratliff wrote: > This has obviously turned into something of a "religious disussion". No o= ne's mind is going to get changed; this is just cluttering up my inbox with= requests to approve postings. *My* request is that we stop the wanton wast= e of electrical power and bandwidth that is this thread. In the words of Na= ncy Reagan long ago: "Just say no." >=20 > Regards, > Stan >=20 > On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote: >=20 >>=20 >>=20 >> On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) wrote: >> I'm not sure if I should really take this seriously, but consider the ev= ents of 7th July 2005 on the London Underground and ask (a) would a MANET h= ave been useful? and (b) would a balloon have been useful? >>=20 >>=20 >>=20 >> I guess you assume that cell phones do not work underground? >>=20 >> If so why the MANET is the best solution?=20 >> Is it really a solution? What if we are 5 people underground not in reac= h of other 4?=20 >>=20 >> For example I would think about increasing the cell phone's tranceiver p= ower for emergency cases (to reach the balloon). Just an example.=20 >>=20 >> Pars >>=20 >> =20 >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >>=20 >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>=20 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >> =20 >>=20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Pars Mutaf >> Sent: 10 April 2012 06:26 >> To: manet@ietf.org >> Subject: [manet] Replacing MANET with a simple solution >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an ex= ternal partner or the internet. >> Keep this in mind if you answer this message. >> Please see this process on how to deal with suspicious emails. >>=20 >> In a disaster scenario, the base stations are down, everything is broken= .=20 >>=20 >> =20 >>=20 >> Just find a big balloon, attach the antennas to it, send it to the air w= ith an electric cable connected to a power generator on the ground.=20 >>=20 >> =20 >>=20 >> You have a base station in 1 hour. >>=20 >> =20 >>=20 >> Why spend millions of dollars/euros for this MANET effort? >>=20 >> =20 >>=20 >> Pars Mutaf >>=20 >> Asst. Prof. >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole us= e of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message. From jomullen@ad.nmsu.edu Thu Apr 19 12:10:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B025111E8074 for ; Thu, 19 Apr 2012 12:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htAdBxqrDrD6 for ; Thu, 19 Apr 2012 12:10:41 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-01.nmsu.edu [128.123.34.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93B11E8073 for ; Thu, 19 Apr 2012 12:10:41 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-01.ACN.ad.nmsu.edu ([128.123.34.211]) with mapi; Thu, 19 Apr 2012 13:10:37 -0600 From: Dr John P Mullen To: "manet@ietf.org" Date: Thu, 19 Apr 2012 13:10:36 -0600 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0W2mYq1o/FZDOOTkG3jDd6meSHmgHLrUPgABWCALA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C06FEXCHANGEMBX01_" MIME-Version: 1.0 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 19:10:43 -0000 --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C06FEXCHANGEMBX01_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think the biggest problem was in setting up a control scheme that require= d direct communications between an officer and a handler without assuring t= hat such communications would exist in all areas in which that control was = likely to be needed. A MANET could have helped, providing there were other nodes in the area. In= that situation, things moved very quickly, so there probably would not hav= e been peers to network with. A more reliable approach would be a system of= hot points in such areas hardwired to the net to assure continued communic= ations. Sort of like a subterranean cellular system. John Mullen From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of D= earlove, Christopher (UK) Sent: Thursday, April 19, 2012 2:51 AM To: Pars Mutaf; manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution I'm not sure if I should really take this seriously, but consider the event= s of 7th July 2005 on the London Underground and ask (a) would a MANET have= been useful? and (b) would a balloon have been useful? -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Pars = Mutaf Sent: 10 April 2012 06:26 To: manet@ietf.org Subject: [manet] Replacing MANET with a simple solution *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with= an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C06FEXCHANGEMBX01_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I think the biggest problem was in setting up a co= ntrol scheme that required direct communications between an officer and a h= andler without assuring that such communications would exist in all areas i= n which that control was likely to be needed.

 

A MANET could have helped, providing there were other nodes in the area. = In that situation, things moved very quickly, so there probably would not h= ave been peers to network with. A more reliable approach would be a system = of hot points in such areas hardwired to the net to assure continued commun= ications. Sort of like a subterranean cellular system.

 <= /span>

John Mullen

=

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] = On Behalf Of Dearlove, Christopher (UK)
Sent: Thursday, Ap= ril 19, 2012 2:51 AM
To: Pars Mutaf; manet@ietf.org
Subject= : Re: [manet] Replacing MANET with a simple solution<= /p>

 

I’m not sure if I should really take this seri= ously, but consider the events of 7th July 2005 on the London Un= derground and ask (a) would a MANET have been useful? and (b) would a ballo= on have been useful?

 

--

Christopher Dearlove<= /o:p>

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

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

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org]= On Behalf Of Pars Mutaf
Sent: 10 April 2012 06:26
T= o: manet@ietf.org
Subject:<= /b> [manet] Replacing MANET with a simple solution

 

&nb= sp;

*** WARNING ***

This message originates from outside our organisation, either from an ex= ternal partner or the internet.
Keep this in mind if you answ= er this message.
Please see t= his process on how to deal with suspicious emails.

= In a disaster scenario, the base stations are down, ever= ything is broken. 

 

= Just find a big balloon, attach the antennas to it, send= it to the air with an electric cable connected to a power genera= tor on the ground. 

 

You have a base station in 1 hour.

 =

Why spend&nbs= p;millions of dollars/euros for this MANET effort?

 

Pars Mutaf

Asst. Prof= .


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

= --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C06FEXCHANGEMBX01_-- From henning.rogge@fkie.fraunhofer.de Thu Apr 19 22:26:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8421F86BA for ; Thu, 19 Apr 2012 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mX9JujlnBb0 for ; Thu, 19 Apr 2012 22:25:59 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2C21F86B7 for ; Thu, 19 Apr 2012 22:25:47 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SL6Lp-0004PJ-Fb for manet@ietf.org; Fri, 20 Apr 2012 07:25:45 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SL6Lp-0000Dj-D0 for manet@ietf.org; Fri, 20 Apr 2012 07:25:45 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 07:25:45 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 20 Apr 2012 07:25:44 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 20 Apr 2012 07:25:44 +0200 Message-ID: <4F90F351.4020102@fkie.fraunhofer.de> Date: Fri, 20 Apr 2012 07:25:37 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080606070902020806040404" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 20 Apr 2012 05:25:45.0165 (UTC) FILETIME=[093F7FD0:01CD1EB6] X-Virus-Scanned: yes (ClamAV 0.97.3/14822/Thu Apr 19 19:37:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 797bbac53b4539d3de9d70869dd0fccf Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 05:26:00 -0000 --------------ms080606070902020806040404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable One interesting aspect of MANETs is that they can easily include fixed=20 or adhoc infrastructure in their network. You get into the disaster area, everyone has a MANET node in his vehicle = and you start working. Communication in the local area is good,=20 communication for long range might be (depending on node density) shaky. But at least you are sure to have working communication in areas where a = lot of your people are. Then you can begin to setup your HQ or several fixed places and connect=20 them with directional links (or satellite links if you can afford it).=20 If you integrate this links into your MANET, you instantly extend the=20 capabilities of the local MANET clouds for long range communication. Finally you start repairing the former cell based network to increase=20 the datarate and quality of service of the communication in the disaster = area. If you also include this connections into your MANET, your=20 networks area total capability increase again, even in areas where your=20 cell based one is difficult to reach. Henning Rogge On 04/19/2012 09:10 PM, Dr John P Mullen wrote: > Hi, > > I think the biggest problem was in setting up a control scheme that > required direct communications between an officer and a handler > without assuring that such communications would exist in all areas in > which that control was likely to be needed. > > A MANET could have helped, providing there were other nodes in the > area. In that situation, things moved very quickly, so there probably > would not have been peers to network with. A more reliable approach > would be a system of hot points in such areas hardwired to the net to > assure continued communications. Sort of like a subterranean cellular > system. > > John Mullen --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080606070902020806040404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjAwNTI1NDJaMCMGCSqGSIb3DQEJBDEWBBRZYR5NcElPJ188cMCCMQQK8HhujzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBWmy9JPCvfs6iAFksMKDpV1b9UsyJntTcgpCvw5OtEmIfNzl8M/1motwIghw3V Iowlj/oHvogX54vdFvDS4rFcH0ZGnbQNN8q+i5hmtK8ss376+z5AXkS0ZdGiqolE3wdtH2tk u8KdU1Ij2NU43pJFPrLLALv+Hb3VDYypgDGhHS3OagGVJ1RBTQwAk8aQ/EqH5onRZt/MpuXU 3rl7AtZG8zPD26bxQ6kkYNRQsQ1TnvKq1WmwfocvyvVWyfrhib9hL1GPUBz9GiT0VgHYQAB3 zYWtpWmYLBBcBSrR2vMzSMdE+wmwzKerg2yaqIbI+jX3pDTFV6siJ+LqOoUzDKFXAAAAAAAA --------------ms080606070902020806040404-- From henning.rogge@fkie.fraunhofer.de Fri Apr 20 03:41:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D121F8484 for ; Fri, 20 Apr 2012 03:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbWO5jZbTFa5 for ; Fri, 20 Apr 2012 03:41:40 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id D80A721F8670 for ; Fri, 20 Apr 2012 03:41:39 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SLBHS-0003CJ-Sz; Fri, 20 Apr 2012 12:41:34 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SLBHS-0000OB-QJ; Fri, 20 Apr 2012 12:41:34 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 12:41:34 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 20 Apr 2012 12:41:34 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 20 Apr 2012 12:41:33 +0200 Message-ID: <4F913D5C.60302@fkie.fraunhofer.de> Date: Fri, 20 Apr 2012 12:41:32 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> <4F8589A6.3030305@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060203000106090100010103" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 20 Apr 2012 10:41:34.0629 (UTC) FILETIME=[28023D50:01CD1EE2] X-Virus-Scanned: yes (ClamAV 0.97.3/14822/Thu Apr 19 19:37:34 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 10:41:40 -0000 --------------ms060203000106090100010103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/19/2012 12:03 PM, Dearlove, Christopher (UK) wrote: > There were discussions about encoding optional/mandatory information > in what became RFC 5444. These weren't used because they weren't good > - and they wouldn't have worked for DLEP as they concentrated on > different aspects of optional/mandatory-ness than DLEP would have > wanted (about forwarding for example). This demonstrates that design > for an uncertain future is hard, and best avoided if possible. In > addition the proposals confused format and function, where 5444 was > intended to provide the former not the latter. (Some function in > packet management crept in because 5498 - against the ignored > protests of the 5444 authors - dumped some of what it should have > done back on 5444.) Okay. > I'm catching up elsewhere, so not planning to participate in this for > a bit. But I will just note that having a TLV type for metric, and a > type extension for which metric, is the poster child for the purpose > of a type extension. I think that does only make sense as long as the 'data format' (value)=20 of the TLV is always the same type. Having one extension type of=20 "metric" for datarate (bits/s, 8 byte data) and another extension type=20 for signal strength (dBm, 2 byte data?) sounds strange. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060203000106090100010103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjAxMDQxMzJaMCMGCSqGSIb3DQEJBDEWBBT2IwC3tygXGOelL26n3uqzHhps+jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAP/LMmiYx0ENzpPjOIIu5K/0QmzJLc8dbKGpWTdssjd4UNx5TuTMS0aJiEe4PM BdFJuz9UNrS8i8RhNyVI5uu4xaW7gMeAYgiXhq46Tk8LEEmIUn8OHwKZMQIBT8TQvfZCkmVU zaLPXYAQzmvRkp2Znvx/0KpcilbF8HGAHMFl21iMmCYFClSchrS/L5JSltTE+GLchCdrX9cc 0MecyaB96vNXmEzHWmufWB69uSK5SbifrwoK93qKbs0IDLxr2Sdij5uojh6gFdRP+RjwG6K9 3LTc6rEU4FBzbVsoTV5p67ju6Lans6wZzTIbS76Kh45GY+XVEKs2CoguaV3ebMi5AAAAAAAA --------------ms060203000106090100010103-- From Chris.Dearlove@baesystems.com Fri Apr 20 03:51:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0421F870F for ; Fri, 20 Apr 2012 03:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF3Y32rPq-g9 for ; Fri, 20 Apr 2012 03:51:33 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5B21F86DD for ; Fri, 20 Apr 2012 03:51:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,452,1330905600"; d="scan'208";a="232846443" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 20 Apr 2012 11:51:32 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3KApVG6014565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Apr 2012 11:51:31 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.56]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 11:51:32 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] DLEP and RFC5444 message types Thread-Index: Ac0X6KBs5upA4BdvS5eDmXecFJctNwGKYYiAADHniAAAAiCfUA== Date: Fri, 20 Apr 2012 10:51:30 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> In-Reply-To: <4F913D5C.60302@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "sratliff@cisco.com" Subject: Re: [manet] DLEP and RFC5444 message types X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 10:51:34 -0000 I agree that when the format is the same it's an even better fit than when = it isn't. But when metrics don't have the same format, using different type= extensions of a single type is still better than using separate types. For= a start you get to require IANA to create a registry, and you can create r= ules for that registry about what metric type properties you can and can't = add in the future (subject to whichever management of policy for inclusion = you set - Expert Review is good). You could also create sub-ranges for diff= erent data formats, or various other ways of organising things. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 20 April 2012 11:42 To: Dearlove, Christopher (UK) Cc: manet@ietf.org; sratliff@cisco.com Subject: Re: [manet] DLEP and RFC5444 message types On 04/19/2012 12:03 PM, Dearlove, Christopher (UK) wrote: > There were discussions about encoding optional/mandatory information > in what became RFC 5444. These weren't used because they weren't good > - and they wouldn't have worked for DLEP as they concentrated on > different aspects of optional/mandatory-ness than DLEP would have > wanted (about forwarding for example). This demonstrates that design > for an uncertain future is hard, and best avoided if possible. In > addition the proposals confused format and function, where 5444 was > intended to provide the former not the latter. (Some function in > packet management crept in because 5498 - against the ignored > protests of the 5444 authors - dumped some of what it should have > done back on 5444.) Okay. > I'm catching up elsewhere, so not planning to participate in this for > a bit. But I will just note that having a TLV type for metric, and a > type extension for which metric, is the poster child for the purpose > of a type extension. I think that does only make sense as long as the 'data format' (value)=20 of the TLV is always the same type. Having one extension type of=20 "metric" for datarate (bits/s, 8 byte data) and another extension type=20 for signal strength (dBm, 2 byte data?) sounds strange. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From pars.mutaf@gmail.com Fri Apr 20 05:11:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1721F865B for ; Fri, 20 Apr 2012 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MpWh6O6wMUf for ; Fri, 20 Apr 2012 05:11:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFC21F85A8 for ; Fri, 20 Apr 2012 05:11:17 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so9340015obb.31 for ; Fri, 20 Apr 2012 05:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GH1gKJAxPmhDrJqqO89HFErjK1hMkNVhVHdrMby35Rk=; b=ToFr+CDieedGnIkKD4jR3jEPyXAx9ygB6CMBRx/FNGPDprAP+7wTX0DbMAGsZufeJg aDgGa/dGiG6HBqJSl6IygYVJQzcckf1SzUmY15RMotYjSuAz4fc6lktHeT38eZvhTq5I RvqwS+c12RFWH9NJ8rWSANhXnliwpne83EBEy2gHCyfioN4onTBQmKD3gnoB2PK6lW6d mh+i0i/zk3DrjFsji4aF4EqJEVGOkz7ZaCuAmwrqDDRCXGk1OZq9vJgrbAkWUKQBCWJ/ VazvW2UpOaUYjzotdGE1MKVnRBNFVIpUgHoKIMbZ8skLCQ4R5TlM6oqKUaZC77wqfiyH X7aw== MIME-Version: 1.0 Received: by 10.182.119.74 with SMTP id ks10mr8565027obb.30.1334923877444; Fri, 20 Apr 2012 05:11:17 -0700 (PDT) Received: by 10.182.40.165 with HTTP; Fri, 20 Apr 2012 05:11:17 -0700 (PDT) In-Reply-To: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> References: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> Date: Fri, 20 Apr 2012 15:11:17 +0300 Message-ID: From: Pars Mutaf To: Stan Ratliff Content-Type: multipart/alternative; boundary=f46d044469dd846b1404be1b2f45 X-Mailman-Approved-At: Fri, 20 Apr 2012 10:37:42 -0700 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:11:19 -0000 --f46d044469dd846b1404be1b2f45 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for requests to approve postings. I just want to remind you that the "partitioned network" problem may look like a small technical detail from inside. But from outside it looks serious: Hello my leg is broken Ah no the network is partitioned sorry Ah ok no problem. I don't think this is acceptable. This was not sarcasm I hope you get my frequency as it is. MANET approach is: What if MANET works? My approach is: What if MANET doesn't work? My last words (because I don't have any other technical arguments) Pars On Thu, Apr 19, 2012 at 6:31 PM, Stan Ratliff wrote: > This has obviously turned into something of a "religious disussion". No > one's mind is going to get changed; this is just cluttering up my inbox > with requests to approve postings. *My* request is that we stop the wanto= n > waste of electrical power and bandwidth that is this thread. In the words > of Nancy Reagan long ago: "Just say no." > > Regards, > Stan > > On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote: > > > > On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> I=92m not sure if I should really take this seriously, but consider the >> events of 7th July 2005 on the London Underground and ask (a) would a >> MANET have been useful? and (b) would a balloon have been useful?**** >> >> ** >> > > I guess you assume that cell phones do not work underground? > > If so why the MANET is the best solution? > Is it really a solution? What if we are 5 people underground not in reach > of other 4? > > For example I would think about increasing the cell phone's tranceiver > power for emergency cases (to reach the balloon). Just an example. > > Pars > > > >> ** >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> ** ** >> >> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >> Behalf Of *Pars Mutaf >> *Sent:* 10 April 2012 06:26 >> *To:* manet@ietf.org >> *Subject:* [manet] Replacing MANET with a simple solution**** >> >> ** ** >> >> ** ** >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how = to deal with suspicious emails. >> ***** >> >> In a disaster scenario, the base stations are down, everything is broken= . >> **** >> >> ** ** >> >> Just find a big balloon, attach the antennas to it, send it to the air >> with an electric cable connected to a power generator on the ground. ***= * >> >> ** ** >> >> You have a base station in 1 hour.**** >> >> ** ** >> >> Why spend millions of dollars/euros for this MANET effort?**** >> >> ** ** >> >> Pars Mutaf**** >> >> Asst. Prof.**** >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --f46d044469dd846b1404be1b2f45 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for requests to approve postings.

I just want to remind you t= hat the "partitioned network" problem may look like a small techn= ical detail from inside. But from outside
it looks serious:

Hell= o my leg is broken
Ah no the network is partitioned sorry
Ah ok no problem.

I don&#= 39;t think this is acceptable.

This was not sarcasm I hope you get = my frequency as it is.

MANET approach is: What if MANET works?
My approach is: What if MANET doesn't work?

My last words (becau= se I don't have any other technical arguments)

Pars

On Thu, Apr 19, 2012 at 6:31 PM, Stan Ratliff <sratliff@cisco.com= > wrote:
This has= obviously turned into something of a "religious disussion". No o= ne's mind is going to get changed; this is just cluttering up my inbox = with requests to approve postings. *My* request is that we stop the wanton = waste of electrical power and bandwidth that is this thread. In the words o= f Nancy Reagan long ago: "Just say no."

Regards,
Stan

On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote:



On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) <= Chris.Dearlove@baesystems.com> wrote:

I=92m not sure if I should really take thi= s seriously, but consider the events of 7th July 2005 on the Lon= don Underground and ask (a) would a MANET have been useful? and (b) would a= balloon have been useful?

<= /div>

I guess you assume that cell phones d= o not work underground?

If so why the MANET is the best solution?=A0
Is it really a solution? What if we are 5 people underground not in reach = of other 4?=A0

For example I would think about inc= reasing the cell phone's tranceiver power for emergency cases (to reach= the balloon). Just an example.=A0

Pars

=A0

=A0

--

Christopher Dearlove

Senio= r Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Adv= anced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsfor= d, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 = 242124

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

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

=A0

<= p class=3D"MsoNormal"> From: <= a href=3D"mailto:manet-bounces@ietf.org" target=3D"_blank">manet-bounces@ie= tf.org [mailto:manet-bounces@ietf.org] On Behalf Of Pars Mutaf
Sent: 10 April 2012 06:26
To: manet@ietf.org
Subject: [manet] Re= placing MANET with a simple solution

=A0

=A0

*** WARNING ***

Th= is message originates from outside our organisation, either from an externa= l partner or the internet.
Ke= ep this in mind if you answer this message.
Please see this proc= ess on how to deal with suspicious emails.

In a disaster scenario, the base stati= ons are down, everything is broken.=A0

=A0

Just fin= d a big balloon, attach the antennas to it, send it to the air with an=A0el= ectric=A0cable connected to a power generator on the ground.=A0

=A0

You have a base station in 1 hour.

=A0

Why spend=A0millions=A0of dollars/euros for this MANET effort?

=A0

=

Pars Mutaf

Asst. Prof.


**************************= ******************************************
This email and any attachmen= ts are confidential to the intended
recipient and may also be privilege= d. 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
distribut= e its contents to any other person.
***********************************= *********************************


________= _______________________________________
manet mailing list
manet@ietf.org
https://www.= ietf.org/mailman/listinfo/manet


--f46d044469dd846b1404be1b2f45-- From william.d.ivancic@nasa.gov Fri Apr 20 10:45:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD83F21F867E for ; Fri, 20 Apr 2012 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6Zbrx-Q9pZp for ; Fri, 20 Apr 2012 10:45:22 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id D4BA221F867C for ; Fri, 20 Apr 2012 10:45:21 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 43D1E2D8B9D; Fri, 20 Apr 2012 12:45:21 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3KHjEbx008348; Fri, 20 Apr 2012 12:45:21 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 20 Apr 2012 12:45:18 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "manet@ietf.org" Date: Fri, 20 Apr 2012 12:45:17 -0500 Thread-Topic: DLEP and modemLPA Thread-Index: Ac0fHVm91TesHMtDRcqqwZSwyt7yMg== Message-ID: <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC103643216@SUKNPT8106.cogent-dsn.! local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-20_05:2012-04-20, 2012-04-20, 1970-01-01 signatures=0 Cc: "modemlpa@googlegroups.com" Subject: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 17:45:22 -0000 From: http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01 " The authors of modemLPA have been in discussion with the authors of "Dynamic Link Exchange Protocol (DLEP)" determine if DLEP will fullfil the needs that ModemLPA is targeted at. DLEP is currently a client/server session oriented protocol that provides link layer information to directly connected devices - generally routers. The Modem Link Property Advertisment protocol broadcasts link status notifications to directly-attached devices and devices or applications that may be multiple hops away from the modem (or other sending device). It should be possible to use the DLEP message formats without all the signalling required for the DLEP client/server session to perform the functions addressed in this draft. The modem would simply provide link states out via multicast or unicast UDP datagrams (DLEP-Lite). Whether or not this is a good idea, or acceptable to the manet group, is yet to be determined. " Basically, DLEP and modemLPA are doing similar things. It is my understandi= ng that DLEP is mainly targeted at providing information to directly attach= ed routers in ad hoc networks. =20 ModemLPA is targeted are very simple deployment with a modem (or crypto dev= ice or whatever) providing upstream entities with at least some minimal ide= a of what may be going on in the wireless link by periodically broadcasting= status or changes in status . ModemLPA is looking at devices and applicat= ions that may be multiple hops away. Thus, if DLEP were used, one would op= erate in a "notification" or "broadcast" mode where status message would be= sent to either unicast addresses, link-local multicast addresses or scoped= multicast addresses. The upstream entities would simply listen of the app= ropriate port. No response would be required. =20 see - http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01#page-8 For a general idea of modemLPA see -=20 http://roland.grc.nasa.gov/~ivancic/shared/modemLPA/ModemLPA.pdf Questions: 1) Is this a good idea? 2) Is this acceptable to the manet wg to be included as part of DLEP? 3) Should modemLPA remains a separate protocol? 3a) if so, should modemLPA use the DLEP message structure? - Will From jomullen@ad.nmsu.edu Fri Apr 20 11:26:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AC921F865E for ; Fri, 20 Apr 2012 11:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3xaT8inckVE for ; Fri, 20 Apr 2012 11:26:41 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-02.nmsu.edu [128.123.34.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7A41321F8659 for ; Fri, 20 Apr 2012 11:26:41 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-02.ACN.ad.nmsu.edu ([128.123.34.236]) with mapi; Fri, 20 Apr 2012 12:26:37 -0600 From: Dr John P Mullen To: "manet@ietf.org" Date: Fri, 20 Apr 2012 12:26:36 -0600 Thread-Topic: [manet] Replacing MANET with a simple solution Thread-Index: Ac0fHExTuCgUgatOTMu2CMnqC3Nd3wABVbKg Message-ID: References: <2EBE8B23-55B2-4563-911D-88B7C8385695@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C073EXCHANGEMBX01_" MIME-Version: 1.0 Subject: Re: [manet] Replacing MANET with a simple solution X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 18:26:44 -0000 --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C073EXCHANGEMBX01_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think anyone here thinks of partitioning as "a small technical prob= lem," but the problem arises due to a lack of resources, not because a MANE= T is in use. That is, a good protocol will find viable paths, but if there = is no path, no protocol can prevent partition. This would apply to any prot= ocol, not just MANET protocols. A balloon can provide a link in some circumstances, but, as several have po= inted out here, not all. Even so, it may be easier to just have the balloon= act as an additional MANET node, rather than activate a whole different pr= otocol. In such a case, it just represents an alternate resource, not a dif= ferent protocol. It also means the ground=3Dbound transceivers don't have t= o be capable of two protocols, instead of just one. The point is, technology cannot solve all problems. This group is intereste= d in developing protocols for situations in which a mobile ad-hoc network i= s a good solution. It is not intended to promote the idea that MANETs can s= olve all problems. Unless your post is on this or a related topic, you are = talking to the wrong people. I suggest you look for a group that is develop= ing a protocol for balloon-assisted communications. John Mullen From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of P= ars Mutaf Sent: Friday, April 20, 2012 6:11 AM To: Stan Ratliff Cc: Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] Replacing MANET with a simple solution Sorry for requests to approve postings. I just want to remind you that the "partitioned network" problem may look l= ike a small technical detail from inside. But from outside it looks serious: Hello my leg is broken Ah no the network is partitioned sorry Ah ok no problem. I don't think this is acceptable. This was not sarcasm I hope you get my frequency as it is. MANET approach is: What if MANET works? My approach is: What if MANET doesn't work? My last words (because I don't have any other technical arguments) Pars On Thu, Apr 19, 2012 at 6:31 PM, Stan Ratliff > wrote: This has obviously turned into something of a "religious disussion". No one= 's mind is going to get changed; this is just cluttering up my inbox with r= equests to approve postings. *My* request is that we stop the wanton waste = of electrical power and bandwidth that is this thread. In the words of Nanc= y Reagan long ago: "Just say no." Regards, Stan On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote: On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) > wrote: I'm not sure if I should really take this seriously, but consider the event= s of 7th July 2005 on the London Underground and ask (a) would a MANET have= been useful? and (b) would a balloon have been useful? I guess you assume that cell phones do not work underground? If so why the MANET is the best solution? Is it really a solution? What if we are 5 people underground not in reach o= f other 4? For example I would think about increasing the cell phone's tranceiver powe= r for emergency cases (to reach the balloon). Just an example. Pars -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Pars Mutaf Sent: 10 April 2012 06:26 To: manet@ietf.org Subject: [manet] Replacing MANET with a simple solution *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. In a disaster scenario, the base stations are down, everything is broken. Just find a big balloon, attach the antennas to it, send it to the air with= an electric cable connected to a power generator on the ground. You have a base station in 1 hour. Why spend millions of dollars/euros for this MANET effort? Pars Mutaf Asst. Prof. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C073EXCHANGEMBX01_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I donR= 17;t think anyone here thinks of partitioning as “a small technical p= roblem,” but the problem arises due to a lack of resources, not becau= se a MANET is in use. That is, a good protocol will find viable paths, but = if there is no path, no protocol can prevent partition. This would apply to= any protocol, not just MANET protocols.

 

A ba= lloon can provide a link in some circumstances, but, as several have pointe= d out here, not all. Even so, it may be easier to just have the balloon act= as an additional MANET node, rather than activate a whole different protoc= ol. In such a case, it just represents an alternate resource, not a differe= nt protocol. It also means the ground=3Dbound transceivers don’t have= to be capable of two protocols, instead of just one.

=

 

The point is, technology cannot solve all problems. This group is = interested in developing protocols for situations in which a mobile ad-hoc = network is a good solution. It is not intended to promote the idea that MAN= ETs can solve all problems. Unless your post is on this or a related topic,= you are talking to the wrong people. I suggest you look for a group that i= s developing a protocol for balloon-assisted communications.

 <= /o:p>

John Mullen

From: manet-bounces@ietf.org [mailto:manet-bounces= @ietf.org] On Behalf Of Pars Mutaf


Sent: Friday, April 20, 2012 6:11 AM
To: Stan Ratliff=
Cc: Dearlove, Christopher (UK); manet@ietf.org
Subject: Re: [manet] Replacing MANET with a simple solution

<= p class=3DMsoNormal> 

Sorry for requests to approve postings.

I just wa= nt to remind you that the "partitioned network" problem may look = like a small technical detail from inside. But from outside
it looks ser= ious:

Hello my leg is broken
Ah no the network is partitioned so= rry
Ah ok no problem.

I don't think this is acceptable.

= This was not sarcasm I hope you get my frequency as it is.

MANET ap= proach is: What if MANET works?
My approach is: What if MANET doesn't wo= rk?

My last words (because I don't have any other technical argument= s)

Pars

On Thu, Apr 19, 2012= at 6:31 PM, Stan Ratliff <sratlif= f@cisco.com> wrote:

This has= obviously turned into something of a "religious disussion". No o= ne's mind is going to get changed; this is just cluttering up my inbox with= requests to approve postings. *My* request is that we stop the wanton wast= e of electrical power and bandwidth that is this thread. In the words of Na= ncy Reagan long ago: "Just say no."

 

Regards,<= o:p>

Stan

 

On Apr 19, 2012, at 10:37 AM, Pars Mutaf wrote:

 

 

On Thu, Apr 19, 2012 at 11:51 AM, Dearlove, Christopher (UK) <Chris.Dearlove@= baesystems.com> wrote:

I’m not sure if I should really take this seriously, but consid= er the events of 7th July 2005 on the London Underground and ask= (a) would a MANET have been useful? and (b) would a balloon have been usef= ul?

 

I guess = you assume that cell phones do not work underground?

 

If so why the MANET is the best solution? 

=

Is it really a solution? What if we are 5 people under= ground not in reach of other 4? 

 

For example I= would think about increasing the cell phone's tranceiver power for emergen= cy cases (to reach the balloon). Just an example. 

 

Pars

 

 

 

--

Christopher Dearlove<= /p>

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

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

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f Of Pars Mutaf
Sent: 10 April 2012 06:26
To: manet@ietf.org
Sub= ject: [manet] Replacing MANET with a simple solution

 <= /span>

 

*** WARNING ***

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

In a disaster scenario, the = base stations are down, everything is broken. 

 

= Just find a big balloon, attach the antennas to it, send= it to the air with an electric cable connected to a power genera= tor on the ground. 

 

= You have a base station in 1 hour.

<= span lang=3DEN-GB> 

Why spend millions of dollars/euros for this MANET effor= t?

 

Pars Mutaf

Asst. Prof.<= /p>


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

<= p class=3DMsoNormal> 

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

 

 

= --_000_F9A5F0DF0BBF2547A0E94FC12263712E842607C073EXCHANGEMBX01_-- From hrogge@googlemail.com Fri Apr 20 16:10:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283B621E8039 for ; Fri, 20 Apr 2012 16:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3gp9csJVnDj for ; Fri, 20 Apr 2012 16:10:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4921E8011 for ; Fri, 20 Apr 2012 16:10:35 -0700 (PDT) Received: by lbgc1 with SMTP id c1so3509814lbg.31 for ; Fri, 20 Apr 2012 16:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Qbb9XdYfXkwD135W9rURYOQQdtV3TK/ry3jiiUVyNyU=; b=bLBHggW3XvJymIdAp84r2KJ0e1jAfMkIJKNvdghKB+CQKhGXtg1YQyTaLpdXmfAJNQ Ip4VuloC1k1F0lrCGQ1MWIPcfKprs2a5jyzdN/my3mAMLVRnrnhvXQkgNB9mekejtks+ jTjOsK10NvGJxRALmQtVypf+wl3ZVgUhazUOgHA4AA0eMwQsxpbbUJf6eD4+NPu3E89k WIQ9ceCP9cTh2l6yh2PgaHJPnDCdyxrDBrFlcaQwYz7CG9vwkD8GKiPffpLD7AZtF8T7 fFppQz+E5PhJhWfjOWQvEMXWDZoshZm4Ps+5zWvplzduQ3PZguAgB/Y/WhUPSmN049cn Ba1Q== Received: by 10.152.112.161 with SMTP id ir1mr7558726lab.13.1334963433991; Fri, 20 Apr 2012 16:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 20 Apr 2012 16:10:13 -0700 (PDT) In-Reply-To: <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> From: Henning Rogge Date: Sat, 21 Apr 2012 01:10:13 +0200 Message-ID: To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 23:10:37 -0000 We are still in the process of discussing how the mechanisms of DLEP should work like. Teco already suggested that just multicasting the layer-2 data regularly and listening by the clients should be a valid usecase of DLEP. At the moment the draft contains a lot of complexity, and I still do not know why its necessary. I hope we will get this resolved. Henning Rogge On Fri, Apr 20, 2012 at 19:45, Ivancic, William D. (GRC-RHN0) wrote: > > From: > http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01 > > " =A0 The authors of modemLPA have been in discussion with the authors of > =A0 "Dynamic Link Exchange Protocol (DLEP)" =A0determine > =A0 if DLEP will fullfil the needs that ModemLPA is targeted > =A0 at. =A0DLEP is currently a client/server session oriented protocol th= at > =A0 provides link layer information to directly connected devices - > =A0 generally routers. =A0The Modem Link Property Advertisment protocol > =A0 broadcasts link status notifications to directly-attached devices and > =A0 devices or applications that may be multiple hops away from the modem > =A0 (or other sending device). > > =A0 It should be possible to use the DLEP message formats without all the > =A0 signalling required for the DLEP client/server session to perform the > =A0 functions addressed in this draft. =A0The modem would simply provide > =A0 link states out via multicast or unicast UDP datagrams (DLEP-Lite). > =A0 Whether or not this is a good idea, or acceptable to the manet group, > =A0 is yet to be determined. =A0 =A0" > > > Basically, DLEP and modemLPA are doing similar things. It is my understan= ding that DLEP is mainly targeted at providing information to directly atta= ched routers in ad hoc networks. > > ModemLPA is targeted are very simple deployment with a modem (or crypto d= evice or whatever) providing upstream entities with at least some minimal i= dea of what may be going on in the wireless link by periodically broadcasti= ng status or changes in status . =A0ModemLPA is looking at devices and appl= ications that may be multiple hops away. =A0Thus, if DLEP were used, one wo= uld operate in a "notification" or "broadcast" mode where status message wo= uld be sent to either unicast addresses, link-local multicast addresses or = scoped multicast addresses. =A0The upstream entities would simply listen of= the appropriate port. =A0No response would be required. > see - > http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01#page-8 > > For a general idea of modemLPA see - > http://roland.grc.nasa.gov/~ivancic/shared/modemLPA/ModemLPA.pdf > > Questions: > > 1) Is this a good idea? > > 2) Is this acceptable to the manet wg to be included as part of DLEP? > > 3) Should modemLPA remains a separate protocol? > > 3a) if so, should modemLPA use the DLEP message structure? > > > > - Will > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Fri Apr 20 23:57:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FD721F854E for ; Fri, 20 Apr 2012 23:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhGvwgih9uaX for ; Fri, 20 Apr 2012 23:57:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 098B321F854F for ; Fri, 20 Apr 2012 23:57:13 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2759006eaa.31 for ; Fri, 20 Apr 2012 23:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rfl1k95RYkAczC4Swua6tUF/NFd1pWIurBe+QgVAD7o=; b=WswNnale4RyN4xfxIw7vVB2dEKfL/erZaSMLdoO9OM6SZ/b/bYyZoQCZAN1K0onwD6 /+nNz4EP6890Uuppow5CmbZcE335UFOpMJaxzIieI7cjhyZ71FT/Y1YLEXFhPpza3bQs jUuo9+GBjWwtfaV0IrMYxlQStCM1fWl6pMikBGOS6RMQJRfd7FaZca86M1ptuZXQ5pry AITBf53M8zUTWk2gx8mqnfp2oFSX3H5IJ0r4wRAtr9q7Ja8b4ggpQAkc0KxM8v8T0PQ8 iBNGFljg6/JbLXp9Ky14G51hPdZdY4xNdAfVt7uM7ICZUcu70r6IJ1mMDelGXs5WqGku e/Rw== Received: by 10.213.21.204 with SMTP id k12mr454679ebb.109.1334991432771; Fri, 20 Apr 2012 23:57:12 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id q45sm37339460eem.7.2012.04.20.23.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Apr 2012 23:57:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sat, 21 Apr 2012 08:57:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkYyTbSoxBmYQppI4UBEqMHShFl98kXpmnSpcotDZFbh9nZWacVJDvqWHTdcBewJRmEg4AB Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 06:57:19 -0000 Thanks echoing. I think there is room for a simple protocol, that=20 just provide link info to be used for path calculation. DLEP looks flexible, but it is complex due to IMHO unneeded functions. I say the STD link exchange protocol MUST support 802.11 IBSS,=20 802.11S and infrastructure mode. This brings the default 802.11S=20 link metric (airtime / ETT), the optional BestThroughput (Minstrel,=20 available at Tx) and many-to-many support on the radio-router link.=20 And the 802.11S multi-hop sub-IP topology. (I've seen OSPF on top of=20 OLSR...). Sure the protocol MUST support other (some say better) media=20= access. 802.11* is just a standardized reference. I prefer a single STD protocol. Could be DLEP-Lite. Other options=20 are IMHO experimental. I already suggested to split off flow control and address negotiation. There are already better solutions for this. Teco Op 21 apr. 2012, om 01:10 heeft Henning Rogge het volgende geschreven: > We are still in the process of discussing how the mechanisms of DLEP > should work like. Teco already suggested that just multicasting the > layer-2 data regularly and listening by the clients should be a valid > usecase of DLEP. >=20 > At the moment the draft contains a lot of complexity, and I still do > not know why its necessary. I hope we will get this resolved. >=20 > Henning Rogge >=20 > On Fri, Apr 20, 2012 at 19:45, Ivancic, William D. (GRC-RHN0) > wrote: >>=20 >> From: >> http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01 >>=20 >> " The authors of modemLPA have been in discussion with the authors = of >> "Dynamic Link Exchange Protocol (DLEP)" determine >> if DLEP will fullfil the needs that ModemLPA is targeted >> at. DLEP is currently a client/server session oriented protocol = that >> provides link layer information to directly connected devices - >> generally routers. The Modem Link Property Advertisment protocol >> broadcasts link status notifications to directly-attached devices = and >> devices or applications that may be multiple hops away from the = modem >> (or other sending device). >>=20 >> It should be possible to use the DLEP message formats without all = the >> signalling required for the DLEP client/server session to perform = the >> functions addressed in this draft. The modem would simply provide >> link states out via multicast or unicast UDP datagrams (DLEP-Lite). >> Whether or not this is a good idea, or acceptable to the manet = group, >> is yet to be determined. " >>=20 >>=20 >> Basically, DLEP and modemLPA are doing similar things. It is my = understanding that DLEP is mainly targeted at providing information to = directly attached routers in ad hoc networks. >>=20 >> ModemLPA is targeted are very simple deployment with a modem (or = crypto device or whatever) providing upstream entities with at least = some minimal idea of what may be going on in the wireless link by = periodically broadcasting status or changes in status . ModemLPA is = looking at devices and applications that may be multiple hops away. = Thus, if DLEP were used, one would operate in a "notification" or = "broadcast" mode where status message would be sent to either unicast = addresses, link-local multicast addresses or scoped multicast addresses. = The upstream entities would simply listen of the appropriate port. No = response would be required. >> see - >> http://tools.ietf.org/html/draft-ivancic-mobopts-modemlpa-01#page-8 >>=20 >> For a general idea of modemLPA see - >> http://roland.grc.nasa.gov/~ivancic/shared/modemLPA/ModemLPA.pdf >>=20 >> Questions: >>=20 >> 1) Is this a good idea? >>=20 >> 2) Is this acceptable to the manet wg to be included as part of DLEP? >>=20 >> 3) Should modemLPA remains a separate protocol? >>=20 >> 3a) if so, should modemLPA use the DLEP message structure? >>=20 >>=20 >>=20 >> - Will >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Apr 21 01:50:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0F721F855D for ; Sat, 21 Apr 2012 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1DHp0aV9wc5 for ; Sat, 21 Apr 2012 01:50:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9521F85A5 for ; Sat, 21 Apr 2012 01:50:17 -0700 (PDT) Received: by lagj5 with SMTP id j5so8582761lag.31 for ; Sat, 21 Apr 2012 01:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xqR5OD4050kWlVUHfb66s84cin6XVI4Ig/+jNZMpRyM=; b=R7pjLCfsOuCTvd6UB1QHnX8qBmonupt9vXoLQRbdWcHkMCxuJCf/ajYrY661qEfNbB FDxJSANAs4nm4GbsLCMRoPSohb2P/hWP/GM4z9gwQLONQlMT7NEzJUm5BrvBR+xbASqp eFtHC6N7d0jRB3ZK4iE7oQghzIQj4+UiC/dbHQBGPXqzZTsrqsVhprqGnuAGOzzkbg44 IeLzjnV8HFf/6rx/nn+3ETwz7TUQxhPA+nYxpLZIavb/lQcRQMwkrOFZS2AUX7PSIzjc NwN0qZ1NiZuaNLyASjctkQealv9vUuvD7PVKaHn5Xr3G4JgxH2XOdiVfMR9R8d/xfDVx jvcw== Received: by 10.152.148.9 with SMTP id to9mr8549711lab.6.1334998216711; Sat, 21 Apr 2012 01:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sat, 21 Apr 2012 01:49:56 -0700 (PDT) In-Reply-To: <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> From: Henning Rogge Date: Sat, 21 Apr 2012 10:49:56 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 08:50:23 -0000 I am experimenting with a "simplified DLEP" implementation at the moment, which use UDP packets to transport linklayer data from the linux mac80211 stack. I skipped all the active parts (both Request Link Characteristics and the Token scheme) and reduced the rest to four message orders. Instead of using ACKs or Heartbeats, EVERY message contains a Validity-Time Message-TLV and has to be repeated within the interval to stay valid. This makes the whole session handling and state machine unnecessary without making the protocol unreliable on a lossy connection to the router (which should be unlikely anyways). Its a direct copy of the mechanisms of NHDP/OLSRv2. My current message orders are: 1) interface discovery (radio to router) Announce the presence of the radio interface via multicast. Can be used for autodiscovery of radios/modems. 2) neighbor address update (radio to router) A list of known direct neighbors. I plan to generate an additional one of this messages every times the linklayer detects a new neighbor or loose an old one. This can speed up neighbor discovery. 3) neighbor metric update (radio to router) Contains metric values of all neighbors. 4) connect router (router to radio) An optional message that can be sent to the radio to request getting all its messages also through unicast. What do you think? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Sat Apr 21 00:36:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EF921F8594 for ; Sat, 21 Apr 2012 00:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJzRcxvpRLtX for ; Sat, 21 Apr 2012 00:36:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2864821F858E for ; Sat, 21 Apr 2012 00:36:28 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3646281vcb.31 for ; Sat, 21 Apr 2012 00:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CUxKJc8Ewg3ue+p7+dsQRJAQUopjOYkHHa5mWDdD4hg=; b=kV2UvWkFnjd5wDynECBAfgwpb/ZFuKuHq6uAwTUu/98V+LIsI7HnwdiNGlOPT0uxH/ LKUITYQOA09ljP4Plo5TYd196DwvexjYJU448iq9d6gGFP+PwMexMtUSuGaiikW115V4 uuwJdV0JEVP09I6xSaGmyksUUJucjgk/KGPAq0eR1FYGVFBQvQdaPCu/EZosmIkC42Xm OUCAPEVVXP4+Z5UXXCBGAbSnMX5OH3WyT+Av4bTV0rZ+zDg4VOqgqu6N/LA7Yy0gLPbQ pOYOygfqC33e06jQbZRj6VZW1dDbJN99u3VM7KUwUbDaPaI25tK6cq7Z/jDjsIzor5YU V4sw== MIME-Version: 1.0 Received: by 10.52.23.10 with SMTP id i10mr6757302vdf.24.1334993787634; Sat, 21 Apr 2012 00:36:27 -0700 (PDT) Received: by 10.220.7.143 with HTTP; Sat, 21 Apr 2012 00:36:27 -0700 (PDT) Date: Sat, 21 Apr 2012 09:36:27 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 21 Apr 2012 17:55:55 -0700 Subject: Re: [manet] Does AODVv2 update DYMO? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 07:36:29 -0000 Hi While reading the manet-dymo-22 work in progress (AODVv2 protocol), commented as, # in Abstract The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest change> =93The Dynamic MANET On-demand (AODVv2)=94, to be changed to =93The Dynamic MANET On-demand Distance Vector (D-AODVv2)=94, because the term =93AODVv2=94 has letter =93A=94 which is presented in the second letter of the abbreviation word MANET, but AODVv2 has the D and V letters which is the abbreviation of Distance Vector. Regarding the word Dynamic an abbriviation =93D=94 preferable to be added. The =93v2=94 m= ay be left to indicate its origin protocol source-idea RFC3561 AODV, however, this can be explained in the overview. AB>general comment> AODVv2 is a routing protocol that determines unicast routes within the mobile routers. AB> due to mentioning the protocol route-determination and on-demand, It is useful to specify in abstract, to mention the protocol special method/technique (e.g. its name or what it uses) used for this determination and/or the convergence (i.e. to differentiate it from other reactive protocols for summary or future purposes). I still am reading the draft to full comment, Abdussalam Baryun University of Glamorgan Pontypridd, Wales, UK abdussalambaryun@gmail.com ++++++++++++++++++++++++++++++++++++++++++ On 3/20/12, Abdussalam Baryun wrote: > Hi, > > Reviewing the draft of AODVv2 (previously DYMO), I think the title confus= ed > me because I thought that AODVv2 is a new version of the AODV RFC3561, bu= t > I see that it is an update to the DYMO draft. > > In the introduction there is no reference to AODV FRC3561, which now AODV= v2 > has the similar name, it was not confusing in the previous DYMO_draft. I > think if mentioning RFC3561 in draft AODVv2 introduction is > preferable, to clarify its relationship with this work. > > The only related reference was seen in section 9 and 5.3.1 > > However, There are two questions I didn't understand: > 1- Will we see a new draft or version of DYMO or not? > 2- Is AODVv2 another routing protocol than RFC 3561? Please clarify, > > Abdussalam > ICRC, University of Glamorgan, UK > From teco@inf-net.nl Sat Apr 21 23:40:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5991721F847E for ; Sat, 21 Apr 2012 23:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FH3dyhVRL+m for ; Sat, 21 Apr 2012 23:40:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F49121F847D for ; Sat, 21 Apr 2012 23:40:44 -0700 (PDT) Received: by eeke51 with SMTP id e51so2917183eek.31 for ; Sat, 21 Apr 2012 23:40:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ol4UfrsILDrei0YE7ghMXT/706hlxcdAkUKapR7QIVE=; b=HT5vEGhAvWmEVwPYlOl8+jj+EnFOT+BI9Ckol6G4MjELTgAIe8auFy+P6/0dfhDSJY NqV9g0J8cWokqk2JoZiOxQC7Xy8Fdp6TwLGbOW07p039Rln1CxK7YS2oWOda6riXOyDN shmUqazjFymUHfesjRmWq+S52DoyVMGhTjti5lvyNCYEcnA8N+uTW5neEJoXN54vc4DQ mucbgPJsjH6Zy4XBQ277egRzofMDMYaM3kUVyG+wxO7ZiwNcbCHeyxEsU3dLO1hgr2C5 NuaXEdY9n4qnbq9NkwrXqBN2L0yLC+5T2SNDni/LjC5ilGTgeswLIML6tZMd3t8TCrdz Qslw== Received: by 10.213.3.66 with SMTP id 2mr290711ebm.187.1335076843516; Sat, 21 Apr 2012 23:40:43 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id q45sm51662120eem.7.2012.04.21.23.40.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Apr 2012 23:40:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 08:40:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlFXjWw47HjPEO3I8ikOZhtvTIxXF+XXcfZj3Jm86BraJTsFVuLR3k9MrtfSXemGAvxrwBk Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 06:40:46 -0000 Op 21 apr. 2012, om 10:49 heeft Henning Rogge het volgende geschreven: > I am experimenting with a "simplified DLEP" implementation at the > moment, which use UDP packets to transport linklayer data from the > linux mac80211 stack. > > I skipped all the active parts (both Request Link Characteristics and > the Token scheme) and reduced the rest to four message orders. > > Instead of using ACKs or Heartbeats, EVERY message contains a > Validity-Time Message-TLV and has to be repeated within the interval > to stay valid. This makes the whole session handling and state machine > unnecessary without making the protocol unreliable on a lossy > connection to the router (which should be unlikely anyways). Its a > direct copy of the mechanisms of NHDP/OLSRv2. > > > My current message orders are: > > 1) interface discovery (radio to router) > Announce the presence of the radio interface via multicast. Can be > used for autodiscovery of radios/modems. This is optional? For using a management port/vlan, and ports/vlans for data? It can be eliminated (see 4). I think the basic mode would be using a single interface, with filter blocking DLEP on the RF interface. Then, there is no need for interface discovery. > > 2) neighbor address update (radio to router) > A list of known direct neighbors. > I plan to generate an additional one of this messages every times the > linklayer detects a new neighbor or loose an old one. This can speed > up neighbor discovery. Why? Metric updates provides the neighbors. This needs triggered updates anyway. > > 3) neighbor metric update (radio to router) > Contains metric values of all neighbors. I think we need only incremental updates (lots of small messages). Use a HighestValue (or whatever) metric for lost neighbors. Most lost neighbors would have increasing metrics, towards what practically equals to lost. > > 4) connect router (router to radio) > An optional message that can be sent to the radio to request getting > all its messages also through unicast. Useful. On wired connections, multicast should not be a problem. Maybe TCP for flow control, preventing overruns (CPU, buffers) on router. It also provides a trigger for DB transfer, in case the router lost state. The "also" could be weakened. For a 1-to-1 relation between radio and router, with unicast, the multicast could be stopped. This suppression needs valid_time, so the radio starts multicasting when state of the router is lost. You could combine 1 & 4. Radio simply multicasts neighbor state, until it is told to do it different. Router multicasts: please send your DLEP info with [ tcp | udp | other ] on interface [ this | vlan nn | other ], duration [ valid_time], and [ do | do_not] suppress multicast. > > What do you think? I like simple and efficient protocols, which do exactly what is needed. Nothing less, nothing more. I think you took the right approach. Teco > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Sun Apr 22 00:34:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147121F8652 for ; Sun, 22 Apr 2012 00:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYMcxbt7+MTS for ; Sun, 22 Apr 2012 00:34:37 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88B21F85A5 for ; Sun, 22 Apr 2012 00:34:36 -0700 (PDT) Received: by lagj5 with SMTP id j5so8946970lag.31 for ; Sun, 22 Apr 2012 00:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EafKmR/Yaogy/sMCm5AkVOBY+RsoDNaRNTrLRN4QXkk=; b=S9/yeZZuMyyqx0mkuoMYhdr8qteQh/hFjukAd0FbcBoQb8sHinTrZdK/0NMLAdej+x EABGl4fQPrAVzAF5Q4yjvDc9pPQtRI6kICx95mLhYYK1CHdv3Fze2iHEC5yeV6Sk9ePf D6lK+HtSXScdLSCAts1dI5WK72FRAQ1PdOLJx2+P2JRT20irQF/ZwMrQeUZ0X9C2XfH7 +rGFkHUOyauBZSC4KvBJeemnFJp1Lrj4NS4fUQhwB+pqU9vRUKzuRIKgYrdTsxbDD6e5 A0rbVTIhV460FQ9LO5qxpe5bTeFPFTaLiwSL5Anw9zAC6xvCxFu+bmnpVTdt2RlG19nD A1wA== Received: by 10.152.103.134 with SMTP id fw6mr11351789lab.20.1335080076104; Sun, 22 Apr 2012 00:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sun, 22 Apr 2012 00:34:15 -0700 (PDT) In-Reply-To: <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> From: Henning Rogge Date: Sun, 22 Apr 2012 09:34:15 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 07:34:38 -0000 On Sun, Apr 22, 2012 at 08:40, Teco Boot wrote: > > Op 21 apr. 2012, om 10:49 heeft Henning Rogge het volgende geschreven: > >> I am experimenting with a "simplified DLEP" implementation at the >> moment, which use UDP packets to transport linklayer data from the >> linux mac80211 stack. >> >> I skipped all the active parts (both Request Link Characteristics and >> the Token scheme) and reduced the rest to four message orders. >> >> Instead of using ACKs or Heartbeats, EVERY message contains a >> Validity-Time Message-TLV and has to be repeated within the interval >> to stay valid. This makes the whole session handling and state machine >> unnecessary without making the protocol unreliable on a lossy >> connection to the router (which should be unlikely anyways). Its a >> direct copy of the mechanisms of NHDP/OLSRv2. >> >> >> My current message orders are: >> >> 1) interface discovery (radio to router) >> Announce the presence of the radio interface via multicast. Can be >> used for autodiscovery of radios/modems. > This is optional? For using a management port/vlan, and > ports/vlans for data? It can be eliminated (see 4). But then you would need to know the IP address of the radio. If you are willing to configure it, this could be skipped. You could switch this off in my code by setting the Radio Discovery Interval to zero. > I think the basic mode would be using a single interface, with > filter blocking DLEP on the RF interface. Then, there is no need > for interface discovery. There is still the question for the IP address. Unless your DLEP-Service is on the same node than your router (in which case DLEP is just a hardware abstraction layer). >> 2) neighbor address update (radio to router) >> A list of known direct neighbors. >> I plan to generate an additional one of this messages every times the >> linklayer detects a new neighbor or loose an old one. This can speed >> up neighbor discovery. > Why? Metric updates provides the neighbors. This needs triggered > updates anyway. I want a message type I can send when the link layer loose a neighbor. Theoretically, this messages could be joined with the metric update. >> 3) neighbor metric update (radio to router) >> Contains metric values of all neighbors. > I think we need only incremental updates (lots of small messages). > Use a HighestValue (or whatever) metric for lost neighbors. > Most lost neighbors would have increasing metrics, towards > what practically equals to lost. I think a single "link lost" TLV would be better than have special values for metrics. Incremental updates are already possible in my current code, as long as you repeat one metric at least once every Validity Time. A new message does not overwrite the old database entry at the moment, it just overwrites the new metric values of the database entry and resets the validity time. I have no "per metric value" validity time planned. >> 4) connect router (router to radio) >> An optional message that can be sent to the radio to request getting >> all its messages also through unicast. > Useful. On wired connections, multicast should not be a problem. > Maybe TCP for flow control, preventing overruns (CPU, buffers) on router. > It also provides a trigger for DB transfer, in case the router lost state. TCP doesn't work well with RFC 5444, because it does not contain a total "length" packet. UDP is a much easier way to do this. In addition to this the kernel can simply throw away UDP packets when overloaded. > The "also" could be weakened. For a 1-to-1 relation between radio and > router, with unicast, the multicast could be stopped. This suppression > needs valid_time, so the radio starts multicasting when state of the > router is lost. Hmm... I am not sure I like this. By keep repeating the Interface Discovery and Connect Router every Validity Time, i get the information on both sides that the connection between router and radio/modem is still present. > You could combine 1 & 4. Radio simply multicasts neighbor state, until > it is told to do it different. Router multicasts: please send your DLEP > info with [ tcp | udp | other ] on interface [ this | vlan nn | other ], > duration [ valid_time], and [ do | do_not] suppress multicast. I am not sure I like this, but it could be done... I would like to keep the protocol practically stateless, with easy ways to support multiple radios on a router and multiple layer-2 data-consumers (one router, one logging system) getting data from a radio. >> What do you think? > I like simple and efficient protocols, which do exactly what is needed. > Nothing less, nothing more. I think you took the right approach. Thank you. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Sun Apr 22 03:48:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02821F85B8 for ; Sun, 22 Apr 2012 03:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT4lkyRS3r8m for ; Sun, 22 Apr 2012 03:48:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0736821F85A2 for ; Sun, 22 Apr 2012 03:48:21 -0700 (PDT) Received: by eeke51 with SMTP id e51so2940953eek.31 for ; Sun, 22 Apr 2012 03:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fbgoGymtx75oKxcpvpdAmEBaqZOFUHazAugt08qvbZo=; b=o/3FwTu/IMXQ8Fm9KvFz+ZyTxj2BAhasRf/AZ5aKKndoyo6/KwGFyoGQFrJOYaLchI ofqqX6RSBYxYAmNzlYdcZtGSUS3GAHM3z9uSZ6freUC97njjtF/iirZe7zkLY/lRrCtU t/58L2v2YqLrSnbCQR06Oc7iF9NLY7rVmZsTNgsidMAJplc/899FfRAJAJgw5KBGqkPP 2uy0Th7VGxPziddPMb+8nlMnganW/0cCv8tWZhktObdNG5uGjm+NlLB9sWRtKjWitvyr G8ZEWOZYqX4JvyDVpybaDsrZqOAqiJwW3zcZXYvvtLBdO5kJql3OzZp+4vkCxq5liPXG CXiQ== Received: by 10.213.17.2 with SMTP id q2mr1019147eba.4.1335091700310; Sun, 22 Apr 2012 03:48:20 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r44sm54212410eef.2.2012.04.22.03.48.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 03:48:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 12:48:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlHme5Q+Kb+OoTQJ4GGHYWCJOLNuF88eCyclLGfDqBNIpZRyeE7TDqpaWWmi7VXkga3rv5y Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:48:23 -0000 Op 22 apr. 2012, om 09:34 heeft Henning Rogge het volgende geschreven: > On Sun, Apr 22, 2012 at 08:40, Teco Boot wrote: >> >> Op 21 apr. 2012, om 10:49 heeft Henning Rogge het volgende geschreven: >> >>> I am experimenting with a "simplified DLEP" implementation at the >>> moment, which use UDP packets to transport linklayer data from the >>> linux mac80211 stack. >>> >>> I skipped all the active parts (both Request Link Characteristics and >>> the Token scheme) and reduced the rest to four message orders. >>> >>> Instead of using ACKs or Heartbeats, EVERY message contains a >>> Validity-Time Message-TLV and has to be repeated within the interval >>> to stay valid. This makes the whole session handling and state machine >>> unnecessary without making the protocol unreliable on a lossy >>> connection to the router (which should be unlikely anyways). Its a >>> direct copy of the mechanisms of NHDP/OLSRv2. >>> >>> >>> My current message orders are: >>> >>> 1) interface discovery (radio to router) >>> Announce the presence of the radio interface via multicast. Can be >>> used for autodiscovery of radios/modems. >> This is optional? For using a management port/vlan, and >> ports/vlans for data? It can be eliminated (see 4). > But then you would need to know the IP address of the radio. If you > are willing to configure it, this could be skipped. Msg_3 provides the IP address (or MAC address, for one that likes L2). Msg_4 is unicast towards this address. If the protocol switches to unicast, there is no need for VLANs or DLEP filter (to prevent DLEP flooding on RF). > You could switch this off in my code by setting the Radio Discovery > Interval to zero. You could remove the code :-), this function is not needed. >> I think the basic mode would be using a single interface, with >> filter blocking DLEP on the RF interface. Then, there is no need >> for interface discovery. > There is still the question for the IP address. Unless your > DLEP-Service is on the same node than your router (in which case DLEP > is just a hardware abstraction layer). I would say that id one wants a multi-hop L3 path between radio and router, configuration is needed. If it is only a single L2 link, discovery is easy, using msg_3. >>> 2) neighbor address update (radio to router) >>> A list of known direct neighbors. >>> I plan to generate an additional one of this messages every times the >>> linklayer detects a new neighbor or loose an old one. This can speed >>> up neighbor discovery. >> Why? Metric updates provides the neighbors. This needs triggered >> updates anyway. > I want a message type I can send when the link layer loose a neighbor. > Theoretically, this messages could be joined with the metric update. It is the same function, lower complexity and more efficient. >>> 3) neighbor metric update (radio to router) >>> Contains metric values of all neighbors. >> I think we need only incremental updates (lots of small messages). >> Use a HighestValue (or whatever) metric for lost neighbors. >> Most lost neighbors would have increasing metrics, towards >> what practically equals to lost. > I think a single "link lost" TLV would be better than have special > values for metrics. It is taste. Or religion. It is a special TLV or a special value. With special value, DLEP-lite needs only a single (dimensionless...) metric TLV. All other TLVs are extensions, and IMHO optional / experimental. More important, do not expect compatibility from the other TLVs. > Incremental updates are already possible in my current code, as long > as you repeat one metric at least once every Validity Time. A new > message does not overwrite the old database entry at the moment, it > just overwrites the new metric values of the database entry and resets > the validity time. :-) > I have no "per metric value" validity time planned. Not needed. Could be done with separate messages. >>> 4) connect router (router to radio) >>> An optional message that can be sent to the radio to request getting >>> all its messages also through unicast. >> Useful. On wired connections, multicast should not be a problem. >> Maybe TCP for flow control, preventing overruns (CPU, buffers) on router. >> It also provides a trigger for DB transfer, in case the router lost state. > > TCP doesn't work well with RFC 5444, because it does not contain a > total "length" packet. UDP is a much easier way to do this. In > addition to this the kernel can simply throw away UDP packets when > overloaded. IP protocol would be OK also. >> The "also" could be weakened. For a 1-to-1 relation between radio and >> router, with unicast, the multicast could be stopped. This suppression >> needs valid_time, so the radio starts multicasting when state of the >> router is lost. > Hmm... I am not sure I like this. By keep repeating the Interface > Discovery and Connect Router every Validity Time, i get the > information on both sides that the connection between router and > radio/modem is still present. Why? The router to radio unicast will not be forwarded over RF link. The effect is that the radio sends DLEP to router only. The DLEP filter in the radio is needed anyway, blocking multicast on RF-link. >> You could combine 1 & 4. Radio simply multicasts neighbor state, until >> it is told to do it different. Router multicasts: please send your DLEP >> info with [ tcp | udp | other ] on interface [ this | vlan nn | other ], >> duration [ valid_time], and [ do | do_not] suppress multicast. > I am not sure I like this, but it could be done... I would like to > keep the protocol practically stateless, Me to !!! > with easy ways to support > multiple radios on a router and multiple layer-2 data-consumers (one > router, one logging system) getting data from a radio. My suggestion to suppress DLEP multicast blocks auto-discovery for multiple consumers. Easy to fix: let the radio send out a multicast message every now and then. Could be empty "announcement" packet. Teco > >>> What do you think? >> I like simple and efficient protocols, which do exactly what is needed. >> Nothing less, nothing more. I think you took the right approach. > Thank you. > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From teco@inf-net.nl Sun Apr 22 03:58:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B932321F85C9 for ; Sun, 22 Apr 2012 03:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58KopjZFIp3A for ; Sun, 22 Apr 2012 03:58:41 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C29C21F85B8 for ; Sun, 22 Apr 2012 03:58:40 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2912543eaa.31 for ; Sun, 22 Apr 2012 03:58:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6UZfVSeqEll6Ju0RYwGDO4bnCcVnyM40ZPZfmsjRclo=; b=Jw0Nxq3dMRdT2wgprb7v+XPAM/kkb7RNHWipi6MG26lp84BEVi7LGybetqYvhoxQfN gPe1e+6wqkm2xfdT3mdurRgCptxk70ONCNq3CLaouu/h091kafsW2fuvyJkrlGI4HhCU mlVQwznRhxr3WzDl7jI0cNnm6WDvpeN3GfLAmO3pbNStbboJEArkcCQqacGjabbFOw9s zsfrh605ZT2JOszQ4L/6Y52H0LvSLvD03gj24VI+BBBqisRVHqxpAg4T98Xfk8F2hO0e A/+osiyfWQs8vIXLQsgEaMv/SduSiaC8RUNm/4hImMqgDbV998rnBWac9a9vbc9ggBM4 7+9Q== Received: by 10.213.8.71 with SMTP id g7mr636697ebg.139.1335092319383; Sun, 22 Apr 2012 03:58:39 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r44sm54319153eef.2.2012.04.22.03.58.37 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 03:58:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 12:58:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmsPtgyPtNRtyRNXjeHHnBFy+HaZNVsvNdoJtjqRh2MK1Nj7qarsk7QRhnZIDicWAN4KiKz Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 10:58:41 -0000 Op 22 apr. 2012, om 12:48 heeft Teco Boot het volgende geschreven: >=20 > Op 22 apr. 2012, om 09:34 heeft Henning Rogge het volgende geschreven: >=20 >> On Sun, Apr 22, 2012 at 08:40, Teco Boot wrote: >>>=20 >>> Op 21 apr. 2012, om 10:49 heeft Henning Rogge het volgende = geschreven: >>>=20 >>>> I am experimenting with a "simplified DLEP" implementation at the >>>> moment, which use UDP packets to transport linklayer data from the >>>> linux mac80211 stack. >>>>=20 >>>> I skipped all the active parts (both Request Link Characteristics = and >>>> the Token scheme) and reduced the rest to four message orders. >>>>=20 >>>> Instead of using ACKs or Heartbeats, EVERY message contains a >>>> Validity-Time Message-TLV and has to be repeated within the = interval >>>> to stay valid. This makes the whole session handling and state = machine >>>> unnecessary without making the protocol unreliable on a lossy >>>> connection to the router (which should be unlikely anyways). Its a >>>> direct copy of the mechanisms of NHDP/OLSRv2. >>>>=20 >>>>=20 >>>> My current message orders are: >>>>=20 >>>> 1) interface discovery (radio to router) >>>> Announce the presence of the radio interface via multicast. Can be >>>> used for autodiscovery of radios/modems. >>> This is optional? For using a management port/vlan, and >>> ports/vlans for data? It can be eliminated (see 4). >> But then you would need to know the IP address of the radio. If you >> are willing to configure it, this could be skipped. > Msg_3 provides the IP address (or MAC address, for one that likes L2). > Msg_4 is unicast towards this address. > If the protocol switches to unicast, there is no need for VLANs=20 > or DLEP filter (to prevent DLEP flooding on RF). >=20 >> You could switch this off in my code by setting the Radio Discovery >> Interval to zero. > You could remove the code :-), this function is not needed. Msg_1 is the announcement packet, so the function is needed Thereafter, Msg_4 is send, where the router requests data. Then, Msg_3 (and Msg_2) are send. On Msg_2: do you provide L2/L3 address mapping? Why not trigger router=20= HELLO and ARP/NDP? I don't like DLEP-related info over RF-link. We = cannot assume DLEP radio has any idea on L3-stuff on other sides. Teco >>> I think the basic mode would be using a single interface, with >>> filter blocking DLEP on the RF interface. Then, there is no need >>> for interface discovery. >> There is still the question for the IP address. Unless your >> DLEP-Service is on the same node than your router (in which case DLEP >> is just a hardware abstraction layer). > I would say that id one wants a multi-hop L3 path between radio and > router, configuration is needed. > If it is only a single L2 link, discovery is easy, using msg_3. >=20 >>>> 2) neighbor address update (radio to router) >>>> A list of known direct neighbors. >>>> I plan to generate an additional one of this messages every times = the >>>> linklayer detects a new neighbor or loose an old one. This can = speed >>>> up neighbor discovery. >>> Why? Metric updates provides the neighbors. This needs triggered >>> updates anyway. >> I want a message type I can send when the link layer loose a = neighbor. >> Theoretically, this messages could be joined with the metric update. > It is the same function, lower complexity and more efficient. >=20 >>>> 3) neighbor metric update (radio to router) >>>> Contains metric values of all neighbors. >>> I think we need only incremental updates (lots of small messages). >>> Use a HighestValue (or whatever) metric for lost neighbors. >>> Most lost neighbors would have increasing metrics, towards >>> what practically equals to lost. >> I think a single "link lost" TLV would be better than have special >> values for metrics. > It is taste. Or religion. It is a special TLV or a special value. >=20 > With special value, DLEP-lite needs only a single (dimensionless...)=20= > metric TLV. All other TLVs are extensions, and IMHO optional / = experimental.=20 > More important, do not expect compatibility from the other TLVs. >=20 >> Incremental updates are already possible in my current code, as long >> as you repeat one metric at least once every Validity Time. A new >> message does not overwrite the old database entry at the moment, it >> just overwrites the new metric values of the database entry and = resets >> the validity time. > :-) >=20 >> I have no "per metric value" validity time planned. > Not needed. Could be done with separate messages. >=20 >>>> 4) connect router (router to radio) >>>> An optional message that can be sent to the radio to request = getting >>>> all its messages also through unicast. >>> Useful. On wired connections, multicast should not be a problem. >>> Maybe TCP for flow control, preventing overruns (CPU, buffers) on = router. >>> It also provides a trigger for DB transfer, in case the router lost = state. >>=20 >> TCP doesn't work well with RFC 5444, because it does not contain a >> total "length" packet. UDP is a much easier way to do this. In >> addition to this the kernel can simply throw away UDP packets when >> overloaded. > IP protocol would be OK also. >=20 >>> The "also" could be weakened. For a 1-to-1 relation between radio = and >>> router, with unicast, the multicast could be stopped. This = suppression >>> needs valid_time, so the radio starts multicasting when state of the >>> router is lost. >> Hmm... I am not sure I like this. By keep repeating the Interface >> Discovery and Connect Router every Validity Time, i get the >> information on both sides that the connection between router and >> radio/modem is still present. > Why? The router to radio unicast will not be forwarded over RF link. > The effect is that the radio sends DLEP to router only. >=20 > The DLEP filter in the radio is needed anyway, blocking multicast on = RF-link. >=20 >>> You could combine 1 & 4. Radio simply multicasts neighbor state, = until >>> it is told to do it different. Router multicasts: please send your = DLEP >>> info with [ tcp | udp | other ] on interface [ this | vlan nn | = other ], >>> duration [ valid_time], and [ do | do_not] suppress multicast. >> I am not sure I like this, but it could be done... I would like to >> keep the protocol practically stateless, > Me to !!! >=20 >> with easy ways to support >> multiple radios on a router and multiple layer-2 data-consumers (one >> router, one logging system) getting data from a radio. > My suggestion to suppress DLEP multicast blocks auto-discovery for = multiple=20 > consumers. Easy to fix: let the radio send out a multicast message = every now=20 > and then. Could be empty "announcement" packet. >=20 > Teco >=20 >>=20 >>>> What do you think? >>> I like simple and efficient protocols, which do exactly what is = needed. >>> Nothing less, nothing more. I think you took the right approach. >> Thank you. >>=20 >> Henning Rogge >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >=20 From hrogge@googlemail.com Sun Apr 22 04:48:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D521F856D for ; Sun, 22 Apr 2012 04:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfxTC2DXKv1n for ; Sun, 22 Apr 2012 04:48:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6121F8562 for ; Sun, 22 Apr 2012 04:48:40 -0700 (PDT) Received: by lagj5 with SMTP id j5so9009334lag.31 for ; Sun, 22 Apr 2012 04:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FZAqgHokdojjiylYPVY87NQkdWDWNRZRmn3qwdbBOvw=; b=h9Km6xYYUZtbM716QWQJp77ppPkioB34/mJdbOXVz5J0n/i7vqkM+ND3+nnV+zzrtr lZpvb5pNSPkUF+SKkRECQhx7OJZ0f/B67BuYQHKBsCQNeqX0pOx612Y7eXbv43KS/pEF HUvojOyVbD2MS55iZw4N2jqunQBPNJxPIdtMVCDuOsXn6m7quoh8rNapXqFrqSm9o2fQ /a5JVxfJH+pCcAX+asGlsNYYuoOXXOP9r9u2sHR2w5ilWoUGn7QHua2H18+hpd7euURX aUTZZ/WPUVafX1m+nlbssRvD/KyATULxlN+Hq6DUqi5hGJenXLU3iqW3b05JiMiEg9dU N8fA== Received: by 10.112.24.197 with SMTP id w5mr634564lbf.83.1335095319238; Sun, 22 Apr 2012 04:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sun, 22 Apr 2012 04:48:19 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> From: Henning Rogge Date: Sun, 22 Apr 2012 13:48:19 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 11:48:41 -0000 On Sun, Apr 22, 2012 at 12:48, Teco Boot wrote: > Msg_3 provides the IP address (or MAC address, for one that likes L2). > Msg_4 is unicast towards this address. This is an interesting idea, yes. > If the protocol switches to unicast, there is no need for VLANs > or DLEP filter (to prevent DLEP flooding on RF). I am not sure this works well, especially if you want to bridge the radio and the router interface on the radio. Especially with IEEE802.11 radios, you will run into problems because of the mac addresses. >> You could switch this off in my code by setting the Radio Discovery >> Interval to zero. > You could remove the code :-), this function is not needed. If an "empty" Neighbor Update message is valid, this could work out well (Interface discovery without a radio neighbor in range). >>> I think the basic mode would be using a single interface, with >>> filter blocking DLEP on the RF interface. Then, there is no need >>> for interface discovery. >> There is still the question for the IP address. Unless your >> DLEP-Service is on the same node than your router (in which case DLEP >> is just a hardware abstraction layer). > I would say that id one wants a multi-hop L3 path between radio and > router, configuration is needed. > If it is only a single L2 link, discovery is easy, using msg_3. Yes. >>>> 3) neighbor metric update (radio to router) >>>> Contains metric values of all neighbors. >>> I think we need only incremental updates (lots of small messages). >>> Use a HighestValue (or whatever) metric for lost neighbors. >>> Most lost neighbors would have increasing metrics, towards >>> what practically equals to lost. >> I think a single "link lost" TLV would be better than have special >> values for metrics. > It is taste. Or religion. It is a special TLV or a special value. > > With special value, DLEP-lite needs only a single (dimensionless...) > metric TLV. All other TLVs are extensions, and IMHO optional / experimental. > More important, do not expect compatibility from the other TLVs. I totally disagree with this. I don't even think the "dimensionless" metric TLV is really useful for DLEP, because the router would not know what this value is about. This whole "hiding information from the radio" is a bad idea in a lot of cases. And even with this, the "dimensionless metric" would have to be a special case, otherwise an "infinite" metric there would not mean the other DLEP metrics become "infinite" too. DLEP is for transporting layer-2 data from the radio to the router, so the router can calculate the metric. So I would consider the raw metric data (and not some precalculated value) important. >> Incremental updates are already possible in my current code, as long >> as you repeat one metric at least once every Validity Time. A new >> message does not overwrite the old database entry at the moment, it >> just overwrites the new metric values of the database entry and resets >> the validity time. > :-) > >> I have no "per metric value" validity time planned. > Not needed. Could be done with separate messages. Not with my current implementation, because the database that stores the metric values have only one validity time per set of metrics for a neighbor. >>>> 4) connect router (router to radio) >>>> An optional message that can be sent to the radio to request getting >>>> all its messages also through unicast. >>> Useful. On wired connections, multicast should not be a problem. >>> Maybe TCP for flow control, preventing overruns (CPU, buffers) on router. >>> It also provides a trigger for DB transfer, in case the router lost state. >> >> TCP doesn't work well with RFC 5444, because it does not contain a >> total "length" packet. UDP is a much easier way to do this. In >> addition to this the kernel can simply throw away UDP packets when >> overloaded. > IP protocol would be OK also. As long as it is packet and not stream based, it should work out fine. IP, UDP, it doesn't matter that much. >>> The "also" could be weakened. For a 1-to-1 relation between radio and >>> router, with unicast, the multicast could be stopped. This suppression >>> needs valid_time, so the radio starts multicasting when state of the >>> router is lost. >> Hmm... I am not sure I like this. By keep repeating the Interface >> Discovery and Connect Router every Validity Time, i get the >> information on both sides that the connection between router and >> radio/modem is still present. > Why? The router to radio unicast will not be forwarded over RF link. > The effect is that the radio sends DLEP to router only. > > The DLEP filter in the radio is needed anyway, blocking multicast on RF-link. I don't think this "bridging everything together" will work well in all cases. Especially with IEE802.11 >>> You could combine 1 & 4. Radio simply multicasts neighbor state, until >>> it is told to do it different. Router multicasts: please send your DLEP >>> info with [ tcp | udp | other ] on interface [ this | vlan nn | other ], >>> duration [ valid_time], and [ do | do_not] suppress multicast. >> I am not sure I like this, but it could be done... I would like to >> keep the protocol practically stateless, > Me to !!! > >> with easy ways to support >> multiple radios on a router and multiple layer-2 data-consumers (one >> router, one logging system) getting data from a radio. > My suggestion to suppress DLEP multicast blocks auto-discovery for multiple > consumers. Easy to fix: let the radio send out a multicast message every now > and then. Could be empty "announcement" packet. Hmm... I think just keep the linklocal multicast with the radio data might be easier. The radio can start sending out unicasts if necessary in addition to this. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sun Apr 22 04:52:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5E21F85FB for ; Sun, 22 Apr 2012 04:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENVdcDrX8Qei for ; Sun, 22 Apr 2012 04:52:08 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E099521F85EF for ; Sun, 22 Apr 2012 04:52:07 -0700 (PDT) Received: by lbgc1 with SMTP id c1so4083238lbg.31 for ; Sun, 22 Apr 2012 04:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rFy56blBksSze8LxgS19R16fpalO0ANZLz0riqTMtjg=; b=d3ymSaCOTSTZY0rif1qH0jnWdu1Ce1c1p56BYsL4WakZ2khwnArXq720Uolsf0rAgZ eCvDrK9dAD0fKK0SjjQdbAPdcUukYCywCzaYYI/zyRDb+yGij5P7AwJ/aN6opxKgg9KL cRc5LHfgiVba3ClCwqP5NqIy8ceolvYCHkAF3rOjoogG82dXFpzsNy1lqbsN+U5JSE1v 7O+qB49gTf05xi6c0yCiBG3FQyPJUy36ww6fTZmn89Nx7BKBiazt1G5OhzaAE98evJ/6 LslJUnJdM18xp88hHOQSnocqoUjoGLHbAoVVOH2FEzbCLbGXsvTC4wg9w7hGcUbqxGPK EuXw== Received: by 10.112.24.197 with SMTP id w5mr639389lbf.83.1335095526921; Sun, 22 Apr 2012 04:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sun, 22 Apr 2012 04:51:46 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> From: Henning Rogge Date: Sun, 22 Apr 2012 13:51:46 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 11:52:09 -0000 On Sun, Apr 22, 2012 at 12:58, Teco Boot wrote: >>> You could switch this off in my code by setting the Radio Discovery >>> Interval to zero. >> You could remove the code :-), this function is not needed. > Msg_1 is the announcement packet, so the function is needed > Thereafter, Msg_4 is send, where the router requests data. > Then, Msg_3 (and Msg_2) are send. Yes, thats how it works at the moment... Msg_1 is just "I am here and that is the MAC address of my radio". > On Msg_2: do you provide L2/L3 address mapping? Why not trigger router > HELLO and ARP/NDP? I don't like DLEP-related info over RF-link. We cannot > assume DLEP radio has any idea on L3-stuff on other sides. At the moment my DLEP implementation does transport any layer-2 information about the radio to the router, because in my current usecase the DLEP-Server (the radio) will not even have an IP set for the radio interface. It will just bridge it on layer-2 to the ethernet. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Sun Apr 22 05:14:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E497821F85E6 for ; Sun, 22 Apr 2012 05:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVBl00iNgwKH for ; Sun, 22 Apr 2012 05:14:31 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED6CE21F85DD for ; Sun, 22 Apr 2012 05:14:30 -0700 (PDT) Received: by eeke51 with SMTP id e51so2950124eek.31 for ; Sun, 22 Apr 2012 05:14:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7oRnt1qQS53nqMr8330bo48Bs1pT/A6oBMVbPYMp+Qk=; b=fajZo/PMZrF8dTTjgur7FuAs+EmK/fslqVPniaQXFFXn61LV2uJq+qdp9+1+fvmDc1 t9dN8++xrH9iaofLfnx6p8hSbC2jG/vMIak5IuEBum8wIHdmgx6suFkb6uSB3Nl0dyNo eRGoyfslxSFwiaOgIG6dIPSy8sDbIv68X/jn+iSs4JNRj3kspOlQ3e2mCv2eAtDgXNxy OxswoJbJivVAmdeWPv3v0M4w/h+9GQLMKZ+zYu4r5qq/cCust+Jk1ieC1eLFESJh3KBZ j93srKw7AJ5/q4kUtzIktlPwGXKunh+A/pQPxuU8jUQhaiwsDzoGoKT/TvBxEy3cl5IH NhQQ== Received: by 10.213.13.20 with SMTP id z20mr1048661ebz.191.1335096869333; Sun, 22 Apr 2012 05:14:29 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m42sm55110294eef.0.2012.04.22.05.14.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 05:14:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 14:14:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: <26E1A9DF-7F95-49ED-A909-C1BB70F29809@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl2EWowynJAST50XuQ1f4orru+FPeaddNuA6/atCR+OJTZOmiaFNj+y1SXhUhh9PXzNiqkO Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 12:14:32 -0000 Op 22 apr. 2012, om 13:51 heeft Henning Rogge het volgende geschreven: > >> On Msg_2: do you provide L2/L3 address mapping? Why not trigger router >> HELLO and ARP/NDP? I don't like DLEP-related info over RF-link. We cannot >> assume DLEP radio has any idea on L3-stuff on other sides. > > At the moment my DLEP implementation does transport any layer-2 > information about the radio to the router, because in my current > usecase the DLEP-Server (the radio) will not even have an IP set for > the radio interface. It will just bridge it on layer-2 to the > ethernet. DLEP describes some kind of address resolving for far-end neighbors. This overlaps with hello & arp/ndp. You do not implement such, and let the router take care of L3. Better approach. Teco > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From teco@inf-net.nl Sun Apr 22 05:30:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4CA21F85E4 for ; Sun, 22 Apr 2012 05:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns5+yv30jwsE for ; Sun, 22 Apr 2012 05:30:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F241B21F85BB for ; Sun, 22 Apr 2012 05:30:16 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2922100eaa.31 for ; Sun, 22 Apr 2012 05:30:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+0T0wdT7nQUPsACXPZjaLfwXlaXc1D+dl2UnMImwTUE=; b=ExpBOOvEDX5K30TEfDcapDxMd8HNeXc2eshHVhHSmBEETBo7ynabK0IpG+kNNbmjaI AuszIjFF90tpTsq1/WpdOIFTdk8W7X1DBwy/py9vXkM7FTREFUeZOshXAHDsLAbh16ZW M8Hs0x2M6JeAFoorpOrj4Aa1+kkdovatjrj0sOQ+WUXRN0pvskbEf7FRmTg8taK6QCIB pHwcMrqCL9flPlA9HzvORffhAgPkfqYMIPkJzKWvSesTR2ie/m+SH7s6Me+gEMInlmmP OgnSfRrSJPvgYAz6Iq9FMXJPIeCFrVnfdT4p+295shT0JonSOhFJlIjrvKw6LGLLjOBg L99A== Received: by 10.14.96.136 with SMTP id r8mr261756eef.121.1335097815499; Sun, 22 Apr 2012 05:30:15 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id n55sm55233509eef.6.2012.04.22.05.30.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 05:30:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 14:30:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlRd+U4oYFip91mbFxBBK9pNv+LeLUHz5Jq2lM6q2UECmA+K7R4N2Fl3y1o85CmulNZGKip Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 12:30:22 -0000 Op 22 apr. 2012, om 13:48 heeft Henning Rogge het volgende geschreven: >> If the protocol switches to unicast, there is no need for VLANs >> or DLEP filter (to prevent DLEP flooding on RF). > I am not sure this works well, especially if you want to bridge the > radio and the router interface on the radio. Especially with > IEEE802.11 radios, you will run into problems because of the mac > addresses. It is solved in 802.11S. Or IBSS with 4-address mode. Vanilla 802.11=20 stack needs some kind of repeater, as you mentioned some time ago. >>>>> 3) neighbor metric update (radio to router) >>>>> Contains metric values of all neighbors. >>>> I think we need only incremental updates (lots of small messages). >>>> Use a HighestValue (or whatever) metric for lost neighbors. >>>> Most lost neighbors would have increasing metrics, towards >>>> what practically equals to lost. >>> I think a single "link lost" TLV would be better than have special >>> values for metrics. >> It is taste. Or religion. It is a special TLV or a special value. >>=20 >> With special value, DLEP-lite needs only a single (dimensionless...) >> metric TLV. All other TLVs are extensions, and IMHO optional / = experimental. >> More important, do not expect compatibility from the other TLVs. > I totally disagree with this. I don't even think the "dimensionless" > metric TLV is really useful for DLEP, because the router would not > know what this value is about. This whole "hiding information from the > radio" is a bad idea in a lot of cases. Not every user will write it's own metric calculation routine. How is it=20= guaranteed any DLEP implementation is interoperable? We need a minimum set that MUST be implemented. > And even with this, the "dimensionless metric" would have to be a > special case, otherwise an "infinite" metric there would not mean the > other DLEP metrics become "infinite" too. >=20 > DLEP is for transporting layer-2 data from the radio to the router, so > the router can calculate the metric. So I would consider the raw > metric data (and not some precalculated value) important. Yes, raw is important. Supporting incompatible raw is also required. >>> Incremental updates are already possible in my current code, as long >>> as you repeat one metric at least once every Validity Time. A new >>> message does not overwrite the old database entry at the moment, it >>> just overwrites the new metric values of the database entry and = resets >>> the validity time. >> :-) >>=20 >>> I have no "per metric value" validity time planned. >> Not needed. Could be done with separate messages. > Not with my current implementation, because the database that stores > the metric values have only one validity time per set of metrics for a > neighbor. Your dlep receiver would support it. Why not? >>>> The "also" could be weakened. For a 1-to-1 relation between radio = and >>>> router, with unicast, the multicast could be stopped. This = suppression >>>> needs valid_time, so the radio starts multicasting when state of = the >>>> router is lost. >>> Hmm... I am not sure I like this. By keep repeating the Interface >>> Discovery and Connect Router every Validity Time, i get the >>> information on both sides that the connection between router and >>> radio/modem is still present. >> Why? The router to radio unicast will not be forwarded over RF link. >> The effect is that the radio sends DLEP to router only. >>=20 >> The DLEP filter in the radio is needed anyway, blocking multicast on = RF-link. > I don't think this "bridging everything together" will work well in > all cases. Especially with IEE802.11 It is up to the radio to provide transparent L2 transport. It can be = done with 802.11 on multiple special ways, as you and I know. >>>> You could combine 1 & 4. Radio simply multicasts neighbor state, = until >>>> it is told to do it different. Router multicasts: please send your = DLEP >>>> info with [ tcp | udp | other ] on interface [ this | vlan nn | = other ], >>>> duration [ valid_time], and [ do | do_not] suppress multicast. >>> I am not sure I like this, but it could be done... I would like to >>> keep the protocol practically stateless, >> Me to !!! >>=20 >>> with easy ways to support >>> multiple radios on a router and multiple layer-2 data-consumers (one >>> router, one logging system) getting data from a radio. >> My suggestion to suppress DLEP multicast blocks auto-discovery for = multiple >> consumers. Easy to fix: let the radio send out a multicast message = every now >> and then. Could be empty "announcement" packet. >=20 > Hmm... I think just keep the linklocal multicast with the radio data > might be easier. The radio can start sending out unicasts if necessary > in addition to this. Then router gets data twice? I don't see much benefits of getting rid of multicast, other than an = implicit=20 filter the DLEP data is not send over RF. But the filter is needed = anyway. Link-local multicast is not enough for the filter. Is needs to be L2 = link-local. Teco >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From hrogge@googlemail.com Sun Apr 22 06:37:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0737D21F85D6 for ; Sun, 22 Apr 2012 06:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXVmorzQgooJ for ; Sun, 22 Apr 2012 06:37:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1621F854C for ; Sun, 22 Apr 2012 06:37:51 -0700 (PDT) Received: by lagj5 with SMTP id j5so9039354lag.31 for ; Sun, 22 Apr 2012 06:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nHCQNJFtFnFaBzm4BSuoztJKSmdySNBX+y46nugSNp0=; b=dOz+WichGCk03p7UPf1zNkXymsdV3LxHJZw4J+ybGaiJ379QlZJUpMtiN0xi2HPcxm I7ntKg3ZGax9uNU6YbewxbRfsMQSyEn1Elf1C9mEEZKOMoeXfKnk1CVIzYJiPSCv2MdJ Uq5CJL6bJeCvo3lAwrv0IPjG7b8w/j1pSrF3PGeI8d2OHxJNIDsvzqbxYGAqCnOWCebT ogj4vc/Ytlm94Ub3w2O8dqV3EKgDq4jFy1mByWHJvdhnmLIMMioMSdzhFvFw2mpzIYGo k6nb5q4aWApP97Cqf2iklTREXcS5HH2dPzMKgluG7IBJqHxBHmu5+QLeFJcjaKvJJRCi vpUA== Received: by 10.112.24.197 with SMTP id w5mr776357lbf.83.1335101871038; Sun, 22 Apr 2012 06:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Sun, 22 Apr 2012 06:37:30 -0700 (PDT) In-Reply-To: <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> From: Henning Rogge Date: Sun, 22 Apr 2012 15:37:30 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 13:37:54 -0000 On Sun, Apr 22, 2012 at 14:30, Teco Boot wrote: > It is solved in 802.11S. Or IBSS with 4-address mode. Vanilla 802.11 > stack needs some kind of repeater, as you mentioned some time ago. 802.11s is a layer-2 mesh with a 6-mac address format. I think using DLEP on a full layer-2 mesh is even more complex, lets get the basics right first. >> I totally disagree with this. I don't even think the "dimensionless" >> metric TLV is really useful for DLEP, because the router would not >> know what this value is about. This whole "hiding information from the >> radio" is a bad idea in a lot of cases. > Not every user will write it's own metric calculation routine. How is it > guaranteed any DLEP implementation is interoperable? We need a minimum > set that MUST be implemented. I don't think a dimensionless metric is a useful "minimum". Without knowing what the radio means with this metric, it would just lead to crazy results. >> And even with this, the "dimensionless metric" would have to be a >> special case, otherwise an "infinite" metric there would not mean the >> other DLEP metrics become "infinite" too. >> >> DLEP is for transporting layer-2 data from the radio to the router, so >> the router can calculate the metric. So I would consider the raw >> metric data (and not some precalculated value) important. > Yes, raw is important. Supporting incompatible raw is also required. Yes, fortunately a standard RFC5444 reader should be able to skip unknown data (metric TLVs) easily. >> Not with my current implementation, because the database that stores >> the metric values have only one validity time per set of metrics for a >> neighbor. > Your dlep receiver would support it. Why not? I have split my implementation work into several parts. I have a "layer 2 database", both in the radio and the router. I use the DLEP-server and DLEP-client code to mirror this database from the radio to the router. And I have NL80211-listener code that can fill the database by using tha mac80211 linux code. The layer-2 db on both radio and router side are API-compatible. Which makes it easily to switch from DLEP-using router to directly reading one. And this database only has a single VTime-field for each SET of layer-2 data. >>>>> The "also" could be weakened. For a 1-to-1 relation between radio and >>>>> router, with unicast, the multicast could be stopped. This suppression >>>>> needs valid_time, so the radio starts multicasting when state of the >>>>> router is lost. >>>> Hmm... I am not sure I like this. By keep repeating the Interface >>>> Discovery and Connect Router every Validity Time, i get the >>>> information on both sides that the connection between router and >>>> radio/modem is still present. >>> Why? The router to radio unicast will not be forwarded over RF link. >>> The effect is that the radio sends DLEP to router only. >>> >>> The DLEP filter in the radio is needed anyway, blocking multicast on RF-link. >> I don't think this "bridging everything together" will work well in >> all cases. Especially with IEE802.11 > It is up to the radio to provide transparent L2 transport. It can be done with > 802.11 on multiple special ways, as you and I know. Still I see no advantage by unicast over a linklocal multicast. The second one should be interface specific too. >> Hmm... I think just keep the linklocal multicast with the radio data >> might be easier. The radio can start sending out unicasts if necessary >> in addition to this. > Then router gets data twice? > > I don't see much benefits of getting rid of multicast, other than an implicit > filter the DLEP data is not send over RF. But the filter is needed anyway. > Link-local multicast is not enough for the filter. Is needs to be L2 link-local. Linklocal multicast (at least for IPv6) is always interface specific. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Sun Apr 22 10:41:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D339421F854B for ; Sun, 22 Apr 2012 10:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aW8N8-EFCOc for ; Sun, 22 Apr 2012 10:41:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01E0F21F8549 for ; Sun, 22 Apr 2012 10:41:50 -0700 (PDT) Received: by eeke51 with SMTP id e51so2988124eek.31 for ; Sun, 22 Apr 2012 10:41:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nriGA3VTndQ6yN9sdDQMtgfVqK3I0c0z1zGhrYs9NMQ=; b=FsmKzN5+POq/fYBl7iUJyy0oQsDa6LoKFD8xMYqaHyaZo+3TOynczqqGKsoRrhyfdx 2QGtb8wGhBpBoMJ5/SeNw5VMO/7uwiDfyBirATxeBNBMAADHida9c/TvxGJIsxbm7MUs WJdwuzznP75QbGgiRjjUc06aFm8KYjglC2u50vJYFirdOANuT4O5ScTXw9dF/Y/Mre5Q gv1tgRl1cMLN2Y2zgprjnKbyEp0BNbbWMGdxa0GzweTrqJcz4xsUXkZyJ80Up9fLesEZ QbQ+4ynRpCiQVNPTDAMroDWTpfBwFtugEceWcWEcCUFmsC1zR0Y5toA1sNNJqfk8HTZI 5UPg== Received: by 10.213.106.2 with SMTP id v2mr1107747ebo.206.1335116509999; Sun, 22 Apr 2012 10:41:49 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id d54sm58559946eei.9.2012.04.22.10.41.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 10:41:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 19:41:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F4F8038-B516-4204-9F0F-7644285093A6@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlNtB1iXR4I7JnkB2jpb4xDqX2WGl27jbIDlT71ymNxF6kQ9hkZGV0mQQWWwG5iIQl4cCB7 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 17:41:51 -0000 Op 22 apr. 2012, om 15:37 heeft Henning Rogge het volgende geschreven: >=20 >>> Hmm... I think just keep the linklocal multicast with the radio data >>> might be easier. The radio can start sending out unicasts if = necessary >>> in addition to this. >> Then router gets data twice? >>=20 >> I don't see much benefits of getting rid of multicast, other than an = implicit >> filter the DLEP data is not send over RF. But the filter is needed = anyway. >=20 >> Link-local multicast is not enough for the filter. Is needs to be L2 = link-local. >=20 > Linklocal multicast (at least for IPv6) is always interface specific. You may miss my point. Assume a flat ethernet (no VLANs), and radio and = router use link multicast. Radio is a bridge. Bridges do flood broadcast / = multicast (OK, there are L2 multicast mechanisms that snoop IGMP/MLP). How can we = make sure the DLEP traffic is not send over RF? How can snoop work, when both ends use same DLEP multicast address? Simple example: Ethernet-SDSL bridge (switched 100Mbps RJ45s and couple = of jacks for phone wire). Now, due to DLEP, this bridge needs some multicast = filter. Or=20 additional management VLANs, only for DLEP (there would be a normal = management=20 VLAN that spans both ends). The special DLEP VLANs must be blocked on = the SDSL=20 ports. Example with radios would be similar to the simple VLAN bridge. Teco >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From teco@inf-net.nl Sun Apr 22 10:49:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1921F85B6 for ; Sun, 22 Apr 2012 10:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thPtrh+YNWNT for ; Sun, 22 Apr 2012 10:49:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F17321F85CC for ; Sun, 22 Apr 2012 10:49:13 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2958893eaa.31 for ; Sun, 22 Apr 2012 10:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Gwao3xFLM+riS5u5RG7lS6PPLBmiirOjr/Wk91oeRgI=; b=m1Vg1SQgJNMQjEM/2Gz2NZ+qdL6PQZ7v6ICLsSQb+dALYulLJhFFDYXCoZMEzOtlyO LBzbaUW5n6pPv2KAuE20OSkqBVaEFpvDK9C9B9htcZNjD25SwBTgKm4uj6DMuGQ87mM8 eQwqfbZKSXsGoo/CxYFvr8wP1skwXwibAdVP2KfTOEeo3LJeDDe7NE926ULbCXnG0AKJ MKFpStbpVczFdgmL7G3s2+v19EnswV8AHKjytF7jvcctEwmA9WKi3HI0Hha9ENp3qa8O B1R6qT8xVF/FRBNm8klitBiVNTX2Aj/NuSVfoxXoK09KQuPlSoibPgY/aXh0O2uc9/Eh 9jDQ== Received: by 10.213.19.205 with SMTP id c13mr1110281ebb.172.1335116953068; Sun, 22 Apr 2012 10:49:13 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m55sm58690940eei.1.2012.04.22.10.49.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 10:49:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 19:49:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <538E5C0E-48E3-4FC9-9485-582818FBDDF6@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmeiAbAKzAI3tFaT6cAJL5xJ6VCq2ArsO3eZlHwtC0m27ZVAN3uCRw4wnVretk0xhEFIINl Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 17:49:15 -0000 Op 22 apr. 2012, om 15:37 heeft Henning Rogge het volgende geschreven: >>>>=20 >>>> The DLEP filter in the radio is needed anyway, blocking multicast = on RF-link. >>> I don't think this "bridging everything together" will work well in >>> all cases. Especially with IEE802.11 >> It is up to the radio to provide transparent L2 transport. It can be = done with >> 802.11 on multiple special ways, as you and I know. > Still I see no advantage by unicast over a linklocal multicast. The > second one should be interface specific too. In a more complex link between radio and router, unicast takes single = path, where multicast is flooded. Unicast doesn't touch the multicast filter that much (see other mail) = and often has better performance. The multicast filter is needed for announcement packets, these must be = multicast=20 and must be kept local. So it cannot be unicast-only. Multicast-only is straightforward and often without negative effects.=20 Teco >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From teco@inf-net.nl Sun Apr 22 11:08:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D74521F866B for ; Sun, 22 Apr 2012 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN1W5aYcTQDR for ; Sun, 22 Apr 2012 11:08:08 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C241E21F866A for ; Sun, 22 Apr 2012 11:08:06 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2961278eaa.31 for ; Sun, 22 Apr 2012 11:08:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+aOkGRsgHOlyA5jUskELf4WUSxPKMhkI7XyeDu0A94k=; b=RF/JTUu+NmFW9GYN9j1jwbJaKdElTRkik2tnd53m5Nj+PL1tIBCvHDCxYnxfT+O25d QxA5sLjZLfIEQEAHBEZOcW26xuj6joTwRDqNt4fuwC6XwIHPJt6zyk/GHWxyURDwOsbC cdHhVFYGliY0QhIk1cnjTLJ3AfwFvce/YKCag3wApjJJXMrFWauZtaZ+PvKpsGPcHz1h Vfep8hNlUEzQYGIjzRMnsL4moud9sRgtEa5k7RNMxUMCXmO20erASsBWKaQE1lb+cgsG LeFfepr36dvIWtQw9b2HzJx3/55onDPxLSj5/eZRK01enRDAbzCc9GNClWHnAMpa+jRs LaLQ== Received: by 10.14.95.141 with SMTP id p13mr694537eef.112.1335118085874; Sun, 22 Apr 2012 11:08:05 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m55sm58897883eei.1.2012.04.22.11.08.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 11:08:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 20:08:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6AD9A2F4-F125-4F1F-8C83-7D37891464BE@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQltz+OeZ70h+kFwuy/7UkGYVYLYEM5pRSpkFuI0km0ZrntUZagU+vCzUGHs7gJfT2pdlwgy Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 18:08:08 -0000 Op 22 apr. 2012, om 15:37 heeft Henning Rogge het volgende geschreven: > On Sun, Apr 22, 2012 at 14:30, Teco Boot wrote: >> It is solved in 802.11S. Or IBSS with 4-address mode. Vanilla 802.11 >> stack needs some kind of repeater, as you mentioned some time ago. > > 802.11s is a layer-2 mesh with a 6-mac address format. I think using > DLEP on a full layer-2 mesh is even more complex, lets get the basics > right first. 4 of the 6 addresses of 802.11s are out of scope of DLEP. Only the SA and DA are of interest. 802.11s has metrics for each DA it knows about. It is cleaner than IBSS & bridging. WiFi Direct is a bit of a problem. I don't think the non access points has knowledge of link quality for the access point with the other nodes. In this scenario, the 802.11 stack provides wrong info. Same for normal BSS/EBSS stations and stations attached to 802.11s. I don't say I like 802.11s meshing in combination with a MANET protocol. It just has capabilities to provide needed info and has no problems with bridging. Teco From teco@inf-net.nl Sun Apr 22 12:08:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB621F8642 for ; Sun, 22 Apr 2012 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygPkd4RGeXkd for ; Sun, 22 Apr 2012 12:08:03 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8021F8671 for ; Sun, 22 Apr 2012 12:08:02 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2970089eaa.31 for ; Sun, 22 Apr 2012 12:08:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+RbgOJ/2R7DvwDZDBx7nqVkIk8IHjMLLippMkPrO+50=; b=BlsUPhGl7NVcEF9MB+ajlPnPi78+GbSKWeXWupQyGhy9U4MSjh6Diw0hB/sB6N8pJx 9WgU04D4BSdomcCCPw1WL7D6xO/GEbhSwII9/OWOM0JOBTW1uWj42bVkGN4RJy53LoDh FVSghAZrypHt2TMgYUb3d04AsnxIhAUvxZIXcUPPbId0BB1NT/8HwoQS2BmqIbLinFn+ IpJFWWpDX1XoBUMoTYw5sxx2518JMaSKwZ615MPZMXkV9PSXgAyWYMVhpKhFGwQOfREM uZuXfCkUsy5K0a5+TFfjGHKXyPv1LZ5Clkw6msOym1CFvroo6kz6WN/qQynHd3uFOhBF bs0g== Received: by 10.213.10.196 with SMTP id q4mr1024549ebq.6.1335121681504; Sun, 22 Apr 2012 12:08:01 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id n55sm59547509eef.6.2012.04.22.12.07.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Apr 2012 12:08:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sun, 22 Apr 2012 21:07:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmWZNM5ZfgPLhfKBI0kSctGOFLLaMZr3eHGUb/6nHks6HzF785O7C1f19VR8whYfdwAYNC1 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 19:08:04 -0000 Op 22 apr. 2012, om 15:37 heeft Henning Rogge het volgende geschreven: >>> ... I don't even think the "dimensionless" >>> metric TLV is really useful for DLEP, because the router would not >>> know what this value is about. This whole "hiding information from the >>> radio" is a bad idea in a lot of cases. >> Not every user will write it's own metric calculation routine. How is it >> guaranteed any DLEP implementation is interoperable? We need a minimum >> set that MUST be implemented. > > I don't think a dimensionless metric is a useful "minimum". Without > knowing what the radio means with this metric, it would just lead to > crazy results. Owners of incompatible standards_based gear will get crazy. What is the minimum set of TLVs that MUST be implemented? Negotiations? Our task as IETF is make gear compatible. (dlep-02: only MDR is mandatory) >>> And even with this, the "dimensionless metric" would have to be a >>> special case, otherwise an "infinite" metric there would not mean the >>> other DLEP metrics become "infinite" too. Is this a special case? I say: we don't need neighbor_up messages. Any link metric for a new neighbor, except "infinite metrics", is an up trigger. The MANET protocol would start detecting bi-directionality. Neighbor_down cannot be detected easily (as old-days carrier-detect), as we are facing frame based media access. Due to movements, signals fade away and DLEP link metrics provide this to the router. The router on its turn prefer an alternate path, if available. A radio may implement an I_will_shutdown message, for local and remote radio. Some max_value would do, or RLQ=0 &| CDR=0. Similar for link layer notifications. Teco From henning.rogge@fkie.fraunhofer.de Mon Apr 23 01:42:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E45F21F862B for ; Mon, 23 Apr 2012 01:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[AWL=2.493, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPp5hWBwfxjx for ; Mon, 23 Apr 2012 01:42:08 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id DB1B821F85D3 for ; Mon, 23 Apr 2012 01:42:07 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SMEqT-0007vT-F7 for manet@ietf.org; Mon, 23 Apr 2012 10:42:05 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SMEqT-0001cJ-Bx for manet@ietf.org; Mon, 23 Apr 2012 10:42:05 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 10:42:05 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 10:42:04 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 10:42:04 +0200 Message-ID: <4F9515DB.6030909@fkie.fraunhofer.de> Date: Mon, 23 Apr 2012 10:42:03 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <1047F2AD-53AD-48D1-B8B2-963B9DCE5E8D@inf-net.nl> <031302C2-2677-47E2-B9CF-576BDCECCF23@inf-net.nl> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080807060802070800080406" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 23 Apr 2012 08:42:05.0200 (UTC) FILETIME=[F5EF7100:01CD212C] X-Virus-Scanned: yes (ClamAV 0.97.3/14830/Mon Apr 23 04:57:47 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:42:09 -0000 --------------ms080807060802070800080406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/22/2012 09:07 PM, Teco Boot wrote: > Is this a special case? > > I say: we don't need neighbor_up messages. Any link metric for a new > neighbor, except "infinite metrics", is an up trigger. The MANET protoc= ol > would start detecting bi-directionality. > > Neighbor_down cannot be detected easily (as old-days carrier-detect), a= s > we are facing frame based media access. Due to movements, signals fade > away and DLEP link metrics provide this to the router. The router on it= s > turn prefer an alternate path, if available. > A radio may implement an I_will_shutdown message, for local and remote > radio. Some max_value would do, or RLQ=3D0&| CDR=3D0. Similar for link = layer > notifications. Maybe we can just reuse Address TLVs from RFC 6130 (NHDP) and OLSRv2, in = addition to the VALIDITY_TIME tlv from RFC 5497 (Time-TLV)? In NHDP we have the LINK_STATUS Address TLV, which can transport the=20 values "lost", "symmetric" or "heard". I think that might be useful here = to encode the status of a neighbor (mostly the 'lost' and 'heard' value, = unless the radio checks bi-directional connectivity). In OLSRv2 we will have the LINK_METRIC Address TLV, which could be used=20 for transporting a dimensionless metric value. This would allow to=20 specify if the metric is directional or bi-directional too. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080807060802070800080406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjMwODQyMDNaMCMGCSqGSIb3DQEJBDEWBBR6+kUn3YOBm8WHuJph2rltRxUdUTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQA0uMQf7IzLvQa5VS3Fs4iWCkIQVf2yU+fMoNZShq73XTad1GD7UADI4yYJaBT8 3bLzmRqq+AaQs8XehtFVIVYGNp9WzaNqUF2CDSykLxNbNJ0c56IYHwe/m8nCYSPTxiLfStVe tpbnbB3zDmxiXWvdwsPtriY80tN4VhwoZ0hfHN/5UqFbNERTf7rzQDulPV7ansUdI8ojqtFG 0qwWTtoibv1EPh8OFV4iMTcEK7R1pwF7HsCDTuTbBrPwpyMbc+jm8w4IDolyDJY07UGsxLim KMOJYoDQBUR0NwunpS55UQgKtuU5q9tq525Ep5U1VJ4A7TsJemOkr1SHr2CD37BuAAAAAAAA --------------ms080807060802070800080406-- From Chris.Dearlove@baesystems.com Mon Apr 23 01:57:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8B21F8659 for ; Mon, 23 Apr 2012 01:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJee7kGCv-CV for ; Mon, 23 Apr 2012 01:57:31 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2428D21F865A for ; Mon, 23 Apr 2012 01:57:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,465,1330905600"; d="scan'208";a="233237921" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 23 Apr 2012 09:57:30 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3N8vTER027168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Apr 2012 09:57:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 09:57:29 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Henning Rogge Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNHx1fSxLA12bEhU2HylJVFk057JakRnyAgACCeICAA1ScMA== Date: Mon, 23 Apr 2012 08:57:29 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> In-Reply-To: <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:57:32 -0000 Teco > IMHO unneeded functions. One man's unneeded function is another man's essential function. I think when there's a function one doesn't see a need for, it's time to ask why it's there before suggesting removing 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. ******************************************************************** From teco@inf-net.nl Mon Apr 23 03:36:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C59521F8688 for ; Mon, 23 Apr 2012 03:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18td61Kzmvmc for ; Mon, 23 Apr 2012 03:36:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E030C21F867F for ; Mon, 23 Apr 2012 03:36:29 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so7931556wgb.13 for ; Mon, 23 Apr 2012 03:36:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WQyHiSdg+nPQaFDjAqb8d3cCsi6YNHJKNfe4iBElrJU=; b=mijRau2nXsWJOYl232+nchZJVVrLGtGFnIB2mtFV/OIcUTVbOoPv9ypp51/tEux70l Z1g8OXs/5ePVths9hXQBTR5Hoh2kd69I/7TuuBFmAqwA7rIS1ld8T/rL5yqDvVQVP8oo xup73T6Len3F1Jbs5K4kCkKb3FQcrvmjs5smp1nepSMJojjg9kHGHVhUxGYjQ4QVzamR fS1GV6ogs4hox7IHOPb1YGj0A0epKxAJabDzpB/gjRzZgF+am10GwWZGlo5u3OrWJstN kd6g7v3zX2qVr2wWmrt/jtZfd3q/EPXOnSR/bF6IYCuq4f4wLxr1N79+lveK+HpXIR4r 2bqQ== Received: by 10.180.81.198 with SMTP id c6mr15294426wiy.18.1335177389026; Mon, 23 Apr 2012 03:36:29 -0700 (PDT) Received: from [172.16.4.190] ([188.205.88.52]) by mx.google.com with ESMTPS id fl2sm33848931wib.2.2012.04.23.03.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 03:36:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 23 Apr 2012 12:36:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0924FA27-0EA6-4AD8-883F-A9FBA3DA758A@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkm7o2BvFTiUZDliF2Aec/CRkV7zXJwGEu7rNwAyyKft/AO9QBJKgEAqE6TqV7I11PYAc06 Cc: "modemlpa@googlegroups.com" , "manet@ietf.org" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 10:36:30 -0000 Op 23 apr. 2012, om 10:57 heeft Dearlove, Christopher (UK) het volgende = geschreven: > Teco >> IMHO unneeded functions. >=20 > One man's unneeded function is another man's essential function. I = think when there's a function one doesn't see a need for, it's time to = ask why it's there before suggesting removing it. I did not have any intention to remove functionality. I meant IETF has = already protocols for functions DLEP also provides. We should try to use = existing protocols as much as possible, before standardizing new ones. I = suggested to split DLEP in what is needed and isn't in place (STD TRACK) = and what can be done in some special cases (experimental). IMHO flow = control and address resolving are unneeded and I asked why these are in = DLEP. I did not get satisfying answers.=20 Teco >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From henning.rogge@fkie.fraunhofer.de Mon Apr 23 03:51:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6321F86B7 for ; Mon, 23 Apr 2012 03:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=2.404, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDg7pBTdQDRa for ; Mon, 23 Apr 2012 03:51:12 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 397F521F86B6 for ; Mon, 23 Apr 2012 03:51:12 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SMGrP-0005wo-KH for manet@ietf.org; Mon, 23 Apr 2012 12:51:11 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SMGrP-0005It-HL for manet@ietf.org; Mon, 23 Apr 2012 12:51:11 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 12:51:11 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 12:51:11 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 12:51:10 +0200 Message-ID: <4F95341D.80402@fkie.fraunhofer.de> Date: Mon, 23 Apr 2012 12:51:09 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC1035F1EFA@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F2057@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F20A9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F219D@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1035F21E8@SUKNPT8106.cogent-dsn.local> <4F8589A6.3030305@fkie.fraunhofer.de> <4F913D5C.60302@fkie.fraunhofer.de> <1EE716A9-6C9B-4181-B080-17E2DC41439E@nasa.gov> <83B2BA38-3DF6-4F75-AF09-CF2755BAA820@inf-net.nl> <0924FA27-0EA6-4AD8-883F-A9FBA3DA758A@inf-net.nl> In-Reply-To: <0924FA27-0EA6-4AD8-883F-A9FBA3DA758A@inf-net.nl> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010409050601030409080709" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 23 Apr 2012 10:51:11.0343 (UTC) FILETIME=[FEFF0FF0:01CD213E] X-Virus-Scanned: yes (ClamAV 0.97.3/14830/Mon Apr 23 04:57:47 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: dad17b0fa7a976ea34f8545b3e71195d Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 10:51:13 -0000 --------------ms010409050601030409080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/23/2012 12:36 PM, Teco Boot wrote: > > Op 23 apr. 2012, om 10:57 heeft Dearlove, Christopher (UK) het > volgende geschreven: > >> Teco >>> IMHO unneeded functions. >> >> One man's unneeded function is another man's essential function. I >> think when there's a function one doesn't see a need for, it's time >> to ask why it's there before suggesting removing it. > > I did not have any intention to remove functionality. I meant IETF > has already protocols for functions DLEP also provides. We should try > to use existing protocols as much as possible, before standardizing > new ones. I suggested to split DLEP in what is needed and isn't in > place (STD TRACK) and what can be done in some special cases > (experimental). IMHO flow control and address resolving are unneeded > and I asked why these are in DLEP. I did not get satisfying answers. I think they are in DLEP because there are already quite a few IP=20 capable radios who KNOW their own and their neighbors IP address because = of their internal protocol. If the radio has knowledge about this, it should be able to tell the=20 router about it so the router can set the right IP on his local interface= =2E But the DLEP-Service (radio) should only report whats already known, it=20 should not generate additional traffic. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010409050601030409080709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjMxMDUxMDlaMCMGCSqGSIb3DQEJBDEWBBTlziPavu8q5A+tkAGZWZ1xDuS3YjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCzRKJAGOB2MctuSdBfdSqH+jJ9hoAYC5BIy4AdWin3TFbJ1+GWfLLZiE8byyFp f7UWwc6cDNwAqmbSMpTQ7MfWJ9t5KoZgfOi4hNwB3nTEBVsVIIjyotiPA7tDo0TSfbXiwbUy ti/3t4d2Qj43iWksXMz2WXcLvuL5U3aZO0RCdDvTYTUwydQnWPEDBu+SysPnMV8ovn7Ld6hy 02Q8qWwaPIYrKnybxOIq8L98sY1WFlrEOG0fwKEJJUsSK7u/FjE9faMaZM977Ybpz7SN5foN MgRpdChQTTWT47LSjutIIAyQIUJkzbjThTG6OlirDqFXjr1ilzlgfQM5N6Mxub/mAAAAAAAA --------------ms010409050601030409080709-- From abdussalambaryun@gmail.com Wed Apr 25 08:17:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210FB21F865B for ; Wed, 25 Apr 2012 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6ipEr2L9vVg for ; Wed, 25 Apr 2012 08:17:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8470C21F864D for ; Wed, 25 Apr 2012 08:17:17 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so152565vcb.31 for ; Wed, 25 Apr 2012 08:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2e3k9qmc3BaQsCRokTQ4HzJtmPnkW2mZoNduegwi2Ck=; b=eZICzboIaUms6VeGhVdWwBU9ws7PxyEoKM/L8FZfld7FJsfSa4W4okXxu+GP4kx3/4 69tKiznS4Id6B4l5QxaiEfPW8efDoJ5Z+R9rGXpzd0UH6WrMQyLNWVz+2MSQ8H5mpK68 WMAH5h6Ktg7cUflN56aIq9FSl/C9Yyd/J0yozZ8tf9kuKThl7iJgIZshvBAuDcZplCpP 2hmKS1LN8VwkboLc/ceDRT4C1QL94OIMP5IBBDgeOP44QvXmfN49m7tlbf7zdmFTYIyx nwH1Ecev00NrXxAojTOzpCgNozxWtz6v3JZvQiNQNjFFAwm7XR7CVPikc4xXhc/53UwH z2qQ== MIME-Version: 1.0 Received: by 10.52.23.10 with SMTP id i10mr2492429vdf.24.1335367036962; Wed, 25 Apr 2012 08:17:16 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Wed, 25 Apr 2012 08:17:16 -0700 (PDT) Date: Wed, 25 Apr 2012 17:17:16 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 25 Apr 2012 08:18:42 -0700 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:17:19 -0000 Hi Henning and Teco, Having some comments on below discussions, I maybe misunderstood (I still reading the DLEP protocol !). >IMHO unneeded functions. >One man's unneeded function is another man's essential function. I >think when there's a function one doesn't see a need for, it's time >to ask why it's there before suggesting removing it. AB> IMHO, this unneeded-function is only true in fixed state conditions not in arbitrary. The DLEP solves slow process of the-updating-functions (link state detection) which usually are expected-stable by routing function for a certen time, but DLEP reports the unexpected link factors, even though it may have some limitations. IMHO all DLEP functions should be independent in this first standard, in future we may think to adapt to other protocols' works. >I did not have any intention to remove functionality. I meant IETF >has already protocols for functions DLEP also provides. We should try >to use existing protocols as much as possible, before standardizing >new ones. I suggested to split DLEP in what is needed and isn't in >place (STD TRACK) and what can be done in some special cases >(experimental). IMHO flow control and address resolving are unneeded >and I asked why these are in DLEP. I did not get satisfying answers. AB> I think it is better to solve the protocol advantages in its use-case-problem, than to solve the full MANET problems. Then we may look at all protocols equally and see which functions needs to be taken apart and which should be satying as it is. If we follow the evaluation process as in RFC2501, I think DLEP has interesting methods which if we modify routing protocols to adapt to its rules will be more reasonable, because the dynamic topology is the main problem in MANET, and DLEP is reporting this change very closer than other MRPs. However, I just want to mention that we can look in both sides either modify/split DLEP functions or MRPs. >I think they are in DLEP because there are already quite a few IP capable radios >who KNOW their own and their neighbors IP address because of their internal >protocol. >If the radio has knowledge about this, it should be able to tell the router about it so >the router can set the right IP on his local interface. AB> DLEP is for link dynamic behavior than it is about node's behavior, so it is more important that it is reporting the link change, the IP is an advantage alternative. >But the DLEP-Service (radio) should only report whats already known, it should not >generate additional traffic. AB> I don't think it is generating additional, it generated necessary information for an arbitrary situation (unpredicted by routers), Therefore, it is solving a problem that is not solved as mentioned in the use-case discussions. Abdussalam Baryun University of Glamorgan, UK From sratliff@cisco.com Wed Apr 25 09:57:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB9321F87A1 for ; Wed, 25 Apr 2012 09:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca7iot1NVuZ1 for ; Wed, 25 Apr 2012 09:57:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0557821F87A0 for ; Wed, 25 Apr 2012 09:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4640; q=dns/txt; s=iport; t=1335373069; x=1336582669; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=fXn1jNkVkFe1/3LKStdjrcU3ts0gLiNf7e+/4zPLGS0=; b=R/XmWYKS/ZOfarH/MARNgaPdBEHoR0/0YnQaA5ER6ZH6VwtNrhCQPvz8 6vU558NPXSGEO3SyycXe3/8T6jrob0Cup1vUqzem1RX6PTeuqK5zpvY4u 4OW8s0EJxR+dMxEaEzALnpVUyQVAHiAiF09SmK3mTflqbiOH9UleQg4Tt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABYsmE+tJV2a/2dsb2JhbABFsU2BB4IJAQEBAwEBAQEPASUCNAsFCwtGJzAGEyKHaAULm0GgHgSJa4YSYwSVe45VgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77804973" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 25 Apr 2012 16:57:48 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PGvmaa027444; Wed, 25 Apr 2012 16:57:48 GMT Message-Id: From: Stan Ratliff To: Abdussalam Baryun In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Apr 2012 12:57:49 -0400 References: X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:57:50 -0000 On Apr 25, 2012, at 11:17 AM, Abdussalam Baryun wrote: > Hi Henning and Teco, > > Having some comments on below discussions, I maybe misunderstood (I > still reading the DLEP protocol !). > >> IMHO unneeded functions. > >> One man's unneeded function is another man's essential function. I >> think when there's a function one doesn't see a need for, it's time >> to ask why it's there before suggesting removing it. > > AB> IMHO, this unneeded-function is only true in fixed state > conditions not in arbitrary. The DLEP solves slow process of > the-updating-functions (link state detection) which usually are > expected-stable by routing function for a certen time, but DLEP > reports the unexpected link factors, even though it may have some > limitations. IMHO all DLEP functions should be independent in this > first standard, in future we may think to adapt to other protocols' > works. > >> I did not have any intention to remove functionality. I meant IETF >> has already protocols for functions DLEP also provides. We should try >> to use existing protocols as much as possible, before standardizing >> new ones. I suggested to split DLEP in what is needed and isn't in >> place (STD TRACK) and what can be done in some special cases >> (experimental). IMHO flow control and address resolving are unneeded >> and I asked why these are in DLEP. I did not get satisfying answers. > First off, splitting DLEP into multiple specs is a REALLY bad idea. If we did that, there wouldn't be ANY place where the protocol, in its entirety, is documented. IMO, that makes it more difficult to implement, and more difficult to ensure interoperability. Next, I've explained the reasoning behind the flow control on more than one occasion - it was put in due to *specific requests*, both on and off- list, by members of the WG. It's consistent with RFC 5578. And, IT IS OPTIONAL. Don't like it? Simple. Then DON'T IMPLEMENT IT. Same thing goes for the addresses - as has been said before, reliance on other protocols like ARP slows down the process. It also makes the underlying assumption that *everything* one router/radio pair attaches to is in the same subnet - because IIRC, ARP gets discarded when subnets don't match. With this OPTIONAL (again, if you don't like it, then don't implement it) approach, the appropriate ARP caches can be populated when they're needed, irrespective of subnet masks. Provided, of course, the modem (radio) already has cognizance of the far-end's address(es). Thus far, I've seen MULTIPLE requests to put flow control into the spec, and only ONE to remove it. Operating under the "Rough consensus and working code" model, I'd say that up to this juncture, we have "rough consensus" to KEEP flow control in the document. Stan > AB> I think it is better to solve the protocol advantages in its > use-case-problem, than to solve the full MANET problems. Then we may > look at all protocols equally and see which functions needs to be > taken apart and which should be satying as it is. If we follow the > evaluation process as in RFC2501, I think DLEP has interesting methods > which if we modify routing protocols to adapt to its rules will be > more reasonable, because the dynamic topology is the main problem in > MANET, and DLEP is reporting this change very closer than other MRPs. > However, I just want to mention that we can look in both sides either > modify/split DLEP functions or MRPs. > >> I think they are in DLEP because there are already quite a few IP >> capable radios >who KNOW their own and their neighbors IP address >> because of their internal >protocol. > >> If the radio has knowledge about this, it should be able to tell >> the router about it so >the router can set the right IP on his >> local interface. > > AB> DLEP is for link dynamic behavior than it is about node's > behavior, so it is more important that it is reporting the link > change, the IP is an advantage alternative. > >> But the DLEP-Service (radio) should only report whats already >> known, it should not >generate additional traffic. > > AB> I don't think it is generating additional, it generated necessary > information for an arbitrary situation (unpredicted by routers), > Therefore, it is solving a problem that is not solved as mentioned in > the use-case discussions. > > Abdussalam Baryun > University of Glamorgan, UK > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Wed Apr 25 10:21:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5521F85D8 for ; Wed, 25 Apr 2012 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onYJgQHGOeE9 for ; Wed, 25 Apr 2012 10:21:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE121F84FD for ; Wed, 25 Apr 2012 10:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=6050; q=dns/txt; s=iport; t=1335374459; x=1336584059; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=r+yDVnXM9lODd4ai/NIO8ABzOBCXJdS3/lzHjoCQXac=; b=O8umSs23VrRR5d/qonqwDgzf7/JuVjXbzS+FvfAih1KaalNCZt9y8W77 lXQ2ChqDAGD9IBzMJLzB+gppWbibkpr6SNu5506eAEESAQZtZlM50nkXk c0JaSpVAVzyt7yMuMIty2znOPdK9V70XxGSfx9SM5SlBB2OcjPBXPKJu1 8=; X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77799467" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Apr 2012 17:20:58 +0000 Received: from dhcp-64-102-194-250.cisco.com (dhcp-64-102-194-250.cisco.com [64.102.194.250]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PHKv3E013614; Wed, 25 Apr 2012 17:20:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Wed, 25 Apr 2012 13:20:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org, Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:21:10 -0000 Stan, All I think the spec should remain intact, not split-up. I also=20 think the flow control should remain as this was added by=20 requests. We have had good experiences with it in other protocols.=20 While speaking up, I'm not a fan of forcing the DLEP addresses into the Address TLV. If we really what to do so, then we need to enhance RFC 5444.=20 We spec'ed DLEP from our experiences with other related protocols, a variety of radios, networks and applications. I suspect as time rolls on, more features and capabilities will be requested.=20 We do appreciate the discussion.=20 Thanks -Bo On Apr 25, 2012, at 12:57 PM, Stan Ratliff wrote: >=20 > On Apr 25, 2012, at 11:17 AM, Abdussalam Baryun wrote: >=20 >> Hi Henning and Teco, >>=20 >> Having some comments on below discussions, I maybe misunderstood (I >> still reading the DLEP protocol !). >>=20 >>> IMHO unneeded functions. >>=20 >>> One man's unneeded function is another man's essential function. I >>> think when there's a function one doesn't see a need for, it's time >>> to ask why it's there before suggesting removing it. >>=20 >> AB> IMHO, this unneeded-function is only true in fixed state >> conditions not in arbitrary. The DLEP solves slow process of >> the-updating-functions (link state detection) which usually are >> expected-stable by routing function for a certen time, but DLEP >> reports the unexpected link factors, even though it may have some >> limitations. IMHO all DLEP functions should be independent in this >> first standard, in future we may think to adapt to other protocols' >> works. >>=20 >>> I did not have any intention to remove functionality. I meant IETF >>> has already protocols for functions DLEP also provides. We should = try >>> to use existing protocols as much as possible, before standardizing >>> new ones. I suggested to split DLEP in what is needed and isn't in >>> place (STD TRACK) and what can be done in some special cases >>> (experimental). IMHO flow control and address resolving are unneeded >>> and I asked why these are in DLEP. I did not get satisfying answers. >>=20 >=20 > First off, splitting DLEP into multiple specs is a REALLY bad idea. If = we did that, there wouldn't be ANY place where the protocol, in its = entirety, is documented. IMO, that makes it more difficult to implement, = and more difficult to ensure interoperability. Next, I've explained the = reasoning behind the flow control on more than one occasion - it was put = in due to *specific requests*, both on and off-list, by members of the = WG. It's consistent with RFC 5578. And, IT IS OPTIONAL. Don't like it? = Simple. Then DON'T IMPLEMENT IT. Same thing goes for the addresses - as = has been said before, reliance on other protocols like ARP slows down = the process. It also makes the underlying assumption that *everything* = one router/radio pair attaches to is in the same subnet - because IIRC, = ARP gets discarded when subnets don't match. With this OPTIONAL (again, = if you don't like it, then don't implement it) approach, the appropriate = ARP caches can be populated when they're needed, irrespective of subnet = masks. Provided, of course, the modem (radio) already has cognizance of = the far-end's address(es). >=20 > Thus far, I've seen MULTIPLE requests to put flow control into the = spec, and only ONE to remove it. Operating under the "Rough consensus = and working code" model, I'd say that up to this juncture, we have = "rough consensus" to KEEP flow control in the document. >=20 > Stan >=20 >=20 >=20 >> AB> I think it is better to solve the protocol advantages in its >> use-case-problem, than to solve the full MANET problems. Then we may >> look at all protocols equally and see which functions needs to be >> taken apart and which should be satying as it is. If we follow the >> evaluation process as in RFC2501, I think DLEP has interesting = methods >> which if we modify routing protocols to adapt to its rules will be >> more reasonable, because the dynamic topology is the main problem in >> MANET, and DLEP is reporting this change very closer than other MRPs. >> However, I just want to mention that we can look in both sides either >> modify/split DLEP functions or MRPs. >>=20 >>> I think they are in DLEP because there are already quite a few IP = capable radios >who KNOW their own and their neighbors IP address = because of their internal >protocol. >>=20 >>> If the radio has knowledge about this, it should be able to tell the = router about it so >the router can set the right IP on his local = interface. >>=20 >> AB> DLEP is for link dynamic behavior than it is about node's >> behavior, so it is more important that it is reporting the link >> change, the IP is an advantage alternative. >>=20 >>> But the DLEP-Service (radio) should only report whats already known, = it should not >generate additional traffic. >>=20 >> AB> I don't think it is generating additional, it generated necessary >> information for an arbitrary situation (unpredicted by routers), >> Therefore, it is solving a problem that is not solved as mentioned in >> the use-case discussions. >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From hrogge@googlemail.com Wed Apr 25 11:59:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5B21F8911 for ; Wed, 25 Apr 2012 11:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT0iTpB0I9kK for ; Wed, 25 Apr 2012 11:59:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5329321F890C for ; Wed, 25 Apr 2012 11:59:33 -0700 (PDT) Received: by lagj5 with SMTP id j5so368316lag.31 for ; Wed, 25 Apr 2012 11:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mayBH28E2ja1Lqs2NWBfkhoBPsrZiF8UI2tdTG4ITwM=; b=qIL7VLd82Rw4TtsMUlKfiHHdoXAkvowAxXjF0pTDwMC7/D6ga+TpLnhMFRIIOvWcLF sHRL8lnDw4OxsR25OJ8uEaDqtnE6B2/6Pc0jEEaVDNkGJxj1BoiNoVCfdhIDAkUg8h4D arQkvYR6hj2QS8v6kkKA9tvBZ177FBC5H/QkxEEOJeOHRDhNHYO0ORb7KFJR1l3GcNqP cm963aSPaZFs9R3JqDTYWAkhC84xbVf8fMnCQDkzqR6VyrOohaUBt+Cn1yFh7k4xlCC2 +gHpVc52mssMR9X23j0dIXjnDc0I+1ABg9QNfSlnjwWuufekoMLhEclekIt17rCPfbzE VkqQ== Received: by 10.112.24.197 with SMTP id w5mr1908374lbf.83.1335380372298; Wed, 25 Apr 2012 11:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 25 Apr 2012 11:59:10 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 25 Apr 2012 20:59:10 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:59:35 -0000 On Wed, Apr 25, 2012 at 19:20, Bo Berry wrote: > Stan, All > I think the spec should remain intact, not split-up. =A0I also > think the flow control should remain as this was added by > requests. =A0We have had good experiences with it in other > protocols. I agree with this... the flow control (and the link characteristics request) might be a different "block of functionality" of DLEP, but it mixes well in the concept of a Router-Interface communication protocol. > While speaking up, I'm not a fan of forcing the DLEP addresses > into the Address TLV. If we really what to do so, then we need > to enhance RFC 5444. I think moving the MAC addresses into the address space of RFC 5444 makes a LOT of sense. It allows it to trivially formulate DLEP messages that contain updates (both IP or metric) for multiple radio neighbors by allowing to have TLVs for one and for multiple neighbors/mac-addresses. Putting the IPs (if they are available on the radio) into address-TLVs on this MACs is just a natural extension of this. It also allows the interface to identify itself by using the originator-address (which will become also a 6 byte field in this case). > We spec'ed DLEP from our experiences with other related protocols, > a variety of radios, networks and applications. =A0I suspect as time > rolls on, more features and capabilities will be requested. > We do appreciate the discussion. I would like to talk about the reason why you decided to split the handshake between Interface and Router apart into that many "orders". >From my point of view, this part of the protocol is very complex without too much gain. As I can see it, there are several things the handshake should be able to d= o: (I am talking about the Peer Discovery (both), Peer Termination (including ACK) orders and the bi-directional heartbeat order.) - it should allow the router to auto-discover the DLEP-equipped radio by just listening - it should allow both the router and the radio to become aware of each oth= er - it should allow both the router and the radio to discover a loss of connection between each other. Did I missed something important? Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From boberry@cisco.com Wed Apr 25 12:10:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDC121F8933 for ; Wed, 25 Apr 2012 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aqZljpdCj3i for ; Wed, 25 Apr 2012 12:10:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 02D2221F88EE for ; Wed, 25 Apr 2012 12:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=3444; q=dns/txt; s=iport; t=1335381044; x=1336590644; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/XPd1qXe/FpZkwUP2Paj1dhytmEgJhvbKD9BWUr3wO8=; b=MZYKMHQknkuZ0gMTDs6J6NFTZmR5n/C9kBwiA3VUCmKWMvokfwTFDenB 31NP8Bv6bLV3nQFBGwh+/TckfwfsnoRJkxAq8leqF99Bx3P81JavtT1uT JlNCUPwjFu7xFg9QqpnEYfrfOX18708Hm694pxRFhK3E4H8wsgoxqfVGD M=; X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77838210" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 25 Apr 2012 19:10:39 +0000 Received: from dhcp-64-102-194-250.cisco.com (dhcp-64-102-194-250.cisco.com [64.102.194.250]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3PJAd1e002851; Wed, 25 Apr 2012 19:10:39 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Wed, 25 Apr 2012 15:10:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Rogge X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:10:44 -0000 Henning On Apr 25, 2012, at 2:59 PM, Henning Rogge wrote: > On Wed, Apr 25, 2012 at 19:20, Bo Berry wrote: >> Stan, All >> I think the spec should remain intact, not split-up. I also >> think the flow control should remain as this was added by >> requests. We have had good experiences with it in other >> protocols. >=20 > I agree with this... the flow control (and the link characteristics > request) might be a different "block of functionality" of DLEP, but it > mixes well in the concept of a Router-Interface communication > protocol. concensus +1 >=20 >> While speaking up, I'm not a fan of forcing the DLEP addresses >> into the Address TLV. If we really what to do so, then we need >> to enhance RFC 5444. >=20 > I think moving the MAC addresses into the address space of RFC 5444 > makes a LOT of sense. It allows it to trivially formulate DLEP > messages that contain updates (both IP or metric) for multiple radio > neighbors by allowing to have TLVs for one and for multiple > neighbors/mac-addresses. >=20 > Putting the IPs (if they are available on the radio) into address-TLVs > on this MACs is just a natural extension of this. >=20 > It also allows the interface to identify itself by using the > originator-address (which will become also a 6 byte field in this > case). =46rom my perspective, mushing, obscuring multiple data types into=20 single and yet diff data type (IPV6) is a bad idea. =20 >=20 >> We spec'ed DLEP from our experiences with other related protocols, >> a variety of radios, networks and applications. I suspect as time >> rolls on, more features and capabilities will be requested. >=20 >> We do appreciate the discussion. The router-radio peer layer facilitates management of the neighbors beyond the radio. For example, if the radio fails, routing can=20 quickly cleanup. We need both levels. Complexity is relative, its not so bad. >=20 > I would like to talk about the reason why you decided to split the > handshake between Interface and Router apart into that many "orders". > =46rom my point of view, this part of the protocol is very complex > without too much gain. >=20 > As I can see it, there are several things the handshake should be able = to do: > (I am talking about the Peer Discovery (both), Peer Termination > (including ACK) orders and the bi-directional heartbeat order.) >=20 > - it should allow the router to auto-discover the DLEP-equipped radio > by just listening > - it should allow both the router and the radio to become aware of = each other > - it should allow both the router and the radio to discover a loss of > connection between each other. >=20 > Did I missed something important? >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From ulrich@herberg.name Wed Apr 25 12:29:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4E21F893A for ; Wed, 25 Apr 2012 12:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syQYJN5nK74r for ; Wed, 25 Apr 2012 12:29:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF97E21F8931 for ; Wed, 25 Apr 2012 12:29:56 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1877780pbb.31 for ; Wed, 25 Apr 2012 12:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x9RoIcs5Ic4Qv2NH91TdruTyL0dgrtHfKABAczgaM80=; b=kxnux/hm/2BwGW5ghaHKJKBiqp5EbfhjApgnw5HN/p5nxZdTfyiLcTuvr21WgW4gdY sPL3U7TRofkt9GWqAvlgN4lvekqDNTYrNBXmYY8udwhGlmPa7smiVvSmJsVo69e6SFTx zpZg2N62RNUZLhLSBT2RgsJGu27Vj1W7UTSF4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=x9RoIcs5Ic4Qv2NH91TdruTyL0dgrtHfKABAczgaM80=; b=on6eQ/f/0zzRLe9rrt/YbBFMo/Rr5NJP5ekn2RqQ5QipdykVWKBUvHXCy2rb3q7ugM HzYVWua2ykiv+zcB+hKAbqMhqP3zuGT3WW34t5ud1aFfknc89sa8Mp97ag9Y26fRMKoB 8jWir/+19fvj9FPDdQXqLyKQsIstbXB2tdvzmsrEWVqqc62Nvkc2mYaO76ViXW1hNUDu 9mW85sTLhD6HaTwGzUZyjsats6Som4OnqsBLj2GRnKbmZyaDXZPrkehJDgcFpdzy2i4s 6I+fUujnk57YGnK3B+mNFgDdpbI5I5YSOYWSJWXHYrY5oTEju3fXXywW3hj/hRvcSGra fygg== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr9505407pbc.35.1335382196583; Wed, 25 Apr 2012 12:29:56 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Wed, 25 Apr 2012 12:29:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 12:29:56 -0700 Message-ID: From: Ulrich Herberg To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnOj85LdS5BKwPckj2TOczvAzzsL5eOVzo8VDAcOz0mZMbWzyIhA69ZiwH3olSL7O8POzi+ Cc: manet@ietf.org, Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:29:57 -0000 Bo, On Wed, Apr 25, 2012 at 12:10 PM, Bo Berry wrote: > > Henning > > On Apr 25, 2012, at 2:59 PM, Henning Rogge wrote: > > [...] > > > > >> While speaking up, I'm not a fan of forcing the DLEP addresses > >> into the Address TLV. If we really what to do so, then we need > >> to enhance RFC 5444. > > > > I think moving the MAC addresses into the address space of RFC 5444 > > makes a LOT of sense. It allows it to trivially formulate DLEP > > messages that contain updates (both IP or metric) for multiple radio > > neighbors by allowing to have TLVs for one and for multiple > > neighbors/mac-addresses. > > > > Putting the IPs (if they are available on the radio) into address-TLVs > > on this MACs is just a natural extension of this. > > > > It also allows the interface to identify itself by using the > > originator-address (which will become also a 6 byte field in this > > case). > > From my perspective, mushing, obscuring multiple data types into > single and yet diff data type (IPV6) is a bad idea. I thought that this idea has already been abandoned and replaced by instead by a proposal to use 6-byte (MAC) address length and address blocks, and to put IPv6 and IPv4 addresses into message TLVs? That seems to be the logical approach, since DLEP is a layer 2 protocol (and updating RFC5444 is difficult). > [...] Regards Ulrich From boberry@cisco.com Wed Apr 25 12:35:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA821F88FE for ; Wed, 25 Apr 2012 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW5Jq0yh4fA7 for ; Wed, 25 Apr 2012 12:35:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D11B721F88DF for ; Wed, 25 Apr 2012 12:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=2107; q=dns/txt; s=iport; t=1335382518; x=1336592118; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=im1FLPxI5sN/s6Q6hW1CaSPkrgsP1gqpgJj+l1WLHmM=; b=kYbvRy9OYFKLm+ua8jphuD/f3hLwM14gfLy9e6AUkQPOwzEQKNIc2HTQ Nh21Uki0+r9Tpeed0HlOes535auZuhy6JfKZ/WV0X25rwYlYZ/yVaRxeU IlQQhCsE80sILKagsBNAO02xXAErqsWHClGgdd4C5tpdeWZKwKFXgzDZN 0=; X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77848024" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 25 Apr 2012 19:35:17 +0000 Received: from dhcp-64-102-194-250.cisco.com (dhcp-64-102-194-250.cisco.com [64.102.194.250]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PJZH3l021168; Wed, 25 Apr 2012 19:35:17 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Wed, 25 Apr 2012 15:35:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org, Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:35:18 -0000 On Apr 25, 2012, at 3:29 PM, Ulrich Herberg wrote: > Bo, >=20 > On Wed, Apr 25, 2012 at 12:10 PM, Bo Berry wrote: >>=20 >> Henning >>=20 >> On Apr 25, 2012, at 2:59 PM, Henning Rogge wrote: >>> [...] >>=20 >>>=20 >>>> While speaking up, I'm not a fan of forcing the DLEP addresses >>>> into the Address TLV. If we really what to do so, then we need >>>> to enhance RFC 5444. >>>=20 >>> I think moving the MAC addresses into the address space of RFC 5444 >>> makes a LOT of sense. It allows it to trivially formulate DLEP >>> messages that contain updates (both IP or metric) for multiple radio >>> neighbors by allowing to have TLVs for one and for multiple >>> neighbors/mac-addresses. >>>=20 >>> Putting the IPs (if they are available on the radio) into = address-TLVs >>> on this MACs is just a natural extension of this. >>>=20 >>> It also allows the interface to identify itself by using the >>> originator-address (which will become also a 6 byte field in this >>> case). >>=20 >> =46rom my perspective, mushing, obscuring multiple data types into >> single and yet diff data type (IPV6) is a bad idea. >=20 >=20 > I thought that this idea has already been abandoned and replaced by > instead by a proposal to use 6-byte (MAC) address length and address > blocks, and to put IPv6 and IPv4 addresses into message TLVs? That > seems to be the logical approach, since DLEP is a layer 2 protocol > (and updating RFC5444 is difficult). no, there was a lot of discussion by some, but no concensus, agree, at least from me. >=20 >> [...] >=20 >=20 > Regards > Ulrich ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From sratliff@cisco.com Wed Apr 25 12:41:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C759621F8930 for ; Wed, 25 Apr 2012 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnOe8rBAg5Vf for ; Wed, 25 Apr 2012 12:41:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EC61921F87AA for ; Wed, 25 Apr 2012 12:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2022; q=dns/txt; s=iport; t=1335382889; x=1336592489; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=YDocIaRCawtgU5Uxt9bm1mPPofTfmXI/KZ1V45Doi78=; b=OScrnPEj8uwdcWpSOlbN2CcsW4XVwK4l/tNGfiH1BjeixgfFP7KDi9uA CEfSaf8k0pY/j9i8bnn6fijjWoz4ltmPfYpDtl0tZGD/++8ruTGyhbuQj Ul0vBzR6JfX/DOA73Ja+eyd+uXF0Z7yMCrXyRIZg+Lg9HMTwpZv5BVckq M=; X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77850569" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 25 Apr 2012 19:41:28 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3PJfRmp004142; Wed, 25 Apr 2012 19:41:28 GMT Message-Id: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: Stan Ratliff To: Ulrich Herberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 25 Apr 2012 15:41:28 -0400 References: X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org, Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:41:31 -0000 Ulrich, On Apr 25, 2012, at 3:29 PM, Ulrich Herberg wrote: > Bo, > > On Wed, Apr 25, 2012 at 12:10 PM, Bo Berry wrote: >> >> Henning >> >> On Apr 25, 2012, at 2:59 PM, Henning Rogge wrote: >>> [...] >> >>> >>>> While speaking up, I'm not a fan of forcing the DLEP addresses >>>> into the Address TLV. If we really what to do so, then we need >>>> to enhance RFC 5444. >>> >>> I think moving the MAC addresses into the address space of RFC 5444 >>> makes a LOT of sense. It allows it to trivially formulate DLEP >>> messages that contain updates (both IP or metric) for multiple radio >>> neighbors by allowing to have TLVs for one and for multiple >>> neighbors/mac-addresses. >>> >>> Putting the IPs (if they are available on the radio) into address- >>> TLVs >>> on this MACs is just a natural extension of this. >>> >>> It also allows the interface to identify itself by using the >>> originator-address (which will become also a 6 byte field in this >>> case). >> >> From my perspective, mushing, obscuring multiple data types into >> single and yet diff data type (IPV6) is a bad idea. > > > I thought that this idea has already been abandoned and replaced by > instead by a proposal to use 6-byte (MAC) address length and address > blocks, and to put IPv6 and IPv4 addresses into message TLVs? That > seems to be the logical approach, since DLEP is a layer 2 protocol > (and updating RFC5444 is difficult). I think that any attempt to force MAC addresses into 5444 address blocks for DLEP *only* (at least it's only DLEP at this time) is basically trying to ram a square peg into a round hole - with a sufficiently large sledge-hammer, "anything is possible". My concern all along with doing that is that we end up with a one-off, and I'm strongly opposed to that. IMO, the way to address it "properly" is with "RFC 5444 bis"., and I don't see any energy to do that. Regards, Stan > >> [...] > > > Regards > Ulrich From hrogge@googlemail.com Wed Apr 25 13:18:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CA621F8919 for ; Wed, 25 Apr 2012 13:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4Wimcjj8qNb for ; Wed, 25 Apr 2012 13:18:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8DF521F88F5 for ; Wed, 25 Apr 2012 13:18:05 -0700 (PDT) Received: by lagj5 with SMTP id j5so426187lag.31 for ; Wed, 25 Apr 2012 13:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1HTqpop1HpvZ/zOPHgHJc7K2F2D1B1AFrSWesD5h2p8=; b=xvuoXSmhZdLIHpRJSH/5YFjiELXYiaCySAyUW0OQ0Q1r0YqF4BZv/x7lnqO8cYegVF Ad91HE/snMNmPA8DqDey9J2GbERB9FnWaWPCNVMgEMVM6MOjLi+ggFVs4NxlEyUtTk24 ZcX1j+AGmF4SmnbsFqfOQpcRKX/6G3eLyamY6QGQeH2k6UZVo8Tc7RHQ9L67GcMn2n/n 1VjVMgRColXz4KskgiS1YGdpsxNUlGthrBL/C8QJoGnHAipVP6MVvmkP4Pbhn+WgW8aP t3uGz9CZQVooqZ7+qLzmg1U86GCxlRllkIrH2eD5jOghZgwBk6V08ms9vPvw5HcUA68u Eomw== Received: by 10.112.47.170 with SMTP id e10mr2018514lbn.69.1335385084709; Wed, 25 Apr 2012 13:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 25 Apr 2012 13:17:44 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 25 Apr 2012 22:17:44 +0200 Message-ID: To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:18:09 -0000 On Wed, Apr 25, 2012 at 21:10, Bo Berry wrote: >>> While speaking up, I'm not a fan of forcing the DLEP addresses >>> into the Address TLV. If we really what to do so, then we need >>> to enhance RFC 5444. >> >> I think moving the MAC addresses into the address space of RFC 5444 >> makes a LOT of sense. It allows it to trivially formulate DLEP >> messages that contain updates (both IP or metric) for multiple radio >> neighbors by allowing to have TLVs for one and for multiple >> neighbors/mac-addresses. >> >> Putting the IPs (if they are available on the radio) into address-TLVs >> on this MACs is just a natural extension of this. >> >> It also allows the interface to identify itself by using the >> originator-address (which will become also a 6 byte field in this >> case). > > From my perspective, mushing, obscuring multiple data types into > single and yet diff data type (IPV6) is a bad idea. I only want to put mac-addresses (6 bytes) into the RFC 5444 defined addresses. The IPs can stay in TLVs (address TLVs in my suggestion) like its currently described in the DLEP-draft (if you ignore the whole sub-tlv mess). >>> We spec'ed DLEP from our experiences with other related protocols, >>> a variety of radios, networks and applications. =A0I suspect as time >>> rolls on, more features and capabilities will be requested. >> >>> We do appreciate the discussion. > > The router-radio peer layer facilitates management of the neighbors > beyond the radio. =A0For example, if the radio fails, routing can > quickly cleanup. =A0We need both levels. =A0Complexity is relative, > its not so bad. Is the management of the neighbors beyond the radio part of the Peer Discovery (both), Peer Termination (including ACK) orders and the bi-directional heartbeat order? I thought this "tell about the neighbors" is mostly the neighbor updates. Do not understand me wrong, I do not want to skip any of the described features, I just try to grasp if I missed an important feature of the router-radio handshake. Henning --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Wed Apr 25 13:18:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7BF21F8956 for ; Wed, 25 Apr 2012 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHBe3DQeBrbE for ; Wed, 25 Apr 2012 13:18:36 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E624B21F8952 for ; Wed, 25 Apr 2012 13:18:35 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4400011wib.13 for ; Wed, 25 Apr 2012 13:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9TYHU9MeCumnQT4O0PcorS+jgWDirRdsjl/UVwD8MZ8=; b=BcUgGA1VxFpSMMpiZL65cWbrq3tR12a83om0f01tDF27RMtjviPGKwdwwDlVNj/vim aLynXg4//zgbp2NgDGIHRyHPE5dLIE6s/3vSFfsbvb7mq2Oe3n2DllGnFKvFRGdaO7ca yaFRXPNFf7tYBiB2l9YuVzu6+HZWZhrXATsU0XqNqhC309hyPSwPiEi7q0M+pp8QtI3h xIXisfI02ZwTosas/3qR48Day0hDBXgqBFj4jX6UiSMTeWtXwc8l1OmbYn++zU+j6Zem 6mG07Np4KPhKlLiAM+M6DsFa/in9zVYQZ/1uVTfXlbard8sNtcybAQ20HUh9YUKoj9R5 IiFA== Received: by 10.180.88.169 with SMTP id bh9mr9930556wib.5.1335385115079; Wed, 25 Apr 2012 13:18:35 -0700 (PDT) Received: from [10.87.30.159] ([80.187.201.33]) by mx.google.com with ESMTPS id gd4sm2617169wib.6.2012.04.25.13.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 13:18:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Wed, 25 Apr 2012 22:18:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlrbHk7OHUB+GQJVg5HKHldCDp1IiF7gtWFWZBciBIYQYenLz5adcpVSLcahXm5UQoW3RN8 Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:18:37 -0000 Stan, If you SHOUT, what hat are you wearing? Teco Op 25 apr. 2012, om 18:57 heeft Stan Ratliff het volgende geschreven: >=20 > On Apr 25, 2012, at 11:17 AM, Abdussalam Baryun wrote: >=20 >> Hi Henning and Teco, >>=20 >> Having some comments on below discussions, I maybe misunderstood (I >> still reading the DLEP protocol !). >>=20 >>> IMHO unneeded functions. >>=20 >>> One man's unneeded function is another man's essential function. I >>> think when there's a function one doesn't see a need for, it's time >>> to ask why it's there before suggesting removing it. >>=20 >> AB> IMHO, this unneeded-function is only true in fixed state >> conditions not in arbitrary. The DLEP solves slow process of >> the-updating-functions (link state detection) which usually are >> expected-stable by routing function for a certen time, but DLEP >> reports the unexpected link factors, even though it may have some >> limitations. IMHO all DLEP functions should be independent in this >> first standard, in future we may think to adapt to other protocols' >> works. >>=20 >>> I did not have any intention to remove functionality. I meant IETF >>> has already protocols for functions DLEP also provides. We should = try >>> to use existing protocols as much as possible, before standardizing >>> new ones. I suggested to split DLEP in what is needed and isn't in >>> place (STD TRACK) and what can be done in some special cases >>> (experimental). IMHO flow control and address resolving are unneeded >>> and I asked why these are in DLEP. I did not get satisfying answers. >>=20 >=20 > First off, splitting DLEP into multiple specs is a REALLY bad idea. If = we did that, there wouldn't be ANY place where the protocol, in its = entirety, is documented. IMO, that makes it more difficult to implement, = and more difficult to ensure interoperability. Next, I've explained the = reasoning behind the flow control on more than one occasion - it was put = in due to *specific requests*, both on and off-list, by members of the = WG. It's consistent with RFC 5578. And, IT IS OPTIONAL. Don't like it? = Simple. Then DON'T IMPLEMENT IT. Same thing goes for the addresses - as = has been said before, reliance on other protocols like ARP slows down = the process. It also makes the underlying assumption that *everything* = one router/radio pair attaches to is in the same subnet - because IIRC, = ARP gets discarded when subnets don't match. With this OPTIONAL (again, = if you don't like it, then don't implement it) approach, the appropriate = ARP caches can be populated when they're needed, irrespective of subnet = masks. Provided, of course, the modem (radio) already has cognizance of = the far-end's address(es). >=20 > Thus far, I've seen MULTIPLE requests to put flow control into the = spec, and only ONE to remove it. Operating under the "Rough consensus = and working code" model, I'd say that up to this juncture, we have = "rough consensus" to KEEP flow control in the document. >=20 > Stan >=20 >=20 >=20 >> AB> I think it is better to solve the protocol advantages in its >> use-case-problem, than to solve the full MANET problems. Then we may >> look at all protocols equally and see which functions needs to be >> taken apart and which should be satying as it is. If we follow the >> evaluation process as in RFC2501, I think DLEP has interesting = methods >> which if we modify routing protocols to adapt to its rules will be >> more reasonable, because the dynamic topology is the main problem in >> MANET, and DLEP is reporting this change very closer than other MRPs. >> However, I just want to mention that we can look in both sides either >> modify/split DLEP functions or MRPs. >>=20 >>> I think they are in DLEP because there are already quite a few IP = capable radios >who KNOW their own and their neighbors IP address = because of their internal >protocol. >>=20 >>> If the radio has knowledge about this, it should be able to tell the = router about it so >the router can set the right IP on his local = interface. >>=20 >> AB> DLEP is for link dynamic behavior than it is about node's >> behavior, so it is more important that it is reporting the link >> change, the IP is an advantage alternative. >>=20 >>> But the DLEP-Service (radio) should only report whats already known, = it should not >generate additional traffic. >>=20 >> AB> I don't think it is generating additional, it generated necessary >> information for an arbitrary situation (unpredicted by routers), >> Therefore, it is solving a problem that is not solved as mentioned in >> the use-case discussions. >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Wed Apr 25 13:24:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA55E11E8080 for ; Wed, 25 Apr 2012 13:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQlX44VGT+f5 for ; Wed, 25 Apr 2012 13:24:54 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6911E808E for ; Wed, 25 Apr 2012 13:24:53 -0700 (PDT) Received: by lagj5 with SMTP id j5so430545lag.31 for ; Wed, 25 Apr 2012 13:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jvXpE09/NcP3UAN2/tJfUjQY6K7K1im7c248hYOybo0=; b=r11nPsJOQL3OGUH/2NYjBaMbDXtjvY/poAG419oyMuFnqHcz4EOv41ooz+CSL2n2nZ eQheVDPAdTPhr0437B7swuN4Ez3HpUfERBSwhOVBSJaxqilhVigtKbsTWJDzUF06qBzq J6Hbt/533YfS9+KMiOUEcdbJLWwX2yVG2bjYhv2AGq3qC5ULwd1n1r3X4zt85wzw0BnQ zhMfVtJrdbN4PJ+jjXXHhiVA6yGG5g/5tfwtiCBPN0U8EIHvnfqAWT/DiwX1fyKqmmok mhIzCKdXXpz2Z6eXK8QTLQc7T6FV772LANRbYoORWoOwSiPn6bdoZZsBsZ6HXrVjIuV1 5pJg== Received: by 10.112.47.170 with SMTP id e10mr2028050lbn.69.1335385492665; Wed, 25 Apr 2012 13:24:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Wed, 25 Apr 2012 13:24:31 -0700 (PDT) In-Reply-To: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: Henning Rogge Date: Wed, 25 Apr 2012 22:24:31 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org, Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:24:54 -0000 On Wed, Apr 25, 2012 at 21:41, Stan Ratliff wrote: > I think that any attempt to force MAC addresses into 5444 address blocks for > DLEP *only* (at least it's only DLEP at this time) is basically trying to > ram a square peg into a round hole - with a sufficiently large > sledge-hammer, "anything is possible". My concern all along with doing that > is that we end up with a one-off, and I'm strongly opposed to that. IMO, the > way to address it "properly" is with "RFC 5444 bis"., and I don't see any > energy to do that. It was an explicit design decission for RFC 5444 that it is not restricted to IP as addresses, but just sees addresses as a binary field of 1 to 16 bytes. So using a RFC 5444 message with 6 bytes addresses for DLEP is fitting the round cylinder into the round hole. Each radio (from the point of view of the IP router) has a mac address, so its a natural way to describe radios by their mac address. And then you can attach any kind of (optional) information you have about the radios to these mac addresses. I don't see where this doesn't fit the concept of RFC 5444. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Wed Apr 25 13:34:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D953121F8857 for ; Wed, 25 Apr 2012 13:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhYZsUBXTeZU for ; Wed, 25 Apr 2012 13:34:19 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB821F8836 for ; Wed, 25 Apr 2012 13:34:19 -0700 (PDT) Received: by dady13 with SMTP id y13so903342dad.27 for ; Wed, 25 Apr 2012 13:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PUWkRCQFHjtKUxRYn9KuPTWf4C5CeUZdab2iAF8R1sc=; b=WwblvNan3f24Ci0rPDOD1qoyJ3NTz2xohs5bmXaXgl+y4ywnXWr1TWwnS2OqAGk3oC K5XosOhDeYmqIDuDUyAC/6LHJBifjPdI89nN4eoT34YI+6tSh5zuvkHXFNUIbwH4KCpk 3QGPBNky4Eo8V1wCaQyJW9mYKEAI2ew0kMwa0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PUWkRCQFHjtKUxRYn9KuPTWf4C5CeUZdab2iAF8R1sc=; b=DsGOcTn8eFYW0CVSPickNFusYAD19xf3h3TfmBTvX2cahrXHhW6AnDBvL4FS9n7PQA vGXTjUtQVH30b/PgpM5dmDcsx8UdbWAEd5yRnk3mioooL4zkJl/aoVcBHaY0yhiV4kV/ tfEKROlalv2hZUn5akuWSJveNdjzxSkWsZTF2iQ5x6dhXIQHDkzxnCAwAjuC6HX2M/wg +5QZq3weaSxvOrnATyrEXO+YklQpXyQKe5M2cXu+JZCJhl7/lxuQyvK7/rcJPxq3kafp GdQyQ1eLuZWhgdFriXvz+gsTbk7/bCOiCqXSvyiZceJMOiPCFvwYzYMxoy5u52ZpOuUz XPPQ== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr9905443pbc.35.1335386059028; Wed, 25 Apr 2012 13:34:19 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Wed, 25 Apr 2012 13:34:18 -0700 (PDT) In-Reply-To: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> Date: Wed, 25 Apr 2012 13:34:18 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl1BcxLQuV62AgcvTLoUjkAnr8aweG4b4TEMf/R/4roJVl/A6ZwkjQXDzGX+gzDTIMt/iR6 Cc: manet@ietf.org, Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:34:20 -0000 Stan, On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff wrote: > I think that any attempt to force MAC addresses into 5444 address blocks for > DLEP *only* (at least it's only DLEP at this time) is basically trying to > ram a square peg into a round hole - with a sufficiently large > sledge-hammer, "anything is possible". My concern all along with doing that > is that we end up with a one-off, and I'm strongly opposed to that. IMO, the > way to address it "properly" is with "RFC 5444 bis"., and I don't see any > energy to do that. I don't understand that. RFC5444 can be used for any address length. Therefore, using 6 byte addresses is absolutely conform with RFC5444 and not DLEP *only*. There would be no need for a RFC5444 bis. Ulrich From teco@inf-net.nl Wed Apr 25 13:46:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017E611E8072 for ; Wed, 25 Apr 2012 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT09IIvOaSGu for ; Wed, 25 Apr 2012 13:46:26 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3A11E8074 for ; Wed, 25 Apr 2012 13:46:20 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4417956wib.13 for ; Wed, 25 Apr 2012 13:46:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X+d+Pqovke1wx6uWPjLFt6AR8tzIBfMo2NTBsIwq/ZA=; b=YgCIDqz5IFSaX/Lb+yEhMUikz9g+Px/3iuSjpUU7M16M2ZQrLFHIBmLYLEXbnqM1VM EyQ3eRhuRdlqxdsl35WlKF7g13qRUeBOEGpfhPYue1Oeq4pen69tZF3Lk+95WtuwaRVF d/jybTfh3FUpvdbSkJdLZ3vKYGJEF1qlATxA6vZu3sG5w7U27YdfmV/VbE/JBPtoeOAX bVf5xpUECdk0ckSIPmGlTE9RNYLJySC4Qs3NsGuqm6PDWcB1V8ZUpUdSs8SPyVD+8Jr3 lNHbOIL7nSrXmoE559p/pqKfYMhEtWQ4EJ1XEZCPV02xC5IKNJOg5cfP0Pro3yEIS72U 4ZOQ== Received: by 10.216.131.24 with SMTP id l24mr2498482wei.76.1335386779806; Wed, 25 Apr 2012 13:46:19 -0700 (PDT) Received: from [10.87.40.20] ([80.187.201.33]) by mx.google.com with ESMTPS id gg2sm2872397wib.7.2012.04.25.13.46.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 13:46:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Wed, 25 Apr 2012 22:46:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: <64B394D0-6B14-4B8D-A20A-B5605D0B48D8@inf-net.nl> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnmhrDBvTfFUbR4QyJiCEYjWEjV5YIc0AVL9H/la/e7fq7NV8jSJ5pUbx3TA/ye+oKmqCtg Cc: manet@ietf.org, Abdussalam Baryun , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:46:27 -0000 Op 25 apr. 2012, om 22:24 heeft Henning Rogge het volgende geschreven: > Each radio (from the point of view of the IP router) has a mac > address, so its a natural way to describe radios by their mac address. I guess it is all about MAC addresses of far-en routers. The local radio would have a MAC address, could be used as orig-addr. There could be multiple local radio's, probably on same Ethernet segment. On separate segments, MAC addresses may overlap. Applies to local radios and remote routers. Teco From teco@inf-net.nl Wed Apr 25 13:54:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6D11E808A for ; Wed, 25 Apr 2012 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fi35YXSk0P3 for ; Wed, 25 Apr 2012 13:54:53 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6DE11E8072 for ; Wed, 25 Apr 2012 13:54:49 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4816964wib.1 for ; Wed, 25 Apr 2012 13:54:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mK4mF8R18BzVWzXdSfadeDZU/cNMCLyekmc6QhgSvmw=; b=i+gBs4AzZd39pY+dVEF8QPuwN9CXPgJFfa51vvzbLbLYvEUye1BzPwoJRp2dQnHbVW yShQA0e9qziyFMuSYb/TWpwwFHBPh0t5XaOASa59h+PTifYEzE+o6Dm0kxySXZqVSEDl alHXxbEJKqWXIFzlAD3cXGVA00xsO9Au3jaL854W+BmXz0A+cImHYdghUaBOoSCI5//N GUO8RCLsueEg3ZEsf+XugYQTwzuU7EBrtxHxWFXWDSKiJ05Vug41P1AqHjBmzBqBLyYH DmDA3uybkPHCae238eBtnsRCR3OVFmRYIyeiZXe0cXeGizi+SOU8Lo1aZLI0GJkz2RnC KIdA== Received: by 10.216.135.103 with SMTP id t81mr2535475wei.113.1335387285523; Wed, 25 Apr 2012 13:54:45 -0700 (PDT) Received: from [10.87.40.20] ([80.187.201.33]) by mx.google.com with ESMTPS id b3sm39853054wib.4.2012.04.25.13.54.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 13:54:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Wed, 25 Apr 2012 22:54:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkTZc8MuCyo7ZlO/ZRFpAozIaoADqdxAdMqgsvELVcVpRSM49NsDhoz5bjx/vce8pAcY6nQ Cc: manet@ietf.org, Abdussalam Baryun , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:54:53 -0000 Op 25 apr. 2012, om 22:34 heeft Ulrich Herberg het volgende geschreven: > Stan, >=20 > On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff = wrote: >> I think that any attempt to force MAC addresses into 5444 address = blocks for >> DLEP *only* (at least it's only DLEP at this time) There is OLSR at layer 2.something around. I guess it will use OLSRv2=20 one time. >> is basically trying to >> ram a square peg into a round hole - with a sufficiently large >> sledge-hammer, "anything is possible". My concern all along with = doing that >> is that we end up with a one-off, and I'm strongly opposed to that. = IMO, the >> way to address it "properly" is with "RFC 5444 bis"., and I don't see = any >> energy to do that. >=20 > I don't understand that. RFC5444 can be used for any address length. > Therefore, using 6 byte addresses is absolutely conform with RFC5444 > and not DLEP *only*. There would be no need for a RFC5444 bis. +1. Thanks to Henning. Teco >=20 > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Apr 25 14:15:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8911E8099 for ; Wed, 25 Apr 2012 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RrXWisvzm4v for ; Wed, 25 Apr 2012 14:15:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDBC011E808E for ; Wed, 25 Apr 2012 14:14:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so462903vbb.31 for ; Wed, 25 Apr 2012 14:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kAGauf1KH3sG32OhvYI8nhhDAh2OpIsaz4cF7w/yk6k=; b=N+WlITYiVyJB7XX9F92ZhHO8vkDgjyOohOTplHNUXR8QmO3pjEzgf46WqdL7o2jNAa hL9eHcl9e6mGgwgkcIUEg+qFs8FuKglEq8tWEHTlLWUYidYDiHVqep2DH7uS8ZNlP4NT lZkHnBmz0cIXyqs/ewaW7p/Wym+U9BNBgX7DH3+7ZcO2rOvkSvSTmMl6rdG20iWZH+uz xUncdxwT5ioTSdvB5qYLr6sEBO1EJFNyisxHl/q0JUt3kP+p/Z1U/jroZgHhB3QeBWED jd07F/aqY1YaTS7LKlC9NCxPk+iLctYALVuQg5Onlqf8lPnifg8XrtjXP0Mzr6g0XftP K1gQ== MIME-Version: 1.0 Received: by 10.52.68.77 with SMTP id u13mr3546694vdt.81.1335388498244; Wed, 25 Apr 2012 14:14:58 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Wed, 25 Apr 2012 14:14:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 23:14:58 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge , manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 21:15:03 -0000 Hi Henning, > I would like to talk about the reason why you decided to split the > handshake between Interface and Router apart into that many "orders". > From my point of view, this part of the protocol is very complex > without too much gain. AB> IMHO the manet-dlep-02 needs more definitions about the DLEP communication it referse to in pages 13, 15, 17, 57. AB> in title says Dynamic Link Exchange for DLEP but in body say Data Link Exchange. However, I am still writting down the full-comments, however, it seems difficult to understand the handshaking which I dought there is a handshaking, it seems like interaction between server and clients and neighbors, by sending messages, not full connection. I hope we get some new describtions/definition about these relationship in the next draft as in a terminology section and in some easier to read paragraphs. > > As I can see it, there are several things the handshake should be able to > do: > (I am talking about the Peer Discovery (both), Peer Termination > (including ACK) orders and the bi-directional heartbeat order.) > > - it should allow the router to auto-discover the DLEP-equipped radio > by just listening > - it should allow both the router and the radio to become aware of each > other > - it should allow both the router and the radio to discover a loss of > connection between each other. > > Did I missed something important? AB> I think I may misunderstood the DLEP but I think you may missed:- - That DLEP is a stateful protocol and it is not having a connections with server and client (both are DLEP adapted), the session is initiated in the DLEP entity and bothe server (DLEP's router) and client (radio) have not session between them. -Niegbors are not L3 nor L2 neighbors (only server maybe L2 or L3, or L4) they are L1 (PHY-layer, because clients are physical-modems) neighbors. Each neighbor has a ID = MAC address which is the MAC of the MANET interface. - DLEP interface is not a MANET interface. the router abstract from the DLEP but it exchanged specific messages (control messages) which are out-bound from the data communication. Therefore DLEP faciltates a control path for the router to change modem parameters, and in the same time it gets feedback of the events of link changes. AB> I am not sure what I have said is true but just I repeat what I understood from the draft only. Abdussalam Baryun University of Glamorgan, UK > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From boberry@cisco.com Wed Apr 25 19:27:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C6211E80BB for ; Wed, 25 Apr 2012 19:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy4gWDQsKutL for ; Wed, 25 Apr 2012 19:27:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E07CB11E80C0 for ; Wed, 25 Apr 2012 19:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2060; q=dns/txt; s=iport; t=1335407223; x=1336616823; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dn4oZodlK9HXhevRBa1D2wTCNEeagiXNnOVlJEgzNYY=; b=De5v6gCejD6tpIFbf2ky71Ry97KVxKnnRkexMjMs91JiNUw2aItINIPk 3aTdr/s8ClbNI/DTnp3v9bBHpBuFV6IJ4q1y2VW2wT+zx5yJHm1XaVXoe 2O7OEtVOqP++cRjBhjfhLpTVQtr3lN1iLLr7TqcXfNDV5+1ObfwwBUBLA Q=; X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208,217";a="74912338" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 26 Apr 2012 02:27:02 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-111.cisco.com [10.81.230.111]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3Q2R1bn016657; Thu, 26 Apr 2012 02:27:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Wed, 25 Apr 2012 22:27:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:27:03 -0000 All As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP designation that complements the address. I do not=20 think this fits in the Address block.=20 Still not seeing MAC addresses efficiently fitting into=20 address block. =20 Rather stay with the DLEP MAC, IPv4/6 TLVs. Thanks -Bo ""An address is specified as a sequence of address-length=20 octets of the form Head:Mid:Tail."" is defined by: :=3D (?)? (?)? * * On Apr 25, 2012, at 4:34 PM, Ulrich Herberg wrote: > Stan, >=20 > On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff = wrote: >> I think that any attempt to force MAC addresses into 5444 address = blocks for >> DLEP *only* (at least it's only DLEP at this time) is basically = trying to >> ram a square peg into a round hole - with a sufficiently large >> sledge-hammer, "anything is possible". My concern all along with = doing that >> is that we end up with a one-off, and I'm strongly opposed to that. = IMO, the >> way to address it "properly" is with "RFC 5444 bis"., and I don't see = any >> energy to do that. >=20 > I don't understand that. RFC5444 can be used for any address length. > Therefore, using 6 byte addresses is absolutely conform with RFC5444 > and not DLEP *only*. There would be no need for a RFC5444 bis. >=20 > Ulrich ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From ulrich@herberg.name Wed Apr 25 19:49:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03821F8631 for ; Wed, 25 Apr 2012 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRjJ8I9KMedG for ; Wed, 25 Apr 2012 19:49:06 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62721F8630 for ; Wed, 25 Apr 2012 19:49:06 -0700 (PDT) Received: by dady13 with SMTP id y13so1376638dad.27 for ; Wed, 25 Apr 2012 19:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3sKPGMrp/hCBF6KEHq3Zfqn7akDMmpWGHuF6Nszcn2Y=; b=MU42KcBH/z/RJq2q8/ajLvPeNX1rFY52oyQp0Tg0UUsKeydR3DLCkkqIDHXKMNsHj5 d9L+NcMeJCTRUGkfMzLz2f+OA+kBM7Ypunc+0Nf6Jk1KC2/7zn4HGcWLeBXp08ziWN62 jgT0PRvZ3RCqnUJptZY+XIU0Q5HZwEim049nM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3sKPGMrp/hCBF6KEHq3Zfqn7akDMmpWGHuF6Nszcn2Y=; b=XY1KMEW15XveddPgnHh93+46BHNE8/ePru8z9UYhy72NwyZn6xpx0xFBd1eiOmPJ4f KpLzc63j4HfdT+SdMpRiiqNAIhVN2MWwaSW8DHKDe6z6adGR9/ogDmtai+An1s/zd9uo lZSoS1oKLpuzYLgzuS8NMrEECjcAQg+O+aU2TOeyTJ9ZqqOMqGAPwnS5TwG0jKB6opP4 0D4ojDEcIbm4A+OR6w5tt6dVByBDkTKPBjhPku67WgW/07h8heaKd9wnp0sgVRZGE/3E ObcmL7HEVX0ItKXUY/3/GIPGKAfp+Z19MN9HMxA2+pkRoYh879mc1AO7EPCGO29fi0Uk k1sA== MIME-Version: 1.0 Received: by 10.68.212.133 with SMTP id nk5mr11835164pbc.120.1335408545972; Wed, 25 Apr 2012 19:49:05 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Wed, 25 Apr 2012 19:49:05 -0700 (PDT) In-Reply-To: <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> Date: Wed, 25 Apr 2012 19:49:05 -0700 Message-ID: From: Ulrich Herberg To: Bo Berry Content-Type: multipart/alternative; boundary=e89a8ff1c43003411d04be8c085e X-Gm-Message-State: ALoCoQkvtwBBeVag1cV/FX9j8MI7RNF11CC+d1XSS7jhDE6EKBEHZRzFzJhoHT2t06XTD5/IHCF7 Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 02:49:07 -0000 --e89a8ff1c43003411d04be8c085e Content-Type: text/plain; charset=ISO-8859-1 Bo, On Wed, Apr 25, 2012 at 7:27 PM, Bo Berry wrote: > All > As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP > designation that complements the address. I do not > think this fits in the Address block. > > Still not seeing MAC addresses efficiently fitting into > address block. > Why not? It may not be well compressible if using NICs from different vendors, but at least it would fit well in the RFC5444 architecture and maybe saves some bytes for the TLVs type and length for each address. > > Rather stay with the DLEP MAC, IPv4/6 TLVs. > My concern is that if we 1) don't use address blocks, but 2) use sub-TLVs instead of TLVs, there is not much left of RFC5444. A completely new parser has to be implemented, and one could just as well not use RFC5444 at all. Maybe I just don't see your argument why using address blocks for the MAC addresses (and for the originator address) is bad. To me, it seems the natural way when using RFC5444 on L2. For IPv4/6, I agree that using TLVs is probably the only option, since RFC5444 does not support mixed address lengths (unless we issue an RFC5444bis, which could have compatibility problems). > > > ""An address is specified as a sequence of address-length > octets of the form Head:Mid:Tail."" > > is defined by: > > := > > (?)? > (?)? > * > * > In case the NICs are from different vendors, tail and head would be empty, and all addresses would be in the mid. If NICs are from the same vendor, would likely contain the first three bytes of the vendor ID and would contain the latter three bytes. would quite likely always be empty. Regards Ulrich > > > On Apr 25, 2012, at 4:34 PM, Ulrich Herberg wrote: > > > Stan, > > > > On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff > wrote: > >> I think that any attempt to force MAC addresses into 5444 address > blocks for > >> DLEP *only* (at least it's only DLEP at this time) is basically trying > to > >> ram a square peg into a round hole - with a sufficiently large > >> sledge-hammer, "anything is possible". My concern all along with doing > that > >> is that we end up with a one-off, and I'm strongly opposed to that. > IMO, the > >> way to address it "properly" is with "RFC 5444 bis"., and I don't see > any > >> energy to do that. > > > > I don't understand that. RFC5444 can be used for any address length. > > Therefore, using 6 byte addresses is absolutely conform with RFC5444 > > and not DLEP *only*. There would be no need for a RFC5444 bis. > > > > Ulrich > > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole > use of the intended recipient. This email may contain information that is > protected by NDA. Any unauthorized review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by > reply email and delete all copies of this message. > > > > --e89a8ff1c43003411d04be8c085e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bo,

On Wed, Ap= r 25, 2012 at 7:27 PM, Bo Berry <boberry@cisco.com> wrote:
All
As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP
designation that complements the address. =A0I do not
think this fits in the Address block.

Still not seeing MAC addresses efficiently fitting into
address block.


Why not? It may not be well com= pressible if using NICs from different vendors, but at least it would fit w= ell in the RFC5444 architecture and maybe saves some bytes for the TLVs typ= e and length for each address.
=A0

Rather stay with the DLEP MAC, IPv4/6 TLVs.

My con= cern is that if we 1) don't use address blocks, but 2) use sub-TLVs ins= tead of TLVs, there is not much left of RFC5444. A completely new parser ha= s to be implemented, and one could just as well not use RFC5444 at all.
Maybe I just don't see your argument why using address blocks for the M= AC addresses (and for the originator address) is bad. To me, it seems the n= atural way when using RFC5444 on L2. For IPv4/6, I agree that using TLVs is= probably the only option, since RFC5444 does not support mixed address len= gths (unless we issue an RFC5444bis, which could have compatibility problem= s).
=A0


""An address is specified as a sequence of address-length
octets of the form Head:Mid:Tail.""

=A0 <address-block> is defined by:

=A0 =A0 =A0 <address-block> :=3D <num-addr>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<addr-flags>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(<head-length><= ;head>?)?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(<tail-length><= ;tail>?)?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mid>*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<prefix-length>*<= br>


In case the NICs are from different vendors, t= ail and head would be empty, and all addresses would be in the mid. If NICs= are from the same vendor, <head> would likely contain the first thre= e bytes of the vendor ID and <mid> would contain the latter three byt= es. <tail> would quite likely always be empty.

Regards
Ulrich

=A0


On Apr 25, 2012, at 4:34 PM, Ulrich Herberg wrote:

> Stan,
>
> On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff <sratliff@cisco.com> wrote:
>> I think that any attempt to force MAC addresses into 5444 address = blocks for
>> DLEP *only* (at least it's only DLEP at this time) is basicall= y trying to
>> ram a square peg into a round hole - with a sufficiently large
>> sledge-hammer, "anything is possible". My concern all al= ong with doing that
>> is that we end up with a one-off, and I'm strongly opposed to = that. IMO, the
>> way to address it "properly" is with "RFC 5444 bis&= quot;., and I don't see any
>> energy to do that.
>
> I don't understand that. RFC5444 can be used for any address lengt= h.
> Therefore, using 6 byte addresses is absolutely conform with RFC5444 > and not DLEP *only*. There would be no need for a RFC5444 bis.
>
> Ulrich

----
boberry@cisco.com
This email may contain confidential and privileged material for the sole us= e of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message.




--e89a8ff1c43003411d04be8c085e-- From boberry@cisco.com Wed Apr 25 20:16:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA011E8075 for ; Wed, 25 Apr 2012 20:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhbEN7J4zL4x for ; Wed, 25 Apr 2012 20:16:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04CAA21F890B for ; Wed, 25 Apr 2012 20:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=4486; q=dns/txt; s=iport; t=1335410193; x=1336619793; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Jrw+EBkjSnmTifFcIuObQANTxPeW6K7MAVQKdTX/K9g=; b=nJ0T+fwwEr8nSj/qPYtRTX4Oj65MAY0d/VnUJDLaPf9savrkfI8fv6D3 qQ3Q58GfcUFGyvqGkDXCphT9rgrya1FKnqAuWKk8k++Os80kBJ2urRStg vvQTNCpcyTnO7OBQ0RXbVexPAQfFzS1eSaFQEXFyih0VY6FKUZ5YsSDB9 4=; X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208,217";a="77726346" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 26 Apr 2012 03:16:32 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-114.cisco.com [10.81.230.114]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3Q3GV95016021; Thu, 26 Apr 2012 03:16:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Wed, 25 Apr 2012 23:16:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <848FCD58-95D3-4EA0-BF47-A6F3C222EF4D@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org, Abdussalam Baryun , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 03:16:39 -0000 Ulrich Thanks for the healthy discussion. In-line. -Bo On Apr 25, 2012, at 10:49 PM, Ulrich Herberg wrote: > Bo, >=20 > On Wed, Apr 25, 2012 at 7:27 PM, Bo Berry wrote: > All > As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP > designation that complements the address. I do not > think this fits in the Address block. >=20 > Still not seeing MAC addresses efficiently fitting into > address block. >=20 >=20 > Why not? It may not be well compressible if using NICs from different = vendors, but at least it would fit well in the RFC5444 architecture and = maybe saves some bytes for the TLVs type and length for each address. I'm more concerned about it fitting into DLEP specification and = functionality than mushing MACs into an Address block, for one MAC. It = is easy to parse the MAC TLV and other DLEP TLVs. Given earlier = guidance, we reduced DLEP's footprint on RFC 5444 to a single type. As = for what's left, DLEP continues to use the RFC 5444 message and TLV = structures. IMO, DLEP is heavily vetted in RFC 5444.=20 > =20 >=20 > Rather stay with the DLEP MAC, IPv4/6 TLVs. >=20 > My concern is that if we 1) don't use address blocks, but 2) use = sub-TLVs instead of TLVs, there is not much left of RFC5444. A = completely new parser has to be implemented, and one could just as well = not use RFC5444 at all. > Maybe I just don't see your argument why using address blocks for the = MAC addresses (and for the originator address) is bad. To me, it seems = the natural way when using RFC5444 on L2. For IPv4/6, I agree that using = TLVs is probably the only option, since RFC5444 does not support mixed = address lengths (unless we issue an RFC5444bis, which could have = compatibility problems). > =20 >=20 >=20 > ""An address is specified as a sequence of address-length > octets of the form Head:Mid:Tail."" >=20 > is defined by: >=20 > :=3D > > (?)? > (?)? > * > * >=20 >=20 > In case the NICs are from different vendors, tail and head would be = empty, and all addresses would be in the mid. If NICs are from the same = vendor, would likely contain the first three bytes of the vendor = ID and would contain the latter three bytes. would quite = likely always be empty. >=20 > Regards > Ulrich >=20 > =20 >=20 >=20 > On Apr 25, 2012, at 4:34 PM, Ulrich Herberg wrote: >=20 > > Stan, > > > > On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff = wrote: > >> I think that any attempt to force MAC addresses into 5444 address = blocks for > >> DLEP *only* (at least it's only DLEP at this time) is basically = trying to > >> ram a square peg into a round hole - with a sufficiently large > >> sledge-hammer, "anything is possible". My concern all along with = doing that > >> is that we end up with a one-off, and I'm strongly opposed to that. = IMO, the > >> way to address it "properly" is with "RFC 5444 bis"., and I don't = see any > >> energy to do that. > > > > I don't understand that. RFC5444 can be used for any address length. > > Therefore, using 6 byte addresses is absolutely conform with RFC5444 > > and not DLEP *only*. There would be no need for a RFC5444 bis. > > > > Ulrich >=20 > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the = sole use of the intended recipient. This email may contain information = that is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >=20 >=20 >=20 >=20 ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From henning.rogge@fkie.fraunhofer.de Wed Apr 25 22:32:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F75221F8893 for ; Wed, 25 Apr 2012 22:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=2.321, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvTajKp+LrH8 for ; Wed, 25 Apr 2012 22:32:39 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id D752A21F88FE for ; Wed, 25 Apr 2012 22:32:38 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNHJk-0003CB-It for manet@ietf.org; Thu, 26 Apr 2012 07:32:36 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNHJk-0002MN-GG for manet@ietf.org; Thu, 26 Apr 2012 07:32:36 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 07:32:36 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 07:32:36 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 07:32:35 +0200 Message-ID: <4F98DDF2.9080009@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 07:32:34 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120423 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> In-Reply-To: <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010006040809090409070602" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 05:32:36.0238 (UTC) FILETIME=[FCBEC2E0:01CD236D] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 4e544d76eca59e3a294bec2f89d17dba Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:32:40 -0000 --------------ms010006040809090409070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 04:27 AM, Bo Berry wrote: > All > As defined, the DLEP IPv4& IPV6 TLVs support an ADD/DROP > designation that complements the address. I do not > think this fits in the Address block. Thats exactly whats NHDP is doing in the HELLO message. It use a single address of a specific type for each node to identify (in = the case of DLEP its MAC addresses). The message contains a list of neighbor addresses, the status of the=20 link to the neighbor (in form of a LINK_STATUS TLV) and additional=20 optional information about the link like metrics (at least when used in=20 OLSRv2). > Still not seeing MAC addresses efficiently fitting into > address block. I cannot see how putting them into address blocks can be less efficient=20 and less straight forward (in terms of protocol design) than some=20 special purpose DLEP only "subtlv". Thats exactly what the address fields of RFC 5444 are about. > ""An address is specified as a sequence of address-length > octets of the form Head:Mid:Tail."" > > is defined by: > > :=3D > > (?)? > (?)? > * > * Both head and tail can be length zero, if the specific bit in the=20 addr-flags field is not set. In this case, you don't even need to store=20 a head/tail length. You also don't need a header for each of the addresses, you only need=20 one for all the addresses (up to 255). They will share (optional) a=20 single head and (optional too) a single tail, but each has its own "mid" = part (which might be the whole address). And if you use a bunch of radios of the same type and manufacturer, you=20 might even have the case that all MAC addresses of the devices begin=20 with the same head. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010006040809090409070602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYwNTMyMzRaMCMGCSqGSIb3DQEJBDEWBBTz5eVauo9LWt/DTaPYlE0ylpTxMzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQDBSJmrv9leYjoQaTRXtP9oL91ODnOMUpWeJa8V+/cdbcdkwKy0E9rkpovqnPJF t3QDt/xoKK7GGhJSzuN0YCoj8ms5L7RiL6KFvw/X0H/lfrddU2GtvDjzG00l+r5BCgFMhCIb /v5EP4uafHmycLUHRn7cIuL3L1nTcUGibbYw6V84PAeNJ17Z5Psib9b8688q4VQjSx1WWDnQ +ggfp4MSmUqXt8JbmGuFwbCqvAPCpX0iufaXn3KyLpJVk8xSgz492MFeaUDdML4NdMgVQI3t 0QRf1k2Lkk+RRHGDtI932P20znU0qCUwnbSpOjQQ7wp0cV0SFE1k1q9Zd+lQ211sAAAAAAAA --------------ms010006040809090409070602-- From ulrich@herberg.name Wed Apr 25 22:36:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD9821F8597 for ; Wed, 25 Apr 2012 22:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uleBYqiAB6NK for ; Wed, 25 Apr 2012 22:36:29 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5721F85D6 for ; Wed, 25 Apr 2012 22:36:26 -0700 (PDT) Received: by dady13 with SMTP id y13so1606180dad.27 for ; Wed, 25 Apr 2012 22:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nsCobtwWy+r9rajoyF9zpKJo2h0xPHg5ky4uYQdMaww=; b=J/O7jIWlQk+JD4bfhT4ekugbRbug58J6rtGvjUXV1K1MHkI3uyt6cW+wQttGd9PoA2 jGcyQSebsN0SnuoZLNEfWqzr4UvYvrtPYQfgUkK+kIe8boeLnePx4tqyY36EoALKtMnS N8ENaBrkOjCmzJXYQPlU8kJCsgHIGzIgNJbVE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nsCobtwWy+r9rajoyF9zpKJo2h0xPHg5ky4uYQdMaww=; b=B9q7xRyLQwG9OiqOn7m2T6LBoaHNCZmJ7vvm57gXuxd12ruqr6qpjU/p3Bc9eP9yNY QA4uVOWHaraWFpbcAnIcGiylTukxbbITP6PeZXQGCtORDaNc0TX4G4rdt0U7sU7m/TOk UnrMwl/56nbAvg7olDjlBTNuDMJWYmOmy+Jj4x0ODM11lwrWvxv8mdpr/YwN+aaCbLII Wyacm5Ce/FKtTbMAbEzqKrELGcWOFVmHReSLSS/CjD1bBwf5ZB3iDglYw5dLNi2XNNFT hHiI9bSfB7GuDsvQ6Sk6pEPSJkO3ALQng9j74OsotuZf9V7+WbxzhReshtPGltM3WGtL W9zw== MIME-Version: 1.0 Received: by 10.68.220.2 with SMTP id ps2mr13525105pbc.109.1335418586479; Wed, 25 Apr 2012 22:36:26 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Wed, 25 Apr 2012 22:36:26 -0700 (PDT) In-Reply-To: <4F98DDF2.9080009@fkie.fraunhofer.de> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> <4F98DDF2.9080009@fkie.fraunhofer.de> Date: Wed, 25 Apr 2012 22:36:26 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b2ee199793d2204be8e5ef1 X-Gm-Message-State: ALoCoQnY2JHDeNB19tMH6+ZSDeErw0NsAK3BHJpupayfm39KhUQhuHeIRsKbHy4JzmdFcwdG1cC2 Cc: manet@ietf.org Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:36:30 -0000 --047d7b2ee199793d2204be8e5ef1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 (too all the arguments) On Wed, Apr 25, 2012 at 10:32 PM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 04/26/2012 04:27 AM, Bo Berry wrote: > >> All >> As defined, the DLEP IPv4& IPV6 TLVs support an ADD/DROP >> >> designation that complements the address. I do not >> think this fits in the Address block. >> > > Thats exactly whats NHDP is doing in the HELLO message. > > It use a single address of a specific type for each node to identify (in > the case of DLEP its MAC addresses). > > The message contains a list of neighbor addresses, the status of the link > to the neighbor (in form of a LINK_STATUS TLV) and additional optional > information about the link like metrics (at least when used in OLSRv2). > > > Still not seeing MAC addresses efficiently fitting into >> address block. >> > > I cannot see how putting them into address blocks can be less efficient > and less straight forward (in terms of protocol design) than some special > purpose DLEP only "subtlv". > > Thats exactly what the address fields of RFC 5444 are about. > > > ""An address is specified as a sequence of address-length >> octets of the form Head:Mid:Tail."" >> >> is defined by: >> >> :=3D >> >> (?)? >> (?)? >> * >> * >> > > Both head and tail can be length zero, if the specific bit in the > addr-flags field is not set. In this case, you don't even need to store a > head/tail length. > > You also don't need a header for each of the addresses, you only need one > for all the addresses (up to 255). They will share (optional) a single he= ad > and (optional too) a single tail, but each has its own "mid" part (which > might be the whole address). > > And if you use a bunch of radios of the same type and manufacturer, you > might even have the case that all MAC addresses of the devices begin with > the same head. > > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b2ee199793d2204be8e5ef1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 (too all the arguments)

On Wed, Apr 25, 2012 at 10:32 PM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
On 04/26/2012 04:27 AM, Bo= Berry wrote:
All
As defined, the DLEP IPv4& =A0IPV6 TLVs support an ADD/DROP

designation that complements the address. =A0I do not
think this fits in the Address block.

Thats exactly whats NHDP is doing in the HELLO message.

It use a single address of a specific type for each node to identify (in th= e case of DLEP its MAC addresses).

The message contains a list of neighbor addresses, the status of the link t= o the neighbor (in form of a LINK_STATUS TLV) and additional optional infor= mation about the link like metrics (at least when used in OLSRv2).


Still not seeing MAC addresses efficiently fitting into
address block.

I cannot see how putting them into address blocks can be less efficient and= less straight forward (in terms of protocol design) than some special purp= ose DLEP only "subtlv".

Thats exactly what the address fields of RFC 5444 are about.


""An address is specified as a sequence of address-length
octets of the form Head:Mid:Tail.""

=A0 =A0<address-block> =A0is defined by:

=A0 =A0 =A0 =A0<address-block> =A0:=3D<num-addr>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <addr-flags>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (<head-length>&l= t;head>?)?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (<tail-length>&l= t;tail>?)?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mid>*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <prefix-length>*=

Both head and tail can be length zero, if the specific bit in the addr-flag= s field is not set. In this case, you don't even need to store a head/t= ail length.

You also don't need a header for each of the addresses, you only need o= ne for all the addresses (up to 255). They will share (optional) a single h= ead and (optional too) a single tail, but each has its own "mid" = part (which might be the whole address).

And if you use a bunch of radios of the same type and manufacturer, you mig= ht even have the case that all MAC addresses of the devices begin with the = same head.


Henning Rogge

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0


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


--047d7b2ee199793d2204be8e5ef1-- From henning.rogge@fkie.fraunhofer.de Wed Apr 25 23:43:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F190B21F8564 for ; Wed, 25 Apr 2012 23:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[AWL=2.244, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dkQ+ahsYGDR for ; Wed, 25 Apr 2012 23:43:54 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 214BA21F855D for ; Wed, 25 Apr 2012 23:43:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNI6A-0005UW-Cf for manet@ietf.org; Thu, 26 Apr 2012 08:22:38 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNI6A-0003Z7-A3 for manet@ietf.org; Thu, 26 Apr 2012 08:22:38 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 08:22:38 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 08:22:38 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 08:22:36 +0200 Message-ID: <4F98E9AC.2040809@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 08:22:36 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120423 Thunderbird/12.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704000108040104060202" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 06:22:38.0054 (UTC) FILETIME=[F9F78860:01CD2374] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: bde457e082b6573242c43f66a8a95436 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:43:55 -0000 --------------ms050704000108040104060202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/25/2012 11:14 PM, Abdussalam Baryun wrote: > However, I am still writting down the full-comments, however, it seems > difficult to understand the handshaking which I dought there is a > handshaking, it seems like interaction between server and clients and > neighbors, by sending messages, not full connection. I hope we get > some new describtions/definition about these relationship in the next > draft as in a terminology section and in some easier to read > paragraphs. Thats why I am asking for confirmation that I got the use behind this=20 protocol parts right. I am also not really happy with the names of the radio and the router=20 part, both are called 'peer something', which can be quite confusing. Calling them "radio/interface" and "router" would be more intuitive to=20 understand. >> >> As I can see it, there are several things the handshake should be able= to >> do: >> (I am talking about the Peer Discovery (both), Peer Termination >> (including ACK) orders and the bi-directional heartbeat order.) >> >> - it should allow the router to auto-discover the DLEP-equipped radio >> by just listening >> - it should allow both the router and the radio to become aware of eac= h >> other >> - it should allow both the router and the radio to discover a loss of >> connection between each other. >> >> Did I missed something important? > > AB> I think I may misunderstood the DLEP but I think you may missed:- > > - That DLEP is a stateful protocol and it is not having a connections > with server and client (both are DLEP adapted), the session is > initiated in the DLEP entity and bothe server (DLEP's router) and > client (radio) have not session between them. That exactly how I see it too. We have an active DLEP component (the=20 radio) and a reactive one (the router). The whole session establishment=20 is to get both sides known to each other in an easy, robust way and fast = way. > -Niegbors are not L3 nor L2 neighbors (only server maybe L2 or L3, or > L4) they are L1 (PHY-layer, because clients are physical-modems) > neighbors. Each neighbor has a ID =3D MAC address which is the MAC of > the MANET interface. If each neighbor has a MAC address which is used as its ID, they are=20 both layer-1 and layer-2 from DLEP point of view. > - DLEP interface is not a MANET interface. the router abstract from > the DLEP but it exchanged specific messages (control messages) which > are out-bound from the data communication. DLEP is control-traffic agnostic, it should not care about how its=20 transported between the router and the radio. > Therefore DLEP faciltates a control path for the router to change > modem parameters, and in the same time it gets feedback of the events > of link changes. I was just asking questions about the "Session establishment" part of DLE= P. As I see it, the current draft describes five parts of DLEP. - router-radio Session establishment (and teardown) - transportation of known neighbors from radio to router (optional with=20 known IP addresses) - transportation of metric data from radio to router - controlling the link characteristics of the radio by the router - traffic shaping on the radio with a token scheme by the router Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050704000108040104060202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYwNjIyMzZaMCMGCSqGSIb3DQEJBDEWBBRR3za+XpqRC9s0drsHbQE0WiJ+ZzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAPUKyNtQ3oiR3gh28mM6uJEDZHiM5RgLXZyURHRiErX3GxrkGvS1v7mlrGVjoc awF8VjlbMgiQjpicXokIT6rZM4Sbs2ooX00gu4wWL65wdD3MijRRusG/haX8osgAzhJS9jrI /n2T0u2SRiurhFiBoB2rx9RlaJ96qZ1OcGZg4uG4sKMCQQLdIOPxjIY8B6YBNBtm3Njr/Su3 84U5zySggxff3ph3D9SdxIsCZjU1zFuob9O7PIvpwWKB5SLYuVMAXx9SCNA0EYcoDeqzL6U1 RxWUBLD6LKNINi0iLLFOal6Jn/ckZgSCpBLDQFezZOiFdbsX/o3nxizvldbI2mKYAAAAAAAA --------------ms050704000108040104060202-- From rick.taylor@cassidian.com Thu Apr 26 02:25:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46721F86DA for ; Thu, 26 Apr 2012 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKaRwPW3s6Q5 for ; Thu, 26 Apr 2012 02:25:58 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 757AD21F86D3 for ; Thu, 26 Apr 2012 02:25:56 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 11:25:53 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 11:25:52 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:25:50 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:25:50 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:25:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 10:25:49 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA Thread-Index: Ac0jIYX/zBn0/EcQT6a+i2vl0EbPngAbCLXQ References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: "Rick Taylor" To: "Henning Rogge" , "Stan Ratliff" X-OriginalArrivalTime: 26 Apr 2012 09:25:44.0353 (UTC) FILETIME=[8E4FB910:01CD238E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--32.696300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:25:59 -0000 Stan, Henning, et.al. Concerning using MAC-addresses in RFC5444 Address-Block TLVs for DLEP *neighbour* messages... +1=20 It's a good fit. =20 Doesn't require RFC5444bis. =20 Minimal changes to existing DLEP draft. =20 Keeps in the 'spirit' of RFC5444. IP Addresses in Address Blocks... -1 IP addresses are secondary/optional information, and should not be used as a 'key' field in messages. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Henning Rogge > Sent: 25 April 2012 21:25 > To: Stan Ratliff > Cc: manet@ietf.org; Bo Berry; Abdussalam Baryun > Subject: Re: [manet] DLEP and modemLPA >=20 > On Wed, Apr 25, 2012 at 21:41, Stan Ratliff wrote: > > I think that any attempt to force MAC addresses into 5444 address blocks > for > > DLEP *only* (at least it's only DLEP at this time) is basically trying > to > > ram a square peg into a round hole - with a sufficiently large > > sledge-hammer, "anything is possible". My concern all along with doing > that > > is that we end up with a one-off, and I'm strongly opposed to that. IMO, > the > > way to address it "properly" is with "RFC 5444 bis"., and I don't see > any > > energy to do that. >=20 > It was an explicit design decission for RFC 5444 that it is not > restricted to IP as addresses, but just sees addresses as a binary > field of 1 to 16 bytes. So using a RFC 5444 message with 6 bytes > addresses for DLEP is fitting the round cylinder into the round hole. >=20 > Each radio (from the point of view of the IP router) has a mac > address, so its a natural way to describe radios by their mac address. >=20 > And then you can attach any kind of (optional) information you have > about the radios to these mac addresses. >=20 > I don't see where this doesn't fit the concept of RFC 5444. >=20 > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Thu Apr 26 02:33:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6DA21F86E5 for ; Thu, 26 Apr 2012 02:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.778 X-Spam-Level: X-Spam-Status: No, score=-3.778 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1UXRd8b1d5b for ; Thu, 26 Apr 2012 02:33:50 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1217D21F8794 for ; Thu, 26 Apr 2012 02:33:50 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNL58-0006S6-UQ for manet@ietf.org; Thu, 26 Apr 2012 11:33:46 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNL58-0000Y2-Rn for manet@ietf.org; Thu, 26 Apr 2012 11:33:46 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:33:46 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 11:33:46 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 11:33:45 +0200 Message-ID: <4F991673.3050402@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 11:33:39 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040300070908060107060502" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 09:33:46.0565 (UTC) FILETIME=[ADBB6F50:01CD238F] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e2b21d81e24158e5c3d75098b3c9c024 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:33:51 -0000 --------------ms040300070908060107060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 11:25 AM, Rick Taylor wrote: > Stan, Henning, et.al. > > Concerning using MAC-addresses in RFC5444 Address-Block TLVs for DLEP > *neighbour* messages... > > +1 > > It's a good fit. > Doesn't require RFC5444bis. > Minimal changes to existing DLEP draft. > Keeps in the 'spirit' of RFC5444. > > IP Addresses in Address Blocks... > > -1 > > IP addresses are secondary/optional information, and should not be used= > as a 'key' field in messages. Just to make sure I understand you correctly... You mean that you do not want to use IPs as DLEP messages addresses in=20 Address Blocks, right? Its still okay to carry them in Address-Block TLVs, to bind them to the=20 corresponding MAC address? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040300070908060107060502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYwOTMzNDRaMCMGCSqGSIb3DQEJBDEWBBSo7u0agS9JJIBnfk5q3qam6GVIszBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBVeG+KtAIF5xwLHXRbcXyNoZjSer/OU8GsBBoY3rwBlG3QfzgGVaWOE5shF7yg QZiqs6B6P7nlXTw4wh9AwOb3zyGpkE4G8Lyqerrj57of7V+6VTzSOMpmD7tdC4a+kTg/8rV+ Q1YQSoXAAeXp1xdvVQsIW0aNm4vcIbygLHQgyY3FDWQUFHyC06xjV0JMyKDkHA8xXQ/LSzVV RgI8NBONbcd1i92zoaPUewJh1/dD/Mtih8ieCMiSRv94rtCViPTctZV0w0q8mzLy3qsr6P9w 2+sklP7UDysfqo1CuPBlpJ3W9YyGMr+WUATi8+PXNPo14XrV3Ajva8eAjL1EG/7tAAAAAAAA --------------ms040300070908060107060502-- From Chris.Dearlove@baesystems.com Thu Apr 26 02:44:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0C21F87D6 for ; Thu, 26 Apr 2012 02:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XJ8s1CO9gf5 for ; Thu, 26 Apr 2012 02:44:49 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5321F87D2 for ; Thu, 26 Apr 2012 02:44:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="234201766" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 10:44:48 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3Q9il6X029859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 10:44:47 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 10:44:48 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Ulrich Herberg Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94Vg Date: Thu, 26 Apr 2012 09:44:47 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> In-Reply-To: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:44:50 -0000 Stan > I think that any attempt to force MAC addresses into 5444 address > blocks for DLEP *only* (at least it's only DLEP at this time) is > basically trying to ram a square peg into a round hole - with a > sufficiently large sledge-hammer, "anything is possible". I think that's a mischaracterisation. 5444 uses addresses, And all it cares about is how many octets there are in an address. A six byte address (which happens to be a MAC address) is just another address type as far as 5444 is concerned. (You can thank the IESG for that being so, that wasn't in the original packetbb concept, but it is in 5444.) I think it's clear that there is a superior way to present the information using 5444 than the not nice sub-TLVs of the current proposal. Unfortunately while I think it's clear, and so do several other people here, Stan and Bo aren't in that group, and I'm not sure how to persuade them of that. Note that I'm not saying all proposals for modified formats have been good ones - the use of IPv6 addresses for all address types was one idea that was thought of, played around with a bit, and discarded as not a good idea. Bo seems to still think it's what's being proposed however. To be clear, the suggestion (which I think I would say has "consensus among those people who think the format should be changed, but not consensus among all including the DLEP authors") is roughly - That information which is local, and not associated with an address is put in the message TLV block. - That information which is not local is associated with a MAC address. The MAC addresses are put in the address blocks, and other information associated with them is put in the following TLV block. - One such piece of information is an IPv4 or IPv6 address, which uses a TLV, not an address block. Other information includes metrics etc. - Metrics use one, or a small number, of TLV types, and the metric type uses the TLV type extension. But what we need is a concrete example to be coded up in both ways. No one seems willing to do this however. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Thu Apr 26 02:46:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5F421F861D for ; Thu, 26 Apr 2012 02:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqFjpQsuC0f3 for ; Thu, 26 Apr 2012 02:46:16 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD5421F8615 for ; Thu, 26 Apr 2012 02:46:15 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 11:46:15 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 11:46:15 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:46:15 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:46:15 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:46:09 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 10:46:14 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA Thread-Index: Ac0jj+V+WXS3uvycTeWEZUqYeum1cQAAGuyg References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 26 Apr 2012 09:46:09.0470 (UTC) FILETIME=[6889BDE0:01CD2391] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--3.605700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:46:17 -0000 Henning, > Just to make sure I understand you correctly... >=20 > You mean that you do not want to use IPs as DLEP messages addresses in > Address Blocks, right? Correct, I do not want to see them used there. =20 > Its still okay to carry them in Address-Block TLVs, to bind them to the > corresponding MAC address? Yes, as 'normal' TLVs, they can go wherever they are needed as currently specified in draft-02. As Teco says, layer 3 address TLVs should be optional. =20 I agree with Stan that it is really useful to have Layer 3 addressing delivered via DLEP when the modem knows it, but there are examples where the modem does not know, but DLEP can still function. =20 (I am using such a modem now, and I just ARP for the Layer 3 addresses, it's possible, but a PITA, particularly as InARP is largely unsupported in the real world). Rick Taylor From rick.taylor@cassidian.com Thu Apr 26 02:51:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1689A21F8711 for ; Thu, 26 Apr 2012 02:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98MZYVsHa1p3 for ; Thu, 26 Apr 2012 02:51:49 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2798121F85F6 for ; Thu, 26 Apr 2012 02:51:48 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 26 Apr 2012 11:51:47 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 11:51:46 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:51:46 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:51:45 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:51:40 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 10:51:44 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94VggAAFlVA= References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" , "Ulrich Herberg" X-OriginalArrivalTime: 26 Apr 2012 09:51:40.0179 (UTC) FILETIME=[2DA7EE30:01CD2392] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--3.480600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:51:50 -0000 Chris, > To be clear, the suggestion (which I think I would say has "consensus > among those people who think the format should be changed, but not > consensus among all including the DLEP authors") is roughly > - That information which is local, and not associated with an address is > put in the message TLV block. > - That information which is not local is associated with a MAC address. > The MAC addresses are put in the address blocks, and other information > associated with them is put in the following TLV block. > - One such piece of information is an IPv4 or IPv6 address, which uses a > TLV, not an address block. Other information includes metrics etc. > - Metrics use one, or a small number, of TLV types, and the metric type > uses the TLV type extension. +1 your summary > >But what we need is a concrete example to be coded up in both ways. >No one seems willing to do this however. > I did send out some ASCII-art message blocks describing what you summarize to this mailing list a few weeks ago. I'll dig them out and resend if it would help? Or are you suggesting a 'running code' example? Rick Taylor From rick.taylor@cassidian.com Thu Apr 26 02:59:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0321F87E5 for ; Thu, 26 Apr 2012 02:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gksqRkhoAgzG for ; Thu, 26 Apr 2012 02:59:48 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 124AA21F87A3 for ; Thu, 26 Apr 2012 02:59:47 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 11:59:46 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 11:59:45 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:59:45 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:59:44 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 10:59:39 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 10:59:43 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CC83@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94VggAAFlVCAAALRkA== References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: "Rick Taylor" To: "Rick Taylor" , "Dearlove, Christopher (UK)" , "Stan Ratliff" , "Ulrich Herberg" X-OriginalArrivalTime: 26 Apr 2012 09:59:39.0188 (UTC) FILETIME=[4B2AE740:01CD2393] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--25.240200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:59:49 -0000 Chris, I just checked the archive. I didn't send any ASCII art of Address-Block TLVs, just a discovery packet as part of the metric TLV discussion using a Message-Block. I'll do a few today, probably for NeighbourUp. Anyone have any requests for the examples? Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Rick Taylor > Sent: 26 April 2012 10:52 > To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg > Cc: manet@ietf.org; Bo Berry; Abdussalam Baryun > Subject: Re: [manet] DLEP and modemLPA >=20 > Chris, >=20 > > To be clear, the suggestion (which I think I would say has "consensus > > among those people who think the format should be changed, but not > > consensus among all including the DLEP authors") is roughly > > - That information which is local, and not associated with an address > is > > put in the message TLV block. > > - That information which is not local is associated with a MAC > address. > > The MAC addresses are put in the address blocks, and other > information > > associated with them is put in the following TLV block. > > - One such piece of information is an IPv4 or IPv6 address, which uses > a > > TLV, not an address block. Other information includes metrics etc. > > - Metrics use one, or a small number, of TLV types, and the metric > type > > uses the TLV type extension. >=20 > +1 your summary >=20 > > > >But what we need is a concrete example to be coded up in both ways. > >No one seems willing to do this however. > > >=20 > I did send out some ASCII-art message blocks describing what you > summarize to this mailing list a few weeks ago. >=20 > I'll dig them out and resend if it would help? Or are you suggesting a > 'running code' example? >=20 > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Apr 26 03:00:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B017521F863C for ; Thu, 26 Apr 2012 03:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTYjRz1SdboF for ; Thu, 26 Apr 2012 03:00:58 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB321F861D for ; Thu, 26 Apr 2012 03:00:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="234208925" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 11:00:57 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QA0ukr009360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 11:00:57 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 11:00:57 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Ulrich Herberg Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAADsMAgABij4CAAAYogIAAB6qAgACAg8A= Date: Thu, 26 Apr 2012 10:00:56 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <423272BA-C35B-4AC0-ADC3-33BBAADC3DFE@cisco.com> <848FCD58-95D3-4EA0-BF47-A6F3C222EF4D@cisco.com> In-Reply-To: <848FCD58-95D3-4EA0-BF47-A6F3C222EF4D@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:00:59 -0000 Not that I think that a little more would hurt, it's possible to keep the D= LEP allocation to being a single message type while restructuring it, by si= mply making all TLVs be allocated from that message specific TLV allocation= . As for the ease of parsing DLEP sub-TLVs, it's even easier to write the cod= e to parse the proposed restructuring. I already have it, and so do several= other people (their own versions). --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 26 April 2012 04:17 To: Ulrich Herberg Cc: manet@ietf.org; Abdussalam Baryun; Stan Ratliff Subject: Re: [manet] DLEP and modemLPA ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Ulrich Thanks for the healthy discussion. In-line. -Bo On Apr 25, 2012, at 10:49 PM, Ulrich Herberg wrote: > Bo, >=20 > On Wed, Apr 25, 2012 at 7:27 PM, Bo Berry wrote: > All > As defined, the DLEP IPv4 & IPV6 TLVs support an ADD/DROP > designation that complements the address. I do not > think this fits in the Address block. >=20 > Still not seeing MAC addresses efficiently fitting into > address block. >=20 >=20 > Why not? It may not be well compressible if using NICs from different ven= dors, but at least it would fit well in the RFC5444 architecture and maybe = saves some bytes for the TLVs type and length for each address. I'm more concerned about it fitting into DLEP specification and functionali= ty than mushing MACs into an Address block, for one MAC. It is easy to par= se the MAC TLV and other DLEP TLVs. Given earlier guidance, we reduced DLE= P's footprint on RFC 5444 to a single type. As for what's left, DLEP conti= nues to use the RFC 5444 message and TLV structures. IMO, DLEP is heavily = vetted in RFC 5444.=20 > =20 >=20 > Rather stay with the DLEP MAC, IPv4/6 TLVs. >=20 > My concern is that if we 1) don't use address blocks, but 2) use sub-TLVs= instead of TLVs, there is not much left of RFC5444. A completely new parse= r has to be implemented, and one could just as well not use RFC5444 at all. > Maybe I just don't see your argument why using address blocks for the MAC= addresses (and for the originator address) is bad. To me, it seems the nat= ural way when using RFC5444 on L2. For IPv4/6, I agree that using TLVs is p= robably the only option, since RFC5444 does not support mixed address lengt= hs (unless we issue an RFC5444bis, which could have compatibility problems)= . > =20 >=20 >=20 > ""An address is specified as a sequence of address-length > octets of the form Head:Mid:Tail."" >=20 > is defined by: >=20 > :=3D > > (?)? > (?)? > * > * >=20 >=20 > In case the NICs are from different vendors, tail and head would be empty= , and all addresses would be in the mid. If NICs are from the same vendor, = would likely contain the first three bytes of the vendor ID and would contain the latter three bytes. would quite likely always be= empty. >=20 > Regards > Ulrich >=20 > =20 >=20 >=20 > On Apr 25, 2012, at 4:34 PM, Ulrich Herberg wrote: >=20 > > Stan, > > > > On Wed, Apr 25, 2012 at 12:41 PM, Stan Ratliff wro= te: > >> I think that any attempt to force MAC addresses into 5444 address bloc= ks for > >> DLEP *only* (at least it's only DLEP at this time) is basically trying= to > >> ram a square peg into a round hole - with a sufficiently large > >> sledge-hammer, "anything is possible". My concern all along with doing= that > >> is that we end up with a one-off, and I'm strongly opposed to that. IM= O, the > >> way to address it "properly" is with "RFC 5444 bis"., and I don't see = any > >> energy to do that. > > > > I don't understand that. RFC5444 can be used for any address length. > > Therefore, using 6 byte addresses is absolutely conform with RFC5444 > > and not DLEP *only*. There would be no need for a RFC5444 bis. > > > > Ulrich >=20 > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that is p= rotected by NDA. Any unauthorized review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y email and delete all copies of this message. >=20 >=20 >=20 >=20 ---- boberry@cisco.com This email may contain confidential and privileged material for the sole us= e of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Thu Apr 26 03:04:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49BF21F8674 for ; Thu, 26 Apr 2012 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FXK9zAZ1q68 for ; Thu, 26 Apr 2012 03:04:13 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D51B621F863C for ; Thu, 26 Apr 2012 03:04:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="234210745" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 11:04:12 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QA4BHc011782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 11:04:11 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 11:04:11 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Stan Ratliff , Ulrich Herberg Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94VggAAFlVCAAAPlUA== Date: Thu, 26 Apr 2012 10:04:10 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:04:13 -0000 I'm suggesting a form of listing of what information is to be reported, to = then be coded up each way (whether expressed as ASCII art or an octet listi= ng isn't critical). It would need to be an example that includes all the cr= itical features needed (e.g. local information, non-local information, some= , but not all, IP addresses etc.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com]=20 Sent: 26 April 2012 10:52 To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg Cc: manet@ietf.org; Bo Berry; Abdussalam Baryun Subject: RE: [manet] DLEP and modemLPA ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Chris, > To be clear, the suggestion (which I think I would say has "consensus > among those people who think the format should be changed, but not > consensus among all including the DLEP authors") is roughly > - That information which is local, and not associated with an address is > put in the message TLV block. > - That information which is not local is associated with a MAC address. > The MAC addresses are put in the address blocks, and other information > associated with them is put in the following TLV block. > - One such piece of information is an IPv4 or IPv6 address, which uses a > TLV, not an address block. Other information includes metrics etc. > - Metrics use one, or a small number, of TLV types, and the metric type > uses the TLV type extension. +1 your summary > >But what we need is a concrete example to be coded up in both ways. >No one seems willing to do this however. > I did send out some ASCII-art message blocks describing what you summarize to this mailing list a few weeks ago. I'll dig them out and resend if it would help? Or are you suggesting a 'running code' example? Rick Taylor ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Apr 26 03:26:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFFB21F87A5 for ; Thu, 26 Apr 2012 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=2.113, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrbVC515qrdn for ; Thu, 26 Apr 2012 03:26:49 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1321F8663 for ; Thu, 26 Apr 2012 03:26:49 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNLuS-0000nU-Ns for manet@ietf.org; Thu, 26 Apr 2012 12:26:48 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNLuS-00027m-LF for manet@ietf.org; Thu, 26 Apr 2012 12:26:48 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:26:48 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 12:26:48 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 12:26:47 +0200 Message-ID: <4F9922E3.2030102@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 12:26:43 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030400080108030707040604" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 10:26:48.0335 (UTC) FILETIME=[163701F0:01CD2397] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:26:50 -0000 --------------ms030400080108030707040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 11:44 AM, Dearlove, Christopher (UK) wrote: > To be clear, the suggestion (which I think I would say has "consensus > among those people who think the format should be changed, but not > consensus among all including the DLEP authors") is roughly > - That information which is local, and not associated with an address i= s > put in the message TLV block. > - That information which is not local is associated with a MAC address.= > The MAC addresses are put in the address blocks, and other informati= on > associated with them is put in the following TLV block. > - One such piece of information is an IPv4 or IPv6 address, which uses = a > TLV, not an address block. Other information includes metrics etc. > - Metrics use one, or a small number, of TLV types, and the metric type= > uses the TLV type extension. +1 I think thats a correct and good description of the current suggestion. > But what we need is a concrete example to be coded up in both ways. > No one seems willing to do this however. Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay=20 for this? And should the result contain the structure of the=20 packet/message, the binary content or both? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030400080108030707040604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMDI2NDZaMCMGCSqGSIb3DQEJBDEWBBQgTNAUGXjSFXELGL3VEKvGCtepLTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBB5GovydQKFjiO19T0f7wufmp7AAmL5vf7lcBgjLCRMAUi/Une7rGfm2IC/h0Y RhgjshOwob+0j384FHgm4hq+H+m5Vpy5PCEWBvRK+0M/WBq/ZSlVpjnIO/HaG3SOibVBkI1j dubZMLm0DAqDhrjzLlUm9L7OEMGKmexcRWfKAdAt66EMpRjQ0RPGJ+dvUxkdEtpT7pJ4CY+3 Zsn+UpiXVGdbgw6da+BVnTeC+gva2QyrSvEJG3SLA7KHP4n5Qpwm/66tVGQi57BaX7CJ9POV HP7Xs0/F7CCAq+MVJ4DLHd7cfrVLOkKAJHcjvF2+sXGrhgvOo4emrEbpCJAX0vinAAAAAAAA --------------ms030400080108030707040604-- From rick.taylor@cassidian.com Thu Apr 26 03:29:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5581721F87BA for ; Thu, 26 Apr 2012 03:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, SARE_BAYES_6x6=0.4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvR5QzExOEd8 for ; Thu, 26 Apr 2012 03:29:20 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3692C21F8688 for ; Thu, 26 Apr 2012 03:29:19 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 26 Apr 2012 12:29:09 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 12:29:09 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:29:08 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:29:08 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:29:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 11:29:07 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jk+5Q/J36CL0mSZKLy1Jhca5nxQAAQ+pA References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" , "Ulrich Herberg" X-OriginalArrivalTime: 26 Apr 2012 10:29:02.0847 (UTC) FILETIME=[6663E8F0:01CD2397] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--9.299900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry Subject: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:29:21 -0000 Chris, > I'm suggesting a form of listing of what information is to be reported, to > then be coded up each way (whether expressed as ASCII art or an octet > listing isn't critical). It would need to be an example that includes all > the critical features needed (e.g. local information, non-local > information, some, but not all, IP addresses etc.) Agreed. =20 I include a cut'n'paste of my previous mail with my breakdown of draft-02 messages into parts. I have updated the metrics to collapse them into 2 ranges, 'standard' (mandatory) and a space for optional values. I did some ID assignment to try to keep common TLVs with common type-ids. I'm not sure how relevant the actual ID assignment is, but I have tried to keep to 1 top-level TLV-type (DLEP_MESSAGE). My use of extension-types to indicate optional TLVs may not be appropriate, but their use with metrics seems popular. I have described every piece of data from draft-02, but I suggest checking with the draft for actual TLV lengths and meanings. I have also made Version and Status mandatory whenever specified. Rick Taylor KEY: 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type) 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY All address-block-TLVs use a of 6 and the MAC address of the neighbour. Please note the encoding of the extension types, i.e. the extension-id is constant, just the type-id changes (sort of covering the sub-TLV concept) Attached Peer Discovery Message (message-block-TLVs) 0x01 TYPE: Attached_Peer_Discovery + Identification + Version 0x0101 Peer Type 0x0102 Heartbeat Interval 0x0103 Heartbeat Threshold 0x0104 Link Characteristics ACK Timer 0x0180..0x019F (Standard metrics) 0x01A0..0x01FF (Vendor-Extension metrics) Detached Peer Discovery Message (message-block-TLVs) 0x02 TYPE: Detached_Peer_Discovery + Identification + Version 0x0201 Peer Type 0x0202 Heartbeat Interval 0x0203 Heartbeat Threshold 0x0204 Link Characteristics ACK Timer 0x0280..0x029F (Standard metrics) 0x02A0..0x02FF (Vendor-Extension metrics) Peer Offer Message (message-block-TLVs) 0x03 TYPE: Peer_Offer + Identification + Version + Status 0x0301 Peer Type 0x0302 Heartbeat Interval 0x0303 Heartbeat Threshold 0x0304 Link Characteristics ACK Timer 0x0380..0x039F (Standard metrics) 0x03A0..0x03FF (Vendor-Extension metrics) Peer Update Message (message-block-TLVs) 0x04 TYPE: Peer_Update + Identification + Version 0x0401 Peer Type 0x0411 IPv4 Address 0x0412 IPv6 Address 0x0480..0x049F (Standard metrics) 0x04A0..0x04FF (Vendor-Extension metrics) =20 Peer Update ACK Message (message-block-TLVs) 0x05 TYPE: Peer_Update_ACK + Identification + Status Peer Termination Message (message-block-TLVs) 0x06 TYPE: Peer_Termination + Identification + Status Peer Termination ACK Message (message-block-TLVs) 0x07 TYPE: Peer_Termination_ACK + Identification + Status Peer Heartbeat Message (message-block-TLVs) 0x08 TYPE: Peer_Heartbeat + Identification Neighbour Up Message (address-block-TLVs) 0x01 TYPE: Neighbour_Up + Identification 0x0101 Credit Window Status 0x0111 IPv4 Address 0x0112 IPv6 Address 0x0180..0x019F (Standard metrics) 0x01A0..0x01FF (Vendor-Extension metrics) Neighbour Up ACK Message (address-block-TLVs) 0x02 TYPE: Neighbour_Up_ACK + Identification + Status 0x0201 Credit Window Status =20 Neighbour Down Message (address-block-TLVs) 0x03 TYPE: Neighbour_Down + Identification + Status Neighbour Down ACK Message (address-block-TLVs) 0x04 TYPE: Neighbour_Down_ACK + Identification + Status Neighbour Update Message (address-block-TLVs) 0x05 TYPE: Neighbour_Update + Identification 0x0501 Credit Window Status 0x0502 Credit Grant 0x0503 Credit Request 0x0580..0x059F (Standard metrics) 0x05A0..0x05FF (Vendor-Extension metrics) Neighbour Address Update Message (address-block-TLVs) 0x07 TYPE: Neighbour_Address_Update + Identification 0x0711 IPv4 Address 0x0712 IPv6 Address Neighbour Address Update ACK Message (address-block-TLVs) 0x08 TYPE: Neighbour_Address_Update_ACK + Identification + Status Link Characteristics Request Message (address-block-TLVs) 0x09 TYPE: Link_Characteristics_Request + Identification 0x0980..0x099F (Standard metrics) 0x09A0..0x09FF (Vendor-Extension metrics) Link Characteristics ACK Message (address-block-TLVs) 0x0A TYPE: Link_Characteristics_ACK + Identification 0x0A80..0x0A9F (Standard metrics) 0x0AA0..0x0AFF (Vendor-Extension metrics) From henning.rogge@fkie.fraunhofer.de Thu Apr 26 03:29:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D4321F8813 for ; Thu, 26 Apr 2012 03:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=2.049, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 293KQ6OZiK-7 for ; Thu, 26 Apr 2012 03:29:28 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 697ED21F8665 for ; Thu, 26 Apr 2012 03:29:28 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNLx1-0000s6-Py; Thu, 26 Apr 2012 12:29:27 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNLx1-000291-NJ; Thu, 26 Apr 2012 12:29:27 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:29:27 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 12:29:27 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 12:29:26 +0200 Message-ID: <4F992385.20108@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 12:29:25 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030605080007010608020708" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 10:29:27.0399 (UTC) FILETIME=[75063F70:01CD2397] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:29:29 -0000 --------------ms030605080007010608020708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 11:46 AM, Rick Taylor wrote: > Henning, >> You mean that you do not want to use IPs as DLEP messages addresses in= >> Address Blocks, right? > > Correct, I do not want to see them used there. > >> Its still okay to carry them in Address-Block TLVs, to bind them to > the >> corresponding MAC address? > > Yes, as 'normal' TLVs, they can go wherever they are needed as currentl= y > specified in draft-02. The current draft specifies all of them as "subtlvs"... but the=20 definition of normal TLVs (either message or address TLVs) would be=20 quite similar. > As Teco says, layer 3 address TLVs should be optional. Yes. > I agree with Stan that it is really useful to have Layer 3 addressing > delivered via DLEP when the modem knows it, but there are examples wher= e > the modem does not know, but DLEP can still function. I think it will even be the normal case that the modem/radio does not=20 know the layer-3 address. But if its known, DLEP should contain a way to = deliver that information to the router. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms030605080007010608020708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMDI5MjVaMCMGCSqGSIb3DQEJBDEWBBTh0sR73ukaxfEsz+nOTkJ+oQ8YuTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBgHoCtOvtmq3JOd7ooUYMLJ7E+c7Ft6tvlJKFdPiT5BT9o2q1KyDrUMJVOSWf7 EUiGjO3dBSwSEjvOolSF94bnUwXyPqfSgxxC3JOTfYliNMRbY5p0gbwKQS/58fyfd4nr1w6B mv5vyo9MkGhfKKmZWg2kdzPVoFgpSfDGPwd6ZCMsVNE2FMhqckJNM++dKSXJ21bYIIQAClyV YRRd7r6mnBahUxJ37QtQhfDBTJNSwI+vBNZjafHNf9SIyNHNjDXhK+Uclq/7nVYUBPQ2Lk0g OnDudMeEjl0oZgRlLGfznGIGR4sCTIOy94KRR8aOk6cRq4MoozhKhwpX9Srd5ontAAAAAAAA --------------ms030605080007010608020708-- From rick.taylor@cassidian.com Thu Apr 26 03:32:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA21A21F871C for ; Thu, 26 Apr 2012 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yqdPFGitH9n for ; Thu, 26 Apr 2012 03:32:14 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id E676A21F870B for ; Thu, 26 Apr 2012 03:32:13 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 12:32:10 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 12:32:10 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:32:10 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 12:32:10 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 11:32:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 11:32:09 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378CD19@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA Thread-Index: Ac0jly0vyED602pSTT26TJfrx+8p9AAAGBvw References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 26 Apr 2012 10:32:04.0898 (UTC) FILETIME=[D2E6B020:01CD2397] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--3.155500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:32:15 -0000 Henning, > Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay > for this? And should the result contain the structure of the > packet/message, the binary content or both? >=20 I would just outline "Neighbour Address Update", as it will describe clearly how the address TLV's and the MAC address-blocks suggested encodings would work. (Given the addresses are just TLVs, I have yet to see why the two messages can't be collapsed into one...) Rick Taylor From Chris.Dearlove@baesystems.com Thu Apr 26 03:44:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFC21F87D8 for ; Thu, 26 Apr 2012 03:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_6x6=0.4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQndm5v71qiK for ; Thu, 26 Apr 2012 03:44:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 84DFD21F87A3 for ; Thu, 26 Apr 2012 03:44:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="234228783" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 11:44:23 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QAiMgw009366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 11:44:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 11:44:23 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Stan Ratliff , Ulrich Herberg Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: AQHNI5dtQS6Ej0n5skifyF6SVWSSeJas67Kw Date: Thu, 26 Apr 2012 10:44:22 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:44:26 -0000 I'm afraid I'm not going to be able to comment on this immediately, but tha= nks to Rick for this. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com]=20 Sent: 26 April 2012 11:29 To: Dearlove, Christopher (UK); Stan Ratliff; Ulrich Herberg Cc: manet@ietf.org; Bo Berry Subject: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Chris, > I'm suggesting a form of listing of what information is to be reported, to > then be coded up each way (whether expressed as ASCII art or an octet > listing isn't critical). It would need to be an example that includes all > the critical features needed (e.g. local information, non-local > information, some, but not all, IP addresses etc.) Agreed. =20 I include a cut'n'paste of my previous mail with my breakdown of draft-02 messages into parts. I have updated the metrics to collapse them into 2 ranges, 'standard' (mandatory) and a space for optional values. I did some ID assignment to try to keep common TLVs with common type-ids. I'm not sure how relevant the actual ID assignment is, but I have tried to keep to 1 top-level TLV-type (DLEP_MESSAGE). My use of extension-types to indicate optional TLVs may not be appropriate, but their use with metrics seems popular. I have described every piece of data from draft-02, but I suggest checking with the draft for actual TLV lengths and meanings. I have also made Version and Status mandatory whenever specified. Rick Taylor KEY: 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type) 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY All address-block-TLVs use a of 6 and the MAC address of the neighbour. Please note the encoding of the extension types, i.e. the extension-id is constant, just the type-id changes (sort of covering the sub-TLV concept) Attached Peer Discovery Message (message-block-TLVs) 0x01 TYPE: Attached_Peer_Discovery + Identification + Version 0x0101 Peer Type 0x0102 Heartbeat Interval 0x0103 Heartbeat Threshold 0x0104 Link Characteristics ACK Timer 0x0180..0x019F (Standard metrics) 0x01A0..0x01FF (Vendor-Extension metrics) Detached Peer Discovery Message (message-block-TLVs) 0x02 TYPE: Detached_Peer_Discovery + Identification + Version 0x0201 Peer Type 0x0202 Heartbeat Interval 0x0203 Heartbeat Threshold 0x0204 Link Characteristics ACK Timer 0x0280..0x029F (Standard metrics) 0x02A0..0x02FF (Vendor-Extension metrics) Peer Offer Message (message-block-TLVs) 0x03 TYPE: Peer_Offer + Identification + Version + Status 0x0301 Peer Type 0x0302 Heartbeat Interval 0x0303 Heartbeat Threshold 0x0304 Link Characteristics ACK Timer 0x0380..0x039F (Standard metrics) 0x03A0..0x03FF (Vendor-Extension metrics) Peer Update Message (message-block-TLVs) 0x04 TYPE: Peer_Update + Identification + Version 0x0401 Peer Type 0x0411 IPv4 Address 0x0412 IPv6 Address 0x0480..0x049F (Standard metrics) 0x04A0..0x04FF (Vendor-Extension metrics) =20 Peer Update ACK Message (message-block-TLVs) 0x05 TYPE: Peer_Update_ACK + Identification + Status Peer Termination Message (message-block-TLVs) 0x06 TYPE: Peer_Termination + Identification + Status Peer Termination ACK Message (message-block-TLVs) 0x07 TYPE: Peer_Termination_ACK + Identification + Status Peer Heartbeat Message (message-block-TLVs) 0x08 TYPE: Peer_Heartbeat + Identification Neighbour Up Message (address-block-TLVs) 0x01 TYPE: Neighbour_Up + Identification 0x0101 Credit Window Status 0x0111 IPv4 Address 0x0112 IPv6 Address 0x0180..0x019F (Standard metrics) 0x01A0..0x01FF (Vendor-Extension metrics) Neighbour Up ACK Message (address-block-TLVs) 0x02 TYPE: Neighbour_Up_ACK + Identification + Status 0x0201 Credit Window Status =20 Neighbour Down Message (address-block-TLVs) 0x03 TYPE: Neighbour_Down + Identification + Status Neighbour Down ACK Message (address-block-TLVs) 0x04 TYPE: Neighbour_Down_ACK + Identification + Status Neighbour Update Message (address-block-TLVs) 0x05 TYPE: Neighbour_Update + Identification 0x0501 Credit Window Status 0x0502 Credit Grant 0x0503 Credit Request 0x0580..0x059F (Standard metrics) 0x05A0..0x05FF (Vendor-Extension metrics) Neighbour Address Update Message (address-block-TLVs) 0x07 TYPE: Neighbour_Address_Update + Identification 0x0711 IPv4 Address 0x0712 IPv6 Address Neighbour Address Update ACK Message (address-block-TLVs) 0x08 TYPE: Neighbour_Address_Update_ACK + Identification + Status Link Characteristics Request Message (address-block-TLVs) 0x09 TYPE: Link_Characteristics_Request + Identification 0x0980..0x099F (Standard metrics) 0x09A0..0x09FF (Vendor-Extension metrics) Link Characteristics ACK Message (address-block-TLVs) 0x0A TYPE: Link_Characteristics_ACK + Identification 0x0A80..0x0A9F (Standard metrics) 0x0AA0..0x0AFF (Vendor-Extension metrics) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From abdussalambaryun@gmail.com Thu Apr 26 04:26:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2898021F8608 for ; Thu, 26 Apr 2012 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVcrP6nVKuhK for ; Thu, 26 Apr 2012 04:26:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7021F85F9 for ; Thu, 26 Apr 2012 04:26:02 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so926496vcb.31 for ; Thu, 26 Apr 2012 04:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y8W21qqPSOOTmL2I+0S+i7J8SbPZWVeDmgdXrSC6Fj4=; b=IfiJq5+Y/BoDqWyraOSiUrMh2ZkfY77Cf0vRIj0Bg4ve4rh933to4Pl2YWmKZCu1IT 8sJy/VIuVqzM3+Nyp5BxCzriFY1BVFiOpUb+rWzS4SMI643/aP+DZfS5S+WuWM+2sb2N Nh+i54FOA8xma89bgoDnetHwm92wP60qZiRQe8frPjBYkCMyPVZO1jPAGZszLyiY5Eqz 1EFZ9htdNU6MpkBDlmBq9TpFseWDd9B2U9AYKEZpEC+JsFDs+P/XtCNLKPGXIqXqgArn WBMAkRzQloNHtLmZcSnDxh9pQ4/LaqhSfiiMC0gQRDNNhhL7YaFAmsBBsg1YztmroMD1 Z82A== MIME-Version: 1.0 Received: by 10.220.238.211 with SMTP id kt19mr6556728vcb.46.1335439562001; Thu, 26 Apr 2012 04:26:02 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Thu, 26 Apr 2012 04:26:01 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> Date: Thu, 26 Apr 2012 13:26:01 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:26:03 -0000 Hi Stan, I agree that we should not force the 5444 on DLEP as the draft-authors think, so we can solve important and simple problems first. However, I need to be sure of your position on the below views, so I can get progress in reading manet-dlep-02. HR>As I see it, the current draft describes five parts of DLEP. - router-radio Session establishment (and teardown). - transportation of known neighbors from radio to router (optional with known IP. addresses) - transportation of metric data from radio to router. - controlling the link characteristics of the radio by the router. - traffic shaping on the radio with a token scheme by the router. AB> yes, I feel that I understood the same UH>I thought that this idea has already been abandoned and replaced by instead by a proposal to use 6-byte (MAC) address length and address blocks, and to put IPv6 and IPv4 addresses into message TLVs? That seems to be the logical approach, since DLEP is a layer 2 protocol (and updating RFC5444 is difficult). AB> IMO it is easy to update to make 5444 become more welcoming of more scenarios, but difficult to get focused drafts that solve an important-scenario while being depending on specifc standards. that is why we can leave this update after solving small problems first (i.e. making DLEP work in its use-scenarion independently of other standards as much as possible). >I think that any attempt to force MAC addresses into 5444 address blocks f= or >DLEP *only* (at least it's only DLEP at this time) is basically trying = to ram a >square peg into a round hole - with a sufficiently large sledge-h= ammer, "anything is >possible". My concern all along with doing that is tha= t we end up with a one-off, >and I'm strongly opposed to that. IMO, the way= to address it "properly" is >with "RFC 5444 bis"., and I don't see any ene= rgy to do that. AB> IMO we should not mix between the draft ideas and RFC5444 only if necessary to solve the specific-picture-problem, for now I don't see any necessary reason only the attempt to solve the big picture problem. Furthermore, 5444 is for messages for controlling distributed entities of peer to peer routing standards/protocols, not messages for controlling modems by upper-layer entities standards/protocols. Abdussalam Baryun, University of Glamorgan, UK From Chris.Dearlove@baesystems.com Thu Apr 26 04:30:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585DB21F8608 for ; Thu, 26 Apr 2012 04:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqnpQQ9QUn6j for ; Thu, 26 Apr 2012 04:30:06 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A615421F85BB for ; Thu, 26 Apr 2012 04:30:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,485,1330905600"; d="scan'208";a="234251306" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 12:30:05 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QBU4Rt010582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 12:30:04 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 12:30:04 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Stan Ratliff Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94VggAAFlVCAAAPlUIAABumAgAARKGA= Date: Thu, 26 Apr 2012 11:30:04 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:30:07 -0000 Abdussalam Baryun > 5444 is for messages for controlling distributed > entities of peer to peer routing standards/protocols, not messages for > controlling modems by upper-layer entities standards/protocols. 5444 is for anyone who wants to use it. 5498 mandates its use on the manet UDP port or IP protocol, but otherwise it's a take it or leave it thing. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Thu Apr 26 04:40:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190B21F8807 for ; Thu, 26 Apr 2012 04:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PljyqWFCafMA for ; Thu, 26 Apr 2012 04:40:32 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5983D21F8805 for ; Thu, 26 Apr 2012 04:40:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNN3k-0004Pd-Ma; Thu, 26 Apr 2012 13:40:28 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNN3k-00047V-KB; Thu, 26 Apr 2012 13:40:28 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 13:40:28 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 13:40:28 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 13:40:27 +0200 Message-ID: <4F993427.1040801@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 13:40:23 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010103070108040908080703" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 11:40:28.0285 (UTC) FILETIME=[60B5DAD0:01CD23A1] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Cc: "Dearlove, Christopher \(UK\)" , Bo Berry , Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:40:33 -0000 --------------ms010103070108040908080703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 01:26 PM, Abdussalam Baryun wrote: > HR>As I see it, the current draft describes five parts of DLEP. > - router-radio Session establishment (and teardown). > - transportation of known neighbors from radio to router (optional > with known IP. addresses) - transportation of metric data from radio > to router. > - controlling the link characteristics of the radio by the router. > - traffic shaping on the radio with a token scheme by the router. Good. I still think we can do all of this with RFC 5444, and even do it in a=20 less complex manner than the current draft describes without loosing any = functionality or feature. (I am working on an example RFC 5444 Neighbor Update message at the momen= t) Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010103070108040908080703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMTQwMjVaMCMGCSqGSIb3DQEJBDEWBBQEuovwfAEC0HRAZe0H6HExgm6nXzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQA+sz6t5w+2wm+3UgPj9OZSuv/+wvjBlnHrE+fWaiREkji8Pn1ydBvScgLMNEFg 8YaVPL1ZZ6yfz+U0HxyUeoPxpf9dTfloy8i+3GUCbe5qsbcRHCRvoAvZHzQNshVWD78B+bSV ZTSJLjsVMUH3qYUJlcxaN6vWvTSnryy9A2n8zBJvhfqQzzLS5sCh6taqEWrZI5V2WYFoCJ99 eyNsuRZ3qz/8c9lx2HVrjtRcMHNVWYYmyzUWQB3Si8qCHiZ1vZlrkjctrVVlaLJThwcj+wVr rMAyznYwTG8e7D+Rc8Npjz0sYS18xcGMcoYkrD3qKWoEixl/MAR0HV8UUahah0RtAAAAAAAA --------------ms010103070108040908080703-- From teco@inf-net.nl Thu Apr 26 05:16:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947421F8652 for ; Thu, 26 Apr 2012 05:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjDmqZfiYqGa for ; Thu, 26 Apr 2012 05:16:35 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6E5C21F85FC for ; Thu, 26 Apr 2012 05:16:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so759405wgb.13 for ; Thu, 26 Apr 2012 05:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=CY3UXBsKZyG5TkMaOsA/Qy2ryje3ImYmG0tIErSOHmA=; b=jyLxokY6G0uQ2j+cTiy/iMyh9+jBWOBO7RcxTxxyHApOdVcTZJ2UmrWf+Ayn9+4mRA e17CPE0taC/Y2/Ve7pWXHSQmKBZ7O/Gx7fPonrjpQo7QDVBXBtd9Zh7vyvm3fl+Wl6ec aeZYTxU7XQJIMLucJ4bjbIpfbsUGckXW5lHoHCr/2UGqVGkkP//a6agP3Z0JSgjwQNmW TYpK/4vZnRfAdBHnxwmkj7qTYZZ56wDuyzkq/GwvmLu2wuPtPSKyf2kHKi68lwGmbeOn FKvRqvZoXfQFythn7m/x//I8S8B5OTDK5jeUFfsb3PQew7KGfNkVB4lKcxL3v3+aRLsb o/kQ== Received: by 10.180.103.229 with SMTP id fz5mr5212897wib.0.1335442593404; Thu, 26 Apr 2012 05:16:33 -0700 (PDT) Received: from [172.16.4.196] ([188.205.88.52]) by mx.google.com with ESMTPS id o2sm10489391wiv.11.2012.04.26.05.16.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:16:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> Date: Thu, 26 Apr 2012 14:16:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> To: "Rick Taylor" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmtjDILuq/SR+MvRCOfuPZ+QX/CK1qyv4YJzVFdfJlw4XCoIlciw++5KVjGRZZU/7Yu36wt Cc: manet@ietf.org Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:16:35 -0000 Op 26 apr. 2012, om 11:46 heeft Rick Taylor het volgende geschreven: > Henning, > >> Just to make sure I understand you correctly... >> >> You mean that you do not want to use IPs as DLEP messages addresses in >> Address Blocks, right? > > Correct, I do not want to see them used there. > >> Its still okay to carry them in Address-Block TLVs, to bind them to > the >> corresponding MAC address? > > Yes, as 'normal' TLVs, they can go wherever they are needed as currently > specified in draft-02. > > As Teco says, layer 3 address TLVs should be optional. > > I agree with Stan that it is really useful to have Layer 3 addressing > delivered via DLEP when the modem knows it, but there are examples where > the modem does not know, but DLEP can still function. > > (I am using such a modem now, and I just ARP for the Layer 3 addresses, > it's possible, but a PITA, particularly as InARP is largely unsupported > in the real world). The .!!!!-problem is mainly caused by address resolving on non-transit links. On transit links, a good router populates forwarding tables when there is a data path set up. ARP/NDP is enough for this and additional time required for it is minor related to routing protocol convergence in many cases. Teco > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Thu Apr 26 05:45:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC521F8718 for ; Thu, 26 Apr 2012 05:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[AWL=1.940, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4sruJWbD45d for ; Thu, 26 Apr 2012 05:45:34 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3421F871C for ; Thu, 26 Apr 2012 05:45:34 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNO4i-0007bK-Ue; Thu, 26 Apr 2012 14:45:32 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNO4i-0005rW-Ry; Thu, 26 Apr 2012 14:45:32 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 14:45:32 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 14:45:32 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 14:45:31 +0200 Message-ID: <4F99436A.2080600@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 14:45:30 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CD19@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CD19@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050002070309080603090209" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 12:45:32.0514 (UTC) FILETIME=[77CFEC20:01CD23AA] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 194e2da1e6bcf40007c2e4c48fdd6101 Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:45:35 -0000 --------------ms050002070309080603090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 12:32 PM, Rick Taylor wrote: > Henning, > >> Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay= >> for this? And should the result contain the structure of the >> packet/message, the binary content or both? >> > > I would just outline "Neighbour Address Update", as it will describe > clearly how the address TLV's and the MAC address-blocks suggested > encodings would work. > > (Given the addresses are just TLVs, I have yet to see why the two > messages can't be collapsed into one...) > > Rick Taylor I tried to write down an example for a "neighbor update" event in DLEP,=20 with both address, neighbor and metric changes. Please view this message = with a constant width font, otherwise you will not see the structure. Its a neighbor update from radio 01:00:00:00:00:01 about neighbor 1 (02:00:00:00:00:01) and neighbor 2 (02:00:00:00:00:02). Neighbor 1 has the IP address 10.0.0.1, lost the IP address 10.0.0.2 and the current outgoing link speed is 1 mbit/s. Neighbor 2 dropped of the network since the last neighbor update. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "RFC 5444 compatible" logical structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Packet | + Message (type DLEP, 6 byte addresses, | originator 01:00:00:00:00:01, sequence number 1234) + DLEP_ORDER_TLV (ext-type: "neighbor update") | + Address Block (2 addresses, no head/tail/prefix | + Address 1 (mid: 02:00:00:00:00:01) | | | + LINK_STATUS TLV (value "heard") | | | + ADDRESS_TLV (value "10.0.0.1") | | | + ADDRESS_TLV (ext-type: "lost", value "10.0.0.1") | | | + RAW_METRIC_TLV (ext-type: "tx bitrate", value 1000000) | + Address 2 (mid: 02:00:00:00:00:02) | + LINK_STATUS_TLV (value "lost") =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "RFC 5444 compatible" binary structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D packet header: 00 version 0, no sequence number, no TLVs message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 95 address length 6, has originator and sequence number 0044 size of message including header: 68 bytes 010000000001 originator of message: 01:00:00:00:00:01 1234 sequence number 1234 tlv-block: 0003 message TLV block length excluding header =3D 3 tlv: c0 TLV type DLEP_ORDER_TLV (assumption: DLEP_ORDER_TLV =3D 0xc0) 80 has value 77 type extension ORDER_NEIGHBOR_UPDATE (assumption: ORDER_NEIGHBOR_UPDATE =3D 0x77) address-block: 02 2 addresses 00 no special flags, no compression 020000000001 address 1: 02:00:00:00:00:01 020000000002 address 2: 02:00:00:00:00:02 tlv-block: 0023 address TLV block length excluding header =3D 35 tlv: 03 TLV type LINK_STATUS (see RFC 6130) 14 has value, has multivalue 02 TLV length 2 (1 for each value 02 TLV value for address 1: LOST (see RFC 6130) 00 TLV value for address 2: HEARD (see RFC 6130) tlv: c1 TLV type ADDRESS_TLV (assumption: ADDRESS_TLV =3D 0xc1) 50 has single index, has value 01 TLV index 1 04 TLV length 4 10000001 TLV value 10.0.0.1 tlv: c1 TLV type ADDRESS_TLV (assumption: ADDRESS_TLV =3D 0xc1) D0 has extension type, has single index, has value 01 Extension type: LOST (assumption: LOST exttype =3D 0x01) 01 TLV index 1 04 TLV length 4 10000002 TLV value 10.0.0.2 tlv: c2 TLV type RAW_METRIC_TLV D0 has extension type, has single index, has value 01 Extension type: TX_BITRATE (assumption: TX_BITRATE exttype =3D 0x01) 01 TLV index 1 08 TLV length 8 00000000000f4240 TLV value 1000000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D DLEP-draft-02 logical structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The current drafts seems to specifiy that a DLEP message ontains one order (The protocol messages consist of a DLEP order, encoded in the 'tlv-type' field in the message TLV block, with the 'value' field of the TLV block containing a collection (1 or more) DLEP sub-TLVs). The current draft also specifies that the order of SubTLVs has to follow some rules (Identification Sub-TLV must come first). Packet | + Message (type DLEP, 1 byte addresses) | | | + DLEP_NEIGHBOR_UPDATE_TLV | | | + Idenfification Sub-TLV | | | + MAC Address Sub-TLV: 02:00:00:00:00:01 | | | + Current Data Rate Sub-TLV: 1000000 | + Message (type DLEP, 1 byte addresses) | | | + DLEP_NEIGHBOR_UP_TLV | | | + Identification Sub-TLV | | | + MAC Address Sub-TLV: 02:00:00:00:00:01 | | | + IPv4 Address Sub-TLV: existing, 10.0.0.1 | | | + IPv4 Address Sub-TLV: lost, 10.0.0.2 | + Message (type DLEP, 1 byte addresses) | + DLEP_NEIGHBOR_DOWN_TLV | + Identification Sub-TLV | + MAC Address Sub-TLV: 02:00:00:00:00:02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D DLEP-draft-02 binary structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D packet header: 00 version 0, no sequence number, no TLVs message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 002a size of message including header 42 1234 sequence number 1234 tlv-block: 0022 message TLV block length excluding header =3D 34 tlv: c0 TLV type DLEP_NEIGHBOR_UPDATE_TLV (assumption: DLEP_NEIGHBOR_UPDATE_TLV =3D 0xc0) 10 has value 1f TLV length 31 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 subtlv: 03 Subtlv type Current Data Rate (assumption Current Data Rate =3D 0x03) 10 has length 08 Subtlv length 8 00000000000f4240 Value: 1000000 message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 002f size of message including header =3D 47 1235 sequence number 1235 tlv-block: 0027 message TLV block length excluding header =3D 39 tlv: c1 TLV type DLEP_NEIGHBOR_UP_TLV (assumption: DLEP_NEIGHBOR_UP_TLV =3D 0xc1) 10 has value 24 TLV length 36 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 subtlv: 04 Subtlv type IPv4 Address (assumption IPv4 Address =3D 0x04) 10 has length 05 Subtlv length 5 01 Existing(new) address 10000001 10.0.0.1 subtlv: 04 Subtlv type IPv4 Address (assumption IPv4 Address =3D 0x04) 10 has length 05 Subtlv length 5 02 Lost address 10000002 10.0.0.2 message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 001f size of message including header =3D 31 1236 sequence number 1236 tlv-block: 0017 message TLV block length excluding header =3D 23 tlv: c2 TLV type DLEP_NEIGHBOR_DOWN_TLV (assumption: DLEP_NEIGHBOR_UP_TLV =3D 0xc2) 10 has value 14 TLV length 20 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050002070309080603090209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMjQ1MzBaMCMGCSqGSIb3DQEJBDEWBBTP7N4JTjIOtXfN4vnWC14KzNPYoTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAPZhmpV64S0vRZkMEnDHlZKYZemqfcnxsG7L5LVNh5qsbOwu8zCz9yIq3bOhfZ EqAwmA+f5F6Q+AUm8UK0ZwEMK9u4Yp/lSz19+5X1JpatbLEi7pnLjpppdI11U44SbwNsaje1 /t8HPTTYuK4cCdqWjhP8LW/F+SlyfC4MUIzB8VkIOSRu0MvsBGmGqvBy6JUZEsC98fwgD3Yu wFeChAl69YspdIMXFoKqzEpuN7k6kubLbBgkswruK9gRjlateqJQ84H02ZCQUQZKXMh8D/9Q BhTvB6gbfOlX43tkU9SWGVc9IydK1PYb0H6diOylKS+bXfPaWVEDZ5Mg9dAEtsxzAAAAAAAA --------------ms050002070309080603090209-- From boberry@cisco.com Thu Apr 26 05:46:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4221F879A for ; Thu, 26 Apr 2012 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brFE6pBXmsay for ; Thu, 26 Apr 2012 05:46:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAC921F8718 for ; Thu, 26 Apr 2012 05:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=589; q=dns/txt; s=iport; t=1335444404; x=1336654004; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qEQIZ5tgRCW7AF+VaXIkE4I4I05XO5nmOKUBTn64LxI=; b=PXfsce8H6KbXkw+R8wjR6q6HRtfRbymDJ6/Tlkt3w9iyzuOLHkzvmNGX yWWJKJC5k0aknusRx46cnHHpprFt+HMaDvxK1d3BTDNaTtPbd3uKzy8DI hxs26QRKyepQ7X5YcB8FQ1ng0RahPKX0hne3vvRtWVyIH2gnFgCkiL9tN I=; X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78065200" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2012 12:46:43 +0000 Received: from [192.168.1.106] (ggsg-vpn1-230-4.cisco.com [10.81.230.4]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QCkhEw005146; Thu, 26 Apr 2012 12:46:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Thu, 26 Apr 2012 08:46:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E366714-796B-4095-A6D1-86CA5776FC77@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1084) Cc: "manet@ietf.org" , Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:46:45 -0000 On Apr 26, 2012, at 7:30 AM, Dearlove, Christopher (UK) wrote: > Abdussalam Baryun >> 5444 is for messages for controlling distributed >> entities of peer to peer routing standards/protocols, not messages = for >> controlling modems by upper-layer entities standards/protocols. >=20 > 5444 is for anyone who wants to use it. 5498 mandates its use on the = manet UDP port or IP protocol, but otherwise it's a take it or leave it = thing. >=20 and I believe that applies to the method and adoption of the various = concepts defined by RFC 5444. From henning.rogge@fkie.fraunhofer.de Thu Apr 26 05:53:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324BC21F883F for ; Thu, 26 Apr 2012 05:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.363 X-Spam-Level: X-Spam-Status: No, score=-4.363 tagged_above=-999 required=5 tests=[AWL=1.886, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-JC1RxIGUGa for ; Thu, 26 Apr 2012 05:53:00 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id D118921F8798 for ; Thu, 26 Apr 2012 05:52:59 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNOBv-0007yS-75 for manet@ietf.org; Thu, 26 Apr 2012 14:52:59 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNOBv-00061Z-4R for manet@ietf.org; Thu, 26 Apr 2012 14:52:59 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 14:52:58 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 14:52:58 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 14:52:57 +0200 Message-ID: <4F994529.3030609@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 14:52:57 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CD19@SUKNPT8106.cogent-dsn.local> <4F99436A.2080600@fkie.fraunhofer.de> In-Reply-To: <4F99436A.2080600@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020408020509040207070909" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 12:52:58.0798 (UTC) FILETIME=[81D174E0:01CD23AB] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: bf69435e4c39fd5f7be368e1d93e5423 Subject: Re: [manet] DLEP and modemLPA (fixed small bug in binary description) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:53:03 -0000 --------------ms020408020509040207070909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sorry, found a bug in the description seconds after I sent it to the list (and=20 after reading through it three times!). I tried to write down an example for a "neighbor update" event in DLEP,=20 with both address, neighbor and metric changes. Please view this message = with a constant width font, otherwise you will not see the structure. Its a neighbor update from radio 01:00:00:00:00:01 about neighbor 1 (02:00:00:00:00:01) and neighbor 2 (02:00:00:00:00:02). Neighbor 1 has the IP address 10.0.0.1, lost the IP address 10.0.0.2 and the current outgoing link speed is 1 mbit/s. Neighbor 2 dropped of the network since the last neighbor update. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "RFC 5444 compatible" logical structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Packet | + Message (type DLEP, 6 byte addresses, | originator 01:00:00:00:00:01, sequence number 1234) + DLEP_ORDER_TLV (ext-type: "neighbor update") | + Address Block (2 addresses, no head/tail/prefix | + Address 1 (mid: 02:00:00:00:00:01) | | | + LINK_STATUS TLV (value "heard") | | | + ADDRESS_TLV (value "10.0.0.1") | | | + ADDRESS_TLV (ext-type: "lost", value "10.0.0.2") | | | + RAW_METRIC_TLV (ext-type: "tx bitrate", value 1000000) | + Address 2 (mid: 02:00:00:00:00:02) | + LINK_STATUS_TLV (value "lost") =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "RFC 5444 compatible" binary structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D packet header: 00 version 0, no sequence number, no TLVs message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 95 address length 6, has originator and sequence number 0044 size of message including header: 68 bytes 010000000001 originator of message: 01:00:00:00:00:01 1234 sequence number 1234 tlv-block: 0003 message TLV block length excluding header =3D 3 tlv: c0 TLV type DLEP_ORDER_TLV (assumption: DLEP_ORDER_TLV =3D 0xc0) 80 has value 77 type extension ORDER_NEIGHBOR_UPDATE (assumption: ORDER_NEIGHBOR_UPDATE =3D 0x77) address-block: 02 2 addresses 00 no special flags, no compression 020000000001 address 1: 02:00:00:00:00:01 020000000002 address 2: 02:00:00:00:00:02 tlv-block: 0023 address TLV block length excluding header =3D 35 tlv: 03 TLV type LINK_STATUS (see RFC 6130) 14 has value, has multivalue 02 TLV length 2 (1 for each value) 02 TLV value for address 1: HEARD (see RFC 6130) 00 TLV value for address 2: LOST (see RFC 6130) tlv: c1 TLV type ADDRESS_TLV (assumption: ADDRESS_TLV =3D 0xc1) 50 has single index, has value 01 TLV index 1 04 TLV length 4 10000001 TLV value 10.0.0.1 tlv: c1 TLV type ADDRESS_TLV (assumption: ADDRESS_TLV =3D 0xc1) D0 has extension type, has single index, has value 01 Extension type: LOST (assumption: LOST exttype =3D 0x01) 01 TLV index 1 04 TLV length 4 10000002 TLV value 10.0.0.2 tlv: c2 TLV type RAW_METRIC_TLV D0 has extension type, has single index, has value 01 Extension type: TX_BITRATE (assumption: TX_BITRATE exttype =3D 0x01) 01 TLV index 1 08 TLV length 8 00000000000f4240 TLV value 1000000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D DLEP-draft-02 logical structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The current drafts seems to specifiy that a DLEP message ontains one order (The protocol messages consist of a DLEP order, encoded in the 'tlv-type' field in the message TLV block, with the 'value' field of the TLV block containing a collection (1 or more) DLEP sub-TLVs). The current draft also specifies that the order of SubTLVs has to follow some rules (Identification Sub-TLV must come first). Packet | + Message (type DLEP, 1 byte addresses) | | | + DLEP_NEIGHBOR_UPDATE_TLV | | | + Idenfification Sub-TLV | | | + MAC Address Sub-TLV: 02:00:00:00:00:01 | | | + Current Data Rate Sub-TLV: 1000000 | + Message (type DLEP, 1 byte addresses) | | | + DLEP_NEIGHBOR_UP_TLV | | | + Identification Sub-TLV | | | + MAC Address Sub-TLV: 02:00:00:00:00:01 | | | + IPv4 Address Sub-TLV: existing, 10.0.0.1 | | | + IPv4 Address Sub-TLV: lost, 10.0.0.2 | + Message (type DLEP, 1 byte addresses) | + DLEP_NEIGHBOR_DOWN_TLV | + Identification Sub-TLV | + MAC Address Sub-TLV: 02:00:00:00:00:02 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D DLEP-draft-02 binary structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D packet header: 00 version 0, no sequence number, no TLVs message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 002a size of message including header 42 1234 sequence number 1234 tlv-block: 0022 message TLV block length excluding header =3D 34 tlv: c0 TLV type DLEP_NEIGHBOR_UPDATE_TLV (assumption: DLEP_NEIGHBOR_UPDATE_TLV =3D 0xc0) 10 has value 1f TLV length 31 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 subtlv: 03 Subtlv type Current Data Rate (assumption Current Data Rate =3D 0x03) 10 has length 08 Subtlv length 8 00000000000f4240 Value: 1000000 message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 002f size of message including header =3D 47 1235 sequence number 1235 tlv-block: 0027 message TLV block length excluding header =3D 39 tlv: c1 TLV type DLEP_NEIGHBOR_UP_TLV (assumption: DLEP_NEIGHBOR_UP_TLV =3D 0xc1) 10 has value 24 TLV length 36 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 subtlv: 04 Subtlv type IPv4 Address (assumption IPv4 Address =3D 0x04) 10 has length 05 Subtlv length 5 01 Existing(new) address 10000001 10.0.0.1 subtlv: 04 Subtlv type IPv4 Address (assumption IPv4 Address =3D 0x04) 10 has length 05 Subtlv length 5 02 Lost address 10000002 10.0.0.2 message header: 66 message type DLEP (assumption: DLEP-message type =3D 0x66) 10 address length 0+1=3D1, has sequence number 001f size of message including header =3D 31 1236 sequence number 1236 tlv-block: 0017 message TLV block length excluding header =3D 23 tlv: c2 TLV type DLEP_NEIGHBOR_DOWN_TLV (assumption: DLEP_NEIGHBOR_UP_TLV =3D 0xc2) 10 has value 14 TLV length 20 sub-tlv: 01 Subtlv type Identification (assumption Identification =3D 0x01) 10 has length 08 Subtlv length 8 xxxxxxxx Server ID xxxxxxxx yyyyyyyy Client ID yyyyyyyy subtlv: 02 Subtlv type Mac Address (assumption Mac Address =3D 0x02) 10 has length 06 Subtlv length 6 020000000001 Value: 02:00:00:00:00:01 --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020408020509040207070909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMjUyNTdaMCMGCSqGSIb3DQEJBDEWBBR2UwPnveN+J7fEVbDrq2UwnHkt2jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCkbrGD7WThfKVuLS1SRbZ5HbjUYaOtL/xxYcyTz5SBu84yzbCpG3lnknvAFZkz 5KQgGYFxHD9US/2cQzfN+4BIqSWITcd4Ocd3nIpWDy01EjAeZFGuoDhTX4urTjDOWaENbDzE gmbloZ9NmPQA0VVQFxbyCwnxGq7DepXWExqv8B2iGuGZOXDUStHWbKwmfImIhyk9a7iiFVjl hkUDWjY5YAvFT0nQfugaKjEqLJIeu+Pb+8I9Zup/Dlz72sYcQl8u69Xkj63OuUjOYjreea9d NLomzihnmH2OJnM8sYuhiHuk+x12IZqqm+5UXZk4IjFsVtX+uu8p9oOL93lJKNREAAAAAAAA --------------ms020408020509040207070909-- From abdussalambaryun@gmail.com Thu Apr 26 06:14:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CABE21F86F3 for ; Thu, 26 Apr 2012 06:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTdE5mL1Hdsq for ; Thu, 26 Apr 2012 06:14:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4592021F86F1 for ; Thu, 26 Apr 2012 06:14:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1033360vbb.31 for ; Thu, 26 Apr 2012 06:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=03ZZRr42DczYWUiWE3udcGsT3hoQ2nhQdS62OtHux64=; b=X5RY+3X6JUTyYn1kVFlhboeJJ0SBzway2S8ufAwS3kfVP9qN07scWTUgFGwK0oMKzE mwYXXkBZhlXgnhwjf8FwF+ErnRuGFekNJyKUHNdpXoQBBtSnndist8AEBzQ4YlHSlvIj 3qfltSTtwBBxApAqgxJWHp1e+4208GG4cUxroc5ugF3c4+eREDfzOzA2FWwpehyNNG6K F9SyTCpaNilAbupWlhO+nhsGmQqyKk/mLGTUiborF7X2kkfRQ6dZ5hR6o6NHWHf04fhW ZMqrbNdN+viHc8r4ma2SlhaGwkxlOyBWuNkzYko70OYP5U3WMqH38/4ugPJ919PSpXmc 9gWA== MIME-Version: 1.0 Received: by 10.52.68.77 with SMTP id u13mr5966326vdt.81.1335446079744; Thu, 26 Apr 2012 06:14:39 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Thu, 26 Apr 2012 06:14:39 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> Date: Thu, 26 Apr 2012 15:14:39 +0200 Message-ID: From: Abdussalam Baryun To: Chris.Dearlove@baesystems.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:14:41 -0000 Hi Chris, I thank you for your suggestions, I am new in the manet discussion not sure about the rules. I am just trying to understand by adding the below comments >5444 is for anyone who wants to use it. 5498 mandates its use on the manet UDP >port or IP protocol, but otherwise it's a take it or leave it thing. AB> I agree with the above only if the DLEP protocol is a P2P communication protocol, but it is not exactly, it discovers peer-neighbor-modems. From my reading the DLEP does not exchange messages within UDP/IP stack, DLEP has its separate message exchange-channel between entities-endpoints, and it may need a separate UDP/IP port than 5498. I am not sure of this last two lines :( 5444>page 3>This document specifies the syntax of a packet format designed for >carrying multiple routing protocol messages for information exchange >between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >Message Header, which is designed for control of message >dissemination, and a Message Body, which contains protocol >information. AB> therefore, RFC5444 is specified to messages-format for exchange between routers. Therefore, if DLEP-neighbors are routers and they want to exchange messages, then they must use 5444 format. AB> IMO from the authors' discussions, using 5444 is a way to help in future work. However, the draft may leave it by not mentioning the 5444 format and still use it as DLEP message-format (e.g. used DLEP-message-format in section 11), because in some formats it deals with DLEP-server, and DLEP-client IDs, but it is not as 5444 dealing with router-neighbour-peers' IDs. CD>To be clear, the suggestion (which I think I would say has "consensus >among those people who think the format should be changed, but not >consensus among all including the DLEP authors") is roughly - That information which is local, and not associated with an address is put in the message TLV block. - That information which is not local is associated with a MAC address. The MAC addresses are put in the address blocks, and other information associated with them is put in the following TLV block. - One such piece of information is an IPv4 or IPv6 address, which uses a TLV, not an address block. Other information includes metrics etc. - Metrics use one, or a small number, of TLV types, and the metric type uses the TLV type extension. HR>I think thats a correct and good description of the current suggestion. >Would a "Neighbor Address Update" or "Neighbor Update" DLEP order okay for >this? And should the result contain the structure of the packet/message, the >binary content or both? AB> I agree with your both points as long as it does not affect the DLEP functions (not sure!). we need comments from draft's authors. Abdussalam Baryun University of Glamorgan, UK From sratliff@cisco.com Thu Apr 26 06:42:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA19521F8813 for ; Thu, 26 Apr 2012 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgSo2dApwffV for ; Thu, 26 Apr 2012 06:42:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C67D021F865D for ; Thu, 26 Apr 2012 06:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=5168; q=dns/txt; s=iport; t=1335447754; x=1336657354; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=IeGA6m9F7XQi8vd/9+puJoBEvglV1sJHo57h6HvfzT8=; b=aPkKw6KnjUPASQamKaXbARVlznsbYSn+kjUAKJ/7Yam0/R00Eox/S3zd HJbvDqhs/FQbBu6UsoIM4VRdh2kv0nvZxBMZ2NowXm0/FCzUXv2A9ch2j 19pbpbYJklX3FBLdjvyblY5xw12fK6s0MtyiXPLKn56xAoTtQXwBbZrOc M=; X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78083432" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2012 13:42:34 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3QDgXrX001010; Thu, 26 Apr 2012 13:42:34 GMT Message-Id: <711C7D9D-D116-461F-B6A8-F7AD83D479C4@cisco.com> From: Stan Ratliff To: Rick Taylor In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 09:42:34 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:42:36 -0000 Rick, This shows one of the problems I'm having with "restructuring". Looks to me that "Credit WIndow Status" has at least 3 definitions: 0x0101 Credit Window Status > 0x0201 Credit Window Status > 0x0501 Credit Window Status This is easier? Regards, Stan On Apr 26, 2012, at 6:29 AM, Rick Taylor wrote: > Chris, > >> I'm suggesting a form of listing of what information is to be > reported, to >> then be coded up each way (whether expressed as ASCII art or an octet >> listing isn't critical). It would need to be an example that includes > all >> the critical features needed (e.g. local information, non-local >> information, some, but not all, IP addresses etc.) > > Agreed. > > I include a cut'n'paste of my previous mail with my breakdown of > draft-02 messages into parts. I have updated the metrics to collapse > them into 2 ranges, 'standard' (mandatory) and a space for optional > values. > > I did some ID assignment to try to keep common TLVs with common > type-ids. I'm not sure how relevant the actual ID assignment is, but I > have tried to keep to 1 top-level TLV-type (DLEP_MESSAGE). My use of > extension-types to indicate optional TLVs may not be appropriate, but > their use with metrics seems popular. > > I have described every piece of data from draft-02, but I suggest > checking with the draft for actual TLV lengths and meanings. > > I have also made Version and Status mandatory whenever specified. > > Rick Taylor > > KEY: > 0xXX - TLV type 0xXX+128, no extension (DLEP_MESSAGE specific type) > 0xXXYY - Optional TLV type 0xXX+128, extension 0xYY > > All address-block-TLVs use a of 6 and the MAC address of > the neighbour. > > Please note the encoding of the extension types, i.e. the extension-id > is constant, just the type-id changes (sort of covering the sub-TLV > concept) > > Attached Peer Discovery Message (message-block-TLVs) > 0x01 TYPE: Attached_Peer_Discovery + Identification + Version > 0x0101 Peer Type > 0x0102 Heartbeat Interval > 0x0103 Heartbeat Threshold > 0x0104 Link Characteristics ACK Timer > 0x0180..0x019F (Standard metrics) > 0x01A0..0x01FF (Vendor-Extension metrics) > > Detached Peer Discovery Message (message-block-TLVs) > 0x02 TYPE: Detached_Peer_Discovery + Identification + Version > 0x0201 Peer Type > 0x0202 Heartbeat Interval > 0x0203 Heartbeat Threshold > 0x0204 Link Characteristics ACK Timer > 0x0280..0x029F (Standard metrics) > 0x02A0..0x02FF (Vendor-Extension metrics) > > Peer Offer Message (message-block-TLVs) > 0x03 TYPE: Peer_Offer + Identification + Version + Status > 0x0301 Peer Type > 0x0302 Heartbeat Interval > 0x0303 Heartbeat Threshold > 0x0304 Link Characteristics ACK Timer > 0x0380..0x039F (Standard metrics) > 0x03A0..0x03FF (Vendor-Extension metrics) > > Peer Update Message (message-block-TLVs) > 0x04 TYPE: Peer_Update + Identification + Version > 0x0401 Peer Type > 0x0411 IPv4 Address > 0x0412 IPv6 Address > 0x0480..0x049F (Standard metrics) > 0x04A0..0x04FF (Vendor-Extension metrics) > > Peer Update ACK Message (message-block-TLVs) > 0x05 TYPE: Peer_Update_ACK + Identification + Status > > Peer Termination Message (message-block-TLVs) > 0x06 TYPE: Peer_Termination + Identification + Status > > Peer Termination ACK Message (message-block-TLVs) > 0x07 TYPE: Peer_Termination_ACK + Identification + Status > > Peer Heartbeat Message (message-block-TLVs) > 0x08 TYPE: Peer_Heartbeat + Identification > > Neighbour Up Message (address-block-TLVs) > 0x01 TYPE: Neighbour_Up + Identification > 0x0101 Credit Window Status > 0x0111 IPv4 Address > 0x0112 IPv6 Address > 0x0180..0x019F (Standard metrics) > 0x01A0..0x01FF (Vendor-Extension metrics) > > Neighbour Up ACK Message (address-block-TLVs) > 0x02 TYPE: Neighbour_Up_ACK + Identification + Status > 0x0201 Credit Window Status > > Neighbour Down Message (address-block-TLVs) > 0x03 TYPE: Neighbour_Down + Identification + Status > > Neighbour Down ACK Message (address-block-TLVs) > 0x04 TYPE: Neighbour_Down_ACK + Identification + Status > > Neighbour Update Message (address-block-TLVs) > 0x05 TYPE: Neighbour_Update + Identification > 0x0501 Credit Window Status > 0x0502 Credit Grant > 0x0503 Credit Request > 0x0580..0x059F (Standard metrics) > 0x05A0..0x05FF (Vendor-Extension metrics) > > Neighbour Address Update Message (address-block-TLVs) > 0x07 TYPE: Neighbour_Address_Update + Identification > 0x0711 IPv4 Address > 0x0712 IPv6 Address > > Neighbour Address Update ACK Message (address-block-TLVs) > 0x08 TYPE: Neighbour_Address_Update_ACK + Identification + Status > > Link Characteristics Request Message (address-block-TLVs) > 0x09 TYPE: Link_Characteristics_Request + Identification > 0x0980..0x099F (Standard metrics) > 0x09A0..0x09FF (Vendor-Extension metrics) > > Link Characteristics ACK Message (address-block-TLVs) > 0x0A TYPE: Link_Characteristics_ACK + Identification > 0x0A80..0x0A9F (Standard metrics) > 0x0AA0..0x0AFF (Vendor-Extension metrics) > > From Chris.Dearlove@baesystems.com Thu Apr 26 06:43:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0590F21F8838 for ; Thu, 26 Apr 2012 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nrkxUlnaeZN for ; Thu, 26 Apr 2012 06:43:16 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 02ECF21F8822 for ; Thu, 26 Apr 2012 06:43:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="234309429" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 14:43:15 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QDhExK012933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 14:43:14 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 14:43:14 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry Thread-Topic: [manet] DLEP and modemLPA Thread-Index: AQHNIvZ/SxLA12bEhU2HylJVFk057JarsmaAgAAGeACAABtvAIAAAziAgAAFYQCAAAM5AIAA94VggAAFlVCAAAPlUIAABumAgAARKGCAAAViAIAAIC7A Date: Thu, 26 Apr 2012 13:43:13 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <6E366714-796B-4095-A6D1-86CA5776FC77@cisco.com> In-Reply-To: <6E366714-796B-4095-A6D1-86CA5776FC77@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Stan Ratliff , Abdussalam Baryun Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:43:17 -0000 Not quite sure what you mean by that, and therefore don't know whether I ag= ree or disagree with you. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Bo Berry [mailto:boberry@cisco.com]=20 Sent: 26 April 2012 13:47 To: Dearlove, Christopher (UK) Cc: Abdussalam Baryun; Stan Ratliff; henning.rogge@fkie.fraunhofer.de; Rick= Taylor; Ulrich Herberg; manet@ietf.org Subject: Re: [manet] DLEP and modemLPA ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 26, 2012, at 7:30 AM, Dearlove, Christopher (UK) wrote: > Abdussalam Baryun >> 5444 is for messages for controlling distributed >> entities of peer to peer routing standards/protocols, not messages for >> controlling modems by upper-layer entities standards/protocols. >=20 > 5444 is for anyone who wants to use it. 5498 mandates its use on the mane= t UDP port or IP protocol, but otherwise it's a take it or leave it thing. >=20 and I believe that applies to the method and adoption of the various concep= ts defined by RFC 5444. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From sratliff@cisco.com Thu Apr 26 06:47:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533821F86F1 for ; Thu, 26 Apr 2012 06:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPJ1nKGi+tPM for ; Thu, 26 Apr 2012 06:47:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0B93921F86CE for ; Thu, 26 Apr 2012 06:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2677; q=dns/txt; s=iport; t=1335448067; x=1336657667; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=W78UEeKm7FpGJhDsSISv+qeSdkVJRmutOWovO/lpr5E=; b=KAfsB3zaaa9178aQWzigOYwvGDW4VLTaYXlmHXSNnn8kEjxqsxWn1cPx Iy3VwQ9ba5JuJWIvItz9illQAVhma9l5T8d9IXZBXLd/XC0KmnpE+v8dO CoLALtrv6n5MViPWW2n2QPGioRC3N0w1jAEoPxaw9syc89dBKaJqbFXrn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMJQmU+tJV2b/2dsb2JhbABEsUuBB4IJAQEBAwEBAQEPASU2CwULCxgnBycfEQYTIodmBQuaXKA1kAJjBJV9jleBaYME X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78085005" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2012 13:47:46 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QDlkT9000401; Thu, 26 Apr 2012 13:47:46 GMT Message-Id: <44B88B79-EF3D-4343-82C1-1056FD66513C@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: <4F992385.20108@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 09:47:46 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> <4F992385.20108@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:47:47 -0000 On Apr 26, 2012, at 6:29 AM, Henning Rogge wrote: > On 04/26/2012 11:46 AM, Rick Taylor wrote: >> Henning, >>> You mean that you do not want to use IPs as DLEP messages =20 >>> addresses in >>> Address Blocks, right? >> >> Correct, I do not want to see them used there. >> >>> Its still okay to carry them in Address-Block TLVs, to bind them to >> the >>> corresponding MAC address? >> >> Yes, as 'normal' TLVs, they can go wherever they are needed as =20 >> currently >> specified in draft-02. > > The current draft specifies all of them as "subtlvs"... but the =20 > definition of normal TLVs (either message or address TLVs) would be =20= > quite similar. > >> As Teco says, layer 3 address TLVs should be optional. > > Yes. > >> I agree with Stan that it is really useful to have Layer 3 addressing >> delivered via DLEP when the modem knows it, but there are examples =20= >> where >> the modem does not know, but DLEP can still function. > > I think it will even be the normal case that the modem/radio does =20 > not know the layer-3 address. But if its known, DLEP should contain =20= > a way to deliver that information to the router. > And that's precisely why the address TLV's are part of "Peer Offer" - =20= what we envisioned goes something like: 1. Modem sends Peer Discovery 2. Router responds with Peer Offer, *with* its (the router's) addresses. 3. Modem could strip out those TLV's, and treat them as opaque data - =20= no cognizance of what they are, just knowledge that "when I get TLV =20 blah, I need to save that info". 4. As part of radio synchronization, two radios exchange their opaque =20= data. 5. A radio receiving such opaque data inserts it into a Neighbor =20 Up..... and now you have end-to-end Layer 3 knowledge, without the =20 radio needing to know very much at all. 6. If addresses change on the router (via configuration), the router =20 sends Peer Update to its radio, when then re-transmits the opaque data =20= to radio peers. That opaque data is inserted into Neighbor Update. Regards, Stan > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Apr 26 06:51:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4F021F85D3 for ; Thu, 26 Apr 2012 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-JH2SKX2lu9 for ; Thu, 26 Apr 2012 06:51:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BEEEE21F85B9 for ; Thu, 26 Apr 2012 06:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1870; q=dns/txt; s=iport; t=1335448269; x=1336657869; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pK4CQIJYQUtzst334T5EZy7/yZxz6jImyRMHm28IPfc=; b=TeVXNDockt9XUFtOf4TCOFWjcpLiAO/TIlrSCRT/HojEOBScPIQaGIme TgxaV99NW1zPbEd167MW8TVsZKBpR3eL1GzN7bGQ++pswkxJTaGCI4xxX 1705pU8+IJbzO+YSICh6bywsBj2tj/lvpoceQcE1v44B3DfhYtJBuJpOL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACpSmU+tJXG9/2dsb2JhbABEsUuBB4IJAQEBAwEBAQEPASUCNAsFCwtGJzAGEyKHZgULml+gMQSQAmMElX2OV4FpgwQ X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="75063852" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 26 Apr 2012 13:51:09 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3QDp8TA030918; Thu, 26 Apr 2012 13:51:09 GMT Message-Id: <6D11E177-199F-4FE1-ABE6-30A313FEF2E7@cisco.com> From: Stan Ratliff To: Teco Boot In-Reply-To: <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 09:51:09 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:51:11 -0000 On Apr 26, 2012, at 8:16 AM, Teco Boot wrote: > > Op 26 apr. 2012, om 11:46 heeft Rick Taylor het volgende geschreven: > >> Henning, >> >>> Just to make sure I understand you correctly... >>> >>> You mean that you do not want to use IPs as DLEP messages >>> addresses in >>> Address Blocks, right? >> >> Correct, I do not want to see them used there. >> >>> Its still okay to carry them in Address-Block TLVs, to bind them to >> the >>> corresponding MAC address? >> >> Yes, as 'normal' TLVs, they can go wherever they are needed as >> currently >> specified in draft-02. >> >> As Teco says, layer 3 address TLVs should be optional. >> >> I agree with Stan that it is really useful to have Layer 3 addressing >> delivered via DLEP when the modem knows it, but there are examples >> where >> the modem does not know, but DLEP can still function. >> >> (I am using such a modem now, and I just ARP for the Layer 3 >> addresses, >> it's possible, but a PITA, particularly as InARP is largely >> unsupported >> in the real world). > > The .!!!!-problem is mainly caused by address resolving on non- > transit links. > On transit links, a good router populates forwarding tables when > there is > a data path set up. ARP/NDP is enough for this and additional time > required > for it is minor related to routing protocol convergence in many cases. > Except that you inherently force a MANET into a single subnet in order for that to work. That's not the case in the networks I deploy. Stan > Teco > >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Thu Apr 26 06:55:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCE821E801F for ; Thu, 26 Apr 2012 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.414 X-Spam-Level: X-Spam-Status: No, score=-4.414 tagged_above=-999 required=5 tests=[AWL=1.835, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBfDnIXBZ8Zd for ; Thu, 26 Apr 2012 06:55:43 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7321F85FD for ; Thu, 26 Apr 2012 06:55:43 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNPAc-0002eb-Kp for manet@ietf.org; Thu, 26 Apr 2012 15:55:42 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNPAc-0007o4-IE for manet@ietf.org; Thu, 26 Apr 2012 15:55:42 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 15:55:42 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 15:55:42 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 15:55:41 +0200 Message-ID: <4F9953DC.1010407@fkie.fraunhofer.de> Date: Thu, 26 Apr 2012 15:55:40 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <711C7D9D-D116-461F-B6A8-F7AD83D479C4@cisco.com> In-Reply-To: <711C7D9D-D116-461F-B6A8-F7AD83D479C4@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060100030204010709080109" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 26 Apr 2012 13:55:42.0212 (UTC) FILETIME=[44FCDC40:01CD23B4] X-Virus-Scanned: yes (ClamAV 0.97.3/14847/Thu Apr 26 04:33:01 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 90edfc314e3c23e7293fd49106c104bf Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:55:44 -0000 --------------ms060100030204010709080109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/26/2012 03:42 PM, Stan Ratliff wrote: > Rick, > > This shows one of the problems I'm having with "restructuring". Looks t= o > me that "Credit WIndow Status" has at least 3 definitions: > 0x0101 Credit Window Status >> 0x0201 Credit Window Status > >> 0x0501 Credit Window Status > > > This is easier? No, it is not. And it is also not necessary, neither for subtlvs nor for real ones. One = TLV-type (some of them with extension) for each type of data should be=20 enough. > And that's precisely why the address TLV's are part of "Peer Offer" - > what we envisioned goes something like: > 1. Modem sends Peer Discovery > 2. Router responds with Peer Offer, *with* its (the router's) > addresses. > 3. Modem could strip out those TLV's, and treat them as opaque data - > no cognizance of what they are, just knowledge that "when I get TLV > blah, I need to save that info". > 4. As part of radio synchronization, two radios exchange their opaque > data. > 5. A radio receiving such opaque data inserts it into a Neighbor > Up..... and now you have end-to-end Layer 3 knowledge, without the > radio needing to know very much at all. > 6. If addresses change on the router (via configuration), the router > sends Peer Update to its radio, when then re-transmits the opaque > data to radio peers. That opaque data is inserted into Neighbor > Update. Okay, that is something that wasn't clear to me from your draft. I would disagree that this information is totally opaque for the Modem,=20 because it has to know which TLV it has to parse/synchronize. But=20 putting address fields into the "Peer Offer" message is an interesting id= ea. Thats why I am 'drilling' a lot for this 'why is the usecase behind X'=20 things. Because without knowing this details, a lot protocol design=20 decisions seem to be pointless. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060100030204010709080109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjYxMzU1NDBaMCMGCSqGSIb3DQEJBDEWBBSKd3zEXqYorqiHEpuekc4HPfHn9DBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCBYQsjeWmouC4d7zbVYTbODsgFLI1Emem7+oC13WLMwg80J5A9/Cf5lLnrk5GE QxYYchDwi99Vy6TXN8r4LEz1j5YMvrjFRtYAffdTHEIcFmf+bONWXqf5Q8CFmpwZOpt57lmo RP2Sc0DB3nkz+0AyZhjcMahKj8nx3/g6wTygGxiLSSwU78/8Hlqvz1I0l/QB/4T36EXhBTr5 yzFQYP6SKQ9PoUF2ECb+/7kZT08AstBhbEMUIcpV2V1piN3o7wPC/7OxJcB5FbZH9823pNK7 LqnsVU2s0lP1E3FF+XOVmXRkFXjMLT5Wb1QoBHNapQ+dcblXeWunPWt1ush9rBokAAAAAAAA --------------ms060100030204010709080109-- From sratliff@cisco.com Thu Apr 26 07:02:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FB621F8594 for ; Thu, 26 Apr 2012 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTkyb44S004o for ; Thu, 26 Apr 2012 07:02:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 221E721F8425 for ; Thu, 26 Apr 2012 07:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3649; q=dns/txt; s=iport; t=1335448945; x=1336658545; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=f9jYISlSsGNMZAZtzabbLDTML9WtAzF8m5m81HlsXGI=; b=lbci0AYjJPK/15f7f9oO+HRbf4PCuhVhv4DKgsFRMv1f2BBANsRyNGUa T7mRfem93e6u0g5t3c+wRhrqU5eXJuYC0R8kJ4ZdWkcvA+t6Aj+vzy2rs DkHkPXNXxxpSQ2C2VoIpYcqncAFGAFerZ6jD+kZ8CA6/nHV8WEBgx/jIg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPBTmU+tJXHA/2dsb2JhbABEsUuBB4IJAQEBAwEBAQEPASU2AwgFCwsYJwcnHxEGCgkih2YFC5pmoDiQAmMElX2OV4FpgwQ X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78100426" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 26 Apr 2012 14:02:24 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3QE2NgS011628; Thu, 26 Apr 2012 14:02:23 GMT Message-Id: <5A828886-2CBB-441B-9E39-F6E81C040A11@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: <4F9953DC.1010407@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 10:02:23 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <711C7D9D-D116-461F-B6A8-F7AD83D479C4@cisco.com> <4F9953DC.1010407@fkie.fraunhofer.de> X-Mailer: Apple Mail (2.936) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:02:26 -0000 On Apr 26, 2012, at 9:55 AM, Henning Rogge wrote: > On 04/26/2012 03:42 PM, Stan Ratliff wrote: >> Rick, >> >> This shows one of the problems I'm having with "restructuring". =20 >> Looks to >> me that "Credit WIndow Status" has at least 3 definitions: >> 0x0101 Credit Window Status >>> 0x0201 Credit Window Status >> >>> 0x0501 Credit Window Status >> >> >> This is easier? > > No, it is not. > > And it is also not necessary, neither for subtlvs nor for real ones. =20= > One TLV-type (some of them with extension) for each type of data =20 > should be enough. > > > And that's precisely why the address TLV's are part of "Peer =20 > Offer" - > > what we envisioned goes something like: > > 1. Modem sends Peer Discovery > > 2. Router responds with Peer Offer, *with* its (the router's) > > addresses. > > 3. Modem could strip out those TLV's, and treat them as opaque =20 > data - > > no cognizance of what they are, just knowledge that "when I get TLV > > blah, I need to save that info". > > 4. As part of radio synchronization, two radios exchange their =20 > opaque > > data. > > 5. A radio receiving such opaque data inserts it into a Neighbor > > Up..... and now you have end-to-end Layer 3 knowledge, without the > > radio needing to know very much at all. > > 6. If addresses change on the router (via configuration), the router > > sends Peer Update to its radio, when then re-transmits the opaque > > data to radio peers. That opaque data is inserted into Neighbor > > Update. > > Okay, that is something that wasn't clear to me from your draft. > > I would disagree that this information is totally opaque for the =20 > Modem, because it has to know which TLV it has to parse/synchronize. =20= > But putting address fields into the "Peer Offer" message is an =20 > interesting idea. Not really. It just has to know that TLV '0x54' is something to be =20 cached, and what the overall length of it is. then than '0x54' TLV =20 gets lobbed at the radio partner, who knows to insert it into a =20 Neighbor Up (or Update).... no Layer 3 address parsing/cognizance =20 expressed or implied. > > Thats why I am 'drilling' a lot for this 'why is the usecase behind =20= > X' things. Because without knowing this details, a lot protocol =20 > design decisions seem to be pointless. > And the reason I'm reluctant to spell out some of these things is that =20= I get requests to make them *part of the draft*. This is some of the =20 innovation behind DLEP. I think we have to walk a very fine line here =20= - enough in the spec to guarantee interoperability between modems and =20= routers, but not so much that we stifle innovation. So while I'm OK =20 with explaining what the motivation was, I'm going to be extremely =20 reluctant to insert that into the draft - again, I think the mode =20 should be that DLEP specifies what data is transferred between modem =20 and router, and how it's formatted. What is actually *done* with the =20 data once received is out of scope. Stan > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Thu Apr 26 07:05:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D6621F85F7 for ; Thu, 26 Apr 2012 07:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGJRynohDRh3 for ; Thu, 26 Apr 2012 07:05:30 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 38F3221F85E5 for ; Thu, 26 Apr 2012 07:05:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="234318470" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 15:05:29 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QE5Tax029745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 15:05:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 15:05:29 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: AQHNI5dtQS6Ej0n5skifyF6SVWSSeJatDOsAgAADqQCAAAHhgIAAESrA Date: Thu, 26 Apr 2012 14:05:28 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <711C7D9D-D116-461F-B6A8-F7AD83D479C4@cisco.com> <4F9953DC.1010407@fkie.fraunhofer.de> <5A828886-2CBB-441B-9E39-F6E81C040A11@cisco.com> In-Reply-To: <5A828886-2CBB-441B-9E39-F6E81C040A11@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:05:31 -0000 You could present the motivation as an example of use. Example should make = it clear it's not the only option. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 26 April 2012 15:02 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 26, 2012, at 9:55 AM, Henning Rogge wrote: > On 04/26/2012 03:42 PM, Stan Ratliff wrote: >> Rick, >> >> This shows one of the problems I'm having with "restructuring". =20 >> Looks to >> me that "Credit WIndow Status" has at least 3 definitions: >> 0x0101 Credit Window Status >>> 0x0201 Credit Window Status >> >>> 0x0501 Credit Window Status >> >> >> This is easier? > > No, it is not. > > And it is also not necessary, neither for subtlvs nor for real ones. =20 > One TLV-type (some of them with extension) for each type of data =20 > should be enough. > > > And that's precisely why the address TLV's are part of "Peer =20 > Offer" - > > what we envisioned goes something like: > > 1. Modem sends Peer Discovery > > 2. Router responds with Peer Offer, *with* its (the router's) > > addresses. > > 3. Modem could strip out those TLV's, and treat them as opaque =20 > data - > > no cognizance of what they are, just knowledge that "when I get TLV > > blah, I need to save that info". > > 4. As part of radio synchronization, two radios exchange their =20 > opaque > > data. > > 5. A radio receiving such opaque data inserts it into a Neighbor > > Up..... and now you have end-to-end Layer 3 knowledge, without the > > radio needing to know very much at all. > > 6. If addresses change on the router (via configuration), the router > > sends Peer Update to its radio, when then re-transmits the opaque > > data to radio peers. That opaque data is inserted into Neighbor > > Update. > > Okay, that is something that wasn't clear to me from your draft. > > I would disagree that this information is totally opaque for the =20 > Modem, because it has to know which TLV it has to parse/synchronize. =20 > But putting address fields into the "Peer Offer" message is an =20 > interesting idea. Not really. It just has to know that TLV '0x54' is something to be =20 cached, and what the overall length of it is. then than '0x54' TLV =20 gets lobbed at the radio partner, who knows to insert it into a =20 Neighbor Up (or Update).... no Layer 3 address parsing/cognizance =20 expressed or implied. > > Thats why I am 'drilling' a lot for this 'why is the usecase behind =20 > X' things. Because without knowing this details, a lot protocol =20 > design decisions seem to be pointless. > And the reason I'm reluctant to spell out some of these things is that =20 I get requests to make them *part of the draft*. This is some of the =20 innovation behind DLEP. I think we have to walk a very fine line here =20 - enough in the spec to guarantee interoperability between modems and =20 routers, but not so much that we stifle innovation. So while I'm OK =20 with explaining what the motivation was, I'm going to be extremely =20 reluctant to insert that into the draft - again, I think the mode =20 should be that DLEP specifies what data is transferred between modem =20 and router, and how it's formatted. What is actually *done* with the =20 data once received is out of scope. Stan > Henning Rogge > > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Thu Apr 26 07:28:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836DF21F8736 for ; Thu, 26 Apr 2012 07:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdpNB9YSfxNR for ; Thu, 26 Apr 2012 07:28:51 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id C677C21F8732 for ; Thu, 26 Apr 2012 07:28:49 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 26 Apr 2012 16:28:47 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 16:28:47 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:28:46 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:28:46 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 15:28:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 15:28:45 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jsogs8EG8YFhbQyudGn0B8l8cMAABbj+w References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Stan Ratliff" X-OriginalArrivalTime: 26 Apr 2012 14:28:41.0530 (UTC) FILETIME=[E0C0D1A0:01CD23B8] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18866.005 X-TM-AS-Result: No--16.506600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:28:51 -0000 Stan, > From: Stan Ratliff [mailto:sratliff@cisco.com] >=20 > This shows one of the problems I'm having with "restructuring". Looks > to me that "Credit WIndow Status" has at least 3 definitions: > 0x0101 Credit Window Status > > 0x0201 Credit Window Status >=20 > > 0x0501 Credit Window Status >=20 I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, Lo-Byte is always 0x01 =3D Credit Window Status. TLV type indicates message (what Henning calls his Type TLV) Extension types (lo-bytes) give Stan's Sub-TLV. This is a more efficient representation than Henning's, but carries the same information. All I was trying to do was map Stan's Sub-TLV model into RFC5444 by using extension types. Rick Taylor From sratliff@cisco.com Thu Apr 26 07:47:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B097321F866B for ; Thu, 26 Apr 2012 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZznbjWh7-LMS for ; Thu, 26 Apr 2012 07:47:47 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BBE7121F866C for ; Thu, 26 Apr 2012 07:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=5430; q=dns/txt; s=iport; t=1335451666; x=1336661266; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ZaKSmy6sRy7yxIxPH3566MbOWcup1sn+N9u1dpZWmcM=; b=CDU0MdNh/gCUFBpGAKXeuzh/YDRRIz4tp+8gfz08JFypRVPtUVFlsGyR +8XWToxE3j2G4Lg3lD6ewakC1daGWROcDjWvFvv2lp0kDuNFEKg/FAeg/ 9W052YZAogWs2UJ86Rk7wxr918GgeXdTTMiR+cfFBT3l/NbYwZAAoNXFs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAM5emU+tJV2Z/2dsb2JhbABEsWuBB4IJAQEBAwEBAQEPASUCNAsFCwsYLicwBhMih2YFC5peoDAEkAJjBJV9jleBaYME X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78104031" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 26 Apr 2012 14:47:46 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3QEljVn019770; Thu, 26 Apr 2012 14:47:45 GMT Message-Id: <4AD72F83-DCB6-4EED-9628-0BC78EE70CAB@cisco.com> From: Stan Ratliff To: Teco Boot In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 10:47:46 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:47:47 -0000 I thought that would have been intuitively obvious to even the casual observer... But since you asked, I speak as a co-author and editor of the DLEP draft. Stan On Apr 25, 2012, at 4:18 PM, Teco Boot wrote: > Stan, > If you SHOUT, what hat are you wearing? > Teco > > Op 25 apr. 2012, om 18:57 heeft Stan Ratliff het volgende geschreven: > >> >> On Apr 25, 2012, at 11:17 AM, Abdussalam Baryun wrote: >> >>> Hi Henning and Teco, >>> >>> Having some comments on below discussions, I maybe misunderstood (I >>> still reading the DLEP protocol !). >>> >>>> IMHO unneeded functions. >>> >>>> One man's unneeded function is another man's essential function. I >>>> think when there's a function one doesn't see a need for, it's time >>>> to ask why it's there before suggesting removing it. >>> >>> AB> IMHO, this unneeded-function is only true in fixed state >>> conditions not in arbitrary. The DLEP solves slow process of >>> the-updating-functions (link state detection) which usually are >>> expected-stable by routing function for a certen time, but DLEP >>> reports the unexpected link factors, even though it may have some >>> limitations. IMHO all DLEP functions should be independent in this >>> first standard, in future we may think to adapt to other protocols' >>> works. >>> >>>> I did not have any intention to remove functionality. I meant IETF >>>> has already protocols for functions DLEP also provides. We should >>>> try >>>> to use existing protocols as much as possible, before standardizing >>>> new ones. I suggested to split DLEP in what is needed and isn't in >>>> place (STD TRACK) and what can be done in some special cases >>>> (experimental). IMHO flow control and address resolving are >>>> unneeded >>>> and I asked why these are in DLEP. I did not get satisfying >>>> answers. >>> >> >> First off, splitting DLEP into multiple specs is a REALLY bad idea. >> If we did that, there wouldn't be ANY place where the protocol, in >> its entirety, is documented. IMO, that makes it more difficult to >> implement, and more difficult to ensure interoperability. Next, >> I've explained the reasoning behind the flow control on more than >> one occasion - it was put in due to *specific requests*, both on >> and off-list, by members of the WG. It's consistent with RFC 5578. >> And, IT IS OPTIONAL. Don't like it? Simple. Then DON'T IMPLEMENT >> IT. Same thing goes for the addresses - as has been said before, >> reliance on other protocols like ARP slows down the process. It >> also makes the underlying assumption that *everything* one router/ >> radio pair attaches to is in the same subnet - because IIRC, ARP >> gets discarded when subnets don't match. With this OPTIONAL (again, >> if you don't like it, then don't implement it) approach, the >> appropriate ARP caches can be populated when they're needed, >> irrespective of subnet masks. Provided, of course, the modem >> (radio) already has cognizance of the far-end's address(es). >> >> Thus far, I've seen MULTIPLE requests to put flow control into the >> spec, and only ONE to remove it. Operating under the "Rough >> consensus and working code" model, I'd say that up to this >> juncture, we have "rough consensus" to KEEP flow control in the >> document. >> >> Stan >> >> >> >>> AB> I think it is better to solve the protocol advantages in its >>> use-case-problem, than to solve the full MANET problems. Then we may >>> look at all protocols equally and see which functions needs to be >>> taken apart and which should be satying as it is. If we follow the >>> evaluation process as in RFC2501, I think DLEP has interesting >>> methods >>> which if we modify routing protocols to adapt to its rules will be >>> more reasonable, because the dynamic topology is the main problem in >>> MANET, and DLEP is reporting this change very closer than other >>> MRPs. >>> However, I just want to mention that we can look in both sides >>> either >>> modify/split DLEP functions or MRPs. >>> >>>> I think they are in DLEP because there are already quite a few IP >>>> capable radios >who KNOW their own and their neighbors IP address >>>> because of their internal >protocol. >>> >>>> If the radio has knowledge about this, it should be able to tell >>>> the router about it so >the router can set the right IP on his >>>> local interface. >>> >>> AB> DLEP is for link dynamic behavior than it is about node's >>> behavior, so it is more important that it is reporting the link >>> change, the IP is an advantage alternative. >>> >>>> But the DLEP-Service (radio) should only report whats already >>>> known, it should not >generate additional traffic. >>> >>> AB> I don't think it is generating additional, it generated >>> necessary >>> information for an arbitrary situation (unpredicted by routers), >>> Therefore, it is solving a problem that is not solved as mentioned >>> in >>> the use-case discussions. >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From sratliff@cisco.com Thu Apr 26 07:52:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE83D21F8699 for ; Thu, 26 Apr 2012 07:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql-3-yodfvtF for ; Thu, 26 Apr 2012 07:52:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 33C9421F857A for ; Thu, 26 Apr 2012 07:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1371; q=dns/txt; s=iport; t=1335451962; x=1336661562; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=5RWmRuktqwbDgBVWUcBMvrICak3IC2cBdVgx/ot7YUM=; b=cDM3ERrNeozaejG85IO2Pl0weLYvUM3ZIj/PCC1+WwqPtSqf/exSqUfB jJNMZ8l8YTOdP9jPNZtwQGEJcLcLDkh6QlAsMi0iDfVRaA4KQDybCUxdR VgkKYLMNSzQM4tARRYuX/6folnUeTZ0aVBUNm6Ii5sJgphn8bROJ0osxB Y=; X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78119543" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 26 Apr 2012 14:52:41 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q3QEqdRS002569; Thu, 26 Apr 2012 14:52:39 GMT Message-Id: From: Stan Ratliff To: Rick Taylor In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 10:52:39 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:52:43 -0000 On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: > Stan, > >> From: Stan Ratliff [mailto:sratliff@cisco.com] >> >> This shows one of the problems I'm having with "restructuring". Looks >> to me that "Credit WIndow Status" has at least 3 definitions: >> 0x0101 Credit Window Status >>> 0x0201 Credit Window Status >> >>> 0x0501 Credit Window Status >> > > I'm afraid I am doing bit-twiddling here: Hi-byte = Message Type, > Lo-Byte is always 0x01 = Credit Window Status. > > TLV type indicates message (what Henning calls his Type TLV) > Extension types (lo-bytes) give Stan's Sub-TLV. This is a more > efficient representation than Henning's, but carries the same > information. > Since the protocol is intended to *only* traverse the local (typically Ethernet) link between modem and local router, I admit that efficiency/ compression wasn't one of the goals. As for simplicity, it seems easier to me to just pick the Type value up and directly feed it into state machinery instead of needing to perform some sort of "bit-level gymnastics" on it prior. Regards, Stan > All I was trying to do was map Stan's Sub-TLV model into RFC5444 by > using extension types. > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Thu Apr 26 07:54:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A757E21F86AA for ; Thu, 26 Apr 2012 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFEbj34FVFom for ; Thu, 26 Apr 2012 07:54:36 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2A21F857A for ; Thu, 26 Apr 2012 07:54:35 -0700 (PDT) Received: by lagj5 with SMTP id j5so1103974lag.31 for ; Thu, 26 Apr 2012 07:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=3KVzD5vegz5NG+K1GPGwWOZyv8c1wUwEi2gJ7W1GN54=; b=UaeIND5VkDFCEUnEdYo2YzH2ImzCdBqhts8yhQhk2Vclz9+30BsZ5GS8iQCINU6ViL UOlnLexgAh9ASeQT+IiA4j5R84tmLaNSUu9W4TCEQ15BHYqLXLQkYbLFOyUnwqqy8B3e qZG5/UyLx3cjXoeb2UqSYJ/8i3uYa4Ilq6I/CwjTjSSb79jCJkrVc2x0gJ+dNoSmPaDb epaJc8eLTP11HTZE/1X4jHRh+6sX3A4xyjhWtHUbzL9q0NUCBCe+8QQ7pBE7Qj6+Qeu5 FkwcNZV+oAc5qCD+Mf68NFlB8X+siZW3TxMwjSd9oW0UP+5NzWYZljo75VeyrorFTiC4 Vvpg== Received: by 10.112.47.170 with SMTP id e10mr3466244lbn.69.1335452074485; Thu, 26 Apr 2012 07:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 07:54:14 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 16:54:14 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:54:37 -0000 Even for links that are bandwidth constraint, using the context of the message to see what the TLV is about is a better choice. Repeating the order-number over and over for each TLV is just bad. Henning Rogge On Thu, Apr 26, 2012 at 16:52, Stan Ratliff wrote: > > On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: > >> Stan, >> >>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>> >>> This shows one of the problems I'm having with "restructuring". Looks >>> to me that "Credit WIndow Status" has at least 3 definitions: >>> =A00x0101 Credit Window Status >>>> >>>> 0x0201 Credit Window Status >>> >>> >>>> 0x0501 Credit Window Status >>> >>> >> >> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, >> Lo-Byte is always 0x01 =3D Credit Window Status. >> >> TLV type indicates message (what Henning calls his Type TLV) >> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a more >> efficient representation than Henning's, but carries the same >> information. >> > > Since the protocol is intended to *only* traverse the local (typically > Ethernet) link between modem and local router, I admit that > efficiency/compression wasn't one of the goals. As for simplicity, it see= ms > easier to me to just pick the Type value up and directly feed it into sta= te > machinery instead of needing to perform some sort of "bit-level gymnastic= s" > on it prior. > > Regards, > Stan > > >> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >> using extension types. >> >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Thu Apr 26 08:01:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF82321F8594 for ; Thu, 26 Apr 2012 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ9r9sLR-qaz for ; Thu, 26 Apr 2012 08:01:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF1321F8682 for ; Thu, 26 Apr 2012 08:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2561; q=dns/txt; s=iport; t=1335452468; x=1336662068; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=m9vF31oUjCojJvPplkLveAR7CJwO0AJRa4kH+nqmcVA=; b=V8mvuFfpdpiaAO/cp9zFzkHjMCoyviMM82VAmXoR8J75ygKBEcsyEkhF YiZB5E+HXQrZAL9pGUF08/u/vcgjcwwlh3yyWuU9/qVkrsoSFUUC4mSSU IVSO50Ok6MVqDKkQzR1MRtCgpEwuSLBf5B2cSkaUC5TOCS+zFhxTat+dZ g=; X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="78113455" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2012 15:01:07 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QF17qN018154; Thu, 26 Apr 2012 15:01:07 GMT Message-Id: <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 11:01:07 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:01:09 -0000 And in those cases, it's easy to fall prey to the notion that a certain piece of data (e.g. Maximum Data Rate) winds up being allocated from multiple number spaces. And that's a bad thing. Stan On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: > Even for links that are bandwidth constraint, using the context of the > message to see what the TLV is about is a better choice. Repeating the > order-number over and over for each TLV is just bad. > > Henning Rogge > > On Thu, Apr 26, 2012 at 16:52, Stan Ratliff > wrote: >> >> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >> >>> Stan, >>> >>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>> >>>> This shows one of the problems I'm having with "restructuring". >>>> Looks >>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>> 0x0101 Credit Window Status >>>>> >>>>> 0x0201 Credit Window Status >>>> >>>> >>>>> 0x0501 Credit Window Status >>>> >>>> >>> >>> I'm afraid I am doing bit-twiddling here: Hi-byte = Message Type, >>> Lo-Byte is always 0x01 = Credit Window Status. >>> >>> TLV type indicates message (what Henning calls his Type TLV) >>> Extension types (lo-bytes) give Stan's Sub-TLV. This is a more >>> efficient representation than Henning's, but carries the same >>> information. >>> >> >> Since the protocol is intended to *only* traverse the local >> (typically >> Ethernet) link between modem and local router, I admit that >> efficiency/compression wasn't one of the goals. As for simplicity, >> it seems >> easier to me to just pick the Type value up and directly feed it >> into state >> machinery instead of needing to perform some sort of "bit-level >> gymnastics" >> on it prior. >> >> Regards, >> Stan >> >> >>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >>> using extension types. >>> >>> Rick Taylor >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Thu Apr 26 08:04:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC321F8703 for ; Thu, 26 Apr 2012 08:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOuj5TFFOAUx for ; Thu, 26 Apr 2012 08:04:02 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id B27C921F8702 for ; Thu, 26 Apr 2012 08:04:01 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 26 Apr 2012 17:04:01 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 17:04:00 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.21]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:04:00 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:04:00 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:03:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 16:03:59 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378D0F6@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and modemLPA (fixed small bug in binarydescription) Thread-Index: Ac0jq93o4CSmEbC0Qp6IyePbkfq/dQADZsGw References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CD19@SUKNPT8106.cogent-dsn.local><4F99436A.2080600@fkie.fraunhofer.de> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 26 Apr 2012 15:03:54.0836 (UTC) FILETIME=[CC61B940:01CD23BD] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.000 X-TM-AS-Result: No--3.996200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and modemLPA (fixed small bug in binarydescription) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:04:02 -0000 All, Having read and digested Henning's suggestion, may I propose a hybrid between his and my model: As before: "I tried to write down an example for a "neighbor update" event in DLEP, with both address, neighbor and metric changes. Please view this message with a constant width font, otherwise you will not see the structure. Its a neighbor update from radio 01:00:00:00:00:01 about neighbor 1 (02:00:00:00:00:01) and neighbor 2 (02:00:00:00:00:02). Neighbor 1 has the IP address 10.0.0.1, lost the IP address 10.0.0.2 and the current outgoing link speed is 1 mbit/s. Neighbor 2 dropped of the network since the last neighbor update." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "RFC 5444 compatible" logical structure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Packet | + Message (type DLEP, 6 byte addresses, | originator 01:00:00:00:00:01, sequence number 1234) | + Message Block=20 | | | + IDENT_TLV (value "server_id, client_id") | + Address Block (2 addresses, no head/tail/prefix | + Address 1 (mid: 02:00:00:00:00:01) | | | + ADDRESS_DROP_TLV (ext-type: "IPv4", | | value "10.0.0.2") | | | + METRIC_TLV (ext-type: "CDR", | value 1000000) | + Address 2 (mid: 02:00:00:00:00:02) | + NEIGHBOUR_DOWN_TLV () =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And now a Peer Offer message. This demonstrates the use of extension types to connect optional TLVs to their 'parent' TLV, much like Stan's Sub-TLV concept, but using the ext-type instead. Packet | + Message (type DLEP, 6 byte addresses, | originator 01:00:00:00:00:01, sequence number 1234) | | (No Address Blocks!) | + Message Block=20 | + IDENT_TLV (value "server_id, client_id") | + PEER_OFFER_TLV (value "server_id, version") | + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV, | ext-type: PEER_TYPE_SUBTLV, | value: "Fancy DLEP Modem") | + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV, | ext-type: HBEAT_INTERVAL_SUBTLV, | value: "3") | + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV, | ext-type: HBEAT_THRESHOLD_SUBTLV, | value: "5") | + PEER_OFFER_EX_TLV (type: PEER_OFFER_TLV, ext-type: METRICS_MDR_SUBTLV, value: "5000000") Rick Taylor From rick.taylor@cassidian.com Thu Apr 26 08:12:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F17921F8757 for ; Thu, 26 Apr 2012 08:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn8GzZwkYSzg for ; Thu, 26 Apr 2012 08:12:34 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3296B21F8753 for ; Thu, 26 Apr 2012 08:12:27 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 17:12:27 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 17:12:26 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:12:26 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:12:25 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:12:20 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 16:12:25 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378D111@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jvZV7WwA/Q3cFSvylkPYGSw0yFAAAF92g References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 26 Apr 2012 15:12:20.0329 (UTC) FILETIME=[F9ADD590:01CD23BE] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.000 X-TM-AS-Result: No-3.835600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:12:37 -0000 Stan, > And in those cases, it's easy to fall prey to the notion that a > certain piece of data (e.g. Maximum Data Rate) winds up being > allocated from multiple number spaces. And that's a bad thing. >=20 That's exactly what I was trying to avoid. I'm basically suggesting using the as the draft-02 , and the as Henning's Order-Number TLV value. I agree that compression is largely a pointless exercise, unless these packets are broadcast as 'opaque' blobs by the radios as per your previous example. I was just hoping to avoid a situation where it is decided that DLEP needs to fit RFC5444 "better", and the final result ends up being too unusual/weird/complex. Rick Taylor From hrogge@googlemail.com Thu Apr 26 08:13:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5321F8757 for ; Thu, 26 Apr 2012 08:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDY2fy8gIG6J for ; Thu, 26 Apr 2012 08:13:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA5621F8755 for ; Thu, 26 Apr 2012 08:13:10 -0700 (PDT) Received: by lagj5 with SMTP id j5so1122163lag.31 for ; Thu, 26 Apr 2012 08:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yl6y2jyUiVN52F+acS8i662FXpVhq0uMRCBOkR+Z0s0=; b=CEeZNdqCjQE54iIL7w4vEARWfzoKOabF1aqbHdElx5mcMd7aX3odxVRPA7Ewh3Qvjj YDkDIp/XX0idVmZNJKpBOJTt/anjOdReman5DX3Frm8fbIT/G6arxlyh4oBU2JFjYCLh C1SeLJSbP8gZCqF0l1bKc59x+nr4+eSteGYVLpPAz5Th0CvCSB+Qyf1trdTHqYxUhocN YOphgThX4pIxnpgWMHggGkLJvmFaDoLZT7GnLvKx9K44mW4m/wguX3xAJ85QHoo6PNke m0RkfMPxoUAho81vRYIzzxAs5s6w6sOzZmQQXsjdRwhzk1ISpDTdQA7FDiinj+fgFm1h HIVg== Received: by 10.152.103.134 with SMTP id fw6mr6878979lab.20.1335453189261; Thu, 26 Apr 2012 08:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:12:49 -0700 (PDT) In-Reply-To: <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> From: Henning Rogge Date: Thu, 26 Apr 2012 17:12:49 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:13:13 -0000 Thats why a "raw metric TLV" from the global namespace (both message and address TLV) might be a good thing. It gives other protocols the standardized tools to work with too. Henning Rogge On Thu, Apr 26, 2012 at 17:01, Stan Ratliff wrote: > And in those cases, it's easy to fall prey to the notion that a certain > piece of data (e.g. Maximum Data Rate) winds up being allocated from > multiple number spaces. And that's a bad thing. > > Stan > > > On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: > >> Even for links that are bandwidth constraint, using the context of the >> message to see what the TLV is about is a better choice. Repeating the >> order-number over and over for each TLV is just bad. >> >> Henning Rogge >> >> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff wrote: >>> >>> >>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >>> >>>> Stan, >>>> >>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>>> >>>>> This shows one of the problems I'm having with "restructuring". Looks >>>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>>> =A00x0101 Credit Window Status >>>>>> >>>>>> >>>>>> 0x0201 Credit Window Status >>>>> >>>>> >>>>> >>>>>> 0x0501 Credit Window Status >>>>> >>>>> >>>>> >>>> >>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, >>>> Lo-Byte is always 0x01 =3D Credit Window Status. >>>> >>>> TLV type indicates message (what Henning calls his Type TLV) >>>> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a more >>>> efficient representation than Henning's, but carries the same >>>> information. >>>> >>> >>> Since the protocol is intended to *only* traverse the local (typically >>> Ethernet) link between modem and local router, I admit that >>> efficiency/compression wasn't one of the goals. As for simplicity, it >>> seems >>> easier to me to just pick the Type value up and directly feed it into >>> state >>> machinery instead of needing to perform some sort of "bit-level >>> gymnastics" >>> on it prior. >>> >>> Regards, >>> Stan >>> >>> >>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >>>> using extension types. >>>> >>>> Rick Taylor >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Thu Apr 26 08:15:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF55421E804E for ; Thu, 26 Apr 2012 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyZTshgZc3FQ for ; Thu, 26 Apr 2012 08:15:14 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7160021E8049 for ; Thu, 26 Apr 2012 08:15:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,486,1330905600"; d="scan'208";a="234347787" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 16:15:12 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QFFCbE016766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 16:15:12 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 16:15:11 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Stan Ratliff Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: AQHNI5dtQS6Ej0n5skifyF6SVWSSeAABbj+wlq0VDoCAAABxAIAAAe2AgAADRYCAABEdIA== Date: Thu, 26 Apr 2012 15:15:11 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:15:14 -0000 I suggest first working out what the TLVs you want are, then considering wh= ether to make them message specific or global later. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 26 April 2012 16:13 To: Stan Ratliff Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Thats why a "raw metric TLV" from the global namespace (both message and address TLV) might be a good thing. It gives other protocols the standardized tools to work with too. Henning Rogge On Thu, Apr 26, 2012 at 17:01, Stan Ratliff wrote: > And in those cases, it's easy to fall prey to the notion that a certain > piece of data (e.g. Maximum Data Rate) winds up being allocated from > multiple number spaces. And that's a bad thing. > > Stan > > > On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: > >> Even for links that are bandwidth constraint, using the context of the >> message to see what the TLV is about is a better choice. Repeating the >> order-number over and over for each TLV is just bad. >> >> Henning Rogge >> >> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff wrote: >>> >>> >>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >>> >>>> Stan, >>>> >>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>>> >>>>> This shows one of the problems I'm having with "restructuring". Looks >>>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>>> =A00x0101 Credit Window Status >>>>>> >>>>>> >>>>>> 0x0201 Credit Window Status >>>>> >>>>> >>>>> >>>>>> 0x0501 Credit Window Status >>>>> >>>>> >>>>> >>>> >>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, >>>> Lo-Byte is always 0x01 =3D Credit Window Status. >>>> >>>> TLV type indicates message (what Henning calls his Type TLV) >>>> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a more >>>> efficient representation than Henning's, but carries the same >>>> information. >>>> >>> >>> Since the protocol is intended to *only* traverse the local (typically >>> Ethernet) link between modem and local router, I admit that >>> efficiency/compression wasn't one of the goals. As for simplicity, it >>> seems >>> easier to me to just pick the Type value up and directly feed it into >>> state >>> machinery instead of needing to perform some sort of "bit-level >>> gymnastics" >>> on it prior. >>> >>> Regards, >>> Stan >>> >>> >>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >>>> using extension types. >>>> >>>> Rick Taylor >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Thu Apr 26 08:15:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278A21E8098 for ; Thu, 26 Apr 2012 08:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbDh37j6z5hD for ; Thu, 26 Apr 2012 08:15:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABEE21E80A3 for ; Thu, 26 Apr 2012 08:15:18 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so967910lbb.31 for ; Thu, 26 Apr 2012 08:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=NFLjSD7upgdrWKme+6suXOzuVWpsEn/6my/FMYaFxRM=; b=rZMVzXGvKvV7U3aLp/Ex+ncsQhg+MQLben3x4DPk+4LmgXOwYadR8gqoXCAXKIRjIF zsbT5DcFmumXm91dTDPchlR5ukk0Oo4LpjYHFjk/pqGY4nTIJDy+uSVsvaUlHZbtFzhQ VQN7UZkcfvmtSJhWYe9Zr2YWU2ksROEsWxCnJOZpWc5nzax6C0vH3kmOXVG2Y3q7pTMG SdN3qFVkveHflKLxRRY7hYdTrt73jwmmEFfpiYXbFsy/eLeeeTbBiQ81CSaFuvRNkMpV GQh/aA06Ac418WfNOoJSdDJyhJxwdwIjk5o2RTqEFqUIUOa2LWQArubQKOYVOrIHDlef Wj0w== Received: by 10.152.135.104 with SMTP id pr8mr6866920lab.27.1335453317353; Thu, 26 Apr 2012 08:15:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:14:57 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D111@SUKNPT8106.cogent-dsn.local> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D111@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 17:14:57 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:15:19 -0000 On Thu, Apr 26, 2012 at 17:12, Rick Taylor wrot= e: > That's exactly what I was trying to avoid. =A0I'm basically suggesting > using the as the draft-02 , and the as > Henning's Order-Number TLV value. The question is WHY? Just skip the order TLV id in the other TLVs. Its enough to store the order TLV at one place in the message (for example the order TLV I suggested). Thats enough to understand the rest of the message. Henning > I agree that compression is largely a pointless exercise, unless these > packets are broadcast as 'opaque' blobs by the radios as per your > previous example. > > I was just hoping to avoid a situation where it is decided that DLEP > needs to fit RFC5444 "better", and the final result ends up being too > unusual/weird/complex. > > Rick Taylor --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Thu Apr 26 08:23:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1621E8032 for ; Thu, 26 Apr 2012 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPlBuvpvjGtF for ; Thu, 26 Apr 2012 08:23:28 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD821E8092 for ; Thu, 26 Apr 2012 08:23:27 -0700 (PDT) Received: by lagj5 with SMTP id j5so1132915lag.31 for ; Thu, 26 Apr 2012 08:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=maUO9buR8bYRfoGGkDTxcVrN6wLZwnJI5FqUCheSRiM=; b=tQ0jtQY6WWZu5lREZ6WTJIeT1eYXtnwlroNrZF/n47WbN39jGivVMNZm1fNQV5mGYu YwqUPg6KKpbboY6P1EyfiOOsEgJ3pVFVb2Qm3gUi1kO5kzjOlxg9QadYiPadVBA7XvRu amCnzj9npNIT9Jg7fEmunIBqfO3jZAu/Mtj/zjSPZ7jm0YWIGrqo1z6WqKrjx2WyjIvT h3BH6E5XkeCTLWc9NE75UUmTq7IrKlYTZJMNGnlGnFQ/B0tEUfL8fzYKLxx7jVyiETKv O5KTgW0jgev0i0tsXdsg+0PlmLSiNMmkzROYzV+o9rHBXXyDq+3bwpwZTOvJYJlIeSas Fmng== Received: by 10.152.103.134 with SMTP id fw6mr6914111lab.20.1335453806652; Thu, 26 Apr 2012 08:23:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:23:05 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> From: Henning Rogge Date: Thu, 26 Apr 2012 17:23:05 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:23:29 -0000 I think TX/RX current and maximum datarate are examples for "raw metrics" as opposed to the "dimensionless metric" TLV from OLSRv2. Other things I would like to have are Signal Strength, Radio Frequency (especially to reuse the TLV for the Request Link Characteristics order!) and maybe some layer-2 statistics that are difficult/impossible to get from the router. Henning On Thu, Apr 26, 2012 at 17:15, Dearlove, Christopher (UK) wrote: > I suggest first working out what the TLVs you want are, then considering = whether to make them message specific or global later. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Henning Rogge > Sent: 26 April 2012 16:13 > To: Stan Ratliff > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Thats why a "raw metric TLV" from the global namespace (both message > and address TLV) might be a good thing. It gives other protocols the > standardized tools to work with too. > > Henning Rogge > > On Thu, Apr 26, 2012 at 17:01, Stan Ratliff wrote: >> And in those cases, it's easy to fall prey to the notion that a certain >> piece of data (e.g. Maximum Data Rate) winds up being allocated from >> multiple number spaces. And that's a bad thing. >> >> Stan >> >> >> On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: >> >>> Even for links that are bandwidth constraint, using the context of the >>> message to see what the TLV is about is a better choice. Repeating the >>> order-number over and over for each TLV is just bad. >>> >>> Henning Rogge >>> >>> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff wrote: >>>> >>>> >>>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >>>> >>>>> Stan, >>>>> >>>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>>>> >>>>>> This shows one of the problems I'm having with "restructuring". Look= s >>>>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>>>> =A00x0101 Credit Window Status >>>>>>> >>>>>>> >>>>>>> 0x0201 Credit Window Status >>>>>> >>>>>> >>>>>> >>>>>>> 0x0501 Credit Window Status >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, >>>>> Lo-Byte is always 0x01 =3D Credit Window Status. >>>>> >>>>> TLV type indicates message (what Henning calls his Type TLV) >>>>> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a more >>>>> efficient representation than Henning's, but carries the same >>>>> information. >>>>> >>>> >>>> Since the protocol is intended to *only* traverse the local (typically >>>> Ethernet) link between modem and local router, I admit that >>>> efficiency/compression wasn't one of the goals. As for simplicity, it >>>> seems >>>> easier to me to just pick the Type value up and directly feed it into >>>> state >>>> machinery instead of needing to perform some sort of "bit-level >>>> gymnastics" >>>> on it prior. >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >>>>> using extension types. >>>>> >>>>> Rick Taylor >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From rick.taylor@cassidian.com Thu Apr 26 08:25:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A42921E8028 for ; Thu, 26 Apr 2012 08:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmkEADyWcM-y for ; Thu, 26 Apr 2012 08:25:12 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id BE72D21F8737 for ; Thu, 26 Apr 2012 08:25:11 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 17:25:10 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 17:25:10 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:25:10 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:25:10 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:25:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 16:25:08 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccRwL0WZiSTDiUzzTJoNGW1QAACEzQ References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014 224A843C10C0 CCE92AC10378D111@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 26 Apr 2012 15:25:03.0965 (UTC) FILETIME=[C0D770D0:01CD23C0] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.000 X-TM-AS-Result: No--15.911000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:25:12 -0000 > From: Henning Rogge [mailto:hrogge@googlemail.com] >=20 > On Thu, Apr 26, 2012 at 17:12, Rick Taylor > wrote: > > That's exactly what I was trying to avoid. =A0I'm basically = suggesting > > using the as the draft-02 , and the = as > > Henning's Order-Number TLV value. >=20 > The question is WHY? >=20 I was trying to allow more than 1 order per message. But on reflection, = one could just use more than 1 message per packet. So, you are suggesting: 1) In the message-block and/or each address-block in the DLEP message, = there is 1 ORDER_TLV. (Is this right for Address-Blocks?) 2) Every other TLV in the block refers to the order described by the = ORDER_TLV. 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is = discarded. I think you might be convincing me...=20 Rick Taylor From hrogge@googlemail.com Thu Apr 26 08:28:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541AA21E80A9 for ; Thu, 26 Apr 2012 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAGJ0HmGxNfA for ; Thu, 26 Apr 2012 08:28:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3A421E8028 for ; Thu, 26 Apr 2012 08:28:17 -0700 (PDT) Received: by lagj5 with SMTP id j5so1137416lag.31 for ; Thu, 26 Apr 2012 08:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CsZd4KrKXWFOmrda840an+UBIrAYh1Mofm18eFdorRU=; b=OnRSMDd24noJno3HMLzf9uiCGHSXbuSz4pn48sjO1RL0hEOCZWeeVrWlbyfIyjNiFj oKjXuCwz6HTMp+9fWMdNyoW2SCrZlCEzalBWm//KgNegd6E5M6mFAQBET4ScD7GNq0Ke TNpRuguqQUuwmLwbTGO+KIYQfH0w75lNCmoOi3XqkoHhDVCMuSKAMDTb3SoK2Ldg8J9L xuYdGkavwBnL4HnlfvxZ3kQfn25aoO8Ch0L04TAEDTmqzTpERutz+Tfirc2kt7j/YJOu BPv4sdnADoh6KQ7YTbah/jxPxatXVnGFnemBksONRtC9Fx9Ts4+1MqtsxymYAYpVGnV+ u5/A== Received: by 10.152.135.104 with SMTP id pr8mr6911314lab.27.1335454096242; Thu, 26 Apr 2012 08:28:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:27:55 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 17:27:55 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:28:18 -0000 On Thu, Apr 26, 2012 at 17:25, Rick Taylor wrot= e: > I was trying to allow more than 1 order per message. =A0But on reflection= , one could just use more than 1 message per packet. > > So, you are suggesting: > > 1) In the message-block and/or each address-block in the DLEP message, th= ere is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) The order TLV will be a Message-TLV... and there will be only one of them in a DLEP message. > 2) Every other TLV in the block refers to the order described by the ORDE= R_TLV. Every other TLV in the message (both message TLVs and address TLVs refers to the order described in the Order TLV. > 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is disca= rded. the message is discarded. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From rick.taylor@cassidian.com Thu Apr 26 08:29:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887821E80BA for ; Thu, 26 Apr 2012 08:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmvFGpmKa-Lh for ; Thu, 26 Apr 2012 08:29:16 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7030321E80B9 for ; Thu, 26 Apr 2012 08:29:15 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 17:29:14 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 17:29:14 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:29:14 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:29:14 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:29:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 16:29:13 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jwLwmOwvqaemGTzi3NCWtYV8HRAAAB48w References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local><2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> From: "Rick Taylor" To: "Henning Rogge" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 26 Apr 2012 15:29:08.0345 (UTC) FILETIME=[5280DE90:01CD23C1] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.000 X-TM-AS-Result: No--38.267600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:29:17 -0000 The current draft specifies: * Current Data Rate, * Maximum Data Rate, * Latency, * Expected Transmission Time, And some slightly 'fluffy' values: * Relative Link Quality * Resources I can understand how some DLEP consumers like having a dimensionless = metric 'Relative Link Quality', but I am against having more than 1 = dimensionless 'soft' metric to choose from. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Henning Rogge > Sent: 26 April 2012 16:23 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown >=20 > I think TX/RX current and maximum datarate are examples for "raw > metrics" as opposed to the "dimensionless metric" TLV from OLSRv2. >=20 > Other things I would like to have are Signal Strength, Radio Frequency > (especially to reuse the TLV for the Request Link Characteristics > order!) and maybe some layer-2 statistics that are > difficult/impossible to get from the router. >=20 > Henning >=20 > On Thu, Apr 26, 2012 at 17:15, Dearlove, Christopher (UK) > wrote: > > I suggest first working out what the TLVs you want are, then = considering > whether to make them message specific or global later. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > > Communications, Networks and Image Analysis Capability > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > > > -----Original Message----- > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf > Of Henning Rogge > > Sent: 26 April 2012 16:13 > > To: Stan Ratliff > > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry > > Subject: Re: [manet] DLEP and TLV breakdown > > > > ----------------------! WARNING ! ---------------------- > > This message originates from outside our organisation, > > either from an external partner or from the internet. > > Keep this in mind if you answer this message. > > Follow the 'Report Suspicious Emails' link on IT matters > > for instructions on reporting suspicious email messages. > > -------------------------------------------------------- > > > > Thats why a "raw metric TLV" from the global namespace (both message > > and address TLV) might be a good thing. It gives other protocols the > > standardized tools to work with too. > > > > Henning Rogge > > > > On Thu, Apr 26, 2012 at 17:01, Stan Ratliff = wrote: > >> And in those cases, it's easy to fall prey to the notion that a = certain > >> piece of data (e.g. Maximum Data Rate) winds up being allocated = from > >> multiple number spaces. And that's a bad thing. > >> > >> Stan > >> > >> > >> On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: > >> > >>> Even for links that are bandwidth constraint, using the context of = the > >>> message to see what the TLV is about is a better choice. Repeating = the > >>> order-number over and over for each TLV is just bad. > >>> > >>> Henning Rogge > >>> > >>> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff > wrote: > >>>> > >>>> > >>>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: > >>>> > >>>>> Stan, > >>>>> > >>>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] > >>>>>> > >>>>>> This shows one of the problems I'm having with "restructuring". > Looks > >>>>>> to me that "Credit WIndow Status" has at least 3 definitions: > >>>>>> =A00x0101 Credit Window Status > >>>>>>> > >>>>>>> > >>>>>>> 0x0201 Credit Window Status > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 0x0501 Credit Window Status > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message = Type, > >>>>> Lo-Byte is always 0x01 =3D Credit Window Status. > >>>>> > >>>>> TLV type indicates message (what Henning calls his Type TLV) > >>>>> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a = more > >>>>> efficient representation than Henning's, but carries the same > >>>>> information. > >>>>> > >>>> > >>>> Since the protocol is intended to *only* traverse the local > (typically > >>>> Ethernet) link between modem and local router, I admit that > >>>> efficiency/compression wasn't one of the goals. As for = simplicity, it > >>>> seems > >>>> easier to me to just pick the Type value up and directly feed it = into > >>>> state > >>>> machinery instead of needing to perform some sort of "bit-level > >>>> gymnastics" > >>>> on it prior. > >>>> > >>>> Regards, > >>>> Stan > >>>> > >>>> > >>>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 = by > >>>>> using extension types. > >>>>> > >>>>> Rick Taylor > >>>>> _______________________________________________ > >>>>> manet mailing list > >>>>> manet@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/manet > >>> > >>> > >>> > >>> > >>> -- > >>> Steven Hawkings about cosmic inflation: "An increase of billions = of > >>> billions of percent in a tiny fraction of a second. Of course, = that > >>> was before the present government." > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> > > > > > > > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > >=20 >=20 >=20 > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Apr 26 08:32:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35121E80B3 for ; Thu, 26 Apr 2012 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MVwph0PM9QL for ; Thu, 26 Apr 2012 08:32:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3271921E80B8 for ; Thu, 26 Apr 2012 08:32:02 -0700 (PDT) Received: by werb10 with SMTP id b10so1041242wer.31 for ; Thu, 26 Apr 2012 08:32:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gS0VUwYaXLZFnrHJnW5bmU6p3rKqJ6hCiS5+BxtG2to=; b=HviE74q5Oa/iwat/sPi5YTP48iwyu6n83LRzKkvMlfCubd5t/4rYRTPxXtstL9JAnv cdJT8DgE/wJHqMQUXPwLIMj+/rR+zrcomxsoHUEANsOFb52rfAXfCks+6sgqvLxF6u9l sGR8oeNaIwVTGOJiJ8EFDJcpImikxGVMK1VzkAty75sfEVSrQIURl+Dh/yi+da+GJhkA I3rBK/K9tiI8WvpxYeFG7JzN5kPfvyFwE5I/55KcabM6bNT9wHf6rYvgU6WvdU45uH2P ls4njhRBKAdAWWCQr8/8Q02edcH9f7qJjYWDgubUOvtshc27xcy675VazSIyI/3JrkY6 xAuw== Received: by 10.180.97.4 with SMTP id dw4mr43653366wib.18.1335454321242; Thu, 26 Apr 2012 08:32:01 -0700 (PDT) Received: from [172.16.4.196] ([188.205.88.52]) by mx.google.com with ESMTPS id w10sm12080272wiy.3.2012.04.26.08.31.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 08:31:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <6D11E177-199F-4FE1-ABE6-30A313FEF2E7@cisco.com> Date: Thu, 26 Apr 2012 17:32:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> <6D11E177-199F-4FE1-ABE6-30A313FEF2E7@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnFX3p8v5yRfFnfwhNeE7jVSQsTidIO2SDsn56wrC+fACdJUMFYpINHpn8y4VVt3KJCOcY2 Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:32:03 -0000 Op 26 apr. 2012, om 15:51 heeft Stan Ratliff het volgende geschreven: >=20 > On Apr 26, 2012, at 8:16 AM, Teco Boot wrote: >=20 >>=20 >> Op 26 apr. 2012, om 11:46 heeft Rick Taylor het volgende geschreven: >>=20 >>> Henning, >>>=20 >>>> Just to make sure I understand you correctly... >>>>=20 >>>> You mean that you do not want to use IPs as DLEP messages addresses = in >>>> Address Blocks, right? >>>=20 >>> Correct, I do not want to see them used there. >>>=20 >>>> Its still okay to carry them in Address-Block TLVs, to bind them to >>> the >>>> corresponding MAC address? >>>=20 >>> Yes, as 'normal' TLVs, they can go wherever they are needed as = currently >>> specified in draft-02. >>>=20 >>> As Teco says, layer 3 address TLVs should be optional. >>>=20 >>> I agree with Stan that it is really useful to have Layer 3 = addressing >>> delivered via DLEP when the modem knows it, but there are examples = where >>> the modem does not know, but DLEP can still function. >>>=20 >>> (I am using such a modem now, and I just ARP for the Layer 3 = addresses, >>> it's possible, but a PITA, particularly as InARP is largely = unsupported >>> in the real world). >>=20 >> The .!!!!-problem is mainly caused by address resolving on = non-transit links. >> On transit links, a good router populates forwarding tables when = there is >> a data path set up. ARP/NDP is enough for this and additional time = required >> for it is minor related to routing protocol convergence in many = cases. >>=20 >=20 > Except that you inherently force a MANET into a single subnet in order = for that to work. That's not the case in the networks I deploy. With IPv6 NDP this is not a problem. With ARP, AFAIK Cisco routers do not permit address resolving over = different subnets. It is not a limitation of the ARP spec. But yes, = there are problems here. It was discussed in Autoconf. How is it solved = when not using DLEP? Teco >=20 > Stan >=20 >=20 >> Teco >>=20 >>> Rick Taylor >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From hrogge@googlemail.com Thu Apr 26 08:32:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A321E80C9 for ; Thu, 26 Apr 2012 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlpCPJjQkfix for ; Thu, 26 Apr 2012 08:32:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA09D21E80BF for ; Thu, 26 Apr 2012 08:32:40 -0700 (PDT) Received: by lagj5 with SMTP id j5so1141237lag.31 for ; Thu, 26 Apr 2012 08:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D7yAquj4+DF920xuEsm3XQdRiNWJu4R36UH6nuA4gYQ=; b=ZjTU1Playqhj/m0VCDeNskKkX+Cucqmr7PdSYk3DgrBCU9H7zQAHTjpJNP0IwoJsYW u2WGqnEThG2tPWP2RUffkct4HQ6wHTKQvgRE+btMuxgO+1XZPrPsoKw2nSvLkO/OtFUq eEkswqIO7SY1hfx+t8fKyXGRciX1EVd8jogKh1oyZ7Gab4FT4mEbdRHdnwmCH+CgdFqP AAOFq4QFCkKKr09AreZ3esIc7Xuv0VwTl9d63JzLKLjXdXY1l9PnWYZKEzRp6bzcgPCe qE26UVMQTHLqis0DHi6X6fm+uACB+Wy2tgfu8Jjpfl//GrnjPVJfNTfvE4/HsYoFSucv 6Hnw== Received: by 10.152.112.161 with SMTP id ir1mr6999788lab.13.1335454359688; Thu, 26 Apr 2012 08:32:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:32:19 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 17:32:19 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:32:41 -0000 On Thu, Apr 26, 2012 at 17:29, Rick Taylor wrote: > The current draft specifies: > > * Current Data Rate, > * Maximum Data Rate, Both are okay... but they are not necessarily the same for transmission and reception. And there might be an interest in the multicast data rate too. > * Latency, > * Expected Transmission Time, Not sure what is even the difference between this two. > And some slightly 'fluffy' values: > * Relative Link Quality This is already in the OLSRv2 draft as a dimensionless metric value. We should reuse the TLV concept. > * Resources I can see the reason behind this, this might fit the "raw metric" better... because it has a defined meaning, its about how long your device will still operate until it goes offline. > I can understand how some DLEP consumers like having a dimensionless metric 'Relative Link Quality', but I am against having more than 1 dimensionless 'soft' metric to choose from. Yes, having multiple dimensionless metrics could be a crazy thing. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From rick.taylor@cassidian.com Thu Apr 26 08:34:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DED21E80D1 for ; Thu, 26 Apr 2012 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE91KbYroprM for ; Thu, 26 Apr 2012 08:34:38 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC85921E80C7 for ; Thu, 26 Apr 2012 08:34:37 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 26 Apr 2012 17:34:37 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Thu, 26 Apr 2012 17:34:36 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:34:36 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 17:34:36 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Apr 2012 16:34:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 26 Apr 2012 16:34:28 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jwWPDVqzMER8aTLuhq2UL7OGhEQAAG3MA References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" X-OriginalArrivalTime: 26 Apr 2012 15:34:23.0898 (UTC) FILETIME=[0E966FA0:01CD23C2] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.000 X-TM-AS-Result: No--13.617700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:34:38 -0000 > From: Henning Rogge [mailto:hrogge@googlemail.com] >=20 > On Thu, Apr 26, 2012 at 17:25, Rick Taylor > wrote: > > > > So, you are suggesting: > > > > 1) In the message-block and/or each address-block in the DLEP = message, > there is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) > The order TLV will be a Message-TLV... and there will be only one of > them in a DLEP message. >=20 > > 2) Every other TLV in the block refers to the order described by the > ORDER_TLV. > Every other TLV in the message (both message TLVs and address TLVs > refers to the order described in the Order TLV. >=20 > > 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is > discarded. > the message is discarded. >=20 +1 =20 I'm sold on this. Forget my bit-twiddling suggestions, this is much = simpler. Rick Taylor From Chris.Dearlove@baesystems.com Thu Apr 26 08:34:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3657421E80C7 for ; Thu, 26 Apr 2012 08:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9GmQLPKL9co for ; Thu, 26 Apr 2012 08:34:38 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id BB2D221E80C3 for ; Thu, 26 Apr 2012 08:34:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="234355002" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 16:34:37 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QFYaSw029912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 16:34:36 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 16:34:36 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: AQHNI5dtQS6Ej0n5skifyF6SVWSSeAABbj+wlq0VDoCAAABxAIAAAe2AgAADRYCAABEdIP//8cGAgAARMBA= Date: Thu, 26 Apr 2012 15:34:35 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:34:39 -0000 The way that 5444 allocation is defined, it's natural to pick a TLV type, w= hich automatically requires you get IANA to set up a registry for all 256 t= ype extensions. Define some, let a few be private/experimental at the end o= f the range, and pick a policy for allocation of the rest. Expert Review ma= y be good there, maintains some control (so they aren't all frivolously all= ocated) but doesn't require even an ID, let alone an RFC or full IESG appro= val. Then the initial DLEP specification can have a set you can get consens= us that they are a good idea. Note that there are radios that are used to carry IP packets that span half= a dozen orders of magnitude of user data rate. You might want more than on= e type extension there, and possibly elsewhere. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: 26 April 2012 16:23 To: Dearlove, Christopher (UK) Cc: Stan Ratliff; manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I think TX/RX current and maximum datarate are examples for "raw metrics" as opposed to the "dimensionless metric" TLV from OLSRv2. Other things I would like to have are Signal Strength, Radio Frequency (especially to reuse the TLV for the Request Link Characteristics order!) and maybe some layer-2 statistics that are difficult/impossible to get from the router. Henning On Thu, Apr 26, 2012 at 17:15, Dearlove, Christopher (UK) wrote: > I suggest first working out what the TLVs you want are, then considering = whether to make them message specific or global later. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Henning Rogge > Sent: 26 April 2012 16:13 > To: Stan Ratliff > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Thats why a "raw metric TLV" from the global namespace (both message > and address TLV) might be a good thing. It gives other protocols the > standardized tools to work with too. > > Henning Rogge > > On Thu, Apr 26, 2012 at 17:01, Stan Ratliff wrote: >> And in those cases, it's easy to fall prey to the notion that a certain >> piece of data (e.g. Maximum Data Rate) winds up being allocated from >> multiple number spaces. And that's a bad thing. >> >> Stan >> >> >> On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: >> >>> Even for links that are bandwidth constraint, using the context of the >>> message to see what the TLV is about is a better choice. Repeating the >>> order-number over and over for each TLV is just bad. >>> >>> Henning Rogge >>> >>> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff wrote: >>>> >>>> >>>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >>>> >>>>> Stan, >>>>> >>>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>>>> >>>>>> This shows one of the problems I'm having with "restructuring". Look= s >>>>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>>>> =A00x0101 Credit Window Status >>>>>>> >>>>>>> >>>>>>> 0x0201 Credit Window Status >>>>>> >>>>>> >>>>>> >>>>>>> 0x0501 Credit Window Status >>>>>> >>>>>> >>>>>> >>>>> >>>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message Type, >>>>> Lo-Byte is always 0x01 =3D Credit Window Status. >>>>> >>>>> TLV type indicates message (what Henning calls his Type TLV) >>>>> Extension types (lo-bytes) give Stan's Sub-TLV. =A0This is a more >>>>> efficient representation than Henning's, but carries the same >>>>> information. >>>>> >>>> >>>> Since the protocol is intended to *only* traverse the local (typically >>>> Ethernet) link between modem and local router, I admit that >>>> efficiency/compression wasn't one of the goals. As for simplicity, it >>>> seems >>>> easier to me to just pick the Type value up and directly feed it into >>>> state >>>> machinery instead of needing to perform some sort of "bit-level >>>> gymnastics" >>>> on it prior. >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 by >>>>> using extension types. >>>>> >>>>> Rick Taylor >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Thu Apr 26 08:41:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB0C21E80E8 for ; Thu, 26 Apr 2012 08:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54I9+vu0uY-E for ; Thu, 26 Apr 2012 08:41:18 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B90A821E80E3 for ; Thu, 26 Apr 2012 08:41:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="234357342" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 16:41:16 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QFfFpM002058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 16:41:15 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 16:41:15 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAACEzQAACg1hA= Date: Thu, 26 Apr 2012 15:41:14 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014 224A843C10C0 CCE92AC10378D111@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:41:19 -0000 If you are using DLEP under the multiplexing model defined in 5444 Appendix= A (non-normative there, but required by 5498 on manet port/protocol - whic= h I'm not clear if you are using) then DLEP doesn't own packets, and doesn'= t own the delivery of messages from the packet handler. What that means is = that it would be strongly advisable (at the least) for separate messages to= be able to be handled independently. Which may well be the case. Note that you do have the option of multiple address blocks, and nothing in= 5444 mandates anything about ordering. So it would be 5444 compatible (but= I'm not recommending it) to have N copies of a certain TLV in the message = TLV block and say the first copy relates to the first address block, the se= cond copy relates to the second address block etc. (If I'm not recommending= it, why am I mentioning it? Mainly just to point out that there is quite a= lot of freedom in 5444.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= ick Taylor Sent: 26 April 2012 16:25 To: Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- > From: Henning Rogge [mailto:hrogge@googlemail.com] >=20 > On Thu, Apr 26, 2012 at 17:12, Rick Taylor > wrote: > > That's exactly what I was trying to avoid. =A0I'm basically suggesting > > using the as the draft-02 , and the as > > Henning's Order-Number TLV value. >=20 > The question is WHY? >=20 I was trying to allow more than 1 order per message. But on reflection, on= e could just use more than 1 message per packet. So, you are suggesting: 1) In the message-block and/or each address-block in the DLEP message, ther= e is 1 ORDER_TLV. (Is this right for Address-Blocks?) 2) Every other TLV in the block refers to the order described by the ORDER_= TLV. 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is discard= ed. I think you might be convincing me...=20 Rick Taylor _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Thu Apr 26 08:43:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1C321E8089 for ; Thu, 26 Apr 2012 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyMIXmqaCiTT for ; Thu, 26 Apr 2012 08:43:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A38EB21E8032 for ; Thu, 26 Apr 2012 08:43:41 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so994845lbb.31 for ; Thu, 26 Apr 2012 08:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vjAluBqvZ7Bj7I2XWW7430Jkr6uhGbee1F5qkoP/Id0=; b=YcuPVHrn7nsG+hETThCa8vrHNa+UOv6N7Op100sq/7hO8oY8bddySfJABAHnbsJ2YJ 09MCgkfDp7yh6QOFyYkcqnQLXo6Oa9NJCRl0E21KB2k167/qrpTADDgn6hSgOIRQrx58 jBricXckulwakvLpQxKfdcc22cnrk8uA4uMu16sogK3O5HC63F0x0RAf2xgrFgzyYmV3 HEk1DWSXHSUrD0csi/F9TLIMp/bnTD/aHST43tM2o+raT+ATllLdx2Y0yUtvfvTY5qVV EvFCZSBMT1oEyWM+nuwZPzYRsC4el0f1n0Zn+yNG64dv+phozCzcqBWfa2DHqmec3Uvi TozA== Received: by 10.112.40.38 with SMTP id u6mr3455741lbk.97.1335455020277; Thu, 26 Apr 2012 08:43:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 08:43:19 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 17:43:19 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stan Ratliff , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:43:43 -0000 The RFC5444 writer API I am using is splitting up address blocks if it gets you a more compact compression. Doing it by hand can be difficult to tune... Henning On Thu, Apr 26, 2012 at 17:41, Dearlove, Christopher (UK) wrote: > If you are using DLEP under the multiplexing model defined in 5444 Append= ix A (non-normative there, but required by 5498 on manet port/protocol - wh= ich I'm not clear if you are using) then DLEP doesn't own packets, and does= n't own the delivery of messages from the packet handler. What that means i= s that it would be strongly advisable (at the least) for separate messages = to be able to be handled independently. Which may well be the case. > > Note that you do have the option of multiple address blocks, and nothing = in 5444 mandates anything about ordering. So it would be 5444 compatible (b= ut I'm not recommending it) to have N copies of a certain TLV in the messag= e TLV block and say the first copy relates to the first address block, the = second copy relates to the second address block etc. (If I'm not recommendi= ng it, why am I mentioning it? Mainly just to point out that there is quite= a lot of freedom in 5444.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Rick Taylor > Sent: 26 April 2012 16:25 > To: Henning Rogge > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> >> On Thu, Apr 26, 2012 at 17:12, Rick Taylor >> wrote: >> > That's exactly what I was trying to avoid. =A0I'm basically suggesting >> > using the as the draft-02 , and the as >> > Henning's Order-Number TLV value. >> >> The question is WHY? >> > > I was trying to allow more than 1 order per message. =A0But on reflection= , one could just use more than 1 message per packet. > > So, you are suggesting: > > 1) In the message-block and/or each address-block in the DLEP message, th= ere is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) > 2) Every other TLV in the block refers to the order described by the ORDE= R_TLV. > 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is disca= rded. > > I think you might be convincing me... > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Thu Apr 26 08:44:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C657321E80E3 for ; Thu, 26 Apr 2012 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6cH5JQUm-gA for ; Thu, 26 Apr 2012 08:44:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F2C0B21E80C0 for ; Thu, 26 Apr 2012 08:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2590; q=dns/txt; s=iport; t=1335455040; x=1336664640; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Ikice8gcFNj9d7AD6oAegBIABqVPaRus7OEPf1zvOrY=; b=YlPwpH/i8H0KcQUsgPFKfm81AAZ0tcDv4LkYOUy0wCBzP/7s/FDSKhbO OHnrt83vFgMG/3yMm53Ps6kBTkiEhNHvd7Ojn0VrNMN3omPR74PRFLgFA ppN0isIGJcldIFTDITJmLOrNynBWP9aBRCww2Yi20ayk//sYb2gnHUJ6E g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPZrmU+tJXG9/2dsb2JhbABEsWyBB4IJAQEBAwEBAQEPASUCNAsFCwsYLicwBhMih2YFC5pLoCoEkAJjBJV9jleBaYME X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78104515" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2012 15:43:59 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3QFhwnV031597; Thu, 26 Apr 2012 15:43:59 GMT Message-Id: <59096C32-A04D-4DEB-A7C8-3102C16EDCE1@cisco.com> From: Stan Ratliff To: Teco Boot In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 11:43:59 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> <6D11E177-199F-4FE1-ABE6-30A313FEF2E7@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 15:44:02 -0000 On Apr 26, 2012, at 11:32 AM, Teco Boot wrote: > > Op 26 apr. 2012, om 15:51 heeft Stan Ratliff het volgende geschreven: > >> >> On Apr 26, 2012, at 8:16 AM, Teco Boot wrote: >> >>> >>> Op 26 apr. 2012, om 11:46 heeft Rick Taylor het volgende geschreven: >>> >>>> Henning, >>>> >>>>> Just to make sure I understand you correctly... >>>>> >>>>> You mean that you do not want to use IPs as DLEP messages >>>>> addresses in >>>>> Address Blocks, right? >>>> >>>> Correct, I do not want to see them used there. >>>> >>>>> Its still okay to carry them in Address-Block TLVs, to bind them >>>>> to >>>> the >>>>> corresponding MAC address? >>>> >>>> Yes, as 'normal' TLVs, they can go wherever they are needed as >>>> currently >>>> specified in draft-02. >>>> >>>> As Teco says, layer 3 address TLVs should be optional. >>>> >>>> I agree with Stan that it is really useful to have Layer 3 >>>> addressing >>>> delivered via DLEP when the modem knows it, but there are >>>> examples where >>>> the modem does not know, but DLEP can still function. >>>> >>>> (I am using such a modem now, and I just ARP for the Layer 3 >>>> addresses, >>>> it's possible, but a PITA, particularly as InARP is largely >>>> unsupported >>>> in the real world). >>> >>> The .!!!!-problem is mainly caused by address resolving on non- >>> transit links. >>> On transit links, a good router populates forwarding tables when >>> there is >>> a data path set up. ARP/NDP is enough for this and additional time >>> required >>> for it is minor related to routing protocol convergence in many >>> cases. >>> >> >> Except that you inherently force a MANET into a single subnet in >> order for that to work. That's not the case in the networks I deploy. > > With IPv6 NDP this is not a problem. > With ARP, AFAIK Cisco routers do not permit address resolving over > different subnets. It is not a limitation of the ARP spec. But yes, > there are problems here. It was discussed in Autoconf. How is it > solved when not using DLEP? > WIthout DLEP, it's *not* solved. That is the point. Or rather, the point of including the address TLV's. Stan > Teco > >> >> Stan >> >> >>> Teco >>> >>>> Rick Taylor >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > From Chris.Dearlove@baesystems.com Thu Apr 26 09:13:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B0011E80A0 for ; Thu, 26 Apr 2012 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQZgCGtx4Gda for ; Thu, 26 Apr 2012 09:13:53 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 770E711E809A for ; Thu, 26 Apr 2012 09:13:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="234368685" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 17:13:51 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QGDotF025312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 17:13:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 17:13:51 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAACEzQAACg1hD///GggP//5/eA Date: Thu, 26 Apr 2012 16:13:49 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stan Ratliff , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:13:54 -0000 The intelligence of your 5444 formatter is a potential quality of implement= ation differentiator. I concentrate more on intelligent ordering than intel= ligent splitting (including whether to use single or multi value TLVs - or = both) but as you note, splitting can help . However if you know that you'll= never have more than 255 addresses in one "message" and you aren't that fu= ssed about efficiency, then you could split for other reasons. Just to be c= lear, neither NHDP nor OLSRv2 use splitting (or ordering) to carry informat= ion. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: 26 April 2012 16:43 To: Dearlove, Christopher (UK) Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- The RFC5444 writer API I am using is splitting up address blocks if it gets you a more compact compression. Doing it by hand can be difficult to tune... Henning On Thu, Apr 26, 2012 at 17:41, Dearlove, Christopher (UK) wrote: > If you are using DLEP under the multiplexing model defined in 5444 Append= ix A (non-normative there, but required by 5498 on manet port/protocol - wh= ich I'm not clear if you are using) then DLEP doesn't own packets, and does= n't own the delivery of messages from the packet handler. What that means i= s that it would be strongly advisable (at the least) for separate messages = to be able to be handled independently. Which may well be the case. > > Note that you do have the option of multiple address blocks, and nothing = in 5444 mandates anything about ordering. So it would be 5444 compatible (b= ut I'm not recommending it) to have N copies of a certain TLV in the messag= e TLV block and say the first copy relates to the first address block, the = second copy relates to the second address block etc. (If I'm not recommendi= ng it, why am I mentioning it? Mainly just to point out that there is quite= a lot of freedom in 5444.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Rick Taylor > Sent: 26 April 2012 16:25 > To: Henning Rogge > Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> >> On Thu, Apr 26, 2012 at 17:12, Rick Taylor >> wrote: >> > That's exactly what I was trying to avoid. =A0I'm basically suggesting >> > using the as the draft-02 , and the as >> > Henning's Order-Number TLV value. >> >> The question is WHY? >> > > I was trying to allow more than 1 order per message. =A0But on reflection= , one could just use more than 1 message per packet. > > So, you are suggesting: > > 1) In the message-block and/or each address-block in the DLEP message, th= ere is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) > 2) Every other TLV in the block refers to the order described by the ORDE= R_TLV. > 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is disca= rded. > > I think you might be convincing me... > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Thu Apr 26 09:18:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5205A21E8123 for ; Thu, 26 Apr 2012 09:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+AVuqKhMNvX for ; Thu, 26 Apr 2012 09:18:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D94B621E810A for ; Thu, 26 Apr 2012 09:18:45 -0700 (PDT) Received: by lagj5 with SMTP id j5so1184543lag.31 for ; Thu, 26 Apr 2012 09:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=iA+58zvD5oqX9ZetObV+oJM8xh34mjNaE9+W0VaVlwU=; b=zHYylYtzg0CqlmtWysGI67hiw53QR/lFZ4Bbl03EAMXbBT4ahgtEUixBhQiW5r4Qkz g3bpBeSK7FDdG9uoPdvWFNfAIhEJVDGsSNToSwnyapwgk8F/52mlW6HNOyvpcbn2D53B FpVtNuT0LHZMDel3CBP9afxXsQzembDJRF+Fc7W/+ujL2IlE8gtPwpJjMkXe4zzqBwTH /d/e7+Qkmydr2FmfGFg6sHpwJ0glnsMOl6A2TaJHVktw8FFbSkSYAjtvKwQfwsqitqL3 QUG0lz+1Fd0TeVPkyqOoZSNF1uPmYXqXEi2tdSDWRfX1vFgLPC4WPrEzPdF7Ir3b/Be9 kNCw== Received: by 10.152.124.76 with SMTP id mg12mr969338lab.6.1335457124766; Thu, 26 Apr 2012 09:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 09:18:24 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 18:18:24 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stan Ratliff , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:18:47 -0000 I don't think any sane protocol should use address block splitting to define a syntax. Its just a tool to allow for more flexible ways to write the addresses. My implementation does not switch the order of the TLVs (I assume that the implementation has most likely insider knowledge how to order them) and it does the whole splitting (and reading in the parser) in a transparent way. You never see it in the code. Henning On Thu, Apr 26, 2012 at 18:13, Dearlove, Christopher (UK) wrote: > The intelligence of your 5444 formatter is a potential quality of impleme= ntation differentiator. I concentrate more on intelligent ordering than int= elligent splitting (including whether to use single or multi value TLVs - o= r both) but as you note, splitting can help . However if you know that you'= ll never have more than 255 addresses in one "message" and you aren't that = fussed about efficiency, then you could split for other reasons. Just to be= clear, neither NHDP nor OLSRv2 use splitting (or ordering) to carry inform= ation. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 26 April 2012 16:43 > To: Dearlove, Christopher (UK) > Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > The RFC5444 writer API I am using is splitting up address blocks if it > gets you a more compact compression. Doing it by hand can be difficult > to tune... > > Henning > > On Thu, Apr 26, 2012 at 17:41, Dearlove, Christopher (UK) > wrote: >> If you are using DLEP under the multiplexing model defined in 5444 Appen= dix A (non-normative there, but required by 5498 on manet port/protocol - w= hich I'm not clear if you are using) then DLEP doesn't own packets, and doe= sn't own the delivery of messages from the packet handler. What that means = is that it would be strongly advisable (at the least) for separate messages= to be able to be handled independently. Which may well be the case. >> >> Note that you do have the option of multiple address blocks, and nothing= in 5444 mandates anything about ordering. So it would be 5444 compatible (= but I'm not recommending it) to have N copies of a certain TLV in the messa= ge TLV block and say the first copy relates to the first address block, the= second copy relates to the second address block etc. (If I'm not recommend= ing it, why am I mentioning it? Mainly just to point out that there is quit= e a lot of freedom in 5444.) >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Rick Taylor >> Sent: 26 April 2012 16:25 >> To: Henning Rogge >> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff >> Subject: Re: [manet] DLEP and TLV breakdown >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >>> From: Henning Rogge [mailto:hrogge@googlemail.com] >>> >>> On Thu, Apr 26, 2012 at 17:12, Rick Taylor >>> wrote: >>> > That's exactly what I was trying to avoid. =A0I'm basically suggestin= g >>> > using the as the draft-02 , and the a= s >>> > Henning's Order-Number TLV value. >>> >>> The question is WHY? >>> >> >> I was trying to allow more than 1 order per message. =A0But on reflectio= n, one could just use more than 1 message per packet. >> >> So, you are suggesting: >> >> 1) In the message-block and/or each address-block in the DLEP message, t= here is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) >> 2) Every other TLV in the block refers to the order described by the ORD= ER_TLV. >> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is disc= arded. >> >> I think you might be convincing me... >> >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From Chris.Dearlove@baesystems.com Thu Apr 26 09:29:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB621E80BA for ; Thu, 26 Apr 2012 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IUxB5o1cHZw for ; Thu, 26 Apr 2012 09:29:02 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 03DFF21E80A9 for ; Thu, 26 Apr 2012 09:29:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="234372329" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 26 Apr 2012 17:29:01 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3QGT0YC002310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Apr 2012 17:29:00 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 17:29:00 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAACEzQAACg1hD///GggP//5/eAgAAh1gD//+yqEA== Date: Thu, 26 Apr 2012 16:28:59 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stan Ratliff , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:29:03 -0000 I would regard address block splitting to define information as poor, but b= etter than separate messages with linkages between them (which is a lot wor= se than poor). Separate but independent messages is OK. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Henning Rogge [mailto:hrogge@googlemail.com]=20 Sent: 26 April 2012 17:18 To: Dearlove, Christopher (UK) Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I don't think any sane protocol should use address block splitting to define a syntax. Its just a tool to allow for more flexible ways to write the addresses. My implementation does not switch the order of the TLVs (I assume that the implementation has most likely insider knowledge how to order them) and it does the whole splitting (and reading in the parser) in a transparent way. You never see it in the code. Henning On Thu, Apr 26, 2012 at 18:13, Dearlove, Christopher (UK) wrote: > The intelligence of your 5444 formatter is a potential quality of impleme= ntation differentiator. I concentrate more on intelligent ordering than int= elligent splitting (including whether to use single or multi value TLVs - o= r both) but as you note, splitting can help . However if you know that you'= ll never have more than 255 addresses in one "message" and you aren't that = fussed about efficiency, then you could split for other reasons. Just to be= clear, neither NHDP nor OLSRv2 use splitting (or ordering) to carry inform= ation. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 26 April 2012 16:43 > To: Dearlove, Christopher (UK) > Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > The RFC5444 writer API I am using is splitting up address blocks if it > gets you a more compact compression. Doing it by hand can be difficult > to tune... > > Henning > > On Thu, Apr 26, 2012 at 17:41, Dearlove, Christopher (UK) > wrote: >> If you are using DLEP under the multiplexing model defined in 5444 Appen= dix A (non-normative there, but required by 5498 on manet port/protocol - w= hich I'm not clear if you are using) then DLEP doesn't own packets, and doe= sn't own the delivery of messages from the packet handler. What that means = is that it would be strongly advisable (at the least) for separate messages= to be able to be handled independently. Which may well be the case. >> >> Note that you do have the option of multiple address blocks, and nothing= in 5444 mandates anything about ordering. So it would be 5444 compatible (= but I'm not recommending it) to have N copies of a certain TLV in the messa= ge TLV block and say the first copy relates to the first address block, the= second copy relates to the second address block etc. (If I'm not recommend= ing it, why am I mentioning it? Mainly just to point out that there is quit= e a lot of freedom in 5444.) >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf O= f Rick Taylor >> Sent: 26 April 2012 16:25 >> To: Henning Rogge >> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff >> Subject: Re: [manet] DLEP and TLV breakdown >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >>> From: Henning Rogge [mailto:hrogge@googlemail.com] >>> >>> On Thu, Apr 26, 2012 at 17:12, Rick Taylor >>> wrote: >>> > That's exactly what I was trying to avoid. =A0I'm basically suggestin= g >>> > using the as the draft-02 , and the a= s >>> > Henning's Order-Number TLV value. >>> >>> The question is WHY? >>> >> >> I was trying to allow more than 1 order per message. =A0But on reflectio= n, one could just use more than 1 message per packet. >> >> So, you are suggesting: >> >> 1) In the message-block and/or each address-block in the DLEP message, t= here is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) >> 2) Every other TLV in the block refers to the order described by the ORD= ER_TLV. >> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is disc= arded. >> >> I think you might be convincing me... >> >> Rick Taylor >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Thu Apr 26 09:31:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEC121F86C8 for ; Thu, 26 Apr 2012 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md38fokrVxb9 for ; Thu, 26 Apr 2012 09:31:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5187821F86C6 for ; Thu, 26 Apr 2012 09:31:27 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so1037838lbb.31 for ; Thu, 26 Apr 2012 09:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=V1trEaFSOJBxSX35uw1Wbfh9YXRF2/Kr0moK3BV0U/g=; b=0W5ecw5QZWr8459Patc/Tmg5D2D+lVFMDKlol+VVrspX0Khypp+58cBSd9Ff3Ev65x Jp2c9OX0xgB4VPxVhjhXpq1Q9i8ELczD9C7foq03lDr+1U8D3RvtELi0VPWSfu6Dla0o qLT+TRLhWaFWwEzbkV0T4UhoT3Y6XCOrA7YUqyaEZ+0m1+MsWDnQ8mn/nEtl+1QeUKQw CAM9RAanhf5vjVbabj3glC0iafQ99lbr0eWSoyp9dt6w8JP0TYSp1x2u93QKnbUqRPEC cGwyr7yZ7TS2FWBfrd5GK4RmsenHIFkWnRrFvo6drshX1/xaiaWocpw0rZySzitnG8ko Hktg== Received: by 10.112.24.197 with SMTP id w5mr3659529lbf.83.1335457885709; Thu, 26 Apr 2012 09:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 09:31:05 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 18:31:05 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stan Ratliff , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:31:29 -0000 I totally agree. Henning On Thu, Apr 26, 2012 at 18:28, Dearlove, Christopher (UK) wrote: > I would regard address block splitting to define information as poor, but= better than separate messages with linkages between them (which is a lot w= orse than poor). Separate but independent messages is OK. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 26 April 2012 17:18 > To: Dearlove, Christopher (UK) > Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff > Subject: Re: [manet] DLEP and TLV breakdown > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > I don't think any sane protocol should use address block splitting to > define a syntax. Its just a tool to allow for more flexible ways to > write the addresses. > > My implementation does not switch the order of the TLVs (I assume that > the implementation has most likely insider knowledge how to order > them) and it does the whole splitting (and reading in the parser) in a > transparent way. You never see it in the code. > > Henning > > On Thu, Apr 26, 2012 at 18:13, Dearlove, Christopher (UK) > wrote: >> The intelligence of your 5444 formatter is a potential quality of implem= entation differentiator. I concentrate more on intelligent ordering than in= telligent splitting (including whether to use single or multi value TLVs - = or both) but as you note, splitting can help . However if you know that you= 'll never have more than 255 addresses in one "message" and you aren't that= fussed about efficiency, then you could split for other reasons. Just to b= e clear, neither NHDP nor OLSRv2 use splitting (or ordering) to carry infor= mation. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 26 April 2012 16:43 >> To: Dearlove, Christopher (UK) >> Cc: Rick Taylor; manet@ietf.org; Bo Berry; Stan Ratliff >> Subject: Re: [manet] DLEP and TLV breakdown >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> The RFC5444 writer API I am using is splitting up address blocks if it >> gets you a more compact compression. Doing it by hand can be difficult >> to tune... >> >> Henning >> >> On Thu, Apr 26, 2012 at 17:41, Dearlove, Christopher (UK) >> wrote: >>> If you are using DLEP under the multiplexing model defined in 5444 Appe= ndix A (non-normative there, but required by 5498 on manet port/protocol - = which I'm not clear if you are using) then DLEP doesn't own packets, and do= esn't own the delivery of messages from the packet handler. What that means= is that it would be strongly advisable (at the least) for separate message= s to be able to be handled independently. Which may well be the case. >>> >>> Note that you do have the option of multiple address blocks, and nothin= g in 5444 mandates anything about ordering. So it would be 5444 compatible = (but I'm not recommending it) to have N copies of a certain TLV in the mess= age TLV block and say the first copy relates to the first address block, th= e second copy relates to the second address block etc. (If I'm not recommen= ding it, why am I mentioning it? Mainly just to point out that there is qui= te a lot of freedom in 5444.) >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Rick Taylor >>> Sent: 26 April 2012 16:25 >>> To: Henning Rogge >>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry; Stan Ratliff >>> Subject: Re: [manet] DLEP and TLV breakdown >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>>> From: Henning Rogge [mailto:hrogge@googlemail.com] >>>> >>>> On Thu, Apr 26, 2012 at 17:12, Rick Taylor >>>> wrote: >>>> > That's exactly what I was trying to avoid. =A0I'm basically suggesti= ng >>>> > using the as the draft-02 , and the = as >>>> > Henning's Order-Number TLV value. >>>> >>>> The question is WHY? >>>> >>> >>> I was trying to allow more than 1 order per message. =A0But on reflecti= on, one could just use more than 1 message per packet. >>> >>> So, you are suggesting: >>> >>> 1) In the message-block and/or each address-block in the DLEP message, = there is 1 ORDER_TLV. =A0(Is this right for Address-Blocks?) >>> 2) Every other TLV in the block refers to the order described by the OR= DER_TLV. >>> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is dis= carded. >>> >>> I think you might be convincing me... >>> >>> Rick Taylor >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Thu Apr 26 11:10:50 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AE821F8718 for ; Thu, 26 Apr 2012 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PjzqvIW5FII for ; Thu, 26 Apr 2012 11:10:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6521F86DE for ; Thu, 26 Apr 2012 11:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1751; q=dns/txt; s=iport; t=1335463849; x=1336673449; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=T6YVkwabfmeg9fbH+1Nx3QOgSRu9YmqJrHQgrqBoqo0=; b=e+rPHz3uJ3pLONgsVnRwxsCWfsb6lmiSRRNiEMA5TpNI679YygmUUKbV Myl6iR3Efy+9n0Jml5oa1rRn/8hq5EMS2Nmmcn2pGe+wv3B4bYHgu4fcq 8bPAgPWpYkSxSmxgu6gSmdk0QdXiEF+EVEnNwC6Nf7aT04dsKTysjs0ED I=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78188197" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 26 Apr 2012 18:10:49 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3QIAlp8012965; Thu, 26 Apr 2012 18:10:47 GMT Message-Id: From: Stan Ratliff To: Rick Taylor In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:10:47 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:10:50 -0000 I'm glad *some of us* are sold... ;-) I still can't get past the notion that this approach requires the allocation of a TLV into TWO number spaces. All of the address and metric TLV's can currently exist at the Peer (radio-wide) level, AND for an individual neighbor. As I understand the proposal, Peer level traffic (Peer Discovery, Peer Offer, Peer Update) would be encoded as 5444 message TLV's. Neighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor Down) would be referencing a specific neighbor, therefore, it would be address TLV's... So, we'd have to create TWO registries (one for DLEP message TLV's, another for DLEP address TLV's), and make sure at least metrics and addresses are in BOTH of them. I'm sorry, but that's just silly to me. Stan On Apr 26, 2012, at 11:34 AM, Rick Taylor wrote: >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> >> On Thu, Apr 26, 2012 at 17:25, Rick Taylor >> >> wrote: >>> >>> So, you are suggesting: >>> >>> 1) In the message-block and/or each address-block in the DLEP >>> message, >> there is 1 ORDER_TLV. (Is this right for Address-Blocks?) >> The order TLV will be a Message-TLV... and there will be only one of >> them in a DLEP message. >> >>> 2) Every other TLV in the block refers to the order described by the >> ORDER_TLV. >> Every other TLV in the message (both message TLVs and address TLVs >> refers to the order described in the Order TLV. >> >>> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is >> discarded. >> the message is discarded. >> > > +1 > > I'm sold on this. Forget my bit-twiddling suggestions, this is much > simpler. > > Rick Taylor From hrogge@googlemail.com Thu Apr 26 11:19:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B847721E80F2 for ; Thu, 26 Apr 2012 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixlG7lENQlaP for ; Thu, 26 Apr 2012 11:19:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 811E621E80A1 for ; Thu, 26 Apr 2012 11:19:24 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so1122350lbb.31 for ; Thu, 26 Apr 2012 11:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n7KgKPc3mFlWf0xQpoDbE3O1h/q4pgI2ancgz5tTCds=; b=S4Xy963wxJU20tLDws8KA02bYeXERm3ByD7eeIDd3E9buCmhNNoRpHi0eSGQUMyM8I C/Gzj04AUiHkbRcL0kfCH62vSx1cMK3K1FEhl8C4zIroWllg/jbw8sH1VYKFZzGbJcLW +WiPyGqngHXkQ0UOmSx/xlvQsQikDFLmk5VFWWyzlz+nXOUnYouEnC6FWz5dbe6C80b+ kMAsU5ihfoSAQWDTxVuAC/KXQkMY5L6BJqQMDMNVTvHuVh/aya9LuJqhrvTxLdMLbFpA iWj917ziyZyGK162jIjSJgkl/b3vBPsLWs6NvKKjwRXTHQhjhFlkTltrnkLSEKNIWWJ6 tJzQ== Received: by 10.152.135.104 with SMTP id pr8mr7483526lab.27.1335464363307; Thu, 26 Apr 2012 11:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 11:19:03 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Thu, 26 Apr 2012 20:19:03 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:19:25 -0000 On Thu, Apr 26, 2012 at 20:10, Stan Ratliff wrote: > I'm glad *some of us* are sold... ;-) > > I still can't get past the notion that this approach requires the allocation > of a TLV into TWO number spaces. All of the address and metric TLV's can > currently exist at the Peer (radio-wide) level, AND for an individual > neighbor. As I understand the proposal, Peer level traffic (Peer Discovery, > Peer Offer, Peer Update) would be encoded as 5444 message TLV's. > Neighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor Down) > would be referencing a specific neighbor, therefore, it would be address > TLV's... Yes. So what? > So, we'd have to create TWO registries (one for DLEP message TLV's, another > for DLEP address TLV's), and make sure at least metrics and addresses are in > BOTH of them. I'm sorry, but that's just silly to me. Its common stuff in the IETF, for example with RFC 5444 involved. Its reasonable to have this kind of TLVs for routing protocols that are layer-2 aware. If we go (as Christopher suggested some time ago) the way of a "specific metric" TLV, you could have one message TLV for the metrics, one address TLV for them... and use the same extension type registry for them. Some other TLVs might even be useful for the global address space. If we have a TLV for attaching an address of different length to an existing address in RFC 5444, I could see this quite useful for a dual-stack OLSRv2 implementation. A similar thing is true for the 'Maximum Link speed' TLV, this could be quite useful in multi-topology routing to choose paths for high-bandwidth links. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Thu Apr 26 11:29:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE55E21E80D9 for ; Thu, 26 Apr 2012 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFHicvL2mxNn for ; Thu, 26 Apr 2012 11:29:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5D21E813C for ; Thu, 26 Apr 2012 11:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2342; q=dns/txt; s=iport; t=1335464997; x=1336674597; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=bdkoGbQ7MJXwpwDUoYsiYQanw4AvTkJvJOkPvdkql38=; b=dJYoSd6wo2O9SskThLy84jl9z+gzgFQkLVNFl7wFmhwdjYbYnVUwHJIM KkvsYFbrG40eK6EmZEfVEN5X1XJOuCah3PIkRRlXuEi5G2NAmO5BvWE2i Do8EezwDXLCeby10/js7JuAbYfe0bEv87uRVAJrksc96McKrp5fxCarwn E=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78196509" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Apr 2012 18:29:56 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3QITudA029454; Thu, 26 Apr 2012 18:29:56 GMT Message-Id: <0B7A195D-95A3-4960-AB83-48CD73ED7D2B@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:29:56 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:29:58 -0000 On Apr 26, 2012, at 2:19 PM, Henning Rogge wrote: > On Thu, Apr 26, 2012 at 20:10, Stan Ratliff > wrote: >> I'm glad *some of us* are sold... ;-) >> >> I still can't get past the notion that this approach requires the >> allocation >> of a TLV into TWO number spaces. All of the address and metric >> TLV's can >> currently exist at the Peer (radio-wide) level, AND for an individual >> neighbor. As I understand the proposal, Peer level traffic (Peer >> Discovery, >> Peer Offer, Peer Update) would be encoded as 5444 message TLV's. >> Neighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor >> Down) >> would be referencing a specific neighbor, therefore, it would be >> address >> TLV's... > > Yes. So what? So what? You want to put the same TLV in 2 different registries, then tell me that's simpler? > >> So, we'd have to create TWO registries (one for DLEP message TLV's, >> another >> for DLEP address TLV's), and make sure at least metrics and >> addresses are in >> BOTH of them. I'm sorry, but that's just silly to me. > > Its common stuff in the IETF, for example with RFC 5444 involved. Its > reasonable to have this kind of TLVs for routing protocols that are > layer-2 aware. > No, I haven't seen this as a "common" approach. It's a bad idea. Stan > If we go (as Christopher suggested some time ago) the way of a > "specific metric" TLV, you could have one message TLV for the metrics, > one address TLV for them... and use the same extension type registry > for them. > > Some other TLVs might even be useful for the global address space. If > we have a TLV for attaching an address of different length to an > existing address in RFC 5444, I could see this quite useful for a > dual-stack OLSRv2 implementation. A similar thing is true for the > 'Maximum Link speed' TLV, this could be quite useful in multi-topology > routing to choose paths for high-bandwidth links. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Apr 26 11:30:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58C121E8142 for ; Thu, 26 Apr 2012 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8knmUNynY5R for ; Thu, 26 Apr 2012 11:30:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77E21E8143 for ; Thu, 26 Apr 2012 11:30:44 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so22660pbb.31 for ; Thu, 26 Apr 2012 11:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SwvTIA9uB00mFqBWua97S3u3tKlq3D3PLDeWHhFTncc=; b=HsJaxZ4mAdIkJ7F7wCRkVRdMgvBq5cZbndfcAQFK1kC1tXrjm2Nahltdar3li1+ZQQ NzNdk7+ncq56RckNfhlG9mwt4gPBNaRKaH5pFmFjTmYCT16If3GdUR4ROQ5jijETNTE5 WFKb2kaho71EdIDeAq8DsX4T/T075RA/vTPgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SwvTIA9uB00mFqBWua97S3u3tKlq3D3PLDeWHhFTncc=; b=mo8SX41kcJMYBf8oHjQRCWM1xrZfPdEVHyhtV6d6wTaBLgiR3wEclGEiOVLC5lGgrm WwiTqFoNDH+MWiNjyfRyLWqXGxbS2SMORpZSrtWMImr4Yo3fwAjEH7lXqPMrHC2c7nSG qwAk9VZ2JqLqkiiv0JHPerjmvayerCTYLQYm+eM9AAKlk+J4eetlSZe+rH/xXSrSCerm vTxc2iBElB79MY6eQoLxRP92WprCBhWCbCT1BNKeNpuB16hTRCb5oNiXKjn1HmdCj6E6 0gqiCccTLkTbpRA0p0bKtDoUvOThXKvkzPMbNA2K0ybqLTPTZ2qp2ZqIc+1IPaKF65Z3 m4EA== MIME-Version: 1.0 Received: by 10.68.233.167 with SMTP id tx7mr5752792pbc.50.1335465044038; Thu, 26 Apr 2012 11:30:44 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Thu, 26 Apr 2012 11:30:43 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> Date: Thu, 26 Apr 2012 11:30:43 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=047d7b33d9be8f52b204be992fe1 X-Gm-Message-State: ALoCoQnXrTizjDeAPZmWTfyfOawQgH4w9yE+RvbcYE0RkxBP2oeqf4cqvzv5j62FhGeNB3iTs6eE Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:30:47 -0000 --047d7b33d9be8f52b204be992fe1 Content-Type: text/plain; charset=ISO-8859-1 Stan, On Thu, Apr 26, 2012 at 11:10 AM, Stan Ratliff wrote: > I'm glad *some of us* are sold... ;-) > > I still can't get past the notion that this approach requires the > allocation of a TLV into TWO number spaces. All of the address and metric > TLV's can currently exist at the Peer (radio-wide) level, AND for an > individual neighbor. As I understand the proposal, Peer level traffic (Peer > Discovery, Peer Offer, Peer Update) would be encoded as 5444 message TLV's. > Neighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor Down) > would be referencing a specific neighbor, therefore, it would be address > TLV's... > > So, we'd have to create TWO registries (one for DLEP message TLV's, > another for DLEP address TLV's), and make sure at least metrics and > addresses are in BOTH of them. I'm sorry, but that's just silly to me. > Yes, that is exactly what we did for all the other drafts/RFCs in MANET, for example, for the packetbb-sec RFC-to-be. I think it is wise to use the same TLV types for packet/message/address-block TLVs. Setting up registries is trivial and does not complicate code. Regards Ulrich --047d7b33d9be8f52b204be992fe1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stan,

On Thu, = Apr 26, 2012 at 11:10 AM, Stan Ratliff <sratliff@cisco.com>= wrote:
I'm glad *some of us* are sold... ;-)
I still can't get past the notion that this approach requires the alloc= ation of a TLV into TWO number spaces. All of the address and metric TLV= 9;s can currently exist at the Peer (radio-wide) level, AND for an individu= al neighbor. As I understand the proposal, Peer level traffic (Peer Discove= ry, Peer Offer, Peer Update) would be encoded as 5444 message TLV's. Ne= ighbor-specific traffic (Neighbor Up, Neighbor Update, Neighbor Down) would= be referencing a specific neighbor, therefore, it would be address TLV'= ;s...

So, we'd have to create TWO registries (one for DLEP message TLV's,= another for DLEP address TLV's), and make sure at least metrics and ad= dresses are in BOTH of them. I'm sorry, but that's just silly to me= .



Yes, that is exactly what we di= d for all the other drafts/RFCs in MANET,=A0 for example, for the packetbb-= sec RFC-to-be. I think it is wise to use the same TLV types for packet/mess= age/address-block TLVs. Setting up registries is trivial and does not compl= icate code.

Regards
Ulrich



--047d7b33d9be8f52b204be992fe1-- From sratliff@cisco.com Thu Apr 26 11:32:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B4721E8148 for ; Thu, 26 Apr 2012 11:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQH-cc6wLuA8 for ; Thu, 26 Apr 2012 11:32:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6111E80A1 for ; Thu, 26 Apr 2012 11:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4326; q=dns/txt; s=iport; t=1335465159; x=1336674759; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=fFc6CzUaMi1kT/pnXrrAodfVdwDjAyMyufPFTqCo67E=; b=mTQNRZthV+2yGbzvZ0gbHzCUl8ElLlE4gtjRQt1RanYOn2mEwDDU/ev3 F+p76E+So/heD5WpiL5ti9Yv/38Kbr/cSPFlOxicc/5UNfI4WU23VFWcK 5029o28nFg/5Cn90XLHS+9MIv/r1bfV3WXIugrs7gZGo27iybJ2C2iXEb 0=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208,217";a="78162735" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2012 18:32:39 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3QIWcv9020080; Thu, 26 Apr 2012 18:32:39 GMT Message-Id: <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> From: Stan Ratliff To: Ulrich Herberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-10-675673621 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:32:39 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:32:40 -0000 --Apple-Mail-10-675673621 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 26, 2012, at 2:30 PM, Ulrich Herberg wrote: > Stan, > > On Thu, Apr 26, 2012 at 11:10 AM, Stan Ratliff > wrote: > I'm glad *some of us* are sold... ;-) > > I still can't get past the notion that this approach requires the > allocation of a TLV into TWO number spaces. All of the address and > metric TLV's can currently exist at the Peer (radio-wide) level, AND > for an individual neighbor. As I understand the proposal, Peer level > traffic (Peer Discovery, Peer Offer, Peer Update) would be encoded > as 5444 message TLV's. Neighbor-specific traffic (Neighbor Up, > Neighbor Update, Neighbor Down) would be referencing a specific > neighbor, therefore, it would be address TLV's... > > So, we'd have to create TWO registries (one for DLEP message TLV's, > another for DLEP address TLV's), and make sure at least metrics and > addresses are in BOTH of them. I'm sorry, but that's just silly to me. > > > > Yes, that is exactly what we did for all the other drafts/RFCs in > MANET, for example, for the packetbb-sec RFC-to-be. I think it is > wise to use the same TLV types for packet/message/address-block > TLVs. Setting up registries is trivial and does not complicate code. > I disagree - it does complicate things. Both code-wise, and administratively. The fact that it's been done before means little to me. Stan > Regards > Ulrich > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-10-675673621 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Apr 26, 2012, = at 2:30 PM, Ulrich Herberg wrote:

Stan,

On Thu, = Apr 26, 2012 at 11:10 AM, Stan Ratliff <sratliff@cisco.com> wrote:
=
I'm glad *some of us* = are sold... ;-)

I still can't get past the notion that this = approach requires the allocation of a TLV into TWO number spaces. All of = the address and metric TLV's can currently exist at the Peer = (radio-wide) level, AND for an individual neighbor. As I understand the = proposal, Peer level traffic (Peer Discovery, Peer Offer, Peer Update) = would be encoded as 5444 message TLV's. Neighbor-specific traffic = (Neighbor Up, Neighbor Update, Neighbor Down) would be referencing a = specific neighbor, therefore, it would be address TLV's...

So, = we'd have to create TWO registries (one for DLEP message TLV's, another = for DLEP address TLV's), and make sure at least metrics and addresses = are in BOTH of them. I'm sorry, but that's just silly to me.
=



Yes, that is exactly what we = did for all the other drafts/RFCs in MANET,  for example, for the = packetbb-sec RFC-to-be. I think it is wise to use the same TLV types for = packet/message/address-block TLVs. Setting up registries is trivial and = does not complicate code.
=

I disagree - it = does complicate things. Both code-wise, and administratively. The fact = that it's been done before means little to = me.

Stan


Regards
Ulrich



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

= --Apple-Mail-10-675673621-- From ulrich@herberg.name Thu Apr 26 11:35:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8682121E815A for ; Thu, 26 Apr 2012 11:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThKZU7keQxHF for ; Thu, 26 Apr 2012 11:35:29 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0E21E8158 for ; Thu, 26 Apr 2012 11:35:29 -0700 (PDT) Received: by dady13 with SMTP id y13so2978927dad.27 for ; Thu, 26 Apr 2012 11:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RHVuzp8B9xruU/PCemgPGgd7hN3YPKwhd923u6BfEsQ=; b=JqqpDetpVcMKmLYY65ZQDsKSWNQOziDoROCaH6zezZowcbCiMH6xEhlUJa21H+yjgH bBB+vVbGwd3ZJNiyyXpSXdQAGCLVg0nXBOqyfvFIkFc5/sxBHJVL8QPx/PUNxTqS2+P6 1HpiBhntPrSuufwnSjCs1nA7LLahqmNAG59Fs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RHVuzp8B9xruU/PCemgPGgd7hN3YPKwhd923u6BfEsQ=; b=kwfimED7sxTCsWmPnVNAqOwN7lveVsEfPffuoXGRCSK3KdbsXCI69lzHj4+1Nhmf6Q /rkcG3P3jzJNuStYMGuZDYwFz7X6Mdmia/ULxq1UeQ0jH2Sp8NjZ/r/AnsVQ9BaGgZK2 8kVHX5WpLKNf9BrO0qZywrZYNKpvo4IWjJ5ovG2xLR9IyDA5rdj8Nt6gypsM3Km1yfZw lf8+rtq3J6ZHLLLdzQap3iUK6wz3fMHdjjPcx8/xOCKzUsPAy4r2WMp2tIbDQi6Xfxb6 CQ+X0eJdGuWghUIHIDjlkuCZnVsu/qpCyrgsyRxlbnHPYQGUam28HCqZKKYFoWNSpZUA bYfw== MIME-Version: 1.0 Received: by 10.68.213.71 with SMTP id nq7mr6516509pbc.84.1335465329459; Thu, 26 Apr 2012 11:35:29 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Thu, 26 Apr 2012 11:35:29 -0700 (PDT) In-Reply-To: <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> Date: Thu, 26 Apr 2012 11:35:29 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=e89a8ff1c40c92832b04be994055 X-Gm-Message-State: ALoCoQnyPR2fgFYsASJmQBJ+anGtuu14hB0CwJ0ivetuN9v7DMHfoVKwpv71JexUmzlu2V8H/e7Q Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:35:30 -0000 --e89a8ff1c40c92832b04be994055 Content-Type: text/plain; charset=ISO-8859-1 Stan, why should it complicate things? Have a look at the MANET regsitry: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I hope they will be for packetbb-sec ;-), there is no more code complexity. I have implemented the different TLVs only once. Regards Ulrich On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote: > > > > Yes, that is exactly what we did for all the other drafts/RFCs in MANET, > for example, for the packetbb-sec RFC-to-be. I think it is wise to use the > same TLV types for packet/message/address-block TLVs. Setting up registries > is trivial and does not complicate code. > > > I disagree - it does complicate things. Both code-wise, and > administratively. The fact that it's been done before means little to me. > > Stan > > > Regards > Ulrich > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --e89a8ff1c40c92832b04be994055 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stan,

why should it complicate things? Ha= ve a look at the MANET regsitry:
http://www.i= ana.org/assignments/manet-parameters/manet-parameters.xml#message-type-rang= es

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and T= IMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP= /OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I= hope they will be for packetbb-sec ;-), there is no more code complexity. = I have implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 201= 2 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:
=



Yes, that is exactly what we did for all the other drafts/RFCs i= n MANET,=A0 for example, for the packetbb-sec RFC-to-be. I think it is wise= to use the same TLV types for packet/message/address-block TLVs. Setting u= p registries is trivial and does not complicate code.


I disag= ree - it does complicate things. Both code-wise, and administratively. The = fact that it's been done before means little to me.

Stan


Regards
Ulrich



____________________________________= ___________
manet mailing list
m= anet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--e89a8ff1c40c92832b04be994055-- From hrogge@googlemail.com Thu Apr 26 11:36:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442BA21F866C for ; Thu, 26 Apr 2012 11:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTUfT3lxl8-S for ; Thu, 26 Apr 2012 11:36:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8292421F8595 for ; Thu, 26 Apr 2012 11:36:55 -0700 (PDT) Received: by lagj5 with SMTP id j5so1295846lag.31 for ; Thu, 26 Apr 2012 11:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MS5W6oRq3dVi1raAi/kbcQe9svL2yNdCKx2rU5oZx3Q=; b=I2T3yKqikZSAnF1JCxRwbHuals4O+HNYEUZ2cGAPL26AkYJJIIIF73y9p04Xp3TrJ7 BDpyQycWJD4rJjqbDi9MtmGeAIEQsY+u6i7qUXJOOPKrZhU71SAGIkykjbgAYGRMSBKP L0/eWMp6y3dn2VI/MJHpAc4j0jsB0oi2zZY0DIJG4/Ia99+QEu0ZZWhymfNzHh2anVaR IHaMef7Q1T96AQc26sV3a2Gt9Xvv5WJ5ZB4I9NsxnM/0ETUKM6wTckYW/QTaf+poMxCp q0ZJzI7myz8IpNqYb3E3YkMQUWiyQV/DKKZ1hMzI+ql1Fsh17TTyVdH8s0cZ2wwAarNQ AbpA== Received: by 10.112.9.130 with SMTP id z2mr68879lba.83.1335465414449; Thu, 26 Apr 2012 11:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 11:36:34 -0700 (PDT) In-Reply-To: <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> From: Henning Rogge Date: Thu, 26 Apr 2012 20:36:34 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:36:56 -0000 There is a reason why IANA always allocated the same code value for both address and message TLVs where they applied to both. I think they will keep doing so, because it keeps things easy. It seems no problem for writing the drafts (as you can see in the existing drafts) and I know from personal experience it does NOT complicate the code of your program. So where is your problem? Henning On Thu, Apr 26, 2012 at 20:32, Stan Ratliff wrote: > I disagree - it does complicate things. Both code-wise, and > administratively. The fact that it's been done before means little to me. > > Stan -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Thu Apr 26 11:37:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBB621E8167 for ; Thu, 26 Apr 2012 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq0zdcqs0B+p for ; Thu, 26 Apr 2012 11:37:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACF6A21E8166 for ; Thu, 26 Apr 2012 11:37:22 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so28773pbb.31 for ; Thu, 26 Apr 2012 11:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cf8l/QOxxhKPldFCKFpCr/wlCPHDqWY2jKL/rX70XwY=; b=Gdo8DltGdKBqMu0s8fQZYE9rFRFM/pPXzfIFxwkVvNE7uivUO/iLWJZIfNFaNnBI9f w4Qynhbbyab4KBZFYM2PYiFKMYRLpXhHnWw5QRTuChxNBs4bHfAKQ3HPdtc4PxMXb1jZ ZR7pGk03NB5J6ZUUaGxRpc7vGAjLGN6RV35NY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Cf8l/QOxxhKPldFCKFpCr/wlCPHDqWY2jKL/rX70XwY=; b=DbXY17iw08d1o63MbQTyvcIB1jQbndjvJziF+gbAApP6IOSS6U6UIqb5zSWYyg3bYr HmRvYfMRbv9KshALU++i6bbZOJs19i+O4nLicH/MRM+Jo/gGWaYJsi86BQElosc0WQ7Q rBfFYquFPdFBsuR8pN3KDfgNPKaBv2aG3ErfnNXDXoh2CGgjH1Q4tj64PPdeyLilLEuj KGq3lPqcTl8R7KAUTP6UHiawZ6abKMOebdvAn7j+UKREW72CTpwQNC6tjeNd2vJ0I9rj 7GgRnWmFYQMtlAiq+O8TKzZjVFB8X8hKpQ6ciymKeaxYVGIMw6eaGrJIMYQqJDKUTraQ l33Q== MIME-Version: 1.0 Received: by 10.68.239.37 with SMTP id vp5mr610063pbc.137.1335465442436; Thu, 26 Apr 2012 11:37:22 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Thu, 26 Apr 2012 11:37:22 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> Date: Thu, 26 Apr 2012 11:37:22 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=047d7b33daf84e672a04be994778 X-Gm-Message-State: ALoCoQkWhD0+SV0HUnHyeNj8HtdwsltSxKN1ao5UKSFBsxO3f6MTGj+tGxvlzB2RPkKOjtXVFPnV Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:37:23 -0000 --047d7b33daf84e672a04be994778 Content-Type: text/plain; charset=ISO-8859-1 P.S. Administratively, that is trivial. Just an email to IANA once the draft is in the RFC Editor Queue. We are going through that process right now with packetbb-sec. On Thu, Apr 26, 2012 at 11:35 AM, Ulrich Herberg wrote: > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and > TIMESTAMP TLVs as message and as address block TLVs. I have implemented > NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same > (which I hope they will be for packetbb-sec ;-), there is no more code > complexity. I have implemented the different TLVs only once. > > Regards > Ulrich > > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote: > >> >> >> >> Yes, that is exactly what we did for all the other drafts/RFCs in MANET, >> for example, for the packetbb-sec RFC-to-be. I think it is wise to use the >> same TLV types for packet/message/address-block TLVs. Setting up registries >> is trivial and does not complicate code. >> >> >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little to me. >> >> Stan >> >> >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > --047d7b33daf84e672a04be994778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
P.S. Administratively, that is trivial. Just an = email to IANA once the draft is in the RFC Editor Queue. We are going throu= gh that process right now with packetbb-sec.

On Thu, Apr 26, 2012 at 11:35 AM, Ulrich Herberg <ulrich@herberg.name> wrote:
Stan,

why should it complicate things? Ha= ve a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/manet-parameters.xml= #message-type-ranges

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and T= IMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP= /OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I= hope they will be for packetbb-sec ;-), there is no more code complexity. = I have implemented the different TLVs only once.

Regards
Ulrich=


On Thu, Apr 26,= 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:=



Ye= s, that is exactly what we did for all the other drafts/RFCs in MANET,=A0 f= or example, for the packetbb-sec RFC-to-be. I think it is wise to use the s= ame TLV types for packet/message/address-block TLVs. Setting up registries = is trivial and does not complicate code.


I disag= ree - it does complicate things. Both code-wise, and administratively. The = fact that it's been done before means little to me.

Stan


Regards
Ulrich



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



--047d7b33daf84e672a04be994778-- From sratliff@cisco.com Thu Apr 26 11:52:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B611C21E80C8 for ; Thu, 26 Apr 2012 11:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32wrL7BIgpru for ; Thu, 26 Apr 2012 11:52:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8421E80CC for ; Thu, 26 Apr 2012 11:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4752; q=dns/txt; s=iport; t=1335466369; x=1336675969; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=5/hQtmqA924Teg4HYViFC7SX81y3DkzGXNyg5DbT7HE=; b=lunUhF2luEp7CF7Bj7pJ6FA6DTdcmc7jJbVCGl6u4fbh3clCO1lCskJE Enqr0JBQ5efxhYeBn3bzEMaViJn6QIzmDEKDEgAW4GlxAeKkjCrIXPHxu zOPl8A9XymTcwqgjoWHR2qwp8vxT+Plb8pdEpTvpMw+11ZkELZdhr0d86 4=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208,217";a="78216545" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Apr 2012 18:52:45 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3QIqiuX022075; Thu, 26 Apr 2012 18:52:44 GMT Message-Id: <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> From: Stan Ratliff To: Ulrich Herberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11-676879411 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:52:44 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:52:49 -0000 --Apple-Mail-11-676879411 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Why does it complicate things? As you said - "Assuming that the TLV types are the same..." Not only now, but on down the line if/when we want to add TLVs? You can guarantee that will always be the case? Stan On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV > and TIMESTAMP TLVs as message and as address block TLVs. I have > implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV > types are the same (which I hope they will be for packetbb-sec ;-), > there is no more code complexity. I have implemented the different > TLVs only once. > > Regards > Ulrich > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff > wrote: > > >> >> Yes, that is exactly what we did for all the other drafts/RFCs in >> MANET, for example, for the packetbb-sec RFC-to-be. I think it is >> wise to use the same TLV types for packet/message/address-block >> TLVs. Setting up registries is trivial and does not complicate code. >> > > I disagree - it does complicate things. Both code-wise, and > administratively. The fact that it's been done before means little > to me. > > Stan > > >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --Apple-Mail-11-676879411 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Why does it complicate = things? 
As you said - "Assuming that the TLV types are the = same..."  Not only now, but on down the line if/when we want to add = TLVs? You can guarantee that will always be the = case?

Stan

On Apr 26, = 2012, at 2:35 PM, Ulrich Herberg wrote:

Stan,

why should it complicate things? Have = a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/= manet-parameters.xml#message-type-ranges

We have = VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP = TLVs as message and as address block TLVs. I have implemented = NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same = (which I hope they will be for packetbb-sec ;-), there is no more code = complexity. I have implemented the different TLVs only once.
=
Regards
Ulrich

On Thu, Apr 26, = 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> = wrote:



Yes, that is exactly what we did for all = the other drafts/RFCs in MANET,  for example, for the packetbb-sec = RFC-to-be. I think it is wise to use the same TLV types for = packet/message/address-block TLVs. Setting up registries is trivial and = does not complicate code.
=

I = disagree - it does complicate things. Both code-wise, and = administratively. The fact that it's been done before means little to = me.

Stan


Regards
Ulrich



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



= = --Apple-Mail-11-676879411-- From sratliff@cisco.com Thu Apr 26 11:54:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89A21E814F for ; Thu, 26 Apr 2012 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG1S0423xlRr for ; Thu, 26 Apr 2012 11:54:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B164521E8175 for ; Thu, 26 Apr 2012 11:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1377; q=dns/txt; s=iport; t=1335466477; x=1336676077; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=SJyT6ahUf5HHqYPpsWdL2X/XJLzaiWBDcJIU/cT9rf0=; b=KR+SHq7qTX7G0LbdcFc7kc/PtJ7P3jP0DTjTXqYIqCQ8/E0mNBEdmkJY JNTBKWxjVb8qX5ZTMWgYf+Yx7h+spDx/AIzhsp/PTlGyjZg/W3n9agfCd QNe8G6fW34KlII5n/TgdebpF4raXthJ3BK6/XrJGuqxw0D9lNNWmHwm1p 8=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78169985" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2012 18:54:37 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q3QIsaAL003803; Thu, 26 Apr 2012 18:54:36 GMT Message-Id: From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:54:36 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:54:38 -0000 On Apr 26, 2012, at 2:36 PM, Henning Rogge wrote: > There is a reason why IANA always allocated the same code value for > both address and message TLVs where they applied to both. I think they > will keep doing so, because it keeps things easy. > > It seems no problem for writing the drafts (as you can see in the > existing drafts) and I know from personal experience it does NOT > complicate the code of your program. > > So where is your problem? See the earlier response to Ulrich. Multiple allocations in multiple number spaces is a bad idea. The fact that it has been done before doesn't help me - by extension, I could use that same argument to say "People have successfully shop-lifted before. Ergo, shop-lifting is OK." Doesn't work for me. Stan > > Henning > > On Thu, Apr 26, 2012 at 20:32, Stan Ratliff > wrote: >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little >> to me. >> >> Stan > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Thu Apr 26 11:56:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B44121F85F0 for ; Thu, 26 Apr 2012 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBF0-i+n3iVG for ; Thu, 26 Apr 2012 11:56:17 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C017121F85D8 for ; Thu, 26 Apr 2012 11:56:16 -0700 (PDT) Received: by lagj5 with SMTP id j5so1310411lag.31 for ; Thu, 26 Apr 2012 11:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4CpaKTZs4e/hdzrPfS+R+tk2tIeyg7g+e8GZlyD09n8=; b=x1XwOtLXplG/L2E1/oeNwy6mMR5c2BdIh9YyPmzeeuFNKOwfXCKNGQxzq/z4kgmz/3 WTZPxj6hc1RYtRSPv81Odkzp4ENiqlTgq93+8gQNZOknmFZABTO1cM6224EQCiSejaxB 3A9wtirMU4w6azhqIAW/ID4FItHhRrd0gaPwzmt3iFf3WC2UrOxHckm3nnqvHLVqFyC+ 3hG/C5ZNH+vXKIKDHrIOVYxeapmXipnPnlpMt0ryrMGTMGdzqbdsWUTtsKOkeeE77PZO 9cDepC7BQCOdxksY194vJyuNRHntHclGnViuKf7rbhLcZMeeVqs9Q0FwIjgxICQnC3By ZxCQ== Received: by 10.112.47.170 with SMTP id e10mr3884508lbn.69.1335466571173; Thu, 26 Apr 2012 11:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 11:55:49 -0700 (PDT) In-Reply-To: <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> From: Henning Rogge Date: Thu, 26 Apr 2012 20:55:49 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:56:18 -0000 Adding something proprietary like "subtlvs" is a lot worse. Its an additional dimension for the registries and for the parser/generator. Henning Rogge On Thu, Apr 26, 2012 at 20:52, Stan Ratliff wrote: > Why does it complicate things? > As you said - "Assuming that the TLV types are the same..." =A0Not only n= ow, > but on down the line if/when we want to add TLVs? You can guarantee that > will always be the case? > > Stan > > On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#mes= sage-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and > TIMESTAMP TLVs as message and as address block TLVs. I have implemented > NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same > (which I hope they will be for packetbb-sec ;-), there is no more code > complexity. I have implemented the different TLVs only once. > > Regards > Ulrich > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote= : >> >> >> >> >> Yes, that is exactly what we did for all the other drafts/RFCs in MANET, >> for example, for the packetbb-sec RFC-to-be. I think it is wise to use t= he >> same TLV types for packet/message/address-block TLVs. Setting up registr= ies >> is trivial and does not complicate code. >> >> >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little to me= . >> >> Stan >> >> >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From sratliff@cisco.com Thu Apr 26 11:57:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF3621E80F2 for ; Thu, 26 Apr 2012 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6RcV3MY01FJ for ; Thu, 26 Apr 2012 11:57:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AE10C21E8050 for ; Thu, 26 Apr 2012 11:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4675; q=dns/txt; s=iport; t=1335466629; x=1336676229; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=AMBd54OWHO/JhnsIJAX2UCF4KDXqSoYSiU30yYdXQuQ=; b=WcWAMIx6rNKULVx+2oSIsJnOIMxVqKGnJh4RHHfCaPgEwG/ADnoAt2+k q50/GHQMjK/gVgq3uvCpEGmWaYe7HaMvW/9fn3dWWgzMvW2ELtEY4oHIN +m7tg1njy+GIYGH0cxL6viK+FgZpcbCjDTJOMm6mZtlUfyGYZrSA/5JLO w=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208,217";a="78170701" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 26 Apr 2012 18:57:09 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QIv8Sm003777; Thu, 26 Apr 2012 18:57:09 GMT Message-Id: From: Stan Ratliff To: Ulrich Herberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-12-677143671 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:57:09 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:57:11 -0000 --Apple-Mail-12-677143671 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit BTW - according to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs have different type values for packet/message/address TLVs. How does that simplify things? Stan On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV > and TIMESTAMP TLVs as message and as address block TLVs. I have > implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV > types are the same (which I hope they will be for packetbb-sec ;-), > there is no more code complexity. I have implemented the different > TLVs only once. > > Regards > Ulrich > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff > wrote: > > >> >> Yes, that is exactly what we did for all the other drafts/RFCs in >> MANET, for example, for the packetbb-sec RFC-to-be. I think it is >> wise to use the same TLV types for packet/message/address-block >> TLVs. Setting up registries is trivial and does not complicate code. >> > > I disagree - it does complicate things. Both code-wise, and > administratively. The fact that it's been done before means little > to me. > > Stan > > >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > --Apple-Mail-12-677143671 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable BTW - according to a quick read = by one of my co-authors, , ICV and TIMESTAMP TLVs have = different type values for packet/message/address TLVs. How does that = simplify things?

Stan

On Apr = 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

Stan,

why should it complicate things? Have = a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/= manet-parameters.xml#message-type-ranges

We have = VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP = TLVs as message and as address block TLVs. I have implemented = NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same = (which I hope they will be for packetbb-sec ;-), there is no more code = complexity. I have implemented the different TLVs only once.
=
Regards
Ulrich

On Thu, Apr 26, = 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> = wrote:



Yes, that is exactly what we did for all = the other drafts/RFCs in MANET,  for example, for the packetbb-sec = RFC-to-be. I think it is wise to use the same TLV types for = packet/message/address-block TLVs. Setting up registries is trivial and = does not complicate code.
=

I = disagree - it does complicate things. Both code-wise, and = administratively. The fact that it's been done before means little to = me.

Stan


Regards
Ulrich



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



= = --Apple-Mail-12-677143671-- From sratliff@cisco.com Thu Apr 26 11:58:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8E21E8136 for ; Thu, 26 Apr 2012 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX0+ei23cbcQ for ; Thu, 26 Apr 2012 11:58:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 05B2521E8131 for ; Thu, 26 Apr 2012 11:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2543; q=dns/txt; s=iport; t=1335466713; x=1336676313; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kmtxLT5ZGjepok/fccCyMWFkhO6arwgOKlejbJmAHUw=; b=d778rHUeIpqZZFdiLp/YgmfvpZEp+MGfQbSlhEeOvxturduqkV4yDx4H atzk4vJDBsDSHJhOkZ141b3r+H+oSGM/IsZrhYLLLI4aM7au+Nu8KVvRv NAU7ntgHcns15x3LkfvatJYfAU/OUA8LMS4b7GNVcmYMFcALfi0oRwztX A=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="78207012" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2012 18:58:32 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3QIwWIc012741; Thu, 26 Apr 2012 18:58:32 GMT Message-Id: <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> From: Stan Ratliff To: Henning Rogge In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 14:58:32 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:58:33 -0000 And I guess that's the crux of the subjective crossroads we find ourselves at. At least with the sub-TLV's, you always know that CDR is CDR, because it's only defined once. Stan On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote: > Adding something proprietary like "subtlvs" is a lot worse. Its an > additional dimension for the registries and for the parser/generator. > > Henning Rogge > > On Thu, Apr 26, 2012 at 20:52, Stan Ratliff > wrote: >> Why does it complicate things? >> As you said - "Assuming that the TLV types are the same..." Not >> only now, >> but on down the line if/when we want to add TLVs? You can guarantee >> that >> will always be the case? >> >> Stan >> >> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >> >> Stan, >> >> why should it complicate things? Have a look at the MANET regsitry: >> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges >> >> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and >> TIMESTAMP TLVs as message and as address block TLVs. I have >> implemented >> NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the >> same >> (which I hope they will be for packetbb-sec ;-), there is no more >> code >> complexity. I have implemented the different TLVs only once. >> >> Regards >> Ulrich >> >> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff >> wrote: >>> >>> >>> >>> >>> Yes, that is exactly what we did for all the other drafts/RFCs in >>> MANET, >>> for example, for the packetbb-sec RFC-to-be. I think it is wise to >>> use the >>> same TLV types for packet/message/address-block TLVs. Setting up >>> registries >>> is trivial and does not complicate code. >>> >>> >>> I disagree - it does complicate things. Both code-wise, and >>> administratively. The fact that it's been done before means little >>> to me. >>> >>> Stan >>> >>> >>> Regards >>> Ulrich >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From ulrich@herberg.name Thu Apr 26 12:01:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48A921E8221 for ; Thu, 26 Apr 2012 12:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuMVuqd4Tchs for ; Thu, 26 Apr 2012 12:01:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD621F8475 for ; Thu, 26 Apr 2012 12:00:56 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so50445pbb.31 for ; Thu, 26 Apr 2012 12:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M4PuLal5GEu/grisoZH07jn5mVObNeI/Nc2xxKezwLA=; b=DAAv84W/ysCUIq4VMlrAiyfTsivFAd4klzYEkgCJhz/j/Fjp1VkC/WPHGbYp3J/SPv X/oD1Tjk3tgLVEYXmqgjm2bEnMudzbRRnaFeRzfevnmL32QO1ZF3sC5YXJQbbI8tDXST ZDrSW3ORaGy4pENjOI8yp2JyfnMIogjAB5zuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=M4PuLal5GEu/grisoZH07jn5mVObNeI/Nc2xxKezwLA=; b=oteLFTrcO+EmNmzd/Km+fyrqQPDMUGmOu14hkH9qVEqT6nVSi8JnH+hyfv36MgwfKc j7td1uyIUmvUP0q7jdSh3nLIcvTieA8O5qI7Pynk+j/gmJ7UzrimZqBP4LNDw3GaI5Z8 Sjv3ZiF2YH0yjrrd/cJEfYKJASKvmZJ3z62aPDJciXtU4xyYiqEl/EZzN/wcbe4097FV //gtEBvSf7jglYIBoXJHpyOrXh11wpRmmIDpPkRg/ZD3IMHjgkDWECf1nhhKeWdNpjwl mdISiZhAIEUnJeR4rmW9NdfmRhGWegmN4RPudOfEtAhX7nOgX7b5wOiKgE4XjllvgqDs C8kQ== MIME-Version: 1.0 Received: by 10.68.189.1 with SMTP id ge1mr10579225pbc.19.1335466856326; Thu, 26 Apr 2012 12:00:56 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Thu, 26 Apr 2012 12:00:56 -0700 (PDT) In-Reply-To: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> Date: Thu, 26 Apr 2012 12:00:56 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=e89a8ff1c3f294a76204be999b1e X-Gm-Message-State: ALoCoQngdKbpJC6+tHSrnpbXMpcY31PEmI8uTTp0res4VWbf/XX7Qqw7ypM0dbiA8n9OkdG3ZGUY Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:01:10 -0000 --e89a8ff1c3f294a76204be999b1e Content-Type: text/plain; charset=ISO-8859-1 Stan, I think you should have been in CC of some mails between the authors of packetbb-sec and IANA. I suggested to IANA to use the same values instead. They requested confirmation by the chairs. The registration process for packetbb-sec is not yet finished, so that can still be changed. Regards Ulrich On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff wrote: > BTW - according to a quick read by one of my co-authors, , ICV and > TIMESTAMP TLVs have different type values for packet/message/address TLVs. > How does that simplify things? > > Stan > > On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and > TIMESTAMP TLVs as message and as address block TLVs. I have implemented > NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same > (which I hope they will be for packetbb-sec ;-), there is no more code > complexity. I have implemented the different TLVs only once. > > Regards > Ulrich > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote: > >> >> >> >> Yes, that is exactly what we did for all the other drafts/RFCs in MANET, >> for example, for the packetbb-sec RFC-to-be. I think it is wise to use the >> same TLV types for packet/message/address-block TLVs. Setting up registries >> is trivial and does not complicate code. >> >> >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little to me. >> >> Stan >> >> >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > > --e89a8ff1c3f294a76204be999b1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stan,

I think you should have been in CC = of some mails between the authors of packetbb-sec and IANA. I suggested to = IANA to use the same values instead. They requested confirmation by the cha= irs. The registration process for packetbb-sec is not yet finished, so that= can still be changed.

Regards
Ulrich



On Thu, Apr= 26, 2012 at 11:57 AM, Stan Ratliff <sratliff@cisco.com> wr= ote:
BTW - ac= cording to a quick read by one of my co-authors, ,=A0ICV and TIMESTAMP TLVs= =A0have different type values for packet/message/address TLVs. How does tha= t simplify things?

Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

Stan,
why should it complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/ma= net-parameters/manet-parameters.xml#message-type-ranges

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and = TIMESTAMP TLVs as message and as address block TLVs. I have implemented NHD= P/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which = I hope they will be for packetbb-sec ;-), there is no more code complexity.= I have implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 20= 12 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:



Y= es, that is exactly what we did for all the other drafts/RFCs in MANET,=A0 = for example, for the packetbb-sec RFC-to-be. I think it is wise to use the = same TLV types for packet/message/address-block TLVs. Setting up registries= is trivial and does not complicate code.


I disag= ree - it does complicate things. Both code-wise, and administratively. The = fact that it's been done before means little to me.

Stan


Regards
Ulrich


<= /div>

_______________________________________________<= br> manet mailing list
= manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet




--e89a8ff1c3f294a76204be999b1e-- From hrogge@googlemail.com Thu Apr 26 12:02:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A21821F8575 for ; Thu, 26 Apr 2012 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+BW9EBBGjek for ; Thu, 26 Apr 2012 12:02:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA221F854A for ; Thu, 26 Apr 2012 12:02:40 -0700 (PDT) Received: by lagj5 with SMTP id j5so1314429lag.31 for ; Thu, 26 Apr 2012 12:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=GW06tqI1LbxWbLAVV1FR89CZimCNf77ztq3hPKmw6Yo=; b=DaNXG+OI7tCExxI9M+zAxPwJXq18HTqcvBiQmwgPOl6+f3pSjcrIMptM51UPXIpKZF /3X6HnrYvif7nBeP8TLzoYUdZZ1fzOIyB9qw2uqKwzXkd4euAAvRWvZ5azN+WE9WxcJl AFfJXvvtfnYZjROOg26gSmG9y558oq7gl7h4PDCjmR/S+RWjRcUI1HUuG1ghCUyXV8At CE+mjpndr4YZYisGx9++96H7fmmzd+stKIk+QJaRbPbfiMzBRV9AOCD0W1wuBoa4yWdA YXzXeH3BQ9aKrF4ex2h8R4sAMusKIffyCScFID04Zt/jbuViV3j0p82V6T8WA9wEc4K5 FdNg== Received: by 10.152.124.76 with SMTP id mg12mr1511834lab.6.1335466959868; Thu, 26 Apr 2012 12:02:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Thu, 26 Apr 2012 12:02:19 -0700 (PDT) In-Reply-To: <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> From: Henning Rogge Date: Thu, 26 Apr 2012 21:02:19 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:02:42 -0000 The problem is that SubTLVs are the start of duplicating things. Because if we define useful TLVs as subtlvs, we cannot reuse them elsewhere. But I think thats not even the important point. We did quite a lot of work to get RFC5444 to the current state, and now we don't want to use it because of the registries involved? Whats the use of a generic and flexible packet format if protocols start using it just as a wrapper for proprietary stuff? Henning Rogge On Thu, Apr 26, 2012 at 20:58, Stan Ratliff wrote: > And I guess that's the crux of the subjective crossroads we find ourselve= s > at. At least with the sub-TLV's, you always know that CDR is CDR, because > it's only defined once. > > Stan > > > On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote: > >> Adding something proprietary like "subtlvs" is a lot worse. Its an >> additional dimension for the registries and for the parser/generator. >> >> Henning Rogge >> >> On Thu, Apr 26, 2012 at 20:52, Stan Ratliff wrote: >>> >>> Why does it complicate things? >>> As you said - "Assuming that the TLV types are the same..." =A0Not only >>> now, >>> but on down the line if/when we want to add TLVs? You can guarantee tha= t >>> will always be the case? >>> >>> Stan >>> >>> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >>> >>> Stan, >>> >>> why should it complicate things? Have a look at the MANET regsitry: >>> >>> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#m= essage-type-ranges >>> >>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and >>> TIMESTAMP TLVs as message and as address block TLVs. I have implemented >>> NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same >>> (which I hope they will be for packetbb-sec ;-), there is no more code >>> complexity. I have implemented the different TLVs only once. >>> >>> Regards >>> Ulrich >>> >>> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff >>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> Yes, that is exactly what we did for all the other drafts/RFCs in MANE= T, >>>> for example, for the packetbb-sec RFC-to-be. I think it is wise to use >>>> the >>>> same TLV types for packet/message/address-block TLVs. Setting up >>>> registries >>>> is trivial and does not complicate code. >>>> >>>> >>>> I disagree - it does complicate things. Both code-wise, and >>>> administratively. The fact that it's been done before means little to >>>> me. >>>> >>>> Stan >>>> >>>> >>>> Regards >>>> Ulrich >>>> >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." > > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Thu Apr 26 12:03:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62B221F844B for ; Thu, 26 Apr 2012 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0vd30hiZLet for ; Thu, 26 Apr 2012 12:03:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E832A21F84EE for ; Thu, 26 Apr 2012 12:03:42 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so52988pbb.31 for ; Thu, 26 Apr 2012 12:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pWggFpAhfG354MPhZahgrw/TNDji+EWXBOF8hmzd3Bo=; b=CkPDc0Xerv26DnNotB+2iM7LZfHF0OlkI59FyDZEMBJ5kcrBYPjpFJFOwXnMuD2Ni9 nUCxPrcBNg4yO1VPsM9DgN2KryCB8NVBSPQbDNtJYxRj83ON768nt0lkw9Ble2AvOJOi K3LEp+hPnTJnAda/lGkKPJmvZ1cfYlifvay3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pWggFpAhfG354MPhZahgrw/TNDji+EWXBOF8hmzd3Bo=; b=S/WNCVxZBpmrw75FRP1p6tT76i12oLzHqYPA7A0zXxVokNUqR4Gun/Ek3o3dmo4Xph Y3+YTfVjv11xWBBTV3DjFTyUOnShr6kZSzZ1jX2rADEMAfYaeItZKXdqIVW8YLBTwJxd l07B7/aIQ3I+dICiZiA24rHqLXv40lU8/8gG9midH7vpKVB3rBtcnKwoIwgiiYqseNRT jRQjvkdZU8W6CxKEWLEXbf0SdAeJlUQxS/M2nRkCoLHP1qYCH87cZAYf9vv4FMFwFxlW aqwcqPjNCtzjNKb/I0004PuJMc+Df38uyG+iYcLI1u0E8ASUlcDSGk15Uoai38h/6+uA nXTw== MIME-Version: 1.0 Received: by 10.68.239.37 with SMTP id vp5mr756492pbc.137.1335467022640; Thu, 26 Apr 2012 12:03:42 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Thu, 26 Apr 2012 12:03:42 -0700 (PDT) In-Reply-To: <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> Date: Thu, 26 Apr 2012 12:03:42 -0700 Message-ID: From: Ulrich Herberg To: Stan Ratliff Content-Type: multipart/alternative; boundary=047d7b33daf87e670b04be99a5a8 X-Gm-Message-State: ALoCoQmcAMV8lNIciH5B/dXI5GxwBiLf+rtGMhVvHgvRjsRI+Xgtfnh/E+ckUd1nbYpMtSoT/Tj4 Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:03:44 -0000 --047d7b33daf87e670b04be99a5a8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 26, 2012 at 11:52 AM, Stan Ratliff wrote: > Why does it complicate things? > As you said - "Assuming that the TLV types are the same..." Not only now, > but on down the line if/when we want to add TLVs? You can guarantee that > will always be the case? > I cannot guarantee that. But IANA / an Expert Review can and should do that. If we wanted to change the way of the message / address block TLV registrations, we would need to obsolete or update RFC5444 and all RFCs based on it. Best regards Ulrich > > Stan > > On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > > Stan, > > why should it complicate things? Have a look at the MANET regsitry: > > http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges > > We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and > TIMESTAMP TLVs as message and as address block TLVs. I have implemented > NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same > (which I hope they will be for packetbb-sec ;-), there is no more code > complexity. I have implemented the different TLVs only once. > > Regards > Ulrich > > On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote: > >> >> >> >> Yes, that is exactly what we did for all the other drafts/RFCs in MANET, >> for example, for the packetbb-sec RFC-to-be. I think it is wise to use the >> same TLV types for packet/message/address-block TLVs. Setting up registries >> is trivial and does not complicate code. >> >> >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little to me. >> >> Stan >> >> >> Regards >> Ulrich >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> > > --047d7b33daf87e670b04be99a5a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 2= 6, 2012 at 11:52 AM, Stan Ratliff <sratliff@cisco.com> wrot= e:
Why does it complicate things?=A0
A= s you said - "Assuming that the TLV types are the same..." =A0Not= only now, but on down the line if/when we want to add TLVs? You can guaran= tee that will always be the case?

I cannot guarantee that. But IANA / an Expert R= eview can and should do that. If we wanted to change the way of the message= / address block TLV registrations, we would need to obsolete or update RFC= 5444 and all RFCs based on it.

Best regards
Ulrich


=A0

Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

Stan,

why should it comp= licate things? Have a look at the MANET regsitry:
http://www.iana.org/assignment= s/manet-parameters/manet-parameters.xml#message-type-ranges

We = have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAM= P TLVs as message and as address block TLVs. I have implemented NHDP/OLSRv2= and packetbb-sec. Assuming that the TLV types are the same (which I hope t= hey will be for packetbb-sec ;-), there is no more code complexity. I have = implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 20= 12 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:



Y= es, that is exactly what we did for all the other drafts/RFCs in MANET,=A0 = for example, for the packetbb-sec RFC-to-be. I think it is wise to use the = same TLV types for packet/message/address-block TLVs. Setting up registries= is trivial and does not complicate code.


I disag= ree - it does complicate things. Both code-wise, and administratively. The = fact that it's been done before means little to me.

Stan


Regards
Ulrich


<= /div>

_______________________________________________<= br> manet mailing list
= manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet



=
--047d7b33daf87e670b04be99a5a8-- From sratliff@cisco.com Thu Apr 26 12:06:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3C21E8136 for ; Thu, 26 Apr 2012 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXN0wzRB+JTR for ; Thu, 26 Apr 2012 12:06:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B905721E80D1 for ; Thu, 26 Apr 2012 12:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6723; q=dns/txt; s=iport; t=1335467195; x=1336676795; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=7WOP5YAXqypQFRy+bvbNrmIIzTCZjnytccqiBkhzL9g=; b=E81RCwSHnRK7cGigtar2LCg4i6xMt3CA9JwgeB1+2KphS3gmYNs3R2I+ sNh18kcpEuS8/hmXndWNVn56oAJ1wtEDbTpjJGiECQ94YTuyISTMc0jCp S9JtAntc9wE7V3/lC3QP+iFwZ0O+3FACj8vyN9OiFZmI5G9WvgODaK8Ne U=; X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208,217";a="78221076" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 26 Apr 2012 19:06:34 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3QJ6XjH022714; Thu, 26 Apr 2012 19:06:34 GMT Message-Id: <2E4A2099-1FB9-407A-8C22-F224DEBBD8CF@cisco.com> From: Stan Ratliff To: Ulrich Herberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-13-677708691 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Apr 2012 15:06:34 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:06:36 -0000 --Apple-Mail-13-677708691 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ulrich, JMO, but that just makes my point - this is "easier"? Having to check & double-check to make sure some poor individual in IANA gets the allocations matched up correctly? Stan On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote: > Stan, > > I think you should have been in CC of some mails between the authors > of packetbb-sec and IANA. I suggested to IANA to use the same values > instead. They requested confirmation by the chairs. The registration > process for packetbb-sec is not yet finished, so that can still be > changed. > > Regards > Ulrich > > > > On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff > wrote: > BTW - according to a quick read by one of my co-authors, , ICV and > TIMESTAMP TLVs have different type values for packet/message/address > TLVs. How does that simplify things? > > Stan > > On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: > >> Stan, >> >> why should it complicate things? Have a look at the MANET regsitry: >> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges >> >> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV >> and TIMESTAMP TLVs as message and as address block TLVs. I have >> implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV >> types are the same (which I hope they will be for packetbb-sec ;-), >> there is no more code complexity. I have implemented the different >> TLVs only once. >> >> Regards >> Ulrich >> >> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff >> wrote: >> >> >>> >>> Yes, that is exactly what we did for all the other drafts/RFCs in >>> MANET, for example, for the packetbb-sec RFC-to-be. I think it is >>> wise to use the same TLV types for packet/message/address-block >>> TLVs. Setting up registries is trivial and does not complicate code. >>> >> >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little >> to me. >> >> Stan >> >> >>> Regards >>> Ulrich >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> > > --Apple-Mail-13-677708691 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Stan

On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote:

Stan,

I think you should have been in CC of = some mails between the authors of packetbb-sec and IANA. I suggested to = IANA to use the same values instead. They requested confirmation by the = chairs. The registration process for packetbb-sec is not yet finished, = so that can still be changed.
=
Regards
Ulrich



On Thu, = Apr 26, 2012 at 11:57 AM, Stan Ratliff <sratliff@cisco.com> wrote:
=
BTW - according to a quick read by one of = my co-authors, , ICV and TIMESTAMP TLVs have different type = values for packet/message/address TLVs. How does that simplify = things?
=
Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg = wrote:

Stan,

why should it = complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/manet-p= arameters.xml#message-type-ranges

We have VALIDITY_TIME and = INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message = and as address block TLVs. I have implemented NHDP/OLSRv2 and = packetbb-sec. Assuming that the TLV types are the same (which I hope = they will be for packetbb-sec ;-), there is no more code complexity. I = have implemented the different TLVs only once.
=
Regards
Ulrich

On Thu, Apr 26, = 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> = wrote:



Yes, that is exactly what we did for all = the other drafts/RFCs in MANET,  for example, for the packetbb-sec = RFC-to-be. I think it is wise to use the same TLV types for = packet/message/address-block TLVs. Setting up registries is trivial and = does not complicate code.
=

I = disagree - it does complicate things. Both code-wise, and = administratively. The fact that it's been done before means little to = me.

Stan


Regards
Ulrich



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





= --Apple-Mail-13-677708691-- From ietf@thomasclausen.org Thu Apr 26 14:02:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953F811E8073 for ; Thu, 26 Apr 2012 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+lauJHUFYuQ for ; Thu, 26 Apr 2012 14:02:01 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A0A5D21F86B8 for ; Thu, 26 Apr 2012 14:02:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 94418557F88 for ; Thu, 26 Apr 2012 14:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 75F5B1BD8F1A; Thu, 26 Apr 2012 14:02:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.249] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8FCB51BD8F0C; Thu, 26 Apr 2012 14:02:00 -0700 (PDT) References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6BA91A12-E4FF-4637-B254-F2B444813AFA Message-Id: <805A4958-853A-4C14-8CC6-68424081B404@thomasclausen.org> X-Mailer: iPad Mail (9B176) From: Thomas Heide Clausen Date: Thu, 26 Apr 2012 23:02:09 +0200 To: Ulrich Herberg Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 21:02:02 -0000 --Apple-Mail-6BA91A12-E4FF-4637-B254-F2B444813AFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Actually, I think that it's more precise to say that we've requested that IA= NA allocate the same values for the same mnemonics, and that they're waiting= for the designated experts (which, currently, is the WG chairs) to OK that.= In the interest of seeing packetbb-sec move ahead, would it be possible to g= et you to OK that request to IANA? Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 26 Apr 2012, at 21:00, Ulrich Herberg wrote: > Stan, >=20 > I think you should have been in CC of some mails between the authors of pa= cketbb-sec and IANA. I suggested to IANA to use the same values instead. The= y requested confirmation by the chairs. The registration process for packetb= b-sec is not yet finished, so that can still be changed. >=20 > Regards > Ulrich >=20 >=20 >=20 > On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff wrote:= > BTW - according to a quick read by one of my co-authors, , ICV and TIMESTA= MP TLVs have different type values for packet/message/address TLVs. How does= that simplify things? >=20 > Stan >=20 > On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >=20 >> Stan, >>=20 >> why should it complicate things? Have a look at the MANET regsitry: >> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#mes= sage-type-ranges >>=20 >> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIM= ESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/OL= SRv2 and packetbb-sec. Assuming that the TLV types are the same (which I hop= e they will be for packetbb-sec ;-), there is no more code complexity. I hav= e implemented the different TLVs only once. >>=20 >> Regards >> Ulrich >>=20 >> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrote= : >>=20 >>=20 >>>=20 >>> Yes, that is exactly what we did for all the other drafts/RFCs in MANET,= for example, for the packetbb-sec RFC-to-be. I think it is wise to use the= same TLV types for packet/message/address-block TLVs. Setting up registries= is trivial and does not complicate code. >>>=20 >>=20 >> I disagree - it does complicate things. Both code-wise, and administrativ= ely. The fact that it's been done before means little to me. >>=20 >> Stan >>=20 >>=20 >>> Regards >>> Ulrich >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-6BA91A12-E4FF-4637-B254-F2B444813AFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Actually, I think that it'= s more precise to say that we've requested that IANA allocate the same value= s for the same mnemonics, and that they're waiting for the designated expert= s (which, currently, is the WG chairs) to OK that.

In the interest of= seeing packetbb-sec move ahead, would it be possible to get you to OK that r= equest to IANA?

Best,

Thom= as

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetin= gs are held to
 discuss it."
   -- Mitche= ll's Law of Committees


On 26 Apr 20= 12, at 21:00, Ulrich Herberg <ulri= ch@herberg.name> wrote:

Stan,

I think you should have be= en in CC of some mails between the authors of packetbb-sec and IANA. I sugge= sted to IANA to use the same values instead. They requested confirmation by t= he chairs. The registration process for packetbb-sec is not yet finished, so= that can still be changed.

Regards
Ulrich



On Thu, Apr 2= 6, 2012 at 11:57 AM, Stan Ratliff <sratliff@cisco.com> wrote:=
BTW - acco= rding to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs=  have different type values for packet/message/address TLVs. How does t= hat simplify things?

Stan

= On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

Stan,
why should it complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/manet= -parameters/manet-parameters.xml#message-type-ranges

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and T= IMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/= OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I h= ope they will be for packetbb-sec ;-), there is no more code complexity. I h= ave implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 201= 2 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:



Yes= , that is exactly what we did for all the other drafts/RFCs in MANET,  f= or example, for the packetbb-sec RFC-to-be. I think it is wise to use the sa= me TLV types for packet/message/address-block TLVs. Setting up registries is= trivial and does not complicate code.


I disagr= ee - it does complicate things. Both code-wise, and administratively. The fa= ct that it's been done before means little to me.

Stan


Regards
Ulrich



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




____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-6BA91A12-E4FF-4637-B254-F2B444813AFA-- From thomas@thomasclausen.org Thu Apr 26 14:13:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65C11E80A1 for ; Thu, 26 Apr 2012 14:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqy3jMmEG7Tf for ; Thu, 26 Apr 2012 14:13:33 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6C211E8073 for ; Thu, 26 Apr 2012 14:13:33 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 5052A557F5E for ; Thu, 26 Apr 2012 14:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0E3181C08FC; Thu, 26 Apr 2012 14:13:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.249] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5B4AB1C01AF; Thu, 26 Apr 2012 14:13:32 -0700 (PDT) References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <2E4A2099-1FB9-407A-8C22-F224DEBBD8CF@cisco.com> In-Reply-To: <2E4A2099-1FB9-407A-8C22-F224DEBBD8CF@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-E3B900A2-2C22-4C24-90C9-28183FF92134 Message-Id: <4A4F3F42-8D33-422F-BDF4-4ED33DBC0F0D@thomasclausen.org> X-Mailer: iPad Mail (9B176) From: Thomas Heide Clausen Date: Thu, 26 Apr 2012 23:13:41 +0200 To: Stan Ratliff Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 21:13:34 -0000 --Apple-Mail-E3B900A2-2C22-4C24-90C9-28183FF92134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stan, I'm not Ulrich, but I am one of the authors of RFC5444. In RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are different e= ntities, doing different things and applying in different contexts. Therefor= e, there are different registries for these.=20 It's therefore not a matter of "registering the same thing multiple times". R= ather, it's merely a convenience if the same mnemonic maps to the same numer= ical value, regardless of in which context it's used. If IANA does not get things "matched up correctly", that doesn't break thing= s - but generally, vigilant designated experts and attentive working-groups s= hould be able to keep registries sane and safe ;) Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 26 Apr 2012, at 21:06, Stan Ratliff wrote: > Ulrich,=20 >=20 > JMO, but that just makes my point - this is "easier"? Having to check & do= uble-check to make sure some poor individual in IANA gets the allocations ma= tched up correctly? >=20 > Stan >=20 > On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote: >=20 >> Stan, >>=20 >> I think you should have been in CC of some mails between the authors of p= acketbb-sec and IANA. I suggested to IANA to use the same values instead. Th= ey requested confirmation by the chairs. The registration process for packet= bb-sec is not yet finished, so that can still be changed. >>=20 >> Regards >> Ulrich >>=20 >>=20 >>=20 >> On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff wrote= : >> BTW - according to a quick read by one of my co-authors, , ICV and TIMEST= AMP TLVs have different type values for packet/message/address TLVs. How doe= s that simplify things? >>=20 >> Stan >>=20 >> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >>=20 >>> Stan, >>>=20 >>> why should it complicate things? Have a look at the MANET regsitry: >>> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#me= ssage-type-ranges >>>=20 >>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TI= MESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/O= LSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I ho= pe they will be for packetbb-sec ;-), there is no more code complexity. I ha= ve implemented the different TLVs only once. >>>=20 >>> Regards >>> Ulrich >>>=20 >>> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff wrot= e: >>>=20 >>>=20 >>>>=20 >>>> Yes, that is exactly what we did for all the other drafts/RFCs in MANET= , for example, for the packetbb-sec RFC-to-be. I think it is wise to use th= e same TLV types for packet/message/address-block TLVs. Setting up registrie= s is trivial and does not complicate code. >>>>=20 >>>=20 >>> I disagree - it does complicate things. Both code-wise, and administrati= vely. The fact that it's been done before means little to me. >>>=20 >>> Stan >>>=20 >>>=20 >>>> Regards >>>> Ulrich >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-E3B900A2-2C22-4C24-90C9-28183FF92134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Stan,

=
I'm not Ulrich, but I am one of the authors of RFC5444.

<= /div>
In RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are d= ifferent entities, doing different things and applying in different contexts= . Therefore, there are different registries for these. 

<= /div>
It's therefore not a matter of "registering the same thing multipl= e times". Rather, it's merely a convenience if the same mnemonic maps to the= same numerical value, regardless of in which context it's used.
<= br>
If IANA does not get things "matched up correctly", that doesn= 't break things - but generally, vigilant designated experts and attentive w= orking-groups should be able to keep registries sane and safe ;)
<= br>
Best,

Thomas

--&nb= sp;
Thomas Heide Clausen

"Any si= mple problem can be made insoluble if enough meetings are held to&n= bsp;discuss it."
   -- Mitchell's Law of Committees


On 26 Apr 2012, at 21:06, Stan Ratliff= <sratliff@cisco.com> wrote:=

Ulrich, 
JMO, but that just makes my point - this is "easier"? Having to= check & double-check to make sure some poor individual in IANA gets the= allocations matched up correctly?

Stan
<= br>
On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote:
Stan,

I think you should have been in CC of some= mails between the authors of packetbb-sec and IANA. I suggested to IANA to u= se the same values instead. They requested confirmation by the chairs. The r= egistration process for packetbb-sec is not yet finished, so that can still b= e changed.

Regards
Ulrich



On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff <sratliff@cisco.com&g= t; wrote:
BTW - according to a quick read by one of my co-authors, , I= CV and TIMESTAMP TLVs have different type values for packet/message/add= ress TLVs. How does that simplify things?

Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:

=
Stan,

why should it complicate things? Have a look at the MANE= T regsitry:
http://www.iana.o= rg/assignments/manet-parameters/manet-parameters.xml#message-type-ranges=

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV a= nd TIMESTAMP TLVs as message and as address block TLVs. I have implemented N= HDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which= I hope they will be for packetbb-sec ;-), there is no more code complexity.= I have implemented the different TLVs only once.

Regards
Ulrich<= br>
On Thu, Apr 26, 2012 at 11:32 AM, Stan Rat= liff <sratliff@cisco.com> wrote:


Yes, that is exactly what we did for all the other drafts/RFCs in MANET,&n= bsp; for example, for the packetbb-sec RFC-to-be. I think it is wise to use t= he same TLV types for packet/message/address-block TLVs. Setting up registri= es is trivial and does not complicate code.


I disagree - it does complicate thing= s. Both code-wise, and administratively. The fact that it's been done before= means little to me.

Stan


=
Regards
Ulrich



__________= _____________________________________
manet mailing list
manet@ietf.org
https://www.ietf= .org/mailman/listinfo/manet





___________________________________________= ____
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=
= --Apple-Mail-E3B900A2-2C22-4C24-90C9-28183FF92134-- From teco@inf-net.nl Fri Apr 27 00:06:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7221F8718 for ; Fri, 27 Apr 2012 00:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjWMB2Kjkynq for ; Fri, 27 Apr 2012 00:06:54 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5E021F8711 for ; Fri, 27 Apr 2012 00:06:53 -0700 (PDT) Received: by eeke51 with SMTP id e51so80210eek.31 for ; Fri, 27 Apr 2012 00:06:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OBgpP+72lzHQj8qsYWkbHnQN1n9TGx/PLLnZHJCXi38=; b=SWyP4pS9f65orEuJP3a/+HG9DYSATsZuVPa19J3TVWclcoRv+EY1UeBeH+E/dqNIja 0COjdgYQ1HLPGQ76w8Kl6E+VEcNG11dcpTIuBK6MKFX7Qq2sM0Kkw+KVkJcr30N4YzY+ mogtiOmHc7gP4YW7lqqlBE+IFDCf4iVLrU8klTaR4s+fQU/OMhWfxX37mYlVQSPiLl8q atQzdZKhJjB0KcOtvHfLVUsrnKE514p5M/M/bnYjtv80GGEjw92h1rElAqliHhOUHVhW q5Ot9XoMVJ7spzXJy/rICKx5BVdARs2Ph3DpoxSSqDpTJ96VqwPxNsWPIO8Idjlr+Zqs 00sA== Received: by 10.213.9.14 with SMTP id j14mr402126ebj.278.1335510412746; Fri, 27 Apr 2012 00:06:52 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id e56sm25778337eea.11.2012.04.27.00.06.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 00:06:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <59096C32-A04D-4DEB-A7C8-3102C16EDCE1@cisco.com> Date: Fri, 27 Apr 2012 09:06:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CBD9@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CC32@SUKNPT8106.cogent-dsn.local> <2313FDE9-FCC5-4F74-9F86-CC1463A82BE7@inf-net.nl> <6D11E177-199F-4FE1-ABE6-30A313FEF2E7@cisco.com> <59096C32-A04D-4DEB-A7C8-3102C16EDCE1@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkukHJc5GCD1Z8/OVfNz0suAQrn9UzAp0kVZuqamDWtVPwNxMC6q/PHH4qCeqC+YBLt07fq Cc: "manet@ietf.org IETF" Subject: Re: [manet] DLEP and modemLPA X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 07:06:55 -0000 Op 26 apr. 2012, om 17:43 heeft Stan Ratliff het volgende geschreven: >=20 > On Apr 26, 2012, at 11:32 AM, Teco Boot wrote: >=20 >>=20 >> Op 26 apr. 2012, om 15:51 heeft Stan Ratliff het volgende geschreven: >>=20 >>>=20 >>> On Apr 26, 2012, at 8:16 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 26 apr. 2012, om 11:46 heeft Rick Taylor het volgende = geschreven: >>>>=20 >>>>> Henning, >>>>>=20 >>>>>> Just to make sure I understand you correctly... >>>>>>=20 >>>>>> You mean that you do not want to use IPs as DLEP messages = addresses in >>>>>> Address Blocks, right? >>>>>=20 >>>>> Correct, I do not want to see them used there. >>>>>=20 >>>>>> Its still okay to carry them in Address-Block TLVs, to bind them = to >>>>> the >>>>>> corresponding MAC address? >>>>>=20 >>>>> Yes, as 'normal' TLVs, they can go wherever they are needed as = currently >>>>> specified in draft-02. >>>>>=20 >>>>> As Teco says, layer 3 address TLVs should be optional. >>>>>=20 >>>>> I agree with Stan that it is really useful to have Layer 3 = addressing >>>>> delivered via DLEP when the modem knows it, but there are examples = where >>>>> the modem does not know, but DLEP can still function. >>>>>=20 >>>>> (I am using such a modem now, and I just ARP for the Layer 3 = addresses, >>>>> it's possible, but a PITA, particularly as InARP is largely = unsupported >>>>> in the real world). >>>>=20 >>>> The .!!!!-problem is mainly caused by address resolving on = non-transit links. >>>> On transit links, a good router populates forwarding tables when = there is >>>> a data path set up. ARP/NDP is enough for this and additional time = required >>>> for it is minor related to routing protocol convergence in many = cases. >>>>=20 >>>=20 >>> Except that you inherently force a MANET into a single subnet in = order for that to work. That's not the case in the networks I deploy. >>=20 >> With IPv6 NDP this is not a problem. >> With ARP, AFAIK Cisco routers do not permit address resolving over = different subnets. It is not a limitation of the ARP spec. But yes, = there are problems here. It was discussed in Autoconf. How is it solved = when not using DLEP? >>=20 >=20 > WIthout DLEP, it's *not* solved. That is the point. Or rather, the = point of including the address TLV's. It is a problem in your boxes. Can be fixed, using something similar to = Linux's arp_ignore sysctl. Then, it always works. Without dependency on = DLEP and radio's support for this address resolving feature, which is = good. ARP is a standard protocol and there is running code around. Teco >=20 > Stan >=20 >=20 >> Teco >>=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>> Teco >>>>=20 >>>>> Rick Taylor >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From teco@inf-net.nl Fri Apr 27 00:15:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77021F86CA for ; Fri, 27 Apr 2012 00:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My4iJH0haUl0 for ; Fri, 27 Apr 2012 00:14:59 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA421F86B5 for ; Fri, 27 Apr 2012 00:14:58 -0700 (PDT) Received: by eaaq11 with SMTP id q11so81518eaa.31 for ; Fri, 27 Apr 2012 00:14:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=funnL1GCedniDpDfwcDKUWH/WjMM9Je9mBRbpS5LBWo=; b=VZ9zsgC5RYVGUUPyr6X+w/u0QyNaftx3rVz8vVZmfscr+dizyD0Bwgp7HQbpbTffh6 kL5CNznTeNY04k49BFMQzV5SazoShYnecJF8Hax/pfbuRbwb4Xz2n82wAi7H8v8vX0jF oLC862IL81kGireERhioz4DyCdLn7QilfQK2WycKcZYIuIoOa4rTKhLURSM+mMo2++wd hrHhZSntzLjqBkq0pQx8jMyYdkrcn033NYtFnJdomnTUpKEXw68xuyhtsZvj91gQ/YJw oCFjDCKPubxVBAaOS2vwTFCfKfT48hs2JTunMh3cTt2LR+m9RIhjkyzyMkW+kZvn1w2g bWZg== Received: by 10.213.21.20 with SMTP id h20mr596261ebb.185.1335510897580; Fri, 27 Apr 2012 00:14:57 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z47sm25907514een.5.2012.04.27.00.14.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 00:14:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> Date: Fri, 27 Apr 2012 09:14:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BF5971A-2B3E-4F16-BB37-DA2C79DB1963@inf-net.nl> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local><2C1D451C-BCEC-4B73-8141-A8BDA67B344D@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> To: Rick Taylor X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmDYl6jrPNQWBOz6tl9sRSeoz6NI17TJIt1KZ+5TyWDj2MhXRxfQUecnrojmT9lQjYv/eSR Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 07:15:00 -0000 Op 26 apr. 2012, om 17:29 heeft Rick Taylor het volgende geschreven: > The current draft specifies: >=20 > * Current Data Rate, > * Maximum Data Rate, > * Latency, > * Expected Transmission Time, >=20 > And some slightly 'fluffy' values: > * Relative Link Quality > * Resources >=20 > I can understand how some DLEP consumers like having a dimensionless = metric 'Relative Link Quality', but I am against having more than 1 = dimensionless 'soft' metric to choose from. It is not about dimensionless or not. It is about semantics. RLQ is = something like RSSI / loss ratio and resources could be = battery/CPU/memory levels, or coins in the pocket. Yes, having more than = one semantics_free dimensionless metric doesn't make sense. Teco >=20 > Rick Taylor >=20 >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Henning Rogge >> Sent: 26 April 2012 16:23 >> To: Dearlove, Christopher (UK) >> Cc: manet@ietf.org; Bo Berry; Stan Ratliff >> Subject: Re: [manet] DLEP and TLV breakdown >>=20 >> I think TX/RX current and maximum datarate are examples for "raw >> metrics" as opposed to the "dimensionless metric" TLV from OLSRv2. >>=20 >> Other things I would like to have are Signal Strength, Radio = Frequency >> (especially to reuse the TLV for the Request Link Characteristics >> order!) and maybe some layer-2 statistics that are >> difficult/impossible to get from the router. >>=20 >> Henning >>=20 >> On Thu, Apr 26, 2012 at 17:15, Dearlove, Christopher (UK) >> wrote: >>> I suggest first working out what the TLVs you want are, then = considering >> whether to make them message specific or global later. >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >> Of Henning Rogge >>> Sent: 26 April 2012 16:13 >>> To: Stan Ratliff >>> Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry >>> Subject: Re: [manet] DLEP and TLV breakdown >>>=20 >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>>=20 >>> Thats why a "raw metric TLV" from the global namespace (both message >>> and address TLV) might be a good thing. It gives other protocols the >>> standardized tools to work with too. >>>=20 >>> Henning Rogge >>>=20 >>> On Thu, Apr 26, 2012 at 17:01, Stan Ratliff = wrote: >>>> And in those cases, it's easy to fall prey to the notion that a = certain >>>> piece of data (e.g. Maximum Data Rate) winds up being allocated = from >>>> multiple number spaces. And that's a bad thing. >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>>> On Apr 26, 2012, at 10:54 AM, Henning Rogge wrote: >>>>=20 >>>>> Even for links that are bandwidth constraint, using the context of = the >>>>> message to see what the TLV is about is a better choice. Repeating = the >>>>> order-number over and over for each TLV is just bad. >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>> On Thu, Apr 26, 2012 at 16:52, Stan Ratliff >> wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Apr 26, 2012, at 10:28 AM, Rick Taylor wrote: >>>>>>=20 >>>>>>> Stan, >>>>>>>=20 >>>>>>>> From: Stan Ratliff [mailto:sratliff@cisco.com] >>>>>>>>=20 >>>>>>>> This shows one of the problems I'm having with "restructuring". >> Looks >>>>>>>> to me that "Credit WIndow Status" has at least 3 definitions: >>>>>>>> 0x0101 Credit Window Status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 0x0201 Credit Window Status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> 0x0501 Credit Window Status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> I'm afraid I am doing bit-twiddling here: Hi-byte =3D Message = Type, >>>>>>> Lo-Byte is always 0x01 =3D Credit Window Status. >>>>>>>=20 >>>>>>> TLV type indicates message (what Henning calls his Type TLV) >>>>>>> Extension types (lo-bytes) give Stan's Sub-TLV. This is a more >>>>>>> efficient representation than Henning's, but carries the same >>>>>>> information. >>>>>>>=20 >>>>>>=20 >>>>>> Since the protocol is intended to *only* traverse the local >> (typically >>>>>> Ethernet) link between modem and local router, I admit that >>>>>> efficiency/compression wasn't one of the goals. As for = simplicity, it >>>>>> seems >>>>>> easier to me to just pick the Type value up and directly feed it = into >>>>>> state >>>>>> machinery instead of needing to perform some sort of "bit-level >>>>>> gymnastics" >>>>>> on it prior. >>>>>>=20 >>>>>> Regards, >>>>>> Stan >>>>>>=20 >>>>>>=20 >>>>>>> All I was trying to do was map Stan's Sub-TLV model into RFC5444 = by >>>>>>> using extension types. >>>>>>>=20 >>>>>>> Rick Taylor >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>> was before the present government." >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ******************************************************************** >>>=20 >>=20 >>=20 >>=20 >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Fri Apr 27 01:39:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56B721F8634 for ; Fri, 27 Apr 2012 01:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBODfw8StB7h for ; Fri, 27 Apr 2012 01:39:37 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id E678321F86DA for ; Fri, 27 Apr 2012 01:39:35 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 27 Apr 2012 10:39:31 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 10:39:31 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:39:31 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:39:30 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 09:39:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 09:38:54 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kRX4gfVHaCmeARYO4jijW1F3hTQAC5o8g References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Teco Boot" X-OriginalArrivalTime: 27 Apr 2012 08:39:27.0277 (UTC) FILETIME=[41754DD0:01CD2451] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.005 X-TM-AS-Result: No--12.981200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:39:37 -0000 >=20 > Op 26 apr. 2012, om 17:29 heeft Rick Taylor het volgende geschreven: >=20 > > The current draft specifies: > > > > * Current Data Rate, > > * Maximum Data Rate, > > * Latency, > > * Expected Transmission Time, > > > > And some slightly 'fluffy' values: > > * Relative Link Quality > > * Resources > > > > I can understand how some DLEP consumers like having a dimensionless > metric 'Relative Link Quality', but I am against having more than 1 > dimensionless 'soft' metric to choose from. >=20 > It is not about dimensionless or not. It is about semantics. RLQ is > something like RSSI / loss ratio and resources could be battery/CPU/memory > levels, or coins in the pocket. Yes, having more than one semantics_free > dimensionless metric doesn't make sense. >=20 +1 (Agreeing with myself) Rick Taylor From henning.rogge@fkie.fraunhofer.de Fri Apr 27 01:43:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A782C21F86F2 for ; Fri, 27 Apr 2012 01:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.462 X-Spam-Level: X-Spam-Status: No, score=-4.462 tagged_above=-999 required=5 tests=[AWL=1.787, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb3o7uvjdzeS for ; Fri, 27 Apr 2012 01:43:40 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 304C921F86F1 for ; Fri, 27 Apr 2012 01:43:40 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNgmB-0000mc-C0 for manet@ietf.org; Fri, 27 Apr 2012 10:43:39 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNgmB-0007kl-9M for manet@ietf.org; Fri, 27 Apr 2012 10:43:39 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:43:39 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 10:43:39 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 10:43:38 +0200 Message-ID: <4F9A5C2E.4050300@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 10:43:26 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020005040007070108010809" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 08:43:39.0137 (UTC) FILETIME=[D7941710:01CD2451] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2d58c557eff95fe6d1f20ba5c7a78ca3 Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:43:41 -0000 --------------ms020005040007070108010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 27.04.2012 10:38, schrieb Rick Taylor: >> >> Op 26 apr. 2012, om 17:29 heeft Rick Taylor het volgende geschreven: >> >>> The current draft specifies: >>> >>> * Current Data Rate, >>> * Maximum Data Rate, >>> * Latency, >>> * Expected Transmission Time, >>> >>> And some slightly 'fluffy' values: >>> * Relative Link Quality >>> * Resources >>> >>> I can understand how some DLEP consumers like having a dimensionless >> metric 'Relative Link Quality', but I am against having more than 1 >> dimensionless 'soft' metric to choose from. >> >> It is not about dimensionless or not. It is about semantics. RLQ is >> something like RSSI / loss ratio and resources could be > battery/CPU/memory >> levels, or coins in the pocket. Yes, having more than one > semantics_free >> dimensionless metric doesn't make sense. >> > > +1 (Agreeing with myself) > > Rick Taylor Maybe we could allocate one of the type extensions of the link metric=20 address-tlv from OLSRv2 for DLEP? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020005040007070108010809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcwODQzMzBaMCMGCSqGSIb3DQEJBDEWBBSWIzQQqjKWvseBUaAfjTWqUpAcBTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQC3gc0wM14GrFvLCjFVW3VaoAwHhoBfEulQicYkvFc9fHg9jBeux+dhXald7MyQ Ajh1ll24rWHxw+rIm/gDgnygZj47mb3oO29LpXrJ495fAXrf2Ix+FnzQJBTxFttqSriuuY08 oM3aWfguC0acEabe0OtWUqx3YP+/H751WC81IieLzlysZoERrFCkfYbWLtMeTHMg+eTPVL+4 CpOdWsJHCMAVgbPGmTjUNVBAfBgKs8naKIbz0znPICsDmq2C0PSGeGBoGZfn6Ybm1zc005rC 4s+dO82UCi9bGAoOa3aAKWzNqEd6Y8IThFrxp24YwZH1I3x1HTWjg+LApJiw+jvTAAAAAAAA --------------ms020005040007070108010809-- From Chris.Dearlove@baesystems.com Fri Apr 27 01:47:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0548721F8621 for ; Fri, 27 Apr 2012 01:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmMBz2MZRCbb for ; Fri, 27 Apr 2012 01:47:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D367121F8616 for ; Fri, 27 Apr 2012 01:47:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="234499874" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 09:47:20 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R8lJ0X002959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 09:47:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 09:47:19 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jwLwmQS6Ej0n5skifyF6SVWSSeAAC5o8gAB9F5gAAAiVOEA== Date: Fri, 27 Apr 2012 08:47:19 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local> <4F9A5C2E.4050300@fkie.fraunhofer.de> In-Reply-To: <4F9A5C2E.4050300@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:47:26 -0000 It is essential to the metric type agnosticism of OLSRv2 that all type exte= nsions of the selected type use the same encoding, which no one is suggesti= ng for DLEP. So. no, DLEP can't have one. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 27 April 2012 09:43 To: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown Am 27.04.2012 10:38, schrieb Rick Taylor: >> >> Op 26 apr. 2012, om 17:29 heeft Rick Taylor het volgende geschreven: >> >>> The current draft specifies: >>> >>> * Current Data Rate, >>> * Maximum Data Rate, >>> * Latency, >>> * Expected Transmission Time, >>> >>> And some slightly 'fluffy' values: >>> * Relative Link Quality >>> * Resources >>> >>> I can understand how some DLEP consumers like having a dimensionless >> metric 'Relative Link Quality', but I am against having more than 1 >> dimensionless 'soft' metric to choose from. >> >> It is not about dimensionless or not. It is about semantics. RLQ is >> something like RSSI / loss ratio and resources could be > battery/CPU/memory >> levels, or coins in the pocket. Yes, having more than one > semantics_free >> dimensionless metric doesn't make sense. >> > > +1 (Agreeing with myself) > > Rick Taylor Maybe we could allocate one of the type extensions of the link metric=20 address-tlv from OLSRv2 for DLEP? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Fri Apr 27 01:50:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E433E21F8724 for ; Fri, 27 Apr 2012 01:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.508 X-Spam-Level: X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[AWL=1.741, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8LvoO43CMqU for ; Fri, 27 Apr 2012 01:50:45 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id AD6DA21F8621 for ; Fri, 27 Apr 2012 01:50:44 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNgt2-0001EW-2z; Fri, 27 Apr 2012 10:50:44 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNgt2-000831-0K; Fri, 27 Apr 2012 10:50:44 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:50:43 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 10:50:43 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 10:50:42 +0200 Message-ID: <4F9A5DE2.9050104@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 10:50:42 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local> <4F9A5C2E.4050300@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080202060604000502010201" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 08:50:43.0843 (UTC) FILETIME=[D4B91530:01CD2452] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:50:47 -0000 --------------ms080202060604000502010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK): > It is essential to the metric type agnosticism of OLSRv2 that all > type extensions of the selected type use the same encoding, which no > one is suggesting for DLEP. So. no, DLEP can't have one. I think it might be a good idea to use the same encoding as OLSRv2. But I see this can be controversial. Still, it might be a nice idea to allow DLEP radios to deliver a=20 dimensionless encoding in OLSRv2 encoded form. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms080202060604000502010201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcwODUwNDJaMCMGCSqGSIb3DQEJBDEWBBSemNnKsHuRZoDjydOCJMUWguoH1zBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCaarJCmQhDPhXfL7al8JUMSiVrG+r5br8DavWpkDFLOyAjNG6suGWvj7jIJJ+V D/4VGUXuI4L58F4Dt4m2b2XycpON45hl6PsbtAAs76uu043awX1e7ozCaO7TtKd4FU7lAL8s Z5G7jO04arCTnbUum7KmJKFiKp+MxSpgJFEWZ1JWcaUQdrJhsKvA1XUak/lGALsou+U/9UXU T7WinTAw2ycGXERsH44O6JtSbL7js6iYdS+k5cR7FJkLV8u0eZAfJF0QdB1Trge23M0SVkIp z0PvX8W8cD9/zvaEYpbR00ZEeyVQIBESaykyX4z6oJqtFowzfI5XUcX9HXc1AASuAAAAAAAA --------------ms080202060604000502010201-- From Chris.Dearlove@baesystems.com Fri Apr 27 01:51:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41921F8702 for ; Fri, 27 Apr 2012 01:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFcgJOlHe4-K for ; Fri, 27 Apr 2012 01:51:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7621F8686 for ; Fri, 27 Apr 2012 01:51:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="234501239" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 09:51:50 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R8pnbu006173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 09:51:49 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 09:51:49 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Rick Taylor Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAAG3MAAAPoK4AAIMxjIA== Date: Fri, 27 Apr 2012 08:51:49 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:51:52 -0000 I'm sorry, that makes no sense to me. You want a complicated mess of sub-TL= Vs and a less clear and efficient message just because you don't want simil= ar address and message TLVs? Something we both already do and designed for? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: 26 April 2012 19:11 To: Rick Taylor Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I'm glad *some of us* are sold... ;-) I still can't get past the notion that this approach requires the =20 allocation of a TLV into TWO number spaces. All of the address and =20 metric TLV's can currently exist at the Peer (radio-wide) level, AND =20 for an individual neighbor. As I understand the proposal, Peer level =20 traffic (Peer Discovery, Peer Offer, Peer Update) would be encoded as =20 5444 message TLV's. Neighbor-specific traffic (Neighbor Up, Neighbor =20 Update, Neighbor Down) would be referencing a specific neighbor, =20 therefore, it would be address TLV's... So, we'd have to create TWO registries (one for DLEP message TLV's, =20 another for DLEP address TLV's), and make sure at least metrics and =20 addresses are in BOTH of them. I'm sorry, but that's just silly to me. Stan On Apr 26, 2012, at 11:34 AM, Rick Taylor wrote: >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> >> On Thu, Apr 26, 2012 at 17:25, Rick Taylor =20 >> >> wrote: >>> >>> So, you are suggesting: >>> >>> 1) In the message-block and/or each address-block in the DLEP =20 >>> message, >> there is 1 ORDER_TLV. (Is this right for Address-Blocks?) >> The order TLV will be a Message-TLV... and there will be only one of >> them in a DLEP message. >> >>> 2) Every other TLV in the block refers to the order described by the >> ORDER_TLV. >> Every other TLV in the message (both message TLVs and address TLVs >> refers to the order described in the Order TLV. >> >>> 3) If there is no ORDER_TLV, or more than 1 ORDER_TLV, the block is >> discarded. >> the message is discarded. >> > > +1 > > I'm sold on this. Forget my bit-twiddling suggestions, this is much =20 > simpler. > > Rick Taylor _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Apr 27 01:55:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D7A21F8757 for ; Fri, 27 Apr 2012 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4Isa7jfEn5E for ; Fri, 27 Apr 2012 01:55:46 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2321F8759 for ; Fri, 27 Apr 2012 01:55:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208,217";a="234502965" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 09:55:45 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R8tiQ3009172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 09:55:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 09:55:44 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Ulrich Herberg Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAAG3MAAAPoK4AAALI4gAAAEUmAAAAZVYAAAMG3gAAfTkPg Date: Fri, 27 Apr 2012 08:55:43 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B3! 1B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D013B01GLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:55:49 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D013B01GLKXM0002VGREENLN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Whether the actual numbers are the same is not really something that matters, it's a minor convenience. But INTERVAL_TIME and VALIDITY_TIME in 5497 which are message and address TLVs, have the same number. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Stan Ratliff [mailto:sratliff@cisco.com] Sent: 26 April 2012 19:57 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. BTW - according to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs have different type values for packet/message/address TLVs. How does that simplify things? Stan On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: Stan, why should it complicate things? Have a look at the MANET regsitry: http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I hope they will be for packetbb-sec ;-), there is no more code complexity. I have implemented the different TLVs only once. Regards Ulrich On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff > wrote: Yes, that is exactly what we did for all the other drafts/RFCs in MANET, for example, for the packetbb-sec RFC-to-be. I think it is wise to use the same TLV types for packet/message/address-block TLVs. Setting up registries is trivial and does not complicate code. I disagree - it does complicate things. Both code-wise, and administratively. The fact that it's been done before means little to me. Stan Regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D013B01GLKXM0002VGREENLN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Whether the actual numbers are the same is not really something that matters, it’s a minor convenience. But INTERVAL_TIME and VALIDITY_TIME in 5497 which are message and address TLVs, have the same number.

 

--

Christopher Dearlove

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

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

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

 

From: Stan Ratliff [mailto:sratliff@cisco.com]
Sent: 26 April 2012 19:57
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry
Subject: Re: [manet] DLEP and TLV breakdown

 

 

*** WARNING ***

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

BTW - according to a quick read by one of my co-authors, , ICV and TIMESTAMP TLVs have different type values for packet/message/address TLVs. How does that simplify things?

 

Stan

 

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote:



Stan,

why should it complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges

We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message and as address block TLVs. I have implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the same (which I hope they will be for packetbb-sec ;-), there is no more code complexity. I have implemented the different TLVs only once.

Regards
Ulrich

On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> wrote:

 




Yes, that is exactly what we did for all the other drafts/RFCs in MANET,  for example, for the packetbb-sec RFC-to-be. I think it is wise to use the same TLV types for packet/message/address-block TLVs. Setting up registries is trivial and does not complicate code.

 

I disagree - it does complicate things. Both code-wise, and administratively. The fact that it's been done before means little to me.

 

Stan

 



Regards
Ulrich

 

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

 

 

 


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D013B01GLKXM0002VGREENLN_-- From rick.taylor@cassidian.com Fri Apr 27 01:56:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEB821F85AE for ; Fri, 27 Apr 2012 01:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7YBS9I3t7dN for ; Fri, 27 Apr 2012 01:56:23 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 90A9421F855B for ; Fri, 27 Apr 2012 01:56:22 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 27 Apr 2012 10:56:19 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 10:56:19 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:56:19 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:56:19 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 09:56:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 09:55:41 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kUv4mwSaa6hsrS+eSVmHHRmPbMgAACbcQ References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local><4F9A5C2E.4050300@fkie.fraunhofer.de> From: "Rick Taylor" To: "Henning Rogge" , "Dearlove, Christopher (UK)" X-OriginalArrivalTime: 27 Apr 2012 08:56:15.0703 (UTC) FILETIME=[9A86E670:01CD2453] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.005 X-TM-AS-Result: No--9.481900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:56:24 -0000 >=20 > Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK): > > It is essential to the metric type agnosticism of OLSRv2 that all > > type extensions of the selected type use the same encoding, which no > > one is suggesting for DLEP. So. no, DLEP can't have one. >=20 > I think it might be a good idea to use the same encoding as OLSRv2. >=20 > But I see this can be controversial. >=20 > Still, it might be a nice idea to allow DLEP radios to deliver a > dimensionless encoding in OLSRv2 encoded form. >=20 -1 I'm with Chris on this one. =20 I don't want to see DLEP tied closely to OLSRv2. I suggest a different dimensionless "Relative Link Quality" remain in DLEP as a fallback for interoperability with existing routing protocols (OLSR and EIGRP can both use it without much modification) Rick Taylor From teco@inf-net.nl Fri Apr 27 02:06:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4321F86B3 for ; Fri, 27 Apr 2012 02:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg178b1sSvNG for ; Fri, 27 Apr 2012 02:06:03 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3AD21F8623 for ; Fri, 27 Apr 2012 02:06:01 -0700 (PDT) Received: by eaaq11 with SMTP id q11so114649eaa.31 for ; Fri, 27 Apr 2012 02:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dfo2gB4FAXZZHuca1odYDMU5Jnb4K/lwcz5NS8kjzcw=; b=bVZW6vqc/4LXKTEUUL/u42cBZUoVTMiy34m9B+huLBAq8zq83fFj9CIlYqWJ6UuLou iUhA4YmdRjo0nnNhAbSFcxisn/mL+5S12tcV/N4HPne0IhFfZjY/oDMLx3z9Yp7VcZth T60ZeWQG/6npwjTTnEl8BBM4GtD9jEUkIQKwXIlyFlyW/t8AXX5yqycjXRL02+CR+KMk r3l8HFCOY9Z2HopDx+HAuJTHIaYU8OT0xJq/Ni5lK0cLseUkWmA9f7TpqgZxuIHzfvn0 bFNNeHRfjCjw6+UPq8R08BUbBJAJcKDV2614iZVjTlV3oBLnTSCtI41BfXCRymjP9S3l hB+w== Received: by 10.213.21.23 with SMTP id h23mr645855ebb.44.1335517560821; Fri, 27 Apr 2012 02:06:00 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m55sm27285625eei.1.2012.04.27.02.05.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 02:06:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> Date: Fri, 27 Apr 2012 11:05:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <10FE35D0-72BD-4C79-BCAC-7BD5C648AA86@inf-net.nl> References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local><4F9A5C2E.4050300@fkie.fraunhofer.de> <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> To: "Rick Taylor" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk5v89+oD+Ht+i+Qi6p8JZFSXK+0Q+lqCPW/uTqMCrk97REDEdjN7R8SgZ0Itxxuqh0L2DZ Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:06:03 -0000 Op 27 apr. 2012, om 10:55 heeft Rick Taylor het volgende geschreven: >> >> Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK): >>> It is essential to the metric type agnosticism of OLSRv2 that all >>> type extensions of the selected type use the same encoding, which no >>> one is suggesting for DLEP. So. no, DLEP can't have one. >> >> I think it might be a good idea to use the same encoding as OLSRv2. >> >> But I see this can be controversial. >> >> Still, it might be a nice idea to allow DLEP radios to deliver a >> dimensionless encoding in OLSRv2 encoded form. >> > > -1 I'm with Chris on this one. > > I don't want to see DLEP tied closely to OLSRv2. I suggest a different > dimensionless "Relative Link Quality" remain in DLEP as a fallback for > interoperability with existing routing protocols (OLSR and EIGRP can > both use it without much modification) The dimensionless metric is not tied to any routing protocol, I think. RLQ has semantics and range is far to restrictive. For RSSI it is OK. When having the dimensionless metric, high values would be bad / slow / high delay / costly / etc. links. Teco > > Rick Taylor > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Fri Apr 27 02:07:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B421F86BD for ; Fri, 27 Apr 2012 02:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26A-QZVZ2fbs for ; Fri, 27 Apr 2012 02:07:30 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B6F7721F867B for ; Fri, 27 Apr 2012 02:07:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="234507375" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 10:07:24 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R97NMF017858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 10:07:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 10:07:21 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kUv4mQS6Ej0n5skifyF6SVWSSeAAACbcQAAAqWyA= Date: Fri, 27 Apr 2012 09:07:20 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local><4F9A5C2E.4050300@fkie.fraunhofer.de> <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:07:31 -0000 To be precise (and I think this is just refining my agreement with Rick) OL= SRv2 wants a set all coded the same. From the OLSRv2 side it then is fine f= or anything (e.g. DLEP) to use those, as long as no changes are made. But f= rom the DLEP side this isn't the primary purpose of DLEP. It would however = be a trivial addition to specify what we might call "DLEP for OLSRv2" to ad= d it. But if anyone wants to create such a thing, a separate draft that ext= ends DLEP to say "DLEP can also carry the link metrics defined by OLSRv2" (= no doubt turned into several pages of text) could be written. If anyone wan= ts that, they can write it. And in the meanwhile DLEP doesn't couple unnece= ssarily to OLSRv2. (If you were using DLEP with OLSRv2, the question would be where to put the= intelligence that converts real world metrics to additive routing metrics.= If in the router, DLEP has no need to know anything about OLSRv2. If in th= e radio then DLEP for OLSRv2 makes sense. But I can't see any point - or an= y manufacturer likelihood to support - that being in the radio. It would I = think have to be a different use of DLEP, not simply router-radio use.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Rick Taylor [mailto:Rick.Taylor@Cassidian.com]=20 Sent: 27 April 2012 09:56 To: Henning Rogge; Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: RE: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- >=20 > Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK): > > It is essential to the metric type agnosticism of OLSRv2 that all > > type extensions of the selected type use the same encoding, which no > > one is suggesting for DLEP. So. no, DLEP can't have one. >=20 > I think it might be a good idea to use the same encoding as OLSRv2. >=20 > But I see this can be controversial. >=20 > Still, it might be a nice idea to allow DLEP radios to deliver a > dimensionless encoding in OLSRv2 encoded form. >=20 -1 I'm with Chris on this one. =20 I don't want to see DLEP tied closely to OLSRv2. I suggest a different dimensionless "Relative Link Quality" remain in DLEP as a fallback for interoperability with existing routing protocols (OLSR and EIGRP can both use it without much modification) Rick Taylor ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Apr 27 02:13:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3960221F879B for ; Fri, 27 Apr 2012 02:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPyZqIjbRlbf for ; Fri, 27 Apr 2012 02:13:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADEB21F8778 for ; Fri, 27 Apr 2012 02:13:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="234509564" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 10:13:23 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R9DN9m022255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 10:13:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 10:13:23 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAAG3MAAAPoK4AAALI4gAAAEUmAAAAjBAAAAKE7AAAfX31g Date: Fri, 27 Apr 2012 09:13:22 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:13:26 -0000 Sorry, the argument has descended further than it should go at this point.= And as an author of 5497 it's being suggested I was engaged in something t= hat's being compared with shoplifting. (Actually the addition of address TLVs for these times was added at the req= uest of the DYMO authors, who at that time thought they'd have a use for it= . It's not needed by NHDP/OLSRv2. But I wouldn't be an author if I thought = it was inappropriate. And the need for packet/message versions of cryptogra= phic TLVs, especially for signatures, is clear. I would venture to suggest = if that isn't understood then the whole packet/message approach of 5444 isn= 't understood.) --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 26 April 2012 19:55 To: Henning Rogge Cc: Dearlove, Christopher (UK); manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 26, 2012, at 2:36 PM, Henning Rogge wrote: > There is a reason why IANA always allocated the same code value for > both address and message TLVs where they applied to both. I think they > will keep doing so, because it keeps things easy. > > It seems no problem for writing the drafts (as you can see in the > existing drafts) and I know from personal experience it does NOT > complicate the code of your program. > > So where is your problem? See the earlier response to Ulrich. Multiple allocations in multiple =20 number spaces is a bad idea. The fact that it has been done before =20 doesn't help me - by extension, I could use that same argument to say =20 "People have successfully shop-lifted before. Ergo, shop-lifting is =20 OK." Doesn't work for me. Stan > > Henning > > On Thu, Apr 26, 2012 at 20:32, Stan Ratliff =20 > wrote: >> I disagree - it does complicate things. Both code-wise, and >> administratively. The fact that it's been done before means little =20 >> to me. >> >> Stan > > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Apr 27 02:34:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3014121F8847 for ; Fri, 27 Apr 2012 02:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eusgaUCj0Jn3 for ; Fri, 27 Apr 2012 02:34:50 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id C454821F8844 for ; Fri, 27 Apr 2012 02:34:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="234519746" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 10:34:49 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3R9YmRH005830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 10:34:48 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 10:34:48 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAAG3MAAAPoK4AAALI4gAAAEUmAAAAZVYAAAJo6AAAAG5GAAAAYSgAAIHazQA== Date: Fri, 27 Apr 2012 09:34:48 +0000 Message-ID: References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> In-Reply-To: <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:34:51 -0000 It's not entirely subjective. Hands up those who have written 5444 parsing = code, don't have any problems with different TLV spaces, and would find sub= -TLVs much more complicated. My hand is up. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Stan Ratliff [mailto:sratliff@cisco.com]=20 Sent: 26 April 2012 19:59 To: Henning Rogge Cc: Ulrich Herberg; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- And I guess that's the crux of the subjective crossroads we find =20 ourselves at. At least with the sub-TLV's, you always know that CDR is =20 CDR, because it's only defined once. Stan On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote: > Adding something proprietary like "subtlvs" is a lot worse. Its an > additional dimension for the registries and for the parser/generator. > > Henning Rogge > > On Thu, Apr 26, 2012 at 20:52, Stan Ratliff =20 > wrote: >> Why does it complicate things? >> As you said - "Assuming that the TLV types are the same..." Not =20 >> only now, >> but on down the line if/when we want to add TLVs? You can guarantee =20 >> that >> will always be the case? >> >> Stan >> >> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >> >> Stan, >> >> why should it complicate things? Have a look at the MANET regsitry: >> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#me= ssage-type-ranges >> >> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and >> TIMESTAMP TLVs as message and as address block TLVs. I have =20 >> implemented >> NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the =20 >> same >> (which I hope they will be for packetbb-sec ;-), there is no more =20 >> code >> complexity. I have implemented the different TLVs only once. >> >> Regards >> Ulrich >> >> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff =20 >> wrote: >>> >>> >>> >>> >>> Yes, that is exactly what we did for all the other drafts/RFCs in =20 >>> MANET, >>> for example, for the packetbb-sec RFC-to-be. I think it is wise to =20 >>> use the >>> same TLV types for packet/message/address-block TLVs. Setting up =20 >>> registries >>> is trivial and does not complicate code. >>> >>> >>> I disagree - it does complicate things. Both code-wise, and >>> administratively. The fact that it's been done before means little =20 >>> to me. >>> >>> Stan >>> >>> >>> Regards >>> Ulrich >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From rick.taylor@cassidian.com Fri Apr 27 02:55:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1A21F8871 for ; Fri, 27 Apr 2012 02:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiA948KoXghK for ; Fri, 27 Apr 2012 02:55:24 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F621F886E for ; Fri, 27 Apr 2012 02:55:22 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 27 Apr 2012 11:55:22 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 11:55:21 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 11:55:21 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 11:55:21 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:55:17 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 10:54:37 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C717C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kVWTDJDZMm9s9RI64FIm3fYyqkQAADwwA References: <7B31B0093014224A843C10C0CCE92AC10378D15E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C701C@SUKNPT8106.cogent-dsn.local><4F9A5C2E.4050300@fkie.fraunhofer.de> <7B31B0093014224A843C10C0CCE92AC1037C7075@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Teco Boot" X-OriginalArrivalTime: 27 Apr 2012 09:55:17.0635 (UTC) FILETIME=[D9AED530:01CD245B] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.006 X-TM-AS-Result: No--19.780500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:55:25 -0000 I think we are mostly in agreement that the current DLEP draft-02 RLQ is a useful metric. As I understand it, the 'meaning' of RLQ is: "If you understand no other metric but this, RLQ gives you an idea of the quality of a link as a percentage of the ideal quality." Rick Taylor > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 27 April 2012 10:06 > To: Rick Taylor > Cc: Henning Rogge; Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] DLEP and TLV breakdown >=20 >=20 > Op 27 apr. 2012, om 10:55 heeft Rick Taylor het volgende geschreven: >=20 > >> > >> Am 27.04.2012 10:47, schrieb Dearlove, Christopher (UK): > >>> It is essential to the metric type agnosticism of OLSRv2 that all > >>> type extensions of the selected type use the same encoding, which no > >>> one is suggesting for DLEP. So. no, DLEP can't have one. > >> > >> I think it might be a good idea to use the same encoding as OLSRv2. > >> > >> But I see this can be controversial. > >> > >> Still, it might be a nice idea to allow DLEP radios to deliver a > >> dimensionless encoding in OLSRv2 encoded form. > >> > > > > -1 I'm with Chris on this one. > > > > I don't want to see DLEP tied closely to OLSRv2. I suggest a different > > dimensionless "Relative Link Quality" remain in DLEP as a fallback for > > interoperability with existing routing protocols (OLSR and EIGRP can > > both use it without much modification) >=20 > The dimensionless metric is not tied to any routing protocol, I think. > RLQ has semantics and range is far to restrictive. For RSSI it is OK. >=20 > When having the dimensionless metric, high values would be bad / slow / > high delay / costly / etc. links. >=20 > Teco >=20 >=20 >=20 > > > > Rick Taylor > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet From rick.taylor@cassidian.com Fri Apr 27 03:00:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964A221F8861 for ; Fri, 27 Apr 2012 03:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsRzize5Zit4 for ; Fri, 27 Apr 2012 03:00:05 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id C43DB21F885E for ; Fri, 27 Apr 2012 03:00:04 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 27 Apr 2012 12:00:03 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 12:00:02 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 12:00:02 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 12:00:02 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 10:59:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 10:59:17 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0jv3ccQS6Ej0n5skifyF6SVWSSeAAAG3MAAAPoK4AAALI4gAAAEUmAAAAZVYAAAJo6AAAAG5GAAAAYSgAAIHazQAAA9+mw References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Stan Ratliff" , "Henning Rogge" X-OriginalArrivalTime: 27 Apr 2012 09:59:57.0969 (UTC) FILETIME=[80C66810:01CD245C] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.006 X-TM-AS-Result: No-0.510000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet@ietf.org, Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:00:05 -0000 =20 > It's not entirely subjective. Hands up those who have written 5444 parsing > code, don't have any problems with different TLV spaces, and would find > sub-TLVs much more complicated. >=20 > My hand is up. My hand is half-way. I have a production-grade parser. Sub-TLV's are just TLV payload, no more or less complex. My *only* objection to TLV's is 'elegance'. I see no noticeable implementation complexity difference in any of the proposals or draft-02 formats. In reality, parsing is not the most complex part of network I/O software. From ietf@thomasclausen.org Fri Apr 27 03:32:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8221F85D5 for ; Fri, 27 Apr 2012 03:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrfhjmqMhSxE for ; Fri, 27 Apr 2012 03:32:47 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 179E921F85C6 for ; Fri, 27 Apr 2012 03:32:47 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 726CC557F15 for ; Fri, 27 Apr 2012 03:32:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id AF82B1BC8F5D; Fri, 27 Apr 2012 03:32:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 834281BC8F58; Fri, 27 Apr 2012 03:32:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: Date: Fri, 27 Apr 2012 12:32:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0897D892-DAFE-4B6A-A1FD-069D004BFD07@thomasclausen.org> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1257) Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:32:48 -0000 On Apr 27, 2012, at 11:34 , Dearlove, Christopher (UK) wrote: > It's not entirely subjective. Hands up those who have written 5444 = parsing code, don't have any problems with different TLV spaces, and = would find sub-TLVs much more complicated. >=20 > My hand is up. >=20 Ok, since you ask, I've implemented not one, but two 5444 parsers (in = two different languages on two different platforms), and I never even = thought of the different TLV spaces as being problematic (they're for = different kind of TLVs, so fell quite naturally). I'm not sure I understand the sub-TLVs quite right (or rather: I hope = that I dont since if I do then it's definitely quite complicated....) So my hand is up with Chris' (actually, as I've implemented 5444-parsers = twice, can I raise both hands, please?) Thomas > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com]=20 > Sent: 26 April 2012 19:59 > To: Henning Rogge > Cc: Ulrich Herberg; Dearlove, Christopher (UK); manet@ietf.org; Bo = Berry > Subject: Re: [manet] DLEP and TLV breakdown >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > And I guess that's the crux of the subjective crossroads we find =20 > ourselves at. At least with the sub-TLV's, you always know that CDR is = =20 > CDR, because it's only defined once. >=20 > Stan >=20 > On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote: >=20 >> Adding something proprietary like "subtlvs" is a lot worse. Its an >> additional dimension for the registries and for the parser/generator. >>=20 >> Henning Rogge >>=20 >> On Thu, Apr 26, 2012 at 20:52, Stan Ratliff =20 >> wrote: >>> Why does it complicate things? >>> As you said - "Assuming that the TLV types are the same..." Not =20 >>> only now, >>> but on down the line if/when we want to add TLVs? You can guarantee =20= >>> that >>> will always be the case? >>>=20 >>> Stan >>>=20 >>> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >>>=20 >>> Stan, >>>=20 >>> why should it complicate things? Have a look at the MANET regsitry: >>> = http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#mess= age-type-ranges >>>=20 >>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV = and >>> TIMESTAMP TLVs as message and as address block TLVs. I have =20 >>> implemented >>> NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the =20= >>> same >>> (which I hope they will be for packetbb-sec ;-), there is no more =20= >>> code >>> complexity. I have implemented the different TLVs only once. >>>=20 >>> Regards >>> Ulrich >>>=20 >>> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff =20= >>> wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Yes, that is exactly what we did for all the other drafts/RFCs in =20= >>>> MANET, >>>> for example, for the packetbb-sec RFC-to-be. I think it is wise to =20= >>>> use the >>>> same TLV types for packet/message/address-block TLVs. Setting up =20= >>>> registries >>>> is trivial and does not complicate code. >>>>=20 >>>>=20 >>>> I disagree - it does complicate things. Both code-wise, and >>>> administratively. The fact that it's been done before means little =20= >>>> to me. >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>>> Regards >>>> Ulrich >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas@thomasclausen.org Fri Apr 27 03:34:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB6021F85FD for ; Fri, 27 Apr 2012 03:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+EqDaoU54ij for ; Fri, 27 Apr 2012 03:34:08 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B520621F85D5 for ; Fri, 27 Apr 2012 03:34:08 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 69F8C557F15 for ; Fri, 27 Apr 2012 03:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4EBCF1BC8F9D; Fri, 27 Apr 2012 03:34:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 235151BC8F9C; Fri, 27 Apr 2012 03:34:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> Date: Fri, 27 Apr 2012 12:34:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <377872F7-B706-431F-A0DB-9D17B36CF1E2@thomasclausen.org> References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com><7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> To: Rick Taylor X-Mailer: Apple Mail (2.1257) Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:34:09 -0000 On Apr 27, 2012, at 11:59 , Rick Taylor wrote: >=20 >> It's not entirely subjective. Hands up those who have written 5444 > parsing >> code, don't have any problems with different TLV spaces, and would > find >> sub-TLVs much more complicated. >>=20 >> My hand is up. >=20 > My hand is half-way. I have a production-grade parser. Sub-TLV's are > just TLV payload, no more or less complex. >=20 > My *only* objection to TLV's is 'elegance'. I see no noticeable > implementation complexity difference in any of the proposals or = draft-02 > formats. In reality, parsing is not the most complex part of network > I/O software. Well, that _does_ depend on what platform you're targeting, really, = specifically how (in-)efficient you can afford being with memory.=20 From henning.rogge@fkie.fraunhofer.de Fri Apr 27 03:37:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3E21F8787 for ; Fri, 27 Apr 2012 03:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[AWL=1.698, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM8lG6kbFexX for ; Fri, 27 Apr 2012 03:37:56 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id DA63A21F877B for ; Fri, 27 Apr 2012 03:37:55 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNiYi-0006Vx-57 for manet@ietf.org; Fri, 27 Apr 2012 12:37:52 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNiYi-0002hL-2T for manet@ietf.org; Fri, 27 Apr 2012 12:37:52 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 12:37:51 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 12:37:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 12:37:51 +0200 Message-ID: <4F9A76FA.3070704@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 12:37:46 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070709010805090500010405" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 10:37:51.0900 (UTC) FILETIME=[CC24BDC0:01CD2461] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:37:57 -0000 --------------ms070709010805090500010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2012 11:59 AM, Rick Taylor wrote: > >> It's not entirely subjective. Hands up those who have written 5444 > parsing >> code, don't have any problems with different TLV spaces, and would > find >> sub-TLVs much more complicated. >> >> My hand is up. > > My hand is half-way. I have a production-grade parser. Sub-TLV's are > just TLV payload, no more or less complex. > > My *only* objection to TLV's is 'elegance'. I see no noticeable > implementation complexity difference in any of the proposals or draft-0= 2 > formats. In reality, parsing is not the most complex part of network > I/O software. My hand is up, too. I have a parser and a generator that can multiplex and demultiplex=20 RFC5444 for different "interested parties" (for example my OLSRv2 code=20 will be able to add TLVs to NHDP Hello messages without changing the=20 NHDP code). But sub-tlvs will be another layer of complexity, especially because the = order of the subtlvs seems to make a difference! Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms070709010805090500010405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcxMDM3NDlaMCMGCSqGSIb3DQEJBDEWBBSMDNIBHBamxQRNZuGNILQqvwFhZjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBw3dxSglhjvDLPtRZZikfnyA16a0XcQv7aAIffisBc4Pb6kxaia22YpViyd5/V fQZ4OQhpOern5WB+c4O82mgFBK9PZqZ7RswkVsjogHdiitCZq74MWHk1APS4+gu79RvWMYLd GYLCjdJfCLtoC2ElLUPJSTGBESCsJgzKSNBTYehhsBhr+lgAeTAC7S8tqUuWkmPHKfgX8gYi wkcgX+C9mJg/gr5fM0vJ02zczCvEuUVlAauHCwTGmo4U/iGfJFkytTAG26iu6pcxZ1oxQkmh rD81li57nCoQgrmg8jX4xCpRG3eLfGbm4ngLEmYZDIxPdfuGLfjc6YaCtsWrXa82AAAAAAAA --------------ms070709010805090500010405-- From rick.taylor@cassidian.com Fri Apr 27 04:10:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818DC21F873E for ; Fri, 27 Apr 2012 04:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7T4CTNr6vDt for ; Fri, 27 Apr 2012 04:10:33 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id CAC5421F860B for ; Fri, 27 Apr 2012 04:10:32 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 27 Apr 2012 13:10:30 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 13:10:30 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:10:30 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:10:30 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 12:10:26 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 12:09:39 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kYfY6rDGuoYoeRlKKScOXTqsdgwAAt6qw References: <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 27 Apr 2012 11:10:26.0362 (UTC) FILETIME=[5917F9A0:01CD2466] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.006 X-TM-AS-Result: No--24.494800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:10:34 -0000 I think we are in danger of letting the tail wag the dog here. The best DLEP spec will result in specifying what needs to be there by = analysing the use-cases and taking into account transport = characteristics. Not how easy it makes implementers jobs. Obviously, = specifying something totally wacky is never a good idea, but really, = what is the difference between... Packet AND Packet | | +-Message +-Message | | +-DLEP_TLV +-DLEP_ORDER_TLV | | +-SubTLV_1 +-DLEP_TLV_1 | | +-SubTLV_2 +-DLEP_TLV_2 : : =20 ...as far as the parser is concerned? From my perspective, Stan's = Sub-TLV's are possibly easier to integrate into an existing parser than = having to maintain the state at the message processing level in = Henning's model. The problem with Stan's SubTLV model is not really with the SubTLV's = (RFC5444 allows any data in a TLV) but with the administrivia of having = a new Sub-TLV registry. Rick Taylor > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of > Henning Rogge > Sent: 27 April 2012 11:38 > To: manet@ietf.org > Subject: Re: [manet] DLEP and TLV breakdown >=20 > On 04/27/2012 11:59 AM, Rick Taylor wrote: > > > >> It's not entirely subjective. Hands up those who have written 5444 > > parsing > >> code, don't have any problems with different TLV spaces, and would > > find > >> sub-TLVs much more complicated. > >> > >> My hand is up. > > > > My hand is half-way. I have a production-grade parser. Sub-TLV's = are > > just TLV payload, no more or less complex. > > > > My *only* objection to TLV's is 'elegance'. I see no noticeable > > implementation complexity difference in any of the proposals or = draft-02 > > formats. In reality, parsing is not the most complex part of = network > > I/O software. >=20 > My hand is up, too. >=20 > I have a parser and a generator that can multiplex and demultiplex > RFC5444 for different "interested parties" (for example my OLSRv2 code > will be able to add TLVs to NHDP Hello messages without changing the > NHDP code). >=20 > But sub-tlvs will be another layer of complexity, especially because = the > order of the subtlvs seems to make a difference! >=20 > Henning Rogge >=20 > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 From henning.rogge@fkie.fraunhofer.de Fri Apr 27 04:15:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086C121F87FD for ; Fri, 27 Apr 2012 04:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=1.656, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYr3LsWmyfy2 for ; Fri, 27 Apr 2012 04:15:41 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0621F87F8 for ; Fri, 27 Apr 2012 04:15:41 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNj9I-0008Ut-NU; Fri, 27 Apr 2012 13:15:40 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNj9I-0003nG-Kr; Fri, 27 Apr 2012 13:15:40 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:15:40 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:15:40 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:15:39 +0200 Message-ID: <4F9A7FDA.6000704@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 13:15:38 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090603040202050204060402" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 11:15:40.0430 (UTC) FILETIME=[144AF2E0:01CD2467] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 797bbac53b4539d3de9d70869dd0fccf Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:15:43 -0000 --------------ms090603040202050204060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2012 01:09 PM, Rick Taylor wrote: > I think we are in danger of letting the tail wag the dog here. > > The best DLEP spec will result in specifying what needs to be there > by analysing the use-cases and taking into account > transportcharacteristics. Not how easy it makes implementers jobs. > Obviously, specifying something totally wacky is never a good idea, but= > really, what is the difference between... > > Packet AND Packet > | | > +-Message +-Message > | | > +-DLEP_TLV +-DLEP_ORDER_TLV > | | > +-SubTLV_1 +-DLEP_TLV_1 > | | > +-SubTLV_2 +-DLEP_TLV_2 > : : > > > ...as far as the parser is concerned? From my perspective, Stan's > Sub-TLV's are possibly easier to integrate into an existing parser than= > having to maintain the state at the message processing level in > Henning's model. With a generic parser you don't have to integrate anything new for the=20 right one. You just add a few numbers to an array of "TLVs you are=20 interested in". No additional byte parsing code necessary. I would not even notice if the DLEP_ORDER_TLV is the last TLV in the=20 list of message TLVs. I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming=20 olsr.org (v2) implementation. Having something special for DLEP is just=20 bad and unnecessary. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms090603040202050204060402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcxMTE1MzhaMCMGCSqGSIb3DQEJBDEWBBQy4BR5DnVttg+6P/QNtFTchHPuZzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCiKdq2mIxjfap+nHrYQm/sddmWajI1GAixXLoOWw/BgnVreXbVvjuv+q/xqXvk BskIAaEGNlE1M4NVvkSeN+Z/KShZwrPnYjt10D4xr0MXLlwVUft8Fk1JaDeGjVWDfjlVMZvG 5NwAT/MW+vZKPL2H7LiN1lDBWpGFDfo8lFnHvj0ATStu7GiPcCYTwfma3kBW/O6hSzSfvw/n YYKokY62orrxFkNVFGUC0qEQaKfhlevsjNUio44n1jeGRMvonDDcj+ZL3GxtbE51Q7y/izf4 2Pzhl/r4YuLo+085Nj/reCSDZWAju0z8KrzfvZ8fUcOIag6x6aWrJuqRLrfsUSOoAAAAAAAA --------------ms090603040202050204060402-- From boberry@cisco.com Fri Apr 27 04:17:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0CF21F87C7 for ; Fri, 27 Apr 2012 04:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE+tx2v7AdNb for ; Fri, 27 Apr 2012 04:17:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5441D21F87CC for ; Fri, 27 Apr 2012 04:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=3800; q=dns/txt; s=iport; t=1335525464; x=1336735064; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=efaaeNkOB9FG0gyF04i3hkj0hpRwcUbIr59GpJgTDSo=; b=S582xVeIGRSxy6uIDERUqBtOK4wClFkOY/FcqB8O4P7gDLUVgiJNC1Wb LB4glcBuYx0FMQndiRjRBR+rNXoZPT5cKGSVfiQAimwv0c9Ql8CoY8ptj qWIOAmtIjkOpEYKvb7PXWomvSWJxw9rYdIS81BjhzKkvl7lVK3kaVTd28 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkFANB/mk+tJV2a/2dsb2JhbABFgx2uYIEHggkBAQEDAQEBAQ8BWwsFBwQLEQQBAQEVEgcnHwkIBhMih2YFC5xmoDSOEoJOYwSVfYV0iGOBaYMEgUA X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="78386683" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 27 Apr 2012 11:17:43 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-114.cisco.com [10.81.230.114]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3RBHhwP000750; Fri, 27 Apr 2012 11:17:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> Date: Fri, 27 Apr 2012 07:17:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local><7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> To: "Rick Taylor" X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:17:45 -0000 On Apr 27, 2012, at 7:09 AM, Rick Taylor wrote: > I think we are in danger of letting the tail wag the dog here. +1 >=20 > The best DLEP spec will result in specifying what needs to be there by = analysing the use-cases and taking into account transport = characteristics. =20 +1 > Not how easy it makes implementers jobs. Obviously, specifying = something totally wacky is never a good idea, but really, what is the = difference between... +1 >=20 > Packet AND Packet > | | > +-Message +-Message > | | > +-DLEP_TLV +-DLEP_ORDER_TLV > | | > +-SubTLV_1 +-DLEP_TLV_1 > | | > +-SubTLV_2 +-DLEP_TLV_2 > : : >=20 >=20 > ...as far as the parser is concerned? =46rom my perspective, Stan's = Sub-TLV's are possibly easier to integrate into an existing parser than = having to maintain the state at the message processing level in = Henning's model. >=20 > The problem with Stan's SubTLV model is not really with the SubTLV's = (RFC5444 allows any data in a TLV) but with the administrivia of having = a new Sub-TLV registry. >=20 > Rick Taylor >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Henning Rogge >> Sent: 27 April 2012 11:38 >> To: manet@ietf.org >> Subject: Re: [manet] DLEP and TLV breakdown >>=20 >> On 04/27/2012 11:59 AM, Rick Taylor wrote: >>>=20 >>>> It's not entirely subjective. Hands up those who have written 5444 >>> parsing >>>> code, don't have any problems with different TLV spaces, and would >>> find >>>> sub-TLVs much more complicated. >>>>=20 >>>> My hand is up. >>>=20 >>> My hand is half-way. I have a production-grade parser. Sub-TLV's = are >>> just TLV payload, no more or less complex. >>>=20 >>> My *only* objection to TLV's is 'elegance'. I see no noticeable >>> implementation complexity difference in any of the proposals or = draft-02 >>> formats. In reality, parsing is not the most complex part of = network >>> I/O software. >>=20 >> My hand is up, too. >>=20 >> I have a parser and a generator that can multiplex and demultiplex >> RFC5444 for different "interested parties" (for example my OLSRv2 = code >> will be able to add TLVs to NHDP Hello messages without changing the >> NHDP code). >>=20 >> But sub-tlvs will be another layer of complexity, especially because = the >> order of the subtlvs seems to make a difference! >>=20 >> Henning Rogge >>=20 >> -- >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From boberry@cisco.com Fri Apr 27 04:24:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7C21F8827 for ; Fri, 27 Apr 2012 04:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqN2drozXzNe for ; Fri, 27 Apr 2012 04:24:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C2CB521F8734 for ; Fri, 27 Apr 2012 04:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=2995; q=dns/txt; s=iport; t=1335525840; x=1336735440; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1it/B7gvQLri+ymslMRjAXNYwUhuE5BW8UsxXvcO0Cg=; b=hBQ7wPRViwyTrFFcPnm79of6c5Ouw5n0iU0rwFiB1IJv7bG7mWppQEDQ c7n6yiDvdOF71TbLcx3BNhHnlvK8yHhTfHHKuCOpwASuCqXMs2uuZIyWy ilx5fPbIrE3VDknG94/eNqoNk4W1HaxMMK5izc0Egwd53Cs78Sl0TGMhZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFABaBmk+tJXHA/2dsb2JhbABFgx2uYIEHggkBAQEDAQEBAQ8BWwsFCwsYFRIHJx8RBhMih2YFC5xroDWOEoJOYwSVfYERhGOIY4FpgwSBQA X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="78403215" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 27 Apr 2012 11:24:00 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-114.cisco.com [10.81.230.114]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3RBNxVf021019; Fri, 27 Apr 2012 11:24:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <4F9A7FDA.6000704@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 07:23:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:24:01 -0000 On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote: > On 04/27/2012 01:09 PM, Rick Taylor wrote: >> I think we are in danger of letting the tail wag the dog here. >>=20 >> The best DLEP spec will result in specifying what needs to be there >> by analysing the use-cases and taking into account >> transportcharacteristics. Not how easy it makes implementers jobs. >> Obviously, specifying something totally wacky is never a good idea, = but >> really, what is the difference between... >>=20 >> Packet AND Packet >> | | >> +-Message +-Message >> | | >> +-DLEP_TLV +-DLEP_ORDER_TLV >> | | >> +-SubTLV_1 +-DLEP_TLV_1 >> | | >> +-SubTLV_2 +-DLEP_TLV_2 >> : : >>=20 >>=20 >> ...as far as the parser is concerned? =46rom my perspective, Stan's >> Sub-TLV's are possibly easier to integrate into an existing parser = than >> having to maintain the state at the message processing level in >> Henning's model. >=20 > With a generic parser you don't have to integrate anything new for the = right one. You just add a few numbers to an array of "TLVs you are = interested in". >=20 > No additional byte parsing code necessary. >=20 > I would not even notice if the DLEP_ORDER_TLV is the last TLV in the = list of message TLVs. >=20 > I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming = olsr.org (v2) implementation. Having something special for DLEP is just = bad and unnecessary. =46rom your perspective I can understand that position. But there are = others that have diff parsers, diff protocols, diff radios, networks, = etc. Ricks' caution is a good one. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From abdussalambaryun@gmail.com Fri Apr 27 04:25:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3762121F8821 for ; Fri, 27 Apr 2012 04:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3blpCxKfRQZ for ; Fri, 27 Apr 2012 04:25:50 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39621F87D2 for ; Fri, 27 Apr 2012 04:25:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so511881vbb.31 for ; Fri, 27 Apr 2012 04:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4fIltdYH/ZeAwSwx8eOw0JUbG2/rsgAJ1Yw/kyz8qdY=; b=UY0Pb70KeKd2lt7qIVKl2E+hV5a8vyD1qXAFJRkiiewew1Xq+iHPm74CRjsyx0ZW50 yI1PX3TVEAp/PljFan+bjt2bndAyBb8m38kjwQl5K7cWSbS9HlGZREoEcgGqNl/hQhsc SaAeQ5fSam3k6iPuy1kFzKEe2CRCvNSgxzurnSEcQmMk5g02Y27CfpQJXE8WqqNp9Eoo U92zVbHCmuqFqnir1FPVajoLNQsan2jvdlbhQDB6mNs05cj/3bmAhB67MoWlEZ8HqGta +v0/9gTxBDRcOU1StDewGsyHv3H/ymi0tXR7KyyC+Lh7f6jLGjUHujdSaYyAKnlM/n2W xFWA== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr6712882vdb.55.1335525950155; Fri, 27 Apr 2012 04:25:50 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Fri, 27 Apr 2012 04:25:50 -0700 (PDT) Date: Fri, 27 Apr 2012 13:25:50 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:25:51 -0000 Hi Stan, I hope we can consider the interest to use DLEP by all MANET routing which are standard and which are work in progress, therefore, I suggest that any update in its techniques to consider all routing DSR, AODV, OLSR, DYMO etc. protocols' aspects of needed informations or entry updates. On the other hand the different types of link technologies used may add to DLEP considerations. Regards Abdussalam Baryun University of Glamorgan, UK From henning.rogge@fkie.fraunhofer.de Fri Apr 27 04:26:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D221F87F5 for ; Fri, 27 Apr 2012 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=1.617, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeZR1fV9twVI for ; Fri, 27 Apr 2012 04:26:48 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 35A8A21F869C for ; Fri, 27 Apr 2012 04:26:48 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNjK3-0000b2-JF; Fri, 27 Apr 2012 13:26:47 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNjK3-00048i-GY; Fri, 27 Apr 2012 13:26:47 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:26:47 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:26:47 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:26:46 +0200 Message-ID: <4F9A8275.3020506@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 13:26:45 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> <4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020209030003080305050502" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 11:26:47.0309 (UTC) FILETIME=[A1C89BD0:01CD2468] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 00b54f98fe2f0cea78af7465bd8f318d Cc: Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:26:54 -0000 --------------ms020209030003080305050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2012 01:23 PM, Bo Berry wrote: >> With a generic parser you don't have to integrate anything new for the= right one. You just add a few numbers to an array of "TLVs you are inter= ested in". >> >> No additional byte parsing code necessary. >> >> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the l= ist of message TLVs. >> >> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming = olsr.org (v2) implementation. Having something special for DLEP is just b= ad and unnecessary. > > From your perspective I can understand that position. But there are o= thers that have diff parsers, diff protocols, diff radios, networks, etc.= Ricks' caution is a good one. My point is that with RFC 5444 (without subtlvs) one option needs=20 additional byte-juggling code, and the other does not (the one with a=20 generic RFC 5444 parser). The subtlv option needs always additional byte-juggling code. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms020209030003080305050502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcxMTI2NDVaMCMGCSqGSIb3DQEJBDEWBBSGHERfhriK6SsUR785bp265KBgUzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBGzF/V9AXARV5mjngs259H8atgwMUKPaAHHVGteqAsHgpvEc87fc6aNDSPSe+k tVcNRAdke7usd4TUKFRfR14HdfFe6jKj3KA3wFEcU0zs6ZxzTS8mldhDad7oZ55LwWBT4ILV JJ/ML4SB9UTJbCrVInf1yc7jdOl3CzlFr2igxXBX0365KR0gq5y8t3y7POde90JFsWWPJ+Dj v9Fw3+o74oyUJR/k4MnicIB2Gh7KuNu7URrSGRBwWayu978HwuhYehAkePlWKLbK74SPNM9A N8/JatJNGGNLFcpaaJzLieE9VRKatyF6s3Wl8d2kA+mAmaZHXXZWQc2cKNS2E0RsAAAAAAAA --------------ms020209030003080305050502-- From boberry@cisco.com Fri Apr 27 04:29:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434A21F880C for ; Fri, 27 Apr 2012 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6Eq2c0ylSFj for ; Fri, 27 Apr 2012 04:29:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45B21F87F5 for ; Fri, 27 Apr 2012 04:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=2069; q=dns/txt; s=iport; t=1335526172; x=1336735772; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uHsyM4ywafR7FLH515XPe6lVygful1H9ZSQcVbKNVzY=; b=Ooanx55UQbjXy793lnNJS0lKuJalV9AflaU4MMdS3HkRJCdNHl5tui9I 6Px0zM5nAUHVDAXoOSi2W37iG9fpS9zgZzqOZ1tw2wmR0flm0cd8XiSeH cku1LkDLU54HXq6Bdskq1pPB9Nz4p83acgm86fM//5RBGhuirmMmQnR2A g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFACWCmk+tJXG+/2dsb2JhbABFgx2uYIEHggkBAQEDARIBZgULCxgnB0YRBhMih2YFnHmgNZBgYwSVfYERhGOIY4FpgwSBQA X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="78404262" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 27 Apr 2012 11:29:31 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-114.cisco.com [10.81.230.114]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3RBTVdx008254; Fri, 27 Apr 2012 11:29:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <4F9A8275.3020506@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 07:29:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4E9101-88CE-4817-BF3E-26A18B67A47F@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> <4F9A7FDA.6000704@fkie.fraunhofer.de> <4F9A8275.3020506@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:29:32 -0000 On Apr 27, 2012, at 7:26 AM, Henning Rogge wrote: > On 04/27/2012 01:23 PM, Bo Berry wrote: >>> With a generic parser you don't have to integrate anything new for = the right one. You just add a few numbers to an array of "TLVs you are = interested in". >>>=20 >>> No additional byte parsing code necessary. >>>=20 >>> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the = list of message TLVs. >>>=20 >>> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the = coming olsr.org (v2) implementation. Having something special for DLEP = is just bad and unnecessary. >>=20 >> =46rom your perspective I can understand that position. But there = are others that have diff parsers, diff protocols, diff radios, = networks, etc. Ricks' caution is a good one. >=20 > My point is that with RFC 5444 (without subtlvs) one option needs = additional byte-juggling code, and the other does not (the one with a = generic RFC 5444 parser). >=20 > The subtlv option needs always additional byte-juggling code. I understand your point. What one considers byte=3Djuggling in his/her = parser may not be in anothers. =20 >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From boberry@cisco.com Fri Apr 27 04:30:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7B021F8809 for ; Fri, 27 Apr 2012 04:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct99iaiJaBov for ; Fri, 27 Apr 2012 04:30:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38F21F87F5 for ; Fri, 27 Apr 2012 04:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=1258; q=dns/txt; s=iport; t=1335526235; x=1336735835; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wgkyJwzajX/uYgBTEa/e9Y9m/KC6X1Qx218Y9cZ0f/k=; b=TPg5cbqTIz+AYTaJLnUcjVaPfsAnq3ifLBqnyTi94NRt0PiTwPENhE5x NvUO5LKSWqPJXgW8sCH8H57XILLzoHqMTAhb2oFFvsEu1wKvNA6jIEEKQ Nt9mEclm4woy+RZ+h8qWfC/wKsap5F4TNWd+FeNfjjluWiAdTfBsgc1C8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFACWCmk+tJV2c/2dsb2JhbABFgx2uYIEHggkBAQEDAQEBAQ8BJzQLBQsLRicwBhMih2YFC5xuoDEEkGBjBJV9hXSIY4FpgwSBQA X-IronPort-AV: E=Sophos;i="4.75,490,1330905600"; d="scan'208";a="78389132" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 27 Apr 2012 11:30:34 +0000 Received: from [192.168.1.106] (ggsg-vpn2-230-114.cisco.com [10.81.230.114]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3RBUYZ5028466; Fri, 27 Apr 2012 11:30:34 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Fri, 27 Apr 2012 07:30:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1084) Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:30:35 -0000 We need to also add the OSPF MANET extensions, and other protocols that = currently use DLEP. -Bo On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: > Hi Stan, >=20 > I hope we can consider the interest to use DLEP by all MANET routing > which are standard and which are work in progress, therefore, I > suggest that any update in its techniques to consider all routing DSR, > AODV, OLSR, DYMO etc. protocols' aspects of needed informations or > entry updates. On the other hand the different types of link > technologies used may add to DLEP considerations. >=20 > Regards >=20 > Abdussalam Baryun > University of Glamorgan, UK > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From rick.taylor@cassidian.com Fri Apr 27 04:35:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1321F862F for ; Fri, 27 Apr 2012 04:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44psnjvLgEhC for ; Fri, 27 Apr 2012 04:35:02 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id EBCCA21F87D7 for ; Fri, 27 Apr 2012 04:35:01 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 27 Apr 2012 13:34:57 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 27 Apr 2012 13:34:57 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:34:57 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:34:56 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 12:34:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 27 Apr 2012 12:34:03 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1037C7357@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kZzg9rbSRbPIHQW+e23y6KlrJSAAAMVIQ References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> < SUKNPT81 09FyqA1fnDr0001796e@SUKNPT8109.cogent-dsn.local> From: "Rick Taylor" To: "Henning Rogge" , X-OriginalArrivalTime: 27 Apr 2012 11:34:53.0125 (UTC) FILETIME=[C35A3F50:01CD2469] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18868.006 X-TM-AS-Result: No--3.668900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:35:03 -0000 > From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >=20 > With a generic parser you don't have to integrate anything new for the > right one. You just add a few numbers to an array of "TLVs you are > interested in". >=20 > No additional byte parsing code necessary. Or, in a callback-based parser, with SubTLVs, in the On_DLEP_TLV(id,data) function you just loop parsing SubTLVs, calling On_DLEP_SubTLV(). It's all just how you write it. And that shouldn't define the protocol. > I would not even notice if the DLEP_ORDER_TLV is the last TLV in the > list of message TLVs. But you would have to record that you had pending DLEP_TLVs waiting for an order. I like your ORDER_TLVs, but I think they are a potential solution to the SubTLV registry problem, not an implementation aid. > I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming > olsr.org (v2) implementation. Having something special for DLEP is just > bad and unnecessary. I'm all in favour of code reuse. A generic parser is one of the ideals of RFC5444, but your generic parser is different from my generic parser. The problem is DLEP has optional and mandatory 'parameters' to each 'order', this is 'special' when compared to OLSRv2 (as far as I understand) already. The discussion is how do we handle this 'special-ness' in the simplest way, without RFC5444bis or adding excess state to any parser. Rick Taylor From henning.rogge@fkie.fraunhofer.de Fri Apr 27 04:42:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268E21F8798 for ; Fri, 27 Apr 2012 04:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=1.579, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+QF8I1XMUMQ for ; Fri, 27 Apr 2012 04:42:16 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2244221F873C for ; Fri, 27 Apr 2012 04:42:15 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNjYy-0001LN-Fz; Fri, 27 Apr 2012 13:42:12 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SNjYy-0004cO-DL; Fri, 27 Apr 2012 13:42:12 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:42:12 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:42:11 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 13:42:11 +0200 Message-ID: <4F9A8612.2070000@fkie.fraunhofer.de> Date: Fri, 27 Apr 2012 13:42:10 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7357@SUKNPT8106.cogent-dsn.loc al> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1037C7357@SUKNPT8106.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040308090707020908070504" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 27 Apr 2012 11:42:12.0267 (UTC) FILETIME=[C919FFB0:01CD246A] X-Virus-Scanned: yes (ClamAV 0.97.3/14854/Thu Apr 26 23:51:09 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 464bb0742d7c8e8c9ed0f7b593ef686f Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:42:17 -0000 --------------ms040308090707020908070504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2012 01:34 PM, Rick Taylor wrote: >> From: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de] >> >> With a generic parser you don't have to integrate anything new for the= >> right one. You just add a few numbers to an array of "TLVs you are >> interested in". >> >> No additional byte parsing code necessary. > > Or, in a callback-based parser, with SubTLVs, in the > On_DLEP_TLV(id,data) function you just loop parsing SubTLVs, calling > On_DLEP_SubTLV(). > > It's all just how you write it. And that shouldn't define the protocol= =2E no, it doesn't work this way... because the parser would have to be=20 aware that it is a TLV which contains subtlvs, which cannot be detected=20 in the generic case. >> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the >> list of message TLVs. > > But you would have to record that you had pending DLEP_TLVs waiting for= > an order. No, I do not. I don't parse the TLVs in my protocol code in the order=20 they are in the message. I set up a static array where I define which TLVs I am interested in and = the parser fills up the existing TLVs into this array. This means I get=20 all the tlvs of message level at once, instead of getting them piece by=20 piece. Makes parsing things a lot easier. See=20 http://olsr.org/git/?p=3Dframework.git;a=3Dtree;f=3Dsrc-api/packetbb;h=3D= 5bc637e8522633fc2704ff12597e6383d45f3799;hb=3Dmaster I still have to update the documentation for the latest change (which=20 has to do with registering the used address-TLVs), but most of the=20 documentation is okay. http://olsr.org/git/?p=3Dframework.git;a=3Dtree;f=3Ddocs/packetbb;h=3D0e4= c3ee1f30530718b53759a8c7d60ec7c20d27f;hb=3Dmaster Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040308090707020908070504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA0MjcxMTQyMTBaMCMGCSqGSIb3DQEJBDEWBBS5STU7dxKGtqED/GdsHGphxFn+7zBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCIVh8RMAowx8NYMNV86sivGpl1H46wWV3+DryJKWqZHq2kWr+J2iKy+iOf3yxQ Ze/ApZvPvkWH9w8Rf3P/CM0/AmYgR0uI0m4hjwjtPLjN/mxSdQZmTJpR+fPmrUCGxFKI4ezL IH0rW4qidxbbwTkcKe4poC71/QILVwfwKEdDG4Byz29JRmpABDTG8s54CdROJIEkpPdB4SWb +qLQN/bvsaegfL5en6BgL7uGZ9cmVTLEtC0LTeLK5f1Tb6VUgd2NuiQh41EaOEv8lBDiiVNj 44phOVTzpeH5k5Z3SOYwHfjnJ5EvqpQ7AD0BmkkTY9HzVYkAMNdzeGPOymh0ltyVAAAAAAAA --------------ms040308090707020908070504-- From Chris.Dearlove@baesystems.com Fri Apr 27 05:55:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E496E21F86E1 for ; Fri, 27 Apr 2012 05:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2MGwHWtRSxI for ; Fri, 27 Apr 2012 05:55:26 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6B97F21F86DE for ; Fri, 27 Apr 2012 05:55:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="234594211" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 13:55:24 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3RCtOmp017431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 13:55:24 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 13:55:24 +0100 From: "Dearlove, Christopher (UK)" To: Bo Berry , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kYfY6QS6Ej0n5skifyF6SVWSSeAAAt6qw///zuACAAAJVgP//121Q Date: Fri, 27 Apr 2012 12:55:23 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local><4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com><27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com><5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com><7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 12:55:27 -0000 I think the diff parsers etc. misses the point. If DLEP is to use 5444 then= having a 5444 parser may be taken as the starting point. And without sub-T= LVs that's all the parser you need. I'm afraid I think this is a clear case of design using 5444 without really= appreciating it. And then when people who have greater familiarity with 54= 44 suggest what is a more natural use of 5444, meeting a resistance that ma= y be based on several things, but offering a better fit to 5444 and better = parsing options are not among those things. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry Sent: 27 April 2012 12:24 To: Henning Rogge Cc: manet@ietf.org Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote: > On 04/27/2012 01:09 PM, Rick Taylor wrote: >> I think we are in danger of letting the tail wag the dog here. >>=20 >> The best DLEP spec will result in specifying what needs to be there >> by analysing the use-cases and taking into account >> transportcharacteristics. Not how easy it makes implementers jobs. >> Obviously, specifying something totally wacky is never a good idea, but >> really, what is the difference between... >>=20 >> Packet AND Packet >> | | >> +-Message +-Message >> | | >> +-DLEP_TLV +-DLEP_ORDER_TLV >> | | >> +-SubTLV_1 +-DLEP_TLV_1 >> | | >> +-SubTLV_2 +-DLEP_TLV_2 >> : : >>=20 >>=20 >> ...as far as the parser is concerned? From my perspective, Stan's >> Sub-TLV's are possibly easier to integrate into an existing parser than >> having to maintain the state at the message processing level in >> Henning's model. >=20 > With a generic parser you don't have to integrate anything new for the ri= ght one. You just add a few numbers to an array of "TLVs you are interested= in". >=20 > No additional byte parsing code necessary. >=20 > I would not even notice if the DLEP_ORDER_TLV is the last TLV in the list= of message TLVs. >=20 > I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming ols= r.org (v2) implementation. Having something special for DLEP is just bad an= d unnecessary. >From your perspective I can understand that position. But there are others= that have diff parsers, diff protocols, diff radios, networks, etc. Ricks= ' caution is a good one. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole us= e of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or au= thorized to receive for the recipient), please contact the sender by reply = email and delete all copies of this message. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From hrogge@googlemail.com Fri Apr 27 06:32:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4948521F86DB for ; Fri, 27 Apr 2012 06:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu8-v4bs+Euj for ; Fri, 27 Apr 2012 06:32:00 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3675421F86D5 for ; Fri, 27 Apr 2012 06:32:00 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so557153lbb.31 for ; Fri, 27 Apr 2012 06:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=tYSb72XJNpe6B68wXFH4lW7bI65nklT5DIKzyP5pAfM=; b=Mgs3fXiufcrTbDnHQL3tW2f5ic9ZQnkzI+T8+yhpAJyOoaeZVuG7SHeCTDBK0ngLr1 dKmwk6hG+f49PEdLP3ROYkMqhHmNNPf6S5ya1vGsiE6F05rLzLhbyHoPPDD7IOjajYOy fOwcmZ+mv3+i3bph3P1Y38GGj6nJc19E68w34NzJSAn+EK3cccOgVbaBiLi9jw+8mUxx dkTk4LBj7Kugrwwg8H71aY37G4AQwN10yDpoTn8RxYuOaNF9Bsc+rYT34Gy+AnpVJxVb hsJF0BJnX5yDppwfW5meGfvhC9sM7+Q8EwuMDiclbdf6gAmGZhhmVsRBq2iEgLnDWgaT O8aA== Received: by 10.152.146.129 with SMTP id tc1mr13043lab.27.1335533519189; Fri, 27 Apr 2012 06:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 27 Apr 2012 06:31:38 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent-dsn.local> From: Henning Rogge Date: Fri, 27 Apr 2012 15:31:38 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:32:01 -0000 On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) wrote: > I think the diff parsers etc. misses the point. If DLEP is to use 5444 th= en having a 5444 parser may be taken as the starting point. And without sub= -TLVs that's all the parser you need. Exactly. > I'm afraid I think this is a clear case of design using 5444 without real= ly appreciating it. And then when people who have greater familiarity with = 5444 suggest what is a more natural use of 5444, meeting a resistance that = may be based on several things, but offering a better fit to 5444 and bette= r parsing options are not among those things. Yes. At the moment DLEP is not using RFC5444 at all... except as a wrapper around its own format. And everything DLEP does at the moment can be expressed in a reasonable way within RFC5444. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From dsatterw@cisco.com Fri Apr 27 07:17:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114621F8685 for ; Fri, 27 Apr 2012 07:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.489 X-Spam-Level: X-Spam-Status: No, score=-8.489 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYH3PezmdKw5 for ; Fri, 27 Apr 2012 07:16:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 86B4321F8683 for ; Fri, 27 Apr 2012 07:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=2068; q=dns/txt; s=iport; t=1335536219; x=1336745819; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=GkLaD59nCRRqIuxRc2IKhUYQLuEfd8f9J6A299bsBj8=; b=QbSrfVdON6/9hFL2bKhb8xneEcp5AW0YkCdcKXQirWvTbzTrvEruUuuw T0awJr47BWib06GPf06lKVzt9YR2QyoiUmUT391sf50FfC/1az+pMpoHD 3J3J5gxHFMNe1GjFILJD4IqO+B9I6+oFxMumbTFmJZagH2pvLn6vCqsWQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHALypmk+tJXHB/2dsb2JhbABEiiunPQKBB4IJAQEBAwESAScCATcFBQ0BCAkFCoEFAQEEDgUih10DBgWcTZZUDYlTigeHPASOEIdtjleBaYME X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="78450832" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 27 Apr 2012 14:16:59 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3REGxxX026836; Fri, 27 Apr 2012 14:16:59 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 09:16:58 -0500 Received: from 64.102.54.133 ([64.102.54.133]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Apr 2012 14:16:58 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 27 Apr 2012 10:17:29 -0400 From: dsatterw To: Henning Rogge , "Dearlove, Christopher (UK)" Message-ID: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kgHpOs0In1BtiO0apiKhvJ4rgxQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2012 14:16:58.0865 (UTC) FILETIME=[68586610:01CD2480] Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:17:00 -0000 I personally have an issue at this stage of the game (we are now on our 3rd version of DLEP) of having to completely rewrite our packet format so that it better integrates into RFC5444. At this point we have at least 4 working implementations of DLEP out there which were all based on our sourceforge example of a packet parser that seems sufficient for the ones involved. If we, at this point, decide to rewrite the packet formats then everyone that has working versions today would have work to do without really any benefit IMO. If this objection were brought up in the 00 or 01 version of the draft it would be a little easier to accept than year(s) later. To be quite honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444 states that it should be used by routing protocols for information exchange and DLEP is not a routing protocol. I would really rather spend our time trying to make sure that the content being exchanged between the radio and router is adequate than arguing about packet parsers. Darryl Satterwhite Cisco Systems On 4/27/12 9:31 AM, "Henning Rogge" wrote: > On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) > wrote: >> I think the diff parsers etc. misses the point. If DLEP is to use 5444 then >> having a 5444 parser may be taken as the starting point. And without sub-TLVs >> that's all the parser you need. > > Exactly. > >> I'm afraid I think this is a clear case of design using 5444 without really >> appreciating it. And then when people who have greater familiarity with 5444 >> suggest what is a more natural use of 5444, meeting a resistance that may be >> based on several things, but offering a better fit to 5444 and better parsing >> options are not among those things. > > Yes. > > At the moment DLEP is not using RFC5444 at all... except as a wrapper > around its own format. And everything DLEP does at the moment can be > expressed in a reasonable way within RFC5444. > > Henning Rogge From sratliff@cisco.com Fri Apr 27 07:26:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903AC21F85DD for ; Fri, 27 Apr 2012 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izio4j50qyZy for ; Fri, 27 Apr 2012 07:26:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F3C0021F85E5 for ; Fri, 27 Apr 2012 07:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11336; q=dns/txt; s=iport; t=1335536811; x=1336746411; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=UyMNkJueYHqMY8WwuUOs6TR2t3ztl4vtbGiGuO6Jub0=; b=diXD40KqdzqX7suVYMvkJwfLvV5cmQJ4jCckC3F81Vi1w0D23QduZ117 8OwKv84+Nxfbf9LR+bKl7VjY18r6qQXSBcoOjPH47K7evWND/T2XBRGnY qily5BhaHrN2Xn558NUf4Uqs4HNbv2QU0/9DU8HeZuJiBCgu4YE64IN0d M=; X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208,217";a="75434827" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 27 Apr 2012 14:26:49 +0000 Received: from dhcp-64-102-54-245.cisco.com (dhcp-64-102-54-245.cisco.com [64.102.54.245]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3REQmaF014042; Fri, 27 Apr 2012 14:26:49 GMT Message-Id: <2DAFB89A-E999-4124-8BA8-2DEB90543039@cisco.com> From: Stan Ratliff To: Thomas Heide Clausen In-Reply-To: <4A4F3F42-8D33-422F-BDF4-4ED33DBC0F0D@thomasclausen.org> Content-Type: multipart/alternative; boundary=Apple-Mail-15-747324107 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Apr 2012 10:26:49 -0400 References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31 B0093014224A843C10C0CCE92AC10378D143@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <2E4A2099-1FB9-407A-8C22-F224DEBBD8CF@cisco.com> <4A4F3F42-8D33-422F-BDF4-4ED33DBC0F0D@thomasclausen.org> X-Mailer: Apple Mail (2.936) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:26:52 -0000 --Apple-Mail-15-747324107 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thomas, Yes, I agree with that. What I was discussing was an earlier comment that the multiple registries somehow "made the code easier". I don't buy that. Regards, Stan On Apr 26, 2012, at 5:13 PM, Thomas Heide Clausen wrote: > Stan, > > I'm not Ulrich, but I am one of the authors of RFC5444. > > In RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are > different entities, doing different things and applying in different > contexts. Therefore, there are different registries for these. > > It's therefore not a matter of "registering the same thing multiple > times". Rather, it's merely a convenience if the same mnemonic maps > to the same numerical value, regardless of in which context it's used. > > If IANA does not get things "matched up correctly", that doesn't > break things - but generally, vigilant designated experts and > attentive working-groups should be able to keep registries sane and > safe ;) > > Best, > > Thomas > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are > held to > discuss it." > -- Mitchell's Law of Committees > > > On 26 Apr 2012, at 21:06, Stan Ratliff wrote: > >> Ulrich, >> >> JMO, but that just makes my point - this is "easier"? Having to >> check & double-check to make sure some poor individual in IANA gets >> the allocations matched up correctly? >> >> Stan >> >> On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote: >> >>> Stan, >>> >>> I think you should have been in CC of some mails between the >>> authors of packetbb-sec and IANA. I suggested to IANA to use the >>> same values instead. They requested confirmation by the chairs. >>> The registration process for packetbb-sec is not yet finished, so >>> that can still be changed. >>> >>> Regards >>> Ulrich >>> >>> >>> >>> On Thu, Apr 26, 2012 at 11:57 AM, Stan Ratliff >>> wrote: >>> BTW - according to a quick read by one of my co-authors, , ICV and >>> TIMESTAMP TLVs have different type values for packet/message/ >>> address TLVs. How does that simplify things? >>> >>> Stan >>> >>> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >>> >>>> Stan, >>>> >>>> why should it complicate things? Have a look at the MANET regsitry: >>>> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#message-type-ranges >>>> >>>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV >>>> and TIMESTAMP TLVs as message and as address block TLVs. I have >>>> implemented NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV >>>> types are the same (which I hope they will be for packetbb- >>>> sec ;-), there is no more code complexity. I have implemented the >>>> different TLVs only once. >>>> >>>> Regards >>>> Ulrich >>>> >>>> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff >>>> wrote: >>>> >>>> >>>>> >>>>> Yes, that is exactly what we did for all the other drafts/RFCs >>>>> in MANET, for example, for the packetbb-sec RFC-to-be. I think >>>>> it is wise to use the same TLV types for packet/message/address- >>>>> block TLVs. Setting up registries is trivial and does not >>>>> complicate code. >>>>> >>>> >>>> I disagree - it does complicate things. Both code-wise, and >>>> administratively. The fact that it's been done before means >>>> little to me. >>>> >>>> Stan >>>> >>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-15-747324107 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Regards,
Stan
On Apr 26, 2012, at 5:13 PM, Thomas Heide Clausen = wrote:

Stan,

I'm not Ulrich, = but I am one of the authors of RFC5444.

In = RFC5444, Packet-TLVs, Message-TLVs and Address-block-TLVs are different = entities, doing different things and applying in different contexts. = Therefore, there are different registries for = these. 

It's therefore not a matter of = "registering the same thing multiple times". Rather, it's merely a = convenience if the same mnemonic maps to the same numerical value, = regardless of in which context it's used.

If = IANA does not get things "matched up correctly", that doesn't break = things - but generally, vigilant designated experts and attentive = working-groups should be able to keep registries sane and safe = ;)

Best,

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/
"Any = simple problem can be made insoluble if enough meetings are held = to
 discuss it."
   -- Mitchell's Law = of Committees


On 26 Apr 2012, = at 21:06, Stan Ratliff <sratliff@cisco.com> = wrote:

Ulrich, 

JMO, but that just = makes my point - this is "easier"? Having to check & double-check to = make sure some poor individual in IANA gets the allocations matched up = correctly?

Stan

On Apr 26, 2012, at 3:00 PM, Ulrich Herberg wrote:

Stan,

I think you should have been in CC of = some mails between the authors of packetbb-sec and IANA. I suggested to = IANA to use the same values instead. They requested confirmation by the = chairs. The registration process for packetbb-sec is not yet finished, = so that can still be changed.
=
Regards
Ulrich



On Thu, = Apr 26, 2012 at 11:57 AM, Stan Ratliff <sratliff@cisco.com> wrote:
=
BTW - according to a quick read by one of = my co-authors, , ICV and TIMESTAMP TLVs have different type = values for packet/message/address TLVs. How does that simplify = things?
=
Stan

On Apr 26, 2012, at 2:35 PM, Ulrich Herberg = wrote:

Stan,

why should it = complicate things? Have a look at the MANET regsitry:
http://www.iana.org/assignments/manet-parameters/manet-p= arameters.xml#message-type-ranges

We have VALIDITY_TIME and = INTERVAL_TIME, as well as the newer ICV and TIMESTAMP TLVs as message = and as address block TLVs. I have implemented NHDP/OLSRv2 and = packetbb-sec. Assuming that the TLV types are the same (which I hope = they will be for packetbb-sec ;-), there is no more code complexity. I = have implemented the different TLVs only once.
=
Regards
Ulrich

On Thu, Apr 26, = 2012 at 11:32 AM, Stan Ratliff <sratliff@cisco.com> = wrote:



Yes, that is exactly what we did for all = the other drafts/RFCs in MANET,  for example, for the packetbb-sec = RFC-to-be. I think it is wise to use the same TLV types for = packet/message/address-block TLVs. Setting up registries is trivial and = does not complicate code.
=

I = disagree - it does complicate things. Both code-wise, and = administratively. The fact that it's been done before means little to = me.

Stan


Regards
Ulrich



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





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

= --Apple-Mail-15-747324107-- From ulrich@herberg.name Fri Apr 27 07:35:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919FE21F861B for ; Fri, 27 Apr 2012 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+stIoSTOCZ4 for ; Fri, 27 Apr 2012 07:35:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A027221F861A for ; Fri, 27 Apr 2012 07:35:25 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1079434pbb.31 for ; Fri, 27 Apr 2012 07:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=HduNeDkPRUMuRMa4JDGTtkIZZKWWqxRnt+q1DQJM3lk=; b=gs/QGJyjHahN9BUW6C4gdtFgo4RT4FvY7HCPExTIezKqyMeDE7TnXgRHs9l33KvYe9 Ec7JL9BuhSzFvLwCipR/LFPg+I7ATkOLDyMdzpifAUkW/dReaLSg8fK2qRxf3n7INYyc gDhQ+1WDndJbad4RpoHR433+tz/3HLID5hU4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=HduNeDkPRUMuRMa4JDGTtkIZZKWWqxRnt+q1DQJM3lk=; b=MBnqPwb7Gbs8bZmVNX5aFvSqshFbrKRGSruf3mRhuruY1g+u6fmigTfzOmNCpWV29k Zur9klvzN+F2zimIxWZh4DHnvSjC9Uy9BdHNcg3BEuPa1CU4J3/u5ckizS08OGfFkpDU bqUsritzcyKzjmjaHIA9JcGDNif3DZPaJ8mA0bPGrqQT25u4hCq/OiWOIGadpnGWkOGD 6eyOCtyT7DJyQlr/kdmAfD73QKHpxVGSCHOxdmrViilJu1kmRqDM7aae8QQHy7rs24ou r7G891AHsaqe7Fozx98nngwXjCQQHml3Iv1t+s5uPIA9M6VxgvQvA49dEN8ELComRuiK 7yrQ== Received: by 10.68.227.99 with SMTP id rz3mr9428689pbc.159.1335537325167; Fri, 27 Apr 2012 07:35:25 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id ua10sm2090176pbc.20.2012.04.27.07.35.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 07:35:23 -0700 (PDT) References: <2D4D9DC4-90EA-42B2-94E0-DBB79BF6B98F@cisco.com> <7B31B0093014224A843C10C0CCE92AC10378CC4E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378CD0E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC10378D07A@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3CECD3D8-2C8F-427C-8AB4-880DF389BD0D@herberg.name> X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 07:35:18 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQm2yqhN1QnZN8PaZeo4+P2GP0pfy2osi8V5cT9HBKuY1ioAZVgDBTIiaLOHpQ1UN/AMa4xY Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:35:26 -0000 My hand is up, too. Ulrich On Apr 27, 2012, at 2:34, "Dearlove, Christopher (UK)" wrote: > It's not entirely subjective. Hands up those who have written 5444 parsing= code, don't have any problems with different TLV spaces, and would find sub= -TLVs much more complicated. >=20 > My hand is up. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com]=20 > Sent: 26 April 2012 19:59 > To: Henning Rogge > Cc: Ulrich Herberg; Dearlove, Christopher (UK); manet@ietf.org; Bo Berry > Subject: Re: [manet] DLEP and TLV breakdown >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > And I guess that's the crux of the subjective crossroads we find =20 > ourselves at. At least with the sub-TLV's, you always know that CDR is =20= > CDR, because it's only defined once. >=20 > Stan >=20 > On Apr 26, 2012, at 2:55 PM, Henning Rogge wrote: >=20 >> Adding something proprietary like "subtlvs" is a lot worse. Its an >> additional dimension for the registries and for the parser/generator. >>=20 >> Henning Rogge >>=20 >> On Thu, Apr 26, 2012 at 20:52, Stan Ratliff =20 >> wrote: >>> Why does it complicate things? >>> As you said - "Assuming that the TLV types are the same..." Not =20 >>> only now, >>> but on down the line if/when we want to add TLVs? You can guarantee =20 >>> that >>> will always be the case? >>>=20 >>> Stan >>>=20 >>> On Apr 26, 2012, at 2:35 PM, Ulrich Herberg wrote: >>>=20 >>> Stan, >>>=20 >>> why should it complicate things? Have a look at the MANET regsitry: >>> http://www.iana.org/assignments/manet-parameters/manet-parameters.xml#me= ssage-type-ranges >>>=20 >>> We have VALIDITY_TIME and INTERVAL_TIME, as well as the newer ICV and >>> TIMESTAMP TLVs as message and as address block TLVs. I have =20 >>> implemented >>> NHDP/OLSRv2 and packetbb-sec. Assuming that the TLV types are the =20 >>> same >>> (which I hope they will be for packetbb-sec ;-), there is no more =20 >>> code >>> complexity. I have implemented the different TLVs only once. >>>=20 >>> Regards >>> Ulrich >>>=20 >>> On Thu, Apr 26, 2012 at 11:32 AM, Stan Ratliff =20 >>> wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Yes, that is exactly what we did for all the other drafts/RFCs in =20 >>>> MANET, >>>> for example, for the packetbb-sec RFC-to-be. I think it is wise to =20 >>>> use the >>>> same TLV types for packet/message/address-block TLVs. Setting up =20 >>>> registries >>>> is trivial and does not complicate code. >>>>=20 >>>>=20 >>>> I disagree - it does complicate things. Both code-wise, and >>>> administratively. The fact that it's been done before means little =20 >>>> to me. >>>>=20 >>>> Stan >>>>=20 >>>>=20 >>>> Regards >>>> Ulrich >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From hrogge@googlemail.com Fri Apr 27 07:36:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4C21F861B for ; Fri, 27 Apr 2012 07:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2KFeEiR+-iF for ; Fri, 27 Apr 2012 07:36:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2521F8684 for ; Fri, 27 Apr 2012 07:36:47 -0700 (PDT) Received: by lagj5 with SMTP id j5so614887lag.31 for ; Fri, 27 Apr 2012 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RuJLEUSmhv37c+xs0th+C+HQjtfCUsr0cYAnhCEJHYQ=; b=Xb7+VlXA0jOJLvL2xXHIPuxrfBXPKNJL0mzbqoBFMe9zveOXe5DeSUe2Q/oYhuXKNC ncbrruq92KbqZ9efpQw9p7R+9XTwaPJzjGZy1Im2WywLoTOKmchmZ/mAbCpIuMTK+lUX nCuGdYwIw4CttHEGYdejgbvy3kq/iiIl8rmzw+1Wy/w0aho5aMyC27EVLfmZFzsbu3K7 kw4nMj9Z43V+XDB5n7HCUEQp5tqL4RbNHyMDrX2qD8XgwW604jD3jdJjnpAlFpXg3mHP ZRQw8cFQ6sySVLYzl7qJ+3TYrUdAc3d9COWb6KOkI0AMAA0ZHTEndhzIt/z/1i3wup6g QItw== Received: by 10.152.112.161 with SMTP id ir1mr10863849lab.13.1335537406439; Fri, 27 Apr 2012 07:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 27 Apr 2012 07:36:26 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 27 Apr 2012 16:36:26 +0200 Message-ID: To: dsatterw Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:36:52 -0000 On Fri, Apr 27, 2012 at 16:17, dsatterw wrote: > I personally have an issue at this stage of the game (we are now on our 3rd > version of DLEP) of having to completely rewrite our packet format so that > it better integrates into RFC5444. At this point we have at least 4 working > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. If > we, at this point, decide to rewrite the packet formats then everyone that > has working versions today would have work to do without really any benefit > IMO. If this objection were brought up in the 00 or 01 version of the draft > it would be a little easier to accept than year(s) later. DLEP-00 did not even contain the concept of subtlvs. But I must admit that I missed the introduction of subtlvs in DLEP-01. I only noticed them again when I tried to start to implement DLEP-02 and found out, that it defined its own byte format. > honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444 > states that it should be used by routing protocols for information exchange > and DLEP is not a routing protocol. I would really rather spend our time > trying to make sure that the content being exchanged between the radio and > router is adequate than arguing about packet parsers. I disagree completely. DLEP is mostly presenting data about layer2 that reminds me very strong to what NHDP is presenting (just a layer higher). The structure of RFC5444 with messages that contain both message-level information and multiple addresses with attached information is fitting very well to the concept of DLEP. Thats not a guess from my side, I implemented a RFC5444-compatible DLEP protocol (at least the session and metric part) in the last month to test it. Also RFC5444 would make it very easy to extend DLEP later without breaking compatibility quite a lot. At the moment DLEP use some of the mechanisms of RFC5444 without realizing what you can do with them. One example is the "Relative Link Quality Sub-TLV" and its 'default'. I understand the need of default values in protocol with a fixed header format, but its quite useless for TLV-based packet formats. Why using a dual-meaning encoding (perfect link = I cannot measure it?) when you just can drop the TLV from the message to tell the application "cannot calculate it"? But I agree, that the communication at the start of DLEP could have been better. From both sides. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Fri Apr 27 07:45:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1C121F856D for ; Fri, 27 Apr 2012 07:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 851hKyDvhsMG for ; Fri, 27 Apr 2012 07:45:00 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F621F86A6 for ; Fri, 27 Apr 2012 07:45:00 -0700 (PDT) Received: by dady13 with SMTP id y13so1464223dad.27 for ; Fri, 27 Apr 2012 07:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=m9iR5Lg3RT/GdkR+2mVNxUs67SBGRXYTJWqOzanUpog=; b=P7AYO1AEDAGoLGK+jJszEvC5syUBtjhJ5XdssKWPZj4KZMP+7seM48ZxHuwCdfsmP3 yRglvPzIOo4mU9tZGRLTl3sZwk35/uiHEr902K6x2k4ob87pcAr4LhUL+8BusSd7BGtF HWMQOHhV6xlgc+rT5ueF10e4AfRJ31FG7M1N0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=m9iR5Lg3RT/GdkR+2mVNxUs67SBGRXYTJWqOzanUpog=; b=DwHyilMtH0jG1Orv1KNR/HglvUbb9uPmi5QBQ49kqQU2d65K3gZeCVpblg/GUflZ71 tTmrfzuzoDLae5jANcnw0CsH4BkXvRRY7W+NjNp/2hTg7fcE+C1H1ooDVUpwBc2gGQrm GvdD52H9EBUTzEJpOHcTvrArTlaArtJ8Gp/Uhh3+kEnpqCCtMski62becsz8vvkO1AYJ 6EDw9gtXqzsY25PK8GEiGth+SilNgLa+EhCCr72+rllgeut5bzwFokCfQBAJ0gjA0v/W YaECKXnIKpNS0IkmglHkgFwobn6eaSJ/yMhGOw2bZEZFh8Bami8QQoXbxMJJSvICP2KB Q0fA== Received: by 10.68.130.170 with SMTP id of10mr5643322pbb.156.1335537900390; Fri, 27 Apr 2012 07:45:00 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id po10sm6680828pbb.17.2012.04.27.07.44.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 07:44:59 -0700 (PDT) References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent -dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 07:44:56 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQnxgekrHLmKn2kXHiPDVxHsfpi4PQbG0+5jhn7VC8QYNMHddWMSO5Go9XgM3w4WSo5yDemh Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:45:02 -0000 I totally agree with Chris. I think he said in a previous email , "take it o= r leave it". Not using RFC5444 in DLEP would be acceptable for me, but if it= uses it, then it should use it correctly. It has been pointed out by severa= l of the authors of RFC5444 as well as by several implementers how to do tha= t. I don't understand the resistance. There seems to be a rough concensus on= that in the WG (besides by the authors), and the draft is a WG draft, not a= n individual draft. Ulrich On Apr 27, 2012, at 5:55, "Dearlove, Christopher (UK)" wrote: > I think the diff parsers etc. misses the point. If DLEP is to use 5444 the= n having a 5444 parser may be taken as the starting point. And without sub-T= LVs that's all the parser you need. >=20 > I'm afraid I think this is a clear case of design using 5444 without reall= y appreciating it. And then when people who have greater familiarity with 54= 44 suggest what is a more natural use of 5444, meeting a resistance that may= be based on several things, but offering a better fit to 5444 and better pa= rsing options are not among those things. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of B= o Berry > Sent: 27 April 2012 12:24 > To: Henning Rogge > Cc: manet@ietf.org > Subject: Re: [manet] DLEP and TLV breakdown >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote: >=20 >> On 04/27/2012 01:09 PM, Rick Taylor wrote: >>> I think we are in danger of letting the tail wag the dog here. >>>=20 >>> The best DLEP spec will result in specifying what needs to be there >>> by analysing the use-cases and taking into account >>> transportcharacteristics. Not how easy it makes implementers jobs. >>> Obviously, specifying something totally wacky is never a good idea, but >>> really, what is the difference between... >>>=20 >>> Packet AND Packet >>> | | >>> +-Message +-Message >>> | | >>> +-DLEP_TLV +-DLEP_ORDER_TLV >>> | | >>> +-SubTLV_1 +-DLEP_TLV_1 >>> | | >>> +-SubTLV_2 +-DLEP_TLV_2 >>> : : >>>=20 >>>=20 >>> ...as far as the parser is concerned? =46rom my perspective, Stan's >>> Sub-TLV's are possibly easier to integrate into an existing parser than >>> having to maintain the state at the message processing level in >>> Henning's model. >>=20 >> With a generic parser you don't have to integrate anything new for the ri= ght one. You just add a few numbers to an array of "TLVs you are interested i= n". >>=20 >> No additional byte parsing code necessary. >>=20 >> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the list= of message TLVs. >>=20 >> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming ols= r.org (v2) implementation. Having something special for DLEP is just bad and= unnecessary. >=20 > =46rom your perspective I can understand that position. But there are oth= ers that have diff parsers, diff protocols, diff radios, networks, etc. Ric= ks' caution is a good one. >=20 >=20 >=20 >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole u= se of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by o= thers is strictly prohibited. If you are not the intended recipient (or auth= orized to receive for the recipient), please contact the sender by reply ema= il and delete all copies of this message. >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Apr 27 07:49:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5721F86B4 for ; Fri, 27 Apr 2012 07:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvAiwMPz425E for ; Fri, 27 Apr 2012 07:49:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5121F86B3 for ; Fri, 27 Apr 2012 07:49:30 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1094397pbb.31 for ; Fri, 27 Apr 2012 07:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=XL5s4Tsj2yzYb8Rhd3Oi4xWyw/O3lJYHTv56cr+oeOo=; b=Euj1o150oTHf2+9br3vj+9+9peVtgtMaUe+iT3OBf68e7PLc5juLQvS2rzZcA62Gda SvoLKDRIjAHr0AJvz64z5xDQDNpxF11XfqBNOe4jDAMXJWPAvyfWKTBQXeJQ0WkJh9K9 uddC/06a4W3dLjNOCQG0Xika7KfMe92/bftZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=XL5s4Tsj2yzYb8Rhd3Oi4xWyw/O3lJYHTv56cr+oeOo=; b=k7AyMMtpdkU38Cjg6izMd3VC726EX4/J5/gdqNnt0yYD/1tHpgEjvFYeSfzTTE/PlZ kVtF99V2MtXcd69WcJZ3QE+m8SmJyodj2FnPjr8TLKhUHmFrXTzJSkH0RFWjAtscp0z0 590OdLCLls2PL+eqy+CTbiS3LGn5WcpUKz1sGMU6qWL6iz/HrpYeRztaDMHmCIUUYZB6 OMf04iCzGZh9vLo2iWE9JINb4XahfweVU1cpYcYO41PAMf3wA/VVxcZZGcFvMvv3hCGf UMZ8jEatI4hXkJAIRCcDCFLiUACOqutmlY74Sdw5sbh7+iYs/QgYFgU+jcpfRmKQHWJC EkVg== Received: by 10.68.217.201 with SMTP id pa9mr1877079pbc.73.1335538170803; Fri, 27 Apr 2012 07:49:30 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id ry4sm6681717pbc.27.2012.04.27.07.49.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 07:49:29 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <208E5BD4-D910-492A-9815-88112E57AD19@herberg.name> X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 07:49:27 -0700 To: dsatterw X-Gm-Message-State: ALoCoQm6ZeXXO7XvJtDZwc+NIn4Q2cJUP7fwehG1EFmyUFCZJTzOh0FGcJ4xZijQXwvy5NHI9W2K Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:49:31 -0000 Darryl, I don't believe that to be an argument. I still believe the WG should do its= best job to come up with the best solution. DLEP is a WG document and uses= RFC5444, but not correctly. That worries me, and the only real counter-argu= ment to the suggested changes so far has been "we have an existing implement= ation and don't want to change it.". Ulrich On Apr 27, 2012, at 7:17, dsatterw wrote: > I personally have an issue at this stage of the game (we are now on our 3r= d > version of DLEP) of having to completely rewrite our packet format so that= > it better integrates into RFC5444. At this point we have at least 4 workin= g > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. If= > we, at this point, decide to rewrite the packet formats then everyone that= > has working versions today would have work to do without really any benefi= t > IMO. If this objection were brought up in the 00 or 01 version of the draf= t > it would be a little easier to accept than year(s) later. To be quite > honest, I don't think DLEP fits well in RFC5444 in the first place. RFC544= 4 > states that it should be used by routing protocols for information exchang= e > and DLEP is not a routing protocol. I would really rather spend our time > trying to make sure that the content being exchanged between the radio and= > router is adequate than arguing about packet parsers. >=20 > Darryl Satterwhite > Cisco Systems >=20 >=20 > On 4/27/12 9:31 AM, "Henning Rogge" wrote: >=20 >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) >> wrote: >>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 t= hen >>> having a 5444 parser may be taken as the starting point. And without sub= -TLVs >>> that's all the parser you need. >>=20 >> Exactly. >>=20 >>> I'm afraid I think this is a clear case of design using 5444 without rea= lly >>> appreciating it. And then when people who have greater familiarity with 5= 444 >>> suggest what is a more natural use of 5444, meeting a resistance that ma= y be >>> based on several things, but offering a better fit to 5444 and better pa= rsing >>> options are not among those things. >>=20 >> Yes. >>=20 >> At the moment DLEP is not using RFC5444 at all... except as a wrapper >> around its own format. And everything DLEP does at the moment can be >> expressed in a reasonable way within RFC5444. >>=20 >> Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Fri Apr 27 07:59:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2290021F8700 for ; Fri, 27 Apr 2012 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLdEtMDeu876 for ; Fri, 27 Apr 2012 07:59:53 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA321F86F2 for ; Fri, 27 Apr 2012 07:59:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="234628393" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 15:59:52 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3RExpnM027315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 15:59:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 15:59:51 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kYfY6QS6Ej0n5skifyF6SVWSSeAAAt6qw///zuACAAAJVgP//121QgABguAD//+4AgA== Date: Fri, 27 Apr 2012 14:59:50 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent -dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:59:55 -0000 SSBiZWxpZXZlIHRoZSBjb250ZXh0IGZvciAidGFrZSBpdCBvciBsZWF2ZSBpdCIgKHdoaWNoIG1p Z2h0IG90aGVyd2lzZSBiZSBtaXN1bmRlcnN0b29kKSB3YXMgdGhhdCA1NDQ0IGlzIHByb3ZpZGVk IG9uIGEgdGFrZSBpdCBvciBsZWF2ZSBpdCBiYXNpcy4gQW5kIGFsdGhvdWdoIGFzIGFuIGF1dGhv ciBvZiA1NDQ0IEkgZmluZCBpdCBncmF0aWZ5aW5nIHdoZW4gYW55b25lIHdhbnRzIHRvIHVzZSBp dCwgSSB3b3VsZCBhbHdheXMgc2F5IHRoYXQgNTQ0NCBpcyBnb29kIGZvciBzb21lIHRoaW5ncyBh bmQgbGVzcyBnb29kIGZvciBvdGhlcnMuIEhvd2V2ZXIgSSBkbyB0aGluayB0aGF0IGlmIHVzZWQg dGhlbiBtb3JlIHZhbHVlIGlzIGdhaW5lZCBpZiBpdCBpcyB1c2VkIGluIHNvbWUgd2F5cyByYXRo ZXIgdGhhbiBvdGhlcnMuDQoNCihUaGUgb25seSBwbGFjZSB3aGVyZSA1NDQ0IGlzIG90aGVyIHRo YW4gb3B0aW9uYWwgaXMgYXMgZGVzY3JpYmVkIGluIDU0OTgsIGJ1dCBJIGRvbid0IHRoaW5rIHdl IGFyZSBkaXNjdXNzaW5nIHRoYXQgcHJvdG9jb2wvcG9ydC4pDQoNCi0tIA0KQ2hyaXN0b3BoZXIg RGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIENvbW11bmljYXRpb25zIEdyb3Vw DQpDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkN CkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVs ZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAx MjQ1IDI0MjE5NMKgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyAoT3Bl cmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2UsIFBPIEJv eCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91Z2gsIEhhbnRzLCBH VTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAxOTk2Njg3DQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0LWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVWxyaWNoIEhl cmJlcmcNClNlbnQ6IDI3IEFwcmlsIDIwMTIgMTU6NDUNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKQ0KQ2M6IG1hbmV0QGlldGYub3JnOyBCbyBCZXJyeQ0KU3ViamVjdDogUmU6IFttYW5l dF0gRExFUCBhbmQgVExWIGJyZWFrZG93bg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJO SU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv bSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sDQplaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0 bmVyIG9yIGZyb20gdGhlIGludGVybmV0Lg0KS2VlcCB0aGlzIGluIG1pbmQgaWYgeW91IGFuc3dl ciB0aGlzIG1lc3NhZ2UuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxp bmsgb24gSVQgbWF0dGVycw0KZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91 cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCkkgdG90YWxseSBhZ3JlZSB3aXRoIENocmlzLiBJIHRoaW5r IGhlIHNhaWQgaW4gYSBwcmV2aW91cyBlbWFpbCAsICJ0YWtlIGl0IG9yIGxlYXZlIGl0Ii4gTm90 IHVzaW5nIFJGQzU0NDQgaW4gRExFUCB3b3VsZCBiZSBhY2NlcHRhYmxlIGZvciBtZSwgYnV0IGlm IGl0IHVzZXMgaXQsIHRoZW4gaXQgc2hvdWxkIHVzZSBpdCBjb3JyZWN0bHkuIEl0IGhhcyBiZWVu IHBvaW50ZWQgb3V0IGJ5IHNldmVyYWwgb2YgdGhlIGF1dGhvcnMgb2YgUkZDNTQ0NCBhcyB3ZWxs IGFzIGJ5IHNldmVyYWwgaW1wbGVtZW50ZXJzIGhvdyB0byBkbyB0aGF0LiBJIGRvbid0IHVuZGVy c3RhbmQgdGhlIHJlc2lzdGFuY2UuIFRoZXJlIHNlZW1zIHRvIGJlIGEgcm91Z2ggY29uY2Vuc3Vz IG9uIHRoYXQgaW4gdGhlIFdHIChiZXNpZGVzIGJ5IHRoZSBhdXRob3JzKSwgYW5kIHRoZSBkcmFm dCBpcyBhIFdHIGRyYWZ0LCBub3QgYW4gaW5kaXZpZHVhbCBkcmFmdC4NCg0KVWxyaWNoDQoNCk9u IEFwciAyNywgMjAxMiwgYXQgNTo1NSwgIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiA8Q2hy aXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+IHdyb3RlOg0KDQo+IEkgdGhpbmsgdGhlIGRpZmYg cGFyc2VycyBldGMuIG1pc3NlcyB0aGUgcG9pbnQuIElmIERMRVAgaXMgdG8gdXNlIDU0NDQgdGhl biBoYXZpbmcgYSA1NDQ0IHBhcnNlciBtYXkgYmUgdGFrZW4gYXMgdGhlIHN0YXJ0aW5nIHBvaW50 LiBBbmQgd2l0aG91dCBzdWItVExWcyB0aGF0J3MgYWxsIHRoZSBwYXJzZXIgeW91IG5lZWQuDQo+ IA0KPiBJJ20gYWZyYWlkIEkgdGhpbmsgdGhpcyBpcyBhIGNsZWFyIGNhc2Ugb2YgZGVzaWduIHVz aW5nIDU0NDQgd2l0aG91dCByZWFsbHkgYXBwcmVjaWF0aW5nIGl0LiBBbmQgdGhlbiB3aGVuIHBl b3BsZSB3aG8gaGF2ZSBncmVhdGVyIGZhbWlsaWFyaXR5IHdpdGggNTQ0NCBzdWdnZXN0IHdoYXQg aXMgYSBtb3JlIG5hdHVyYWwgdXNlIG9mIDU0NDQsIG1lZXRpbmcgYSByZXNpc3RhbmNlIHRoYXQg bWF5IGJlIGJhc2VkIG9uIHNldmVyYWwgdGhpbmdzLCBidXQgb2ZmZXJpbmcgYSBiZXR0ZXIgZml0 IHRvIDU0NDQgYW5kIGJldHRlciBwYXJzaW5nIG9wdGlvbnMgYXJlIG5vdCBhbW9uZyB0aG9zZSB0 aGluZ3MuDQo+IA0KPiAtLSANCj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4gU2VuaW9yIFByaW5j aXBhbCBFbmdpbmVlciwgQ29tbXVuaWNhdGlvbnMgR3JvdXANCj4gQ29tbXVuaWNhdGlvbnMsIE5l dHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQo+IEJBRSBTeXN0ZW1zIEFkdmFu Y2VkIFRlY2hub2xvZ3kgQ2VudHJlDQo+IFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNCj4gVGVsOiArNDQgMTI0NSAyNDIxOTQgfCAg RmF4OiArNDQgMTI0NSAyNDIxMjQNCj4gY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20gfCBo dHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQo+IA0KPiBCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykg TGltaXRlZA0KPiBSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBG YXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllV LCBVSw0KPiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KPiANCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm8gQmVy cnkNCj4gU2VudDogMjcgQXByaWwgMjAxMiAxMjoyNA0KPiBUbzogSGVubmluZyBSb2dnZQ0KPiBD YzogbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBhbmQgVExWIGJy ZWFrZG93bg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sDQo+IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJv bSB0aGUgaW50ZXJuZXQuDQo+IEtlZXAgdGhpcyBpbiBtaW5kIGlmIHlvdSBhbnN3ZXIgdGhpcyBt ZXNzYWdlLg0KPiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24g SVQgbWF0dGVycw0KPiBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVt YWlsIG1lc3NhZ2VzLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gT24gQXByIDI3LCAyMDEyLCBhdCA3OjE1IEFNLCBIZW5u aW5nIFJvZ2dlIHdyb3RlOg0KPiANCj4+IE9uIDA0LzI3LzIwMTIgMDE6MDkgUE0sIFJpY2sgVGF5 bG9yIHdyb3RlOg0KPj4+IEkgdGhpbmsgd2UgYXJlIGluIGRhbmdlciBvZiBsZXR0aW5nIHRoZSB0 YWlsIHdhZyB0aGUgZG9nIGhlcmUuDQo+Pj4gDQo+Pj4gVGhlIGJlc3QgRExFUCBzcGVjIHdpbGwg cmVzdWx0IGluIHNwZWNpZnlpbmcgd2hhdCBuZWVkcyB0byBiZSB0aGVyZQ0KPj4+IGJ5IGFuYWx5 c2luZyB0aGUgdXNlLWNhc2VzIGFuZCB0YWtpbmcgaW50byBhY2NvdW50DQo+Pj4gdHJhbnNwb3J0 Y2hhcmFjdGVyaXN0aWNzLiBOb3QgaG93IGVhc3kgaXQgbWFrZXMgaW1wbGVtZW50ZXJzIGpvYnMu DQo+Pj4gT2J2aW91c2x5LCBzcGVjaWZ5aW5nIHNvbWV0aGluZyB0b3RhbGx5IHdhY2t5IGlzIG5l dmVyIGEgZ29vZCBpZGVhLCBidXQNCj4+PiByZWFsbHksIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2Ug YmV0d2Vlbi4uLg0KPj4+IA0KPj4+IFBhY2tldCAgICAgICAgICAgICAgICAgICAgICAgIEFORCAg ICAgUGFja2V0DQo+Pj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ Pj4gKy1NZXNzYWdlICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLU1lc3NhZ2UNCj4+PiAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gICstRExFUF9UTFYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy1ETEVQX09SREVSX1RMVg0KPj4+ICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+PiAgICArLVN1YlRMVl8xICAgICAg ICAgICAgICAgICAgICAgICAgICArLURMRVBfVExWXzENCj4+PiAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gICAgKy1TdWJUTFZfMiAgICAgICAgICAgICAgICAg ICAgICAgICAgKy1ETEVQX1RMVl8yDQo+Pj4gICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgOg0KPj4+IA0KPj4+IA0KPj4+IC4uLmFzIGZhciBhcyB0aGUgcGFyc2VyIGlzIGNv bmNlcm5lZD8gRnJvbSBteSBwZXJzcGVjdGl2ZSwgU3RhbidzDQo+Pj4gU3ViLVRMVidzIGFyZSBw b3NzaWJseSBlYXNpZXIgdG8gaW50ZWdyYXRlIGludG8gYW4gZXhpc3RpbmcgcGFyc2VyIHRoYW4N Cj4+PiBoYXZpbmcgdG8gbWFpbnRhaW4gdGhlIHN0YXRlIGF0IHRoZSBtZXNzYWdlIHByb2Nlc3Np bmcgbGV2ZWwgaW4NCj4+PiBIZW5uaW5nJ3MgbW9kZWwuDQo+PiANCj4+IFdpdGggYSBnZW5lcmlj IHBhcnNlciB5b3UgZG9uJ3QgaGF2ZSB0byBpbnRlZ3JhdGUgYW55dGhpbmcgbmV3IGZvciB0aGUg cmlnaHQgb25lLiBZb3UganVzdCBhZGQgYSBmZXcgbnVtYmVycyB0byBhbiBhcnJheSBvZiAiVExW cyB5b3UgYXJlIGludGVyZXN0ZWQgaW4iLg0KPj4gDQo+PiBObyBhZGRpdGlvbmFsIGJ5dGUgcGFy c2luZyBjb2RlIG5lY2Vzc2FyeS4NCj4+IA0KPj4gSSB3b3VsZCBub3QgZXZlbiBub3RpY2UgaWYg dGhlIERMRVBfT1JERVJfVExWIGlzIHRoZSBsYXN0IFRMViBpbiB0aGUgbGlzdCBvZiBtZXNzYWdl IFRMVnMuDQo+PiANCj4+IEkgcGxhbiB0byB1c2UgdGhlIHNhbWUgcGFyc2VyIGZvciBOSERQLCBP TFNSdjIgYW5kIERMRVAgaW4gdGhlIGNvbWluZyBvbHNyLm9yZyAodjIpIGltcGxlbWVudGF0aW9u LiBIYXZpbmcgc29tZXRoaW5nIHNwZWNpYWwgZm9yIERMRVAgaXMganVzdCBiYWQgYW5kIHVubmVj ZXNzYXJ5Lg0KPiANCj4gRnJvbSB5b3VyIHBlcnNwZWN0aXZlIEkgY2FuIHVuZGVyc3RhbmQgdGhh dCBwb3NpdGlvbi4gIEJ1dCB0aGVyZSBhcmUgb3RoZXJzIHRoYXQgaGF2ZSBkaWZmIHBhcnNlcnMs IGRpZmYgcHJvdG9jb2xzLCBkaWZmIHJhZGlvcywgbmV0d29ya3MsIGV0Yy4gIFJpY2tzJyBjYXV0 aW9uIGlzIGEgZ29vZCBvbmUuDQo+IA0KPiANCj4gDQo+PiANCj4+IEhlbm5pbmcgUm9nZ2UNCj4+ IA0KPj4gLS0gDQo+PiBEaXBsb20tSW5mb3JtYXRpa2VyIEhlbm5pbmcgUm9nZ2UgLCBGcmF1bmhv ZmVyLUluc3RpdHV0IGbDvHINCj4+IEtvbW11bmlrYXRpb24sIEluZm9ybWF0aW9uc3ZlcmFyYmVp dHVuZyB1bmQgRXJnb25vbWllIEZLSUUNCj4+IEtvbW11bmlrYXRpb25zc3lzdGVtZSAoS09NKQ0K Pj4gTmV1ZW5haHJlciBTdHJhw59lIDIwLCA1MzM0MyBXYWNodGJlcmcsIEdlcm1hbnkNCj4+IFRl bGVmb24gKzQ5IDIyOCA5NDM1LTk2MSwgICBGYXggKzQ5IDIyOCA5NDM1IDY4NQ0KPj4gbWFpbHRv Omhlbm5pbmcucm9nZ2VAZmtpZS5mcmF1bmhvZmVyLmRlIGh0dHA6Ly93d3cuZmtpZS5mcmF1bmhv ZmVyLmRlDQo+PiBHUEc6IEUxQzYgMDkxNCA0OTBCIDM5MDkgRDk0NCBGODBEIDQ0ODcgQzY3QyA1 NUVDIENGRTANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXRAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gDQo+IC0tLS0NCj4g Ym9iZXJyeUBjaXNjby5jb20NCj4gVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LiBUaGlzIGVtYWlsIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJv dGVjdGVkIGJ5IE5EQS4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBm b3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1h aWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4NCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQg bWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCj4g cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQNCj4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBh bmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCj4gZGlzdHJpYnV0ZSBpdHMgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlz dA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0K From ulrich@herberg.name Fri Apr 27 07:59:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63F21F86F2 for ; Fri, 27 Apr 2012 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGDlMypC-z6d for ; Fri, 27 Apr 2012 07:59:55 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBC21F86FF for ; Fri, 27 Apr 2012 07:59:55 -0700 (PDT) Received: by dady13 with SMTP id y13so1487985dad.27 for ; Fri, 27 Apr 2012 07:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=zsQbZ1tas5Njh5eLAGqKTaq9qnOdw/xt0xcShzsDweY=; b=BjgVexXGzjCuD+A2DveM5RvsiwlLKwmVwpnM6suy2zOnAr/dm22Qh17r5bNov2T0Gm 6cHvUdj5jbOX84m8nZCdPILXR/tliXzfsRvlbc1eXM9sOhf6wYlsXJ0FtwDKBcRkJVc7 WiwvDMnzUhECV2rutG25QyhAB22RpmyMBaeIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=zsQbZ1tas5Njh5eLAGqKTaq9qnOdw/xt0xcShzsDweY=; b=a9b1ksM2jDlnzvaSzsqs1kumNgZ3Q1JDjtAEnGcec3H9PVDtsaFGkdysc62+WlLIZB a8NtWD/waFsPeNqLuECqv9LjzQ+jZAown2FtQQObl7AoUcdvjSQarudmnTt1IkS6Hcuy MN364JsZ+Gr9On//c4Gy9yWQe95iyCrsbN3PjeOcjHyrnvWprT2FDH08pZFizlv1DPqS qwPjtyLrCX/mLP7BccAa0qriyzsjAjVGloaT8BFoEIX7rzs9+ZBJHhOtd7ItbFeeuJ55 yb1hjomTwatsahD4uMGOQ50WOsIJME2f1hDpDQh7CFpBypCH5Zz9fzAOz0wtTusLJ915 u40Q== Received: by 10.68.132.197 with SMTP id ow5mr301824pbb.165.1335538794736; Fri, 27 Apr 2012 07:59:54 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id s7sm6703089pbl.31.2012.04.27.07.59.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 07:59:53 -0700 (PDT) References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent -dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <0C147E46-EEC5-463F-B307-8B8DB760568A@herberg.name> X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 07:59:51 -0700 To: Ulrich Herberg X-Gm-Message-State: ALoCoQm5TY7TaCEsYXLUu5uWYtG365x0kDC9PVWZt8fDz/bs9Y6lRZ2jrvU9dVg0C9sJGsUoCf94 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:59:56 -0000 P.S To clarify my last email... On Apr 27, 2012, at 7:44, Ulrich Herberg wrote: > I totally agree with Chris. I think he said in a previous email , "take it= or leave it". Not using RFC5444 in DLEP would be acceptable for me, Well, as Henning pointed out, I also believe that RFC5444 is very suitable f= or DLEP. So, not using it is just one notch above in my preference of using i= t as it is used currently. Really, I would prefer to use it as discussed by H= enning, Chris, etc. Ulrich > but if it uses it, then it should use it correctly. It has been pointed ou= t by several of the authors of RFC5444 as well as by several implementers ho= w to do that. I don't understand the resistance. There seems to be a rough c= oncensus on that in the WG (besides by the authors), and the draft is a WG d= raft, not an individual draft. >=20 > Ulrich >=20 > On Apr 27, 2012, at 5:55, "Dearlove, Christopher (UK)" wrote: >=20 >> I think the diff parsers etc. misses the point. If DLEP is to use 5444 th= en having a 5444 parser may be taken as the starting point. And without sub-= TLVs that's all the parser you need. >>=20 >> I'm afraid I think this is a clear case of design using 5444 without real= ly appreciating it. And then when people who have greater familiarity with 5= 444 suggest what is a more natural use of 5444, meeting a resistance that ma= y be based on several things, but offering a better fit to 5444 and better p= arsing options are not among those things. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Bo Berry >> Sent: 27 April 2012 12:24 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP and TLV breakdown >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote: >>=20 >>> On 04/27/2012 01:09 PM, Rick Taylor wrote: >>>> I think we are in danger of letting the tail wag the dog here. >>>>=20 >>>> The best DLEP spec will result in specifying what needs to be there >>>> by analysing the use-cases and taking into account >>>> transportcharacteristics. Not how easy it makes implementers jobs. >>>> Obviously, specifying something totally wacky is never a good idea, but= >>>> really, what is the difference between... >>>>=20 >>>> Packet AND Packet >>>> | | >>>> +-Message +-Message >>>> | | >>>> +-DLEP_TLV +-DLEP_ORDER_TLV >>>> | | >>>> +-SubTLV_1 +-DLEP_TLV_1 >>>> | | >>>> +-SubTLV_2 +-DLEP_TLV_2 >>>> : : >>>>=20 >>>>=20 >>>> ...as far as the parser is concerned? =46rom my perspective, Stan's >>>> Sub-TLV's are possibly easier to integrate into an existing parser than= >>>> having to maintain the state at the message processing level in >>>> Henning's model. >>>=20 >>> With a generic parser you don't have to integrate anything new for the r= ight one. You just add a few numbers to an array of "TLVs you are interested= in". >>>=20 >>> No additional byte parsing code necessary. >>>=20 >>> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the lis= t of message TLVs. >>>=20 >>> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming ol= sr.org (v2) implementation. Having something special for DLEP is just bad an= d unnecessary. >>=20 >> =46rom your perspective I can understand that position. But there are ot= hers that have diff parsers, diff protocols, diff radios, networks, etc. Ri= cks' caution is a good one. >>=20 >>=20 >>=20 >>>=20 >>> Henning Rogge >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Neuenahrer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> ---- >> boberry@cisco.com >> This email may contain confidential and privileged material for the sole u= se of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by o= thers is strictly prohibited. If you are not the intended recipient (or auth= orized to receive for the recipient), please contact the sender by reply ema= il and delete all copies of this message. >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Apr 27 08:01:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB5721F86D1 for ; Fri, 27 Apr 2012 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk+l0ecjEKqz for ; Fri, 27 Apr 2012 08:01:46 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 02F0721F86C9 for ; Fri, 27 Apr 2012 08:01:45 -0700 (PDT) Received: by dady13 with SMTP id y13so1491313dad.27 for ; Fri, 27 Apr 2012 08:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ClPlr4OePmFa7Tuwv3Ets0AWjQURVSY6Jby3XGKDvh8=; b=sExylmvTm7BXblImSI0lpMBAK3XWwI0uslUx7HKU5KkksMRsT1lFl+uWIgiaId1wHe gqaUebmUKsiMBkfGiHHhfRWAsZz1BM7Pd6bJIU6VmRphHiolTJbWpcd3IRVSTXgJQzy3 vgJcuXDB0GFJdersCritEDVkwTaUr0fVxNBWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ClPlr4OePmFa7Tuwv3Ets0AWjQURVSY6Jby3XGKDvh8=; b=KqhC2UDwk6XFeazx3yv738xFOgCfFahmqK0fb+s0v1+6hupxUQ5jBY5Jwmy3m6vi44 3lI7b1H7vScJBQ1WxL6aqAFcQTcLIGUjfr+FRbeRwCLYmWygenb7fXVapCry5OYMnXhK taSSGU34B4ffypPKUMY3voy9uYMyvTQc5AOzELEIWQrcmJSUIBsoQethtnYXNfJNtGq8 8YbURKypW0S1Q+1o7HGf4KiJABjgqqv1d4OfKWn8pmvm7Fl0NTVLUrdVc0+pNgjV7DlL lTa72YmpE+8yKHzc546tjq+7IKrGZisQidBbUSHNfdV5+T0+t907OUaIKGLD2NX4RwbU xbPQ== Received: by 10.68.227.226 with SMTP id sd2mr11762312pbc.49.1335538905779; Fri, 27 Apr 2012 08:01:45 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id d2sm6706573pbw.39.2012.04.27.08.01.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 08:01:44 -0700 (PDT) References: <7B31B0093014224A843C10C0CCE92AC1037C6DDD@SUKNPT8106.cogent-dsn.local> <4DC5E791-CA29-40D7-BB35-C0F002969350@cisco.com> <27B33AA1-A134-4319-9EE3-FA0C6E6A1032@cisco.com> <5D02C78E-A378-423B-A99D-38D742D3E174@cisco.com> <7B31B0093014224A843C10C0CCE92AC1037C719E@SUKNPT8106.cogent-dsn.local> <7B31B0093014224A843C10C0CCE92AC1037C7316@SUKNPT8106.cogent -dsn.local> < 4F9A7FDA.6000704@fkie.fraunhofer.de> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <2342CBAB-610B-4975-9F03-AB4018FEAAD3@herberg.name> X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 08:01:43 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQmc/bafsXHIfjeSi48bhQa3YkPDFVhEsxZIc7oWDGvLpz2LWOhLObwHRtiH2pB3qCL6iNDi Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:01:47 -0000 +1 On Apr 27, 2012, at 7:59, "Dearlove, Christopher (UK)" wrote: > I believe the context for "take it or leave it" (which might otherwise be m= isunderstood) was that 5444 is provided on a take it or leave it basis. And a= lthough as an author of 5444 I find it gratifying when anyone wants to use i= t, I would always say that 5444 is good for some things and less good for ot= hers. However I do think that if used then more value is gained if it is use= d in some ways rather than others. >=20 > (The only place where 5444 is other than optional is as described in 5498,= but I don't think we are discussing that protocol/port.) >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of U= lrich Herberg > Sent: 27 April 2012 15:45 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org; Bo Berry > Subject: Re: [manet] DLEP and TLV breakdown >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I totally agree with Chris. I think he said in a previous email , "take it= or leave it". Not using RFC5444 in DLEP would be acceptable for me, but if i= t uses it, then it should use it correctly. It has been pointed out by sever= al of the authors of RFC5444 as well as by several implementers how to do th= at. I don't understand the resistance. There seems to be a rough concensus o= n that in the WG (besides by the authors), and the draft is a WG draft, not a= n individual draft. >=20 > Ulrich >=20 > On Apr 27, 2012, at 5:55, "Dearlove, Christopher (UK)" wrote: >=20 >> I think the diff parsers etc. misses the point. If DLEP is to use 5444 th= en having a 5444 parser may be taken as the starting point. And without sub-= TLVs that's all the parser you need. >>=20 >> I'm afraid I think this is a clear case of design using 5444 without real= ly appreciating it. And then when people who have greater familiarity with 5= 444 suggest what is a more natural use of 5444, meeting a resistance that ma= y be based on several things, but offering a better fit to 5444 and better p= arsing options are not among those things. >>=20 >> --=20 >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Bo Berry >> Sent: 27 April 2012 12:24 >> To: Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP and TLV breakdown >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> On Apr 27, 2012, at 7:15 AM, Henning Rogge wrote: >>=20 >>> On 04/27/2012 01:09 PM, Rick Taylor wrote: >>>> I think we are in danger of letting the tail wag the dog here. >>>>=20 >>>> The best DLEP spec will result in specifying what needs to be there >>>> by analysing the use-cases and taking into account >>>> transportcharacteristics. Not how easy it makes implementers jobs. >>>> Obviously, specifying something totally wacky is never a good idea, but= >>>> really, what is the difference between... >>>>=20 >>>> Packet AND Packet >>>> | | >>>> +-Message +-Message >>>> | | >>>> +-DLEP_TLV +-DLEP_ORDER_TLV >>>> | | >>>> +-SubTLV_1 +-DLEP_TLV_1 >>>> | | >>>> +-SubTLV_2 +-DLEP_TLV_2 >>>> : : >>>>=20 >>>>=20 >>>> ...as far as the parser is concerned? =46rom my perspective, Stan's >>>> Sub-TLV's are possibly easier to integrate into an existing parser than= >>>> having to maintain the state at the message processing level in >>>> Henning's model. >>>=20 >>> With a generic parser you don't have to integrate anything new for the r= ight one. You just add a few numbers to an array of "TLVs you are interested= in". >>>=20 >>> No additional byte parsing code necessary. >>>=20 >>> I would not even notice if the DLEP_ORDER_TLV is the last TLV in the lis= t of message TLVs. >>>=20 >>> I plan to use the same parser for NHDP, OLSRv2 and DLEP in the coming ol= sr.org (v2) implementation. Having something special for DLEP is just bad an= d unnecessary. >>=20 >> =46rom your perspective I can understand that position. But there are ot= hers that have diff parsers, diff protocols, diff radios, networks, etc. Ri= cks' caution is a good one. >>=20 >>=20 >>=20 >>>=20 >>> Henning Rogge >>>=20 >>> --=20 >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Neuenahrer Stra=C3=9Fe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> ---- >> boberry@cisco.com >> This email may contain confidential and privileged material for the sole u= se of the intended recipient. This email may contain information that is pro= tected by NDA. Any unauthorized review, use, distribution or disclosure by o= thers is strictly prohibited. If you are not the intended recipient (or auth= orized to receive for the recipient), please contact the sender by reply ema= il and delete all copies of this message. >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Fri Apr 27 08:22:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6621F8758 for ; Fri, 27 Apr 2012 08:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k+kjqDqAnZF for ; Fri, 27 Apr 2012 08:22:05 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3421F8754 for ; Fri, 27 Apr 2012 08:22:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="234636681" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 27 Apr 2012 16:22:04 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3RFM35v007817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Apr 2012 16:22:03 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 16:22:03 +0100 From: "Dearlove, Christopher (UK)" To: dsatterw , Henning Rogge Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kYfY6QS6Ej0n5skifyF6SVWSSeAAAt6qw///zuACAAAJVgP//121QgABMPQCAAAzQgP//358w Date: Fri, 27 Apr 2012 15:22:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:22:07 -0000 I believe I understand both this point of view and the point of view that s= ays we should do things "right". Understanding two points of view is always= difficult as it leaves you not sure what you think should happen next. I = would suggest that this might be the point where our disinterested (*) WG c= hair, and responsible AD might need to express an opinion. Unfortunately I = don't think any way forward is ideal, but that's life. (*) Correct usage, not uninterested. Not sure there's anything MANET-relate= d Joe's uninterested in. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: dsatterw [mailto:dsatterw@cisco.com]=20 Sent: 27 April 2012 15:17 To: Henning Rogge; Dearlove, Christopher (UK) Cc: manet@ietf.org; Bo Berry Subject: Re: [manet] DLEP and TLV breakdown ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- I personally have an issue at this stage of the game (we are now on our 3rd version of DLEP) of having to completely rewrite our packet format so that it better integrates into RFC5444. At this point we have at least 4 working implementations of DLEP out there which were all based on our sourceforge example of a packet parser that seems sufficient for the ones involved. If we, at this point, decide to rewrite the packet formats then everyone that has working versions today would have work to do without really any benefit IMO. If this objection were brought up in the 00 or 01 version of the draft it would be a little easier to accept than year(s) later. To be quite honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444 states that it should be used by routing protocols for information exchange and DLEP is not a routing protocol. I would really rather spend our time trying to make sure that the content being exchanged between the radio and router is adequate than arguing about packet parsers. Darryl Satterwhite Cisco Systems On 4/27/12 9:31 AM, "Henning Rogge" wrote: > On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) > wrote: >> I think the diff parsers etc. misses the point. If DLEP is to use 5444 t= hen >> having a 5444 parser may be taken as the starting point. And without sub= -TLVs >> that's all the parser you need. >=20 > Exactly. >=20 >> I'm afraid I think this is a clear case of design using 5444 without rea= lly >> appreciating it. And then when people who have greater familiarity with = 5444 >> suggest what is a more natural use of 5444, meeting a resistance that ma= y be >> based on several things, but offering a better fit to 5444 and better pa= rsing >> options are not among those things. >=20 > Yes. >=20 > At the moment DLEP is not using RFC5444 at all... except as a wrapper > around its own format. And everything DLEP does at the moment can be > expressed in a reasonable way within RFC5444. >=20 > Henning Rogge ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Fri Apr 27 08:33:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8F21F87ED for ; Fri, 27 Apr 2012 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzva3bsBtio3 for ; Fri, 27 Apr 2012 08:33:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C12E621F87E5 for ; Fri, 27 Apr 2012 08:33:21 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1140007pbb.31 for ; Fri, 27 Apr 2012 08:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=EDIpZ2DzVd0QQONJcieXU1rN0qGeliq/hcQx4T5HDdE=; b=UXd3yZdHjtxZhHU3dJqLW2vmY2JPNPAJbH1vYFYSd1dAZQWQJGgz7vnmauGkNWhioJ 4l8PYGZKvoeOnBKFBfBFqkt+MGoUEJpqXyItH6+3xR+x8PEZNL2xCsGMuaUdZQ8rJrHd VFR3/q+fu5EgUsyS9HTLLyLCt1VtHZxaIh/w8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=EDIpZ2DzVd0QQONJcieXU1rN0qGeliq/hcQx4T5HDdE=; b=Kh6kcqdaAgIXa2BmejHudjFx4EDUOx5ilp6exCiB3QOijUhe1qL7dgx6IX4dcyBAw3 VFQxis/7As8LddQez2xOiQcOj8YlhQUNidBl8Tcm1jhSMz2+A9ymTQlL77VFG+nV8XHL ASZynmxpk4fVC7Srh3I8eWtgftFbFb32g3vebveUzsKirRumM5ZRD4USZL2zpn/e263r hvf2UxUjWfq3EYiX+ISQWNQKDUDDfxlCD0MFKINAIonIlXuxOULmMoIPLfxbwIOnYCy5 H2WEvM/l2pSomlNu+q3LXAEIaTfXsZOwmieertAr2V+FgymuGDT6qv2Cli5HL+VR35mD +qMg== Received: by 10.68.200.68 with SMTP id jq4mr24721805pbc.42.1335540801463; Fri, 27 Apr 2012 08:33:21 -0700 (PDT) Received: from [192.168.1.69] (108-206-232-34.lightspeed.sntcca.sbcglobal.net. [108.206.232.34]) by mx.google.com with ESMTPS id pi10sm5800923pbc.9.2012.04.27.08.33.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 08:33:20 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <06648009-C217-4233-89CD-B0813E767BFC@herberg.name> X-Mailer: iPad Mail (9B176) From: Ulrich Herberg Date: Fri, 27 Apr 2012 08:33:18 -0700 To: "Dearlove, Christopher (UK)" X-Gm-Message-State: ALoCoQkIX5puEKJ4qz13US0bB99YiZQaeoWx+cZXbX6FfOy8SCQo1D6YHx85o2eK/GU9TKw7UmoV Cc: "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:33:23 -0000 +1 On Apr 27, 2012, at 8:22, "Dearlove, Christopher (UK)" wrote: > I believe I understand both this point of view and the point of view that s= ays we should do things "right". Understanding two points of view is always d= ifficult as it leaves you not sure what you think should happen next. I wou= ld suggest that this might be the point where our disinterested (*) WG chair= , and responsible AD might need to express an opinion. Unfortunately I don't= think any way forward is ideal, but that's life. >=20 > (*) Correct usage, not uninterested. Not sure there's anything MANET-relat= ed Joe's uninterested in. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,= Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 >=20 > -----Original Message----- > From: dsatterw [mailto:dsatterw@cisco.com]=20 > Sent: 27 April 2012 15:17 > To: Henning Rogge; Dearlove, Christopher (UK) > Cc: manet@ietf.org; Bo Berry > Subject: Re: [manet] DLEP and TLV breakdown >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > I personally have an issue at this stage of the game (we are now on our 3r= d > version of DLEP) of having to completely rewrite our packet format so that= > it better integrates into RFC5444. At this point we have at least 4 workin= g > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. If= > we, at this point, decide to rewrite the packet formats then everyone that= > has working versions today would have work to do without really any benefi= t > IMO. If this objection were brought up in the 00 or 01 version of the draf= t > it would be a little easier to accept than year(s) later. To be quite > honest, I don't think DLEP fits well in RFC5444 in the first place. RFC544= 4 > states that it should be used by routing protocols for information exchang= e > and DLEP is not a routing protocol. I would really rather spend our time > trying to make sure that the content being exchanged between the radio and= > router is adequate than arguing about packet parsers. >=20 > Darryl Satterwhite > Cisco Systems >=20 >=20 > On 4/27/12 9:31 AM, "Henning Rogge" wrote: >=20 >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) >> wrote: >>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 t= hen >>> having a 5444 parser may be taken as the starting point. And without sub= -TLVs >>> that's all the parser you need. >>=20 >> Exactly. >>=20 >>> I'm afraid I think this is a clear case of design using 5444 without rea= lly >>> appreciating it. And then when people who have greater familiarity with 5= 444 >>> suggest what is a more natural use of 5444, meeting a resistance that ma= y be >>> based on several things, but offering a better fit to 5444 and better pa= rsing >>> options are not among those things. >>=20 >> Yes. >>=20 >> At the moment DLEP is not using RFC5444 at all... except as a wrapper >> around its own format. And everything DLEP does at the moment can be >> expressed in a reasonable way within RFC5444. >>=20 >> Henning Rogge >=20 >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Apr 27 09:07:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C2F21F866C for ; Fri, 27 Apr 2012 09:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXjtcAyD3GeS for ; Fri, 27 Apr 2012 09:07:18 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id B399A21F85C2 for ; Fri, 27 Apr 2012 09:07:18 -0700 (PDT) Received: by dady13 with SMTP id y13so1594658dad.27 for ; Fri, 27 Apr 2012 09:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4dzQeFxuw5YgNpLqiTvIil6bMCcbcSkvySyHTNgmlMc=; b=iRsP+FY/mQ6px/O/aCgS6IZAEm6+zdk/ZNJFXeS9DG+jR+kJb9AP/SwXvA44MHaeTk iz+KF/1yoP7p6NypNEoSiTuDFKwoKCw917BYMhxTiqyYunNLa8oLzN0E4OTl1EV+m0Bz nNhfHORSOT3n/uoj4rA3xVwCIsBDZg1IFKITw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4dzQeFxuw5YgNpLqiTvIil6bMCcbcSkvySyHTNgmlMc=; b=J65dQ+lv/XUts0VYHzmH2GTCEfIv8CCm2mLNM1NcngmK6ftOrEdbu2mMxX7V7HswJu GRM2FUpyZ8ydPI2mZRvI4jM4szJdSCtyC+OUU5EEvm5DWqjbH+xfrLsslxIcyzbJuGtR 7r5KoKM9P3KYVyoKQ+CO5DtB/Lt4lE6TrIfhlM1oU3855DMainl6Eh0AKETRzJtBVVvE v28iWbxSFxwvJVDu5aQsx644fBxxC0Kd37m9dvAMzNAQFRyEYSv+M0RnvJ8DcQmSQOZF S+w/xKUqd++wl6vVzN2jmmOhd8of79cxM9XfS5ilW5nurzafjIGZVYm/roLp0pCFPAJy EikQ== MIME-Version: 1.0 Received: by 10.68.212.133 with SMTP id nk5mr24169600pbc.120.1335542838398; Fri, 27 Apr 2012 09:07:18 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Fri, 27 Apr 2012 09:07:18 -0700 (PDT) In-Reply-To: <208E5BD4-D910-492A-9815-88112E57AD19@herberg.name> References: <208E5BD4-D910-492A-9815-88112E57AD19@herberg.name> Date: Fri, 27 Apr 2012 09:07:18 -0700 Message-ID: From: Ulrich Herberg To: dsatterw Content-Type: multipart/alternative; boundary=e89a8ff1c430770d1904beab4cae X-Gm-Message-State: ALoCoQkoqp9BZvK7WqDZWCHTHOZ1nx9Yqp+mPNFdXu6lkoYLlXVPq04R9ZTNHGXgFCV60/Piz+Gq Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:07:20 -0000 --e89a8ff1c430770d1904beab4cae Content-Type: text/plain; charset=ISO-8859-1 P.S. My tone may have been a little strong in that email, apologies. I think it is great to have implementations of the standards we come up in MANET, even more so if there are several of them. But I think as a WG we should do the right thing and make sure that our standards, such as RFC5444, are used in the intended and ideal way. And some DLEP implementations (e.g. Henning's) seem to use RFC5444 Message-TLVs and address blocks already, so there is also proof that this works (and does not require to modify the RFC5444 parser). Ulrich (probably my last email on the subject) On Fri, Apr 27, 2012 at 7:49 AM, Ulrich Herberg wrote: > Darryl, > > I don't believe that to be an argument. I still believe the WG should do > its best job to come up with the best solution. DLEP is a WG document and > uses RFC5444, but not correctly. That worries me, and the only real > counter-argument to the suggested changes so far has been "we have an > existing implementation and don't want to change it.". > > Ulrich > > On Apr 27, 2012, at 7:17, dsatterw wrote: > > > I personally have an issue at this stage of the game (we are now on our > 3rd > > version of DLEP) of having to completely rewrite our packet format so > that > > it better integrates into RFC5444. At this point we have at least 4 > working > > implementations of DLEP out there which were all based on our sourceforge > > example of a packet parser that seems sufficient for the ones involved. > If > > we, at this point, decide to rewrite the packet formats then everyone > that > > has working versions today would have work to do without really any > benefit > > IMO. If this objection were brought up in the 00 or 01 version of the > draft > > it would be a little easier to accept than year(s) later. To be quite > > honest, I don't think DLEP fits well in RFC5444 in the first place. > RFC5444 > > states that it should be used by routing protocols for information > exchange > > and DLEP is not a routing protocol. I would really rather spend our time > > trying to make sure that the content being exchanged between the radio > and > > router is adequate than arguing about packet parsers. > > > > Darryl Satterwhite > > Cisco Systems > > > > > > On 4/27/12 9:31 AM, "Henning Rogge" wrote: > > > >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) > >> wrote: > >>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 > then > >>> having a 5444 parser may be taken as the starting point. And without > sub-TLVs > >>> that's all the parser you need. > >> > >> Exactly. > >> > >>> I'm afraid I think this is a clear case of design using 5444 without > really > >>> appreciating it. And then when people who have greater familiarity > with 5444 > >>> suggest what is a more natural use of 5444, meeting a resistance that > may be > >>> based on several things, but offering a better fit to 5444 and better > parsing > >>> options are not among those things. > >> > >> Yes. > >> > >> At the moment DLEP is not using RFC5444 at all... except as a wrapper > >> around its own format. And everything DLEP does at the moment can be > >> expressed in a reasonable way within RFC5444. > >> > >> Henning Rogge > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > --e89a8ff1c430770d1904beab4cae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
P.S. My tone may have been a little strong in th= at email, apologies. I think it is great to have implementations of the sta= ndards we come up in MANET, even more so if there are several of them. But = I think as a WG we should do the right thing and make sure that our standar= ds, such as RFC5444, are used in the intended and ideal way. And some DLEP = implementations (e.g. Henning's) seem to use RFC5444 Message-TLVs and a= ddress blocks already, so there is also proof that this works (and does not= require to modify the RFC5444 parser).

Ulrich (probably my last email on the subject)

On Fri, Apr 27, 2012 at 7:49 AM, Ulrich Herberg <ulrich@herber= g.name> wrote:
Darryl,

I don't believe that to be an argument. I still believe the WG should d= o its best job to come up with =A0the best solution. DLEP is a WG document = and uses RFC5444, but not correctly. That worries me, and the only real cou= nter-argument to the suggested changes so far has been "we have an exi= sting implementation and don't want to change it.".

Ulrich

On Apr 27, 2012, at 7:17, dsatterw <dsatterw@cisco.com> wrote:

> I personally have an issue at this stage of the game (we are now on ou= r 3rd
> version of DLEP) of having to completely rewrite our packet format so = that
> it better integrates into RFC5444. At this point we have at least 4 wo= rking
> implementations of DLEP out there which were all based on our sourcefo= rge
> example of a packet parser that seems sufficient for the ones involved= . If
> we, at this point, decide to rewrite the packet formats then everyone = that
> has working versions today would have work to do without really any be= nefit
> IMO. If this objection were brought up in the 00 or 01 version of the = draft
> it would be a little easier to accept than year(s) later. To be quite<= br> > honest, I don't think DLEP fits well in RFC5444 in the first place= . RFC5444
> states that it should be used by routing protocols for information exc= hange
> and DLEP is not a routing protocol. I would really rather spend our ti= me
> trying to make sure that the content being exchanged between the radio= and
> router is adequate than arguing about packet parsers.
>
> Darryl Satterwhite
> Cisco Systems
>
>
> On 4/27/12 9:31 AM, "Henning Rogge" <hrogge@googlemail.com> wrote:
>
>> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK)
>> <Chris.Dearlov= e@baesystems.com> wrote:
>>> I think the diff parsers etc. misses the point. If DLEP is to = use 5444 then
>>> having a 5444 parser may be taken as the starting point. And w= ithout sub-TLVs
>>> that's all the parser you need.
>>
>> Exactly.
>>
>>> I'm afraid I think this is a clear case of design using 54= 44 without really
>>> appreciating it. And then when people who have greater familia= rity with 5444
>>> suggest what is a more natural use of 5444, meeting a resistan= ce that may be
>>> based on several things, but offering a better fit to 5444 and= better parsing
>>> options are not among those things.
>>
>> Yes.
>>
>> At the moment DLEP is not using RFC5444 at all... except as a wrap= per
>> around its own format. And everything DLEP does at the moment can = be
>> expressed in a reasonable way within RFC5444.
>>
>> Henning Rogge
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--e89a8ff1c430770d1904beab4cae-- From dsatterw@cisco.com Fri Apr 27 09:25:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DE21F8678 for ; Fri, 27 Apr 2012 09:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.796 X-Spam-Level: X-Spam-Status: No, score=-7.796 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Bypbu63xo7 for ; Fri, 27 Apr 2012 09:25:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA1C21F8647 for ; Fri, 27 Apr 2012 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dsatterw@cisco.com; l=10033; q=dns/txt; s=iport; t=1335543906; x=1336753506; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=SiQ9PAoaognPDzWnFKJsM7+A1ZR3g2wkv6oERCkgucg=; b=aRpT9YQkWEOhaN3V7uH6JEh+Ys5iB1oJm4FMHR/xssaSCvalBgVQRam0 uEf9eYBvlv8JGnLYuDPWS5EBR8vhDnvqw5xYr2U8UMJ7LJaKZjkb3q4Ev IMC8k2dshCTWsntEJi4dJgP2+8cHAZ6PhxvmolsoWEKSAoXz5TCzP+NFM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkKAELImk+tJV2d/2dsb2JhbABEgkaGCagegQECgQeCCQEBAQMBAQEBDwEqMQYFBQ0BCAkPVTABAQQOBRsHh10DBgULnCaWSA2JTwSKB4c8BIgvhWGHbY5XgWmBN4FNgUA X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208,217";a="78469781" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 27 Apr 2012 16:24:54 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3RGOsal008253; Fri, 27 Apr 2012 16:24:54 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 11:24:54 -0500 Received: from 64.102.54.133 ([64.102.54.133]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Apr 2012 16:24:53 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 27 Apr 2012 12:25:27 -0400 From: dsatterw To: Ulrich Herberg Message-ID: Thread-Topic: [manet] DLEP and TLV breakdown Thread-Index: Ac0kklrA9tXxat3P/ESi0BHTHqqF9w== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3418374327_16750679" X-OriginalArrivalTime: 27 Apr 2012 16:24:54.0157 (UTC) FILETIME=[472D03D0:01CD2492] Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:25:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3418374327_16750679 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ulrich, You point is taken and I didn=B9t take it in a negative way. I just wish we could have had this lively discussion when reviewing DLEP 01 not DLEP 02. At this point I think its very clear the 2 possible directions we can proceed. I think its time for the DLEP author and co-authors to have a chat and decide where to go from here. - Darryl On 4/27/12 12:07 PM, "Ulrich Herberg" wrote: > P.S. My tone may have been a little strong in that email, apologies. I th= ink > it is great to have implementations of the standards we come up in MANET,= even > more so if there are several of them. But I think as a WG we should do th= e > right thing and make sure that our standards, such as RFC5444, are used i= n the > intended and ideal way. And some DLEP implementations (e.g. Henning's) se= em to > use RFC5444 Message-TLVs and address blocks already, so there is also pro= of > that this works (and does not require to modify the RFC5444 parser). >=20 > Ulrich (probably my last email on the subject) >=20 > On Fri, Apr 27, 2012 at 7:49 AM, Ulrich Herberg wro= te: >> Darryl, >>=20 >> I don't believe that to be an argument. I still believe the WG should do= its >> best job to come up with =A0the best solution. DLEP is a WG document and u= ses >> RFC5444, but not correctly. That worries me, and the only real >> counter-argument to the suggested changes so far has been "we have an >> existing implementation and don't want to change it.". >>=20 >> Ulrich >>=20 >> On Apr 27, 2012, at 7:17, dsatterw wrote: >>=20 >>> > I personally have an issue at this stage of the game (we are now on o= ur >>> 3rd >>> > version of DLEP) of having to completely rewrite our packet format so= that >>> > it better integrates into RFC5444. At this point we have at least 4 >>> working >>> > implementations of DLEP out there which were all based on our sourcef= orge >>> > example of a packet parser that seems sufficient for the ones involve= d. If >>> > we, at this point, decide to rewrite the packet formats then everyone= that >>> > has working versions today would have work to do without really any >>> benefit >>> > IMO. If this objection were brought up in the 00 or 01 version of the >>> draft >>> > it would be a little easier to accept than year(s) later. To be quite >>> > honest, I don't think DLEP fits well in RFC5444 in the first place. >>> RFC5444 >>> > states that it should be used by routing protocols for information >>> exchange >>> > and DLEP is not a routing protocol. I would really rather spend our t= ime >>> > trying to make sure that the content being exchanged between the radi= o and >>> > router is adequate than arguing about packet parsers. >>> > >>> > Darryl Satterwhite >>> > Cisco Systems >>> > >>> > >>> > On 4/27/12 9:31 AM, "Henning Rogge" wrote: >>> > >>>> >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) >>>> >> wrote: >>>>> >>> I think the diff parsers etc. misses the point. If DLEP is to use= 5444 >>>>> then >>>>> >>> having a 5444 parser may be taken as the starting point. And with= out >>>>> sub-TLVs >>>>> >>> that's all the parser you need. >>>> >> >>>> >> Exactly. >>>> >> >>>>> >>> I'm afraid I think this is a clear case of design using 5444 with= out >>>>> really >>>>> >>> appreciating it. And then when people who have greater familiarit= y >>>>> with 5444 >>>>> >>> suggest what is a more natural use of 5444, meeting a resistance = that >>>>> may be >>>>> >>> based on several things, but offering a better fit to 5444 and be= tter >>>>> parsing >>>>> >>> options are not among those things. >>>> >> >>>> >> Yes. >>>> >> >>>> >> At the moment DLEP is not using RFC5444 at all... except as a wrapp= er >>>> >> around its own format. And everything DLEP does at the moment can b= e >>>> >> expressed in a reasonable way within RFC5444. >>>> >> >>>> >> Henning Rogge >>> > >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 --B_3418374327_16750679 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [manet] DLEP and TLV breakdown Ulrich,

You point is taken and I didn’t take it in a negative way. I just wis= h we could have had this lively discussion when reviewing DLEP 01 not DLEP 0= 2.

At this point I think its very clear the 2 possible directions we can proce= ed. I think its time for the DLEP author and co-authors to have a chat and d= ecide where to go from here.

- Darryl


On 4/27/12 12:07 PM, "Ulrich Herberg" <ulrich@herberg.name> wrote:

<= SPAN STYLE=3D'font-size:11pt'>P.S. My tone may have been a little strong in th= at email, apologies. I think it is great to have implementations of the stan= dards we come up in MANET, even more so if there are several of them. But I = think as a WG we should do the right thing and make sure that our standards,= such as RFC5444, are used in the intended and ideal way. And some DLEP impl= ementations (e.g. Henning's) seem to use RFC5444 Message-TLVs and address bl= ocks already, so there is also proof that this works (and does not require t= o modify the RFC5444 parser).

Ulrich (probably my last email on the subject)

On Fri, Apr 27, 2012 at 7:49 AM, Ulrich Herberg <ulrich@herberg.name> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Darryl,

I don't believe that to be an argument. I still believe the WG should do it= s best job to come up with =A0the best solution. DLEP is a WG document and use= s RFC5444, but not correctly. That worries me, and the only real counter-arg= ument to the suggested changes so far has been "we have an existing imp= lementation and don't want to change it.".

Ulrich

On Apr 27, 2012, at 7:17, dsatterw <dsatter= w@cisco.com> wrote:

> I personally have an issue at this stage of the game (we are now on ou= r 3rd
> version of DLEP) of having to completely rewrite our packet format so = that
> it better integrates into RFC5444. At this point we have at least 4 wo= rking
> implementations of DLEP out there which were all based on our sourcefo= rge
> example of a packet parser that seems sufficient for the ones involved= . If
> we, at this point, decide to rewrite the packet formats then everyone = that
> has working versions today would have work to do without really any be= nefit
> IMO. If this objection were brought up in the 00 or 01 version of the = draft
> it would be a little easier to accept than year(s) later. To be quite<= BR> > honest, I don't think DLEP fits well in RFC5444 in the first place. RF= C5444
> states that it should be used by routing protocols for information exc= hange
> and DLEP is not a routing protocol. I would really rather spend our ti= me
> trying to make sure that the content being exchanged between the radio= and
> router is adequate than arguing about packet parsers.
>
> Darryl Satterwhite
> Cisco Systems
>
>
> On 4/27/12 9:31 AM, "Henning Rogge" <hrogge@googlemail.com> wrote:
>
>> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK)
>> <Chris.Dearlove@baesyst= ems.com> wrote:
>>> I think the diff parsers etc. misses the point. If DLEP is to = use 5444 then
>>> having a 5444 parser may be taken as the starting point. And w= ithout sub-TLVs
>>> that's all the parser you need.
>>
>> Exactly.
>>
>>> I'm afraid I think this is a clear case of design using 5444 w= ithout really
>>> appreciating it. And then when people who have greater familia= rity with 5444
>>> suggest what is a more natural use of 5444, meeting a resistan= ce that may be
>>> based on several things, but offering a better fit to 5444 and= better parsing
>>> options are not among those things.
>>
>> Yes.
>>
>> At the moment DLEP is not using RFC5444 at all... except as a wrap= per
>> around its own format. And everything DLEP does at the moment can = be
>> expressed in a reasonable way within RFC5444.
>>
>> Henning Rogge
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf= .org/mailman/listinfo/manet
=

--B_3418374327_16750679-- From hrogge@googlemail.com Fri Apr 27 09:32:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DDE21F863D for ; Fri, 27 Apr 2012 09:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYqxw2zls+iU for ; Fri, 27 Apr 2012 09:32:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86621F8638 for ; Fri, 27 Apr 2012 09:32:56 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so709602lbb.31 for ; Fri, 27 Apr 2012 09:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=scU3mwspdXx3Y0S2reSI/IXxsWiwUNnx6qO4yetAhnw=; b=Wvw2EPK+s98PjSvIZu1Q/ki/SBa89Y9Jlf78jx1SFdp4NJ/iLpn+nZFqMd7iXWIi0q R+hAj3951IcDPwsmhTSq3cfXmZsGCxHPAISPePAbFNbABDTdC5Ibdb+U/ig+RnyBAtH8 kvkM+RGMBIWoQ1INJXcZrztiQw5BoBp3PvjtESJSmEvc94opvqi5Ntv9WclVTPibkjkY 3M13GJtervb+HBrU+xlXU1S5QwC3NPmnFCXQ3pzwxxzgrVGSvprMtejIvcr4JwvDCvyz 2duevKQXzZ60Rzi0JzEfQICyeo86q29sHe2tLxeQhWltwYXfYrrIEM1hu19zPo+2gzrf WiYA== Received: by 10.112.99.71 with SMTP id eo7mr5733908lbb.84.1335544376106; Fri, 27 Apr 2012 09:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 27 Apr 2012 09:32:35 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 27 Apr 2012 18:32:35 +0200 Message-ID: To: dsatterw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:32:58 -0000 On Fri, Apr 27, 2012 at 18:25, dsatterw wrote: > Ulrich, > > You point is taken and I didn=92t take it in a negative way. I just wish = we > could have had this lively discussion when reviewing DLEP 01 not DLEP 02. Sorry for triggering this discussion that late. I always had the 'need to build a DLEP agent' on my personal hobby list, but looking into it only became part of my job at work in late March. I have talked with quite a few people who tried to use the "radio to router" extension for PPPoE, and none of them were happy about it. We need something like DLEP as a really good standard, but I fear we will loose quite a few opportunities if we do not fix it now. And going for a third standard to do this kind of work doesn't sound very g= ood. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Fri Apr 27 09:56:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026C521F8671 for ; Fri, 27 Apr 2012 09:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiLMFRarunLe for ; Fri, 27 Apr 2012 09:56:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFFFC21F86CA for ; Fri, 27 Apr 2012 09:56:50 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so1222770pbb.31 for ; Fri, 27 Apr 2012 09:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NKqLJ892KVJ0dYOwA5GSlOq0Hrl50owbAnD+Fx6pH7A=; b=To5RWmqW7CqpqO5mGcSp+lsuxBtqZmyoyDwPhSGDiWOf/8gigX/jNkp6gJsXDHfGpJ GSYC6pSeoUQMB8hV+Ydc9KqUeJljL4kiLvnn+5KPIORnBP0yBnCuwy4vuaMRSQNPoHzb AyHk1zqemd9VKx/Hff+vMBI5Oiff+7/DNAJZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NKqLJ892KVJ0dYOwA5GSlOq0Hrl50owbAnD+Fx6pH7A=; b=ksTrMzTxN6fIviWzfyXRQ5+/gitp8NkJdVvqstu1IBHvTWBbZX5yP5Q9mvgUuMJhWb HlIbB5PwshUiDisy9J2HyaecGNLu94wh9mFAACXKHPo04S4Quji7iZFCDnh+SiWEFJ23 0+UeNqy7EhLKY5SmX7F2VV2wyT7qzquiWz2E/TGUVVE6aZkrocgLN+1vdFYJGczP6TUJ jACVnfJgsxvf30ljO8Xe5qlwfkDbJ5xEXgvCT3YYZmG3Va9RnR6b5AmPO/8VnWEWD3Eg SZf0YjjlUYaggpRRZOOOOBYSEIaDDsy356GinWc/46Bj6FVMPr2zEEQs3gl/3rh+LjWm QrXA== MIME-Version: 1.0 Received: by 10.68.220.2 with SMTP id ps2mr25095647pbc.109.1335545810242; Fri, 27 Apr 2012 09:56:50 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Fri, 27 Apr 2012 09:56:49 -0700 (PDT) In-Reply-To: <4F7F12CA.9010009@joelhalpern.com> References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com> Date: Fri, 27 Apr 2012 09:56:49 -0700 Message-ID: From: Ulrich Herberg To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b2ee19999ce0404beabfd77 X-Gm-Message-State: ALoCoQl82CmegOX3Pn/JF16ZEpExL5yuLeIqRWK/ZRDFx3yOON8Fa7o+UNPL+0h+SUz9oWMTqI8u Cc: gen-art@ietf.org, manet@ietf.org, "A. Jean Mahoney" , sratliff@cisco.com Subject: Re: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:56:52 -0000 --047d7b2ee19999ce0404beabfd77 Content-Type: text/plain; charset=ISO-8859-1 Dear Joel, thank you very much for your review and apologies for our late reply. Find our answers below, and please tell us if they address your comments. ---------- Forwarded message ---------- From: Joel M. Halpern Date: Fri, Apr 6, 2012 at 8:59 AM Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 To: gen-art@ietf.org Cc: manet@ietf.org, "A. Jean Mahoney" , sratliff@cisco.com > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-manet-nhdp-mib-12 > Definition of Managed Objects for the > Neighborhood Discovery Protocol > Reviewer: Joel M. Halpern > Review Date: 6-April-2012 > IETF LC End Date: 16-April-2012 > IESG Telechat date: (if known) > > Summary: This document is almost ready for publication as a Proposed > Standard. That's good :-) > Major issues: > Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very > reasonable thing, namely suppress notifications for activity which is > expected. The text references RFC 4750 as precedent. RFC 4750 is > clear that the suppress window is tied to specific events (interface > up and election as a DR.) Section 5.1.3.1 does not specify which > condition(s) start(s) the suppress window. If, as seems likely, it is > Interface Up which starts the window, please state that explicitly in > the text. How about adding the following sentence at the end of the paragraph of 5.1.3.1: "The suppression window for notifications is started when the 'nhdpIfStatus' transitions from its default value of 'false' to 'true'." > In section 5.4, in addition to describing objects which are defined > in the MIB, the text describes, under the heading "The following > objects return statistics related to HELLO messages:", a number of > what it refers to as "Derived Objects". These do not appear to be > actual elements of the MIB. They appear rather to be descriptions of > calculations which the manager can perform using the information from > the MIB. It is not at all clear why they are here. If I am > understanding their role properly, and if they belong in this > document, they belong in some other section, as they are NOT objects > which return statistics related to HELLO messages. They appear not to > be returned by the managed device at all. Yes, you are right. We we pull these from the draft and save the text and possibly use elsewhere in the future. > Minor issues: > I can not find the object that corresponds to the setting for > Ignoring the Initial Activity. I presume this is my error. The > document would be helped if the object were named in section 5.1.3.1. > We can change 'HELLO_INTERVAL' in Section 5.1.3.1 to 'nhdpHelloInterval'. > I believe section 5.1.3.2 on Throttling Traps is intended to refer > to the StateChange Threshold and StateChangeWindow objects. It would > be very helpful if these were actually named in section 5.1.3.2. How about adding the following sentence to 5.1.3.2: The following objects are used to define the thresholds and time windows for specific Notifications defined in the NHDP-MIB module: nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold, nhdpIfRxBadPacketWindow. > Most MIBs I review have a description of the tables they contain, > how the tables relate to each other, and how they are indexed, in the > front matter that is roughly equivalent to section 5.2, 5.3, and 5.4. > As I am not a MIB Doctor, I do not know if that is formally required, > but I find it very helpful, and am surprised not to see it here. We agree that this is probably a good practice to follow and will work up text to handle this. > In looking at the fields in the NhdpInterfaceEntry, some of the > field definitions include some of the constraints from RFC 6130 > section 5 in their DESCRIPTION clauses. Some do not. (For exampple, > REFRESH_INTERVAL >= HELLO_INTERVAL is captured in > nhdbpRefreshInterval, but not in nhdpHelloInterval. The requirement > that nhdpHelloInterval be greater than 0 is not captured anywhere. > Neither is H_HOLD_TIME >= REFRESH_INTERVAL captured.) Some elements > have a statement that the object is persistent, while others do not, > but these do not seem to correspond to a difference in RFC 6130. It > is possible that there is a good reason for this apparent variation. > Is there? That's true. We will go through all constraints from NHDP and add them to the MIB. > Particularly for top-level objects such as nhdpNHoldTime and > NhdpIHoldTime I would really like to see a better description than > just this is object from section 5 of RFC 6130. Someone who > is using the MIB, who is looking at the description clause for > assistance, really needs something more than the name of the field in > the MIB. (I think better descriptions would be a good idea through > much of the MIB.) We will can look at the descriptions and copy some more text from NHDP. However, we would like to avoid copying all NHDP into the MIB. > Nits/editorial comments: > The tracker claims this is "In WG Last Call (manet), but also seems > to indicate that it is in IETF Last Call. Are the two happening at > the same time? We actually don't know, and will ask the chairs about that. Best regards Ulrich and Bob --047d7b2ee19999ce0404beabfd77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Joel,

thank you very much for your review and apologies for our late reply. Find = our answers below, and
please tell us if they address your comments.

=A0---------- Forwarded message ----------
From: Joel M. Halpern <jmh@joelha= lpern.com>
Date: Fri, Apr 6, 2012 at 8:59 AM
Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12
To: gen-art@ietf.org
Cc: manet@ietf.org, "A. Jean Mah= oney" <mahoney@nostrum.com>,
sratliff@cisco.com


> I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq= >.
>
> Please resolve these comments along with any other Last Call comments<= br> > you may receive.
>
> Document: draft-ietf-manet-nhdp-mib-12
> =A0 =A0Definition of Managed Objects for the
> =A0 =A0 =A0 =A0Neighborhood Discovery Protocol
> Reviewer: Joel M. Halpern
> Review Date: 6-April-2012
> IETF LC End Date: 16-April-2012
> IESG Telechat date: (if known)
>
> Summary: This document is almost ready for publication as a Proposed > Standard.


<nhdp-mib-authors>
That's good :-)
</nhdp-mib-authors>




> Major issues:
> =A0 =A0Section 5.1.3.1 on Ignoring Initial Activity is trying to do a = very
> reasonable thing, namely suppress notifications for activity which is<= br> > expected. =A0The text references RFC 4750 as precedent. =A0RFC 4750 is=
> clear that the suppress window is tied to specific events (interface > up and election as a DR.) =A0Section 5.1.3.1 does not specify which > condition(s) start(s) the suppress window. =A0If, as seems likely, it = is
> Interface Up which starts the window, please state that explicitly in<= br> > the text.


<nhdp-mib-authors>
How about adding the following sentence at the end of
the paragraph of 5.1.3.1:
"The suppression window for notifications is started when the 'nhd= pIfStatus'
transitions
=A0from its default value of 'false' to 'true= 9;."
</nhdp-mib-authors>



> =A0 =A0In section 5.4, in addition to describing objects which are def= ined
> in the MIB, the text describes, under the heading "The following<= br> > objects return statistics related to HELLO messages:", a number o= f
> what it refers to as "Derived Objects". =A0These do not appe= ar to be
> actual elements of the MIB. =A0They appear rather to be descriptions o= f
> calculations which the manager can perform using the information from<= br> > the MIB. =A0It is not at all clear why they are here. =A0If I am
> understanding their role properly, and if they belong in this
> document, they belong in some other section, as they are NOT objects > which return statistics related to HELLO messages. =A0They appear not = to
> be returned by the managed device at all.



<nhdp-mib-authors>
Yes, you are right. We we pull these from the d= raft and
save the text and possibly use elsewhere in the future.
</nhdp-mib-authors>



> Minor issues:
> =A0 =A0I can not find the object that corresponds to the setting for > Ignoring the Initial Activity. =A0I presume this is my error. =A0The > document would be helped if the object were named in section 5.1.3.1.<= br> >


<nhdp-mib-authors>
We can change 'HELLO_INTERVAL' in Section 5.1.3.1 to 'nhdpHello= Interval'.
</nhdp-mib-authors>



> =A0 =A0I believe section 5.1.3.2 on Throttling Traps is intended to re= fer
> to the StateChange Threshold and StateChangeWindow objects. =A0It woul= d
> be very helpful if these were actually named in section 5.1.3.2.


<nhdp-mib-authors>
How about adding the following sentence to 5.1.3= .2:
The following objects are used to define the thresholds and time
windows for specific Notifications defined in the NHDP-MIB module:
nhdpNbrStateChangeThreshold,
nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold,
nhdp2HopNbrStateChangeWindow, =A0 =A0 =A0 =A0 nhdpIfRxBadPacketThreshold, nhdpIfRxBadPacketWindow.
</nhdp-mib-authors>


> =A0 =A0Most MIBs I review have a description of the tables they contai= n,
> how the tables relate to each other, and how they are indexed, in the<= br> > front matter that is roughly equivalent to section 5.2, 5.3, and 5.4.<= br> > As I am not a MIB Doctor, I do not know if that is formally required,<= br> > but I find it very helpful, and am surprised not to see it here.


<nhdp-mib-authors>
We agree that this is probably a good practice to follow and will work up t= ext to handle this.
</nhdp-mib-authors>


> =A0 =A0In looking at the fields in the NhdpInterfaceEntry, some of the=
> field definitions include some of the constraints from RFC 6130
> section 5 in their DESCRIPTION clauses. =A0Some do not. =A0(For exampp= le,
> REFRESH_INTERVAL >=3D HELLO_INTERVAL is captured in
> nhdbpRefreshInterval, but not in nhdpHelloInterval. =A0The requirement=
> that nhdpHelloInterval be greater than 0 is not captured anywhere.
> =A0Neither is H_HOLD_TIME >=3D REFRESH_INTERVAL captured.) =A0Some = elements
> have a statement that the object is persistent, while others do not, > but these do not seem to correspond to a difference in RFC 6130. =A0It=
> is possible that there is a good reason for this apparent variation. > =A0Is there?


<nhdp-mib-authors>
That's true. We will go through all constraints from NHDP and
add them to the MIB.
</nhdp-mib-authors>



> =A0 =A0Particularly for top-level objects such as nhdpNHoldTime and > NhdpIHoldTime I would really like to see a better description than
> just this is <named> object from section 5 of RFC 6130. =A0Someo= ne who
> is using the MIB, who is looking at the description clause for
> assistance, really needs something more than the name of the field in<= br> > the MIB. =A0(I think better descriptions would be a good idea through<= br> > much of the MIB.)



<nhdp-mib-authors>
We will can look at the descriptions and copy some more text from
NHDP. However, we would like to avoid copying all NHDP into the MIB.
</nhdp-mib-authors>


> Nits/editorial comments:
> =A0 =A0The tracker claims this is "In WG Last Call (manet), but a= lso seems
> to indicate that it is in IETF Last Call. =A0Are the two happening at<= br> > the same time?


<nhdp-mib-authors>
We actually don't know, and will ask the chairs about that.
</nhdp-mib-authors>


Best regards
Ulrich and Bob
--047d7b2ee19999ce0404beabfd77-- From jmh@joelhalpern.com Fri Apr 27 11:03:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314521F86F5; Fri, 27 Apr 2012 11:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjBFTpNEdj4B; Fri, 27 Apr 2012 11:03:25 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E2BFA21F86E8; Fri, 27 Apr 2012 11:03:25 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id CEB795580DD; Fri, 27 Apr 2012 11:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9CC521BCE071; Fri, 27 Apr 2012 11:03:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 378DF1BCE06F; Fri, 27 Apr 2012 11:03:24 -0700 (PDT) Message-ID: <4F9ADF8B.804@joelhalpern.com> Date: Fri, 27 Apr 2012 14:03:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Ulrich Herberg References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Apr 2012 12:48:52 -0700 Cc: gen-art@ietf.org, manet@ietf.org, "A. Jean Mahoney" , sratliff@cisco.com Subject: Re: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 18:03:26 -0000 Pending actual text availability, the approaches described seem to recognize the issues and plan to address them appropriately. I look forward to seeing the result when it is ready, Thank you, Joel On 4/27/2012 12:56 PM, Ulrich Herberg wrote: > Dear Joel, > > thank you very much for your review and apologies for our late reply. > Find our answers below, and > please tell us if they address your comments. > > ---------- Forwarded message ---------- > From: Joel M. Halpern > > Date: Fri, Apr 6, 2012 at 8:59 AM > Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 > To: gen-art@ietf.org > Cc: manet@ietf.org , "A. Jean Mahoney" > >, > sratliff@cisco.com > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-manet-nhdp-mib-12 > > Definition of Managed Objects for the > > Neighborhood Discovery Protocol > > Reviewer: Joel M. Halpern > > Review Date: 6-April-2012 > > IETF LC End Date: 16-April-2012 > > IESG Telechat date: (if known) > > > > Summary: This document is almost ready for publication as a Proposed > > Standard. > > > > That's good :-) > > > > > > > Major issues: > > Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very > > reasonable thing, namely suppress notifications for activity which is > > expected. The text references RFC 4750 as precedent. RFC 4750 is > > clear that the suppress window is tied to specific events (interface > > up and election as a DR.) Section 5.1.3.1 does not specify which > > condition(s) start(s) the suppress window. If, as seems likely, it is > > Interface Up which starts the window, please state that explicitly in > > the text. > > > > How about adding the following sentence at the end of > the paragraph of 5.1.3.1 : > "The suppression window for notifications is started when the 'nhdpIfStatus' > transitions > from its default value of 'false' to 'true'." > > > > > > In section 5.4, in addition to describing objects which are defined > > in the MIB, the text describes, under the heading "The following > > objects return statistics related to HELLO messages:", a number of > > what it refers to as "Derived Objects". These do not appear to be > > actual elements of the MIB. They appear rather to be descriptions of > > calculations which the manager can perform using the information from > > the MIB. It is not at all clear why they are here. If I am > > understanding their role properly, and if they belong in this > > document, they belong in some other section, as they are NOT objects > > which return statistics related to HELLO messages. They appear not to > > be returned by the managed device at all. > > > > > Yes, you are right. We we pull these from the draft and > save the text and possibly use elsewhere in the future. > > > > > > Minor issues: > > I can not find the object that corresponds to the setting for > > Ignoring the Initial Activity. I presume this is my error. The > > document would be helped if the object were named in section 5.1.3.1. > > > > > > We can change 'HELLO_INTERVAL' in Section 5.1.3.1 to 'nhdpHelloInterval'. > > > > > > I believe section 5.1.3.2 on Throttling Traps is intended to refer > > to the StateChange Threshold and StateChangeWindow objects. It would > > be very helpful if these were actually named in section 5.1.3.2. > > > > How about adding the following sentence to 5.1.3.2 : > The following objects are used to define the thresholds and time > windows for specific Notifications defined in the NHDP-MIB module: > nhdpNbrStateChangeThreshold, > nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, > nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold, > nhdpIfRxBadPacketWindow. > > > > > Most MIBs I review have a description of the tables they contain, > > how the tables relate to each other, and how they are indexed, in the > > front matter that is roughly equivalent to section 5.2, 5.3, and 5.4. > > As I am not a MIB Doctor, I do not know if that is formally required, > > but I find it very helpful, and am surprised not to see it here. > > > > We agree that this is probably a good practice to follow and will work > up text to handle this. > > > > > In looking at the fields in the NhdpInterfaceEntry, some of the > > field definitions include some of the constraints from RFC 6130 > > section 5 in their DESCRIPTION clauses. Some do not. (For exampple, > > REFRESH_INTERVAL >= HELLO_INTERVAL is captured in > > nhdbpRefreshInterval, but not in nhdpHelloInterval. The requirement > > that nhdpHelloInterval be greater than 0 is not captured anywhere. > > Neither is H_HOLD_TIME >= REFRESH_INTERVAL captured.) Some elements > > have a statement that the object is persistent, while others do not, > > but these do not seem to correspond to a difference in RFC 6130. It > > is possible that there is a good reason for this apparent variation. > > Is there? > > > > That's true. We will go through all constraints from NHDP and > add them to the MIB. > > > > > > Particularly for top-level objects such as nhdpNHoldTime and > > NhdpIHoldTime I would really like to see a better description than > > just this is object from section 5 of RFC 6130. Someone who > > is using the MIB, who is looking at the description clause for > > assistance, really needs something more than the name of the field in > > the MIB. (I think better descriptions would be a good idea through > > much of the MIB.) > > > > > We will can look at the descriptions and copy some more text from > NHDP. However, we would like to avoid copying all NHDP into the MIB. > > > > > Nits/editorial comments: > > The tracker claims this is "In WG Last Call (manet), but also seems > > to indicate that it is in IETF Last Call. Are the two happening at > > the same time? > > > > We actually don't know, and will ask the chairs about that. > > > > Best regards > Ulrich and Bob From abdussalambaryun@gmail.com Fri Apr 27 13:54:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645121F86EB for ; Fri, 27 Apr 2012 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okKRRqrZUcbY for ; Fri, 27 Apr 2012 13:54:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 417D121F86E8 for ; Fri, 27 Apr 2012 13:54:36 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1020382vcb.31 for ; Fri, 27 Apr 2012 13:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lk8DrsGGnhajta71pavlIZyQ10xE6YduWLIf4Ph2OIQ=; b=S+c0s6aK2bIagFNuLW+ayMGZ4OG4NVmd9GofhqUkkZxxs08CaP1j9iFZIXVFaOM2UE fj192h+QEiFm2yXGnaXWI11vWs018wTgPTJaHv4uZKbp1MR7svI+fPaCHWhQRZ4qAJao E03xGRYmHnldzR9hB7u6tXvD1EZM9L2w/eNjOKOcEtXv+1p08eTr/ML/6NJik99dtUuk ncfOkdVGmKykMX1khA2FblmvFBdL94bltIgXgn5MyxudLX2+kFd3hkkkC7Ek2U6FdRhl rMFc5FUvjCSqWq8n/U04Bgm6h58S5esEUqFGrwgJMlALp3lL3B2lqGp4IGDiaTWC/w5B PSTA== MIME-Version: 1.0 Received: by 10.52.23.81 with SMTP id k17mr1926694vdf.103.1335560075726; Fri, 27 Apr 2012 13:54:35 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Fri, 27 Apr 2012 13:54:35 -0700 (PDT) In-Reply-To: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Fri, 27 Apr 2012 22:54:35 +0200 Message-ID: From: Abdussalam Baryun To: Bo Berry Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 20:54:37 -0000 On 4/27/12, Bo Berry wrote: > > We need to also add the OSPF MANET extensions, and other protocols that > currently use DLEP. I agree with you. I will complete reviewing the dlep-draft to see its advantages if other protocols add the DLEP server instead of modifying the DLEP messages, by seeing the MANET in DLEP eyes, then possibility to create a new protocol, and/or add to the progress works available. IMO the source routing protocol (e.g. DSR) will be advanced by using DLEP. Do you think that it is important that DLEP-server should inform either the server's protocol, or its needed information within the exchange message's type field or you have another way? because I was thinking of a scenario of different protocols controlling the same wireless-link (not in the same time, may need scheduling) with different needs from DLEP, therefore DLEP can be used to adapt protocols to wireless-link's characteristics, which we don't have so far without DLEP ideas. Regards Abdussalam > > -Bo > > On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: > >> Hi Stan, >> >> I hope we can consider the interest to use DLEP by all MANET routing >> which are standard and which are work in progress, therefore, I >> suggest that any update in its techniques to consider all routing DSR, >> AODV, OLSR, DYMO etc. protocols' aspects of needed informations or >> entry updates. On the other hand the different types of link >> technologies used may add to DLEP considerations. >> >> Regards >> >> Abdussalam Baryun >> University of Glamorgan, UK >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole use > of the intended recipient. This email may contain information that is > protected by NDA. Any unauthorized review, use, distribution or disclosure > by others is strictly prohibited. If you are not the intended recipient (or > authorized to receive for the recipient), please contact the sender by reply > email and delete all copies of this message. > > > > From abdussalambaryun@gmail.com Fri Apr 27 14:38:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BDF21E8018 for ; Fri, 27 Apr 2012 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.687 X-Spam-Level: X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkk0Wq9iRwOP for ; Fri, 27 Apr 2012 14:38:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC50111E8073 for ; Fri, 27 Apr 2012 14:38:10 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1048983vcb.31 for ; Fri, 27 Apr 2012 14:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Yrcaq14KOegFFO+6bqJHLvP+hG2zqjLm7SQA3M5wv7c=; b=MyPgiaXsPbe004m3AoXQzroWv+CmYPfZArzJPe4iLxy6CGP8sZTwTMexxbGMSvl/UN aeuFZ99j6vCV5Wd90IfK+rWJ1vWSTfy6VUW9NpgclG46NA0SM5dNsv2eDFWoLOejgDg9 PYUXGogyXhhBFtvetkxqi2S0JzeMb9xUBOAwueJeCOJiJN4XtaqF5hzDxrPxswIVIf/Y JV53qoXD7m9mLiz2L0RvA3UdDQG1ihaK7ApN4+risilUmG3Ewc1FWg4CmrsD1iWwvK6D EPzkhU0lXtLHlouUjm9qNpuNa+8IsTm4fQ8i18CvOc5euICLc6fesL5g1FQIpH5a9nB3 X+3Q== MIME-Version: 1.0 Received: by 10.52.178.129 with SMTP id cy1mr11011728vdc.8.1335562690330; Fri, 27 Apr 2012 14:38:10 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Fri, 27 Apr 2012 14:38:10 -0700 (PDT) Date: Fri, 27 Apr 2012 23:38:10 +0200 Message-ID: From: Abdussalam Baryun To: manet , ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: boberry@cisco.com Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:38:11 -0000 >P.S. My tone may have been a little strong in that email, apologies. I thi= nk it is >great to have implementations of the standards we come up in MANE= T, even more >so if there are several of them. But I think as a WG we shoul= d do the right thing >and make sure that our standards, such as RFC5444, ar= e used in the intended >and ideal way. And some DLEP implementations (e.g. = Henning's) seem to use >RFC5444 Message-TLVs and address blocks already, so= there is also proof that >this works (and does not require to modify the R= FC5444 parser). >Ulrich (probably my last email on the subject) > "I think as a WG we should do the right thing " It may be the right thing to do and it may be wrong, we need to be sure, because still the DLEP did not complete its way through. I think it is good to base theory on solid-theory, but it is better to make theory independent first, then think which to make which theory the base of the other, depending-on/considering their design purposes. Doing things right doesn't mean to respect the first come first serve, or leave or take, there may be a gap not seen, and designers take chances to the best of their purpose. IMHO considering the DLEP use-case is a new case so it is different from that of the use case of others, so it is not right to build on old basis for the first stage. I think it is interesting to use 5444 but it does not mean that it cannot be updated or modified to a better standard that fulfills other conditions which was not considered when authors and WG discussed it. However, I hope DLEP authors can solve this issue, but we never know in the future new things may come up and change again :) Regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Darryl, I don't believe that to be an argument. I still believe the WG should do its best job to come up with the best solution. DLEP is a WG document and uses RFC5444, but not correctly. That worries me, and the only real counter-argument to the suggested changes so far has been "we have an existing implementation and don't want to change it.". Ulrich On Apr 27, 2012, at 7:17, dsatterw wrote: > I personally have an issue at this stage of the game (we are now on our 3= rd > version of DLEP) of having to completely rewrite our packet format so tha= t > it better integrates into RFC5444. At this point we have at least 4 worki= ng > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. I= f > we, at this point, decide to rewrite the packet formats then everyone tha= t > has working versions today would have work to do without really any benef= it > IMO. If this objection were brought up in the 00 or 01 version of the dra= ft > it would be a little easier to accept than year(s) later. To be quite > honest, I don't think DLEP fits well in RFC5444 in the first place. RFC54= 44 > states that it should be used by routing protocols for information exchan= ge > and DLEP is not a routing protocol. I would really rather spend our time > trying to make sure that the content being exchanged between the radio an= d > router is adequate than arguing about packet parsers. > > Darryl Satterwhite > Cisco Systems > > > On 4/27/12 9:31 AM, "Henning Rogge" wrote: > >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) >> wrote: >>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 = then >>> having a 5444 parser may be taken as the starting point. And without su= b-TLVs >>> that's all the parser you need. >> >> Exactly. >> >>> I'm afraid I think this is a clear case of design using 5444 without re= ally >>> appreciating it. And then when people who have greater familiarity with= 5444 >>> suggest what is a more natural use of 5444, meeting a resistance that m= ay be >>> based on several things, but offering a better fit to 5444 and better p= arsing >>> options are not among those things. >> >> Yes. >> >> At the moment DLEP is not using RFC5444 at all... except as a wrapper >> around its own format. And everything DLEP does at the moment can be >> expressed in a reasonable way within RFC5444. >> >> Henning Rogge > > _______________________________________________ From hrogge@googlemail.com Fri Apr 27 14:44:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF921F8603 for ; Fri, 27 Apr 2012 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9sNH2bPj5m3 for ; Fri, 27 Apr 2012 14:44:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7440221E8024 for ; Fri, 27 Apr 2012 14:44:16 -0700 (PDT) Received: by lagj5 with SMTP id j5so908184lag.31 for ; Fri, 27 Apr 2012 14:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+KV5r2gje5GPmUSp7PEHjSKww86cbbRvV56ZsWHyyuE=; b=U/MusFInw15610HsM+tC5FQxfJzRJnFuCvPF+Q5bSAaVINtXZ15+YFc6duX8EZa7Zf LADnruyawsvK/YNKGstgym4/5g+KYti02RgkxNF4FjDKzQ7HsbFG97uCEjqqbFGmEKT1 00t/GVWPqbKdxVU1J48w8cBGv6qotuunWJTbeQ8SGrwv+30IHEMSDZC9rwWd0lkpbAaU rKqbC3r9LhZISL0cD5MNdBnGCh6qSTfepuv6IWrH5ga/vszIScZjV+Bb/ClgA7SSNhpw ODgy7o55WqR+9OERu9qbEqZGQtMIqYNriUyS1lNPOibfSTMZfoNsTo22N7tphhtsPzNs p/Hw== Received: by 10.112.9.130 with SMTP id z2mr2384064lba.83.1335563055188; Fri, 27 Apr 2012 14:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 27 Apr 2012 14:43:51 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> From: Henning Rogge Date: Fri, 27 Apr 2012 23:43:51 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:44:19 -0000 I think a DLEP-server (the one that can receive data from a DLEP equipped radio) could be a good addition/plugin to any routing system that can work with arbitrary and dynamic metric values for their links. You just need some more code that either transforms the 'dimensionless metric' into the local representation or calculates its own metric from the raw metric values. Henning Rogge On Fri, Apr 27, 2012 at 22:54, Abdussalam Baryun wrote: > On 4/27/12, Bo Berry wrote: >> >> We need to also add the OSPF MANET extensions, and other protocols that >> currently use DLEP. > > I agree with you. I will complete reviewing the dlep-draft to see its > advantages if other protocols add the DLEP server instead of modifying > the DLEP messages, by seeing the MANET in DLEP eyes, then possibility > to create a new protocol, and/or add to the progress works available. > IMO the source routing protocol (e.g. DSR) will be advanced by using > DLEP. > > Do you think that it is important that DLEP-server should inform > either the server's protocol, or its needed information within the > exchange message's type field or you have another way? because I was > thinking of a scenario of different protocols controlling the same > wireless-link (not in the same time, may need scheduling) with > different needs from DLEP, therefore DLEP can be used to adapt > protocols to wireless-link's characteristics, which we don't have so > far without DLEP ideas. > > Regards > Abdussalam > > >> >> -Bo >> >> On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: >> >>> Hi Stan, >>> >>> I hope we can consider the interest to use DLEP by all MANET routing >>> which are standard and which are work in progress, therefore, I >>> suggest that any update in its techniques to consider all routing DSR, >>> AODV, OLSR, DYMO etc. protocols' aspects of needed informations or >>> entry updates. On the other hand the different types of link >>> technologies used may add to DLEP considerations. >>> >>> Regards >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> ---- >> boberry@cisco.com >> This email may contain confidential and privileged material for the sole use >> of the intended recipient. This email may contain information that is >> protected by NDA. Any unauthorized review, use, distribution or disclosure >> by others is strictly prohibited. If you are not the intended recipient (or >> authorized to receive for the recipient), please contact the sender by reply >> email and delete all copies of this message. >> >> >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Fri Apr 27 15:06:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CED21E8018 for ; Fri, 27 Apr 2012 15:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy8uoOxxYzsc for ; Fri, 27 Apr 2012 15:06:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27621F861F for ; Fri, 27 Apr 2012 15:06:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1052421vbb.31 for ; Fri, 27 Apr 2012 15:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lRQJIFkxRyozeW7nx/Bh1HjzYYIvUGRNSiEO8vA9uLI=; b=Fj6JejanwQYWcxd7O0wHmisSFD4ifxqvD5KsdvzcKwLRXJiGx3Cb7OMXe8H+IEN5dW Uthf2bdbNHh+Ys+h4YRsCClt2myX+Ku/B5uSS1r3fCPdxZow+IqcAkZyuJ2h5+YrJE7H uDHCsfQh8B76edm756PP/2nKUWyn1W5ReT/5fxfmOy/WJkg9iuSuQRJxI824krV0s6Oe 4g5w1IqLdWCYQxid9s1OigWitU6bqRQGwfovV/d1yO4q6YJP3fib6h+EPhgYQsjDNzSR qyxqfaB+E3ax1mmuQnOgjx7oeQULU2RgaQf9n2R505NajkaIdRoMU5icTv3RGwJchb75 Iu2A== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr8582885vdb.55.1335564380816; Fri, 27 Apr 2012 15:06:20 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Fri, 27 Apr 2012 15:06:20 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Sat, 28 Apr 2012 00:06:20 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 22:06:22 -0000 Hi Henning, Yes I agree with you, and also the metric may not be the only needed information or update, MANET protocols assume some specific conditions, so they can simplify the standard/protocol design, so in MANET we never have a standard/protocol that is the general solution for all scenarios/conditions. Therefore, DLEP may help in making our assumptions less or more even reasonable, in bad scanrios for our protocols. Abdussalam, On 4/27/12, Henning Rogge wrote: > I think a DLEP-server (the one that can receive data from a DLEP > equipped radio) could be a good addition/plugin to any routing system > that can work with arbitrary and dynamic metric values for their > links. You just need some more code that either transforms the > 'dimensionless metric' into the local representation or calculates its > own metric from the raw metric values. > > Henning Rogge > > On Fri, Apr 27, 2012 at 22:54, Abdussalam Baryun > wrote: >> On 4/27/12, Bo Berry wrote: >>> >>> We need to also add the OSPF MANET extensions, and other protocols that >>> currently use DLEP. >> >> I agree with you. I will complete reviewing the dlep-draft to see its >> advantages if other protocols add the DLEP server instead of modifying >> the DLEP messages, by seeing the MANET in DLEP eyes, then possibility >> to create a new protocol, and/or add to the progress works available. >> IMO the source routing protocol (e.g. DSR) will be advanced by using >> DLEP. >> >> Do you think that it is important that DLEP-server should inform >> either the server's protocol, or its needed information within the >> exchange message's type field or you have another way? because I was >> thinking of a scenario of different protocols controlling the same >> wireless-link (not in the same time, may need scheduling) with >> different needs from DLEP, therefore DLEP can be used to adapt >> protocols to wireless-link's characteristics, which we don't have so >> far without DLEP ideas. >> >> Regards >> Abdussalam >> >> >>> >>> -Bo >>> >>> On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: >>> >>>> Hi Stan, >>>> >>>> I hope we can consider the interest to use DLEP by all MANET routing >>>> which are standard and which are work in progress, therefore, I >>>> suggest that any update in its techniques to consider all routing DSR, >>>> AODV, OLSR, DYMO etc. protocols' aspects of needed informations or >>>> entry updates. On the other hand the different types of link >>>> technologies used may add to DLEP considerations. >>>> >>>> Regards >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> ---- >>> boberry@cisco.com >>> This email may contain confidential and privileged material for the sole >>> use >>> of the intended recipient. This email may contain information that is >>> protected by NDA. Any unauthorized review, use, distribution or >>> disclosure >>> by others is strictly prohibited. If you are not the intended recipient >>> (or >>> authorized to receive for the recipient), please contact the sender by >>> reply >>> email and delete all copies of this message. >>> >>> >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From hrogge@googlemail.com Fri Apr 27 15:09:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F94121E802D for ; Fri, 27 Apr 2012 15:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQiTQjmjtB0P for ; Fri, 27 Apr 2012 15:09:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3AB21E8024 for ; Fri, 27 Apr 2012 15:09:51 -0700 (PDT) Received: by lagj5 with SMTP id j5so919290lag.31 for ; Fri, 27 Apr 2012 15:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c0Y1eED/1XQ4PPiSHe1gD60mmK+UqEMfoq7zuQzjIPM=; b=ssPL5Q3jwSFNtwT9/nri5yGLrDbPaAlE5OAamB0o+ZLGaaEfpHy9ab9Hg8WbZt8Xmp C9WUu6woP4HaZ+jCi5S61mfSpZ/xXXbItjR3OM1TpY+EZYIxAMcmeZCZkoQjopdnzyeJ 8T4Kp0s+8ItUXNJCh6JSaMCHpyJlS4ggjCEvxZRizBhrntrJdfOF2McdcjArkM1KLjHc Paj3dLUtSxRrmD/PuoVOmIXk8myqEJ/5pA1n3ZR3ZiqQcsynFm22PEHiPpekRpQ8I2pR 3pCZHQXKr0yr3NLC4GxqWSsJ1wO9krCqs2fwxfRokrHfNHroRri3RVR4uIYBiKrcqN9A 3iDA== Received: by 10.112.99.71 with SMTP id eo7mr6207001lbb.84.1335564590258; Fri, 27 Apr 2012 15:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.8 with HTTP; Fri, 27 Apr 2012 15:09:30 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> From: Henning Rogge Date: Sat, 28 Apr 2012 00:09:30 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 22:09:52 -0000 What kind of assumptions do you mean? Henning Rogge On Sat, Apr 28, 2012 at 00:06, Abdussalam Baryun wrote: > Hi Henning, > > Yes I agree with you, and also the metric may not be the only needed > information or update, MANET protocols assume some specific > conditions, so they can simplify the standard/protocol design, so in > MANET we never have a standard/protocol that is the general solution > for all scenarios/conditions. Therefore, DLEP may help in making our > assumptions less or more even reasonable, in bad scanrios for our > protocols. > > Abdussalam, > > On 4/27/12, Henning Rogge wrote: >> I think a DLEP-server (the one that can receive data from a DLEP >> equipped radio) could be a good addition/plugin to any routing system >> that can work with arbitrary and dynamic metric values for their >> links. You just need some more code that either transforms the >> 'dimensionless metric' into the local representation or calculates its >> own metric from the raw metric values. >> >> Henning Rogge >> >> On Fri, Apr 27, 2012 at 22:54, Abdussalam Baryun >> wrote: >>> On 4/27/12, Bo Berry wrote: >>>> >>>> We need to also add the OSPF MANET extensions, and other protocols that >>>> currently use DLEP. >>> >>> I agree with you. I will complete reviewing the dlep-draft to see its >>> advantages if other protocols add the DLEP server instead of modifying >>> the DLEP messages, by seeing the MANET in DLEP eyes, then possibility >>> to create a new protocol, and/or add to the progress works available. >>> IMO the source routing protocol (e.g. DSR) will be advanced by using >>> DLEP. >>> >>> Do you think that it is important that DLEP-server should inform >>> either the server's protocol, or its needed information within the >>> exchange message's type field or you have another way? because I was >>> thinking of a scenario of different protocols controlling the same >>> wireless-link (not in the same time, may need scheduling) with >>> different needs from DLEP, therefore DLEP can be used to adapt >>> protocols to wireless-link's characteristics, which we don't have so >>> far without DLEP ideas. >>> >>> Regards >>> Abdussalam >>> >>> >>>> >>>> -Bo >>>> >>>> On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: >>>> >>>>> Hi Stan, >>>>> >>>>> I hope we can consider the interest to use DLEP by all MANET routing >>>>> which are standard and which are work in progress, therefore, I >>>>> suggest that any update in its techniques to consider all routing DSR, >>>>> AODV, OLSR, DYMO etc. protocols' aspects of needed informations or >>>>> entry updates. On the other hand the different types of link >>>>> technologies used may add to DLEP considerations. >>>>> >>>>> Regards >>>>> >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> ---- >>>> boberry@cisco.com >>>> This email may contain confidential and privileged material for the sole >>>> use >>>> of the intended recipient. This email may contain information that is >>>> protected by NDA. Any unauthorized review, use, distribution or >>>> disclosure >>>> by others is strictly prohibited. If you are not the intended recipient >>>> (or >>>> authorized to receive for the recipient), please contact the sender by >>>> reply >>>> email and delete all copies of this message. >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Sat Apr 28 01:05:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CD621F86DE for ; Sat, 28 Apr 2012 01:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgYZmbDM7rxb for ; Sat, 28 Apr 2012 01:05:19 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5021F86DD for ; Sat, 28 Apr 2012 01:05:18 -0700 (PDT) Received: by eeke51 with SMTP id e51so365807eek.31 for ; Sat, 28 Apr 2012 01:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=P+VYP3xvd9qAUKB1+fr3TWwTuaF6b6o/VLcr5SoMPXs=; b=B2WeJ4b8vWLUIpfM5/H7wVc2dyRS4Al0+kPQJz/sCl8neBgS/C7PhBLA3IDNZdQpX9 Qd1jQBcVFOeACCIFG8YC+OV8tKoR30WUesCCC51J8biaEeg0NnDsIyws185PmddXzeYh P5xx3kzuHC8BVF5PcuSdWJgzecFVykS3wQGZ96wTanqV1bLyJ3Q7DVw77pj11E3Pmwfg 7XkXoEtYgNl8QSAfficcXEzTQJsKDiG2Uwx3QBRBDkzrUkcGH9WEl0jlwE7wqnGrNG5b Dy/2TmmE2TmXqHdsKtYZQizIpePCWx+hyOQNrSNlDJRW9EoD1WLgJePaOC7fCM5hFOKU 7u0g== Received: by 10.213.17.19 with SMTP id q19mr1001823eba.142.1335600317925; Sat, 28 Apr 2012 01:05:17 -0700 (PDT) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m55sm42081168eei.1.2012.04.28.01.05.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 01:05:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Sat, 28 Apr 2012 10:05:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00ADCB3D-109B-4498-85D2-307E6F7585C3@inf-net.nl> References: To: Henning Rogge X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm/B17/V10dWb9AIFA8/mIefn0AWO7+nD6anSY22/FgVfemW/D95DjkJXav7HwYUD2q9Zr4 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 08:05:20 -0000 I brought up the complexity of DLEP long time ago. It is not only TLV encoding, but also using reliable transfer instead of using validity timers. This introduces synchronisation of state machines on modem and router. IMHO unneeded and it should be removed. Current DLEP reduces traffic with transfer of updates only (the OSPF approach), where 5444 optimizes transfer of repeating messages (the OLSR approach). Where information changes over and over, and is related to addresses, 5444 is to be used. ACKing this info doesn't make sense. Loss rate on=20 local link is expected to be extremely low anyway. I don't mind go forward with current DLEP as-is as experimental DLEP, and discuss an improved DLEPv2. Same approach as OLSR -> OLSRv2, where OLSR uses simple encoded messages and OLSRv2 the optimized variant. AFAIK Henning his efforts takes DLEP to DLEPv2. Teco Op 27 apr. 2012, om 18:32 heeft Henning Rogge het volgende geschreven: > On Fri, Apr 27, 2012 at 18:25, dsatterw wrote: >> Ulrich, >>=20 >> You point is taken and I didn=92t take it in a negative way. I just = wish we >> could have had this lively discussion when reviewing DLEP 01 not DLEP = 02. > Sorry for triggering this discussion that late. I always had the 'need > to build a DLEP agent' on my personal hobby list, but looking into it > only became part of my job at work in late March. >=20 > I have talked with quite a few people who tried to use the "radio to > router" extension for PPPoE, and none of them were happy about it. We > need something like DLEP as a really good standard, but I fear we will > loose quite a few opportunities if we do not fix it now. >=20 > And going for a third standard to do this kind of work doesn't sound = very good. >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Apr 28 02:54:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D0B21F86D8 for ; Sat, 28 Apr 2012 02:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2ZA4aB-eZar for ; Sat, 28 Apr 2012 02:54:06 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE521F86D7 for ; Sat, 28 Apr 2012 02:54:06 -0700 (PDT) Received: by dady13 with SMTP id y13so2682012dad.27 for ; Sat, 28 Apr 2012 02:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v9kqmEQTA5Q1nH8TO0Dw4lHk6RdJc3WQ2VwyytHO1og=; b=Xg34ez+InCGaGzFywDMn12oz+9nFNXn/WbnxABHiBghy3sBqGjOCyM/jVxR5QeK6mB iusszQvKcffcPhwZyo5SLYpXcgOSb+gbLd6GLhwpQSIMQb29VBV1m25ATDTedvHXPySz 2jO/DEqCUDzfl1T4woC5Tbx02lhi4kpuFud0zAd7tF2hfC6YnHoGzKx4DPhD1QcnsSsU 46BMSPK+9aNgJfzYVTm/dNS/uOWjsYFCR2FxSGDxZynCjbHzh/JmjvQ+MGedqxTfOd5N vSch/9u/WiJG1QElloafU+MYZtXX02V1j9E/2uYShyvhcP0l1siBxH/hNGo/QDyAq4AW SWyw== Received: by 10.68.225.170 with SMTP id rl10mr28285348pbc.76.1335606845961; Sat, 28 Apr 2012 02:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Sat, 28 Apr 2012 02:53:44 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 28 Apr 2012 11:53:44 +0200 Message-ID: To: dsatterw Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 09:54:07 -0000 Is there a current version of the source that compiles cleanly? I would like to take a look at the sourcecode at Sourceforge. I downloaded the sourceforge code, but my GCC puts out lots of warnings and errors. (I am using a standard Ubuntu 11.10, gcc 4.6.1 on a x86_64-linux-gnu system) Henning Rogge On Fri, Apr 27, 2012 at 16:17, dsatterw wrote: > I personally have an issue at this stage of the game (we are now on our 3rd > version of DLEP) of having to completely rewrite our packet format so that > it better integrates into RFC5444. At this point we have at least 4 working > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. If > we, at this point, decide to rewrite the packet formats then everyone that > has working versions today would have work to do without really any benefit > IMO. If this objection were brought up in the 00 or 01 version of the draft > it would be a little easier to accept than year(s) later. To be quite > honest, I don't think DLEP fits well in RFC5444 in the first place. RFC5444 > states that it should be used by routing protocols for information exchange > and DLEP is not a routing protocol. I would really rather spend our time > trying to make sure that the content being exchanged between the radio and > router is adequate than arguing about packet parsers. > > Darryl Satterwhite > Cisco Systems > > > On 4/27/12 9:31 AM, "Henning Rogge" wrote: > >> On Fri, Apr 27, 2012 at 14:55, Dearlove, Christopher (UK) >> wrote: >>> I think the diff parsers etc. misses the point. If DLEP is to use 5444 then >>> having a 5444 parser may be taken as the starting point. And without sub-TLVs >>> that's all the parser you need. >> >> Exactly. >> >>> I'm afraid I think this is a clear case of design using 5444 without really >>> appreciating it. And then when people who have greater familiarity with 5444 >>> suggest what is a more natural use of 5444, meeting a resistance that may be >>> based on several things, but offering a better fit to 5444 and better parsing >>> options are not among those things. >> >> Yes. >> >> At the moment DLEP is not using RFC5444 at all... except as a wrapper >> around its own format. And everything DLEP does at the moment can be >> expressed in a reasonable way within RFC5444. >> >> Henning Rogge > -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sat Apr 28 04:00:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6465821F86BB for ; Sat, 28 Apr 2012 04:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r1ovohyUaC4 for ; Sat, 28 Apr 2012 04:00:02 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id C4C2D21F86B8 for ; Sat, 28 Apr 2012 04:00:02 -0700 (PDT) Received: by dady13 with SMTP id y13so2746481dad.27 for ; Sat, 28 Apr 2012 04:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+jriA4L2rc3k7P3TivL7X/I2omejKW6KN8PKJTUH2ck=; b=gv06/xol9x6o/CQm2UNGvFurUluark799U/M/EyceNqNdfcnv+Rb62r6t0LKS3xd5L HqYraQbZksCJQAKMpJ0qdt5Iyo+Py1miFV5DCI9ltqq175L+VVE8Ssva5sVv9pBXC95u phlxXa4UzcAbYVFxtcQeuObk6RsTZVUXXrTiaUtwLVs22hItoAnr+tcw06Y8wdjtoplK bP8ZXcLCKXyUQ5oF5i5S+kPeR4xCf6DJ/PYYmBwyxLNAEI4E3npr+RPAzfwIZgLWCP6z HRiRFEonRZJwEDcpcveY18LEHzW4O7qPT7FaOeF7uNldUsKTegHiyNYCzoI9N2te5oLg ZM9Q== Received: by 10.68.135.40 with SMTP id pp8mr31027222pbb.13.1335610802583; Sat, 28 Apr 2012 04:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Sat, 28 Apr 2012 03:59:42 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 28 Apr 2012 12:59:42 +0200 Message-ID: To: dsatterw Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 11:00:03 -0000 On Fri, Apr 27, 2012 at 16:17, dsatterw wrote: > At this point we have at least 4 working > implementations of DLEP out there which were all based on our sourceforge > example of a packet parser that seems sufficient for the ones involved. One more questions about the sourceforge code: Could it be that the sourceforge code is only compatible with DLEP-00? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From D.He@surrey.ac.uk Sat Apr 28 07:46:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A453F21F8661 for ; Sat, 28 Apr 2012 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnywMZVdlPjD for ; Sat, 28 Apr 2012 07:46:55 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id DB20F21F865F for ; Sat, 28 Apr 2012 07:46:54 -0700 (PDT) Received: from [193.109.255.147:58529] by server-5.bemta-14.messagelabs.com id 95/50-30733-DD20C9F4; Sat, 28 Apr 2012 14:46:53 +0000 X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-5.tower-72.messagelabs.com!1335624413!7283182!2 X-Originating-IP: [131.227.200.39] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7572 invoked from network); 28 Apr 2012 14:46:53 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-5.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 28 Apr 2012 14:46:53 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.208]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Sat, 28 Apr 2012 15:46:45 +0100 From: To: Date: Sat, 28 Apr 2012 15:46:44 +0100 Thread-Topic: Congestion avoidance routing in MANET Thread-Index: AQHNJUp5Q950ys00wkWmlF1CHL1O5g== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 14:46:55 -0000 Dear all, my feeling is that the issues on congestion avoidance in MANET are bogus to= pic. I had read a paper entitled on "Adapting connectionless approach to mobile = ad hoc networks in obstacle environment " on Wireless Pervasive Computing, 2006 1st International Symposium on 2006. = the authors found the packet loss increases if the nodes send more traffic over cross path li= nks. then the cross point of two paths in MANET could be the congestion area.=20 I have quite not agreed with the claim that existing MANET routing " may su= ffer from packet loss because=20 the packet forwarding policy doesn't consider traffic congestion".=20 my fellow colleagues, do you know what scenarios or when the congestion cou= ld happen in MANET?=20 I don't think the packet loss is due to congestion in high dynamic scenario= , it may be occurred due to link quality becoming bad. therefore, I feel that congestion avoidance rout= ing investigation in MANETs is a bogus topic, am I right? Best Regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dan He Research Fellow From hrogge@googlemail.com Sat Apr 28 11:16:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F921F8593 for ; Sat, 28 Apr 2012 11:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.942 X-Spam-Level: X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+Ti6tYXfjRx for ; Sat, 28 Apr 2012 11:16:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08921F858D for ; Sat, 28 Apr 2012 11:16:18 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2201213pbb.31 for ; Sat, 28 Apr 2012 11:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=aQvlsKh5vooXip4J13VkclS6N1Be8Vc1KeqJ1kWIVSg=; b=grzk1c4rftOaVVbT6EJRrGbyti1LaBky+fIdnTxa2ejkaqJOvz1iQLJoZtwWbBqJs4 YPw9FhcaBac/sswBVmL4FUoR3rIev+4EutZyjNnOpkYTF1ZKLlQUvzAc+QrepSyBfosP Sb3KMaW/u2+XIHYFBI97JrtXhs25dhDkzX5tA0IGpWa0Tu/d7oj1ovNVkonhzqTCi6Y/ xojpSvp0gJaIbTSXzEHjleLkKg34dXrJ3hgOd9sSmPlULJRlbLkqAVvp+LHiya21orO1 VmIBtYtbU8+T+6AnZ7p4/dD1IvLEFhVF91e52Y3usVKXt+UbDjuqZGpps+zi0iqQBguM IRyQ== Received: by 10.68.224.165 with SMTP id rd5mr3967635pbc.160.1335636977918; Sat, 28 Apr 2012 11:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Sat, 28 Apr 2012 11:15:57 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sat, 28 Apr 2012 20:15:57 +0200 Message-ID: To: D.He@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 18:16:19 -0000 The problem of "conventional" MANET systems is that when you detect the congestion, its most likely already to late to do much about it, because you cannot talk anymore to your neighbors. The problem with a lot of "too clever" approaches to routing depending on current traffic patterns is that they can lead to highly fluctuating routes or even routing loops. Henning Rogge On Sat, Apr 28, 2012 at 16:46, wrote: > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus = topic. > I had read a paper entitled on "Adapting connectionless approach to mobil= e ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006= . =A0the authors found > the packet loss increases if the nodes send more traffic over cross path = links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may = suffer from packet loss because > the packet =A0forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion c= ould happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenar= io, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance ro= uting investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Sun Apr 29 06:19:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBB621F84CE for ; Sun, 29 Apr 2012 06:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnzROcjB5JG2 for ; Sun, 29 Apr 2012 06:19:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA021F84CD for ; Sun, 29 Apr 2012 06:19:41 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1824006vcb.31 for ; Sun, 29 Apr 2012 06:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q6ZXQ0EDrttJwDGpPTpdcuMA8fhBI1x0e8SafgGvOSQ=; b=ffY4SbrxkRpUiqgv1UAJwJJMcUgaS1qJrF3j+81qbMTPgeplRjNkuHrmbz4NJ55CN5 2ilfLbHWqUcHSa6TQMjmIxDX1ePhUBlSdheZG9x5ttrTlKqT15ySmQI4RRkqdcy5Z+kX hzi9evZbSRtMvzM380GG0Fg75q/GyyzP8UIpzCIQ6wUVDZkXp0jaSa8MmcpJc8HKOllz 990shIYZfLrXA1WPN9MSVo36Lra4dMnonVB7B8iKXafmjB2HgWbz63GMN8/Gd0aXEWaC 7/N1wcOYyUr6GXoselGqvLN0jzlhnLobzaP+Kkm4RLs3dPnmaDRWMVED0xSIexklAr0p DDbg== MIME-Version: 1.0 Received: by 10.52.23.10 with SMTP id i10mr15311607vdf.24.1335705580637; Sun, 29 Apr 2012 06:19:40 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Sun, 29 Apr 2012 06:19:40 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Sun, 29 Apr 2012 15:19:40 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 13:19:42 -0000 On 4/28/12, Henning Rogge wrote: > What kind of assumptions do you mean? > Henning Rogge To answer the question I will just give my discussion-assumption introduction, then examples of our documented works' direct and indirect assumptions. In general, majority of the world population are using the IP networks in their needed purposes and conditions which may direct the future of the internet implementations/documentations. In IETF community, all WGs agree that each standard/task-work in IETF may be used for internet networks and their applications, therefore, no one documented-standard can claim ( even do claim in written) ; that it is the last agreement solution or that it is not to be replaced/updated, and that it cover all conditions including all-use-cases without no assumptions. So we have standards that assume certain things to be implemented correctly and to be reasonable. In MANET standards, all should assume some points, because of the larger possibilities of MANET scenarios than in the static-networks. Therefore, for any draft presented we need to discuss its assumptions, use-case, functionality/technique, and then contribution to others. However, some documents do not clarify directly all assumptions, but can be understood indirectly. For example of assumptions, RFC3651, RFC6130, RFC925, RFC5444, OLSRv2-work-in-progress, and DLEP-work-in-progress. RFC3561>p32> We assume that such asymmetry cannot persist beyond a certain time, say, a multiple K of HELLO_INTERVAL. In other words, a node will invariably receive at least one out of K subsequent Hello messages from a neighbor if the link is working and the neighbor is sending no other traffic. AB> Therefore, AODV cannot work correctly in the network the condition of asymmetric that persist beyond a certain time. RFC6130>p5>This protocol makes no assumptions about the underlying link layer, other than support of local broadcast or multicast for communication to 1-hop neighbor routers. AB> NHDP assumes support of local broadcast or multicast for communication to 1-hop neighbor routers. If no such support then it is not correct. Also indirectly this protocol has not an awareness of any fault in the L1 wireless communication. RFC925>p5> If the environment is very dynamic making T3 shorter will result in more rapid adaptation to the changes.,,,,,,,, Unfortunately there is no necessary relationship between frequency of use and correctness. AB> it assumes that there is no LOS or NLOS link dynamics in the L1 communication medium, but it mentions the problem of no-reply, and T3 or timeouts-feedback. The correctness of ARP is not gauranteed in such dynamic environment. OLSRv2-work-in-progress>p7> >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, through >its use of [RFC6130], may use link layer information and >notifications when available and applicable. In addition, OLSRv2 >uses link metrics that may be derived from link layer or any other >information. OLSRv2 does not specify the physical meaning of link >metrics, but specifies a means by which new types of link metrics may >be specified in the future, but used by OLSRv2 without modification. AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't have to be depending on Data-Link-layer information and in the same time it may use information from Data-Link-Layer, moreover, claiming it will not need to be modified if there is change in metric or information of underlying. This claim is only true if the Data-Link is using RFC5444, and under RFC5444 claims that the messages are routers' messaging not claiming that messaging are Data-Link messages/information/interaction. therefore OLSRv2 assumes that Data-Link layer MUST RFC5444, so that it can use the information in Data-Link. RFC5444>page 4>This document specifies the syntax of a packet format designed >for carrying multiple routing protocol messages for information exchange >between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >Message Header, which is designed for control of message >dissemination, and a Message Body, which contains protocol >information. AB>Comments> Therefore, RFC5444 is specified to messages-format for exchange between Routers. Secondly it mentions no MUST/SHOULD for the IETF-MANET routing standards that it uses this particular message format, otherwise we need to update all old standards that we have like DSR, AODV, etc. Also it does not mention Data-Link interaction/exchange (i.e. L2 information availability, or L2 frames' formating) at all. DLEP-work-in-progress>p1>When routing devices rely on modems to effect communications over wireless links. AB> DLEP assuming indirectly> that there is a direct channel between router and modem, or that modem is able to sense the change or faults in the wireless-medium used for data communication. Regards, Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ It is important to not claim that our discussions is always right, but like to get feedbacks/comments to know if our discussion is wrong so we can learn and make progress. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > On Sat, Apr 28, 2012 at 00:06, Abdussalam Baryun > wrote: >> Hi Henning, >> >> Yes I agree with you, and also the metric may not be the only needed >> information or update, MANET protocols assume some specific >> conditions, so they can simplify the standard/protocol design, so in >> MANET we never have a standard/protocol that is the general solution >> for all scenarios/conditions. Therefore, DLEP may help in making our >> assumptions less or more even reasonable, in bad scanrios for our >> protocols. >> >> Abdussalam, >> >> On 4/27/12, Henning Rogge wrote: >>> I think a DLEP-server (the one that can receive data from a DLEP >>> equipped radio) could be a good addition/plugin to any routing system >>> that can work with arbitrary and dynamic metric values for their >>> links. You just need some more code that either transforms the >>> 'dimensionless metric' into the local representation or calculates its >>> own metric from the raw metric values. >>> >>> Henning Rogge >>> >>> On Fri, Apr 27, 2012 at 22:54, Abdussalam Baryun >>> wrote: >>>> On 4/27/12, Bo Berry wrote: >>>>> >>>>> We need to also add the OSPF MANET extensions, and other protocols that >>>>> currently use DLEP. >>>> >>>> I agree with you. I will complete reviewing the dlep-draft to see its >>>> advantages if other protocols add the DLEP server instead of modifying >>>> the DLEP messages, by seeing the MANET in DLEP eyes, then possibility >>>> to create a new protocol, and/or add to the progress works available. >>>> IMO the source routing protocol (e.g. DSR) will be advanced by using >>>> DLEP. >>>> >>>> Do you think that it is important that DLEP-server should inform >>>> either the server's protocol, or its needed information within the >>>> exchange message's type field or you have another way? because I was >>>> thinking of a scenario of different protocols controlling the same >>>> wireless-link (not in the same time, may need scheduling) with >>>> different needs from DLEP, therefore DLEP can be used to adapt >>>> protocols to wireless-link's characteristics, which we don't have so >>>> far without DLEP ideas. >>>> >>>> Regards >>>> Abdussalam >>>> >>>> >>>>> >>>>> -Bo >>>>> >>>>> On Apr 27, 2012, at 7:25 AM, Abdussalam Baryun wrote: >>>>> >>>>>> Hi Stan, >>>>>> >>>>>> I hope we can consider the interest to use DLEP by all MANET routing >>>>>> which are standard and which are work in progress, therefore, I >>>>>> suggest that any update in its techniques to consider all routing DSR, >>>>>> AODV, OLSR, DYMO etc. protocols' aspects of needed informations or >>>>>> entry updates. On the other hand the different types of link >>>>>> technologies used may add to DLEP considerations. >>>>>> >>>>>> Regards >>>>>> >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> ---- >>>>> boberry@cisco.com >>>>> This email may contain confidential and privileged material for the >>>>> sole >>>>> use >>>>> of the intended recipient. This email may contain information that is >>>>> protected by NDA. Any unauthorized review, use, distribution or >>>>> disclosure >>>>> by others is strictly prohibited. If you are not the intended recipient >>>>> (or >>>>> authorized to receive for the recipient), please contact the sender by >>>>> reply >>>>> email and delete all copies of this message. >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> > > > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From yi.jiazi@gmail.com Sun Apr 29 06:29:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7F021F851B for ; Sun, 29 Apr 2012 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7iqLT4BECzD for ; Sun, 29 Apr 2012 06:29:11 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC421F84F1 for ; Sun, 29 Apr 2012 06:29:10 -0700 (PDT) Received: by werb10 with SMTP id b10so1660257wer.31 for ; Sun, 29 Apr 2012 06:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=RM0PFeCa2kvHwcR6W6j734VeK0mE42RBH/nbQeL8dYs=; b=vhzbUFNifatdqohN7m2GpIMjwg4ZPf/hcgKt8MMetGkHUfgWi5A41dU2KREBzPglIv PcrDV+FMD7bsxEObNL8zTOMzs0fL8YKVh/7W3/792+lFxW8AyCgCAgbcGmqUEjn8UcbD rdN/oL6pAmGNk942QURPcSGErrpJ0rPee723vy0WH6udyuUp/3fBQTnoCtUGMOwBWbzE wpKK6cbd/fJm8gJJ4jr3I2sWvrwHJ6Bu/BHAbXTIo0Xusro2HEZsbXrrZgRjzBhzdmeD s7PStASNDMpChFrkY8Qf5A/FwhePse6ZHx5cup4yAkQGfH+aky6u2K8UN3RytjG4D9Rn bRTg== Received: by 10.180.92.130 with SMTP id cm2mr13503689wib.4.1335706150051; Sun, 29 Apr 2012 06:29:10 -0700 (PDT) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id fz9sm20803044wib.3.2012.04.29.06.29.08 (version=SSLv3 cipher=OTHER); Sun, 29 Apr 2012 06:29:09 -0700 (PDT) Message-ID: <4F9D4223.2070201@gmail.com> Date: Sun, 29 Apr 2012 15:29:07 +0200 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: D.He@surrey.ac.uk References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 13:29:11 -0000 Hi dear Dan, I didn't read the paper you mentioned before. According to my experience based on simulation, for example, in a field of 1000m*1000m, with 100 routers, the congestion can happen for the routers in the central area of the network. There are packets dropped because of the queue is full. Could you elaborate why you think the congestion avoidance doesn't work, maybe with some simulation/testbed experience? best On 4/28/12 4:46 PM, D.He@surrey.ac.uk wrote: > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus topic. > I had read a paper entitled on "Adapting connectionless approach to mobile ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006. the authors found > the packet loss increases if the nodes send more traffic over cross path links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may suffer from packet loss because > the packet forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion could happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenario, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance routing investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > ======================================= > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Jiazi YI Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France From abdussalambaryun@gmail.com Sun Apr 29 07:34:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48E21F84DC for ; Sun, 29 Apr 2012 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h52f78fdJCEe for ; Sun, 29 Apr 2012 07:34:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8113C21F84E4 for ; Sun, 29 Apr 2012 07:34:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1831217vbb.31 for ; Sun, 29 Apr 2012 07:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Y3fN7yzfzK6GzWVc4KV5loG10L7OOYLn9hC1nBz0MTc=; b=iKdDfFs9jWaDGL54asB4OnAXOJuIowWnks6v3d9yOWFJSj2op51Mzs0QyrIi/3Wal0 ERtshCH2aPJkn4nCa29CdcjX8MrSkbozws4Hu6QVjKs6R79nwntseWv+b5YIYwfmnCrk e1v6BeYVn7bb5houYsHaDNghqA27oEabJAYKtUaGJ+xPVIUV9yVsr8NwDTQcE5UbHtwn GdjKwET9CfPV9aqwTc5lrEK8/977pLlEMggjriI2ckJA25PyViENGvVKj70Dalpq2wAx /SfUdem0DH0Eug/sgetYBZVlqrWdNerAPpLxahoOYiVQkROFI5Ztaa27u7Jh7dRh/RQ1 ao+w== MIME-Version: 1.0 Received: by 10.220.64.137 with SMTP id e9mr10154450vci.9.1335710060791; Sun, 29 Apr 2012 07:34:20 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Sun, 29 Apr 2012 07:34:20 -0700 (PDT) Date: Sun, 29 Apr 2012 16:34:20 +0200 Message-ID: From: Abdussalam Baryun To: D.He@surrey.ac.uk, manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 14:34:22 -0000 It is prefered that the traffic congestion control is solved in MANET transportation-protocol functionality not in its routing protocol, and your fellow colleagues, are right that MANET may suffer congestion and packet loss like any network. The solution is not simple and the problem is not always complicated, there are proposals for MANET packet-loss and congestion in literature. >"Adapting connectionless approach in mobile ad hoc networks for obstacle >environment " AB> That approach/proposal is good, but adds to MANET-architecture more complexity. However, overall we need simple control protocols (is DLEP suitable?) for some environment. > I don't think the packet loss is due to congestion in high dynamic scenario, it may >be occurred due to link quality becoming bad. therefore, I feel that congestion >avoidance routing investigation in MANETs > is a bogus topic, am I right? Your right but not totally. MANET's packet loss is mostly because its dynamics but still may have traffic congestion, because of limited number of links, and/or limited route-path BW. However, traffic sources don't just send their requests/data without getting replies, therefore, at sometime it will realise to stop wasting time and energy. Some protocols solve this information-loss-problem by assuming it does not happen for a notice period of time, and others use some technique to control trasportations. In some routing protocol they use acknoledgment [e.g AODV, DSR] and some adaptations to change [e.g. NHDP, OLSRv2, DYMO]. >The problem of "conventional" MANET systems is that when you detect >the congestion, its most likely already to late to do much about it, >because you cannot talk anymore to your neighbors. AB> unless we use a protocol that changes the wireless link characteristics, as it is now proposed by DLEP-work-in-progress, but still I think it has some limitations (both-link-end syncronisation maybe a problem as was mentioned in discussions). Abdussalam Baryun, University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >The problem of "conventional" MANET systems is that when you detect >the congestion, its most likely already to late to do much about it, >because you cannot talk anymore to your neighbors. >The problem with a lot of "too clever" approaches to routing depending >on current traffic patterns is that they can lead to highly >fluctuating routes or even routing loops. >Henning Rogge On Sat, Apr 28, 2012 at 16:46, wrote: > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus topic. > I had read a paper entitled on "Adapting connectionless approach to mobile ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006. the authors found > the packet loss increases if the nodes send more traffic over cross path links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may suffer from packet loss because > the packet forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion could happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenario, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance routing investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > ======================================= > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet at ietf.org > https://www.ietf.org/mailman/listinfo/manet From D.He@surrey.ac.uk Sun Apr 29 08:38:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422AF21F84DF for ; Sun, 29 Apr 2012 08:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IBllmKLElnb for ; Sun, 29 Apr 2012 08:38:41 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 272EE21F84DC for ; Sun, 29 Apr 2012 08:38:40 -0700 (PDT) Received: from [195.245.231.67:9965] by server-7.bemta-5.messagelabs.com id D0/0E-16195-F706D9F4; Sun, 29 Apr 2012 15:38:39 +0000 X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-8.tower-82.messagelabs.com!1335713919!29397988!1 X-Originating-IP: [131.227.200.35] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30205 invoked from network); 29 Apr 2012 15:38:39 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-8.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Apr 2012 15:38:39 -0000 Received: from EXMB01CMS.surrey.ac.uk ([10.60.0.4]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sun, 29 Apr 2012 16:38:39 +0100 From: To: Importance: high X-Priority: 1 Date: Sun, 29 Apr 2012 16:38:36 +0100 Thread-Topic: [manet] Congestion avoidance routing in MANET Thread-Index: Ac0mDBAIEzCYvT3nSXGA2P2rBbTF1gAENJU/ Message-ID: References: , <4F9D4223.2070201@gmail.com> In-Reply-To: <4F9D4223.2070201@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 15:38:42 -0000 Hi Jiazi, Thanks for your answer. I simply thought that some observations like you fo= und packet loss in simulation then people concluded that we need congestion avoidance in router that was = not entirely true.=20 the queue may be in full that the fact of your application injected too muc= h packets into the network. =20 This actually brings us back to the fundamental network design question: do= we want the network smart=20 or MISS? I would say if too complication mechanism brings into routing lay= er, it is hard to optimize the networks. so I would say congestion avoidance should be put on transportat= ion protocol, such as TCP. if we do the same job as TCP does at routing protocol, do we need TCP = protocol any more? Best Regards, Dan From: Jiazi YI [yi.jiazi@gmail.com] Sent: 29 April 2012 14:29 To: He D Dr (CCSR) Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET Hi dear Dan, I didn't read the paper you mentioned before. According to my experience based on simulation, for example, in a field of 1000m*1000m, with 100 routers, the congestion can happen for the routers in the central area of the network. There are packets dropped because of the queue is full. Could you elaborate why you think the congestion avoidance doesn't work, maybe with some simulation/testbed experience? best On 4/28/12 4:46 PM, D.He@surrey.ac.uk wrote: > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus = topic. > I had read a paper entitled on "Adapting connectionless approach to mobil= e ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006= . the authors found > the packet loss increases if the nodes send more traffic over cross path = links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may = suffer from packet loss because > the packet forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion c= ould happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenar= io, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance ro= uting investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Jiazi YI Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France From philippe.jacquet@inria.fr Sun Apr 29 09:48:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6021F84B4 for ; Sun, 29 Apr 2012 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CR06WcmX7PU for ; Sun, 29 Apr 2012 09:48:04 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5876421F84B2 for ; Sun, 29 Apr 2012 09:48:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,500,1330902000"; d="scan'208";a="142016070" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail4-relais-sop.national.inria.fr with ESMTP; 29 Apr 2012 18:48:01 +0200 Date: Sun, 29 Apr 2012 18:48:02 +0200 (CEST) From: Philippe Jacquet To: D He Message-ID: <921943979.130321.1335718081972.JavaMail.root@zmbs5.inria.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [77.204.63.217] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - FF3.0 (Win)/6.0.15_GA_2995) Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 16:48:05 -0000 In an ideal world, the congestion will disrupt some links and the disruptio= n will be detected by the routing protocol by an increase of route length o= r by a decrease of route quality. So that traffic will be diverted from con= gested areas. In real life you may have hysteresis and some other burstines= s problems (the capacity of the network is limited afterall), that would re= quire long term traffic shaping such as with TCP.=20 Philippe ----- Mail original ----- De: "D He" =C0: manet@ietf.org Envoy=E9: Samedi 28 Avril 2012 16:46:44 Objet: [manet] Congestion avoidance routing in MANET Dear all, my feeling is that the issues on congestion avoidance in MANET are bogus to= pic. I had read a paper entitled on "Adapting connectionless approach to mobile = ad hoc networks in obstacle environment " on Wireless Pervasive Computing, 2006 1st International Symposium on 2006. = the authors found the packet loss increases if the nodes send more traffic over cross path li= nks. then the cross point of two paths in MANET could be the congestion area.=20 I have quite not agreed with the claim that existing MANET routing " may su= ffer from packet loss because=20 the packet forwarding policy doesn't consider traffic congestion".=20 my fellow colleagues, do you know what scenarios or when the congestion cou= ld happen in MANET?=20 I don't think the packet loss is due to congestion in high dynamic scenario= , it may be occurred due to link quality becoming bad. therefore, I feel that congestion avoidance rout= ing investigation in MANETs is a bogus topic, am I right? Best Regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dan He Research Fellow _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From D.He@surrey.ac.uk Sun Apr 29 10:09:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6C21F848C for ; Sun, 29 Apr 2012 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.723 X-Spam-Level: X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5vT6LlWQFsS for ; Sun, 29 Apr 2012 10:09:51 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8511621F848B for ; Sun, 29 Apr 2012 10:09:50 -0700 (PDT) Received: from [193.109.255.147:24451] by server-12.bemta-14.messagelabs.com id F7/0A-05898-DD57D9F4; Sun, 29 Apr 2012 17:09:49 +0000 X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-12.tower-72.messagelabs.com!1335719389!7428657!1 X-Originating-IP: [131.227.200.31] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3123 invoked from network); 29 Apr 2012 17:09:49 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-12.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 29 Apr 2012 17:09:49 -0000 Received: from EXMB01CMS.surrey.ac.uk ([10.60.0.4]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 29 Apr 2012 18:09:48 +0100 From: To: Date: Sun, 29 Apr 2012 18:08:50 +0100 Thread-Topic: [manet] Congestion avoidance routing in MANET Thread-Index: Ac0mJ9hmH9HUWQqNRQ6vv7EaWSYYnwAAubSX Message-ID: References: , <921943979.130321.1335718081972.JavaMail.root@zmbs5.inria.fr> In-Reply-To: <921943979.130321.1335718081972.JavaMail.root@zmbs5.inria.fr> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:09:52 -0000 Thanks Philippe, It does make sense. so olsrd hysteresis was designed for congestion avoidan= ce purpose or not? Dan ________________________________________ From: Philippe Jacquet [philippe.jacquet@inria.fr] Sent: 29 April 2012 17:48 To: He D Dr (CCSR) Cc: manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET In an ideal world, the congestion will disrupt some links and the disruptio= n will be detected by the routing protocol by an increase of route length o= r by a decrease of route quality. So that traffic will be diverted from con= gested areas. In real life you may have hysteresis and some other burstines= s problems (the capacity of the network is limited afterall), that would re= quire long term traffic shaping such as with TCP. Philippe ----- Mail original ----- De: "D He" =C0: manet@ietf.org Envoy=E9: Samedi 28 Avril 2012 16:46:44 Objet: [manet] Congestion avoidance routing in MANET Dear all, my feeling is that the issues on congestion avoidance in MANET are bogus to= pic. I had read a paper entitled on "Adapting connectionless approach to mobile = ad hoc networks in obstacle environment " on Wireless Pervasive Computing, 2006 1st International Symposium on 2006. = the authors found the packet loss increases if the nodes send more traffic over cross path li= nks. then the cross point of two paths in MANET could be the congestion area. I have quite not agreed with the claim that existing MANET routing " may su= ffer from packet loss because the packet forwarding policy doesn't consider traffic congestion". my fellow colleagues, do you know what scenarios or when the congestion cou= ld happen in MANET? I don't think the packet loss is due to congestion in high dynamic scenario= , it may be occurred due to link quality becoming bad. therefore, I feel that congestion avoidance rout= ing investigation in MANETs is a bogus topic, am I right? Best Regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dan He Research Fellow _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sun Apr 29 10:16:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393D021F84A0 for ; Sun, 29 Apr 2012 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbRCZHAi+Gay for ; Sun, 29 Apr 2012 10:16:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6448521F8494 for ; Sun, 29 Apr 2012 10:16:41 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2835318pbb.31 for ; Sun, 29 Apr 2012 10:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=92BVdBElFrnKSH/WV2nA4ZowcG5PZ4pWj/k+RWpgEEk=; b=JRUEzvzcelms7ygCgOuEiFNyxJF14Wi0zbLL8I4DPWfK0OnoEaWVF30iy0BMLh+bT/ NMm+pRc8PSHirSy4sK6aw+cjBaFtzr/nSurAcA4867ssuypRNN+0YjJvof+WM3lLxn3n azohZN5cnGQe4Gfd5bBuZipz1E9Wg3ghUXqP9640J8cY9rCUpwVHt4BA+/SaR7gTg4xd hznMeyk/dtdnYnW8U5q50/uXF2sDo7rfxFW5n0qvoop+yXb6bZbakBKhRQjRE5ygzMZz dfFLvT68m+qDkGBLBxVusjV6jEwt9lziul3x2pSCq2D0ndTsdpn/351CxoTkZblvZ/Ks lFgQ== Received: by 10.68.195.71 with SMTP id ic7mr40770883pbc.34.1335719801117; Sun, 29 Apr 2012 10:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Sun, 29 Apr 2012 10:16:20 -0700 (PDT) In-Reply-To: References: <921943979.130321.1335718081972.JavaMail.root@zmbs5.inria.fr> From: Henning Rogge Date: Sun, 29 Apr 2012 19:16:20 +0200 Message-ID: To: D.He@surrey.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: philippe.jacquet@inria.fr, manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:16:42 -0000 It was designed to prevent the traffic-linkmetric feedback loop from going to overdrive. You need to accumulate data to make a decision over the quality of a link, if you just take a single event (like a single lost Hello), you just get too many statistical flukes. Think about a mesh network where you have two equal paths to your target. Your network use a very accurate "link congestion/free airtime" metric and propagates it quickly through the network. At the start both paths are perfect, so you choose randomly the part A towards your target. In the next measurement period your routing protocol notice that path A now has some congestion and path B is still perfect... so it switch to B... but now B has congestion and A has none... so you switch back. I think you see the problem, right? Henning Rogge On Sun, Apr 29, 2012 at 19:08, wrote: > Thanks Philippe, > > It does make sense. so olsrd hysteresis was designed for congestion avoid= ance purpose or not? > > > Dan > ________________________________________ > From: Philippe Jacquet [philippe.jacquet@inria.fr] > Sent: 29 April 2012 17:48 > To: He D =A0Dr (CCSR) > Cc: manet@ietf.org > Subject: Re: [manet] Congestion avoidance routing in MANET > > In an ideal world, the congestion will disrupt some links and the disrupt= ion will be detected by the routing protocol by an increase of route length= or by a decrease of route quality. So that traffic will be diverted from c= ongested areas. In real life you may have hysteresis and some other burstin= ess problems (the capacity of the network is limited afterall), that would = require long term traffic shaping such as with TCP. > > Philippe > > ----- Mail original ----- > De: "D He" > =C0: manet@ietf.org > Envoy=E9: Samedi 28 Avril 2012 16:46:44 > Objet: [manet] Congestion avoidance routing in MANET > > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus = topic. > I had read a paper entitled on "Adapting connectionless approach to mobil= e ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006= . =A0the authors found > the packet loss increases if the nodes send more traffic over cross path = links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may = suffer from packet loss because > the packet =A0forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion c= ould happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenar= io, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance ro= uting investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From hrogge@googlemail.com Sun Apr 29 10:35:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB121F859A for ; Sun, 29 Apr 2012 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rscv+ABz3cph for ; Sun, 29 Apr 2012 10:35:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1521F852E for ; Sun, 29 Apr 2012 10:35:18 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2844146pbb.31 for ; Sun, 29 Apr 2012 10:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Q5Q6vttpL1yZ5HYqHhPbabRmkyRfH75VuNZKaTTuUI=; b=pDc1Pl0dstcarVDoUt2bTTcao5BMIC6tARm9oqzff1RwsbuV4xFN49eA/aGoi9qUDf 3vo5TDQFioGlhixaFBu9J1g943MqIu9TASGt/UTKgaaB62eyOjplhyREyar+zTEf3xRH R8GVGdDuOjn1auKsIp7iMdDovgTypbDqRmR4xtEoI+hK+lGCjLTt5EJShVBqcQ6tAa5f zRo2AkjiM+yyo/2JMoJAfmNWzgBZkSDVPGz4qN15OlQ47pC1OsyhgmjHqGDSrQHLwBM7 yRALyxQy3yfrqukeDH/fTckflENEio425WbfBmzGVxUCXheVj/NKgP5xNB21+IsWg07h /l+g== Received: by 10.68.132.201 with SMTP id ow9mr2105239pbb.160.1335720918559; Sun, 29 Apr 2012 10:35:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Sun, 29 Apr 2012 10:34:58 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> From: Henning Rogge Date: Sun, 29 Apr 2012 19:34:58 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:35:19 -0000 I think most IETF protocols make the assumption that the layer1/2 is "well behaving" on its interface to layer-3. Most times it is assumed that the chance that the layer-2 will give a changed/malformed packet up to layer-3 is reasonable low. On Sun, Apr 29, 2012 at 15:19, Abdussalam Baryun wrote: > AB> Therefore, AODV cannot work correctly in the network the condition > of asymmetric that persist beyond a certain time. Don't know the details of AODV, so I skip this. > RFC6130>p5>This protocol makes no assumptions about the underlying > link layer, other than support of local broadcast or multicast for > communication to 1-hop neighbor routers. > > AB> NHDP assumes support of local broadcast or multicast for communication > to 1-hop neighbor routers. If no such support then it is not correct. Without "send to all neighbors" (multicast/broadcast) it will just not work. Its a requirement for NHDP, as it is for a lot basic networking mechanisms. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. I don't know why you put layer-1 into this... > RFC925>p5> If the environment is very dynamic making T3 shorter will result in > more rapid adaptation to the changes.,,,,,,,, Unfortunately there is > no necessary relationship between frequency of use and correctness. > > AB> it assumes that there is no LOS or NLOS link dynamics in the L1 > communication medium, but it mentions the problem of no-reply, and T3 > or timeouts-feedback. The correctness of ARP is not gauranteed in such > dynamic environment. Never heard about this RFC. > OLSRv2-work-in-progress>p7> >>OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, through >its use of [RFC6130], may use link layer information and >>notifications when available and applicable. In addition, OLSRv2 >>uses link metrics that may be derived from link layer or any other >>information. OLSRv2 does not specify the physical meaning of link >>metrics, but specifies a means by which new types of link metrics may >>be specified in the future, but used by OLSRv2 without modification. > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. This claim is only true if the Data-Link is > using RFC5444, and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. You have a misconception here. OLSRv2 use RFC5444. The underlaying layer (as any network layer) just have to transport this data to the OLSRv2 instance on the other side, it does not need to care about whats inside the packets. Thats the basic OSI approach. > RFC5444>page 4>This document specifies the syntax of a packet format > designed >for carrying multiple routing protocol messages for > information exchange >>between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >>Message Header, which is designed for control of message >>dissemination, and a Message Body, which contains protocol >>information. > > AB>Comments> Therefore, RFC5444 is specified to messages-format for exchange > between Routers. Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, otherwise we need to update all old standards that we have > like DSR, AODV, etc. Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. RFC5444 specifies a packet format, not the behavior or daemons using it. > DLEP-work-in-progress>p1>When routing devices rely on modems to effect > communications over wireless links. > > AB> DLEP assuming indirectly> that there is a direct channel between > router and modem, or that modem is able to sense the change or faults > in the wireless-medium used for data communication. It assumes that radio and router can talk to each other. DLEP is for transporting the known facts about the link layer from the radio to the router. Things that are unknown don't need to be transmitted. I really don't see a point in your posting. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Mon Apr 30 00:58:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B921F85D9 for ; Mon, 30 Apr 2012 00:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.657 X-Spam-Level: X-Spam-Status: No, score=-3.657 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21xhiSp1L2kh for ; Mon, 30 Apr 2012 00:58:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBDA21F85C3 for ; Mon, 30 Apr 2012 00:58:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2197022vbb.31 for ; Mon, 30 Apr 2012 00:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pqVqZafLGR/P6oNVw+G1JnB5UqzY3Ae1S/BYhQlurtw=; b=jzsMreVufk6hmFpjbJE9npHETK1RF0ujpgJDlr0AVur3IIgIuhzwyCYqo61CwQiJTZ pxFopcIRUe9LruPVXBfX420aPvQhPcxReobO7XuTJh5foXW1brp8zwU0GpdAg2G5Bn1t mN+qOO2y9iyqgbFbhCa0KaGqc9eLr7FiIuHxH/qGgppM9oDtpx6urm67m74eQHQhw1OK KSMT5eFYeGPNW8W0ZVh2txvejUBr1vMY3A9G3jTDU/z/4hfALqGkYKBf9+Tbtpgp/Rxj f6/7ClI4bc2/JRJKg71b0KZ4hsjyxCcbsixFsDcKL566PxgVjbwXkZyqBOyFQiKgyWAD vvGg== MIME-Version: 1.0 Received: by 10.220.238.211 with SMTP id kt19mr2914479vcb.46.1335772722579; Mon, 30 Apr 2012 00:58:42 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 00:58:42 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 08:58:42 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=14dae9cfcba8a1477e04bee0d27e Cc: manet , Bo Berry , sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 07:58:44 -0000 --14dae9cfcba8a1477e04bee0d27e Content-Type: text/plain; charset=ISO-8859-1 Hi Hinning, thanks for your comments, >You have a misconception here. OLSRv2 use RFC5444. The underlaying >layer (as any network layer) just have to transport this data to the >OLSRv2 instance on the other side, it does not need to care about >whats inside the packets. Thats the basic OSI approach. I mentioned underlying-link-layer not underlying-newtork-layer. I don't think both draft mention who should care what is in the packet, but thinking to use OSI approach to improve progress of the work. I think the draft's concept of no assumption on underlaying while it does use (or depend sometimes on) availability of the interface-information, is having a misconcept. However, I am writting down my full comments on the document which I will post shortly. >I really don't see a point in your posting. The point is to discuss MANET protocols reasonably, Abdussalam Baryun University of Glamorgan, UK On Sun, Apr 29, 2012 at 6:34 PM, Henning Rogge wrote: > I think most IETF protocols make the assumption that the layer1/2 is > "well behaving" on its interface to layer-3. Most times it is assumed > that the chance that the layer-2 will give a changed/malformed packet > up to layer-3 is reasonable low. > > On Sun, Apr 29, 2012 at 15:19, Abdussalam Baryun > wrote: > > AB> Therefore, AODV cannot work correctly in the network the condition > > of asymmetric that persist beyond a certain time. > Don't know the details of AODV, so I skip this. > > > RFC6130>p5>This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication to 1-hop neighbor routers. > > > > AB> NHDP assumes support of local broadcast or multicast for > communication > > to 1-hop neighbor routers. If no such support then it is not correct. > Without "send to all neighbors" (multicast/broadcast) it will just not > work. Its a requirement for NHDP, as it is for a lot basic networking > mechanisms. > > > Also indirectly this protocol has not an awareness of any fault in the > > L1 wireless communication. > I don't know why you put layer-1 into this... > > > RFC925>p5> If the environment is very dynamic making T3 shorter will > result in > > more rapid adaptation to the changes.,,,,,,,, Unfortunately there is > > no necessary relationship between frequency of use and correctness. > > > > AB> it assumes that there is no LOS or NLOS link dynamics in the L1 > > communication medium, but it mentions the problem of no-reply, and T3 > > or timeouts-feedback. The correctness of ARP is not gauranteed in such > > dynamic environment. > Never heard about this RFC. > > > OLSRv2-work-in-progress>p7> > >>OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, > through >its use of [RFC6130], may use link layer information and > >>notifications when available and applicable. In addition, OLSRv2 > >>uses link metrics that may be derived from link layer or any other > >>information. OLSRv2 does not specify the physical meaning of link > >>metrics, but specifies a means by which new types of link metrics may > >>be specified in the future, but used by OLSRv2 without modification. > > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer, moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying. This claim is only true if the Data-Link is > > using RFC5444, and under RFC5444 claims that the messages are routers' > > messaging not claiming that messaging are Data-Link > > messages/information/interaction. therefore OLSRv2 assumes that > > Data-Link layer MUST RFC5444, so that it can use the information in > > Data-Link. > > You have a misconception here. OLSRv2 use RFC5444. The underlaying > layer (as any network layer) just have to transport this data to the > OLSRv2 instance on the other side, it does not need to care about > whats inside the packets. Thats the basic OSI approach. > > > RFC5444>page 4>This document specifies the syntax of a packet format > > designed >for carrying multiple routing protocol messages for > > information exchange > >>between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >>Message Header, which is designed for control of message > >>dissemination, and a Message Body, which contains protocol > >>information. > > > > AB>Comments> Therefore, RFC5444 is specified to messages-format for > exchange > > between Routers. Secondly it mentions no MUST/SHOULD for the > > IETF-MANET routing standards that it uses this particular message > > format, otherwise we need to update all old standards that we have > > like DSR, AODV, etc. Also it does not mention Data-Link > > interaction/exchange (i.e. L2 information availability, or L2 frames' > > formating) at all. > RFC5444 specifies a packet format, not the behavior or daemons using it. > > > DLEP-work-in-progress>p1>When routing devices rely on modems to effect > > communications over wireless links. > > > > AB> DLEP assuming indirectly> that there is a direct channel between > > router and modem, or that modem is able to sense the change or faults > > in the wireless-medium used for data communication. > > It assumes that radio and router can talk to each other. DLEP is for > transporting the known facts about the link layer from the radio to > the router. Things that are unknown don't need to be transmitted. > > I really don't see a point in your posting. > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --14dae9cfcba8a1477e04bee0d27e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hinning,
=A0
thanks for your comments,
=A0
>You have a misconception here. OLSRv2 use RFC5444. The underlaying=
>layer (as any network layer) just have to transport this data to th= e
>OLSRv2 instance on the other side, it does not need to care about<= br> >whats inside the packets. Thats the basic OSI approach.
I mentioned underlying-link-layer not underlying-newtork-layer. I don&= #39;t think both draft mention who should care what is in the packet, but t= hinking to use OSI approach to improve progress of the work. I think the dr= aft's concept of no assumption on underlaying=A0while it does=A0use (or= depend sometimes on)=A0availability of the interface-information, is havin= g a misconcept. However, I am writting down my full comments on the documen= t which I will post shortly.
=A0
>I really don't see a point in your posting.
The point is to discuss MANET protocols rea= sonably,
=A0
Abdussalam Baryun
University of Glamorgan, UK

On Sun, Apr 29, 2012 at 6:34 PM, Henning Rogge <= span dir=3D"ltr"><hrogge@googlemail.com> wrote:
I think most IETF protocols make the = assumption that the layer1/2 is
"well behaving" on its interfa= ce to layer-3. Most times it is assumed
that the chance that the layer-2 will give a changed/malformed packet
up= to layer-3 is reasonable low.

On Sun, Apr 29, 2012 at 15:19, Abdussalam Baryun
&= lt;abdussalambaryun@gmail.com= > wrote:
> AB> Therefore, AODV cannot work correctly in the= network the condition
> of asymmetric that persist beyond a certain time.
Don't k= now the details of AODV, so I skip this.

> RFC6130>p5>This protocol makes no assumpti= ons about the underlying
> link layer, other than support of local br= oadcast or multicast for
> communication to 1-hop neighbor routers. >
> AB> NHDP assumes support of local broadcast or multicast fo= r communication
> to 1-hop neighbor routers. If no such support then = it is not correct.
Without "send to all neighbors" (mult= icast/broadcast) it will just not
work. Its a requirement for NHDP, as it is for a lot basic networking
me= chanisms.

> Also indirectly this protocol has not an awarene= ss of any fault in the
> L1 wireless communication.
I don= 9;t know why you put layer-1 into this...

> RFC925>p5> If the environment is very dyna= mic making T3 shorter will result in
> more rapid adaptation to the c= hanges.,,,,,,,, Unfortunately there is
> no necessary relationship be= tween frequency of use and correctness.
>
> AB> it assumes that there is no LOS or NLOS link dynamics i= n the L1
> communication medium, but it mentions the problem of no-re= ply, and T3
> or timeouts-feedback. The correctness of ARP is not gau= ranteed in such
> dynamic environment.
Never heard about this RFC.

> OLSRv2-work-in-progress>p7>
>>OLS= Rv2 makes no assumptions about the underlying link layer. OLSRv2, through &= gt;its use of [RFC6130], may use link layer information and
>>noti= fications when available and applicable. In addition, OLSRv2
>>uses link metrics that may be derived from link layer or any other<= br>>>information. OLSRv2 does not specify the physical meaning of lin= k
>>metrics, but specifies a means by which new types of link metr= ics may
>>be specified in the future, but used by OLSRv2 without modification= .
>
> AB> OLSRv2 claims and assumes indirectly> that OLSR= v2-standard doesn't
> have to be depending on Data-Link-layer inf= ormation and in the same
> time it may use information from Data-Link-Layer, moreover, claiming> it will not need to be modified if there is change in metric or
&= gt; information of underlying. This claim is only true if the Data-Link is<= br> > using RFC5444, and under RFC5444 claims that the messages are routers&= #39;
> messaging not claiming that messaging are Data-Link
> me= ssages/information/interaction. therefore OLSRv2 assumes that
> Data-= Link layer MUST RFC5444, so that it can use the information in
> Data-Link.

You have a misconception here. OLSRv2 use RFC5= 444. The underlaying
layer (as any network layer) just have to transport= this data to the
OLSRv2 instance on the other side, it does not need to= care about
whats inside the packets. Thats the basic OSI approach.

> RFC5444>page 4>This document specifies the= syntax of a packet format
> designed >for carrying multiple routi= ng protocol messages for
> information exchange
>>between MA= NET (Mobile Ad hoc NETwork) routers. Messages consist of a
>>Message Header, which is designed for control of message
>>= ;dissemination, and a Message Body, which contains protocol
>>info= rmation.
>
> AB>Comments> Therefore, RFC5444 is specified= to messages-format for exchange
> between Routers. Secondly it mentions no MUST/SHOULD for the
> I= ETF-MANET routing standards that it uses this particular message
> fo= rmat, otherwise we need to update all old standards that we have
> li= ke DSR, AODV, etc. Also it does not mention Data-Link
> interaction/exchange (i.e. L2 information availability, or L2 frames&#= 39;
> formating) at all.
RFC5444 specifies a packet format, = not the behavior or daemons using it.

> DLEP-work-in-progress>p1>When routing devi= ces rely on modems to effect
> communications over wireless links.>
> AB> DLEP assuming indirectly> that there is a direct ch= annel between
> router and modem, or that modem is able to sense the change or faults<= br>> in the wireless-medium used for data communication.

It= assumes that radio and router can talk to each other. DLEP is for
trans= porting the known facts about the link layer from the radio to
the router. Things that are unknown don't need to be transmitted.
I really don't see a point in your posting.

Henning Rogge
--
Steven Hawkings about cosmic inflation: "An in= crease of billions of
billions of percent in a tiny fraction of a second= . Of course, that
was before the present government."

--14dae9cfcba8a1477e04bee0d27e-- From Chris.Dearlove@baesystems.com Mon Apr 30 02:06:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2121F85CF for ; Mon, 30 Apr 2012 02:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ols1A8+VqGg6 for ; Mon, 30 Apr 2012 02:06:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id DA14121F85C3 for ; Mon, 30 Apr 2012 02:06:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,503,1330905600"; d="scan'208";a="234971592" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 10:06:53 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3U96qKc006683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 10:06:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 10:06:51 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Henning Rogge Thread-Topic: [manet] DLEP mechanism used by MANET Routing Thread-Index: AQHNJGiF7hS2wiOVt0ua0yGx2ia9C5aueLyAgACdloCAAA3EgIAABkgAgAAA4wCAApChAIABVwOg Date: Mon, 30 Apr 2012 09:06:50 +0000 Message-ID: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 09:06:55 -0000 Abdussalam Baryun > RFC6130>p5 > >This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication > > to 1-hop neighbor routers. > AB> NHDP assumes support of local broadcast or multicast for communicatio= n > to 1-hop neighbor routers. If no such support then it is not correct. The piece you quoted explicitly points this out (the bit starting "other"). So your comment is incorrect. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. Which is exactly as it says. I don't know what your point is. Abdussalam Baryun > OLSRv2-work-in-progress>p7 > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, thr= ough > >its use of [RFC6130], may use link layer information and > >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other > >information. OLSRv2 does not specify the physical meaning of link > >metrics, but specifies a means by which new types of link metrics may > >be specified in the future, but used by OLSRv2 without modification. > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, There's no contradiction there. It doesn't have to be dependent on data link layer information, but it may (optional, don't have to do it) use it. > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). > This claim is only true if the Data-Link is > using RFC5444, First 5444 is not used by the data link, it's used by the routing protocol, which is at L3. And use of 5444 is mandatory when using OLSRv2 as defined by the specification. I also don't see the connection to link metri= cs. OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics. > and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. This has completely missed the point, being based on the incorrect assumpti= on that 5444 is used at data link layer. Abdussalam Baryun > RFC5444>page 4 > >This document specifies the syntax of a packet format designed > >for carrying multiple routing protocol messages for information exchang= e >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >Message Header, which is designed for control of message > >dissemination, and a Message Body, which contains protocol > >information. > AB>Comments> Therefore, RFC5444 is specified to messages-format for excha= nge > between Routers. That's what it was designed for. If someone wants to use it for something e= lse, fine. > Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, That is done by RFC 5498. > otherwise we need to update all old standards that we have > like DSR, AODV, etc. Obviously 5444 doesn't demand changes to existing experimental protocols. 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). But those earlier protocols each have their own UDP port, and 5498 does not apply. > Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual. I'm afraid I can't see any point made. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Apr 30 02:11:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F04D21F8495 for ; Mon, 30 Apr 2012 02:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmLhYzDKjPzO for ; Mon, 30 Apr 2012 02:11:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id CEC4621F847E for ; Mon, 30 Apr 2012 02:11:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,503,1330905600"; d="scan'208";a="234973671" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 10:11:20 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3U9BJ8I010318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 10:11:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 10:11:19 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "D.He@surrey.ac.uk" Thread-Topic: [manet] Congestion avoidance routing in MANET Thread-Index: AQHNJUp5Q950ys00wkWmlF1CHL1O5pax9FUAgAAF0ACAAAIZAIABGqhA Date: Mon, 30 Apr 2012 09:11:17 +0000 Message-ID: References: <921943979.130321.1335718081972.JavaMail.root@zmbs5.inria.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "philippe.jacquet@inria.fr" , "manet@ietf.org" Subject: Re: [manet] Congestion avoidance routing in MANET X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 09:11:22 -0000 Note that link quality hysteresis is in OLSR (RFC 3626) not invented by ols= rd (though the details may differ, I don't know). OLSRv2 uses the term hyst= eresis more carefully (OLSRv1 didn't quite so carefully distinguish link qu= ality from hysteresis in its wording ) and is less prescriptive in how to d= o it. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 29 April 2012 18:16 To: D.He@surrey.ac.uk Cc: philippe.jacquet@inria.fr; manet@ietf.org Subject: Re: [manet] Congestion avoidance routing in MANET ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- It was designed to prevent the traffic-linkmetric feedback loop from going to overdrive. You need to accumulate data to make a decision over the quality of a link, if you just take a single event (like a single lost Hello), you just get too many statistical flukes. Think about a mesh network where you have two equal paths to your target. Your network use a very accurate "link congestion/free airtime" metric and propagates it quickly through the network. At the start both paths are perfect, so you choose randomly the part A towards your target. In the next measurement period your routing protocol notice that path A now has some congestion and path B is still perfect... so it switch to B... but now B has congestion and A has none... so you switch back. I think you see the problem, right? Henning Rogge On Sun, Apr 29, 2012 at 19:08, wrote: > Thanks Philippe, > > It does make sense. so olsrd hysteresis was designed for congestion avoid= ance purpose or not? > > > Dan > ________________________________________ > From: Philippe Jacquet [philippe.jacquet@inria.fr] > Sent: 29 April 2012 17:48 > To: He D =A0Dr (CCSR) > Cc: manet@ietf.org > Subject: Re: [manet] Congestion avoidance routing in MANET > > In an ideal world, the congestion will disrupt some links and the disrupt= ion will be detected by the routing protocol by an increase of route length= or by a decrease of route quality. So that traffic will be diverted from c= ongested areas. In real life you may have hysteresis and some other burstin= ess problems (the capacity of the network is limited afterall), that would = require long term traffic shaping such as with TCP. > > Philippe > > ----- Mail original ----- > De: "D He" > =C0: manet@ietf.org > Envoy=E9: Samedi 28 Avril 2012 16:46:44 > Objet: [manet] Congestion avoidance routing in MANET > > Dear all, > > my feeling is that the issues on congestion avoidance in MANET are bogus = topic. > I had read a paper entitled on "Adapting connectionless approach to mobil= e ad hoc networks in obstacle environment " > on Wireless Pervasive Computing, 2006 1st International Symposium on 2006= . =A0the authors found > the packet loss increases if the nodes send more traffic over cross path = links. then the cross point > of two paths in MANET could be the congestion area. > > I have quite not agreed with the claim that existing MANET routing " may = suffer from packet loss because > the packet =A0forwarding policy doesn't consider traffic congestion". > > my fellow colleagues, do you know what scenarios or when the congestion c= ould happen in MANET? > I don't think the packet loss is due to congestion in high dynamic scenar= io, it may be occurred due to > link quality becoming bad. therefore, I feel that congestion avoidance ro= uting investigation in MANETs > is a bogus topic, am I right? > > > Best Regards, > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dan He > Research Fellow > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From abdussalambaryun@gmail.com Mon Apr 30 05:27:27 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A73B21F858E for ; Mon, 30 Apr 2012 05:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WlPNlBmNGyP for ; Mon, 30 Apr 2012 05:27:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1925621F854B for ; Mon, 30 Apr 2012 05:27:26 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2339945vbb.31 for ; Mon, 30 Apr 2012 05:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x22I0NH11VHAD46UAWXAlvYw6wdEtltzTRIxatMRVeo=; b=buVJ38fkmhBsk/IFqZLXWygi1nD/+hckmILxk7OnwCgzw8qRMv7s4mWgqGdEdjGWJv G/fB/e6mUllYDtk3UT9MyZKMNsoaoaYUTeckClLJQPn0v7TB6fmUtpw5Sy3uMrFKpUGg h5WNOzwAJqZBuaRMaoGjlREZEKYRuPvO/EjJwIfAuO0CUl6MCVH2YTYRfbIqg9JtDJnY 51XgcJtynpunu2HRkLQMtK0WlUCk1+920il5OKE2x8QoDtR2BM5ZoOYWSZq6cOP6suXC chbTjkOBZ48UaGUm1wNjs1wLTE5h40PmiveEANKlar3i2HoEg8CMfp67BYYWvD/rIza/ mnZA== MIME-Version: 1.0 Received: by 10.52.36.81 with SMTP id o17mr17698712vdj.97.1335788845508; Mon, 30 Apr 2012 05:27:25 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 05:27:25 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 13:27:25 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf307c9e4aa1aa6304bee493c7 Cc: manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 12:27:27 -0000 --20cf307c9e4aa1aa6304bee493c7 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, I am sorry to be pointless, however, I am discussing with reference, andplease just inform me where I understood wrong so we can progress. I don't think volunteering to read other peoples work and trying to make the best in my knowledge is pointless. I know I am less knowledge, but I will not stop reading and commenting, only if the chair of the WG informs me, so please respect my work with no insults, otherwise the chair should inform one of us who is pointless in our discussion under his responsibility. Please read my reply-comment to OLSRv2 below: > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, >There's no contradiction there. It doesn't have to be dependent on data >link layer information, but it may (optional, don't have to do it) use it. Why does the OLSRv2 draft mention that routers must have at least one OLSRv2-interface. The interface isData-Link layer because all MANET-interfaces are Data-link layers, but still it stated no assumption for the underlying data-link layer. I suggest to delete the word 'no assumption' because OLSRv2-draft assumes that all routers must have at least on OLSRv2-interface otherwise it doesn't work. I need an explanation please. thanking you for your comments, Abdussalam Baryun > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > Abdussalam Baryun > > RFC6130>p5 > > >This protocol makes no assumptions about the underlying > > > link layer, other than support of local broadcast or multicast for > > > communication > > > to 1-hop neighbor routers. > > > AB> NHDP assumes support of local broadcast or multicast for > communication > > to 1-hop neighbor routers. If no such support then it is not correct. > > The piece you quoted explicitly points this out (the bit starting "other"). > So your comment is incorrect. > > > Also indirectly this protocol has not an awareness of any fault in the > > L1 wireless communication. > > Which is exactly as it says. I don't know what your point is. > > Abdussalam Baryun > > OLSRv2-work-in-progress>p7 > > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, > through > > >its use of [RFC6130], may use link layer information and > > >notifications when available and applicable. In addition, OLSRv2 > > >uses link metrics that may be derived from link layer or any other > > >information. OLSRv2 does not specify the physical meaning of link > > >metrics, but specifies a means by which new types of link metrics may > > >be specified in the future, but used by OLSRv2 without modification. > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer, > > There's no contradiction there. It doesn't have to be dependent on data > link layer information, but it may (optional, don't have to do it) use it. > > > moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying. > > Which is true, not just a claim. Note that how the metric is calculated is > outside OLSRv2 (read the draft). > > > This claim is only true if the Data-Link is > > using RFC5444, > > First 5444 is not used by the data link, it's used by the routing protocol, > which is at L3. And use of 5444 is mandatory when using OLSRv2 as > defined by the specification. I also don't see the connection to link > metrics. > OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. > If, hypothetically, someone created an alternative data format for OLSRv2 > not based on 5444, it would need to carry metrics. > > > and under RFC5444 claims that the messages are routers' > > messaging not claiming that messaging are Data-Link > > messages/information/interaction. therefore OLSRv2 assumes that > > Data-Link layer MUST RFC5444, so that it can use the information in > > Data-Link. > > This has completely missed the point, being based on the incorrect > assumption > that 5444 is used at data link layer. > > Abdussalam Baryun > > RFC5444>page 4 > > >This document specifies the syntax of a packet format designed > > >for carrying multiple routing protocol messages for information > exchange > >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > > >Message Header, which is designed for control of message > > >dissemination, and a Message Body, which contains protocol > > >information. > > > AB>Comments> Therefore, RFC5444 is specified to messages-format for > exchange > > between Routers. > > That's what it was designed for. If someone wants to use it for something > else, fine. > > > Secondly it mentions no MUST/SHOULD for the > > IETF-MANET routing standards that it uses this particular message > > format, > > That is done by RFC 5498. > > > otherwise we need to update all old standards that we have > > like DSR, AODV, etc. > > Obviously 5444 doesn't demand changes to existing experimental protocols. > 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). > But those earlier protocols each have their own UDP port, and 5498 does > not apply. > > > Also it does not mention Data-Link > > interaction/exchange (i.e. L2 information availability, or L2 frames' > > formating) at all. > > Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, > and then presented to the data link layer. 5444 relies on IP to interface > to the data link layer, as usual. > > I'm afraid I can't see any point made. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > 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. > ******************************************************************** > > --20cf307c9e4aa1aa6304bee493c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
I am sorry to be pointless, however, I am discussing with reference, a= ndplease just inform me where I understood wrong so we can progress. I don&= #39;t think volunteering to read other peoples work and trying to make the = best in my knowledge is pointless. I know I am less knowledge, but I will n= ot stop reading and commenting, only if the chair of the WG informs me, so = please respect my work with no insults, otherwise the chair should inform o= ne of us who is pointless in our discussion under his responsibility.
=A0
Please read my reply-comment to OLSRv2 below:
=A0
> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-stand= ard doesn't
> have to be depending on Data-Link-layer information= and in the same
> time it may use information from Data-Link-Layer,<= br>
>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.
=A0
Why does the OLSRv2 draft mention that routers must have = at least one OLSRv2-interface. The interface isData-Link layer because all = MANET-interfaces are Data-link layers, but still it stated no assumption fo= r the underlying data-link layer. I suggest to delete the word 'no assu= mption' because OLSRv2-draft assumes that all routers must have at leas= t on OLSRv2-interface otherwise it doesn't work.
=A0
I need an explanation please. thanking you for your comme= nts,
=A0
Abdussalam Baryun
=A0

> moreover, claiming
> it will not need to b= e modified if there is change in metric or
> information of underlyin= g.

Which is true, not just a claim. Note that how the metric i= s calculated is
outside OLSRv2 (read the draft).

=A0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Chri= stopher (UK) <Chris.Dearlove@baesystems.com> wro= te:
Abdussalam Baryun
> RFC6130>p5
> >This protocol makes no ass= umptions about the underlying
> > link layer, other than support o= f local broadcast or multicast for
> > communication
> > = to 1-hop neighbor routers.

> AB> NHDP assumes support of local broadcast or multicast for co= mmunication
> to 1-hop neighbor routers. If no such support then it i= s not correct.

The piece you quoted explicitly points this out= (the bit starting "other").
So your comment is incorrect.

> Also indirectly this protocol has not an awarene= ss of any fault in the
> L1 wireless communication.

Whic= h is exactly as it says. I don't know what your point is.

Abduss= alam Baryun
> OLSRv2-work-in-progress>p7
> >OLSRv2 mak= es no assumptions about the underlying link layer. OLSRv2, through
> = >its use of [RFC6130], may use link layer information and
> >no= tifications when available and applicable. In addition, OLSRv2
> >uses link metrics that may be derived from link layer or any other=
> >information. OLSRv2 does not specify the physical meaning of l= ink
> >metrics, but specifies a means by which new types of link m= etrics may
> >be specified in the future, but used by OLSRv2 without modificatio= n.

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-= standard doesn't
> have to be depending on Data-Link-layer inform= ation and in the same
> time it may use information from Data-Link-Layer,

There&#= 39;s no contradiction there. It doesn't have to be dependent on datalink layer information, but it may (optional, don't have to do it) use= it.

> moreover, claiming
> it will not need to b= e modified if there is change in metric or
> information of underlyin= g.

Which is true, not just a claim. Note that how the metric i= s calculated is
outside OLSRv2 (read the draft).

> This claim is only true if the Data-Link is
&= gt; using RFC5444,

First 5444 is not used by the data link, it= 's used by the routing protocol,
which is at L3. And use of 5444 is = mandatory when using OLSRv2 as
defined by the specification. I also don't see the connection to link m= etrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide t= hem.
If, hypothetically, someone created an alternative data format for = OLSRv2
not based on 5444, it would need to carry metrics.

> and under RFC5444 claims that the messages are r= outers'
> messaging not claiming that messaging are Data-Link
= > messages/information/interaction. therefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being b= ased on the incorrect assumption
that 5444 is used at data link layer.
Abdussalam Baryun
> RFC5444>page 4
> >This document specifie= s the syntax of a packet format designed
> >for carrying multiple = routing protocol messages for =A0information exchange
>> between M= ANET (Mobile Ad hoc NETwork) routers. Messages consist of a
> >Message Header, which is designed for control of message
> &= gt;dissemination, and a Message Body, which contains protocol
> >i= nformation.

> AB>Comments> Therefore, RFC5444 is specified = to messages-format for exchange
> between Routers.

That's what it was designed for. If = someone wants to use it for something else, fine.

> Secondly it mentions no MUST/SHOULD for the
&= gt; IETF-MANET routing standards that it uses this particular message
&g= t; format,

That is done by RFC 5498.

> otherwise we need to update all old standards th= at we have
> like DSR, AODV, etc.

Obviously 5444 doesn&#= 39;t demand changes to existing experimental protocols.
5498 mandates th= e use of 5444 on the manet UDP port (and IP protocol).
But those earlier protocols each have their own UDP port, and 5498 does
= not apply.

> Also it does not mention Data-Link
> inter= action/exchange (i.e. L2 information availability, or L2 frames'
>= ; formating) at all.

Of course not. 5444 specifies a format, w= hich is encapsulated in UDP/IP,
and then presented to the data link layer. 5444 relies on IP to interfaceto the data link layer, as usual.

I'm afraid I can't see a= ny point made.

--
Christopher Dearlove
Senior Principal Engine= er, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advan= ced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, = CM2 8HN, UK
Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://w= ww.baesystems.com

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


******************= **************************************************
This email and any at= tachments are confidential to the intended
recipient and may also be pri= vileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You s= hould not copy it or use it for any purpose nor disclose or
distribute i= ts contents to any other person.
***************************************= *****************************


--20cf307c9e4aa1aa6304bee493c7-- From hrogge@googlemail.com Mon Apr 30 06:15:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE74821F8642 for ; Mon, 30 Apr 2012 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er2+oGwaeQm8 for ; Mon, 30 Apr 2012 06:15:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47ABE21F863F for ; Mon, 30 Apr 2012 06:15:20 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so515022pbc.31 for ; Mon, 30 Apr 2012 06:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rfnKBewyUxYt89Anmub1lGDzkYUBrZ1CPIkzrNUOHlA=; b=Ek1545EODP0NGGj35ZZ6cBW3ZaWkaBpYr6uOaOCuLf7y6xA3QXRi35i9zxP2Trb7LE djHTtmO0pX7qJ72JBrGikxAch17wl+6kyBe9cJ6V6dzPIszAaK9JzAAEignGXtfHN/kT OU5yQA7Hsn7WzVmZW/l84gmIEmCpJdCdrvzKlFiVG+D42v9uE5vLfQfByNRTUkDU4ern f059d82se7Nk3kbFG7YOmGOj661yQ56M00UH9jw1fspNuTBYVZvnu1GpSUcgLXIDYMYg OO7mRe/yXNbQVDHSXE1wSGhHQbbuBwB2m93CSks7ckMxfJ83YE+9sJ3zpE41Ht5FabJ3 z81A== Received: by 10.68.135.40 with SMTP id pp8mr13435888pbb.13.1335791719990; Mon, 30 Apr 2012 06:15:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.235.106 with HTTP; Mon, 30 Apr 2012 06:14:59 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> From: Henning Rogge Date: Mon, 30 Apr 2012 15:14:59 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 13:15:20 -0000 On Mon, Apr 30, 2012 at 14:27, Abdussalam Baryun wrote: > Hi Chris, > > I am sorry to be pointless, however, I am discussing with reference, > andplease just inform me where I understood wrong so we can progress. I > don't think volunteering to read other peoples work and trying to make the > best in my knowledge is pointless. I know I am less knowledge, but I will > not stop reading and commenting, only if the chair of the WG informs me, so > please respect my work with no insults, otherwise the chair should inform > one of us who is pointless in our discussion under his responsibility. > > Please read my reply-comment to OLSRv2 below: > >> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't >> have to be depending on Data-Link-layer information and in the same >> time it may use information from Data-Link-Layer, > >>There's no contradiction there. It doesn't have to be dependent on data >>link layer information, but it may (optional, don't have to do it) use it. > > Why does the OLSRv2 draft mention that routers must have at least one > OLSRv2-interface. The interface isData-Link layer because all > MANET-interfaces are Data-link layers, but still it stated no assumption for > the underlying data-link layer. I suggest to delete the word 'no assumption' > because OLSRv2-draft assumes that all routers must have at least on > OLSRv2-interface otherwise it doesn't work. I would suggest reading the OLSRv2-draft again, especially section 2. OLSRv2 interface: A MANET interface running this protocol. A router running this protocol MUST have at least one OLSRv2 interface. A routing protocol which does not run on any interface would be pretty useless, right? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From nehayashika2006@gmail.com Mon Apr 30 08:11:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754F721F864E for ; Mon, 30 Apr 2012 08:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2oelHh542Nl for ; Mon, 30 Apr 2012 08:11:32 -0700 (PDT) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 03EF421F864F for ; Mon, 30 Apr 2012 08:11:31 -0700 (PDT) Received: by ghrr20 with SMTP id r20so1619116ghr.13 for ; Mon, 30 Apr 2012 08:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=00R60x0aCmyTerrGPlEqu+PAu2jK+LgD6SkVMCFeQQA=; b=zgZJOLLmicZMpPD9qfYfaEYLQ+Yp75oCQpa/06diHjQmNOMqkUJAXeUJRBC9/4HoRk 1i8JKMCXFn7Ury0Qfkab88dKV/0ig0MP7/RA9pWsVApWzI13DiGjy4sLvNMuW4KtTQEY yAaEYNT/2R63Plj+3Jx0jJydaJVjxurRjpb3lFEy3mrsNp5OSRXXGIRt++xjeEEPxVkX 1I8tj+9JBx0c25oA5eQ/nhBRNbGgAIH0vTOTil9QJeqE7WUrWeLwoNgUUC1yz6lXqyx/ EFcg8UM4d1P0wCiKlNsHbfqDjsHILrbwyMHSCCt6okgnU4RiGsc9piiFCB3w/BNLF3qL 1mnA== MIME-Version: 1.0 Received: by 10.236.80.105 with SMTP id j69mr22600115yhe.93.1335798691419; Mon, 30 Apr 2012 08:11:31 -0700 (PDT) Received: by 10.236.173.199 with HTTP; Mon, 30 Apr 2012 08:11:31 -0700 (PDT) Date: Mon, 30 Apr 2012 20:41:31 +0530 Message-ID: From: neha_yashika2006 jain To: manet@ietfa.amsl.com Content-Type: multipart/alternative; boundary=20cf30050bfc7e556704bee6dee4 Subject: [manet] Confirm: manet@ietfa.amsl.com X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:11:32 -0000 --20cf30050bfc7e556704bee6dee4 Content-Type: text/plain; charset=ISO-8859-1 --20cf30050bfc7e556704bee6dee4 Content-Type: text/html; charset=ISO-8859-1
--20cf30050bfc7e556704bee6dee4-- From sratliff@cisco.com Mon Apr 30 08:22:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F339B21F8551 for ; Mon, 30 Apr 2012 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.595 X-Spam-Level: X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysy6Vj5q+xZM for ; Mon, 30 Apr 2012 08:22:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9621F8636 for ; Mon, 30 Apr 2012 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=994; q=dns/txt; s=iport; t=1335799378; x=1337008978; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YQXnyvX9Pt4set1FPK1Hv5DJEMyf35e8GLTFRBJGBwE=; b=amvW2OFbS+ovIepiA43vQ8fqlKn8/rvqST/KQaZcMGIGEhVwOC88aQmc UFww8bZMZj7208q54osEF+UQC6Z++kMeS5gxAI4VWpdYpf07xhYqjltJZ jpiXaF3I7VEgdbewExp8esle+fv8FvjeWmvcns66JVzSIbvraTawLT9fz M=; X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208";a="79089224" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 30 Apr 2012 15:22:55 +0000 Received: from dhcp-64-102-54-100.cisco.com (dhcp-64-102-54-100.cisco.com [64.102.54.100]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3UFMsNh021451; Mon, 30 Apr 2012 15:22:54 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Mon, 30 Apr 2012 11:22:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Rogge X-Mailer: Apple Mail (2.1257) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Bo Berry Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:23:00 -0000 Henning,=20 Yes, I believe that's correct. The Sourceforge implementation was based = on DLEP-00 or DLEP-01, can't remember which. It should be in the README. Regards, Stan On Apr 28, 2012, at 6:59 AM, Henning Rogge wrote: > On Fri, Apr 27, 2012 at 16:17, dsatterw wrote: >> At this point we have at least 4 working >> implementations of DLEP out there which were all based on our = sourceforge >> example of a packet parser that seems sufficient for the ones = involved. >=20 > One more questions about the sourceforge code: > Could it be that the sourceforge code is only compatible with DLEP-00? >=20 > Henning Rogge > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Apr 30 08:24:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292E421F8682 for ; Mon, 30 Apr 2012 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y7DmvV1tbQE for ; Mon, 30 Apr 2012 08:24:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 392AE21F8669 for ; Mon, 30 Apr 2012 08:24:45 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2519404vcb.31 for ; Mon, 30 Apr 2012 08:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z24SwGtLWUi0v1ZIJBgdB2xCx1sfQSP+DalUi3tAQSQ=; b=v4I3nklnb9an2+VZ4AG7pc8/KeHsNr7jqz2Cp0zX0JrabztPa/uATd0HXYIlyOz6AM qSwHh3OfQGwEQejKsirORQJODdLPX0szAQZEmiyfHPttKKJ+dXpF5Kf+3kOiQdUMsJ1k dv4hVW9hCHVz6w5RORzJR806/FFfKM/7ocgrDRasyxIae/ZLcDtDyiD+/ydoYqxB23rH A/T7MLHkTMyiWMfc2NW/4wj+hUuCBnP3aSPfPWUJpcaWG1yd4qMDoO7O2F9D5d410z06 0b4/0tAlkvq3SFZVxMAMGosisxnmD3c2HXc80T5oYjKK254g1oSDwKAWSHki4kvlyoq+ p7DA== MIME-Version: 1.0 Received: by 10.52.68.77 with SMTP id u13mr7108373vdt.81.1335799484663; Mon, 30 Apr 2012 08:24:44 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 08:24:44 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 16:24:44 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=20cf307d022cc6467004bee70d9d Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:24:47 -0000 --20cf307d022cc6467004bee70d9d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Henning, Please note that I read the first pages of draft many times before posting any information. HR>I would suggest reading the OLSRv2-draft again, especially section 2. >OLSRv2 interface: >A MANET interface running this protocol. A router running this >protocol MUST have at least one OLSRv2 interface. HR>A routing protocol which does not run on any interface would be pretty >useless, right? You reply to the second sentence not the first which has 'running this protocol' relating it not to the router it is relating it to the interface. I know that router must have at least a network-interface ( or data-link-layer) or MANET interface, this is not what I commenting and the draft is mentioning. We don't assume at least Data-Link because it is obvious and we are following TCP/IP model in the internet, but not at least a specific-interface called bla bla. Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this protocol (OLSRv2) this means there is some thing related to OLSRv2 in the layer-2. You should read again another paragraph mentioning as if there is difference between MANET-interface and OLSRv2-interface. OLSRv2-14>p9> Supports routers that each have one or more participating OLSRv2 interfaces, which will consist of some or all of its MANET interfaces using [RFC6130]. The set of a router=92s OLSRv2 interfaces, and the sets of its other MANET and non-MANET interfaces, may change over time. Each interface may have one or more network addresses (which may have prefix lengths), and these may also be dynamically changing. AB> it is clear from the above draft-page-9, that all MANET interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. So we have to have in or node at least an OLSRv2-interface, not at least one MANET-interfac so the protocol to work correctly. AB> The above page-9 mentions NHDP as well that interfaces need this protocol. What if there is not NHDP, or if it is not working, what will happen. The draft SHOULD explain these issues. AB> It may be that all OLSRv2 routers (as implementation point of practice) only need at least one MANET interface. But the authors need to change. therefore, we know that All routers need at least on interface, but the draft-wording has a special OLSRv2-interface. Then we need to change the draft wording to the right explaination. Abdussalam BAryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 2:14 PM, Henning Rogge wrote= : > On Mon, Apr 30, 2012 at 14:27, Abdussalam Baryun > wrote: > > Hi Chris, > > > > I am sorry to be pointless, however, I am discussing with reference, > > andplease just inform me where I understood wrong so we can progress. I > > don't think volunteering to read other peoples work and trying to make > the > > best in my knowledge is pointless. I know I am less knowledge, but I wi= ll > > not stop reading and commenting, only if the chair of the WG informs me= , > so > > please respect my work with no insults, otherwise the chair should info= rm > > one of us who is pointless in our discussion under his responsibility. > > > > Please read my reply-comment to OLSRv2 below: > > > >> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > >> have to be depending on Data-Link-layer information and in the same > >> time it may use information from Data-Link-Layer, > > > >>There's no contradiction there. It doesn't have to be dependent on data > >>link layer information, but it may (optional, don't have to do it) use > it. > > > > Why does the OLSRv2 draft mention that routers must have at least one > > OLSRv2-interface. The interface isData-Link layer because all > > MANET-interfaces are Data-link layers, but still it stated no assumptio= n > for > > the underlying data-link layer. I suggest to delete the word 'no > assumption' > > because OLSRv2-draft assumes that all routers must have at least on > > OLSRv2-interface otherwise it doesn't work. > > I would suggest reading the OLSRv2-draft again, especially section 2. > > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface. > > A routing protocol which does not run on any interface would be pretty > useless, right? > > Henning Rogge > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > --20cf307d022cc6467004bee70d9d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.

>OLSRv2 interface:
>A MANET interface running this pr= otocol. =A0A router running this
>protocol MUST have at least one OLS= Rv2 interface.

HR>A routing protocol which does not run on any interface would be p= retty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.
=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.
=A0
Abdussalam BAryun
University of Glamorgan, UK
+++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++++++++++
On Mon, Apr 30, 2012 at 2:14 PM, Henning Rogge <= span dir=3D"ltr"><hrogge@googlemail.com> wrote:
On Mon, Apr 30, 2012 at 14:27, Abdussalam Baryun
<<= a href=3D"mailto:abdussalambaryun@gmail.com">abdussalambaryun@gmail.com= > wrote:
> Hi Chris,
>
> I am sorry to be pointless, h= owever, I am discussing with reference,
> andplease just inform me where I understood wrong so we can progress. = I
> don't think volunteering to read other peoples work and tryin= g to make the
> best in my knowledge is pointless. I know I am less k= nowledge, but I will
> not stop reading and commenting, only if the chair of the WG informs m= e, so
> please respect my work with no insults, otherwise the chair s= hould inform
> one of us who is pointless in our discussion under his= responsibility.
>
> Please read my reply-comment to OLSRv2 below:
>
>&= gt; AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard do= esn't
>> have to be depending on Data-Link-layer information a= nd in the same
>> time it may use information from Data-Link-Layer,
>
>&= gt;There's no contradiction there. It doesn't have to be dependent = on data
>>link layer information, but it may (optional, don't = have to do it) use it.
>
> Why does the OLSRv2 draft mention that routers must have at le= ast one
> OLSRv2-interface. The interface isData-Link layer because a= ll
> MANET-interfaces are Data-link layers, but still it stated no as= sumption for
> the underlying data-link layer. I suggest to delete the word 'no a= ssumption'
> because OLSRv2-draft assumes that all routers must h= ave at least on
> OLSRv2-interface otherwise it doesn't work.

I would suggest reading the OLSRv2-draft again, especially sectio= n 2.

OLSRv2 interface:
A MANET interface running this protocol. = =A0A router running this
protocol MUST have at least one OLSRv2 interfac= e.

A routing protocol which does not run on any interface would be pretty<= br>useless, right?

He= nning Rogge
--
Steven Hawkings about cosmic inflation: "An in= crease of billions of
billions of percent in a tiny fraction of a second= . Of course, that
was before the present government."

--20cf307d022cc6467004bee70d9d-- From Chris.Dearlove@baesystems.com Mon Apr 30 08:25:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0E21F866B for ; Mon, 30 Apr 2012 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6BHei77WeO7 for ; Mon, 30 Apr 2012 08:25:26 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 2B18D21F8636 for ; Mon, 30 Apr 2012 08:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208,217";a="235127892" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 16:25:24 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3UFPNWt031870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 16:25:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 16:25:23 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] DLEP mechanism used by MANET Routing Thread-Index: AQHNJGiF7hS2wiOVt0ua0yGx2ia9C5aueLyAgACdloCAAA3EgIAABkgAgAAA4wCAApChAIABVwOggAAsuICAAEFkwA== Date: Mon, 30 Apr 2012 15:25:23 +0000 Message-ID: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0140B4GLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:25:31 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0140B4GLKXM0002VGREENLN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is = an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn't care about = that. Your statement "a MANET interface is a data link interface" is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 13:27 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I am sorry to be pointless, however, I am discussing with reference, andple= ase just inform me where I understood wrong so we can progress. I don't thi= nk volunteering to read other peoples work and trying to make the best in m= y knowledge is pointless. I know I am less knowledge, but I will not stop r= eading and commenting, only if the chair of the WG informs me, so please re= spect my work with no insults, otherwise the chair should inform one of us = who is pointless in our discussion under his responsibility. Please read my reply-comment to OLSRv2 below: > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, >There's no contradiction there. It doesn't have to be dependent on data >link layer information, but it may (optional, don't have to do it) use it. Why does the OLSRv2 draft mention that routers must have at least one OLSRv= 2-interface. The interface isData-Link layer because all MANET-interfaces a= re Data-link layers, but still it stated no assumption for the underlying d= ata-link layer. I suggest to delete the word 'no assumption' because OLSRv2= -draft assumes that all routers must have at least on OLSRv2-interface othe= rwise it doesn't work. I need an explanation please. thanking you for your comments, Abdussalam Baryun > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) > wrote: Abdussalam Baryun > RFC6130>p5 > >This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication > > to 1-hop neighbor routers. > AB> NHDP assumes support of local broadcast or multicast for communicatio= n > to 1-hop neighbor routers. If no such support then it is not correct. The piece you quoted explicitly points this out (the bit starting "other"). So your comment is incorrect. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. Which is exactly as it says. I don't know what your point is. Abdussalam Baryun > OLSRv2-work-in-progress>p7 > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, thr= ough > >its use of [RFC6130], may use link layer information and > >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other > >information. OLSRv2 does not specify the physical meaning of link > >metrics, but specifies a means by which new types of link metrics may > >be specified in the future, but used by OLSRv2 without modification. > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, There's no contradiction there. It doesn't have to be dependent on data link layer information, but it may (optional, don't have to do it) use it. > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). > This claim is only true if the Data-Link is > using RFC5444, First 5444 is not used by the data link, it's used by the routing protocol, which is at L3. And use of 5444 is mandatory when using OLSRv2 as defined by the specification. I also don't see the connection to link metri= cs. OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics. > and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. This has completely missed the point, being based on the incorrect assumpti= on that 5444 is used at data link layer. Abdussalam Baryun > RFC5444>page 4 > >This document specifies the syntax of a packet format designed > >for carrying multiple routing protocol messages for information exchang= e >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >Message Header, which is designed for control of message > >dissemination, and a Message Body, which contains protocol > >information. > AB>Comments> Therefore, RFC5444 is specified to messages-format for excha= nge > between Routers. That's what it was designed for. If someone wants to use it for something e= lse, fine. > Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, That is done by RFC 5498. > otherwise we need to update all old standards that we have > like DSR, AODV, etc. Obviously 5444 doesn't demand changes to existing experimental protocols. 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). But those earlier protocols each have their own UDP port, and 5498 does not apply. > Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual. I'm afraid I can't see any point made. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0140B4GLKXM0002VGREENLN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An OLSRv2 interface (a sp= ecial case of a MANET interface, see RFC 6130) is an IP interface, one whic= h IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn’t care about tha= t. Your statement “a MANET interface is a data link interface” = is wrong.

 <= /p>

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

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

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com
Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and tryin= g to make the best in my knowledge is pointless. I know I am less knowledge, but I will not stop reading and = commenting, only if the chair of the WG informs me, so please respect my wo= rk with no insults, otherwise the chair should inform one of us who is poin= tless in our discussion under his responsibility.

 

Please read my reply-comment to OLSRv2 below:

 

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

>There's no contradiction there. It doesn't have to be dependent on data=
>link layer information, but it may (optional, don't have to do it) use = it.

 

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no assumption' because OLSRv2-draft assumes = that all routers must have at least on OLSRv2-interface otherwise it doesn'= t work.

 

I need an explanation please. thanking you for your = comments,

 

Abdussalam Baryun

 


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

 

 

++++&= #43;++++++++++++++&= #43;++++++++++++++&= #43;++++++++++++++&= #43;++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5 > >This protocol makes no assumptions about the underlying
> > link layer, other than support of local broadcast or multicast fo= r
> > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes support of local broadcast or multicast for commun= ication
> to 1-hop neighbor routers. If no such support then it is not correct.<= o:p>

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectly this protocol has not an awareness of any fault in the=
> L1 wireless communication.

Which is exactly as it says. I don't know what your = point is.

Abdussalam Baryun

> OLSRv2-work-in-p= rogress>p7
> >OLSRv2 makes no assumptions about the underlying link layer. OLSRv= 2, through
> >its use of [RFC6130], may use link layer information and
> >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other=
> >information. OLSRv2 does not specify the physical meaning of link<= br> > >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modificatio= n.

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard d= oesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't have to b= e dependent on data
link layer information, but it may (optional, don't have to do it) use it.<= o:p>


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's used b= y the routing protocol,
which is at L3. And use of 5444 is mandatory when using OLSRv2 as
defined by the specification. I also don't see the connection to link metri= cs.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics.


> and under RFC5444 claims that the messages are routers'
> messaging not claiming that messaging are Data-Link
> messages/information/interaction. therefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

Abdussalam Baryun

> RFC5444>page = 4
> >This document specifies the syntax of a packet format designed
> >for carrying multiple routing protocol messages for  informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
> >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is specified to messages-format = for exchange
> between Routers.

That's what it was designed for. If someone wants to= use it for something else, fine.


> Secondly it mentions no MUST/SHOULD for the
> IETF-MANET routing standards that it uses this particular message
> format,

That is done by RFC 5498.


> otherwise we need to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existing ex= perimental protocols.
5498 mandates the use of 5444 on the manet UDP port (and IP protocol).
But those earlier protocols each have their own UDP port, and 5498 does
not apply.


> Also it does not mention Data-Link
> interaction/exchange (i.e. L2 information availability, or L2 frames'<= br> > formating) at all.

Of course not. 5444 s= pecifies a format, which is encapsulated in UDP/IP,
and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual.

I'm afraid I can't see any point made.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 | &= nbsp;Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://www.baesyst= ems.com

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


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

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0140B4GLKXM0002VGREENLN_-- From boberry@cisco.com Mon Apr 30 08:35:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A128621F86B2 for ; Mon, 30 Apr 2012 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+G9D7EsPWeO for ; Mon, 30 Apr 2012 08:35:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B521F85FB for ; Mon, 30 Apr 2012 08:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=1835; q=dns/txt; s=iport; t=1335800123; x=1337009723; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BMTXFMx7HU/Dn8oLRRnb8/2rSY76KsjQCGjFEmGZ2tE=; b=FZ3KsVRdGhilJinPauJ+g+yARvLQz3wrT2Mv6uvY3w7k3ckwFSlMYa98 2Ngabici0w0M1rMixgbgq5NGTnCeZOoGWjRp4DHMADPkHpeNXQZoKZJbf 1zwZWjfd7Qxz8UpQp932aO5f7qwLqHbDF7U6ErDeE5uAS90nEBU/Eubbr 8=; X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208";a="79099863" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 30 Apr 2012 15:35:22 +0000 Received: from dhcp-64-102-194-44.cisco.com (dhcp-64-102-194-44.cisco.com [64.102.194.44]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q3UFZLAA017929; Mon, 30 Apr 2012 15:35:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 30 Apr 2012 11:35:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <529AE670-683F-48DD-88DB-BD92118A6D50@cisco.com> References: To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP and TLV breakdown X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:35:23 -0000 Henning, All The sourceforge implementation is DLEP-00, supporting only the RFC 544 = features that we required. It includes a server (router) and client = (radio) side. It is posted using the MIT style license.=20 It was built primarily on MAC. =20 -Bo On Apr 30, 2012, at 11:22 AM, Stan Ratliff wrote: > Henning,=20 >=20 > Yes, I believe that's correct. The Sourceforge implementation was = based on DLEP-00 or DLEP-01, can't remember which. It should be in the = README. >=20 > Regards, > Stan >=20 > On Apr 28, 2012, at 6:59 AM, Henning Rogge wrote: >=20 >> On Fri, Apr 27, 2012 at 16:17, dsatterw wrote: >>> At this point we have at least 4 working >>> implementations of DLEP out there which were all based on our = sourceforge >>> example of a packet parser that seems sufficient for the ones = involved. >>=20 >> One more questions about the sourceforge code: >> Could it be that the sourceforge code is only compatible with = DLEP-00? >>=20 >> Henning Rogge >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From abdussalambaryun@gmail.com Mon Apr 30 08:41:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85321F867F for ; Mon, 30 Apr 2012 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imhM093lDAth for ; Mon, 30 Apr 2012 08:41:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE1E21F867A for ; Mon, 30 Apr 2012 08:41:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2512584vbb.31 for ; Mon, 30 Apr 2012 08:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0BcvoaxcgXwAvyWTGjRskTK2EfUspwvHZip9hiBu3vg=; b=jcpDmrguHIoPCUNBL3AyyA1MGIRmC3bpPvwh1tlTGlDFtBqvT3Q7h5Stq1w0gAImjK t2nIyRTmpVY9gvyz0ubWb/fq4kVIy/UhtA83ERoG+5badzV1m6WAmRnKBnBX//qvEAUH RlOfXVU9VYnQcC+zyADQ5uN7uzXHp3u7/RCpG7UdGZXEk6no5n4G1+SaL3JZW1kdziVG xoF44SlnrMV+3EY2eIQv48CAoyQdBJjpz/gf2sOGmKrxwTZZ0RDBgEIMbs3cOK4jnjdH 4R+mZj7DgLydaFm5l/yP9ph8DkyIRleI36uoUF4tnAb6oOCysY00UoyBHA0gkkFtXVn9 +3wg== MIME-Version: 1.0 Received: by 10.220.155.197 with SMTP id t5mr17269023vcw.6.1335800480763; Mon, 30 Apr 2012 08:41:20 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 08:41:20 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 16:41:20 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=f46d043890f5258f2b04bee749e8 Cc: manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:41:23 -0000 --f46d043890f5258f2b04bee749e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Chris ok then if it was simple to explain as a special interface as IP-interface why we have OLSRv2_draft saying that it is network-interface as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that this SHOULD be explained clearly. I think every one seems to understand that network-interface must include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you did. I thank you for your comment, Therefore I suggest to change OLSRv2-interface definition as Chris defined it very clearly. I hope the draft can change the definition, Abdussalam On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) > is an IP interface, one which IP receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t ca= re > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* 30 April 2012 13:27 > *To:* Dearlove, Christopher (UK) > *Cc:* Henning Rogge; manet; Bo Berry; sratliff@cisco.com > > *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > Hi Chris,**** > > **** > > I am sorry to be pointless, however, I am discussing with reference, > andplease just inform me where I understood wrong so we can progress. I > don't think volunteering to read other peoples work and trying to make th= e > best in my knowledge is pointless. I know I am less knowledge, but I will > not stop reading and commenting, only if the chair of the WG informs me, = so > please respect my work with no insults, otherwise the chair should inform > one of us who is pointless in our discussion under his responsibility.***= * > > **** > > Please read my reply-comment to OLSRv2 below:**** > > **** > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer, > > >There's no contradiction there. It doesn't have to be dependent on data > >link layer information, but it may (optional, don't have to do it) use i= t. > **** > > **** > > Why does the OLSRv2 draft mention that routers must have at least one > OLSRv2-interface. The interface isData-Link layer because all > MANET-interfaces are Data-link layers, but still it stated no assumption > for the underlying data-link layer. I suggest to delete the word 'no > assumption' because OLSRv2-draft assumes that all routers must have at > least on OLSRv2-interface otherwise it doesn't work.**** > > **** > > I need an explanation please. thanking you for your comments,**** > > **** > > Abdussalam Baryun**** > > **** > > > > moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying.**** > > Which is true, not just a claim. Note that how the metric is calculated i= s > outside OLSRv2 (read the draft).**** > > ** ** > > **** > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**** > > On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote:**** > > Abdussalam Baryun**** > > > RFC6130>p5 > > >This protocol makes no assumptions about the underlying > > > link layer, other than support of local broadcast or multicast for > > > communication > > > to 1-hop neighbor routers. > > > AB> NHDP assumes support of local broadcast or multicast for > communication > > to 1-hop neighbor routers. If no such support then it is not correct.**= * > * > > The piece you quoted explicitly points this out (the bit starting "other"= ). > So your comment is incorrect.**** > > > > Also indirectly this protocol has not an awareness of any fault in the > > L1 wireless communication.**** > > Which is exactly as it says. I don't know what your point is. > > Abdussalam Baryun**** > > > OLSRv2-work-in-progress>p7 > > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, > through > > >its use of [RFC6130], may use link layer information and > > >notifications when available and applicable. In addition, OLSRv2 > > >uses link metrics that may be derived from link layer or any other > > >information. OLSRv2 does not specify the physical meaning of link > > >metrics, but specifies a means by which new types of link metrics may > > >be specified in the future, but used by OLSRv2 without modification. > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer,**** > > There's no contradiction there. It doesn't have to be dependent on data > link layer information, but it may (optional, don't have to do it) use it= . > **** > > > > moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying.**** > > Which is true, not just a claim. Note that how the metric is calculated i= s > outside OLSRv2 (read the draft).**** > > > > This claim is only true if the Data-Link is > > using RFC5444,**** > > First 5444 is not used by the data link, it's used by the routing protoco= l, > which is at L3. And use of 5444 is mandatory when using OLSRv2 as > defined by the specification. I also don't see the connection to link > metrics. > OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. > If, hypothetically, someone created an alternative data format for OLSRv2 > not based on 5444, it would need to carry metrics.**** > > > > and under RFC5444 claims that the messages are routers' > > messaging not claiming that messaging are Data-Link > > messages/information/interaction. therefore OLSRv2 assumes that > > Data-Link layer MUST RFC5444, so that it can use the information in > > Data-Link.**** > > This has completely missed the point, being based on the incorrect > assumption > that 5444 is used at data link layer. > > Abdussalam Baryun**** > > > RFC5444>page 4 > > >This document specifies the syntax of a packet format designed > > >for carrying multiple routing protocol messages for information > exchange > >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > > >Message Header, which is designed for control of message > > >dissemination, and a Message Body, which contains protocol > > >information. > > > AB>Comments> Therefore, RFC5444 is specified to messages-format for > exchange > > between Routers.**** > > That's what it was designed for. If someone wants to use it for something > else, fine.**** > > > > Secondly it mentions no MUST/SHOULD for the > > IETF-MANET routing standards that it uses this particular message > > format,**** > > That is done by RFC 5498.**** > > > > otherwise we need to update all old standards that we have > > like DSR, AODV, etc.**** > > Obviously 5444 doesn't demand changes to existing experimental protocols. > 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). > But those earlier protocols each have their own UDP port, and 5498 does > not apply.**** > > > > Also it does not mention Data-Link > > interaction/exchange (i.e. L2 information availability, or L2 frames' > > formating) at all.**** > > Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, > and then presented to the data link layer. 5444 relies on IP to interface > to the data link layer, as usual. > > I'm afraid I can't see any point made. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > 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. > ************************************************************************ > > ** ** > --f46d043890f5258f2b04bee749e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as IP-int= erface why we have OLSRv2_draft saying that it is network-interface as MANE= T is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer = to a network while you mean a protocol, even though I know I may misunderst= ood. I sugget that this SHOULD be explained clearly. I think every one seem= s to understand that network-interface must include=A0Data-Link-layer, ther= efore, RFC6130 or OLSRv2-draft should define well as you did. I thank you f= or your comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris def= ined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" target=3D"_blank" value=3D"+4412452421= 24">+44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com=20


Subject: Re: [manet] DLEP mechanism used by MA= NET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originat= es from outside our organisation, either from an external partner or the in= ternet.
Keep t= his in mind if you answer this message.
Please see this process on= how to deal with suspicious emails.

Hi Chris,

=A0

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and t= rying to make the best in my knowledge is pointless. I know I am less knowl= edge, but I will not stop reading and commenting, only if the chair of the = WG informs me, so please respect my work with no insults, otherwise the cha= ir should inform one of us who is pointless in our discussion under his res= ponsibility.

=A0

Please read my reply-comment to OLSRv2 below:=

=A0

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link= -layer information and in the same
> time it may use information from= Data-Link-Layer,

>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.

=A0

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no= assumption' because OLSRv2-draft assumes that all routers must have at= least on OLSRv2-interface otherwise it doesn't work.

=A0

I need an explanation please. thanking you for your = comments,

=A0

Abdussalam Baryun

=A0


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

=A0

=A0

+++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
&= gt; >This protocol makes no assumptions about the underlying
> >= ; link layer, other than support of local broadcast or multicast for
>= ; > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes suppor= t of local broadcast or multicast for communication
> to 1-hop neighb= or routers. If no such support then it is not correct.

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectl= y this protocol has not an awareness of any fault in the
> L1 wireles= s communication.

Which is exactly as it says. I don't know what y= our point is.

Abdussalam Baryun

> OLSRv2-work-in-pro= gress>p7
> >OLSRv2 makes no assumptions about the underlying li= nk layer. OLSRv2, through
> >its use of [RFC6130], may use link la= yer information and
> >notifications when available and applicable. In addition, OLSRv2> >uses link metrics that may be derived from link layer or any oth= er
> >information. OLSRv2 does not specify the physical meaning of= link
> >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modi= fication.

> AB> OLSRv2 claims and assumes indirectly> that = OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same> time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't h= ave to be dependent on data
link layer information, but it may (optional= , don't have to do it) use it.


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is = only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's us= ed by the routing protocol,
which is at L3. And use of 5444 is mandatory= when using OLSRv2 as
defined by the specification. I also don't see= the connection to link metrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If,= hypothetically, someone created an alternative data format for OLSRv2
n= ot based on 5444, it would need to carry metrics.


> and under RFC5= 444 claims that the messages are routers'
> messaging not claimin= g that messaging are Data-Link
> messages/information/interaction. th= erefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

A= bdussalam Baryun

> RFC5444>page 4<= br>> >This document specifies the syntax of a packet format designed<= br>> >for carrying multiple routing protocol messages for =A0informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
= > >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is = specified to messages-format for exchange
> between Routers.

That's what it was designed for. If someone want= s to use it for something else, fine.


> Secondly it me= ntions no MUST/SHOULD for the
> IETF-MANET routing standards that it = uses this particular message
> format,

That is done by RFC 5498.


> otherwise we n= eed to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existin= g experimental protocols.
5498 mandates the use of 5444 on the manet UDP= port (and IP protocol).
But those earlier protocols each have their own= UDP port, and 5498 does
not apply.


> Also it does n= ot mention Data-Link
> interaction/exchange (i.e. L2 information avai= lability, or L2 frames'
> formating) at all.

Of course not. 5444 spe= cifies a format, which is encapsulated in UDP/IP,
and then presented to = the data link layer. 5444 relies on IP to interface
to the data link lay= er, as usual.

I'm afraid I can't see any point made.

--
Christopher= Dearlove
Senior Principal Engineer, Communications Group
Communicati= ons, Networks and Image Analysis Capability
BAE Systems Advanced Technol= ogy Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| = =A0Fax: +44 1245 24= 2124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) L= imited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1= 996687


*********************************************************= ***********
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

=A0


--f46d043890f5258f2b04bee749e8-- From Chris.Dearlove@baesystems.com Mon Apr 30 08:51:48 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6D021F86DA for ; Mon, 30 Apr 2012 08:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTsfm05i0Hqz for ; Mon, 30 Apr 2012 08:51:42 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id C571A21F84A7 for ; Mon, 30 Apr 2012 08:51:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208,217";a="235136661" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 16:51:40 +0100 Received: from GLKXH0003V.GREENLNK.net ([10.109.2.34]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3UFpdDu019211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 16:51:39 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 16:51:39 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] DLEP mechanism used by MANET Routing Thread-Index: AQHNJGiF7hS2wiOVt0ua0yGx2ia9C5aueLyAgACdloCAAA3EgIAABkgAgAAA4wCAApChAIABVwOggAAsuICAAEFkwP//9MoAgAASSCA= Date: Mon, 30 Apr 2012 15:51:39 +0000 Message-ID: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014111GLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet , Bo Berry , "sratliff@cisco.com" Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:51:48 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014111GLKXM0002VGREENLN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IP is a network layer (L3) protocol. All I can say about the definitions in= 6130 (which are at the root of this) is that those were definitions that p= assed review by the WG, the IETF, GEN-ART, RTG-AREA and the IESG (and some = other people who probably didn't look at those definitions). Probably becau= se the IETF's default assumption is that anything like interface is L3 unle= ss stated otherwise. There is no need and no point to change the OLSRv2 definitions. They just s= ay that OLSRv2 interfaces are a subset of MANET interfaces. The definition = that matters is that of MANET interface, and that's in RFC 6130, which as t= he RFC indicates is a done deal. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 16:41 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris ok then if it was simple to explain as a special interface as IP-interface = why we have OLSRv2_draft saying that it is network-interface as MANET is a = network, but IP is not it is a protocol. IMO it is wrong to refer to a netw= ork while you mean a protocol, even though I know I may misunderstood. I su= gget that this SHOULD be explained clearly. I think every one seems to unde= rstand that network-interface must include Data-Link-layer, therefore, RFC6= 130 or OLSRv2-draft should define well as you did. I thank you for your com= ment, Therefore I suggest to change OLSRv2-interface definition as Chris defined = it very clearly. I hope the draft can change the definition, Abdussalam On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) > wrote: An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is = an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn't care about = that. Your statement "a MANET interface is a data link interface" is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 13:27 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I am sorry to be pointless, however, I am discussing with reference, andple= ase just inform me where I understood wrong so we can progress. I don't thi= nk volunteering to read other peoples work and trying to make the best in m= y knowledge is pointless. I know I am less knowledge, but I will not stop r= eading and commenting, only if the chair of the WG informs me, so please re= spect my work with no insults, otherwise the chair should inform one of us = who is pointless in our discussion under his responsibility. Please read my reply-comment to OLSRv2 below: > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, >There's no contradiction there. It doesn't have to be dependent on data >link layer information, but it may (optional, don't have to do it) use it. Why does the OLSRv2 draft mention that routers must have at least one OLSRv= 2-interface. The interface isData-Link layer because all MANET-interfaces a= re Data-link layers, but still it stated no assumption for the underlying d= ata-link layer. I suggest to delete the word 'no assumption' because OLSRv2= -draft assumes that all routers must have at least on OLSRv2-interface othe= rwise it doesn't work. I need an explanation please. thanking you for your comments, Abdussalam Baryun > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) > wrote: Abdussalam Baryun > RFC6130>p5 > >This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication > > to 1-hop neighbor routers. > AB> NHDP assumes support of local broadcast or multicast for communicatio= n > to 1-hop neighbor routers. If no such support then it is not correct. The piece you quoted explicitly points this out (the bit starting "other"). So your comment is incorrect. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. Which is exactly as it says. I don't know what your point is. Abdussalam Baryun > OLSRv2-work-in-progress>p7 > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, thr= ough > >its use of [RFC6130], may use link layer information and > >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other > >information. OLSRv2 does not specify the physical meaning of link > >metrics, but specifies a means by which new types of link metrics may > >be specified in the future, but used by OLSRv2 without modification. > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, There's no contradiction there. It doesn't have to be dependent on data link layer information, but it may (optional, don't have to do it) use it. > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). > This claim is only true if the Data-Link is > using RFC5444, First 5444 is not used by the data link, it's used by the routing protocol, which is at L3. And use of 5444 is mandatory when using OLSRv2 as defined by the specification. I also don't see the connection to link metri= cs. OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics. > and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. This has completely missed the point, being based on the incorrect assumpti= on that 5444 is used at data link layer. Abdussalam Baryun > RFC5444>page 4 > >This document specifies the syntax of a packet format designed > >for carrying multiple routing protocol messages for information exchang= e >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >Message Header, which is designed for control of message > >dissemination, and a Message Body, which contains protocol > >information. > AB>Comments> Therefore, RFC5444 is specified to messages-format for excha= nge > between Routers. That's what it was designed for. If someone wants to use it for something e= lse, fine. > Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, That is done by RFC 5498. > otherwise we need to update all old standards that we have > like DSR, AODV, etc. Obviously 5444 doesn't demand changes to existing experimental protocols. 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). But those earlier protocols each have their own UDP port, and 5498 does not apply. > Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual. I'm afraid I can't see any point made. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014111GLKXM0002VGREENLN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IP is a network layer (L3= ) protocol. All I can say about the definitions in 6130 (which are at the r= oot of this) is that those were definitions that passed review by the WG, the IETF, GEN-ART, RTG-AREA and the IESG (and some other= people who probably didn’t look at those definitions). Probably beca= use the IETF’s default assumption is that anything like interface is = L3 unless stated otherwise.

 <= /p>

There is no need and no p= oint to change the OLSRv2 definitions. They just say that OLSRv2 interfaces= are a subset of MANET interfaces. The definition that matters is that of MANET interface, and that’s in RFC 6130, which as the RFC= indicates is a done deal.

 <= /p>

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

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

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 16:41
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com
Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris

 

ok then if it was simple to explain as a special int= erface as IP-interface why we have OLSRv2_draft saying that it is netw= ork-interface as MANET is a network, but IP is not it is a protocol. IMO it=  is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that thi= s SHOULD be explained clearly. I think every one seems to understand that n= etwork-interface must include Data-Link-layer, therefore, RFC6130 or O= LSRv2-draft should define well as you did. I thank you for your comment,

 

Therefore I suggest to change OLSRv2-interface defin= ition as Chris defined it very clearly. I hope the draft can change th= e definition,

 

Abdussalam=

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

An OLSRv2 interface (a special case of = a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data li= nk layer below it, but OLSRv2 doesn’t care about that. Your statement= “a MANET interface is a data link interface” is wrong.<= o:p>

 

--

Christopher Dearlove<= /p>

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

chris.dearlove@baesystems.com | http://www.baes= ystems.com

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

 

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com


Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I am sorry to be pointless, however, I am discussing with referenc= e, andplease just inform me where I understood wrong so we can progress. I = don't think volunteering to read other peoples work and trying to make the best in my knowledge is pointless. I k= now I am less knowledge, but I will not stop reading and commenting, only i= f the chair of the WG informs me, so please respect my work with no insults= , otherwise the chair should inform one of us who is pointless in our discussion under his responsibility.

 

Please read my reply-comment to OLSRv2 below:

 

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-s= tandard doesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

>There's no contradiction there. It doesn't have to be dependent on data=
>link layer information, but it may (optional, don't have to do it) use = it.

 

Why does the OLSRv2 draft mention that routers must have at least = one OLSRv2-interface. The interface isData-Link layer because all MANET-int= erfaces are Data-link layers, but still it stated no assumption for the underlying data-link layer. I suggest to d= elete the word 'no assumption' because OLSRv2-draft assumes that all router= s must have at least on OLSRv2-interface otherwise it doesn't work.

 

I need an explanation please. thanking you for your comments,=

 

Abdussalam Baryun

 


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).

 

 

++++++++++++++&#= 43;++++++++++++++&#= 43;++++++++++++++&#= 43;+++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) <<= a href=3D"mailto:Chris.Dearlove@baesystems.com" target=3D"_blank">Chris.Dea= rlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
> >This protocol makes no assumptions about the underlying
> > link layer, other than support of local broadcast or multicast fo= r
> > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes support of local broadcast or multicast for commun= ication
> to 1-hop neighbor routers. If no such support then it is not correct.<= o:p>

The piece you quoted explicitly points this out (the bit starting = "other").
So your comment is incorrect.


> Also indirectly this protocol has not an awareness of any fault in the=
> L1 wireless communication.

Which is exactly as it says. I don't know what your point is.

Abdussalam Baryun

> OLSRv2-work-in-progress>p7
> >OLSRv2 makes no assumptions about the underlying link layer. OLSRv= 2, through
> >its use of [RFC6130], may use link layer information and
> >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other=
> >information. OLSRv2 does not specify the physical meaning of link<= br> > >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modificatio= n.

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard d= oesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't have to be dependent on= data
link layer information, but it may (optional, don't have to do it) use it.<= o:p>


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).


> This claim is only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's used by the routing = protocol,
which is at L3. And use of 5444 is mandatory when using OLSRv2 as
defined by the specification. I also don't see the connection to link metri= cs.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics.


> and under RFC5444 claims that the messages are routers'
> messaging not claiming that messaging are Data-Link
> messages/information/interaction. therefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link.

This has completely missed the point, being based on the incorrect= assumption
that 5444 is used at data link layer.

Abdussalam Baryun

> RFC5444>page 4
> >This document specifies the syntax of a packet format designed
> >for carrying multiple routing protocol messages for  informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
> >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is specified to messages-format = for exchange
> between Routers.

That's what it was designed for. If someone wants to use it for so= mething else, fine.


> Secondly it mentions no MUST/SHOULD for the
> IETF-MANET routing standards that it uses this particular message
> format,

That is done by RFC 5498.


> otherwise we need to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existing experimental pro= tocols.
5498 mandates the use of 5444 on the manet UDP port (and IP protocol).
But those earlier protocols each have their own UDP port, and 5498 does
not apply.


> Also it does not mention Data-Link
> interaction/exchange (i.e. L2 information availability, or L2 frames'<= br> > formating) at all.

Of course not. 5444 specifies a format, which is encapsulated in UDP/IP,=
and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual.

I'm afraid I can't see any point made.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=
chris.de= arlove@baesystems.com | http://www.baesyst= ems.com

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


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

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014111GLKXM0002VGREENLN_-- From abdussalambaryun@gmail.com Mon Apr 30 09:17:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9221F867F for ; Mon, 30 Apr 2012 09:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.642 X-Spam-Level: X-Spam-Status: No, score=-3.642 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzsS20VwA1Eo for ; Mon, 30 Apr 2012 09:17:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C178F21F8678 for ; Mon, 30 Apr 2012 09:16:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2543724vbb.31 for ; Mon, 30 Apr 2012 09:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HxCgMiNdIqOfB+mR4naBUerieRjy0Rw2MwsUTcbGLfA=; b=Rhonq7H9nZiWupOghErk+WRVwbn73j6NDrUnJN91WLcsRg8mAA+lTWlgsTPcGBVBKF MwecQQh4LziYMQ+xHSEzckRaDhN+Y/DQxniEwuvl+qRaEwYZHDT4rYVem1yDCNC/UWFK Of4Qlr7/Y04GKDI4EIANotG3S3EgBhUDjgwIT3ls4HHds28YepG3m9GmhGBE2aGbdXOy 7PtVBqE5esiXejWdBHfysHnJ3pkZvkWVHLWvMudCqKwyzu4xghw8JNB4Ed3Rma1txHPD yHpFJlXEUGiICvq+6qZEkLeYQX+H2g0z2QxYJTGQDkOTwPwYaW76hqdoc9bRMQcGosGH Lfng== MIME-Version: 1.0 Received: by 10.52.36.81 with SMTP id o17mr18383668vdj.97.1335802619150; Mon, 30 Apr 2012 09:16:59 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 09:16:58 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 17:16:58 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf307c9e4a9ac1f104bee7c8c4 Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:17:01 -0000 --20cf307c9e4a9ac1f104bee7c8c4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Chris, I read parts quickly from RFC6130, and it does not mention any special IP-interface, it defines in another way: Interface: A router=92s attachment to a communications medium. An interface is assigned one or more addresses. MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. AB> It does not mention that it is Network-layer, so it assumes that we understand the definition, without mentioning where this protocol can be runed. When I read this protocol before, I thought it can be in the both L2 or L3, but if we define the MANET-interface as IP-intrface (as you defined it). I read many draft of IETF but this RFC6130 is not clear in definition and is not consistent with others that define network-interface. I now started to beleive that 6130-MANET-interfaces are all logical interfaces. Please read the draft about IPv6 logical-interface draft below: draft-ietf-netext-logical-interface-support-04.txt Regards Abdussalam Baryun On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Chris > > ok then if it was simple to explain as a special interface as IP-interfac= e > why we have OLSRv2_draft saying that it is network-interface as MANET is = a > network, but IP is not it is a protocol. IMO it is wrong to refer to a > network while you mean a protocol, even though I know I may misunderstood= . > I sugget that this SHOULD be explained clearly. I think every one seems t= o > understand that network-interface must include Data-Link-layer, therefore= , > RFC6130 or OLSRv2-draft should define well as you did. I thank you for yo= ur > comment, > > Therefore I suggest to change OLSRv2-interface definition as Chris define= d > it very clearly. I hope the draft can change the definition, > > Abdussalam > > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >> is an IP interface, one which IP receives packets on, has one or more IP >> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t c= are >> about that. Your statement =93a MANET interface is a data link interface= =94 is >> wrong.**** >> >> ** ** >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> ** ** >> >> *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> *Sent:* 30 April 2012 13:27 >> *To:* Dearlove, Christopher (UK) >> *Cc:* Henning Rogge; manet; Bo Berry; sratliff@cisco.com >> >> *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** >> >> ** ** >> >> ** ** >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how = to deal with suspicious emails. >> ***** >> >> Hi Chris,**** >> >> **** >> >> I am sorry to be pointless, however, I am discussing with reference, >> andplease just inform me where I understood wrong so we can progress. I >> don't think volunteering to read other peoples work and trying to make t= he >> best in my knowledge is pointless. I know I am less knowledge, but I wil= l >> not stop reading and commenting, only if the chair of the WG informs me,= so >> please respect my work with no insults, otherwise the chair should infor= m >> one of us who is pointless in our discussion under his responsibility.**= * >> * >> >> **** >> >> Please read my reply-comment to OLSRv2 below:**** >> >> **** >> >> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't >> > have to be depending on Data-Link-layer information and in the same >> > time it may use information from Data-Link-Layer, >> >> >There's no contradiction there. It doesn't have to be dependent on data >> >link layer information, but it may (optional, don't have to do it) use >> it.**** >> >> **** >> >> Why does the OLSRv2 draft mention that routers must have at least one >> OLSRv2-interface. The interface isData-Link layer because all >> MANET-interfaces are Data-link layers, but still it stated no assumption >> for the underlying data-link layer. I suggest to delete the word 'no >> assumption' because OLSRv2-draft assumes that all routers must have at >> least on OLSRv2-interface otherwise it doesn't work.**** >> >> **** >> >> I need an explanation please. thanking you for your comments,**** >> >> **** >> >> Abdussalam Baryun**** >> >> **** >> >> >> > moreover, claiming >> > it will not need to be modified if there is change in metric or >> > information of underlying.**** >> >> Which is true, not just a claim. Note that how the metric is calculated = is >> outside OLSRv2 (read the draft).**** >> >> ** ** >> >> **** >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**** >> >> On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote:**** >> >> Abdussalam Baryun**** >> >> > RFC6130>p5 >> > >This protocol makes no assumptions about the underlying >> > > link layer, other than support of local broadcast or multicast for >> > > communication >> > > to 1-hop neighbor routers. >> >> > AB> NHDP assumes support of local broadcast or multicast for >> communication >> > to 1-hop neighbor routers. If no such support then it is not correct.*= * >> ** >> >> The piece you quoted explicitly points this out (the bit starting >> "other"). >> So your comment is incorrect.**** >> >> >> > Also indirectly this protocol has not an awareness of any fault in the >> > L1 wireless communication.**** >> >> Which is exactly as it says. I don't know what your point is. >> >> Abdussalam Baryun**** >> >> > OLSRv2-work-in-progress>p7 >> > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, >> through >> > >its use of [RFC6130], may use link layer information and >> > >notifications when available and applicable. In addition, OLSRv2 >> > >uses link metrics that may be derived from link layer or any other >> > >information. OLSRv2 does not specify the physical meaning of link >> > >metrics, but specifies a means by which new types of link metrics may >> > >be specified in the future, but used by OLSRv2 without modification. >> >> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't >> > have to be depending on Data-Link-layer information and in the same >> > time it may use information from Data-Link-Layer,**** >> >> There's no contradiction there. It doesn't have to be dependent on data >> link layer information, but it may (optional, don't have to do it) use i= t. >> **** >> >> >> > moreover, claiming >> > it will not need to be modified if there is change in metric or >> > information of underlying.**** >> >> Which is true, not just a claim. Note that how the metric is calculated = is >> outside OLSRv2 (read the draft).**** >> >> >> > This claim is only true if the Data-Link is >> > using RFC5444,**** >> >> First 5444 is not used by the data link, it's used by the routing >> protocol, >> which is at L3. And use of 5444 is mandatory when using OLSRv2 as >> defined by the specification. I also don't see the connection to link >> metrics. >> OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. >> If, hypothetically, someone created an alternative data format for OLSRv= 2 >> not based on 5444, it would need to carry metrics.**** >> >> >> > and under RFC5444 claims that the messages are routers' >> > messaging not claiming that messaging are Data-Link >> > messages/information/interaction. therefore OLSRv2 assumes that >> > Data-Link layer MUST RFC5444, so that it can use the information in >> > Data-Link.**** >> >> This has completely missed the point, being based on the incorrect >> assumption >> that 5444 is used at data link layer. >> >> Abdussalam Baryun**** >> >> > RFC5444>page 4 >> > >This document specifies the syntax of a packet format designed >> > >for carrying multiple routing protocol messages for information >> exchange >> >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >> > >Message Header, which is designed for control of message >> > >dissemination, and a Message Body, which contains protocol >> > >information. >> >> > AB>Comments> Therefore, RFC5444 is specified to messages-format for >> exchange >> > between Routers.**** >> >> That's what it was designed for. If someone wants to use it for somethin= g >> else, fine.**** >> >> >> > Secondly it mentions no MUST/SHOULD for the >> > IETF-MANET routing standards that it uses this particular message >> > format,**** >> >> That is done by RFC 5498.**** >> >> >> > otherwise we need to update all old standards that we have >> > like DSR, AODV, etc.**** >> >> Obviously 5444 doesn't demand changes to existing experimental protocols= . >> 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). >> But those earlier protocols each have their own UDP port, and 5498 does >> not apply.**** >> >> >> > Also it does not mention Data-Link >> > interaction/exchange (i.e. L2 information availability, or L2 frames' >> > formating) at all.**** >> >> Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, >> and then presented to the data link layer. 5444 relies on IP to interfac= e >> to the data link layer, as usual. >> >> I'm afraid I can't see any point made. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> ******************************************************************** >> 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. >> ************************************************************************ >> >> ** ** >> >> > --20cf307c9e4a9ac1f104bee7c8c4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
I read parts quickly from RFC6130, and it does not mention any special= IP-interface, it defines in another way:

=A0

Interface:

A router=92s attachment to = a communications medium. An interface is

assigned one or more addres= ses.

MANET interface:

An interface participating = in a MANET and using this neighborhood

discovery protocol. A router may have several= MANET interfaces.

=A0AB> It does not mention that it is Netw= ork-layer, so it assumes that we understand the definition, without mention= ing where this protocol can be runed. When I read this protocol before, I t= hought it can be in the both L2 or L3, but if we define the MANET-interface= as IP-intrface (as you defined it).

I read many draft of IETF but this RFC6130 is= not clear in definition and is not consistent with others that define netw= ork-interface. I now started to beleive that 6130-MANET-interfaces are all = logical interfaces. Please read the draft about IPv6 logical-interface draf= t below:

draft-ietf-netext-logical-interface-support-0= 4.txt

=A0

Regards

Abdussalam Baryun


=A0
On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as IP-int= erface why we have OLSRv2_draft saying that it is network-interface as MANE= T is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer = to a network while you mean a protocol, even though I know I may misunderst= ood. I sugget that this SHOULD be explained clearly. I think every one seem= s to understand that network-interface must include=A0Data-Link-layer, ther= efore, RFC6130 or OLSRv2-draft should define well as you did. I thank you f= or your comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris def= ined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" target=3D"_blank" value=3D"+4412452421= 24">+44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com=20


Subject: Re: [manet] DLEP mechanism used by MANET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originat= es from outside our organisation, either from an external partner or the in= ternet.
Keep t= his in mind if you answer this message.
Please see this process on= how to deal with suspicious emails.

Hi Chris,

=A0

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and t= rying to make the best in my knowledge is pointless. I know I am less knowl= edge, but I will not stop reading and commenting, only if the chair of the = WG informs me, so please respect my work with no insults, otherwise the cha= ir should inform one of us who is pointless in our discussion under his res= ponsibility.

=A0

Please read my reply-comment to OLSRv2 below:=

=A0

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link= -layer information and in the same
> time it may use information from= Data-Link-Layer,

>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.

=A0

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no= assumption' because OLSRv2-draft assumes that all routers must have at= least on OLSRv2-interface otherwise it doesn't work.

=A0

I need an explanation please. thanking you for your = comments,

=A0

Abdussalam Baryun

=A0


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

=A0

=A0

+++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
&= gt; >This protocol makes no assumptions about the underlying
> >= ; link layer, other than support of local broadcast or multicast for
>= ; > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes suppor= t of local broadcast or multicast for communication
> to 1-hop neighb= or routers. If no such support then it is not correct.

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectl= y this protocol has not an awareness of any fault in the
> L1 wireles= s communication.

Which is exactly as it says. I don't know what y= our point is.

Abdussalam Baryun

> OLSRv2-work-in-pro= gress>p7
> >OLSRv2 makes no assumptions about the underlying li= nk layer. OLSRv2, through
> >its use of [RFC6130], may use link la= yer information and
> >notifications when available and applicable. In addition, OLSRv2> >uses link metrics that may be derived from link layer or any oth= er
> >information. OLSRv2 does not specify the physical meaning of= link
> >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modi= fication.

> AB> OLSRv2 claims and assumes indirectly> that = OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same> time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't h= ave to be dependent on data
link layer information, but it may (optional= , don't have to do it) use it.


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is = only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's us= ed by the routing protocol,
which is at L3. And use of 5444 is mandatory= when using OLSRv2 as
defined by the specification. I also don't see= the connection to link metrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If,= hypothetically, someone created an alternative data format for OLSRv2
n= ot based on 5444, it would need to carry metrics.


> and under RFC5= 444 claims that the messages are routers'
> messaging not claimin= g that messaging are Data-Link
> messages/information/interaction. th= erefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

A= bdussalam Baryun

> RFC5444>page 4<= br>> >This document specifies the syntax of a packet format designed<= br>> >for carrying multiple routing protocol messages for =A0informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
= > >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is = specified to messages-format for exchange
> between Routers.

That's what it was designed for. If someone want= s to use it for something else, fine.


> Secondly it me= ntions no MUST/SHOULD for the
> IETF-MANET routing standards that it = uses this particular message
> format,

That is done by RFC 5498.


> otherwise we n= eed to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existin= g experimental protocols.
5498 mandates the use of 5444 on the manet UDP= port (and IP protocol).
But those earlier protocols each have their own= UDP port, and 5498 does
not apply.


> Also it does n= ot mention Data-Link
> interaction/exchange (i.e. L2 information avai= lability, or L2 frames'
> formating) at all.

Of course not. 5444 spe= cifies a format, which is encapsulated in UDP/IP,
and then presented to = the data link layer. 5444 relies on IP to interface
to the data link lay= er, as usual.

I'm afraid I can't see any point made.

--
Christopher= Dearlove
Senior Principal Engineer, Communications Group
Communicati= ons, Networks and Image Analysis Capability
BAE Systems Advanced Technol= ogy Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| = =A0Fax: +44 1245 24= 2124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) L= imited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1= 996687


*********************************************************= ***********
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

=A0



--20cf307c9e4a9ac1f104bee7c8c4-- From Chris.Dearlove@baesystems.com Mon Apr 30 09:22:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0725D21F86B9 for ; Mon, 30 Apr 2012 09:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1mCzwwqJFg5 for ; Mon, 30 Apr 2012 09:22:06 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 154A521F875E for ; Mon, 30 Apr 2012 09:22:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208,217";a="235144623" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 17:22:04 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3UGM30N006057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 17:22:04 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 17:22:03 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] DLEP mechanism used by MANET Routing Thread-Index: AQHNJGiF7hS2wiOVt0ua0yGx2ia9C5aueLyAgACdloCAAA3EgIAABkgAgAAA4wCAApChAIABVwOggAAsuICAAEFkwP//9MoAgAAJ9QCAABFRcA== Date: Mon, 30 Apr 2012 16:22:03 +0000 Message-ID: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01415FGLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:22:16 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01415FGLKXM0002VGREENLN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 6130 interfaces are IP interfaces. They may be logical, or they may directl= y map to physical interfaces. The point is that we don't care. As for wheth= er 6130 is not clear, as I said, it passed all those reviews and it is too = late to change it, even if we felt otherwise. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 30 April 2012 17:17 To: Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I read parts quickly from RFC6130, and it does not mention any special IP-i= nterface, it defines in another way: Interface: A router's attachment to a communications medium. An interface is assigned one or more addresses. MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. AB> It does not mention that it is Network-layer, so it assumes that we un= derstand the definition, without mentioning where this protocol can be rune= d. When I read this protocol before, I thought it can be in the both L2 or = L3, but if we define the MANET-interface as IP-intrface (as you defined it)= . I read many draft of IETF but this RFC6130 is not clear in definition and i= s not consistent with others that define network-interface. I now started t= o beleive that 6130-MANET-interfaces are all logical interfaces. Please rea= d the draft about IPv6 logical-interface draft below: draft-ietf-netext-logical-interface-support-04.txt Regards Abdussalam Baryun On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun > wrote: Hi Chris ok then if it was simple to explain as a special interface as IP-interface = why we have OLSRv2_draft saying that it is network-interface as MANET is a = network, but IP is not it is a protocol. IMO it is wrong to refer to a netw= ork while you mean a protocol, even though I know I may misunderstood. I su= gget that this SHOULD be explained clearly. I think every one seems to unde= rstand that network-interface must include Data-Link-layer, therefore, RFC6= 130 or OLSRv2-draft should define well as you did. I thank you for your com= ment, Therefore I suggest to change OLSRv2-interface definition as Chris defined = it very clearly. I hope the draft can change the definition, Abdussalam On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) > wrote: An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is = an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn't care about = that. Your statement "a MANET interface is a data link interface" is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 13:27 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I am sorry to be pointless, however, I am discussing with reference, andple= ase just inform me where I understood wrong so we can progress. I don't thi= nk volunteering to read other peoples work and trying to make the best in m= y knowledge is pointless. I know I am less knowledge, but I will not stop r= eading and commenting, only if the chair of the WG informs me, so please re= spect my work with no insults, otherwise the chair should inform one of us = who is pointless in our discussion under his responsibility. Please read my reply-comment to OLSRv2 below: > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, >There's no contradiction there. It doesn't have to be dependent on data >link layer information, but it may (optional, don't have to do it) use it. Why does the OLSRv2 draft mention that routers must have at least one OLSRv= 2-interface. The interface isData-Link layer because all MANET-interfaces a= re Data-link layers, but still it stated no assumption for the underlying d= ata-link layer. I suggest to delete the word 'no assumption' because OLSRv2= -draft assumes that all routers must have at least on OLSRv2-interface othe= rwise it doesn't work. I need an explanation please. thanking you for your comments, Abdussalam Baryun > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) > wrote: Abdussalam Baryun > RFC6130>p5 > >This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication > > to 1-hop neighbor routers. > AB> NHDP assumes support of local broadcast or multicast for communicatio= n > to 1-hop neighbor routers. If no such support then it is not correct. The piece you quoted explicitly points this out (the bit starting "other"). So your comment is incorrect. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. Which is exactly as it says. I don't know what your point is. Abdussalam Baryun > OLSRv2-work-in-progress>p7 > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, thr= ough > >its use of [RFC6130], may use link layer information and > >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other > >information. OLSRv2 does not specify the physical meaning of link > >metrics, but specifies a means by which new types of link metrics may > >be specified in the future, but used by OLSRv2 without modification. > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, There's no contradiction there. It doesn't have to be dependent on data link layer information, but it may (optional, don't have to do it) use it. > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). > This claim is only true if the Data-Link is > using RFC5444, First 5444 is not used by the data link, it's used by the routing protocol, which is at L3. And use of 5444 is mandatory when using OLSRv2 as defined by the specification. I also don't see the connection to link metri= cs. OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics. > and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. This has completely missed the point, being based on the incorrect assumpti= on that 5444 is used at data link layer. Abdussalam Baryun > RFC5444>page 4 > >This document specifies the syntax of a packet format designed > >for carrying multiple routing protocol messages for information exchang= e >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >Message Header, which is designed for control of message > >dissemination, and a Message Body, which contains protocol > >information. > AB>Comments> Therefore, RFC5444 is specified to messages-format for excha= nge > between Routers. That's what it was designed for. If someone wants to use it for something e= lse, fine. > Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, That is done by RFC 5498. > otherwise we need to update all old standards that we have > like DSR, AODV, etc. Obviously 5444 doesn't demand changes to existing experimental protocols. 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). But those earlier protocols each have their own UDP port, and 5498 does not apply. > Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual. I'm afraid I can't see any point made. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01415FGLKXM0002VGREENLN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

6130 interfaces are IP in= terfaces. They may be logical, or they may directly map to physical interfa= ces. The point is that we don’t care. As for whether 6130 is not clear, as I said, it passed all those reviews and it is too late to= change it, even if we felt otherwise.

 <= /p>

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

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

 <= /p>

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org= ] On Behalf Of Abdussalam Baryun
Sent: 30 April 2012 17:17
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I read parts quickly from RFC6130, and it does not m= ention any special IP-interface, it defines in another way:

 

Interface:

A router’s attachment to a communications medium. = An interface is

assigned one or more addresses.

MANET interface:

An interface participating in a MANET and using this nei= ghborhood

discover= y protocol. A router may have several MANET interfaces.

 AB= > It does not mention that it is Network-layer, so it assumes that we un= derstand the definition, without mentioning where this protocol can be runed. When I read this protocol before, I thought it can be in the bot= h L2 or L3, but if we define the MANET-interface as IP-intrface (as you def= ined it).

I read m= any draft of IETF but this RFC6130 is not clear in definition and is not co= nsistent with others that define network-interface. I now started to beleive that 6130-MANET-interfaces are all logical interfaces. = Please read the draft about IPv6 logical-interface draft below:=

draft-ie= tf-netext-logical-interface-support-04.txt

&nbs= p;

Regards<= /span>

Abdussal= am Baryun


 

On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Chris

 

ok then if it was simple to explain as a special int= erface as IP-interface why we have OLSRv2_draft saying that it is netw= ork-interface as MANET is a network, but IP is not it is a protocol. IMO it=  is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that thi= s SHOULD be explained clearly. I think every one seems to understand that n= etwork-interface must include Data-Link-layer, therefore, RFC6130 or O= LSRv2-draft should define well as you did. I thank you for your comment,

 

Therefore I suggest to change OLSRv2-interface defin= ition as Chris defined it very clearly. I hope the draft can change th= e definition,

 

Abdussalam=

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

An OLSRv2 interface (a special case of = a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data li= nk layer below it, but OLSRv2 doesn’t care about that. Your statement= “a MANET interface is a data link interface” is wrong.<= o:p>

 

--

Christopher Dearlove<= /p>

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

chris.dearlove@baesystems.com | http://www.baes= ystems.com

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

 

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com


Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I am sorry to be pointless, however, I am discussing with referenc= e, andplease just inform me where I understood wrong so we can progress. I = don't think volunteering to read other peoples work and trying to make the best in my knowledge is pointless. I k= now I am less knowledge, but I will not stop reading and commenting, only i= f the chair of the WG informs me, so please respect my work with no insults= , otherwise the chair should inform one of us who is pointless in our discussion under his responsibility.

 

Please read my reply-comment to OLSRv2 below:

 

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-s= tandard doesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

>There's no contradiction there. It doesn't have to be dependent on data=
>link layer information, but it may (optional, don't have to do it) use = it.

 

Why does the OLSRv2 draft mention that routers must have at least = one OLSRv2-interface. The interface isData-Link layer because all MANET-int= erfaces are Data-link layers, but still it stated no assumption for the underlying data-link layer. I suggest to d= elete the word 'no assumption' because OLSRv2-draft assumes that all router= s must have at least on OLSRv2-interface otherwise it doesn't work.

 

I need an explanation please. thanking you for your comments,=

 

Abdussalam Baryun

 


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).

 

 

++++++++++++++&#= 43;++++++++++++++&#= 43;++++++++++++++&#= 43;+++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) <<= a href=3D"mailto:Chris.Dearlove@baesystems.com" target=3D"_blank">Chris.Dea= rlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
> >This protocol makes no assumptions about the underlying
> > link layer, other than support of local broadcast or multicast fo= r
> > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes support of local broadcast or multicast for commun= ication
> to 1-hop neighbor routers. If no such support then it is not correct.<= o:p>

The piece you quoted explicitly points this out (the bit starting = "other").
So your comment is incorrect.


> Also indirectly this protocol has not an awareness of any fault in the=
> L1 wireless communication.

Which is exactly as it says. I don't know what your point is.

Abdussalam Baryun

> OLSRv2-work-in-progress>p7
> >OLSRv2 makes no assumptions about the underlying link layer. OLSRv= 2, through
> >its use of [RFC6130], may use link layer information and
> >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other=
> >information. OLSRv2 does not specify the physical meaning of link<= br> > >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modificatio= n.

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard d= oesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't have to be dependent on= data
link layer information, but it may (optional, don't have to do it) use it.<= o:p>


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).


> This claim is only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's used by the routing = protocol,
which is at L3. And use of 5444 is mandatory when using OLSRv2 as
defined by the specification. I also don't see the connection to link metri= cs.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics.


> and under RFC5444 claims that the messages are routers'
> messaging not claiming that messaging are Data-Link
> messages/information/interaction. therefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link.

This has completely missed the point, being based on the incorrect= assumption
that 5444 is used at data link layer.

Abdussalam Baryun

> RFC5444>page 4
> >This document specifies the syntax of a packet format designed
> >for carrying multiple routing protocol messages for  informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
> >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is specified to messages-format = for exchange
> between Routers.

That's what it was designed for. If someone wants to use it for so= mething else, fine.


> Secondly it mentions no MUST/SHOULD for the
> IETF-MANET routing standards that it uses this particular message
> format,

That is done by RFC 5498.


> otherwise we need to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existing experimental pro= tocols.
5498 mandates the use of 5444 on the manet UDP port (and IP protocol).
But those earlier protocols each have their own UDP port, and 5498 does
not apply.


> Also it does not mention Data-Link
> interaction/exchange (i.e. L2 information availability, or L2 frames'<= br> > formating) at all.

Of course not. 5444 specifies a format, which is encapsulated in UDP/IP,=
and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual.

I'm afraid I can't see any point made.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=
chris.de= arlove@baesystems.com | http://www.baesyst= ems.com

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


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

 

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01415FGLKXM0002VGREENLN_-- From abdussalambaryun@gmail.com Mon Apr 30 09:43:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5580221F8790 for ; Mon, 30 Apr 2012 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7CJrOdPf7nJ for ; Mon, 30 Apr 2012 09:43:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D778121F878B for ; Mon, 30 Apr 2012 09:43:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2566987vbb.31 for ; Mon, 30 Apr 2012 09:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8FOhUZ7tp+YwP/0rKsM/jNRcRUYZFgqCC9hpmjFNajI=; b=yymJzuI7mVtzyZUWcPBUQ8Otp10fVTOqHEXUWdPxW86rKCRMW2A1z84ofcR0I+4uNk b2R9FWvYoEoidQv/TRWihPDoA53fKQegkINyGQTM5+kr+Q4DKzhiNflcWuRneZ7+rOgB h59Z2NADfodbcvRa/oNqyaf0f6dviWe88RKI23S1btcZ1EAr+qYBZTJN83sGDJj/oSTk Ju5H5NVzFNzZuGodeq5z7mCyjwMogMlfN3NsvW492qj1aPqXfbaqXV6cY1MwfRRXtE49 oymnMZ0Z6VKS9LtNvqc6OKKNt/L0/AdrIhHtN6W0BoKtbMXnBnD4Xed8Sg8+ZWWj2ED6 T8Eg== MIME-Version: 1.0 Received: by 10.52.178.129 with SMTP id cy1mr18486757vdc.8.1335804184767; Mon, 30 Apr 2012 09:43:04 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 09:43:04 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 17:43:04 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=bcaec5196a59ec2e2704bee825f4 Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:43:09 -0000 --bcaec5196a59ec2e2704bee825f4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ok, what about OLSRv2 is it possible to clarify the IP-interface in the definition? or is there no confusion about MANET-interfaces with other MANET routing definitions? IMO definitions in the MANET-WG should be very focused and consistent because if in MANET protocols we define differently a commo term how will we get protocols to use in the future common standard(s). Abdussalam Baryun On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > 6130 interfaces are IP interfaces. They may be logical, or they may > directly map to physical interfaces. The point is that we don=92t care. A= s > for whether 6130 is not clear, as I said, it passed all those reviews and > it is too late to change it, even if we felt otherwise.**** > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Abdussalam Baryun > *Sent:* 30 April 2012 17:17 > *To:* Dearlove, Christopher (UK) > *Cc:* manet > > *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > Hi Chris,**** > > **** > > I read parts quickly from RFC6130, and it does not mention any special > IP-interface, it defines in another way:**** > > **** > > Interface:**** > > A router=92s attachment to a communications medium. An interface is**** > > assigned one or more addresses.**** > > MANET interface:**** > > An interface participating in a MANET and using this neighborhood**** > > discovery protocol. A router may have several MANET interfaces.**** > > AB> It does not mention that it is Network-layer, so it assumes that we > understand the definition, without mentioning where this protocol can be > runed. When I read this protocol before, I thought it can be in the both = L2 > or L3, but if we define the MANET-interface as IP-intrface (as you define= d > it).**** > > I read many draft of IETF but this RFC6130 is not clear in definition and > is not consistent with others that define network-interface. I now starte= d > to beleive that 6130-MANET-interfaces are all logical interfaces. Please > read the draft about IPv6 logical-interface draft below:**** > > draft-ietf-netext-logical-interface-support-04.txt**** > > **** > > Regards**** > > Abdussalam Baryun**** > > > **** > > On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote:**** > > Hi Chris**** > > **** > > ok then if it was simple to explain as a special interface as IP-interfac= e > why we have OLSRv2_draft saying that it is network-interface as MANET is = a > network, but IP is not it is a protocol. IMO it is wrong to refer to a > network while you mean a protocol, even though I know I may misunderstood= . > I sugget that this SHOULD be explained clearly. I think every one seems t= o > understand that network-interface must include Data-Link-layer, therefore= , > RFC6130 or OLSRv2-draft should define well as you did. I thank you for yo= ur > comment,**** > > **** > > Therefore I suggest to change OLSRv2-interface definition as Chris define= d > it very clearly. I hope the draft can change the definition,**** > > **** > > Abdussalam**** > > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote:**** > > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s > an IP interface, one which IP receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t ca= re > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong.**** > > **** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > **** > > *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* 30 April 2012 13:27 > *To:* Dearlove, Christopher (UK) > *Cc:* Henning Rogge; manet; Bo Berry; sratliff@cisco.com **** > > > *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** > > **** > > **** > > **** WARNING ******** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how t= o deal with suspicious emails. > ***** > > Hi Chris,**** > > **** > > I am sorry to be pointless, however, I am discussing with reference, > andplease just inform me where I understood wrong so we can progress. I > don't think volunteering to read other peoples work and trying to make th= e > best in my knowledge is pointless. I know I am less knowledge, but I will > not stop reading and commenting, only if the chair of the WG informs me, = so > please respect my work with no insults, otherwise the chair should inform > one of us who is pointless in our discussion under his responsibility.***= * > > **** > > Please read my reply-comment to OLSRv2 below:**** > > **** > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer, > > >There's no contradiction there. It doesn't have to be dependent on data > >link layer information, but it may (optional, don't have to do it) use i= t. > **** > > **** > > Why does the OLSRv2 draft mention that routers must have at least one > OLSRv2-interface. The interface isData-Link layer because all > MANET-interfaces are Data-link layers, but still it stated no assumption > for the underlying data-link layer. I suggest to delete the word 'no > assumption' because OLSRv2-draft assumes that all routers must have at > least on OLSRv2-interface otherwise it doesn't work.**** > > **** > > I need an explanation please. thanking you for your comments,**** > > **** > > Abdussalam Baryun**** > > **** > > > > moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying.**** > > Which is true, not just a claim. Note that how the metric is calculated i= s > outside OLSRv2 (read the draft).**** > > **** > > **** > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**** > > On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote:**** > > Abdussalam Baryun**** > > > RFC6130>p5 > > >This protocol makes no assumptions about the underlying > > > link layer, other than support of local broadcast or multicast for > > > communication > > > to 1-hop neighbor routers. > > > AB> NHDP assumes support of local broadcast or multicast for > communication > > to 1-hop neighbor routers. If no such support then it is not correct.**= * > * > > The piece you quoted explicitly points this out (the bit starting "other"= ). > So your comment is incorrect.**** > > > > Also indirectly this protocol has not an awareness of any fault in the > > L1 wireless communication.**** > > Which is exactly as it says. I don't know what your point is. > > Abdussalam Baryun**** > > > OLSRv2-work-in-progress>p7 > > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, > through > > >its use of [RFC6130], may use link layer information and > > >notifications when available and applicable. In addition, OLSRv2 > > >uses link metrics that may be derived from link layer or any other > > >information. OLSRv2 does not specify the physical meaning of link > > >metrics, but specifies a means by which new types of link metrics may > > >be specified in the future, but used by OLSRv2 without modification. > > > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > > have to be depending on Data-Link-layer information and in the same > > time it may use information from Data-Link-Layer,**** > > There's no contradiction there. It doesn't have to be dependent on data > link layer information, but it may (optional, don't have to do it) use it= . > **** > > > > moreover, claiming > > it will not need to be modified if there is change in metric or > > information of underlying.**** > > Which is true, not just a claim. Note that how the metric is calculated i= s > outside OLSRv2 (read the draft).**** > > > > This claim is only true if the Data-Link is > > using RFC5444,**** > > First 5444 is not used by the data link, it's used by the routing protoco= l, > which is at L3. And use of 5444 is mandatory when using OLSRv2 as > defined by the specification. I also don't see the connection to link > metrics. > OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. > If, hypothetically, someone created an alternative data format for OLSRv2 > not based on 5444, it would need to carry metrics.**** > > > > and under RFC5444 claims that the messages are routers' > > messaging not claiming that messaging are Data-Link > > messages/information/interaction. therefore OLSRv2 assumes that > > Data-Link layer MUST RFC5444, so that it can use the information in > > Data-Link.**** > > This has completely missed the point, being based on the incorrect > assumption > that 5444 is used at data link layer. > > Abdussalam Baryun**** > > > RFC5444>page 4 > > >This document specifies the syntax of a packet format designed > > >for carrying multiple routing protocol messages for information > exchange > >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > > >Message Header, which is designed for control of message > > >dissemination, and a Message Body, which contains protocol > > >information. > > > AB>Comments> Therefore, RFC5444 is specified to messages-format for > exchange > > between Routers.**** > > That's what it was designed for. If someone wants to use it for something > else, fine.**** > > > > Secondly it mentions no MUST/SHOULD for the > > IETF-MANET routing standards that it uses this particular message > > format,**** > > That is done by RFC 5498.**** > > > > otherwise we need to update all old standards that we have > > like DSR, AODV, etc.**** > > Obviously 5444 doesn't demand changes to existing experimental protocols. > 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). > But those earlier protocols each have their own UDP port, and 5498 does > not apply.**** > > > > Also it does not mention Data-Link > > interaction/exchange (i.e. L2 information availability, or L2 frames' > > formating) at all.**** > > Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, > and then presented to the data link layer. 5444 relies on IP to interface > to the data link layer, as usual. > > I'm afraid I can't see any point made. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > ******************************************************************** > 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. > ************************************************************************ > > **** > > ** ** > > ** ** > --bcaec5196a59ec2e2704bee825f4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ok, what about OLSRv2 is it possible to clarify the IP-interface in th= e definition? or is there no confusion about MANET-interfaces with other MA= NET routing definitions? IMO definitions in the MANET-WG should be very foc= used and consistent because if in MANET protocols we define differently a c= ommo term how will we get protocols to use in the future=A0common standard(= s).
=A0
Abdussalam Baryun

On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:

6130 interfaces are IP interfac= es. They may be logical, or they may directly map to physical interfaces. T= he point is that we don=92t care. As for whether 6130 is not clear, as I sa= id, it passed all those reviews and it is too late to change it, even if we= felt otherwise.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" target=3D"_blank" value=3D"+4412452421= 24">+44 1245 242124

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

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

=A0

From: man= et-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam= Baryun
Sent: 30 April 2012 17:17
To: Dearlove, Christopher (UK)Cc: manet=20


Subject: Re: [manet] DLEP mechanism used by MA= NET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originat= es from outside our organisation, either from an external partner or the in= ternet.
Keep t= his in mind if you answer this message.
Please see this process on= how to deal with suspicious emails.

Hi Chris,

=A0

I read parts quickly from RFC6130, and it does not m= ention any special IP-interface, it defines in another way:

=A0

Interface:

A router=92s attachment to a communications medium. An inter= face is

assigned one or more addresses.

MANET interface:

An interface participating in a MANET and using this neighbo= rhood

discovery prot= ocol. A router may have several MANET interfaces.

=A0AB> It d= oes not mention that it is Network-layer, so it assumes that we understand = the definition, without mentioning where this protocol can be runed. When I= read this protocol before, I thought it can be in the both L2 or L3, but i= f we define the MANET-interface as IP-intrface (as you defined it).<= u>

I read many dr= aft of IETF but this RFC6130 is not clear in definition and is not consiste= nt with others that define network-interface. I now started to beleive that= 6130-MANET-interfaces are all logical interfaces. Please read the draft ab= out IPv6 logical-interface draft below:

draft-ietf-net= ext-logical-interface-support-04.txt

=A0=

Regards=

Abdussalam Bar= yun


=A0

On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Chris

=A0

ok then if it was simple to explain as a special int= erface=A0as IP-interface why we have OLSRv2_draft saying that it is network= -interface as MANET is a network, but IP is not it is a protocol. IMO it=A0= is wrong to refer to a network while you mean a protocol, even though I kno= w I may misunderstood. I sugget that this SHOULD be explained clearly. I th= ink every one seems to understand that network-interface must include=A0Dat= a-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you = did. I thank you for your comment,

=A0

Therefore I suggest to change OLSRv2-interface defin= ition as Chris defined it very clearly. I hope the draft can=A0change the d= efinition,

=A0

Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com


Subject: Re: [manet]= DLEP mechanism used by MANET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originat= es from outside our organisation, either from an external partner or the in= ternet.
Keep t= his in mind if you answer this message.
Please see this process on= how to deal with suspicious emails.

Hi Chris,

=A0

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and t= rying to make the best in my knowledge is pointless. I know I am less knowl= edge, but I will not stop reading and commenting, only if the chair of the = WG informs me, so please respect my work with no insults, otherwise the cha= ir should inform one of us who is pointless in our discussion under his res= ponsibility.

=A0

Please read my reply-comment to OLSRv2 below:=

=A0

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link= -layer information and in the same
> time it may use information from= Data-Link-Layer,

>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.

=A0

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no= assumption' because OLSRv2-draft assumes that all routers must have at= least on OLSRv2-interface otherwise it doesn't work.

=A0

I need an explanation please. thanking you for your = comments,

=A0

Abdussalam Baryun

=A0


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

=A0

=A0

+++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
&= gt; >This protocol makes no assumptions about the underlying
> >= ; link layer, other than support of local broadcast or multicast for
>= ; > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes suppor= t of local broadcast or multicast for communication
> to 1-hop neighb= or routers. If no such support then it is not correct.

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectl= y this protocol has not an awareness of any fault in the
> L1 wireles= s communication.

Which is exactly as it says. I don't know what y= our point is.

Abdussalam Baryun

> OLSRv2-work-in-pro= gress>p7
> >OLSRv2 makes no assumptions about the underlying li= nk layer. OLSRv2, through
> >its use of [RFC6130], may use link la= yer information and
> >notifications when available and applicable. In addition, OLSRv2> >uses link metrics that may be derived from link layer or any oth= er
> >information. OLSRv2 does not specify the physical meaning of= link
> >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modi= fication.

> AB> OLSRv2 claims and assumes indirectly> that = OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same> time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't h= ave to be dependent on data
link layer information, but it may (optional= , don't have to do it) use it.


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is = only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's us= ed by the routing protocol,
which is at L3. And use of 5444 is mandatory= when using OLSRv2 as
defined by the specification. I also don't see= the connection to link metrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If,= hypothetically, someone created an alternative data format for OLSRv2
n= ot based on 5444, it would need to carry metrics.


> and under RFC5= 444 claims that the messages are routers'
> messaging not claimin= g that messaging are Data-Link
> messages/information/interaction. th= erefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

A= bdussalam Baryun

> RFC5444>page 4<= br>> >This document specifies the syntax of a packet format designed<= br>> >for carrying multiple routing protocol messages for =A0informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
= > >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is = specified to messages-format for exchange
> between Routers.

That's what it was designed for. If someone want= s to use it for something else, fine.


> Secondly it me= ntions no MUST/SHOULD for the
> IETF-MANET routing standards that it = uses this particular message
> format,

That is done by RFC 5498.


> otherwise we n= eed to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existin= g experimental protocols.
5498 mandates the use of 5444 on the manet UDP= port (and IP protocol).
But those earlier protocols each have their own= UDP port, and 5498 does
not apply.


> Also it does n= ot mention Data-Link
> interaction/exchange (i.e. L2 information avai= lability, or L2 frames'
> formating) at all.

Of course not. 5444 spe= cifies a format, which is encapsulated in UDP/IP,
and then presented to = the data link layer. 5444 relies on IP to interface
to the data link lay= er, as usual.

I'm afraid I can't see any point made.

--
Christopher= Dearlove
Senior Principal Engineer, Communications Group
Communicati= ons, Networks and Image Analysis Capability
BAE Systems Advanced Technol= ogy Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| = =A0Fax: +44 1245 24= 2124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) L= imited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1= 996687


*********************************************************= ***********
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

=A0

=A0

=A0


--bcaec5196a59ec2e2704bee825f4-- From ulrich@herberg.name Mon Apr 30 09:45:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970E621F87EE for ; Mon, 30 Apr 2012 09:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEEb4-jj+DSF for ; Mon, 30 Apr 2012 09:45:11 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A86C321F87EA for ; Mon, 30 Apr 2012 09:45:11 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so720348pbc.31 for ; Mon, 30 Apr 2012 09:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/vPOrV+j676+ymsTHwcWSy1Q/lVGvwIcaokE5mnN20=; b=Dvhaxu2/W3iufRVqcrfL4LEmuRegauKpd/7aO0Vxi+Ku9+ji2tQFrEMvaWPIyCGg3e 6a4RpZTv22kk16Rs/YgtgZATGRVTQy4Po6URJsHvA8EpSgBP/xguRbqPRF4Uw6oIF1C0 I7pNd1iElpGJ8mpkkwD3yw/wzk0Cdx0yyOuyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=J/vPOrV+j676+ymsTHwcWSy1Q/lVGvwIcaokE5mnN20=; b=Izbq5Cg1E+aS9WWV0Ups9sV9vabWVQf38Exn9CnXFAuIyizPYP+/jHZv7VJ5S3L04Z Zpy79ExOAanNpSk1zyAoh2X3EC252ZUOV6FUtEJIqgq/8rlnvCnk8aWSr2Zpe7XHYMno 79fjhzUA7xK4Giilbphn7ERA7VUxkQMj3U6MPJAQiqUWMkd1CSLOzSt5x27O2Fsx59z1 vevJy6eb/6AdoXHpaA9Rs4IJ+Go92UpDvhqOQnImU6HBeLBTpfk+OCePHGwuwKuH9/0c y/PszQp/tcirKCo8o4y044b1l4x9HvTcF8t55Ki5sxVrt47UHESU8LPCsx8HEJEKhA9k clEg== MIME-Version: 1.0 Received: by 10.68.225.9 with SMTP id rg9mr20187753pbc.137.1335804311515; Mon, 30 Apr 2012 09:45:11 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Mon, 30 Apr 2012 09:45:11 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 09:45:11 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b2ee18b7a312704bee82d73 X-Gm-Message-State: ALoCoQmcPSO7lNYwXsIIBNmEDhQ5rJQ5/ntkF2PaHLKC3EymVlpHAtH7sgKQK3VAGgwbM+/bHzwV Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:45:12 -0000 --047d7b2ee18b7a312704bee82d73 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam, RFC6130 defines: MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. And draft-ietf-manet-olsrv2 defines: OLSRv2 interface: A MANET interface running this protocol. A router running this protocol MUST have at least one OLSRv2 interface. In one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiates between neighbors running only NHDP and neighbors running also OLSRv2, and only the latter are used for MPR selection, etc. I do not understand what you would like to change in the OLSRv2 draft. See comments below: On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Henning, > > Please note that I read the first pages of draft many times before postin= g > any information. > > HR>I would suggest reading the OLSRv2-draft again, especially section 2. > > > >OLSRv2 interface: > >A MANET interface running this protocol. A router running this > >protocol MUST have at least one OLSRv2 interface. > > HR>A routing protocol which does not run on any interface would be pretty > >useless, right? > You reply to the second sentence not the first which has 'running this > protocol' relating it not to the router it is relating it to the interfac= e. > I know that router must have at least a network-interface ( or > data-link-layer) or MANET interface, this is not what I commenting and th= e > draft is mentioning. We don't assume at least Data-Link because it is > obvious and we are following TCP/IP model in the internet, but not at lea= st > a specific-interface called bla bla. > > Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this > protocol (OLSRv2) this means there is some thing related to OLSRv2 in the > layer-2. You should read again another paragraph mentioning as if there i= s > difference between MANET-interface and OLSRv2-interface. > > OLSRv2-14>p9> > > Supports routers that each have one or more participating OLSRv2 > > interfaces, which will consist of some or all of its MANET > > interfaces using [RFC6130]. The set of a router=92s OLSRv2 > > interfaces, and the sets of its other MANET and non-MANET > > interfaces, may change over time. Each interface may have one or > > more network addresses (which may have prefix lengths), and these > > may also be dynamically changing. > > AB> it is clear from the above draft-page-9, that all MANET interfaces ar= e > not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. = So > we have to have in or node at least an OLSRv2-interface, not at least one > MANET-interfac so the protocol to work correctly. > > AB> The above page-9 mentions NHDP as well that interfaces need this > protocol. What if there is not NHDP, or if it is not working, what will > happen. The draft SHOULD explain these issues. > > AB> It may be that all OLSRv2 routers (as implementation point of > practice) only need at least one MANET interface. But the authors need to > change. therefore, we know that All routers need at least on interface, b= ut > the draft-wording has a special OLSRv2-interface. Then we need to change > the draft wording to the right explaination. > Can you suggest what you would like to change? I don't understand your point. Best regards Ulrich --047d7b2ee18b7a312704bee82d73 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam,

RFC6130 defines:

MANET interface:
An interface= participating in a MANET and using this neighborhood
=A0=A0=A0=A0=A0 di= scovery protocol.=A0 A router may have several MANET interfaces.

And= draft-ietf-manet-olsrv2 defines:
OLSRv2 interface:
=A0=A0=A0=A0=A0 A MANET interface running this protoco= l.=A0 A router running this
=A0=A0=A0=A0=A0 protocol MUST have at least = one OLSRv2 interface.

In one of the last OLSRv2 revisions, we made s= ure that OLSRv2 differentiates between neighbors running only NHDP and neig= hbors running also OLSRv2, and only the latter are used for MPR selection, = etc. I do not understand what you would like to change in the OLSRv2 draft.=

See comments below:

On Mon, Apr 30, 2= 012 at 8:24 AM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.


>OLSRv2 interface:
>A MANET interfa= ce running this protocol. =A0A router running this
>protocol MUST hav= e at least one OLSRv2 interface.

HR>A routing protocol which does not run on any interface woul= d be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.


=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.


Can you suggest what you would like to change? I = don't understand your point.

Best regards
Ulrich
=A0
--047d7b2ee18b7a312704bee82d73-- From ulrich@herberg.name Mon Apr 30 09:52:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28C21F872D for ; Mon, 30 Apr 2012 09:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9UTe3PAiF4R for ; Mon, 30 Apr 2012 09:52:12 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 77ADD21F8750 for ; Mon, 30 Apr 2012 09:52:11 -0700 (PDT) Received: by dady13 with SMTP id y13so5756980dad.27 for ; Mon, 30 Apr 2012 09:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6qF2awwQ3jYyjE7RO8GcOI4AzGZcCQhVHY1CMhh8tIc=; b=grAWv2lwSRMAI81pqUzXVTLeMyBchIIa/ubaKiwl0eBfuZN+FwKGrjw+zqzonZ1UnW kg4EU6ifG8MpldgZvFWe7ldbrjM+a2A5z1y1o2mZTKheZISbTuc5Q89NBsssId4QxBtz 3wTZhJRuYbqrBbc/xlV6s9jc+rvJdr5m/bQKc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6qF2awwQ3jYyjE7RO8GcOI4AzGZcCQhVHY1CMhh8tIc=; b=azmZOkxiEYz2+5HttGQI80rP+zWY5AYnEccrAOEEG76AYQDI49bniY056eeJPAR+Ei I+rFRn0uU7ihS1oYCoaTZgQfL4erwewGIewpersATGi2YMsHwN5jHby5qwW0Sy+7fiJd FS6TlfooUrfjnTvutVXM91cL7YlAj082VjZh/q05YiqId3DJll4f+gJlKKzB+PBWTYH+ iIaX4dDrlGHpJy/50pQ7i1CKmnZLeVP7TDHZKpHapgCx7qJVosoCxK0vHjpY+ZwjzCdh vODeNXqGr/P+3pZhTTsibjiqwzfTLiP5UeoDsM698gypU3zviYyO5obdKXBZseWUUz8z 4E/A== MIME-Version: 1.0 Received: by 10.68.233.1 with SMTP id ts1mr1468610pbc.19.1335804731102; Mon, 30 Apr 2012 09:52:11 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Mon, 30 Apr 2012 09:52:10 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 09:52:10 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b33ca687c96f904bee84674 X-Gm-Message-State: ALoCoQmI0YVLw7DVFWVQ/nHPt+PVNW3RFlRzCOQHXo0MytRvtqJUM65lWhXO3Y/aXqo/S4G15PWJ Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:52:14 -0000 --047d7b33ca687c96f904bee84674 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam, RFC6130 is an IP protocol (like most IETF standards). It is not specified as L2 protocol. Best regards Ulrich On Mon, Apr 30, 2012 at 9:16 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Chris, > > I read parts quickly from RFC6130, and it does not mention any special > IP-interface, it defines in another way: > > > > Interface: > > A router=92s attachment to a communications medium. An interface is > > assigned one or more addresses. > > MANET interface: > > An interface participating in a MANET and using this neighborhood > > discovery protocol. A router may have several MANET interfaces. > > AB> It does not mention that it is Network-layer, so it assumes that we > understand the definition, without mentioning where this protocol can be > runed. When I read this protocol before, I thought it can be in the both = L2 > or L3, but if we define the MANET-interface as IP-intrface (as you define= d > it). > > I read many draft of IETF but this RFC6130 is not clear in definition and > is not consistent with others that define network-interface. I now starte= d > to beleive that 6130-MANET-interfaces are all logical interfaces. Please > read the draft about IPv6 logical-interface draft below: > > draft-ietf-netext-logical-interface-support-04.txt > > > > Regards > > Abdussalam Baryun > > > On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Chris >> >> ok then if it was simple to explain as a special interface as >> IP-interface why we have OLSRv2_draft saying that it is network-interfac= e >> as MANET is a network, but IP is not it is a protocol. IMO it is wrong t= o >> refer to a network while you mean a protocol, even though I know I may >> misunderstood. I sugget that this SHOULD be explained clearly. I think >> every one seems to understand that network-interface must >> include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should defin= e >> well as you did. I thank you for your comment, >> >> Therefore I suggest to change OLSRv2-interface definition as Chris >> defined it very clearly. I hope the draft can change the definition, >> >> Abdussalam >> >> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote: >> >>> An OLSRv2 interface (a special case of a MANET interface, see RFC >>> 6130) is an IP interface, one which IP receives packets on, has one or = more >>> IP addresses etc. It has a data link layer below it, but OLSRv2 doesn= =92t >>> care about that. Your statement =93a MANET interface is a data link >>> interface=94 is wrong.**** >>> >>> ** ** >>> >>> -- **** >>> >>> Christopher Dearlove**** >>> >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687**** >>> >>> ** ** >>> >>> *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> *Sent:* 30 April 2012 13:27 >>> *To:* Dearlove, Christopher (UK) >>> *Cc:* Henning Rogge; manet; Bo Berry; sratliff@cisco.com >>> >>> *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** >>> >>> ** ** >>> >>> ** ** >>> >>> **** WARNING **** >>> >>> *This message originates from outside our organisation, either from an >>> external partner or the internet.** >>> Keep this in mind if you answer this message. >>> Please see this processon how= to deal with suspicious emails. >>> ***** >>> >>> Hi Chris,**** >>> >>> **** >>> >>> I am sorry to be pointless, however, I am discussing with reference, >>> andplease just inform me where I understood wrong so we can progress. I >>> don't think volunteering to read other peoples work and trying to make = the >>> best in my knowledge is pointless. I know I am less knowledge, but I wi= ll >>> not stop reading and commenting, only if the chair of the WG informs me= , so >>> please respect my work with no insults, otherwise the chair should info= rm >>> one of us who is pointless in our discussion under his responsibility.*= * >>> ** >>> >>> **** >>> >>> Please read my reply-comment to OLSRv2 below:**** >>> >>> **** >>> >>> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn'= t >>> > have to be depending on Data-Link-layer information and in the same >>> > time it may use information from Data-Link-Layer, >>> >>> >There's no contradiction there. It doesn't have to be dependent on dat= a >>> >link layer information, but it may (optional, don't have to do it) use >>> it.**** >>> >>> **** >>> >>> Why does the OLSRv2 draft mention that routers must have at least one >>> OLSRv2-interface. The interface isData-Link layer because all >>> MANET-interfaces are Data-link layers, but still it stated no assumptio= n >>> for the underlying data-link layer. I suggest to delete the word 'no >>> assumption' because OLSRv2-draft assumes that all routers must have at >>> least on OLSRv2-interface otherwise it doesn't work.**** >>> >>> **** >>> >>> I need an explanation please. thanking you for your comments,**** >>> >>> **** >>> >>> Abdussalam Baryun**** >>> >>> **** >>> >>> >>> > moreover, claiming >>> > it will not need to be modified if there is change in metric or >>> > information of underlying.**** >>> >>> Which is true, not just a claim. Note that how the metric is calculated >>> is >>> outside OLSRv2 (read the draft).**** >>> >>> ** ** >>> >>> **** >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**** >>> >>> On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < >>> Chris.Dearlove@baesystems.com> wrote:**** >>> >>> Abdussalam Baryun**** >>> >>> > RFC6130>p5 >>> > >This protocol makes no assumptions about the underlying >>> > > link layer, other than support of local broadcast or multicast for >>> > > communication >>> > > to 1-hop neighbor routers. >>> >>> > AB> NHDP assumes support of local broadcast or multicast for >>> communication >>> > to 1-hop neighbor routers. If no such support then it is not correct.= * >>> *** >>> >>> The piece you quoted explicitly points this out (the bit starting >>> "other"). >>> So your comment is incorrect.**** >>> >>> >>> > Also indirectly this protocol has not an awareness of any fault in th= e >>> > L1 wireless communication.**** >>> >>> Which is exactly as it says. I don't know what your point is. >>> >>> Abdussalam Baryun**** >>> >>> > OLSRv2-work-in-progress>p7 >>> > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, >>> through >>> > >its use of [RFC6130], may use link layer information and >>> > >notifications when available and applicable. In addition, OLSRv2 >>> > >uses link metrics that may be derived from link layer or any other >>> > >information. OLSRv2 does not specify the physical meaning of link >>> > >metrics, but specifies a means by which new types of link metrics ma= y >>> > >be specified in the future, but used by OLSRv2 without modification. >>> >>> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn'= t >>> > have to be depending on Data-Link-layer information and in the same >>> > time it may use information from Data-Link-Layer,**** >>> >>> There's no contradiction there. It doesn't have to be dependent on data >>> link layer information, but it may (optional, don't have to do it) use >>> it.**** >>> >>> >>> > moreover, claiming >>> > it will not need to be modified if there is change in metric or >>> > information of underlying.**** >>> >>> Which is true, not just a claim. Note that how the metric is calculated >>> is >>> outside OLSRv2 (read the draft).**** >>> >>> >>> > This claim is only true if the Data-Link is >>> > using RFC5444,**** >>> >>> First 5444 is not used by the data link, it's used by the routing >>> protocol, >>> which is at L3. And use of 5444 is mandatory when using OLSRv2 as >>> defined by the specification. I also don't see the connection to link >>> metrics. >>> OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. >>> If, hypothetically, someone created an alternative data format for OLSR= v2 >>> not based on 5444, it would need to carry metrics.**** >>> >>> >>> > and under RFC5444 claims that the messages are routers' >>> > messaging not claiming that messaging are Data-Link >>> > messages/information/interaction. therefore OLSRv2 assumes that >>> > Data-Link layer MUST RFC5444, so that it can use the information in >>> > Data-Link.**** >>> >>> This has completely missed the point, being based on the incorrect >>> assumption >>> that 5444 is used at data link layer. >>> >>> Abdussalam Baryun**** >>> >>> > RFC5444>page 4 >>> > >This document specifies the syntax of a packet format designed >>> > >for carrying multiple routing protocol messages for information >>> exchange >>> >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >>> > >Message Header, which is designed for control of message >>> > >dissemination, and a Message Body, which contains protocol >>> > >information. >>> >>> > AB>Comments> Therefore, RFC5444 is specified to messages-format for >>> exchange >>> > between Routers.**** >>> >>> That's what it was designed for. If someone wants to use it for >>> something else, fine.**** >>> >>> >>> > Secondly it mentions no MUST/SHOULD for the >>> > IETF-MANET routing standards that it uses this particular message >>> > format,**** >>> >>> That is done by RFC 5498.**** >>> >>> >>> > otherwise we need to update all old standards that we have >>> > like DSR, AODV, etc.**** >>> >>> Obviously 5444 doesn't demand changes to existing experimental protocol= s. >>> 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). >>> But those earlier protocols each have their own UDP port, and 5498 does >>> not apply.**** >>> >>> >>> > Also it does not mention Data-Link >>> > interaction/exchange (i.e. L2 information availability, or L2 frames' >>> > formating) at all.**** >>> >>> Of course not. 5444 specifies a format, which is encapsulated in UDP/IP= , >>> and then presented to the data link layer. 5444 relies on IP to interfa= ce >>> to the data link layer, as usual. >>> >>> I'm afraid I can't see any point made. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >>> Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the sender. >>> You should not copy it or use it for any purpose nor disclose or >>> distribute its contents to any other person. >>> ***********************************************************************= * >>> >>> ** ** >>> >>> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b33ca687c96f904bee84674 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam,

RFC6130 is an IP protocol (like most IETF standards). It= is not specified as L2 protocol.

Best regards
Ulrich

On Mon, Apr 30, 2012 at 9:16 AM, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:
Hi Chris,
=A0
I read parts quickly from RFC6130, and it does not mention any special= IP-interface, it defines in another way:

=A0

Interface:

A router=92s attachment to a comm= unications medium. An interface is

assigned one or more addresses.

MANET interface:

An interface participating in a M= ANET and using this neighborhood

discovery protocol. A router may have several MANET= interfaces.

=A0AB> It does not mention that it is Network-la= yer, so it assumes that we understand the definition, without mentioning wh= ere this protocol can be runed. When I read this protocol before, I thought= it can be in the both L2 or L3, but if we define the MANET-interface as IP= -intrface (as you defined it).

I read many draft of IETF but this RFC6130 is not c= lear in definition and is not consistent with others that define network-in= terface. I now started to beleive that 6130-MANET-interfaces are all logica= l interfaces. Please read the draft about IPv6 logical-interface draft belo= w:

draft-ietf-netext-logical-interface-support-04.txt<= /font>

=A0

Regards

Abdussalam Baryun


=A0
On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as IP-int= erface why we have OLSRv2_draft saying that it is network-interface as MANE= T is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer = to a network while you mean a protocol, even though I know I may misunderst= ood. I sugget that this SHOULD be explained clearly. I think every one seem= s to understand that network-interface must include=A0Data-Link-layer, ther= efore, RFC6130 or OLSRv2-draft should define well as you did. I thank you f= or your comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris def= ined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" value=3D"+441245242124" target=3D"_bla= nk">+44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com=20


Subject: Re: [manet] DLEP mechanism used by MANE= T Routing

=A0

=A0

*** WARNING ***<= /p>

This message originate= s from outside our organisation, either from an external partner or the int= ernet.
Keep th= is in mind if you answer this message.
Please see this process on ho= w to deal with suspicious emails.

Hi Chris,

=A0

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and t= rying to make the best in my knowledge is pointless. I know I am less knowl= edge, but I will not stop reading and commenting, only if the chair of the = WG informs me, so please respect my work with no insults, otherwise the cha= ir should inform one of us who is pointless in our discussion under his res= ponsibility.

=A0

Please read my reply-comment to OLSRv2 below:=

=A0

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link= -layer information and in the same
> time it may use information from= Data-Link-Layer,

>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.

=A0

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no= assumption' because OLSRv2-draft assumes that all routers must have at= least on OLSRv2-interface otherwise it doesn't work.

=A0

I need an explanation please. thanking you for your = comments,

=A0

Abdussalam Baryun

=A0


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

=A0

=A0

+++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
&= gt; >This protocol makes no assumptions about the underlying
> >= ; link layer, other than support of local broadcast or multicast for
>= ; > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes suppor= t of local broadcast or multicast for communication
> to 1-hop neighb= or routers. If no such support then it is not correct.

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectl= y this protocol has not an awareness of any fault in the
> L1 wireles= s communication.

Which is exactly as it says. I don't know what y= our point is.

Abdussalam Baryun

> OLSRv2-work-in-pro= gress>p7
> >OLSRv2 makes no assumptions about the underlying li= nk layer. OLSRv2, through
> >its use of [RFC6130], may use link la= yer information and
> >notifications when available and applicable. In addition, OLSRv2> >uses link metrics that may be derived from link layer or any oth= er
> >information. OLSRv2 does not specify the physical meaning of= link
> >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modi= fication.

> AB> OLSRv2 claims and assumes indirectly> that = OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same> time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't h= ave to be dependent on data
link layer information, but it may (optional= , don't have to do it) use it.


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is = only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's us= ed by the routing protocol,
which is at L3. And use of 5444 is mandatory= when using OLSRv2 as
defined by the specification. I also don't see= the connection to link metrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If,= hypothetically, someone created an alternative data format for OLSRv2
n= ot based on 5444, it would need to carry metrics.


> and under RFC5= 444 claims that the messages are routers'
> messaging not claimin= g that messaging are Data-Link
> messages/information/interaction. th= erefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

A= bdussalam Baryun

> RFC5444>page 4<= br>> >This document specifies the syntax of a packet format designed<= br>> >for carrying multiple routing protocol messages for =A0informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
= > >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is = specified to messages-format for exchange
> between Routers.

That's what it was designed for. If someone want= s to use it for something else, fine.


> Secondly it me= ntions no MUST/SHOULD for the
> IETF-MANET routing standards that it = uses this particular message
> format,

That is done by RFC 5498.


> otherwise we n= eed to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existin= g experimental protocols.
5498 mandates the use of 5444 on the manet UDP= port (and IP protocol).
But those earlier protocols each have their own= UDP port, and 5498 does
not apply.


> Also it does n= ot mention Data-Link
> interaction/exchange (i.e. L2 information avai= lability, or L2 frames'
> formating) at all.

Of course not. 5444 spe= cifies a format, which is encapsulated in UDP/IP,
and then presented to = the data link layer. 5444 relies on IP to interface
to the data link lay= er, as usual.

I'm afraid I can't see any point made.

--
Christopher= Dearlove
Senior Principal Engineer, Communications Group
Communicati= ons, Networks and Image Analysis Capability
BAE Systems Advanced Technol= ogy Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| = =A0Fax: +44 1245 24= 2124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) L= imited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1= 996687


*********************************************************= ***********
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

=A0


<= /div>

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


--047d7b33ca687c96f904bee84674-- From ulrich@herberg.name Mon Apr 30 09:55:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3121F87B2 for ; Mon, 30 Apr 2012 09:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdn4p7OfYy+5 for ; Mon, 30 Apr 2012 09:55:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88121F87BF for ; Mon, 30 Apr 2012 09:55:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so730071pbc.31 for ; Mon, 30 Apr 2012 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JAotd9Y5l8pfleLaPvwQIxGhc6nMV4vMEfidt71ULXk=; b=KDobO8xErIDi77o+jVkarZktBqLDCUuwTxTDlvOVleI2dPVHV9RZacozyWfFWw19Ll /2Gk8M8ZnjOqFTvqt5J0OBpn4ghZYyGlvKK8tnzLhFF65fU+kyuHXp3PK7Zr+GVcH94B j11zd4ltF/AiITkssL4lPSH4F9GMpqajeFNt8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=JAotd9Y5l8pfleLaPvwQIxGhc6nMV4vMEfidt71ULXk=; b=SqaBfUdaJAKdBAVYMG0cP6P1+a+vAYYKgmuMkniShUhd6muJ0h8rFI3a8wwAOK5NED ImYJnsae2pGXcHQlMTAoLh5UcDKiQXelYq5KOahS424OTwtZCqffkMVisso1bjkiXT0j I+U/c567nk1yxvwImht6sYO1yCwOZKvtvQYVFcqNbcG0jjeONspUNIkLhl69ZCiENuhr GpSELbv5BarYrBERC3+Ts87EDpJnEDJqs+xLcrkxloGZFvXgIK1QKpqXQfglyS91pTLN vRBS4K4ct2GXGIwpH9drCCRZN50dXjF/1xLrHsn43QRjfIIHWeXr/qmbU0/HfNknb1yu gtXQ== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr49562594pbc.35.1335804906897; Mon, 30 Apr 2012 09:55:06 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Mon, 30 Apr 2012 09:55:06 -0700 (PDT) In-Reply-To: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> Date: Mon, 30 Apr 2012 09:55:06 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b15a61ff7029204bee8506f X-Gm-Message-State: ALoCoQlM9hkXxJi+yIdg6B+8cI9uFVpWF6kjrKCBK+EJ8g7KDZYi1SezzGBV6fhOqsr1XS+pQ/p5 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:55:09 -0000 --047d7b15a61ff7029204bee8506f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't think there is any confusion. Chris has pointed out the relationship between MANET interface and OLSRv2 interface clearly. I think that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would like to change anything, please suggest concrete text to replace, so that I can better understand what you mean. Best regards Ulrich On Mon, Apr 30, 2012 at 9:43 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Ok, what about OLSRv2 is it possible to clarify the IP-interface in the > definition? or is there no confusion about MANET-interfaces with other > MANET routing definitions? IMO definitions in the MANET-WG should be very > focused and consistent because if in MANET protocols we define differentl= y > a commo term how will we get protocols to use in the future common > standard(s). > > Abdussalam Baryun > > On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Christopher (UK) < > Chris.Dearlove@baesystems.com> wrote: > >> 6130 interfaces are IP interfaces. They may be logical, or they may >> directly map to physical interfaces. The point is that we don=92t care. = As >> for whether 6130 is not clear, as I said, it passed all those reviews an= d >> it is too late to change it, even if we felt otherwise.**** >> >> ** ** >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> ** ** >> >> *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On >> Behalf Of *Abdussalam Baryun >> *Sent:* 30 April 2012 17:17 >> *To:* Dearlove, Christopher (UK) >> *Cc:* manet >> >> *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** >> >> ** ** >> >> ** ** >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how = to deal with suspicious emails. >> ***** >> >> Hi Chris,**** >> >> **** >> >> I read parts quickly from RFC6130, and it does not mention any special >> IP-interface, it defines in another way:**** >> >> **** >> >> Interface:**** >> >> A router=92s attachment to a communications medium. An interface is**** >> >> assigned one or more addresses.**** >> >> MANET interface:**** >> >> An interface participating in a MANET and using this neighborhood**** >> >> discovery protocol. A router may have several MANET interfaces.**** >> >> AB> It does not mention that it is Network-layer, so it assumes that we >> understand the definition, without mentioning where this protocol can be >> runed. When I read this protocol before, I thought it can be in the both= L2 >> or L3, but if we define the MANET-interface as IP-intrface (as you defin= ed >> it).**** >> >> I read many draft of IETF but this RFC6130 is not clear in definition an= d >> is not consistent with others that define network-interface. I now start= ed >> to beleive that 6130-MANET-interfaces are all logical interfaces. Please >> read the draft about IPv6 logical-interface draft below:**** >> >> draft-ietf-netext-logical-interface-support-04.txt**** >> >> **** >> >> Regards**** >> >> Abdussalam Baryun**** >> >> >> **** >> >> On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote:**** >> >> Hi Chris**** >> >> **** >> >> ok then if it was simple to explain as a special interface as >> IP-interface why we have OLSRv2_draft saying that it is network-interfac= e >> as MANET is a network, but IP is not it is a protocol. IMO it is wrong t= o >> refer to a network while you mean a protocol, even though I know I may >> misunderstood. I sugget that this SHOULD be explained clearly. I think >> every one seems to understand that network-interface must >> include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should defin= e >> well as you did. I thank you for your comment,**** >> >> **** >> >> Therefore I suggest to change OLSRv2-interface definition as Chris >> defined it very clearly. I hope the draft can change the definition,**** >> >> **** >> >> Abdussalam**** >> >> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote:**** >> >> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >> is an IP interface, one which IP receives packets on, has one or more IP >> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t c= are >> about that. Your statement =93a MANET interface is a data link interface= =94 is >> wrong.**** >> >> **** >> >> -- **** >> >> Christopher Dearlove**** >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124**** >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687**** >> >> **** >> >> *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> *Sent:* 30 April 2012 13:27 >> *To:* Dearlove, Christopher (UK) >> *Cc:* Henning Rogge; manet; Bo Berry; sratliff@cisco.com **** >> >> >> *Subject:* Re: [manet] DLEP mechanism used by MANET Routing**** >> >> **** >> >> **** >> >> **** WARNING ******** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.** >> Keep this in mind if you answer this message. >> Please see this processon how = to deal with suspicious emails. >> ***** >> >> Hi Chris,**** >> >> **** >> >> I am sorry to be pointless, however, I am discussing with reference, >> andplease just inform me where I understood wrong so we can progress. I >> don't think volunteering to read other peoples work and trying to make t= he >> best in my knowledge is pointless. I know I am less knowledge, but I wil= l >> not stop reading and commenting, only if the chair of the WG informs me,= so >> please respect my work with no insults, otherwise the chair should infor= m >> one of us who is pointless in our discussion under his responsibility.**= * >> * >> >> **** >> >> Please read my reply-comment to OLSRv2 below:**** >> >> **** >> >> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't >> > have to be depending on Data-Link-layer information and in the same >> > time it may use information from Data-Link-Layer, >> >> >There's no contradiction there. It doesn't have to be dependent on data >> >link layer information, but it may (optional, don't have to do it) use >> it.**** >> >> **** >> >> Why does the OLSRv2 draft mention that routers must have at least one >> OLSRv2-interface. The interface isData-Link layer because all >> MANET-interfaces are Data-link layers, but still it stated no assumption >> for the underlying data-link layer. I suggest to delete the word 'no >> assumption' because OLSRv2-draft assumes that all routers must have at >> least on OLSRv2-interface otherwise it doesn't work.**** >> >> **** >> >> I need an explanation please. thanking you for your comments,**** >> >> **** >> >> Abdussalam Baryun**** >> >> **** >> >> >> > moreover, claiming >> > it will not need to be modified if there is change in metric or >> > information of underlying.**** >> >> Which is true, not just a claim. Note that how the metric is calculated = is >> outside OLSRv2 (read the draft).**** >> >> **** >> >> **** >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++**** >> >> On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) < >> Chris.Dearlove@baesystems.com> wrote:**** >> >> Abdussalam Baryun**** >> >> > RFC6130>p5 >> > >This protocol makes no assumptions about the underlying >> > > link layer, other than support of local broadcast or multicast for >> > > communication >> > > to 1-hop neighbor routers. >> >> > AB> NHDP assumes support of local broadcast or multicast for >> communication >> > to 1-hop neighbor routers. If no such support then it is not correct.*= * >> ** >> >> The piece you quoted explicitly points this out (the bit starting >> "other"). >> So your comment is incorrect.**** >> >> >> > Also indirectly this protocol has not an awareness of any fault in the >> > L1 wireless communication.**** >> >> Which is exactly as it says. I don't know what your point is. >> >> Abdussalam Baryun**** >> >> > OLSRv2-work-in-progress>p7 >> > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, >> through >> > >its use of [RFC6130], may use link layer information and >> > >notifications when available and applicable. In addition, OLSRv2 >> > >uses link metrics that may be derived from link layer or any other >> > >information. OLSRv2 does not specify the physical meaning of link >> > >metrics, but specifies a means by which new types of link metrics may >> > >be specified in the future, but used by OLSRv2 without modification. >> >> > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't >> > have to be depending on Data-Link-layer information and in the same >> > time it may use information from Data-Link-Layer,**** >> >> There's no contradiction there. It doesn't have to be dependent on data >> link layer information, but it may (optional, don't have to do it) use i= t. >> **** >> >> >> > moreover, claiming >> > it will not need to be modified if there is change in metric or >> > information of underlying.**** >> >> Which is true, not just a claim. Note that how the metric is calculated = is >> outside OLSRv2 (read the draft).**** >> >> >> > This claim is only true if the Data-Link is >> > using RFC5444,**** >> >> First 5444 is not used by the data link, it's used by the routing >> protocol, >> which is at L3. And use of 5444 is mandatory when using OLSRv2 as >> defined by the specification. I also don't see the connection to link >> metrics. >> OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. >> If, hypothetically, someone created an alternative data format for OLSRv= 2 >> not based on 5444, it would need to carry metrics.**** >> >> >> > and under RFC5444 claims that the messages are routers' >> > messaging not claiming that messaging are Data-Link >> > messages/information/interaction. therefore OLSRv2 assumes that >> > Data-Link layer MUST RFC5444, so that it can use the information in >> > Data-Link.**** >> >> This has completely missed the point, being based on the incorrect >> assumption >> that 5444 is used at data link layer. >> >> Abdussalam Baryun**** >> >> > RFC5444>page 4 >> > >This document specifies the syntax of a packet format designed >> > >for carrying multiple routing protocol messages for information >> exchange >> >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a >> > >Message Header, which is designed for control of message >> > >dissemination, and a Message Body, which contains protocol >> > >information. >> >> > AB>Comments> Therefore, RFC5444 is specified to messages-format for >> exchange >> > between Routers.**** >> >> That's what it was designed for. If someone wants to use it for somethin= g >> else, fine.**** >> >> >> > Secondly it mentions no MUST/SHOULD for the >> > IETF-MANET routing standards that it uses this particular message >> > format,**** >> >> That is done by RFC 5498.**** >> >> >> > otherwise we need to update all old standards that we have >> > like DSR, AODV, etc.**** >> >> Obviously 5444 doesn't demand changes to existing experimental protocols= . >> 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). >> But those earlier protocols each have their own UDP port, and 5498 does >> not apply.**** >> >> >> > Also it does not mention Data-Link >> > interaction/exchange (i.e. L2 information availability, or L2 frames' >> > formating) at all.**** >> >> Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, >> and then presented to the data link layer. 5444 relies on IP to interfac= e >> to the data link layer, as usual. >> >> I'm afraid I can't see any point made. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ************************************************************************ >> >> **** >> >> ** ** >> >> ** ** >> >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b15a61ff7029204bee8506f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't think there is any confusion. Chris has pointed out the relatio= nship between MANET interface and OLSRv2 interface clearly. I think that RF= C6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you woul= d like to change anything, please suggest concrete text to replace, so that= I can better understand what you mean.

Best regards
Ulrich

On Mon, Apr 30= , 2012 at 9:43 AM, Abdussalam Baryun <abdussalambaryun@gmail.com<= /a>> wrote:
Ok, what about OLSRv2 is it possible to= clarify the IP-interface in the definition? or is there no confusion about= MANET-interfaces with other MANET routing definitions? IMO definitions in = the MANET-WG should be very focused and consistent because if in MANET prot= ocols we define differently a commo term how will we get protocols to use i= n the future=A0common standard(s).
=A0
Abdussalam Baryun

On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Chris= topher (UK) <Chris.Dearlove@baesystems.com> wrot= e:

6130 interfaces are IP interfac= es. They may be logical, or they may directly map to physical interfaces. T= he point is that we don=92t care. As for whether 6130 is not clear, as I sa= id, it passed all those reviews and it is too late to change it, even if we= felt otherwise.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" value=3D"+441245242124" target=3D"_bla= nk">+44 1245 242124

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

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

=A0

From: man= et-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam= Baryun
Sent: 30 April 2012 17:17
To: Dearlove, Christopher (UK)Cc: manet=20


Subject: Re: [manet] DLEP mechanism used by MANET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originate= s from outside our organisation, either from an external partner or the int= ernet.
Keep th= is in mind if you answer this message.
Please see this process on ho= w to deal with suspicious emails.

Hi Chris,

=A0

I read parts quickly from RFC6130, and it does not m= ention any special IP-interface, it defines in another way:

=A0

Interface:

A router=92s attachment to a communications medium. An inter= face is

assigned one or more addresses.

MANET interface:

An interface participating in a MANET and using this neighbo= rhood

discovery prot= ocol. A router may have several MANET interfaces.

=A0AB> It d= oes not mention that it is Network-layer, so it assumes that we understand = the definition, without mentioning where this protocol can be runed. When I= read this protocol before, I thought it can be in the both L2 or L3, but i= f we define the MANET-interface as IP-intrface (as you defined it).<= u>

I read many dr= aft of IETF but this RFC6130 is not clear in definition and is not consiste= nt with others that define network-interface. I now started to beleive that= 6130-MANET-interfaces are all logical interfaces. Please read the draft ab= out IPv6 logical-interface draft below:

draft-ietf-net= ext-logical-interface-support-04.txt

=A0=

Regards=

Abdussalam Bar= yun


=A0

On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Chris

=A0

ok then if it was simple to explain as a special int= erface=A0as IP-interface why we have OLSRv2_draft saying that it is network= -interface as MANET is a network, but IP is not it is a protocol. IMO it=A0= is wrong to refer to a network while you mean a protocol, even though I kno= w I may misunderstood. I sugget that this SHOULD be explained clearly. I th= ink every one seems to understand that network-interface must include=A0Dat= a-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you = did. I thank you for your comment,

=A0

Therefore I suggest to change OLSRv2-interface defin= ition as Chris defined it very clearly. I hope the draft can=A0change the d= efinition,

=A0

Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com


Subject: Re: [manet]= DLEP mechanism used by MANET Routing

=A0

=A0

*** WARNING ***<= /p>

This message originate= s from outside our organisation, either from an external partner or the int= ernet.
Keep th= is in mind if you answer this message.
Please see this process on ho= w to deal with suspicious emails.

Hi Chris,

=A0

I am sorry to be pointless, however, I am discussing= with reference, andplease just inform me where I understood wrong so we ca= n progress. I don't think volunteering to read other peoples work and t= rying to make the best in my knowledge is pointless. I know I am less knowl= edge, but I will not stop reading and commenting, only if the chair of the = WG informs me, so please respect my work with no insults, otherwise the cha= ir should inform one of us who is pointless in our discussion under his res= ponsibility.

=A0

Please read my reply-comment to OLSRv2 below:=

=A0

> AB> OLSRv2 claims and assumes indirectly>= that OLSRv2-standard doesn't
> have to be depending on Data-Link= -layer information and in the same
> time it may use information from= Data-Link-Layer,

>There's no contradiction there. It doesn't have to be depen= dent on data
>link layer information, but it may (optional, don't= have to do it) use it.

=A0

Why does the OLSRv2 draft mention that routers must = have at least one OLSRv2-interface. The interface isData-Link layer because= all MANET-interfaces are Data-link layers, but still it stated no assumpti= on for the underlying data-link layer. I suggest to delete the word 'no= assumption' because OLSRv2-draft assumes that all routers must have at= least on OLSRv2-interface otherwise it doesn't work.

=A0

I need an explanation please. thanking you for your = comments,

=A0

Abdussalam Baryun

=A0


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).

=A0

=A0

+++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
&= gt; >This protocol makes no assumptions about the underlying
> >= ; link layer, other than support of local broadcast or multicast for
>= ; > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes suppor= t of local broadcast or multicast for communication
> to 1-hop neighb= or routers. If no such support then it is not correct.

The piece you quoted explicitly points this out (the= bit starting "other").
So your comment is incorrect.


> Also indirectl= y this protocol has not an awareness of any fault in the
> L1 wireles= s communication.

Which is exactly as it says. I don't know what y= our point is.

Abdussalam Baryun

> OLSRv2-work-in-pro= gress>p7
> >OLSRv2 makes no assumptions about the underlying li= nk layer. OLSRv2, through
> >its use of [RFC6130], may use link la= yer information and
> >notifications when available and applicable. In addition, OLSRv2> >uses link metrics that may be derived from link layer or any oth= er
> >information. OLSRv2 does not specify the physical meaning of= link
> >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modi= fication.

> AB> OLSRv2 claims and assumes indirectly> that = OLSRv2-standard doesn't
> have to be depending on Data-Link-layer information and in the same> time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't h= ave to be dependent on data
link layer information, but it may (optional= , don't have to do it) use it.


> moreover, clai= ming
> it will not need to be modified if there is change in metric o= r
> information of underlying.

Which is true, not just a claim. Note that how the m= etric is calculated is
outside OLSRv2 (read the draft).


> This claim is = only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's us= ed by the routing protocol,
which is at L3. And use of 5444 is mandatory= when using OLSRv2 as
defined by the specification. I also don't see= the connection to link metrics.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If,= hypothetically, someone created an alternative data format for OLSRv2
n= ot based on 5444, it would need to carry metrics.


> and under RFC5= 444 claims that the messages are routers'
> messaging not claimin= g that messaging are Data-Link
> messages/information/interaction. th= erefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in> Data-Link.

This has completely missed the point, being based on= the incorrect assumption
that 5444 is used at data link layer.

A= bdussalam Baryun

> RFC5444>page 4<= br>> >This document specifies the syntax of a packet format designed<= br>> >for carrying multiple routing protocol messages for =A0informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
= > >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is = specified to messages-format for exchange
> between Routers.

That's what it was designed for. If someone want= s to use it for something else, fine.


> Secondly it me= ntions no MUST/SHOULD for the
> IETF-MANET routing standards that it = uses this particular message
> format,

That is done by RFC 5498.


> otherwise we n= eed to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existin= g experimental protocols.
5498 mandates the use of 5444 on the manet UDP= port (and IP protocol).
But those earlier protocols each have their own= UDP port, and 5498 does
not apply.


> Also it does n= ot mention Data-Link
> interaction/exchange (i.e. L2 information avai= lability, or L2 frames'
> formating) at all.

Of course not. 5444 spe= cifies a format, which is encapsulated in UDP/IP,
and then presented to = the data link layer. 5444 relies on IP to interface
to the data link lay= er, as usual.

I'm afraid I can't see any point made.

--
Christopher= Dearlove
Senior Principal Engineer, Communications Group
Communicati= ons, Networks and Image Analysis Capability
BAE Systems Advanced Technol= ogy Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| = =A0Fax: +44 1245 24= 2124
chris.de= arlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) L= imited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1= 996687


*********************************************************= ***********
This email and any attachments are confidential to the intended
recipien= t and may also be privileged. If you are not the intended
recipient plea= se 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.
***************************= *****************************************

=A0

=A0

=A0

=


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


--047d7b15a61ff7029204bee8506f-- From Chris.Dearlove@baesystems.com Mon Apr 30 10:52:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E1A21E8063 for ; Mon, 30 Apr 2012 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdPJ-7U2K+ro for ; Mon, 30 Apr 2012 10:52:11 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4A93521F88B3 for ; Mon, 30 Apr 2012 10:52:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="scan'208,217";a="235161861" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 Apr 2012 18:52:08 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q3UHq8Rk023135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Apr 2012 18:52:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 18:52:07 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] DLEP mechanism used by MANET Routing Thread-Index: AQHNJGiF7hS2wiOVt0ua0yGx2ia9C5aueLyAgACdloCAAA3EgIAABkgAgAAA4wCAApChAIABVwOggAAsuICAAEFkwP//9MoAgAAJ9QCAABFRcP//9foAgAAjP5A= Date: Mon, 30 Apr 2012 17:52:07 +0000 Message-ID: References: <930FD299-129B-4591-B501-B0A8312CDF82@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0141ADGLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:52:20 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0141ADGLKXM0002VGREENLN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I indicated, the great and the good in the IESG, and everyone else has m= anaged quite successfully to know what the existing text in 6130 means. Try= ing to put anything different in OLSRv2 would be a bad idea because it migh= t suggest that an OLSRv2 interface is other than a MANET interface on which= we also run this protocol. An OLSRv2 interface is a MANET interface on whi= ch we run OLSRv2. That's it. And I think I don't have anything else to say on the matter. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 17:43 To: Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Ok, what about OLSRv2 is it possible to clarify the IP-interface in the def= inition? or is there no confusion about MANET-interfaces with other MANET r= outing definitions? IMO definitions in the MANET-WG should be very focused = and consistent because if in MANET protocols we define differently a commo = term how will we get protocols to use in the future common standard(s). Abdussalam Baryun On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Christopher (UK) > wrote: 6130 interfaces are IP interfaces. They may be logical, or they may directl= y map to physical interfaces. The point is that we don't care. As for wheth= er 6130 is not clear, as I said, it passed all those reviews and it is too = late to change it, even if we felt otherwise. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Bar= yun Sent: 30 April 2012 17:17 To: Dearlove, Christopher (UK) Cc: manet Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I read parts quickly from RFC6130, and it does not mention any special IP-i= nterface, it defines in another way: Interface: A router's attachment to a communications medium. An interface is assigned one or more addresses. MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. AB> It does not mention that it is Network-layer, so it assumes that we un= derstand the definition, without mentioning where this protocol can be rune= d. When I read this protocol before, I thought it can be in the both L2 or = L3, but if we define the MANET-interface as IP-intrface (as you defined it)= . I read many draft of IETF but this RFC6130 is not clear in definition and i= s not consistent with others that define network-interface. I now started t= o beleive that 6130-MANET-interfaces are all logical interfaces. Please rea= d the draft about IPv6 logical-interface draft below: draft-ietf-netext-logical-interface-support-04.txt Regards Abdussalam Baryun On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun > wrote: Hi Chris ok then if it was simple to explain as a special interface as IP-interface = why we have OLSRv2_draft saying that it is network-interface as MANET is a = network, but IP is not it is a protocol. IMO it is wrong to refer to a netw= ork while you mean a protocol, even though I know I may misunderstood. I su= gget that this SHOULD be explained clearly. I think every one seems to unde= rstand that network-interface must include Data-Link-layer, therefore, RFC6= 130 or OLSRv2-draft should define well as you did. I thank you for your com= ment, Therefore I suggest to change OLSRv2-interface definition as Chris defined = it very clearly. I hope the draft can change the definition, Abdussalam On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) > wrote: An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is = an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn't care about = that. Your statement "a MANET interface is a data link interface" is wrong. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 30 April 2012 13:27 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com Subject: Re: [manet] DLEP mechanism used by MANET Routing *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. Hi Chris, I am sorry to be pointless, however, I am discussing with reference, andple= ase just inform me where I understood wrong so we can progress. I don't thi= nk volunteering to read other peoples work and trying to make the best in m= y knowledge is pointless. I know I am less knowledge, but I will not stop r= eading and commenting, only if the chair of the WG informs me, so please re= spect my work with no insults, otherwise the chair should inform one of us = who is pointless in our discussion under his responsibility. Please read my reply-comment to OLSRv2 below: > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, >There's no contradiction there. It doesn't have to be dependent on data >link layer information, but it may (optional, don't have to do it) use it. Why does the OLSRv2 draft mention that routers must have at least one OLSRv= 2-interface. The interface isData-Link layer because all MANET-interfaces a= re Data-link layers, but still it stated no assumption for the underlying d= ata-link layer. I suggest to delete the word 'no assumption' because OLSRv2= -draft assumes that all routers must have at least on OLSRv2-interface othe= rwise it doesn't work. I need an explanation please. thanking you for your comments, Abdussalam Baryun > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) > wrote: Abdussalam Baryun > RFC6130>p5 > >This protocol makes no assumptions about the underlying > > link layer, other than support of local broadcast or multicast for > > communication > > to 1-hop neighbor routers. > AB> NHDP assumes support of local broadcast or multicast for communicatio= n > to 1-hop neighbor routers. If no such support then it is not correct. The piece you quoted explicitly points this out (the bit starting "other"). So your comment is incorrect. > Also indirectly this protocol has not an awareness of any fault in the > L1 wireless communication. Which is exactly as it says. I don't know what your point is. Abdussalam Baryun > OLSRv2-work-in-progress>p7 > >OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, thr= ough > >its use of [RFC6130], may use link layer information and > >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other > >information. OLSRv2 does not specify the physical meaning of link > >metrics, but specifies a means by which new types of link metrics may > >be specified in the future, but used by OLSRv2 without modification. > AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard doesn't > have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer, There's no contradiction there. It doesn't have to be dependent on data link layer information, but it may (optional, don't have to do it) use it. > moreover, claiming > it will not need to be modified if there is change in metric or > information of underlying. Which is true, not just a claim. Note that how the metric is calculated is outside OLSRv2 (read the draft). > This claim is only true if the Data-Link is > using RFC5444, First 5444 is not used by the data link, it's used by the routing protocol, which is at L3. And use of 5444 is mandatory when using OLSRv2 as defined by the specification. I also don't see the connection to link metri= cs. OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them. If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics. > and under RFC5444 claims that the messages are routers' > messaging not claiming that messaging are Data-Link > messages/information/interaction. therefore OLSRv2 assumes that > Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link. This has completely missed the point, being based on the incorrect assumpti= on that 5444 is used at data link layer. Abdussalam Baryun > RFC5444>page 4 > >This document specifies the syntax of a packet format designed > >for carrying multiple routing protocol messages for information exchang= e >> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a > >Message Header, which is designed for control of message > >dissemination, and a Message Body, which contains protocol > >information. > AB>Comments> Therefore, RFC5444 is specified to messages-format for excha= nge > between Routers. That's what it was designed for. If someone wants to use it for something e= lse, fine. > Secondly it mentions no MUST/SHOULD for the > IETF-MANET routing standards that it uses this particular message > format, That is done by RFC 5498. > otherwise we need to update all old standards that we have > like DSR, AODV, etc. Obviously 5444 doesn't demand changes to existing experimental protocols. 5498 mandates the use of 5444 on the manet UDP port (and IP protocol). But those earlier protocols each have their own UDP port, and 5498 does not apply. > Also it does not mention Data-Link > interaction/exchange (i.e. L2 information availability, or L2 frames' > formating) at all. Of course not. 5444 specifies a format, which is encapsulated in UDP/IP, and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual. I'm afraid I can't see any point made. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0141ADGLKXM0002VGREENLN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I indicated, the great= and the good in the IESG, and everyone else has managed quite successfully= to know what the existing text in 6130 means. Trying to put anything different in OLSRv2 would be a bad idea because it might sugg= est that an OLSRv2 interface is other than a MANET interface on which we al= so run this protocol. An OLSRv2 interface is a MANET interface on which we = run OLSRv2. That’s it.

 <= /p>

And I think I don’t= have anything else to say on the matter.

 <= /p>

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

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

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 17:43
To: Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Ok, what about OLSRv2 is it possible to clarify the = IP-interface in the definition? or is there no confusion about MANET-interf= aces with other MANET routing definitions? IMO definitions in the MANET-WG = should be very focused and consistent because if in MANET protocols we define differently a commo term how will = we get protocols to use in the future common standard(s).

 

Abdussalam Baryun

On Mon, Apr 30, 2012 at 5:22 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove@baesystems.com> wrote:

6130 interfaces are IP interfaces. They= may be logical, or they may directly map to physical interfaces. The point is that we don’t care. As for whether 6130 is not clear, a= s I said, it passed all those reviews and it is too late to change it, even= if we felt otherwise.

 

--

Christopher Dearlove<= /p>

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

chris.dearlove@baesystems.com | http://www.baes= ystems.com

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

 

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 30 April 2012 17:17
To: Dearlove, Christopher (UK)
Cc: manet


Subject: Re: [manet] DLEP mechanism used by MANET Routing=

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I read parts quickly from RFC6130, and it does not mention any spe= cial IP-interface, it defines in another way:

 

Interface:

A router’s attachment to a communications medium. An interface i= s

assigned one or more addresses.

MANET interface:

An interface participating in a MANET and using this neighborhood

disc= overy protocol. A router may have several MANET interfaces.

&nbs= p;AB> It does not mention that it is Network-layer, so it assumes that w= e understand the definition, without mentioning where this protocol can be = runed. When I read this protocol before, I thought it can be in the both L2 or L3, but if we define the MANET-interface as IP-intrface (as= you defined it).

I re= ad many draft of IETF but this RFC6130 is not clear in definition and is no= t consistent with others that define network-interface. I now started to be= leive that 6130-MANET-interfaces are all logical interfaces. Please read the draft about IPv6 logical-interface draft below:

draf= t-ietf-netext-logical-interface-support-04.txt

 

Rega= rds

Abdu= ssalam Baryun


 

On Mon, Apr 30, 2012 at 4:41 PM, Abdussalam Baryun <abdussalambaryun@gmail= .com> wrote:

Hi Chris

 

ok then if it was simple to explain as a special interface as= IP-interface why we have OLSRv2_draft saying that it is network-interface = as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a pr= otocol, even though I know I may misunderstood. I sugget that this SHOULD b= e explained clearly. I think every one seems to understand that network-int= erface must include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you did. I thank = you for your comment,

 

Therefore I suggest to change OLSRv2-interface definition as Chris= defined it very clearly. I hope the draft can change the definition,<= o:p>

 

Abdussalam

On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) <Chris.Dear= love@baesystems.com> wrote:

An OLSRv2 interface (a special case of = a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data li= nk layer below it, but OLSRv2 doesn’t care about that. Your statement= “a MANET interface is a data link interface” is wrong.<= o:p>

 

--

Christopher Dearlove<= /p>

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

chris.dearlove@baesystems.com | http://www.baes= ystems.com

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

 

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 30 April 2012 13:27
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; manet; Bo Berry; sratliff@cisco.com


Subject: Re: [manet] DLEP mechanism used by MANET Routing

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

Hi Chris,

 

I am sorry to be pointless, however, I am discussing with referenc= e, andplease just inform me where I understood wrong so we can progress. I = don't think volunteering to read other peoples work and trying to make the best in my knowledge is pointless. I k= now I am less knowledge, but I will not stop reading and commenting, only i= f the chair of the WG informs me, so please respect my work with no insults= , otherwise the chair should inform one of us who is pointless in our discussion under his responsibility.

 

Please read my reply-comment to OLSRv2 below:

 

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-s= tandard doesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

>There's no contradiction there. It doesn't have to be dependent on data=
>link layer information, but it may (optional, don't have to do it) use = it.

 

Why does the OLSRv2 draft mention that routers must have at least = one OLSRv2-interface. The interface isData-Link layer because all MANET-int= erfaces are Data-link layers, but still it stated no assumption for the underlying data-link layer. I suggest to d= elete the word 'no assumption' because OLSRv2-draft assumes that all router= s must have at least on OLSRv2-interface otherwise it doesn't work.

 

I need an explanation please. thanking you for your comments,=

 

Abdussalam Baryun

 


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).

 

 

++++++++++++++&#= 43;++++++++++++++&#= 43;++++++++++++++&#= 43;+++++++++++++

On Mon, Apr 30, 2012 at 10:06 AM, Dearlove, Christopher (UK) <<= a href=3D"mailto:Chris.Dearlove@baesystems.com" target=3D"_blank">Chris.Dea= rlove@baesystems.com> wrote:

Abdussalam Baryun

> RFC6130>p5
> >This protocol makes no assumptions about the underlying
> > link layer, other than support of local broadcast or multicast fo= r
> > communication
> > to 1-hop neighbor routers.

> AB> NHDP assumes support of local broadcast or multicast for commun= ication
> to 1-hop neighbor routers. If no such support then it is not correct.<= o:p>

The piece you quoted explicitly points this out (the bit starting = "other").
So your comment is incorrect.


> Also indirectly this protocol has not an awareness of any fault in the=
> L1 wireless communication.

Which is exactly as it says. I don't know what your point is.

Abdussalam Baryun

> OLSRv2-work-in-progress>p7
> >OLSRv2 makes no assumptions about the underlying link layer. OLSRv= 2, through
> >its use of [RFC6130], may use link layer information and
> >notifications when available and applicable. In addition, OLSRv2 > >uses link metrics that may be derived from link layer or any other=
> >information. OLSRv2 does not specify the physical meaning of link<= br> > >metrics, but specifies a means by which new types of link metrics = may
> >be specified in the future, but used by OLSRv2 without modificatio= n.

> AB> OLSRv2 claims and assumes indirectly> that OLSRv2-standard d= oesn't
> have to be depending on Data-Link-layer information and in the same > time it may use information from Data-Link-Layer,

There's no contradiction there. It doesn't have to be dependent on= data
link layer information, but it may (optional, don't have to do it) use it.<= o:p>


> moreover, claiming
> it will not need to be modified if there is change in metric or
> information of underlying.

Which is true, not just a claim. Note that how the metric is calcu= lated is
outside OLSRv2 (read the draft).


> This claim is only true if the Data-Link is
> using RFC5444,

First 5444 is not used by the data link, it's used by the routing = protocol,
which is at L3. And use of 5444 is mandatory when using OLSRv2 as
defined by the specification. I also don't see the connection to link metri= cs.
OLSRv2 uses them, and specifies 5444-compliant TLVs to provide them.
If, hypothetically, someone created an alternative data format for OLSRv2 not based on 5444, it would need to carry metrics.


> and under RFC5444 claims that the messages are routers'
> messaging not claiming that messaging are Data-Link
> messages/information/interaction. therefore OLSRv2 assumes that
> Data-Link layer MUST RFC5444, so that it can use the information in > Data-Link.

This has completely missed the point, being based on the incorrect= assumption
that 5444 is used at data link layer.

Abdussalam Baryun

> RFC5444>page 4
> >This document specifies the syntax of a packet format designed
> >for carrying multiple routing protocol messages for  informat= ion exchange
>> between MANET (Mobile Ad hoc NETwork) routers. Messages consist of= a
> >Message Header, which is designed for control of message
> >dissemination, and a Message Body, which contains protocol
> >information.

> AB>Comments> Therefore, RFC5444 is specified to messages-format = for exchange
> between Routers.

That's what it was designed for. If someone wants to use it for so= mething else, fine.


> Secondly it mentions no MUST/SHOULD for the
> IETF-MANET routing standards that it uses this particular message
> format,

That is done by RFC 5498.


> otherwise we need to update all old standards that we have
> like DSR, AODV, etc.

Obviously 5444 doesn't demand changes to existing experimental pro= tocols.
5498 mandates the use of 5444 on the manet UDP port (and IP protocol).
But those earlier protocols each have their own UDP port, and 5498 does
not apply.


> Also it does not mention Data-Link
> interaction/exchange (i.e. L2 information availability, or L2 frames'<= br> > formating) at all.

Of course not. 5444 specifies a format, which is encapsulated in UDP/IP,=
and then presented to the data link layer. 5444 relies on IP to interface to the data link layer, as usual.

I'm afraid I can't see any point made.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 2= 42194 |  Fax: +44 1245 242124=
chris.de= arlove@baesystems.com | http://www.baesyst= ems.com

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


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

 

 

 

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D0141ADGLKXM0002VGREENLN_-- From rajendradhoni2@gmail.com Mon Apr 30 11:36:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CED21F8914 for ; Mon, 30 Apr 2012 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, DEAR_SOMETHING=1.605, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys35YBslHp9i for ; Mon, 30 Apr 2012 11:36:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EECE21F8912 for ; Mon, 30 Apr 2012 11:36:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so496883wgb.13 for ; Mon, 30 Apr 2012 11:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bcQiDZK4Sr/nh7ZBtaKHpPBFm5gQyH0D8xjOALhJIYE=; b=GUNe3q2ATpfoJ3C8lzOYTvL3WJVLxXANIPIkLusPm7MnG5bIRfbY5G/b4HRF3sQd1r g0Tprh4QEDC2Sa1UM6T7ZrB7PbtzUR2Zg7vAts9nBS9jqjiTqslf3TDJ3RNEWCZrZA0Y 8AqwRJiDcTjsFL6X/EIdSU4SEDWn9yP2rijwuosLuN4EBXfh0SSi5Kfa6q519owok4yl SPc1hBOe8wmcdteVTMeECFFC92CYcHk494uExh5FjOMwMlGmM7qdAVyvZNDnjcS0AxKZ OVF57I/fVPBLVX6uoE7H9dY5xMu36ntdpM51pd8UwPyI8QFD+efIOMafrAiACpLPt9lX 9M7A== MIME-Version: 1.0 Received: by 10.180.86.132 with SMTP id p4mr31241180wiz.15.1335811005445; Mon, 30 Apr 2012 11:36:45 -0700 (PDT) Received: by 10.180.145.167 with HTTP; Mon, 30 Apr 2012 11:36:45 -0700 (PDT) Date: Tue, 1 May 2012 00:06:45 +0530 Message-ID: From: Rajendra Dhoni To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] urgent help X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 18:36:47 -0000 Dear Sir, I am M.tech student of IT branch with dissertation topic performance comparision of AODV and SAODV in presence of blackhole attack. I have been unable to locate tcl scripts of SAODV and blackhole implementation for ns2. please help me and guide me for completion of my dissertation. and please send me TCL script Thanking you in advance. From abdussalambaryun@gmail.com Mon Apr 30 14:10:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3121F84D1 for ; Mon, 30 Apr 2012 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH+mbXfOMO68 for ; Mon, 30 Apr 2012 14:10:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 951D621F84B9 for ; Mon, 30 Apr 2012 14:10:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2811645vcb.31 for ; Mon, 30 Apr 2012 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=enVGiIURiEZyhgMh1Eig/eO7xXKIvt1Gipf4CZjjmPY=; b=jutIvWZ2ES11lZ28Y5W3YA3a8hS6C8+P9FMD0uKK3jrI2YF578tVtD9Sk2vsYhHDv7 t74nrVUbDsDFmgkutbYQSUBSsFSs1N5U3ekt/zbt6bHZdWgXcMDVkeZkWoVhDDzA801d hUBvT6YJft4jU+eEWiBSXa0VrshdufCGYQ+3ASIKrNjbbwPJ0eXtltsXHkrVMSRUEaNO 4CbQG3pNenQPRkjohSjyrgn4wod2Fo659ZGduKI54JUQAUGzih7e5cMFdVpFtXUdteta JOjBDM98A681UpJovxlvb1E9Y2e6YYLBpZlOjTyMgneg/RXIsjSsXMqTTDrhLvWnemUB CbLQ== MIME-Version: 1.0 Received: by 10.52.68.77 with SMTP id u13mr8069848vdt.81.1335820223999; Mon, 30 Apr 2012 14:10:23 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Mon, 30 Apr 2012 14:10:23 -0700 (PDT) Date: Mon, 30 Apr 2012 22:10:23 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg , manet Content-Type: multipart/alternative; boundary=20cf307d022cef6d5404beebe10d Cc: "Dearlove, Christopher \(UK\)" Subject: [manet] Comments for OLSRv2-14 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:10:26 -0000 --20cf307d022cef6d5404beebe10d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Herberg, I am suggesting to clarify interfaces, I donot like to change if unnecessary. Mentioning that an interface is in the layer 3, or its logical, or even just explaining the way Chris defined to me, really makes difference. My question is why is the draft not mentioning that OLSRv2-interface is an IP-interface or a logical-interface? Does the authors see that this information is not important? or even MANET-interfaces are in layer 3. If we define protocols without mentioning which layer it is located in, then how can we define such protocol, its layer-location is more important than its functionality, because each layer has its special interfaces, functions, services, and messages. There are many documents that explain interface in the same model that OLSRv2 is presenting so why didn't have confusion when I read them? >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t >car= e about that. Your statement =93a MANET interface is a data link interface=94= is wrong. >I don't think there is any confusion. Chris has pointed out the relationship between MANET interface and OLSRv2 >interface clearly. I think that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would like to >change anything, please suggest concrete text to replace, so that I can better understand what you mean. I disagree that there is no confusion. There are confusions in defining terms in MANET WG, I have seen in the past a long discussion between many, just arguing about defining host or router, and now l was confused of interfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or reading about network-interface in many papers, and I read RFC2501 (it refers alot to wireless interface and communications) and mentioned in RFC6130 for the interface as attach to communication medium, I thought it was a medium as physical medium. I suggest to clarify by adding information in one of the following explanation to the draft (even a line will do): - Mentioning which layer(s) the OLSRv2-interface works or allowed to be at by the protocol, or - defining the MANET-interface as Chris defined (IP-interface, at layer 3) in terminology, or - mentioning that OLSRv2-interface is not a wireless interface, or - defining MANET-interface as logical interface. I am sorry to disturb, I actually still have many comments for OLSRv2-draft and will try to submit, and let the WG to decide. However, I thank you and Chris to explain to me so at least my other comments will be in understanding. Abdussalam ++++++++++++++++++ On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wrote= : > Abdussalam, > > RFC6130 defines: > > > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces. > > And draft-ietf-manet-olsrv2 defines: > > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface. > > In one of the last OLSRv2 revisions, we made sure that OLSRv2 > differentiates between neighbors running only NHDP and neighbors running > also OLSRv2, and only the latter are used for MPR selection, etc. I do no= t > understand what you would like to change in the OLSRv2 draft. > > See comments below: > > On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Henning, >> >> Please note that I read the first pages of draft many times before >> posting any information. >> >> HR>I would suggest reading the OLSRv2-draft again, especially section 2. >> >> >> >OLSRv2 interface: >> >A MANET interface running this protocol. A router running this >> >protocol MUST have at least one OLSRv2 interface. >> >> HR>A routing protocol which does not run on any interface would be prett= y >> >useless, right? >> You reply to the second sentence not the first which has 'running this >> protocol' relating it not to the router it is relating it to the interfa= ce. >> I know that router must have at least a network-interface ( or >> data-link-layer) or MANET interface, this is not what I commenting and t= he >> draft is mentioning. We don't assume at least Data-Link because it is >> obvious and we are following TCP/IP model in the internet, but not at le= ast >> a specific-interface called bla bla. >> >> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS thi= s >> protocol (OLSRv2) this means there is some thing related to OLSRv2 in th= e >> layer-2. You should read again another paragraph mentioning as if there = is >> difference between MANET-interface and OLSRv2-interface. >> >> OLSRv2-14>p9> >> >> Supports routers that each have one or more participating OLSRv2 >> >> interfaces, which will consist of some or all of its MANET >> >> interfaces using [RFC6130]. The set of a router=92s OLSRv2 >> >> interfaces, and the sets of its other MANET and non-MANET >> >> interfaces, may change over time. Each interface may have one or >> >> more network addresses (which may have prefix lengths), and these >> >> may also be dynamically changing. >> >> AB> it is clear from the above draft-page-9, that all MANET >> interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are >> MANET-interfaces. So we have to have in or node at least an >> OLSRv2-interface, not at least one MANET-interfac so the protocol to wor= k >> correctly. >> >> AB> The above page-9 mentions NHDP as well that interfaces need this >> protocol. What if there is not NHDP, or if it is not working, what will >> happen. The draft SHOULD explain these issues. >> > > > >> AB> It may be that all OLSRv2 routers (as implementation point of >> practice) only need at least one MANET interface. But the authors need t= o >> change. therefore, we know that All routers need at least on interface, = but >> the draft-wording has a special OLSRv2-interface. Then we need to change >> the draft wording to the right explaination. >> > > > Can you suggest what you would like to change? I don't understand your > point. > > Best regards > Ulrich > +++++++++++++++++++++++++++++++++++++++++++ > Hi Chris ok then if it was simple to explain as a special interface as IP-interface why we have OLSRv2_draft saying that it is network-interface as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that this SHOULD be explained clearly. I think every one seems to understand that network-interface must include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you did. I thank you for your comment, Therefore I suggest to change OLSRv2-interface definition as Chris defined it very clearly. I hope the draft can change the definition, Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) wrote: An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MANET interface is a data link interface=94= is wrong. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove at baesystems.com | http://www.baesystems.com --20cf307d022cef6d5404beebe10d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Herberg,
=A0
I am suggesting to clarify interfaces, I d= onot like=A0to change=A0if unnecessary. Mentioning that an interface is in = the layer 3, or its logical, or even just explaining the way Chris defined = to me, really makes difference. My question is why is the draft not mention= ing that OLSRv2-interface is an IP-interface or a logical-interface? Does t= he authors see that this information is not important? or even MANET-interf= aces are in layer 3.=A0 If we define protocols without mentioning which lay= er it is located in, then how can we define such protocol, its layer-locati= on is more important than its functionality, because each layer has its spe= cial interfaces, functions, services, and messages. There are many documen= ts that explain interface in the same model that=20 OLSRv2 is presenting so why didn't have confusion when I read them?
>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more IP= =20 addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20 >care about that. Your statement =93a MANET interface is a data link=20 interface=94 is wrong.

>I don't think there is any con= fusion. Chris has pointed out the=20 relationship between MANET interface and OLSRv2 >interface clearly. I=20 think that RFC6130/draft-ietf-manet-olsrv2 define the terminology=20 correctly. If you would like to >change anything, please suggest concret= e text to replace, so that I can better understand what you mean.

I d= isagree that there is no confusion. There are confusions in defining terms = in MANET WG, I have seen in the past a long discussion between many, just a= rguing about defining host or router, and now l was confused of interfaces = in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or reading= about network-interface in many papers, and I read RFC2501 (it refers alot= to wireless interface and communications) and mentioned in RFC6130 for the= interface as attach to communication medium, I thought it was a medium as = physical medium.

I suggest to clarify by adding information in one of the following expl= anation to the draft (even a line will do):
=A0
- Mentioning which layer(s)=A0the OLSRv2-interface works or allowed to= be at by the protocol, or
- defining the MANET-interface as=A0Chris defined (IP-interface, at la= yer 3) in terminology, or
- mentioning that OLSRv2-interface is not a wireless interface, or
- defining MANET-interface as logical interface.

I am sorry to disturb, I actually still have many comments for OLS= Rv2-draft and will try to submit, and let the WG to decide. However, I than= k you and Chris to explain to me so at least my other comments will be in u= nderstanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 defines:= =20


MANET interface:
An interface participating in a MANET and = using this neighborhood
=A0=A0=A0=A0=A0 discovery protocol.=A0 A router = may have several MANET interfaces.

And draft-ietf-manet-olsrv2= defines:=20

OLSRv2 interface:
=A0=A0=A0=A0=A0 A MANET interface running thi= s protocol.=A0 A router running this
=A0=A0=A0=A0=A0 protocol MUST have = at least one OLSRv2 interface.

In one of the last OLSRv2 revis= ions, we made sure that OLSRv2 differentiates between neighbors running onl= y NHDP and neighbors running also OLSRv2, and only the latter are used for = MPR selection, etc. I do not understand what you would like to change in th= e OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.=20


>OLSRv2 interface:
>A MANET interface running this pr= otocol. =A0A router running this
>protocol MUST have at least one OLS= Rv2 interface.

HR>A routing protocol which does not run on = any interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.


=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.


Can you suggest what you would like to change? I don't und= erstand your point.

Best regards
Ul= rich
=A0+++++++++++++++++++++++++++++++++++++++++++


Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as=20 IP-interface why we have OLSRv2_draft saying that it is=20 network-interface as MANET is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer to a network while you mean a protocol, even=20 though I know I may misunderstood. I sugget that this SHOULD be=20 explained clearly. I think every one seems to understand that=20 network-interface must include=A0Data-Link-layer, therefore, RFC6130 or=20 OLSRv2-draft should define well as you did. I thank you for your=20 comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris=20 defined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) <Chris.Dearlove at baesystems.com> wr= ote:


An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP=20 addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20 care about that. Your statement =93a MANET interface is a data link=20 interface=94 is wrong.

=A0

--

Christopher Dearlove

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194<= /a>=A0|=A0 Fax: +44 1245 242124

chris.dearlove at baesystems.com | http://www.baesys= tems.com


--20cf307d022cef6d5404beebe10d-- From ulrich@herberg.name Mon Apr 30 14:29:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA821E8083 for ; Mon, 30 Apr 2012 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27nRmHO0YzK7 for ; Mon, 30 Apr 2012 14:28:59 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id EA25121E8094 for ; Mon, 30 Apr 2012 14:28:56 -0700 (PDT) Received: by dady13 with SMTP id y13so6122169dad.27 for ; Mon, 30 Apr 2012 14:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=umpusw9HJfTj7QfYXZk/zcWNxaXDWIWpukBzM5M3ONA=; b=nOf/uIPXu3HW3TpfU88EGtoJ/KxiK8L3J3Hjn//dkIYKVV86kCYFn9aORwIFc5UFbY 5Iz42LCgFr/NK7eNo1U3iM7YyDR1v9WsAsvYLLs5j44S/vwXSMo00BmiHbCMSkzNA/D2 qJeHcAqKtnozBA4+tMiHglwQ0bY1y1RoY5gw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=umpusw9HJfTj7QfYXZk/zcWNxaXDWIWpukBzM5M3ONA=; b=NETsml2NVRvqIhTlnse9N2unN0d+1r+ZpDpfq3Z4xW7ohJTi6p56J/fNMoHG+6IVal Yhn+0AJ3voZ8/+0+wm2C/gXdoq5mqcILF/aRdAbYCzushBnVsNlTmnxVIFWdpZ2Uqf1f y+YzJZ9ZPwTCtGGCgcnDGwErC2tMqiQsFU2faCZn1NRvjizFREyFr66X1GDx1k+s+zA+ NZzEj7y1oc4tpRsYfQDm8wjj0Vyqqr4mqAQ+Xc4izcvafwDKeIoFiVlL6gvVvrya6uCI yztikMVtXq4zjqNVQEjQNqyTwU6DjUuMnRUQeJURuV7LI/2/eXWJdrwPDPVEuzq6cusl tK5A== MIME-Version: 1.0 Received: by 10.68.220.2 with SMTP id ps2mr52491275pbc.109.1335821336713; Mon, 30 Apr 2012 14:28:56 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Mon, 30 Apr 2012 14:28:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Apr 2012 14:28:56 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b2ee19942184e04beec2474 X-Gm-Message-State: ALoCoQkNqgktT6+CLNuGuZ1wNJHLLVC/+0uTCkFBEuqdW95CN+Eio4K8gm5sy6kFIiVtRIDlS4dU Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:29:00 -0000 --047d7b2ee19942184e04beec2474 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam, so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). IMO, unless other people in the WG see the same danger of confusion, I would not change it. Regards Ulrich On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Herberg, > > I am suggesting to clarify interfaces, I donot like to change if > unnecessary. Mentioning that an interface is in the layer 3, or its > logical, or even just explaining the way Chris defined to me, really make= s > difference. My question is why is the draft not mentioning that > OLSRv2-interface is an IP-interface or a logical-interface? Does the > authors see that this information is not important? or even > MANET-interfaces are in layer 3. If we define protocols without mentioni= ng > which layer it is located in, then how can we define such protocol, its > layer-location is more important than its functionality, because each lay= er > has its special interfaces, functions, services, and messages. There are > many documents that explain interface in the same model that OLSRv2 is > presenting so why didn't have confusion when I read them? > > >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) > is an IP interface, one which IP >receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t >c= are > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong. > > >I don't think there is any confusion. Chris has pointed out the > relationship between MANET interface and OLSRv2 >interface clearly. I thi= nk > that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If > you would like to >change anything, please suggest concrete text to > replace, so that I can better understand what you mean. > > I disagree that there is no confusion. There are confusions in defining > terms in MANET WG, I have seen in the past a long discussion between many= , > just arguing about defining host or router, and now l was confused of > interfaces in OLSRv2-draft. Maybe because I am not much familiar with OLS= R, > or reading about network-interface in many papers, and I read RFC2501 (it > refers alot to wireless interface and communications) and mentioned in > RFC6130 for the interface as attach to communication medium, I thought it > was a medium as physical medium. > > I suggest to clarify by adding information in one of the following > explanation to the draft (even a line will do): > > - Mentioning which layer(s) the OLSRv2-interface works or allowed to be a= t > by the protocol, or > - defining the MANET-interface as Chris defined (IP-interface, at layer 3= ) > in terminology, or > - mentioning that OLSRv2-interface is not a wireless interface, or > - defining MANET-interface as logical interface. > > I am sorry to disturb, I actually still have many comments for > OLSRv2-draft and will try to submit, and let the WG to decide. However, I > thank you and Chris to explain to me so at least my other comments will b= e > in understanding. > > Abdussalam > ++++++++++++++++++ > > On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wro= te: > >> Abdussalam, >> >> RFC6130 defines: >> >> >> MANET interface: >> An interface participating in a MANET and using this neighborhood >> discovery protocol. A router may have several MANET interfaces. >> >> And draft-ietf-manet-olsrv2 defines: >> >> OLSRv2 interface: >> A MANET interface running this protocol. A router running this >> protocol MUST have at least one OLSRv2 interface. >> >> In one of the last OLSRv2 revisions, we made sure that OLSRv2 >> differentiates between neighbors running only NHDP and neighbors running >> also OLSRv2, and only the latter are used for MPR selection, etc. I do n= ot >> understand what you would like to change in the OLSRv2 draft. >> >> See comments below: >> >> On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >> >>> Hi Henning, >>> >>> Please note that I read the first pages of draft many times before >>> posting any information. >>> >>> HR>I would suggest reading the OLSRv2-draft again, especially section 2= . >>> >>> >>> >OLSRv2 interface: >>> >A MANET interface running this protocol. A router running this >>> >protocol MUST have at least one OLSRv2 interface. >>> >>> HR>A routing protocol which does not run on any interface would be pret= ty >>> >useless, right? >>> You reply to the second sentence not the first which has 'running this >>> protocol' relating it not to the router it is relating it to the interf= ace. >>> I know that router must have at least a network-interface ( or >>> data-link-layer) or MANET interface, this is not what I commenting and = the >>> draft is mentioning. We don't assume at least Data-Link because it is >>> obvious and we are following TCP/IP model in the internet, but not at l= east >>> a specific-interface called bla bla. >>> >>> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS >>> this protocol (OLSRv2) this means there is some thing related to OLSRv2= in >>> the layer-2. You should read again another paragraph mentioning as if t= here >>> is difference between MANET-interface and OLSRv2-interface. >>> >>> OLSRv2-14>p9> >>> >>> Supports routers that each have one or more participating OLSRv2 >>> >>> interfaces, which will consist of some or all of its MANET >>> >>> interfaces using [RFC6130]. The set of a router=92s OLSRv2 >>> >>> interfaces, and the sets of its other MANET and non-MANET >>> >>> interfaces, may change over time. Each interface may have one or >>> >>> more network addresses (which may have prefix lengths), and these >>> >>> may also be dynamically changing. >>> >>> AB> it is clear from the above draft-page-9, that all MANET >>> interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are >>> MANET-interfaces. So we have to have in or node at least an >>> OLSRv2-interface, not at least one MANET-interfac so the protocol to wo= rk >>> correctly. >>> >>> AB> The above page-9 mentions NHDP as well that interfaces need this >>> protocol. What if there is not NHDP, or if it is not working, what will >>> happen. The draft SHOULD explain these issues. >>> >> >> >> >>> AB> It may be that all OLSRv2 routers (as implementation point of >>> practice) only need at least one MANET interface. But the authors need = to >>> change. therefore, we know that All routers need at least on interface,= but >>> the draft-wording has a special OLSRv2-interface. Then we need to chang= e >>> the draft wording to the right explaination. >>> >> >> >> Can you suggest what you would like to change? I don't understand your >> point. >> >> Best regards >> Ulrich >> +++++++++++++++++++++++++++++++++++++++++++ >> > > > Hi Chris > > ok then if it was simple to explain as a special interface as IP-interfac= e > why we have OLSRv2_draft saying that it is network-interface as MANET is = a > network, but IP is not it is a protocol. IMO it is wrong to refer to a > network while you mean a protocol, even though I know I may misunderstood= . > I sugget that this SHOULD be explained clearly. I think every one seems t= o > understand that network-interface must include Data-Link-layer, therefore= , > RFC6130 or OLSRv2-draft should define well as you did. I thank you for yo= ur > comment, > > Therefore I suggest to change OLSRv2-interface definition as Chris define= d > it very clearly. I hope the draft can change the definition, > > Abdussalam > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) at baesystems.com> wrote: > > > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s > an IP interface, one which IP receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t ca= re > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove at baesystems.com | http://www.baesystems.com > > > --047d7b2ee19942184e04beec2474 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam,

so far, nobody else seemed to be confused on which layer= OLSRv2 is used (or how the interfaces are defined). IMO, unless other peop= le in the WG see the same danger of confusion, I would not change it.

Regards
Ulrich

On Mon, Apr 30, 201= 2 at 2:10 PM, Abdussalam Baryun <abdussalambaryun@gmail.com&g= t; wrote:
Hi Herberg,
=A0
I am suggesting to clarify interfaces, I d= onot like=A0to change=A0if unnecessary. Mentioning that an interface is in = the layer 3, or its logical, or even just explaining the way Chris defined = to me, really makes difference. My question is why is the draft not mention= ing that OLSRv2-interface is an IP-interface or a logical-interface? Does t= he authors see that this information is not important? or even MANET-interf= aces are in layer 3.=A0 If we define protocols without mentioning which lay= er it is located in, then how can we define such protocol, its layer-locati= on is more important than its functionality, because each layer has its spe= cial interfaces, functions, services, and messages. There are many documen= ts that explain interface in the same model that=20 OLSRv2 is presenting so why didn't have confusion when I read them?
>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more IP= =20 addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20 >care about that. Your statement =93a MANET interface is a data link=20 interface=94 is wrong.

>I don't think there is any con= fusion. Chris has pointed out the=20 relationship between MANET interface and OLSRv2 >interface clearly. I=20 think that RFC6130/draft-ietf-manet-olsrv2 define the terminology=20 correctly. If you would like to >change anything, please suggest concret= e text to replace, so that I can better understand what you mean.

I d= isagree that there is no confusion. There are confusions in defining terms = in MANET WG, I have seen in the past a long discussion between many, just a= rguing about defining host or router, and now l was confused of interfaces = in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or reading= about network-interface in many papers, and I read RFC2501 (it refers alot= to wireless interface and communications) and mentioned in RFC6130 for the= interface as attach to communication medium, I thought it was a medium as = physical medium.

I suggest to clarify by adding information in one of the following expl= anation to the draft (even a line will do):
=A0
- Mentioning which layer(s)=A0the OLSRv2-interface works or allowed to= be at by the protocol, or
- defining the MANET-interface as=A0Chris defined (IP-interface, at la= yer 3) in terminology, or
- mentioning that OLSRv2-interface is not a wireless interface, or
- defining MANET-interface as logical interface.

I am sorry to disturb, I actually still have many comments for OLS= Rv2-draft and will try to submit, and let the WG to decide. However, I than= k you and Chris to explain to me so at least my other comments will be in u= nderstanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 defines:= =20


MANET interface:
An interface participating in a MANET and = using this neighborhood
=A0=A0=A0=A0=A0 discovery protocol.=A0 A router = may have several MANET interfaces.

And draft-ietf-manet-olsrv2= defines:=20

OLSRv2 interface:
=A0=A0=A0=A0=A0 A MANET interface running thi= s protocol.=A0 A router running this
=A0=A0=A0=A0=A0 protocol MUST have = at least one OLSRv2 interface.

In one of the last OLSRv2 revis= ions, we made sure that OLSRv2 differentiates between neighbors running onl= y NHDP and neighbors running also OLSRv2, and only the latter are used for = MPR selection, etc. I do not understand what you would like to change in th= e OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.=20


>OLSRv2 interface:
>A MANET interface running this pr= otocol. =A0A router running this
>protocol MUST have at least one OLS= Rv2 interface.

HR>A routing protocol which does not run on = any interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.


=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.


Can you suggest what you would like to change? I don't und= erstand your point.

Best regards
Ul= rich
=A0+++++++++++++++++++++++++++++++++++++++++++


Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as=20 IP-interface why we have OLSRv2_draft saying that it is=20 network-interface as MANET is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer to a network while you mean a protocol, even=20 though I know I may misunderstood. I sugget that this SHOULD be=20 explained clearly. I think every one seems to understand that=20 network-interface must include=A0Data-Link-layer, therefore, RFC6130 or=20 OLSRv2-draft should define well as you did. I thank you for your=20 comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris=20 defined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) <Chris.Dearlove at baesystems.com> wr= ote:


An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP=20 addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20 care about that. Your statement =93a MANET interface is a data link=20 interface=94 is wrong.

=A0

--

Christopher Dearlove

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194<= /a>=A0|=A0 Fax: +44 1245 242124

chris.dearlove at baesystems.com | http://www.baesys= tems.com



--047d7b2ee19942184e04beec2474-- From ietf@thomasclausen.org Mon Apr 30 17:40:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A521521E8126 for ; Mon, 30 Apr 2012 17:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCwB38k7N9Z0 for ; Mon, 30 Apr 2012 17:40:53 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 30A1821E809F for ; Mon, 30 Apr 2012 17:40:53 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E47F35581EB for ; Mon, 30 Apr 2012 17:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B7E621C075B; Mon, 30 Apr 2012 17:40:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 03BEE1C08BD; Mon, 30 Apr 2012 17:40:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_BD073CBA-4EF8-4BF7-BF59-BBB5B6198BA9" From: Thomas Clausen In-Reply-To: Date: Tue, 1 May 2012 02:40:47 +0200 Message-Id: <6C04E6A1-5883-42D8-BDB6-6A796A8AF9B5@thomasclausen.org> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1257) Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:40:54 -0000 --Apple-Mail=_BD073CBA-4EF8-4BF7-BF59-BBB5B6198BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2012, at 11:10 PM, Abdussalam Baryun wrote: > Hi Herberg, > =20 > I am suggesting to clarify interfaces, I donot like to change if = unnecessary. Mentioning that an interface is in the layer 3, or its = logical, or even just explaining the way Chris defined to me, really = makes difference. No, it is utterly pointless to do so. As a matter of fact, all OLSRv2 = cares about is, that the interface over which it operates also runs NHDP = (RFC6130). Hence, the stipulation that an OLSRv2 interface is a MANET = interface (with the latter being defined exactly in RFC6130). RFC5498 specifies a relationship to IP and UDP. > My question is why is the draft not mentioning that OLSRv2-interface = is an IP-interface or a logical-interface? Does the authors see that = this information is not important? or even MANET-interfaces are in layer = 3. It is not mentioned because it doesn't matter one iota.=20 An OLSRv2 interface can be physical or virtual. Chris explained it well, = I suggest re-reading his email. > If we define protocols without mentioning which layer it is located = in, then how can we define such protocol > its layer-location is more important than its functionality, No, it isn't. > because each layer has its special interfaces, functions, services, = and messages. That doesn't have any relevance here. > There are many documents that explain interface in the same model that = OLSRv2 is presenting so why didn't have confusion when I read them?=20 I do not understand what you are asking above. > >An OLSRv2 interface (a special case of a MANET interface, see RFC = 6130) is an IP interface, one which IP >receives packets on, has one or = more IP addresses etc. It has a data link layer below it, but OLSRv2 = doesn=92t >care about that. Your statement =93a MANET interface is a = data link interface=94 is wrong. >=20 > >I don't think there is any confusion. Chris has pointed out the = relationship between MANET interface and OLSRv2 >interface clearly. I = think that RFC6130/draft-ietf-manet-olsrv2 define the terminology = correctly. If you would like to >change anything, please suggest = concrete text to replace, so that I can better understand what you mean. >=20 > I disagree that there is no confusion. There are confusions in = defining terms in MANET WG, I Disagree; in the IETF, protocols define in their respective terminology = sections the appropriate terminology. > have seen in the past a long discussion between many, just arguing = about defining host or router, Irrelevant in the context of discussing OLSRv2. > and now l was confused of interfaces in OLSRv2-draft. Maybe because I = am not much familiar with OLSR, or reading about network-interface in = many papers, and I read RFC2501 (it refers alot to wireless interface = and communications) and mentioned in RFC6130 for the interface as attach = to communication medium, I thought it was a medium as physical medium. Doesn't matter if it is physical or logical or virtual - as long as it = permits sending/receiving packets. > I suggest to clarify by adding information in one of the following = explanation to the draft (even a line will do): > =20 > - Mentioning which layer(s) the OLSRv2-interface works or allowed to = be at by the protocol, or > - defining the MANET-interface as Chris defined (IP-interface, at = layer 3) in terminology, or > - mentioning that OLSRv2-interface is not a wireless interface, or > - defining MANET-interface as logical interface. It's fairly clear that a MANET interface is (according to RFC6130) an = interface over which NHDP is operating, and an OLSRv2-interface = (according to the OLSRv2 I-D) is a MANET interface, over which also = OLSRv2 is operating. Physical/logical interfaces make no difference.=20 Wireless or not-a-wireless-interface makes no difference (where on earth = did that idea come from?) All the layer-discussion is also entirely off the mark by more than a = mile.=20 Now, if you really want to be pedantic (and it seems you do, so I will = be ;) ), a routing protocol implementation would run as an application = (so, on layer-7 in the OSI model), interacting only with the networking = layer by way of manipulating entries in the routing table; with IP being = the only "true Layer-3 protocol" (in as much as only IP defines headers = added/stripped at L3. Hence, being pedantic, it would be wrong to talk = about OLSR running at Layer 3. OLSRv2 using UDP would, incidentally, = attach to something decidedly at the transport layer (which, I hope that = we agree, is above Layer 3). In other words, all of the suggestions made are varying degrees of = wrong, so they should definitely not be added. Best, Thomas > I am sorry to disturb, I actually still have many comments for = OLSRv2-draft and will try to submit, and let the WG to decide. However, = I thank you and Chris to explain to me so at least my other comments = will be in understanding. >=20 > Abdussalam > ++++++++++++++++++ >=20 > On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg = wrote: > Abdussalam, >=20 > RFC6130 defines: >=20 >=20 > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces. >=20 > And draft-ietf-manet-olsrv2 defines: >=20 > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface. >=20 > In one of the last OLSRv2 revisions, we made sure that OLSRv2 = differentiates between neighbors running only NHDP and neighbors running = also OLSRv2, and only the latter are used for MPR selection, etc. I do = not understand what you would like to change in the OLSRv2 draft. >=20 > See comments below: >=20 > On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun = wrote: > Hi Henning, > =20 > Please note that I read the first pages of draft many times before = posting any information. > =20 > HR>I would suggest reading the OLSRv2-draft again, especially section = 2. >=20 >=20 > >OLSRv2 interface: > >A MANET interface running this protocol. A router running this > >protocol MUST have at least one OLSRv2 interface. >=20 > HR>A routing protocol which does not run on any interface would be = pretty > >useless, right? > You reply to the second sentence not the first which has 'running this = protocol' relating it not to the router it is relating it to the = interface. I know that router must have at least a network-interface ( = or data-link-layer) or MANET interface, this is not what I commenting = and the draft is mentioning. We don't assume at least Data-Link because = it is obvious and we are following TCP/IP model in the internet, but not = at least a specific-interface called bla bla. > =20 > Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS = this protocol (OLSRv2) this means there is some thing related to OLSRv2 = in the layer-2. You should read again another paragraph mentioning as if = there is difference between MANET-interface and OLSRv2-interface. > =20 > OLSRv2-14>p9> > Supports routers that each have one or more participating OLSRv2 > interfaces, which will consist of some or all of its MANET > interfaces using [RFC6130]. The set of a router=92s OLSRv2 > interfaces, and the sets of its other MANET and non-MANET > interfaces, may change over time. Each interface may have one or > more network addresses (which may have prefix lengths), and these > may also be dynamically changing. > =20 > AB> it is clear from the above draft-page-9, that all MANET interfaces = are not an OLSRv2-interface, but All OLSRv2 interfaces are = MANET-interfaces. So we have to have in or node at least an = OLSRv2-interface, not at least one MANET-interfac so the protocol to = work correctly. > =20 > AB> The above page-9 mentions NHDP as well that interfaces need this = protocol. What if there is not NHDP, or if it is not working, what will = happen. The draft SHOULD explain these issues. >=20 >=20 > =20 > AB> It may be that all OLSRv2 routers (as implementation point of = practice) only need at least one MANET interface. But the authors need = to change. therefore, we know that All routers need at least on = interface, but the draft-wording has a special OLSRv2-interface. Then we = need to change the draft wording to the right explaination. >=20 >=20 > Can you suggest what you would like to change? I don't understand your = point. >=20 > Best regards > Ulrich > +++++++++++++++++++++++++++++++++++++++++++ >=20 >=20 > Hi Chris > =20 > ok then if it was simple to explain as a special interface as = IP-interface why we have OLSRv2_draft saying that it is = network-interface as MANET is a network, but IP is not it is a protocol. = IMO it is wrong to refer to a network while you mean a protocol, even = though I know I may misunderstood. I sugget that this SHOULD be = explained clearly. I think every one seems to understand that = network-interface must include Data-Link-layer, therefore, RFC6130 or = OLSRv2-draft should define well as you did. I thank you for your = comment, > =20 > Therefore I suggest to change OLSRv2-interface definition as Chris = defined it very clearly. I hope the draft can change the definition, > =20 > Abdussalam >=20 > = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) = wrote: >=20 >=20 > An OLSRv2 interface (a special case of a MANET interface, see RFC = 6130) is an IP interface, one which IP receives packets on, has one or = more IP addresses etc. It has a data link layer below it, but OLSRv2 = doesn=92t care about that. Your statement =93a MANET interface is a data = link interface=94 is wrong. >=20 > =20 > -- >=20 > Christopher Dearlove >=20 > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 >=20 > chris.dearlove at baesystems.com | http://www.baesystems.com >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_BD073CBA-4EF8-4BF7-BF59-BBB5B6198BA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Herberg,
 
= I am suggesting to clarify interfaces, I donot like to = change if unnecessary. Mentioning that an interface is in the layer = 3, or its logical, or even just explaining the way Chris defined to me, = really makes difference.

No, it is = utterly pointless to do so. As a matter of fact, all OLSRv2 cares about = is, that the interface over which it operates also runs NHDP (RFC6130). = Hence, the stipulation that an OLSRv2 interface is a MANET interface = (with the latter being defined exactly in = RFC6130).

RFC5498 specifies a relationship to = IP and UDP.

My question is why = is the draft not mentioning that OLSRv2-interface is an IP-interface or = a logical-interface? Does the authors see that this information is not = important? or even MANET-interfaces are in layer = 3.

It is not mentioned because it = doesn't matter one iota. 

An OLSRv2 = interface can be physical or virtual. Chris explained it well, I suggest = re-reading his email.

  If we define protocols without mentioning = which layer it is located in, then how can we define such = protocol
its = layer-location is more important than its functionality, =

No, it = isn't.

because each layer has = its special interfaces, functions, services, and messages. =

That doesn't have any relevance = here.

There are many documents = that explain interface in the same model that=20 OLSRv2 is presenting so why didn't have confusion when I read them? =

I do not understand what you = are asking above.

= >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more = IP=20 addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20= >care about that. Your statement =93a MANET interface is a data link=20= interface=94 is wrong.

>I don't think there is any = confusion. Chris has pointed out the=20 relationship between MANET interface and OLSRv2 >interface clearly. I=20= think that RFC6130/draft-ietf-manet-olsrv2 define the terminology=20 correctly. If you would like to >change anything, please suggest = concrete text to replace, so that I can better understand what you = mean.

I disagree that there is no confusion. There are = confusions in defining terms in MANET WG, = I

Disagree; in the IETF, protocols = define in their respective terminology sections the appropriate = terminology.

have seen in the = past a long discussion between many, just arguing about defining host or = router,

Irrelevant in the context = of discussing OLSRv2.

and now l = was confused of interfaces in OLSRv2-draft. Maybe because I am not much = familiar with OLSR, or reading about network-interface in many papers, = and I read RFC2501 (it refers alot to wireless interface and = communications) and mentioned in RFC6130 for the interface as attach to = communication medium, I thought it was a medium as physical = medium.

Doesn't matter if it is = physical or logical or virtual - as long as it permits sending/receiving = packets.

I suggest to = clarify by adding information in one of the following explanation to the = draft (even a line will do):
 
- Mentioning which layer(s) the OLSRv2-interface works or = allowed to be at by the protocol, or
- defining the MANET-interface as Chris defined = (IP-interface, at layer 3) in terminology, = or
- mentioning that OLSRv2-interface is not a wireless interface, = or
- defining MANET-interface as logical = interface.


It's = fairly clear that a MANET interface is (according to RFC6130) an = interface over which NHDP is operating, and an OLSRv2-interface = (according to the OLSRv2 I-D) is a MANET interface, over which also = OLSRv2 is operating.

Physical/logical = interfaces make no difference. 

Wireless = or not-a-wireless-interface makes no difference (where on earth did that = idea come from?)

All the layer-discussion is = also entirely off the mark by more than a = mile. 

Now, if you really want to be = pedantic (and it seems you do, so I will be ;) ), a routing protocol = implementation would run as an application (so, on layer-7 in the OSI = model), interacting only with the networking layer by way of = manipulating entries in the routing table; with IP being the only "true = Layer-3 protocol" (in as much as only IP defines headers added/stripped = at L3. Hence, being pedantic, it would be wrong to talk about OLSR = running at Layer 3. OLSRv2 using UDP would, incidentally, attach to = something decidedly at the transport layer (which, I hope that we agree, = is above Layer 3).

In other words, all of the = suggestions made are varying degrees of wrong, so they should definitely = not be = added.

Best,

Thomas


I am sorry to disturb, I actually still have many comments for = OLSRv2-draft and will try to submit, and let the WG to decide. However, = I thank you and Chris to explain to me so at least my other comments = will be in understanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich = Herberg <ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 = defines:=20


MANET interface:
An interface participating in a MANET = and using this neighborhood
      discovery = protocol.  A router may have several MANET = interfaces.

And draft-ietf-manet-olsrv2 defines:=20

OLSRv2 interface:
      A MANET = interface running this protocol.  A router running = this
      protocol MUST have at least one = OLSRv2 interface.

In one of the last OLSRv2 revisions, we = made sure that OLSRv2 differentiates between neighbors running only NHDP = and neighbors running also OLSRv2, and only the latter are used for MPR = selection, etc. I do not understand what you would like to change in the = OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Henning,
 
Please note that I read the first pages of draft many times = before posting any information.
 
HR>I would suggest reading the OLSRv2-draft again, especially = section 2.=20


>OLSRv2 interface:
>A MANET interface running this = protocol.  A router running this
>protocol MUST have at least = one OLSRv2 interface.

HR>A routing protocol which does = not run on any interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the = interface. I know that router must have at least a network-interface ( = or data-link-layer) or MANET interface, this is not what I = commenting and the draft is mentioning. We don't assume at least = Data-Link because it is obvious and we are following TCP/IP model in the = internet, but not at least a specific-interface called bla bla.
 
Why it defines the 'OLSRv2-interface' as a MANET-interface that = RUNS this protocol (OLSRv2) this means there is some thing related = to OLSRv2 in the layer-2. You should read again another paragraph = mentioning as if there is difference between MANET-interface and = OLSRv2-interface.
 
OLSRv2-14>p9>
Supports routers that = each have one or more participating OLSRv2
interfaces, which will = consist of some or all of its MANET
interfaces using [RFC6130]. The set of a router=92s = OLSRv2
interfaces, and the sets = of its other MANET and non-MANET
interfaces, may change = over time. Each interface may have one or
more network addresses = (which may have prefix lengths), and these
may also be dynamically = changing.
 
AB> it is clear from the above draft-page-9, that all MANET = interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces = are MANET-interfaces. So we have to have in or node at least an = OLSRv2-interface, not at least one MANET-interfac so the protocol to = work correctly.
 
AB> The above page-9 mentions NHDP as well that interfaces need = this protocol. What if there is not NHDP, or if it is not working, what = will happen. The draft SHOULD explain these issues.


 
AB> It may be that all OLSRv2 routers (as implementation point = of practice) only need at least one MANET interface. But the authors = need to change. therefore, we know that All routers need at least on = interface, but the draft-wording has a special OLSRv2-interface. Then we = need to change the draft wording to the right explaination.


Can you suggest what you would like to change? I don't = understand your point.

Best regards
Ulrich
 ++++++++++++++++++++++++++++++++++++= +++++++


Hi Chris
 
ok then if it was simple to explain as a special interface as=20= IP-interface why we have OLSRv2_draft saying that it is=20 network-interface as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a protocol, = even=20 though I know I may misunderstood. I sugget that this SHOULD be=20 explained clearly. I think every one seems to understand that=20 network-interface must include Data-Link-layer, therefore, RFC6130 = or=20 OLSRv2-draft should define well as you did. I thank you for your=20 comment,
 
Therefore I suggest to change OLSRv2-interface definition as Chris=20= defined it very clearly. I hope the draft can change the = definition,
 
Abdussalam

= +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<= br>On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) <Chris.Dearlove at baesystems.com> = wrote:


= An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP=20= addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t=20= care about that. Your statement =93a MANET interface is a data link=20 interface=94 is wrong.

=  

= --

= Christopher Dearlove

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

= chris.dearlove at = baesystems.com | http://www.baesystems.com
=

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

= --Apple-Mail=_BD073CBA-4EF8-4BF7-BF59-BBB5B6198BA9--