From internet-drafts@ietf.org Sat Aug 6 23:26:31 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BC21F8745; Sat, 6 Aug 2011 23:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 3xSBgp3-+coO; Sat, 6 Aug 2011 23:26:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F010A21F871E; Sat, 6 Aug 2011 23:26:30 -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: 3.57 Message-ID: <20110807062630.2246.23965.idtracker@ietfa.amsl.com> Date: Sat, 06 Aug 2011 23:26:30 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-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: Sun, 07 Aug 2011 06:26:31 -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 : Cryptographical Signatures in NHDP Author(s) : Ulrich Herberg Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-00.txt Pages : 10 Date : 2011-07-29 This document specifies an extension to the Neighbor Discovery Protocol (NHDP) which uses cryptographic signatures in HELLO messages to encounter a selection of security threats to NHDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-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-00.txt From jkang@telcordia.com Tue Aug 9 09:03:48 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B430321F8C52 for ; Tue, 9 Aug 2011 09:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, 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 V6el-iIU1wrV for ; Tue, 9 Aug 2011 09:03:47 -0700 (PDT) Received: from dnsmx1mnh.telcordia.com (dnsmx1mnh.telcordia.com [192.4.156.21]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD021F8C49 for ; Tue, 9 Aug 2011 09:03:47 -0700 (PDT) Received: from rrc-dte-bms01.telcordia.com (rrc-dte-bms01.cc.telcordia.com [128.96.150.38]) by dnsmx1mnh.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id p79G4EB2016861; Tue, 9 Aug 2011 12:04:14 -0400 (EDT) X-AuditID: 80609626-b7b95ae000004167-1d-4e415a7eec2a Received: from pya-dte-exhb1.dte.telcordia.com (pya-dte-exhb1.cc.telcordia.com [128.96.20.11]) by rrc-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id 78.A5.16743.E7A514E4; Tue, 9 Aug 2011 12:04:14 -0400 (EDT) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) with mapi; Tue, 9 Aug 2011 12:04:13 -0400 From: "Kang, Jaewon" To: "sratliff@cisco.com" Date: Tue, 9 Aug 2011 12:04:13 -0400 Thread-Topic: [manet] DLEP v1 Thread-Index: AcxWrftTytlLuFbPS7W/fnOQYTL9pw== Message-ID: <563593148DD9A040B93397F642B3C1255957DEACB3@rrc-dte-exmb1.dte.telcordia.com> 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_563593148DD9A040B93397F642B3C1255957DEACB3rrcdteexmb1dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "manet@ietf.org" Subject: [manet] DLEP v1 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 09 Aug 2011 16:03:48 -0000 --_000_563593148DD9A040B93397F642B3C1255957DEACB3rrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stan, I have a question about the operation of a Router's ARP protocol in conjunc= tion with DLEP. >From the document, it seems like the ARP protocol is enabled or disabled ba= sed on the DLEP messages and can be controlled per modem device. For exampl= e, a Router has two modem devices with and without DLEP capabilities. On pa= ge 52 in the document, the ARP protocol is enabled only after the Router an= d the Client exchange Neighbor Up/Neighbor Up ACK orders. In this case, is = it true that the ARP protocol is still operational for the other modem (wit= hout DLEP)? If so, can we control the ARP protocol per modem at the Router? If not, the MAC information retrieved from the modem without DLEP will not = be instantiated in the Router's neighbor table. Or are we assuming that all modem device should talk DLEP protocol? Thanks. Jae from Telcordia --_000_563593148DD9A040B93397F642B3C1255957DEACB3rrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stan,=

 

I have a= question about the operation of a Router’s ARP protocol in conjuncti= on with DLEP.

 

From the document, it seems like the ARP protocol is enable= d or disabled based on the DLEP messages and can be controlled per modem de= vice. For example, a Router has two modem devices with and without DLEP cap= abilities. On page 52 in the document, the ARP protocol is enabled only aft= er the Router and the Client exchange Neighbor Up/Neighbor Up ACK orders. I= n this case, is it true that the ARP protocol is still operational for the = other modem (without DLEP)?

If so, can w= e control the ARP protocol per modem at the Router?

If not, the MAC information retrieved from the modem without D= LEP will not be instantiated in the Router’s neighbor table.

Or are we assuming that all modem device should = talk DLEP protocol?

 

Thanks.

 = ;

Jae from Telcordia

 

= --_000_563593148DD9A040B93397F642B3C1255957DEACB3rrcdteexmb1dt_-- From sratliff@cisco.com Tue Aug 9 09:57:58 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A197621F8C19 for ; Tue, 9 Aug 2011 09:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 x5AA9Mx7XA-x for ; Tue, 9 Aug 2011 09:57:58 -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 CD73321F8C18 for ; Tue, 9 Aug 2011 09:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6238; q=dns/txt; s=iport; t=1312909107; x=1314118707; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=zYa4GR4fPijgQCZEin3USh1fj1/PHQdUchWElBpUYt4=; b=NeTkPEFhEvLVkWZYARTq0TK5uoDTCBZI2U1+1JwZmC/rQNZaJPDVR/5H fy6b2D4Dxa6UMtJUR2oGlGP1nwMEp0W295Dp8Wusq9LGeACoRQXA+ZwwG Qi/r71N9dci6IRi47ndzT2ByB8jDJMxUnjfOhufckXSEZbHznRHNc9Pos g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP1lQU6tJXG+/2dsb2JhbABCgk2kcXeBQAEBAQECARIBZgULC0ZXBjWHS6ARAZ5rhWdfBJMFkQc X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208,217";a="11368358" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 09 Aug 2011 16:58:27 +0000 Received: from rtp-sratliff-8713.cisco.com (rtp-sratliff-8713.cisco.com [10.116.179.212]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79GwQNP018584; Tue, 9 Aug 2011 16:58:26 GMT Message-Id: <517F3E56-1230-40D8-A9BA-D0D79B3105D6@cisco.com> From: Stan Ratliff To: "Kang, Jaewon" In-Reply-To: <563593148DD9A040B93397F642B3C1255957DEACB3@rrc-dte-exmb1.dte.telcordia.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4--405541476 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 9 Aug 2011 12:58:27 -0400 References: <563593148DD9A040B93397F642B3C1255957DEACB3@rrc-dte-exmb1.dte.telcordia.com> X-Mailer: Apple Mail (2.936) Cc: "manet@ietf.org" Subject: Re: [manet] DLEP v1 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 09 Aug 2011 16:57:58 -0000 --Apple-Mail-4--405541476 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Jae, That's really an implementation issue. The idea was that a Neighbor Up =20= with Layer 3 addresses supplied by the modem would allow code to =20 populate the ARP table immediately. ARP (as well as inARP, Reverse =20 ARP, etc) are also available if/when a Neighbor Up is received without =20= the Layer 3 addressing information. Regards, Stan On Aug 9, 2011, at 12:04 PM, Kang, Jaewon wrote: > Stan, > > I have a question about the operation of a Router=92s ARP protocol in =20= > conjunction with DLEP. > > =46rom the document, it seems like the ARP protocol is enabled or =20 > disabled based on the DLEP messages and can be controlled per modem =20= > device. For example, a Router has two modem devices with and without =20= > DLEP capabilities. On page 52 in the document, the ARP protocol is =20 > enabled only after the Router and the Client exchange Neighbor Up/=20 > Neighbor Up ACK orders. In this case, is it true that the ARP =20 > protocol is still operational for the other modem (without DLEP)? > If so, can we control the ARP protocol per modem at the Router? > If not, the MAC information retrieved from the modem without DLEP =20 > will not be instantiated in the Router=92s neighbor table. > Or are we assuming that all modem device should talk DLEP protocol? > > Thanks. > > Jae from Telcordia > --Apple-Mail-4--405541476 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Stan,
I have a question about the = operation of a Router=92s ARP protocol in conjunction with = DLEP.
 
=46rom the = document, it seems like the ARP protocol is enabled or disabled based on = the DLEP messages and can be controlled per modem device. For example, a = Router has two modem devices with and without DLEP capabilities. On page = 52 in the document, the ARP protocol is enabled only after the Router = and the Client exchange Neighbor Up/Neighbor Up ACK orders. In this = case, is it true that the ARP protocol is still operational for the = other modem (without DLEP)?
If so, can we = control the ARP protocol per modem at the Router?
Or are we assuming that all modem device should = talk DLEP protocol?
 
 
To: Stan Ratliff Date: Tue, 9 Aug 2011 14:31:58 -0400 Thread-Topic: [manet] DLEP v1 Thread-Index: AcxWtZCxeu4eo0eiTFuw8mJznMtSnQADLGnA Message-ID: <563593148DD9A040B93397F642B3C1255957DEAE96@rrc-dte-exmb1.dte.telcordia.com> References: <563593148DD9A040B93397F642B3C1255957DEACB3@rrc-dte-exmb1.dte.telcordia.com> <517F3E56-1230-40D8-A9BA-D0D79B3105D6@cisco.com> In-Reply-To: <517F3E56-1230-40D8-A9BA-D0D79B3105D6@cisco.com> 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_563593148DD9A040B93397F642B3C1255957DEAE96rrcdteexmb1dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "manet@ietf.org" Subject: Re: [manet] DLEP v1 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 09 Aug 2011 18:31:34 -0000 --_000_563593148DD9A040B93397F642B3C1255957DEAE96rrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK. It looks like the DLEP protocol at the Router inserts an ARP entry into= the ARP cache when it receives a Neighbor Up order while the legacy ARP pr= otocol is still in operation at the Router. Jae. From: Stan Ratliff [mailto:sratliff@cisco.com] Sent: Tuesday, August 09, 2011 12:58 PM To: Kang, Jaewon Cc: manet@ietf.org Subject: Re: [manet] DLEP v1 Jae, That's really an implementation issue. The idea was that a Neighbor Up with= Layer 3 addresses supplied by the modem would allow code to populate the A= RP table immediately. ARP (as well as inARP, Reverse ARP, etc) are also ava= ilable if/when a Neighbor Up is received without the Layer 3 addressing inf= ormation. Regards, Stan On Aug 9, 2011, at 12:04 PM, Kang, Jaewon wrote: Stan, I have a question about the operation of a Router's ARP protocol in conjunc= tion with DLEP. >From the document, it seems like the ARP protocol is enabled or disabled ba= sed on the DLEP messages and can be controlled per modem device. For exampl= e, a Router has two modem devices with and without DLEP capabilities. On pa= ge 52 in the document, the ARP protocol is enabled only after the Router an= d the Client exchange Neighbor Up/Neighbor Up ACK orders. In this case, is = it true that the ARP protocol is still operational for the other modem (wit= hout DLEP)? If so, can we control the ARP protocol per modem at the Router? If not, the MAC information retrieved from the modem without DLEP will not = be instantiated in the Router's neighbor table. Or are we assuming that all modem device should talk DLEP protocol? Thanks. Jae from Telcordia --_000_563593148DD9A040B93397F642B3C1255957DEAE96rrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK. It looks like the DLEP protocol at the Router inserts an ARP= entry into the ARP cache when it receives a Neighbor Up order while the le= gacy ARP protocol is still in operation at the Router.

 

Jae.

 =

From: Stan Ratliff [mail= to:sratliff@cisco.com]
Sent: Tuesday, August 09, 2011 12:58 PMTo: Kang, Jaewon
Cc: manet@ietf.org
Subject: R= e: [manet] DLEP v1

 

Jae, 

 

That's= really an implementation issue. The idea was that a Neighbor Up with Layer= 3 addresses supplied by the modem would allow code to populate the ARP tab= le immediately. ARP (as well as inARP, Reverse ARP, etc) are also available= if/when a Neighbor Up is received without the Layer 3 addressing informati= on. 

 

Regards,

Stan

 = ;

On Aug 9, 2011, at 12:04 PM, Kang= , Jaewon wrote:



Stan,

<= div>

 

I have a question about the operation of a Router’= ;s ARP protocol in conjunction with DLEP.

<= p class=3DMsoNormal> 

From the document, it seems like the ARP protocol is enabled= or disabled based on the DLEP messages and can be controlled per modem dev= ice. For example, a Router has two modem devices with and without DLEP capa= bilities. On page 52 in the document, the ARP protocol is enabled only afte= r the Router and the Client exchange Neighbor Up/Neighbor Up ACK orders. In= this case, is it true that the ARP protocol is still operational for the o= ther modem (without DLEP)?

If so, can we control the ARP protocol per modem at the Router?

If not, the MAC in= formation retrieved from the modem without DLEP will not be instantiated in= the Router’s neighbor table.

Or are we assuming that all modem device should talk DLE= P protocol?

 = ;

Thanks.

 =

Jae from Telcordia

 

 

= = --_000_563593148DD9A040B93397F642B3C1255957DEAE96rrcdteexmb1dt_-- From vkaul@research.telcordia.com Mon Aug 15 08:13:49 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0121F8C41 for ; Mon, 15 Aug 2011 08:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB9rcPaaeMA4 for ; Mon, 15 Aug 2011 08:13:49 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1621F8C40 for ; Mon, 15 Aug 2011 08:13:49 -0700 (PDT) Received: from vkaul7-t61.research.telcordia.com (vpntnlA77.research.telcordia.com [128.96.58.77]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p7FFEY4p021982; Mon, 15 Aug 2011 11:14:34 -0400 (EDT) Date: Mon, 15 Aug 2011 11:14:30 -0400 (Eastern Daylight Time) From: Vikram KAUL To: manet@ietf.org Message-ID: User-Agent: Alpine 2.01 (WNT 1266 2009-07-14) X-X-Sender: vkaul@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [manet] DLEP and broadcast/multicast X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 15 Aug 2011 15:13:50 -0000 Folks I have some questions about how DLEP handles multicast/broadcast traffic and the intents that the router might have to send to the modem device. Some of this might have been answered; but I couldn't find it in the archives The inherent nature of DLEP seems focused on neighbor relationships and link characteristics (MDR, CDR, Latency, etc) are focused on individual neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory in most of the messages My question is related to broadcast and/or multicast traffic that would emanate from a router. Let us presume that the underlying multicast protocol is SMF for ease of discussion... but it could be anything that forwards native multicast packets, either via flooding or after creating trees. How can one use DLEP to specify the MDR/CDR or latency requirements for those flows ? Is it even possible to do so ? I understand how one could do it for individual links to neighbors. But if I presume that multicast and broadcast is the predominant traffic (say 70%-80%, and I don't believe I am wrong about that), how can one use DLEP "Link Characteristics Request Message" to specify that traffic to a particular MAC address should be able to get at least what is specified by the CDR Sub-TLV Typically (but not always) MAC addresses for multicast IP packets are set to 01:00:xx:yy:zz:aa for a destination multicast address of xx.yy.zz.aa. Could one not have that 01:00:xx:yy:zz:aa MAC Address Sub-TLV so that the modem could identify that traffic to that MAC Address (and hence traffic to that destination multicast IP address) needs to get at least that data rate. How the modems would achieve that is a separate question, but DLEP does not delve into those answers anyway Again, it might be that the charter for DLEP is to focus specifically on one-to-one relationships (and hence one-to-one specifications and conditions). Could the specs not be augmented to support something on one-to-many specifications ? Just thinking aloud. regards.. Vikram From reller@cococorp.com Mon Aug 15 10:01:04 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B921F8C79 for ; Mon, 15 Aug 2011 10:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J88U+P9ZcYE for ; Mon, 15 Aug 2011 10:01:03 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB921F8C7B for ; Mon, 15 Aug 2011 10:01:03 -0700 (PDT) Received: from exhub13.exchhosting.com (192.168.11.122) by exhub05.exchhosting.com (192.168.11.101) with Microsoft SMTP Server (TLS) id 8.2.213.0; Mon, 15 Aug 2011 10:01:47 -0700 Received: from EXMBX13.exchhosting.com ([fe80::34:7540:6989:7b8d]) by exhub13.exchhosting.com ([::1]) with mapi; Mon, 15 Aug 2011 10:01:47 -0700 From: "A. Riley Eller" To: Vikram KAUL , "manet@ietf.org" Date: Mon, 15 Aug 2011 10:01:47 -0700 Thread-Topic: [manet] DLEP and broadcast/multicast Thread-Index: AcxbXkci4/+BiQpISFOKZvWse5W0swADHRhA Message-ID: <3D05610F3AC2E047AACAA68F63DF908D345B1AA01A@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] DLEP and broadcast/multicast X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 15 Aug 2011 17:01:04 -0000 Perhaps the DLEP specification would benefit from accepting a pseudo-link i= dentifier for multicast messages?=20 My team's research shows that EFT implementations achieve higher overall ac= curacy by measuring multicast messages as a universal estimator for queuing= -plus-congestion. Giving DLEP the ability to describe that value, and also = gaining the ability to control the radio's performance for multicast traffi= c, would be a valuable addition. -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of V= ikram KAUL Sent: Monday, August 15, 2011 8:15 AM To: manet@ietf.org Subject: [manet] DLEP and broadcast/multicast Folks I have some questions about how DLEP handles multicast/broadcast traffic= =20 and the intents that the router might have to send to the modem device.=20 Some of this might have been answered; but I couldn't find it in the=20 archives The inherent nature of DLEP seems focused on neighbor relationships and=20 link characteristics (MDR, CDR, Latency, etc) are focused on individual=20 neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory in=20 most of the messages My question is related to broadcast and/or multicast traffic that would=20 emanate from a router. Let us presume that the underlying multicast=20 protocol is SMF for ease of discussion... but it could be anything that=20 forwards native multicast packets, either via flooding or after creating=20 trees. How can one use DLEP to specify the MDR/CDR or latency requirements for=20 those flows ? Is it even possible to do so ? I understand how one could do= =20 it for individual links to neighbors. But if I presume that multicast and=20 broadcast is the predominant traffic (say 70%-80%, and I don't believe I=20 am wrong about that), how can one use DLEP "Link Characteristics Request= =20 Message" to specify that traffic to a particular MAC address should be=20 able to get at least what is specified by the CDR Sub-TLV Typically (but not always) MAC addresses for multicast IP packets are set= =20 to 01:00:xx:yy:zz:aa for a destination multicast address of xx.yy.zz.aa.=20 Could one not have that 01:00:xx:yy:zz:aa MAC Address Sub-TLV so that the=20 modem could identify that traffic to that MAC Address (and hence traffic=20 to that destination multicast IP address) needs to get at least that data=20 rate. How the modems would achieve that is a separate question, but DLEP=20 does not delve into those answers anyway Again, it might be that the charter for DLEP is to focus specifically on= =20 one-to-one relationships (and hence one-to-one specifications and=20 conditions). Could the specs not be augmented to support something on=20 one-to-many specifications ? Just thinking aloud. regards.. Vikram _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Thu Aug 18 10:04:17 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5D21F8B42 for ; Thu, 18 Aug 2011 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9P1-+5YwhVx for ; Thu, 18 Aug 2011 10:04:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5621F8B33 for ; Thu, 18 Aug 2011 10:04:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IH584S004742; Thu, 18 Aug 2011 18:05:08 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7IH56fs004701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Aug 2011 18:05:07 +0100 From: "Adrian Farrel" To: Date: Thu, 18 Aug 2011 18:05:06 +0100 Message-ID: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxdyNP6A67SDLNjTXO6pVbO+LuoPw== Content-Language: en-gb Subject: [manet] Tidying an Erratum on RFC 4728 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:04:17 -0000 Hi, Erratum 919 is on RFC 4728 You may have discussed it before, but I want to get it tidied away. http://www.rfc-editor.org/errata_search.php?rfc=4728&rec_status=2&presentation=r ecords I believe this is a typo, and the correction is right. Opinions? Thanks, Adrian From heffalump486@gmail.com Fri Aug 19 05:44:58 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951321F8A7B for ; Fri, 19 Aug 2011 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 uZATzC9vJc+T for ; Fri, 19 Aug 2011 05:44:58 -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 DE50D21F8ABB for ; Fri, 19 Aug 2011 05:44:57 -0700 (PDT) Received: by yxj17 with SMTP id 17so950482yxj.31 for ; Fri, 19 Aug 2011 05:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MU31crF8Eog9h0EytbHCAiH465v1+RnC+QARfiqTJqk=; b=hHWH8TgaavAZB9P1AHgHJCPPonG0omiuJrgOU7YpX97/qg/w2tGROSxgE7my8yQiQH WGy1vcicdsdD6/KFY8fE3k27OqdX8JrGOKyc2RuFGP5CLMKPu6qpGZast7acnwjYGBB/ Ot0uSJUD+2mlLroJ/vp1/iCNAn2fxMc+HQAVA= MIME-Version: 1.0 Received: by 10.101.5.21 with SMTP id h21mr2216213ani.123.1313757950560; Fri, 19 Aug 2011 05:45:50 -0700 (PDT) Received: by 10.100.126.16 with HTTP; Fri, 19 Aug 2011 05:45:50 -0700 (PDT) Date: Fri, 19 Aug 2011 13:45:50 +0100 Message-ID: From: John Dowdell To: manet@ietf.org Content-Type: multipart/alternative; boundary=001636c9297df6cae604aadb1b7f Subject: [manet] nhdp-sec and IPv6 SEND X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 19 Aug 2011 12:46:49 -0000 --001636c9297df6cae604aadb1b7f Content-Type: text/plain; charset=ISO-8859-1 Hi I notice similarities between the intent of nhdp-sec and RFC3971 IPv6 SEcure Neighbour Discovery (SEND). Is there any plan to re-use or cross-reference any part of SEND in nhdp-sec? Regards John --001636c9297df6cae604aadb1b7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
I notice similarities between=A0the intent of nhdp-sec=A0and RFC3971 I= Pv6 SEcure Neighbour Discovery (SEND). Is there any plan to re-use or cross= -reference any part of SEND in nhdp-sec?
=A0
Regards
John
--001636c9297df6cae604aadb1b7f-- From joseph.macker@nrl.navy.mil Fri Aug 19 10:15:32 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1521F8B89 for ; Fri, 19 Aug 2011 10:15:32 -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 6XsTZGpIIFLu for ; Fri, 19 Aug 2011 10:15:32 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id EA05921F8B88 for ; Fri, 19 Aug 2011 10:15:30 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p7JHGPaE020762; Fri, 19 Aug 2011 13:16:25 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011081913162507899 ; Fri, 19 Aug 2011 13:16:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> Date: Fri, 19 Aug 2011 13:16:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13D87764-8E77-4519-89C5-3B13D2DB177C@nrl.navy.mil> References: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1084) Cc: MANET IETF Subject: Re: [manet] Tidying an Erratum on RFC 4728 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 19 Aug 2011 17:15:32 -0000 Correction looks right to me as well. The error type provides the type specific info that is needed. -joe On Aug 18, 2011, at 1:05 PM, Adrian Farrel wrote: > Hi, >=20 > Erratum 919 is on RFC 4728 >=20 > You may have discussed it before, but I want to get it tidied away. >=20 > = http://www.rfc-editor.org/errata_search.php?rfc=3D4728&rec_status=3D2&pres= entation=3Dr > ecords >=20 > I believe this is a typo, and the correction is right. >=20 > Opinions? >=20 > Thanks, > Adrian >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From raghavan.muralidharan@gmail.com Sun Aug 21 09:26:07 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9904921F8779 for ; Sun, 21 Aug 2011 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 MN1PrrL-+H54 for ; Sun, 21 Aug 2011 09:26:07 -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 16F8021F8770 for ; Sun, 21 Aug 2011 09:26:06 -0700 (PDT) Received: by gxk19 with SMTP id 19so3792079gxk.31 for ; Sun, 21 Aug 2011 09:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JFBkAgkPu6/dPpuquwPyAzz/GeAfldQIfD7Pc5p00M4=; b=ANuP+Y/3mcsex94D5Y2E2q9FcxLAeQhpVG/meKGlXLYAELFWMaUES+/OGlkZiWXUSy FxULNV+8hx1Zzyn+dlYGK6n0qTO07pMluoJuFSrddkoGxhRjkvUl9N6zdeA3xuJK3kW2 k33/Bo8jBebMV4L+UStU+MgAutWZzffnDwoFg= MIME-Version: 1.0 Received: by 10.236.161.169 with SMTP id w29mr8296439yhk.79.1313944029384; Sun, 21 Aug 2011 09:27:09 -0700 (PDT) Sender: raghavan.muralidharan@gmail.com Received: by 10.236.203.233 with HTTP; Sun, 21 Aug 2011 09:27:09 -0700 (PDT) In-Reply-To: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> References: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> Date: Sun, 21 Aug 2011 21:57:09 +0530 X-Google-Sender-Auth: DHCMkpIyJYhMoDu5HpBa5PTqj4I Message-ID: From: "R. Muralidharan" To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf3056390720503b04ab066fd2 Cc: manet@ietf.org Subject: Re: [manet] Tidying an Erratum on RFC 4728 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 21 Aug 2011 16:27:05 -0000 --20cf3056390720503b04ab066fd2 Content-Type: text/plain; charset=ISO-8859-1 Hello, would the grateful if someone can educate me on the following: 1) status of ZRP draft rfc 2) status of OLSR v2 draft rfc 3) open source implementations of ZRP thanks in advance and best regards, murali --20cf3056390720503b04ab066fd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0 would the grateful if someone can educate me = on the following:

=A0 1) status of ZRP draft rfc
=A02) =A0status of OLSR v2 draft rfc

3) o= pen source implementations of ZRP

thanks in advance and best regards,
murali

--20cf3056390720503b04ab066fd2-- From Chris.Dearlove@baesystems.com Mon Aug 22 02:34:24 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E768321F8663 for ; Mon, 22 Aug 2011 02:34:24 -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, 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 l3+V2lMMFGyV for ; Mon, 22 Aug 2011 02:34:24 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5C21F85F2 for ; Mon, 22 Aug 2011 02:34:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,262,1312153200"; d="scan'208,217";a="153129567" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 22 Aug 2011 10:35:25 +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 p7M9ZJkH027159; Mon, 22 Aug 2011 10:35:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 10:35:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC60AE.CF2A27C2" Date: Mon, 22 Aug 2011 10:35:19 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Tidying an Erratum on RFC 4728 Thread-Index: AcxgH1W/Y3n+j/egRbeUImnJ2W65aAAjlPMg References: <02b601cc5dc8$fb400160$f1c00420$@olddog.co.uk> From: "Dearlove, Christopher (UK)" To: "R. Muralidharan" , X-OriginalArrivalTime: 22 Aug 2011 09:35:20.0690 (UTC) FILETIME=[CF63C520:01CC60AE] Cc: manet@ietf.org Subject: Re: [manet] Tidying an Erratum on RFC 4728 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 22 Aug 2011 09:34:25 -0000 ------_=_NextPart_001_01CC60AE.CF2A27C2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit OLSRv2 is a WG draft that was recently updated to incorporate metrics, as previously agreed by the WG. However in the most recent draft one section and one appendix remain unconvertted. The authors hope (other commitments permitting) to issue a new version as soon as they can. Following that we hope for the usual process of WG review (though comments on the existing draft would be helpful), IETF review, IESG review, RFC editor, and then to an RFC. [Four other parts of OLSRv2 with their own independent uses, have already followed this route to RFCs 5148, 5444, 5497 and 6130.] ZRP has not been a WG item for many years, its Internet Drafts are technically expired although of course they may have interest or use. (I haven't studied them to know how complete they are.) I do not think there is any likelihood of a ZRP RFC. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 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 R. Muralidharan Sent: 21 August 2011 17:27 To: adrian@olddog.co.uk Cc: manet@ietf.org Subject: Re: [manet] Tidying an Erratum on RFC 4728 *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Hello, would the grateful if someone can educate me on the following: 1) status of ZRP draft rfc 2) status of OLSR v2 draft rfc 3) open source implementations of ZRP thanks in advance and best regards, murali ******************************************************************** 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. ******************************************************************** ------_=_NextPart_001_01CC60AE.CF2A27C2 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
OLSRv2 is a WG draft that was recently updated to incorporate metrics,
as previously agreed by the WG. However in the most recent draft one
section and one appendix remain unconvertted. The authors hope (other
commitments permitting) to issue a new version as soon as they can.
Following that we hope for the usual process of WG review (though
comments on the existing draft would be helpful), IETF review, IESG
review, RFC editor, and then to an RFC. [Four other parts of OLSRv2
with their own independent uses, have already followed this route to
RFCs 5148, 5444, 5497 and 6130.]
 
ZRP has not been a WG item for many years, its Internet Drafts are
technically expired although of course they may have interest or use.
(I haven't studied them to know how complete they are.) I do not think
there is any likelihood of a ZRP RFC.

--
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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 R. Muralidharan
Sent: 21 August 2011 17:27
To: adrian@olddog.co.uk
Cc: manet@ietf.org
Subject: Re: [manet] Tidying an Erratum on RFC 4728

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet.
      Keep this in mind if you answer this message.
Hello,

  would the grateful if someone can educate me on the following:

  1) status of ZRP draft rfc
 2)  status of OLSR v2 draft rfc

3) open source implementations of ZRP

thanks in advance and best regards,
murali



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

------_=_NextPart_001_01CC60AE.CF2A27C2-- From ulrich@herberg.name Thu Aug 25 10:44:55 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8322E21F8C1E for ; Thu, 25 Aug 2011 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.085, 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 qvgWmcifmCH5 for ; Thu, 25 Aug 2011 10:44:54 -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 9348621F8C1B for ; Thu, 25 Aug 2011 10:44:54 -0700 (PDT) Received: by vxi29 with SMTP id 29so2370456vxi.31 for ; Thu, 25 Aug 2011 10:46:08 -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=yFOdlRpt4Dc8eHz3wq+cHzdmPC6bGNbkxYEjY815Bsg=; b=SgoDMptR1kezfBzxjPCVMBPpj1i3MxsiSCV45cWhTG483NwjPNd3lSUVRxp+XcQA0q z4p+ckwbEvhuoaNMBka4/6brtgVswYxa7k/mGNlDAzGJDP4nGmuMII577NmgqP4HgeSX dWpFlep676QlDTb95Z9Z0D9FJ9kRACgqb6CBg= MIME-Version: 1.0 Received: by 10.220.24.11 with SMTP id t11mr1658vcb.224.1314294367888; Thu, 25 Aug 2011 10:46:07 -0700 (PDT) Received: by 10.220.117.142 with HTTP; Thu, 25 Aug 2011 10:46:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Aug 2011 10:46:07 -0700 Message-ID: From: Ulrich Herberg To: John Dowdell Content-Type: multipart/alternative; boundary=485b39618a38eda4d904ab58006f Cc: manet@ietf.org Subject: Re: [manet] nhdp-sec and IPv6 SEND X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 25 Aug 2011 17:44:55 -0000 --485b39618a38eda4d904ab58006f Content-Type: text/plain; charset=ISO-8859-1 John, there are certainly similarities between SEND and NHDP-sec, and we will make sure to check if some of the elements of SEND are useful for NHDP-sec as well. However, ND and NHDP are different protocols, and so their respective security extensions will be different as well. Regards Ulrich On Fri, Aug 19, 2011 at 5:45 AM, John Dowdell wrote: > Hi > > I notice similarities between the intent of nhdp-sec and RFC3971 IPv6 > SEcure Neighbour Discovery (SEND). Is there any plan to re-use or > cross-reference any part of SEND in nhdp-sec? > > Regards > John > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --485b39618a38eda4d904ab58006f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

there are certainly similarities between SEND and NHDP-sec, an= d we will make sure to check if some of the elements of SEND are useful for= NHDP-sec as well. However, ND and NHDP are different protocols, and so the= ir respective security extensions will be different as well.

Regards
Ulrich

On Fri, Aug 19, 20= 11 at 5:45 AM, John Dowdell <heffalump486@gmail.com> wrote:
Hi
=A0
I notice similarities between=A0the intent of nhdp-sec=A0and RFC3971 I= Pv6 SEcure Neighbour Discovery (SEND). Is there any plan to re-use or cross= -reference any part of SEND in nhdp-sec?
=A0
Regards
John

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


--485b39618a38eda4d904ab58006f--