From abdussalambaryun@gmail.com Sun Jul 1 10:31: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 D1A3E11E8080; Sun, 1 Jul 2012 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 Imzzc29Ihn8M; Sun, 1 Jul 2012 10:31:44 -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 0295D21F898B; Sun, 1 Jul 2012 10:31:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3444689vbb.31 for ; Sun, 01 Jul 2012 10:31:43 -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=7QFiE7jTFacTq7JPZBi5fPLSPA4o6Y0L2qYDGB/QTJc=; b=DuweKxGsk1lFHhte3h6f/MqBIlj5gmiAisjUQ4XGVvdgMCNUoJ3didsDB0SL9I+d9x Yw5H4qwSA7F2L1Pmu0muKhsFQOaNwHybDv/dK8+HHL23MCQN/Lcfns0QU3j19ZQ/vQV9 4l89xjsKQaU/qUFlrzjYorTmVkYmoVDGStDjHJBzpbP/ZlsM97RRS1445iv5t8S9CKp0 fFgJPCqtHaIGA0Ze1MiejDhVoAlOyV451S22Edb7ZFnp1j9C4p7zgPywz9VZnrwHca3c 87ftz/hpjBehzVnV9WBiVM8JeJiUm9I/bzvk7e4kiJFw2avyYntwd0SwmZw2vqQuOs2a lzRQ== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr4785239vcw.43.1341163903327; Sun, 01 Jul 2012 10:31:43 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Sun, 1 Jul 2012 10:31:43 -0700 (PDT) Date: Sun, 1 Jul 2012 19:31:43 +0200 Message-ID: From: Abdussalam Baryun To: alexandru.petrescu@gmail.com, its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 01 Jul 2012 17:31:44 -0000 Hi Alex and All, >Scenario : A router deployed in a moving vehicle, uses its egress >interface to connect to larger-area access network(s) or to other >vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >Open to discussion: what are the scenarios? What are the potential > work items? What might be needed, if anything at all? I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS issues and in your questions directions. I will join the ITS-WG which I think can have relation to MANET [RFC2501]. IMO that vehicle routers communications depend on both their communication protocols and the used-network for such communication (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is needed for the router's if the communication is through the Internet's domain(s), but if it is through Ad-hoc networks' domain(s) it MAY not be used. The Internet is an infrastructure network and Ad-hoc networks are infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with the WG answers, and will read more into the WG inputs regarding these issues. I will schedule to participate/prepare I-D in the future for ITS scenarios. I am preparing an I-D on DSRv2 routing which is a MANET routing protocol that fits the use-case of ITS and VANET as well. Regards Abdussalam Baryun University of Glamorgan, UK ======================================================= From: Alexandru Petrescu To: its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] Scenarios, potential topics... -------------------------------------------------------------------------------- Welcome to the ITS list at IETF, an informal discussion. Earlier at IETF discussions related to vehicular communications happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a few), drafts were published [*]. At times people expressed interest to meet f2f. Now there is this email list. Participants are solicited to work on the topic of using IP in Intelligent Transportation Systems. The term ITS is a placeholder that, in my oppinion, is generic enough to cover many aspects of vehicular communications; vehicles may be wheeled, watered, flown. Ambulance, fire engine, coastal ship are particular examples. Scenario : A router deployed in a moving vehicle, uses its egress interface to connect to larger-area access network(s) or to other vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? Example potential work items: - Reqs for IPv6 in vehicular networks - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p (IPv6-over-foo). - open. I am told about other vehicular drafts and discussions, that I have not cited, existed and still exist (about e.g. ecall). I am interested to learn about all the vehicular activities at IETF. Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. Open to discussion: what are the scenarios? What are the potential work items? What might be needed, if anything at all? Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 draft-jhlee-mext-mnpp-00.txt, October 2009. draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. draft-petrescu-mip4-tuntype-change-00.txt, March 2011. draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. draft-singh-simple-vehicle-info, July 2007. draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. draft-bauer-mext-aero-solspace, Sep. 2009. draft-bauer-mext-aero-topology, Sep. 2009. draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. draft-rosen-ecrit-ecall-05.txt, March 2012. From abdussalambaryun@gmail.com Sun Jul 1 12:08: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 8ECB921F87B1 for ; Sun, 1 Jul 2012 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 b8FR3Zcd786H for ; Sun, 1 Jul 2012 12:08:05 -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 9196B21F87AE for ; Sun, 1 Jul 2012 12:08:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3466275vbb.31 for ; Sun, 01 Jul 2012 12:08:07 -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=M+BPbUHCIy+erye1915iUWXangIMihFx2dwpTO2etdk=; b=ebTY97bUG6PChBrVlAbysdKg77rqM1LtcvGVTLnX/eAukIVGyGeGswIO19+BxUxsB2 +kfi9jeM50QvSdVjenE1CCd7Dwt+UxVTqhUpshx99fWq4AvDgQm2C9FGBxAbfq8MFMvn KR01cfNxGz9OOUxNkdxo5qkuK4QfhLMtRaUNbWp1LYwjjMnHeI7VMNl/YIiLY6eMX53J STFIWdtMTIWCL42vNqngW4/I5uxcXPY81QNkvyltA+JJZB5iFdxkBcsy/CUhYe1YB8bv ci0ozoh/rgEk53yxZ0/VVd2Yb2NRbn9PBKjzFVotvZGDQXAHJd/p9kkV4FQnrO547f54 fcCw== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr4882837vcw.43.1341169687049; Sun, 01 Jul 2012 12:08:07 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Sun, 1 Jul 2012 12:08:06 -0700 (PDT) In-Reply-To: <0d3d01cd56f2$6ebb1080$4c313180$@olddog.co.uk> References: <0d3d01cd56f2$6ebb1080$4c313180$@olddog.co.uk> Date: Sun, 1 Jul 2012 21:08:06 +0200 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Being productive X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 01 Jul 2012 19:08:05 -0000 Hi Adrian, On 6/30/12, Adrian Farrel wrote: > Abdussalam: > - You are not a member of the MANET WG. There is no IETF membership. > You are welcome as a participant. So I understand now that all workers in IETF MANET WG are participants not members, and I am also a participant in the MANET WG. Thanking you, AB === From alexandru.petrescu@gmail.com Tue Jul 3 00:59: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 BFFBD21F87B9; Tue, 3 Jul 2012 00:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=2.000, 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 Y+D3cxPVxZjH; Tue, 3 Jul 2012 00:59:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3863A21F87B4; Tue, 3 Jul 2012 00:59:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q637xTGE019845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2012 09:59:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q637xT72025705; Tue, 3 Jul 2012 09:59:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q637xQbO005408; Tue, 3 Jul 2012 09:59:29 +0200 Message-ID: <4FF2A65E.2080000@gmail.com> Date: Tue, 03 Jul 2012 09:59:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 07:59:27 -0000 Hi Abdussalam and thanks for the reply. Le 01/07/2012 19:31, Abdussalam Baryun a écrit : > Hi Alex and All, > >> Scenario : A router deployed in a moving vehicle, uses its egress >> interface to connect to larger-area access network(s) or to other >> vehicles. > > Should it use IPv6-over-LTE? In our context we consider indeed IPv6 over LTE, for several reasons. The 3GPP specs about LTE seem to be very specific and detailed about the use of IPv6. (In the past, before LTE, the earlier 3GPP specs were mentioning IPv6 but more like an option feature.) However, the 3GPP specs about the use of IPv6 have some lack of specification in the case that the UE (User Terminal) is actually a Mobile Router. The Prefix Delegation part may be underspecified. > Should it use Mobile IP? Hmm... that is a good question and much can be said about it. I am interested to liste others' oppinions as well. I think Mobile IP may be necessary but not sufficient. In the case of direct vehicle-to-vehicle IP communications (non covered areas) Mobile IP may not be necessary. It may be that extensions to Neighbor Discovery and DHCP could help establish paths within local topologies. And, when that is done (e.g. exchange routes between two vehicles using RA) it may become apparent that interactions between Mobile IP and this mechanism may be necessary. >> Open to discussion: what are the scenarios? We are interested in describing the scenarios. There may exist several possibilities. I think of the following lego-like approach: - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. - scenario MR-to-MR - conceive prefixes in Router Advertisements, compare to other dynamic routing approaches. - scenario MR-to-MR-to-Infrastructure - combine the above two. Another direction is classify the kinds of vehicles. I think of something like this: - Internet Vehicle (has a plethora of interfaces, long- and short- range). - Range Extending Vehicle - extends the range of reachability. - Leaf Vehicle - like and end-node. Then there are other scenario statements that could open the path to the following: - addressability within vehicle, ULA, VIN. - problem of bandwidth difference between inside and outside the vehicle. > What are the potential work items? What might be needed, > if anything at all? > > I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS > issues and in your questions directions. I will join the ITS-WG which > I think can have relation to MANET [RFC2501]. Well, hmm. I am happy to hear that but let us go easy about this. "ITS" at IETF is currently just an informal effort. Its future may be ambitious but right now it's not a WG. To do that, we'd need to make a BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward. Secod, RFC2501 and ad-hoc routing are just one possibility to continue working on this. Some people may express positive technical feedback about MANET and others less so. > IMO that vehicle routers communications depend on both their > communication protocols and the used-network for such communication > (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO > there is no doubt that Mobile IP [RFC6275] is needed for the router's > if the communication is through the Internet's domain(s), but if it > is through Ad-hoc networks' domain(s) it MAY not be used. I tend to agree that Mobile IP may not be needed between vehicles which communicate directly without infrastructure. Then one wonders _what_ is needed? > The Internet is an infrastructure network and Ad-hoc networks are > infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with > the WG answers, and will read more into the WG inputs regarding these > issues. (see above note about this "WG" acronym which ITS is not currently) > I will schedule to participate/prepare I-D in the future for ITS > scenarios. I am preparing an I-D on DSRv2 routing which is a MANET > routing protocol that fits the use-case of ITS and VANET as well. I am interested to work on scenario/reqs drafts for ITS. About "DSRv2" - is it still about Routing Headers? I am interested to hear others' oppinions as well. Yours, Alex > > Regards > > Abdussalam Baryun University of Glamorgan, UK > ======================================================= > > From: Alexandru Petrescu To: its > at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] > Scenarios, potential topics... > -------------------------------------------------------------------------------- > > > > > Welcome to the ITS list at IETF, an informal discussion. > > Earlier at IETF discussions related to vehicular communications > happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a > few), drafts were published [*]. At times people expressed interest > to meet f2f. Now there is this email list. > > Participants are solicited to work on the topic of using IP in > Intelligent Transportation Systems. The term ITS is a placeholder > that, in my oppinion, is generic enough to cover many aspects of > vehicular communications; vehicles may be wheeled, watered, flown. > Ambulance, fire engine, coastal ship are particular examples. > > Scenario : A router deployed in a moving vehicle, uses its egress > interface to connect to larger-area access network(s) or to other > vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? > > Example potential work items: - Reqs for IPv6 in vehicular networks > - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and > IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p > (IPv6-over-foo). - open. > > I am told about other vehicular drafts and discussions, that I have > not cited, existed and still exist (about e.g. ecall). I am > interested to learn about all the vehicular activities at IETF. > > Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. > > Open to discussion: what are the scenarios? What are the potential > work items? What might be needed, if anything at all? > > Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 > draft-jhlee-mext-mnpp-00.txt, October 2009. > draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. > draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. > draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. > draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. > draft-petrescu-mip4-tuntype-change-00.txt, March 2011. > draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. > draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 > draft-rosen-ecrit-ecall-04.txt, March 2010. > draft-singh-simple-vehicle-info, July 2007. > draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. > draft-bauer-mext-aero-solspace, Sep. 2009. > draft-bauer-mext-aero-topology, Sep. 2009. > draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. > draft-rosen-ecrit-ecall-05.txt, March 2012. > > From john.dowdell@cassidian.com Tue Jul 3 02:06: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 2A9B721F87D3; Tue, 3 Jul 2012 02:06:20 -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 gzbHpUvuwd3H; Tue, 3 Jul 2012 02:06:19 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8921F86DB; Tue, 3 Jul 2012 02:06:16 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 03 Jul 2012 11:06: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); Tue, 3 Jul 2012 11:06:18 +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 Jul 2012 11:06:18 +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 Jul 2012 11:06:17 +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 Jul 2012 10:06:16 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01711737@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: Ac1Y8pEnW9bdVnJPRhu8hafq0xCkWAABShYg References: From: "John Dowdell" To: "manet" , X-OriginalArrivalTime: 03 Jul 2012 09:06:17.0782 (UTC) FILETIME=[1B121D60:01CD58FB] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19014.005 X-TM-AS-Result: No--12.334600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Alexandru Petrescu , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:06:20 -0000 Alex, Abdussalam and all Ref the discussion below, Q2 in particular, I'm happy to be corrected = but I cannot see how Mobile IP will work with no infrastructure and = direct node-to-node communications. Is not Mobile IP used when roaming = onto another provider's network (termed the foreign network) to create a = care-of address, and DIAMETER used to verify the roaming devices = authorisation to access services on the home and foreign network? In = this scenario using IPv4, home and foreign agent servers in the = infrastructure are used to handle and validate the requests. In IPv6, I = understand there is no foreign agent, but there is still a single home = agent. In the Q2 scenario below, surely IPv6 neighbour discovery is sufficient? = ND is then linked to the routing protocol process to discover the = adjacent routers. But thanks for bringing ITS to my attention. I'm off to join the list. John =20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Alexandru Petrescu Sent: 03 July 2012 08:59 To: Abdussalam Baryun Cc: manet; its@ietf.org Subject: Re: [manet] [its] Scenarios, potential topics... Hi Abdussalam and thanks for the reply. Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : > Hi Alex and All, > >> Scenario : A router deployed in a moving vehicle, uses its egress >> interface to connect to larger-area access network(s) or to other >> vehicles. > > Should it use Mobile IP? Hmm... that is a good question and much can be said about it. I am interested to liste others' oppinions as well. I think Mobile IP may be necessary but not sufficient. In the case of direct vehicle-to-vehicle IP communications (non covered areas) Mobile IP may not be necessary. It may be that extensions to Neighbor Discovery and DHCP could help establish paths within local topologies. And, when that is done (e.g. exchange routes between two vehicles using RA) it may become apparent that interactions between Mobile IP and this mechanism may be necessary. > IMO that vehicle routers communications depend on both their > communication protocols and the used-network for such communication > (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO > there is no doubt that Mobile IP [RFC6275] is needed for the router's > if the communication is through the Internet's domain(s), but if it > is through Ad-hoc networks' domain(s) it MAY not be used. I tend to agree that Mobile IP may not be needed between vehicles which communicate directly without infrastructure. Then one wonders _what_ is needed? From alexandru.petrescu@gmail.com Tue Jul 3 02:38: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 09E8021F87C1; Tue, 3 Jul 2012 02:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 5y00bdiv5vJf; Tue, 3 Jul 2012 02:38:26 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C021F8639; Tue, 3 Jul 2012 02:38:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q639cSM7031970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2012 11:38:29 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q639cSFx006297; Tue, 3 Jul 2012 11:38:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q639cOxk003245; Tue, 3 Jul 2012 11:38:28 +0200 Message-ID: <4FF2BD91.6050007@gmail.com> Date: Tue, 03 Jul 2012 11:38:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Dowdell References: <1B40484159234F4FB6FE11D4C2F408DE01711737@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01711737@SUKNPT8108.cogent-dsn.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:38:27 -0000 Le 03/07/2012 11:06, John Dowdell a écrit : > Alex, Abdussalam and all > > Ref the discussion below, Q2[Should it use Mobile IP?] in > particular, I'm happy to be corrected but I cannot see how Mobile IP > will work with no infrastructure and direct node-to-node > communications. Node-to-node communications may indeed not be the right application for the Mobile IP protocol. MIP has at least 3 entities: MN, HA and CN, whereas node-to-node it's but 2. A vehicular scenario would depict a vehicle as a set of nodes deployed in one vehicle; some of these nodes may be communicating with other nodes in another vehicle nearby; each vehicle would also hold a Router on-board. In such a scenario, maybe 'node-to-node' may mean that one such node (an LFN) communicates to another node (another LFN) in another vehicle through their respective Mobile Routers. This would become a problem of how to assign addresses or how to set up routes between the two vehicles such that this node-to-node communication can happen. Protocols to assign addresses would be DHCP and Stateless Autoconf (not DIAMETER since there is no central auth server) and maybe forming local addresses based on manufacturer identifiers. Protocols to establish routes would be routing protocols or simpler. > Is not Mobile IP used when roaming onto another provider's network > (termed the foreign network) to create a care-of address, and > DIAMETER used to verify the roaming devices authorisation to access > services on the home and foreign network? In this scenario using > IPv4, home and foreign agent servers in the infrastructure are used > to handle and validate the requests. In IPv6, I understand there is > no foreign agent, but there is still a single home agent. I agree with most points in this above paragraph. > In the Q2 scenario below, surely IPv6 neighbour discovery is > sufficient? ND is then linked to the routing protocol process to > discover the adjacent routers. I don't know. I think ND is well adapted for simpler and well-defined topologies. A 'star' topology using nearby vehicles, and only one well defined IP-subnet link between the egress interfaces between the mobile routers may be such simple topology. (even in the simpler topologies, ND has a shortcoming in that (1) does not exchange routes and (2) does not assign prefixes - both could be solved by extending ND). The simple topologies are exposed in many real-world scenarios: incident static scene, traffic jam, billboard advertisement vehicles, and more. For more complex topologies, this could further be discussed. Simple vs complex - I think it's impossible to define one protocol that would be applicable in all vehicular scenarios. Listening, Alex > But thanks for bringing ITS to my attention. I'm off to join the > list. > > > John > > > -----Original Message----- From: manet-bounces@ietf.org > [mailto:manet-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 03 July 2012 08:59 To: Abdussalam Baryun Cc: manet; its@ietf.org > Subject: Re: [manet] [its] Scenarios, potential topics... > > Hi Abdussalam and thanks for the reply. > > Le 01/07/2012 19:31, Abdussalam Baryun a écrit : >> Hi Alex and All, >> >>> Scenario : A router deployed in a moving vehicle, uses its >>> egress interface to connect to larger-area access network(s) or >>> to other vehicles. >> > >> Should it use Mobile IP? > > Hmm... that is a good question and much can be said about it. I am > interested to liste others' oppinions as well. > > I think Mobile IP may be necessary but not sufficient. In the case > of direct vehicle-to-vehicle IP communications (non covered areas) > Mobile IP may not be necessary. It may be that extensions to > Neighbor Discovery and DHCP could help establish paths within local > topologies. > > And, when that is done (e.g. exchange routes between two vehicles > using RA) it may become apparent that interactions between Mobile IP > and this mechanism may be necessary. > >> IMO that vehicle routers communications depend on both their >> communication protocols and the used-network for such >> communication (my answer of both Q1 and Q2). In particular, to >> answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is >> needed for the router's if the communication is through the >> Internet's domain(s), but if it is through Ad-hoc networks' >> domain(s) it MAY not be used. > > I tend to agree that Mobile IP may not be needed between vehicles > which communicate directly without infrastructure. Then one wonders > _what_ is needed? > > > From abdussalambaryun@gmail.com Tue Jul 3 04:24: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 E1C9621F87EC; Tue, 3 Jul 2012 04:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 k26AMwQ85M6R; Tue, 3 Jul 2012 04:24:09 -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 7C82E21F86FA; Tue, 3 Jul 2012 04:24:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4536036vbb.31 for ; Tue, 03 Jul 2012 04:24:16 -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=m083XjFfH0EUxb6vgYU8i6j1omQNdjqvt27IPivW5Zw=; b=viY/egFGImJapOLlKWhl2U8A9AZCkAsnivzuEd4XwMsHaetUOPqByiUS5wFyd1Aa6y WYTNEOsysgPtlZObZhf/mfdKkYFD4tMK3NlLjtkn4pajR/x+QnX91S878vxm/gLFj5x2 anhNohIFMhAj22KoSk5/EBodAa412wlJsEzzu+o6ZElkEcd6Vvs3dD6o1yb8JtGU+Oib ruoymrtB+W9Q6cwYvsrN+2vhE1uhGvpLu9rYYlSFAQlQcfCm5BL04797PKz3Cl9wvdSp YtsO06XsE2aDpIPH+i4m8jIKzPf2hc09o/unLkUEuaXI8khp46MFmdTGZ5iOQCAeDup8 27ZQ== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr6531999vdb.66.1341314656627; Tue, 03 Jul 2012 04:24:16 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Tue, 3 Jul 2012 04:24:16 -0700 (PDT) Date: Tue, 3 Jul 2012 13:24:16 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll , ietf Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:24:12 -0000 Dear All I completed the first version of draft on terminology and submited the draft yesterday (with getting some techniq problem), but needed to post to know the community feedback and advise. There are other terms that was not yet included which will need some advise from you. Thanking you, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Abbreviations Used in The submitted Document AH Authentication Header DAD Duplicate Address Detection DPD Duplicate Packet Detection DoS Denial of Service ESP Encapsulating Security Payload IP IPv4 or IPv6 ICMP Internet Control Message Protocol IIB Interface Information Base ETX Estimated Expected number of Transmission FIB Forwarding Information Base LQI Link Quality Indicator L2 Data Link Layer (i.e. 2nd layer in ISO model) L3 Internet Layer (i.e. 3rd layer in ISO model) LLN Low power and Lossy Network MAC Mediam Access Control MIB Management Information Base MTU Maximum Transmission Unit NBMA Non-Broadcast Multi-Access link NHDP Neighborhood Discovery Protocol ND IP Neighbor Discovery OSPF Open Shortest Path First RIB Routing Information Base SMF Simplified Multicast Forwarding TCP Transmission Control Protocol UDP User Datagram Protocol 2.3 Definitions for MANET Terms 2.3.1 Terms Definition of MANET Communication: Communications=92 Technology or Facility: The means employed by two or more devices/subsystems to transfer and/or receive information between them in one way or two way communication. MANET communications often uses the wireless transmission medium(s) and MAY use some wired mediums (e.g. free space, air, water, antenna, coaxial cables, etc.) Communication Medium: The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, satellite system, etc.) that the routing device uses to communicates through the transmission medium(s), by providing connectionless and/or connection services that MAY be established. The system medium includes MAC layer and MAY include the physical Layer. Communication Channel: A subdivision of the physical communication medium (i.e. radio carrier signal bandwidth, or the system bandwidth) allowing possibly shared independent uses of the medium. Channels may be made available by subdividing the medium into; distinct time slots, distinct spectral bands, or coding sequence, etc. MANET Protocol: The communication system/subsystem that operates and maintains the ad hoc communication technology or facility within MANET. MANET routing Protocols often apply distributed algorithms/techniques to disseminate or forward routing messages within a MANET routing domain. Topology: An abstract representation of a network (physical or logical), as a graph (G) whose topology is defined by a set of routers/bridges (V) that communicate through set of links (E), where the G =3D (V, E). Physical-level Topology: A topology of the communication medium networks consists of routing devices and physical links. This topology information is updated by devices=92 technology in the L2 information Base. Network-level Topology: A topology of the communication system networks consists of routers and links. This topology information is updated by routers in its RIB. Multihop MANET: A MANET that its node(s) MAY need(s) more than one IP hop to reach the destination. Reactive Routing: An on-demand based routing protocol that operates route discover and maintainance the route(s), to reach the demanded destination(s). Proactive Routing: A topology RIB based routing protocol that operates routes and maintains the network topology, to reach its known destination(s). Each router maintains routes to all reachable destinations at all times, whether or not there is currently any demand to deliver packets to those destinations. Upper Layer: a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). MANET Domain: TBD MANET Signaling: Sending and exchanging some MANET messages/information. 2.3.2 Terms Definition of MANET Elements Node: A device/subsystem that MUST implement IP and SHOULD participate in MANET signaling. It either runs a MANET routing protocol or participate in MANET signaling. Router: A MANET node that MUST implement a MANET routing protocol and forwards IP packets not explicitly addressed to itself. Host: A node that is not a router. All destinations in MANET that receive delivered data are hosts. Link: A link between two node interfaces. This link may be Logical (i.e. virtual) link or physical link. Logical links are between two logical interfaces and physical links are between two physical interfaces. Links are either unidirectional or bidirectional (links may be on-link and off-link: see RFC4861). Physical Link: a communication facility or medium over which the nodes can communicate at the link layer, i.e., the layer immediately below IP. Physical interfaces are the nodes=92 attachment to physical links. Physical Link types are point-to-point, NBMA, multicast capable, and shared-media, etc (see link types in ND [RFC4861]). Logical (virtual) Link: a communication facility (at L3, or upper-layer) over which nodes can communicate. This logical link is between two MANET interfaces exists if either can be heard by the other. Link MTU: the maximum transmission unit (i.e. maximum unit size in octets), that can be conveyed in one transmission unit over the link. Node Interface: A node's point of attachment to a link. Each node MUST have at least one interface that SHOULD be assigned an IP address. If there is/are more than one interface(s) per node then the additional interface(s) MAY be assigned an IP address. If an interface is not assigned to an IP address it MUST be identified by the MANET routing protocol. An interface MAY be assigned one or more addresses. MANET Interface: A node interface that participate in; exchange MANET information used in MANET routing or exchange information in MANET neighbor node discovery (e.g as the term used in RFC6130). A MANET interface MUST be assigned to least one address to communicate. A router interface MUST be assigned a routable address which is the main address for the interface. 2.3.3 Terms Definition of MANET Identifications: An interface MAY be assigned one or more addresses. If the interface is a logical interface it MAY be assigned to only logical addresses, but if it is a physical interface MAY be assigned with physical address (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, MANET addresses). MANET Address A MANET-subnet, node, or interface address. Node and interface addresses are either IP addresses or RFC5444 addresses. All subnet addresses are unicast IP addresses. Address Block and TLV: as specified in RFC5444 Routable address: A subnet address which can be a destination address. A router MUST be able to distinguish a routable address from a non-routable address. Broadcast, and multicast addresses, limited in scope to less than the entire MANET, MUST NOT be considered as routable addresses. Anycast addresses MAY be considered as routable addresses. Main address A routable address (MANET address) that is assigned to one router's MANET interface. Originator address: A node address of the node that originated a MANET message (this message MUST include the originator address). It MAY be a routable or an unroutable address. subnet prefix A bit string that consists of some number of initial bits of an IP address. Interface identifier the remaining low-order bits in the node's IP address after the subnet prefix. A number used to identify a node's interface on a link. 2.3.4 Terms Definition of MANET exchange information formats: Packet: A MANET packet of a header plus payload. These packets are either IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated in IP packet. Packets are generated by nodes to be sent to destination(s) through MANET or through the Internet. RFC5444 packets information MAY not be used only by MANET routers. Message: A MANET data message or routing control message. Routing control messages are either MANET routing protocol messages or/and RFC5444 messages. Type Length Value coding (TLV): A generic way to represent MANET information (as in [RFC5444] and [RFC5497]). Frame: A L2 protocol TLV with a header and payload. In some technologies the L2 operates a MANET routing protocol as a local area networking system. Frames MAY encapsulate MANET packets to be tunneled through a telecommunication network. Route Request Message (RREQ) A message is used to discover a valid route to a particular destination address, called the RREQ Target Node. When a router processes a RREQ it learns routing information on how to Originator Node. Route Reply Message (RREP) A message is used to disseminate routing information about the RREP Target Node to the RREQ Originator Node and the intermediate routers. Route Error Message (RERR) A message is used to disseminate the information that a route is not available for one or more particular addresses. A RERR message is used to indicate that a router does not have a forwarding route to one or more particular addresses. 2.3.5 Terms Definition Related to MANET Protocol Operation: Hop-by-hop Routing: (TBD) A dynamic routing that routes to destination by routing table. Source Routing: (TBD) A dynamic routing that its route path is provided in the IP packet. Route Discovery: TBD Route Maintenance: TBD Neighbor discovery: (TBD) A node discovers neighbors only if the node receives from it's neighbors. Multipoint relay (MPR): (TBD) A router X1 is an MPR for a router Y1, if router Y1 has indicated its selection of router X1 as an MPR in a recent HELLO message. Router X1 may be a flooding MPR for Y1 if it is indicated to participate in the flooding process of messages received from router Y1, or it may be a routing MPR for Y1, if it is indicated to declare link-state information for the link from X1 to Y1. It may also be both at the same time. MPR selector: A router, Y, is a flooding/routing MPR selector of router X if router Y has selected router X as a flooding/routing MPR. Router Parameters: boolean or numerical values, specified for each router, and not specific to an interface. A router MAY change router parameter values at any time, subject to some MANET constraints. MANET Routing Metric: A MANET routing cost that is governed by specific rules and properties defined by the MANET routing protocol which captures specific link or node characteristics. Examples of basic metrics are hop-count, ETX, LQI, etc. Distance Vector Metric A metric class related to rules of the MANET interface and MANET path distance. The metric can be calculated by the distance vector routing algorithm class used by the MANET routing protocol. A metric of the distance a message or piece of information has traversed. The minimum value of distance is the number of IP hops traversed. Link State Metric A metric type related to the MANET network-topology status and logical links' states. This metric is calculated by the link state routing algorithm class used by the MANET routing protocol. A metric type maybe EXT, LQL, etc. Link Metric: TBD Neighbor Metric: TBD Path accumulated: The RREQ message accumulates intermediate routers that are in path to destination(s). Protocol Sequence Number: A Sequence Number related to a MANET protocol that maintained by each protocol subsystem process. This sequence number is used by other subsystems to identify the temporal order of protocol information generated. Router Sequence Number: A router sequence number is maintained by each router process. The sequence number is used by other routers to identify the temporal order of routing information generated and ensure loop-free routes. MANET Information Base: A collection of information (in Table or Cache structure) maintained by MANET protocols and which is to be made available to MANET routing protocols. An Information Base may be associated with a MANET router or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB). RIB Entry: The RIB entry is a conceptual data structure. Implementations may use any internal representation that conforms to the semantics of a route as specified in the router specification. 3. IP Considerations and Terminology All MANET nodes MUST implement IP and all MANET routers MUST run/implement at least one MANET routing protocol. The terminologies described in this document can be used for IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 packets but IPv6 addresses MUST not be in IPv4 packets. IP address: IPv4 addresses or IPv6 addresses. IP Packet: The packet header plus payload as specified in [RFC791] and [RFC2460] for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as specified by RFC5498. Mobile IP considerations: Mobile IP terms are provided in [RFC6275], and this technology assists nodes while connected through the Internet domain(s). MANET is an infrastructure-less network that is able to communicate with the Internet (i.e. an IP infrastructure network). 4. Security Consideration and Terminology It is RECOMMENDED that MANET routing protocols consider security issues because the MANET's transmission medium is wireless which make it vulnerable to attacks [ANJUM][RFC4593]. In some situations the routing information while traversing the MANET MAY be used by an intruder node, to obtain MANET data traffic or/and attack the MANET [HERBERG]. Forwarding protocols that use DPD techniques MAY be vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured by using IPsec, AH, DAD, and ESP techniques, and other. However, it is RECOMMENDED that MANET detects attackers and possible threats. The following are some terminology related to MANET threats and security. Attacker: A node, present in the network and which intentionally seeks to compromise information based in MANET router(s). The Attacker MAY be a compromised MANET router if obtained MANET identity or routing information. Compromised MANET Router: An attacker router, present in MANET and which generates syntactically correct routing control messages. Control messages emitted by compromised router(s) may contain additional information, or omit information, as compared to a control message generated by a non-compromised router located in the same MANET topological position. Legitimate MANET Router: A MANET router, which is not a Compromised MANET Router. Jamming Attack: The attacker transmits massive amounts of interfering radio traffic, which will prevent legitimate traffic (e.g., routing and data traffic) on all or part of the MANET. Indirect jamming attacks MAY occur by influencing Legitimate MANET Router to transmit unnecessary information. Eavesdropping: Obtaining a copy by the attacker of the transmitted MANET routing information or the transmitted data information from its neighbor's transmitted radio packet. Attacker=92s processes MANY be used by attacker to mislead routing. Eavesdropping does not pose a direct threat to the MANET or to its routing. Identity Spoofing: Attacker sends routing messages, pretending to have the MANET identity of another node. Link Spoofing: Compromised MANET router sends routing messages to neighbor node(s) providing incorrect set of link information. Replay Attack: A Compromised router in one MANET region records control traffic information and replays the recorded information in a different MANET region (this type of attack is also called the Wormhole attack). Broadcast Storm: Compromised MANET router may attack the MANET by attempting to change the MANET flooding algorithm(s) to increase routing overheads or/and to increase the route discovery delay. Broadcast storm degrades the data traffic delivery and MANET performance. Falsification in MANET: The compromised MANET router sends false routing information into MANET. False routing information received in MANET, MAY create unrealistic information bases. ICMP Attacks: The generation of ICMPv6 error messages may be used by compromised MANET router to attempt DoS attacks by sending an error-causing source routing header in back-to-back datagrams. As the ICMP messages are passed to the upper-layer processes, it is possible to perform attacks on the upper layer protocols (e.g., UDP, TCP). Protocols at the upper layers are RECOMMENDED to perform some form of validation to ICMP messages (using the information contained in the payload of the ICMP message) before acting upon them. Source Routing Attacks: TBD Acknowledgments: This work has used/modified terms of the following documents: RFC2462, RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], Gratefully acknowledge to the IETF community and all contributions. Reference: [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for NHDP", Work in progress, March, 2012. [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc Networks", John Wiley & Sons, March 2007. ISBN: 978-0-471-75688-0. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I hope to get some advise from the Internet community to make the definitions more suitable/accurate, because I MAY misunderstood. Thanking you, Best Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From yi.jiazi@gmail.com Tue Jul 3 06:55: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 2FF0C21F87B2 for ; Tue, 3 Jul 2012 06:55:31 -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 1dbNwLnoPbLA for ; Tue, 3 Jul 2012 06:55:21 -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 69F7721F87E0 for ; Tue, 3 Jul 2012 06:55:20 -0700 (PDT) Received: by werp11 with SMTP id p11so1568237wer.31 for ; Tue, 03 Jul 2012 06:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=hEGr7RTLDcu4eWtHrRDhif1fVOVZ8O6lQxL0YXozEsc=; b=vN9I/yDegqN4Eh49NqPSaniVvKpr8jsLQpT4mpHdzejF19txFeRyAgT1TAWsB+MYqE W3KleCrjdsU3iaF9VFTretdwRgw40GvfrWDLummogl9A92VmZ7h0hv+L2UEGg70GsTRh Ky1hUZmdKN7TCjswQZZyHT0SgdwHTBJ09nOXQ3/6FzUfsTt+0nKRwKPgC6ZvX+VT5xqu mhTdAVKPdHCSy+2X9LgZI6LnEpOnd8Nj38dAOsVfmct9UCPVo0WJkawdO+9HDYvWv/5d BUAA1s+xr+xmmJJyu7fT5ZbjI6GDPOjfitWqCDtuyHxvnc9tNcxlO0GtZvcOWSycM0vq pkFQ== Received: by 10.180.99.196 with SMTP id es4mr25463593wib.18.1341323727514; Tue, 03 Jul 2012 06:55:27 -0700 (PDT) Received: from [192.168.112.242] (sphinx.lix.polytechnique.fr. [129.104.11.1]) by mx.google.com with ESMTPS id cl8sm31047553wib.10.2012.07.03.06.55.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 06:55:26 -0700 (PDT) Sender: Jiazi YI From: Jiazi YI Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9BC354B4-7299-4A18-A3A6-3BB046502AB6" Date: Tue, 3 Jul 2012 15:55:25 +0200 In-Reply-To: To: manet References: Message-Id: <0318325F-2830-41FB-AF69-913774D66085@jiaziyi.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [manet] [Roll] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 13:55:31 -0000 --Apple-Mail=_9BC354B4-7299-4A18-A3A6-3BB046502AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Abdussalam,=20 I had a quick look of your draft, here are some very general and quick = comments: 1. I didn't get the scope of this document. The definitions are from = "Communication Medium" to protocol-specific term like "Route Reply = Message (RREP)", and even security. I don't think it's necessary to go = from the general terms of telecommunication to some specified protocols = -- if you define RREP, why not HELLO, TC, and all other message types in = the other protocols?=20 2. A lot of definitions are quite vague and do not make much sense, for = example: > "Upper layer" this can be only used in certain context, but not a an depenent term.=20= >Reactive Routing: >An on-demand based routing protocol that operates route discover and >maintainance the route(s), to reach the demanded destination(s). what's an on-demand based routing procotol then? A reactive routing? >Message: >A MANET data message or routing control message.=20 You are trying to define "message" using "message"? And=20 >Routing control messages are either MANET routing protocol messages = or/and RFC5444 >messages. I'm confused with the relation between routing protocol message and RFC = 5444 messages when saying this...=20 Are you tying to say: a chicken can be either a white chicken or/and a = cock? plus, RFC 5444 defines both packet and message... 3. There are a lot controversial terms (phy link, logic link, subnet = prefix...) and terms that rarely used in the protocols ( Protocol = Sequence Number/Router Sequence Number, Distance Vector Metric/Link Stat = Metric, or I don't really know what they really are). Personally, I'm against to have this kind of document that "tries to = define everything", with the reasons that the others have stated before.=20= YI Jiazi http://www.jiaziyi.com LIX, Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex France On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: > Dear All >=20 > I completed the first version of draft on terminology and submited the > draft yesterday (with getting some techniq problem), but needed to > post to know the community feedback and advise. There are other terms > that was not yet included which will need some advise from you. > Thanking you, >=20 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Abbreviations Used in The submitted Document >=20 > AH Authentication Header > DAD Duplicate Address Detection > DPD Duplicate Packet Detection > DoS Denial of Service > ESP Encapsulating Security Payload > IP IPv4 or IPv6 > ICMP Internet Control Message Protocol > IIB Interface Information Base > ETX Estimated Expected number of Transmission > FIB Forwarding Information Base > LQI Link Quality Indicator > L2 Data Link Layer (i.e. 2nd layer in ISO model) > L3 Internet Layer (i.e. 3rd layer in ISO model) > LLN Low power and Lossy Network > MAC Mediam Access Control > MIB Management Information Base > MTU Maximum Transmission Unit > NBMA Non-Broadcast Multi-Access link > NHDP Neighborhood Discovery Protocol > ND IP Neighbor Discovery > OSPF Open Shortest Path First > RIB Routing Information Base > SMF Simplified Multicast Forwarding > TCP Transmission Control Protocol > UDP User Datagram Protocol >=20 > 2.3 Definitions for MANET Terms >=20 > 2.3.1 Terms Definition of MANET Communication: >=20 > Communications=92 Technology or Facility: > The means employed by two or more devices/subsystems to transfer > and/or receive information between them in one way or two way > communication. MANET communications often uses the wireless > transmission medium(s) and MAY use some wired mediums (e.g. free > space, air, water, antenna, coaxial cables, etc.) >=20 > Communication Medium: > The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, > satellite system, etc.) that the routing device uses to communicates > through the transmission medium(s), by providing connectionless = and/or > connection services that MAY be established. The system medium > includes MAC layer and MAY include the physical Layer. >=20 > Communication Channel: > A subdivision of the physical communication medium (i.e. radio carrier > signal bandwidth, or the system bandwidth) allowing possibly shared > independent uses of the medium. Channels may be made available by > subdividing the medium into; distinct time slots, distinct spectral > bands, or coding sequence, etc. >=20 > MANET Protocol: > The communication system/subsystem that operates and maintains the > ad hoc communication technology or facility within MANET. MANET = routing > Protocols often apply distributed algorithms/techniques to disseminate > or forward routing messages within a MANET routing domain. >=20 > Topology: > An abstract representation of a network (physical or logical), as a > graph (G) whose topology is defined by a set of routers/bridges (V) = that > communicate through set of links (E), where the G =3D (V, E). >=20 > Physical-level Topology: > A topology of the communication medium networks consists of routing > devices and physical links. This topology information is updated by > devices=92 technology in the L2 information Base. >=20 > Network-level Topology: > A topology of the communication system networks consists of routers = and > links. This topology information is updated by routers in its RIB. >=20 > Multihop MANET: > A MANET that its node(s) MAY need(s) more than one IP hop to reach the > destination. >=20 > Reactive Routing: > An on-demand based routing protocol that operates route discover and > maintainance the route(s), to reach the demanded destination(s). >=20 > Proactive Routing: > A topology RIB based routing protocol that operates routes and = maintains > the network topology, to reach its known destination(s). Each router > maintains routes to all reachable destinations at all times, whether = or > not there is currently any demand to deliver packets to those > destinations. >=20 > Upper Layer: > a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >=20 > MANET Domain: TBD >=20 > MANET Signaling: > Sending and exchanging some MANET messages/information. >=20 > 2.3.2 Terms Definition of MANET Elements >=20 > Node: > A device/subsystem that MUST implement IP and SHOULD participate in > MANET signaling. It either runs a MANET routing protocol or = participate > in MANET signaling. >=20 > Router: > A MANET node that MUST implement a MANET routing protocol and forwards > IP packets not explicitly addressed to itself. >=20 > Host: > A node that is not a router. All destinations in MANET that receive > delivered data are hosts. >=20 > Link: > A link between two node interfaces. This link may be Logical > (i.e. virtual) link or physical link. Logical links are between two > logical interfaces and physical links are between two physical > interfaces. Links are either unidirectional or bidirectional > (links may be on-link and off-link: see RFC4861). >=20 >=20 > Physical Link: > a communication facility or medium over which the nodes can > communicate at the link layer, i.e., the layer immediately below > IP. Physical interfaces are the nodes=92 attachment to physical links. > Physical Link types are point-to-point, NBMA, multicast capable, > and shared-media, etc (see link types in ND [RFC4861]). >=20 > Logical (virtual) Link: > a communication facility (at L3, or upper-layer) over which nodes can > communicate. This logical link is between two MANET interfaces exists > if either can be heard by the other. >=20 > Link MTU: > the maximum transmission unit (i.e. maximum unit size in octets), that > can be conveyed in one transmission unit over the link. >=20 >=20 > Node Interface: > A node's point of attachment to a link. Each node MUST have at least = one > interface that SHOULD be assigned an IP address. If there is/are more > than one interface(s) per node then the additional interface(s) MAY be > assigned an IP address. If an interface is not assigned to an IP = address > it MUST be identified by the MANET routing protocol. An interface MAY = be > assigned one or more addresses. >=20 > MANET Interface: > A node interface that participate in; exchange MANET information used = in > MANET routing or exchange information in MANET neighbor node discovery > (e.g as the term used in RFC6130). A MANET interface MUST be assigned = to > least one address to communicate. A router interface MUST be > assigned a routable address which is the main address for the = interface. >=20 >=20 > 2.3.3 Terms Definition of MANET Identifications: >=20 > An interface MAY be assigned one or more addresses. If the interface = is > a logical interface it MAY be assigned to only logical addresses, but = if > it is a physical interface MAY be assigned with physical address > (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, > MANET addresses). >=20 >=20 > MANET Address > A MANET-subnet, node, or interface address. Node and interface = addresses > are either IP addresses or RFC5444 addresses. All subnet addresses are > unicast IP addresses. >=20 > Address Block and TLV: as specified in RFC5444 >=20 > Routable address: > A subnet address which can be a destination address. A router MUST be > able to distinguish a routable address from a non-routable address. > Broadcast, and multicast addresses, limited in scope to less than the > entire MANET, MUST NOT be considered as routable addresses. Anycast > addresses MAY be considered as routable addresses. >=20 > Main address > A routable address (MANET address) that is assigned to one router's > MANET interface. >=20 > Originator address: > A node address of the node that originated a MANET message (this = message > MUST include the originator address). It MAY be a routable or an > unroutable address. >=20 > subnet prefix > A bit string that consists of some number of initial bits of an IP > address. >=20 > Interface identifier > the remaining low-order bits in the node's IP address after the subnet > prefix. A number used to identify a node's interface on a link. >=20 > 2.3.4 Terms Definition of MANET exchange information formats: >=20 > Packet: > A MANET packet of a header plus payload. These packets are either > IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated > in IP packet. Packets are generated by nodes to be sent to > destination(s) through MANET or through the Internet. RFC5444 packets > information MAY not be used only by MANET routers. >=20 > Message: > A MANET data message or routing control message. Routing control > messages are either MANET routing protocol messages or/and RFC5444 > messages. >=20 > Type Length Value coding (TLV): > A generic way to represent MANET information (as in [RFC5444] and > [RFC5497]). >=20 > Frame: > A L2 protocol TLV with a header and payload. In some technologies the = L2 > operates a MANET routing protocol as a local area networking system. > Frames MAY encapsulate MANET packets to be tunneled through a > telecommunication network. >=20 > Route Request Message (RREQ) > A message is used to discover a valid route to a particular > destination address, called the RREQ Target Node. When a router > processes a RREQ it learns routing information on how to Originator > Node. >=20 > Route Reply Message (RREP) > A message is used to disseminate routing information about > the RREP Target Node to the RREQ Originator Node and the intermediate > routers. >=20 > Route Error Message (RERR) > A message is used to disseminate the information that a route is > not available for one or more particular addresses. A RERR message is > used to indicate that a router does not have a forwarding route > to one or more particular addresses. >=20 > 2.3.5 Terms Definition Related to MANET Protocol Operation: >=20 > Hop-by-hop Routing: (TBD) > A dynamic routing that routes to destination by routing table. >=20 > Source Routing: (TBD) > A dynamic routing that its route path is provided in the IP packet. >=20 > Route Discovery: TBD >=20 > Route Maintenance: TBD >=20 > Neighbor discovery: (TBD) > A node discovers neighbors only if the node receives from it's > neighbors. >=20 >=20 > Multipoint relay (MPR): (TBD) > A router X1 is an MPR for a router Y1, if router Y1 has indicated > its selection of router X1 as an MPR in a recent HELLO message. > Router X1 may be a flooding MPR for Y1 if it is indicated to > participate in the flooding process of messages received from > router Y1, or it may be a routing MPR for Y1, if it is indicated to > declare link-state information for the link from X1 to Y1. It may > also be both at the same time. >=20 > MPR selector: > A router, Y, is a flooding/routing MPR selector of router X if > router Y has selected router X as a flooding/routing MPR. >=20 > Router Parameters: > boolean or numerical values, specified for each router, and not > specific to an interface. A router MAY change router parameter > values at any time, subject to some MANET constraints. >=20 > MANET Routing Metric: > A MANET routing cost that is governed by specific rules and properties > defined by the MANET routing protocol which captures specific link or > node characteristics. Examples of basic metrics are hop-count, ETX, = LQI, > etc. >=20 > Distance Vector Metric > A metric class related to rules of the MANET interface and MANET path > distance. The metric can be calculated by the distance vector routing > algorithm class used by the MANET routing protocol. A metric of the > distance a message or piece of information has traversed. The minimum > value of distance is the number of IP hops traversed. >=20 > Link State Metric > A metric type related to the MANET network-topology status and logical > links' states. This metric is calculated by the link state routing > algorithm class used by the MANET routing protocol. A metric type = maybe > EXT, LQL, etc. >=20 > Link Metric: TBD >=20 > Neighbor Metric: TBD >=20 > Path accumulated: > The RREQ message accumulates intermediate routers that are in path to > destination(s). >=20 > Protocol Sequence Number: > A Sequence Number related to a MANET protocol that maintained by each > protocol subsystem process. This sequence number is used by other > subsystems to identify the temporal order of protocol information > generated. >=20 > Router Sequence Number: > A router sequence number is maintained by each router process. The > sequence number is used by other routers to identify the temporal > order of routing information generated and ensure loop-free routes. >=20 > MANET Information Base: > A collection of information (in Table or Cache structure) maintained > by MANET protocols and which is to be made available to MANET routing > protocols. An Information Base may be associated with a MANET router > or with MANET interface (e.g. route request table, IIB, RIB, FIB, = MIB). >=20 > RIB Entry: > The RIB entry is a conceptual data structure. Implementations may use > any internal representation that conforms to the semantics of a route > as specified in the router specification. >=20 > 3. IP Considerations and Terminology >=20 > All MANET nodes MUST implement IP and all MANET routers MUST > run/implement at least one MANET routing protocol. The > terminologies described in this document can be used for > IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 > packets but IPv6 addresses MUST not be in IPv4 packets. >=20 > IP address: > IPv4 addresses or IPv6 addresses. >=20 > IP Packet: > The packet header plus payload as specified in [RFC791] and = [RFC2460] > for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets = as > specified by RFC5498. >=20 > Mobile IP considerations: > Mobile IP terms are provided in [RFC6275], and this technology > assists nodes while connected through the Internet domain(s). MANET > is an infrastructure-less network that is able to communicate with > the Internet (i.e. an IP infrastructure network). >=20 > 4. Security Consideration and Terminology >=20 > It is RECOMMENDED that MANET routing protocols consider security > issues because the MANET's transmission medium is wireless which = make > it vulnerable to attacks [ANJUM][RFC4593]. In some situations the > routing information while traversing the MANET MAY be used by an > intruder node, to obtain MANET data traffic or/and attack the MANET > [HERBERG]. Forwarding protocols that use DPD techniques MAY be > vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured > by using IPsec, AH, DAD, and ESP techniques, and other. However, > it is RECOMMENDED that MANET detects attackers and possible threats. >=20 > The following are some terminology related to MANET threats and > security. >=20 > Attacker: A node, present in the network and which intentionally seeks > to compromise information based in MANET router(s). The Attacker MAY = be > a compromised MANET router if obtained MANET identity or routing > information. >=20 > Compromised MANET Router: An attacker router, present in MANET and > which generates syntactically correct routing control messages. = Control > messages emitted by compromised router(s) may contain additional > information, or omit information, as compared to a control message > generated by a non-compromised router located in the same MANET > topological position. >=20 > Legitimate MANET Router: A MANET router, which is not a Compromised > MANET Router. >=20 > Jamming Attack: > The attacker transmits massive amounts of interfering radio traffic, > which will prevent legitimate traffic (e.g., routing and data traffic) > on all or part of the MANET. Indirect jamming attacks MAY occur by > influencing Legitimate MANET Router to transmit unnecessary = information. >=20 > Eavesdropping: > Obtaining a copy by the attacker of the transmitted MANET routing > information or the transmitted data information from its neighbor's > transmitted radio packet. Attacker=92s processes MANY be used by = attacker > to mislead routing. Eavesdropping does not pose a direct threat to the > MANET or to its routing. >=20 > Identity Spoofing: > Attacker sends routing messages, pretending to have the MANET identity > of another node. >=20 > Link Spoofing: > Compromised MANET router sends routing messages to neighbor node(s) > providing incorrect set of link information. >=20 > Replay Attack: > A Compromised router in one MANET region records control traffic > information and replays the recorded information in a different MANET > region (this type of attack is also called the Wormhole attack). >=20 > Broadcast Storm: > Compromised MANET router may attack the MANET by attempting to change > the MANET flooding algorithm(s) to increase routing overheads or/and = to > increase the route discovery delay. Broadcast storm degrades the data > traffic delivery and MANET performance. >=20 > Falsification in MANET: > The compromised MANET router sends false routing information into = MANET. > False routing information received in MANET, MAY create unrealistic > information bases. >=20 > ICMP Attacks: > The generation of ICMPv6 error messages may be used by compromised = MANET > router to attempt DoS attacks by sending an error-causing source = routing > header in back-to-back datagrams. As the ICMP messages are passed to = the > upper-layer processes, it is possible to perform attacks on the upper > layer protocols (e.g., UDP, TCP). Protocols at the upper layers are > RECOMMENDED to perform some form of validation to ICMP messages (using > the information contained in the payload of the ICMP message) before > acting upon them. >=20 > Source Routing Attacks: TBD >=20 > Acknowledgments: >=20 > This work has used/modified terms of the following documents: RFC2462, > RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, > RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], > Gratefully acknowledge to the IETF community and all contributions. >=20 > Reference: > [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for > NHDP", Work in progress, March, 2012. > [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc > Networks", John Wiley & Sons, March 2007. > ISBN: 978-0-471-75688-0. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 > I hope to get some advise from the Internet community to make the > definitions more suitable/accurate, because I MAY misunderstood. > Thanking you, >=20 > Best Regards >=20 > Abdussalam Baryun > University of Glamorgan, UK > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_9BC354B4-7299-4A18-A3A6-3BB046502AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear Abdussalam, 
I had a quick look of your = draft, here are some very general and quick comments:

1. I didn't get the scope of this document. The definitions are = from "Communication Medium" to protocol-specific term like "Route Reply = Message (RREP)", and even security. I don't think it's necessary to go = from the general terms of telecommunication to some specified protocols = -- if you define RREP, why not HELLO, TC, and all other message types in = the other protocols? 

2. A lot of definitions are quite vague and do not make much = sense, for example:

> "Upper layer"
 this can be only used = in certain context, but not a an depenent term. 
what's an on-demand based = routing procotol then? A reactive routing?


>Message:
>A = MANET data message or routing control message. 

You are trying to define "message" using "message"? = And 
I'm confused with the relation between routing protocol message = and RFC 5444 messages when saying this... 
Are you tying to say: a chicken can be either a white chicken = or/and a cock?
plus, RFC 5444 defines both = packet and message...

3. There are a lot = controversial terms (phy link, logic link, subnet prefix...) and terms = that rarely used in the protocols ( Protocol Sequence Number/Router = Sequence Number, Distance Vector Metric/Link Stat Metric, or I don't = really know what they really are).
Personally, I'm against to = have this kind of document that "tries to define everything", with the = reasons that the others have stated before. 


YI = Jiazi

LIX, = Ecole Polytechnique
Route de Saclay 91128 Palaiseau Cedex = France




On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun = wrote:

Dear All

I completed the first version of = draft on terminology and submited the
draft yesterday (with getting = some techniq problem), but needed to
post to know the community = feedback and advise. There are other terms
that was not yet included = which will need some advise from you.
Thanking = you,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
= Abbreviations Used in The submitted Document

  AH =   Authentication Header
  DAD  Duplicate = Address Detection
  DPD  Duplicate Packet = Detection
  DoS  Denial of Service
=   ESP  Encapsulating Security Payload
  IP =   IPv4 or IPv6
  ICMP Internet Control Message = Protocol
  IIB  Interface Information Base
=   ETX  Estimated Expected number of Transmission
=   FIB  Forwarding Information Base
  LQI =  Link Quality Indicator
  L2   Data Link = Layer (i.e. 2nd layer in ISO model)
  L3 =   Internet Layer (i.e. 3rd layer in ISO model)
=   LLN  Low power and Lossy Network
  MAC =  Mediam Access Control
  MIB  Management = Information Base
  MTU  Maximum Transmission Unit
=   NBMA Non-Broadcast Multi-Access link
  NHDP = Neighborhood Discovery Protocol
  ND   IP = Neighbor Discovery
  OSPF Open Shortest Path First
=   RIB  Routing Information Base
  SMF =  Simplified Multicast Forwarding
  TCP =  Transmission Control Protocol
  UDP  User = Datagram Protocol

2.3 Definitions for MANET Terms

2.3.1 = Terms Definition of MANET Communication:

Communications=92 = Technology or Facility:
  The means employed by two or = more devices/subsystems to transfer
  and/or receive = information between them in one way or two way
=   communication.  MANET communications often uses the = wireless
  transmission medium(s) and MAY use some wired = mediums (e.g. free
  space, air, water, antenna, coaxial = cables, etc.)

Communication Medium:
  The = transceiver system (e.g. such as L2 systems, IEEE802.11 systems,
=   satellite system, etc.) that the routing device uses to = communicates
  through the transmission medium(s), by = providing connectionless and/or
  connection services that = MAY be established. The system medium
  includes MAC layer = and MAY include the physical Layer.

Communication Channel:
A = subdivision of the physical communication medium (i.e. radio = carrier
signal bandwidth, or the system bandwidth) allowing possibly = shared
independent uses of the medium. Channels may be made available = by
subdividing the medium into; distinct time slots, distinct = spectral
bands, or coding sequence, etc.

MANET = Protocol:
The communication system/subsystem that operates and = maintains the
ad hoc communication technology or facility within = MANET. MANET routing
Protocols often apply distributed = algorithms/techniques to disseminate
or forward routing messages = within a MANET routing domain.

Topology:
An abstract = representation of a network (physical or logical), as a
graph (G) = whose topology is defined by a set of routers/bridges (V) = that
communicate through set of links (E), where the G =3D (V, = E).

Physical-level Topology:
A topology of the communication = medium networks consists of routing
devices and physical links. This = topology information is updated by
devices=92 technology in the L2 = information Base.

Network-level Topology:
A topology of the = communication system networks consists of routers and
links. This = topology information is updated by routers in its RIB.

Multihop = MANET:
A MANET that its node(s) MAY need(s) more than one IP hop to = reach the
destination.

Reactive Routing:
An on-demand based = routing protocol that operates route discover and
maintainance the = route(s), to reach the demanded destination(s).

Proactive = Routing:
A topology RIB based routing protocol that operates routes = and maintains
the network topology, to reach its known = destination(s). Each router
maintains routes to all reachable = destinations at all times, whether or
not there is currently any = demand to deliver packets to those
destinations.

Upper = Layer:
a protocol layer above IP layer (e.g. as TCP, UDP, = OSPF).

MANET Domain: TBD

MANET Signaling:
Sending and = exchanging some MANET messages/information.

2.3.2 Terms = Definition of MANET Elements

Node:
A device/subsystem that = MUST implement IP and SHOULD participate in
MANET signaling. It = either runs a MANET routing protocol or participate
in MANET = signaling.

Router:
A MANET node that MUST implement a MANET = routing protocol and forwards
IP packets not explicitly addressed to = itself.

Host:
A node that is not a router. All destinations in = MANET that receive
delivered data are hosts.

Link:
A link = between two node interfaces. This link may be Logical
(i.e. virtual) = link or physical link. Logical links are between two
logical = interfaces and physical links are between two physical
interfaces. = Links are either unidirectional or bidirectional
(links may be = on-link and off-link: see RFC4861).


Physical Link:
a = communication facility or medium over which the nodes can
communicate = at the link layer, i.e., the layer immediately below
IP. Physical = interfaces are the nodes=92 attachment to physical links.
Physical = Link types are point-to-point, NBMA, multicast capable,
and = shared-media, etc (see link types in ND [RFC4861]).

Logical = (virtual) Link:
a communication facility (at L3, or upper-layer) over = which nodes can
communicate. This logical link is between two MANET = interfaces exists
if either can be heard by the other.

Link = MTU:
the maximum transmission unit (i.e. maximum unit size in = octets), that
can be conveyed in one transmission unit over the = link.


Node Interface:
A node's point of attachment to a = link. Each node MUST have at least one
interface that SHOULD be = assigned an IP address. If there is/are more
than one interface(s) = per node then the additional interface(s) MAY be
assigned an IP = address. If an interface is not assigned to an IP address
it MUST be = identified by the MANET routing protocol. An interface MAY = be
assigned one or more addresses.

MANET Interface:
A node = interface that participate in; exchange MANET information used = in
MANET routing or exchange information in MANET neighbor node = discovery
(e.g as the term used in RFC6130). A MANET interface MUST = be assigned to
least one  address to communicate. A router = interface MUST be
assigned a routable address which is the main = address for the interface.


2.3.3 Terms Definition of MANET = Identifications:

An interface MAY be assigned one or more = addresses. If the interface is
a logical interface it MAY be assigned = to only logical addresses, but if
it is a physical interface MAY be = assigned with physical address
(e.g. MAC address) and/or logical = address(es) (e.g. IP addresses,
MANET addresses).


MANET = Address
A MANET-subnet, node, or interface address. Node and = interface addresses
are either IP addresses or RFC5444 addresses. All = subnet addresses are
unicast IP addresses.

Address Block and = TLV: as specified in RFC5444

Routable address:
A subnet = address which can be a destination address. A router MUST be
able to = distinguish a routable address from a non-routable = address.
Broadcast, and multicast addresses, limited in scope to less = than the
entire MANET, MUST NOT be considered as routable addresses. = Anycast
addresses MAY be considered as routable = addresses.

Main address
A routable address (MANET address) = that is assigned to one router's
MANET interface.

Originator = address:
A node address of the node that originated a MANET message = (this message
MUST include the originator address). It MAY be a = routable or an
unroutable address.

subnet prefix
A bit = string that consists of some number of initial bits of an = IP
address.

Interface identifier
the remaining low-order = bits in the node's IP address after the subnet
prefix. A number used = to identify a node's interface on a link.

2.3.4 Terms Definition = of MANET exchange information formats:

Packet:
A MANET packet = of a header plus payload. These packets are either
IP packets or = RFC5444 packets. RFC5444 packet MUST be encapsulated
in IP packet. = Packets are generated by nodes to be sent to
destination(s) through = MANET or through the Internet. RFC5444 packets
information MAY not be = used only by MANET routers.

Message:
A MANET data message or = routing control message. Routing control
messages are either MANET = routing protocol messages or/and RFC5444
messages.

Type Length = Value coding (TLV):
A generic way to represent MANET information (as = in [RFC5444] and
[RFC5497]).

Frame:
A L2 protocol TLV with = a header and payload. In some technologies the L2
operates a MANET = routing protocol as a local area networking system.
Frames MAY = encapsulate MANET packets to be tunneled through a
telecommunication = network.

Route Request Message (RREQ)
A message is used to = discover a valid route to a particular
destination address, called = the RREQ Target Node. When a router
processes a RREQ it learns = routing information on how to Originator
Node.

Route Reply = Message (RREP)
A message is used to disseminate routing information = about
the RREP Target Node to the RREQ Originator Node and the = intermediate
routers.

Route Error Message (RERR)
A message = is used to disseminate the information that a route is
not available = for one or more particular addresses. A RERR message is
used to = indicate that a router does not have a forwarding route
to one or = more particular addresses.

2.3.5 Terms Definition Related to = MANET Protocol Operation:

Hop-by-hop Routing: (TBD)
A dynamic = routing that routes to destination by routing table.

Source = Routing: (TBD)
A dynamic routing that its route path is provided in = the IP packet.

Route Discovery: TBD

Route Maintenance: = TBD

Neighbor discovery: (TBD)
A node discovers neighbors only = if the node receives from it's
neighbors.


Multipoint relay = (MPR): (TBD)
A router X1 is an MPR for a router Y1, if router Y1 has = indicated
its selection of router X1 as an MPR in a recent HELLO = message.
Router X1 may be a flooding MPR for Y1 if it is indicated = to
participate in the flooding process of messages received = from
router Y1, or it may be a routing MPR for Y1, if it is indicated = to
declare link-state information for the link from X1 to Y1. It = may
also be both at the same time.

MPR selector:
A router, = Y, is a flooding/routing MPR selector of router X if
router Y has = selected router X as a flooding/routing MPR.

Router = Parameters:
boolean or numerical values, specified for each router, = and not
specific to an interface. A router MAY change router = parameter
values at any time, subject to some MANET = constraints.

MANET Routing Metric:
A MANET routing cost that = is governed by specific rules and properties
defined by the MANET = routing protocol which captures specific link or
node = characteristics. Examples of basic metrics are hop-count, ETX, = LQI,
etc.

Distance Vector Metric
A metric class related to = rules of the MANET interface and MANET path
distance. The metric can = be calculated by the distance vector routing
algorithm class used by = the MANET routing protocol. A metric of the
distance a message or = piece of information has traversed. The minimum
value of distance is = the number of IP hops traversed.

Link State Metric
A metric = type related to the MANET network-topology status and logical
links' = states. This metric is calculated by the link state routing
algorithm = class used by the MANET routing protocol. A metric type maybe
EXT, = LQL, etc.

Link Metric: TBD

Neighbor Metric: = TBD

Path accumulated:
The RREQ message accumulates = intermediate routers that are in path = to
destination(s).

Protocol Sequence Number:
A Sequence = Number related to a MANET protocol that maintained by each
protocol = subsystem process. This sequence number is used by other
subsystems = to identify the temporal order of protocol = information
generated.

Router Sequence Number:
A router = sequence number is maintained by each router process. The
sequence = number is used by other routers to identify the temporal
order of = routing information generated and ensure loop-free routes.

MANET = Information Base:
A collection of information (in Table or Cache = structure) maintained
by MANET protocols and which is to be made = available to MANET routing
protocols. An Information Base may be = associated with a MANET router
or with MANET interface (e.g. route = request table, IIB, RIB, FIB, MIB).

RIB Entry:
The RIB entry = is a conceptual data structure. Implementations may use
any internal = representation that conforms to the semantics of a route
as specified = in the router specification.

3. IP Considerations and = Terminology

  All MANET nodes MUST implement IP and = all MANET routers MUST
  run/implement  at least one = MANET routing protocol. The
  terminologies described in = this document can be used for
  IPv4-MANET and IPv6-MANET. = The IPv4 addresses MAY be used in IPv6
  packets but IPv6 = addresses MUST not be in IPv4 packets.

  IP = address:
  IPv4 addresses or IPv6 addresses.

=   IP Packet:
  The packet header plus payload as = specified in [RFC791] and [RFC2460]
  for IPv4 and IPv6 = respectively. It can encapsulate RFC5444 packets as
=   specified by RFC5498.

  Mobile IP = considerations:
  Mobile IP terms are provided in = [RFC6275], and this technology
  assists nodes while = connected through the Internet domain(s). MANET
  is an = infrastructure-less network that is able to communicate with
=   the Internet (i.e. an IP infrastructure network).

4. = Security Consideration and Terminology

  It is = RECOMMENDED that MANET routing protocols consider security
=   issues because the MANET's transmission medium is wireless = which make
  it vulnerable to attacks [ANJUM][RFC4593]. In = some situations the
  routing information while traversing = the MANET MAY be used by an
  intruder node, to obtain = MANET data traffic or/and attack the MANET
  [HERBERG]. = Forwarding protocols that use DPD techniques MAY be
=   vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be = secured
  by using IPsec, AH, DAD, and ESP techniques, and = other. However,
  it is RECOMMENDED that MANET detects = attackers and possible threats.

  The following are = some terminology related to MANET threats and
=   security.

Attacker: A node, present in the network = and which intentionally seeks
to compromise information based in = MANET router(s). The Attacker MAY be
a compromised MANET router if = obtained MANET identity or routing
information.

Compromised = MANET Router: An attacker router, present in MANET and
which = generates syntactically correct routing control messages. = Control
messages emitted by compromised router(s) may contain = additional
information, or omit information, as compared to a control = message
generated by a non-compromised router located in the same = MANET
topological position.

Legitimate MANET Router: A MANET = router, which is not a Compromised
MANET Router.

Jamming = Attack:
The attacker transmits massive amounts of interfering radio = traffic,
which will prevent legitimate traffic (e.g., routing and = data traffic)
on all or part of the MANET. Indirect jamming attacks = MAY occur by
influencing Legitimate MANET Router to transmit = unnecessary information.

Eavesdropping:
Obtaining a copy by = the attacker of the transmitted MANET routing
information or the = transmitted data information from its neighbor's
transmitted radio = packet. Attacker=92s processes MANY be used by attacker
to mislead = routing. Eavesdropping does not pose a direct threat to the
MANET or = to its routing.

Identity Spoofing:
Attacker sends routing = messages, pretending to have the MANET identity
of another = node.

Link Spoofing:
Compromised MANET router sends routing = messages to neighbor node(s)
providing incorrect set of link = information.

Replay Attack:
A Compromised router in one MANET = region records control traffic
information and replays the recorded = information in a different MANET
region (this type of attack is also = called the Wormhole attack).

Broadcast Storm:
Compromised = MANET router may attack the MANET by attempting to change
the MANET = flooding algorithm(s) to increase routing overheads or/and = to
increase the route discovery delay. Broadcast storm degrades the = data
traffic delivery and MANET performance.

Falsification in = MANET:
The compromised MANET router sends false routing information = into MANET.
False routing information received in MANET, MAY create = unrealistic
information bases.

ICMP Attacks:
The generation = of ICMPv6 error messages may be used by compromised MANET
router to = attempt DoS attacks by sending an error-causing source routing
header = in back-to-back datagrams. As the ICMP messages are passed to = the
upper-layer processes, it is possible to perform attacks on the = upper
layer protocols (e.g., UDP, TCP). Protocols at the upper layers = are
RECOMMENDED to perform some form of validation to ICMP messages = (using
the information contained in the payload of the ICMP message) = before
acting upon them.

Source Routing Attacks: = TBD

Acknowledgments:

This work has used/modified terms of = the following documents: RFC2462,
RFC2501, RFC3561, RFC3626, RFC3753, = RFC4728, RFC4861, RFC5444,
RFC6130,  RFC6621, [AODVv2], = [OLSRv2], and [HERBERG],
Gratefully acknowledge to the IETF community = and all contributions.

Reference:
  [HERBERG] = Herberg, U., Yi, J., Clausen, T.,"Security Threats for
=             NH= DP", Work in progress, March, 2012.
  [ANJUM] =   Anjum, F. and Mouchtaris, P. "Security for Wireless Ad = Hoc
=             Ne= tworks", John Wiley & Sons, March 2007.
=             IS= BN: = 978-0-471-75688-0.
++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++

I hope to get some advise from the Internet community to = make the
definitions more suitable/accurate, because I MAY = misunderstood.
Thanking you,

Best Regards

Abdussalam = Baryun
University of Glamorgan, = UK
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
_= ______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail=_9BC354B4-7299-4A18-A3A6-3BB046502AB6-- From henning.rogge@fkie.fraunhofer.de Tue Jul 3 07:31: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 ECF1411E808A for ; Tue, 3 Jul 2012 07:31: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 WzIeMAF5O-gw for ; Tue, 3 Jul 2012 07:31:39 -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 AF02C11E807F for ; Tue, 3 Jul 2012 07:31: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 1Sm48k-00077s-Kg; Tue, 03 Jul 2012 16:31: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 1Sm48k-0007XQ-Hv; Tue, 03 Jul 2012 16:31: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); Tue, 3 Jul 2012 16:31:42 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 3 Jul 2012 16:31:42 +0200 Message-ID: <4FF30247.6080303@fkie.fraunhofer.de> Date: Tue, 3 Jul 2012 16:31:35 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030106030503000808010705" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 03 Jul 2012 14:31:42.0352 (UTC) FILETIME=[909F1100:01CD5928] X-Virus-Scanned: yes (ClamAV 0.97.3/15107/Tue Jul 3 00:42:55 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 1835fb2b1f494bb0880b86f87a4ad6ad Cc: Greg Harrison , Shawn Jury , Bo Berry , Stan Ratliff Subject: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:31:40 -0000 --------------ms030106030503000808010705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I think it is time to talk about the status of the DLEP draft. We=20 stopped the discussion to give the authors time to talk about the ideas=20 of the WG about how to change and improve the draft. That was two months ago. I would like to hear an update how we should go forward with DLEP in the = Manet WG, the concept is too important to just let it stay quiet for mont= hs. Has there been a decision what Cisco thinks about all the discussions we = had in March/April? Do you work on a -03 draft updated to RFC5444=20 compatibility? I think that many members of the Manet WG are very interested to push=20 DLEP forward. Regards 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 --------------ms030106030503000808010705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA3MDMxNDMxNDBaMCMGCSqGSIb3DQEJBDEWBBT1kKGMJtQOO9cKUXBNnvngDh/UWjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAp17oVbZm/0mz/ipzvWc7TbG5IdSDcVi/Ap8J/xFDNUKu F61hR8gJqEnvdHXvnYQ27pkYa+JY9PlcFejHKfbf5FbwtaCscKceJ4ZlG4QkMwjBM64hd08S HYwQNtxjoA2OI/d3JAWFInXGRDQV4fovVlf14LSkOPb0iCGa4DpXn7K+4RH/bwznqZWzER58 C8gro0bMmIH5r+qScA8c2kqAiDgjoNg18TI27+96vgwuMwjGX8YaxRpxvSF6jYUhJ/c1Q1t4 Yzfvjf8Uop0dODdwOajDE0cqu4FRT8m8su3yQwNnxkWy4amn8+q0cZ6YaTn10qmkER5jAmad PzTu3M+DUgAAAAAAAA== --------------ms030106030503000808010705-- From sratliff@cisco.com Tue Jul 3 08:16: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 480EE11E8111 for ; Tue, 3 Jul 2012 08:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 MCUc+S+Lury0 for ; Tue, 3 Jul 2012 08:16:46 -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 A719721F8548 for ; Tue, 3 Jul 2012 08:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3044; q=dns/txt; s=iport; t=1341328615; x=1342538215; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mlAiec9cqh183azS2VRaAvrIU2flIi6/YwJgy1pHZJc=; b=mXJF/GyjGkgOVgewl2Zb3nrH70mGyP+jhLvWM+jdUNjLv/V8nkS9G7Cn i0UulYGNWLD9hJy1WdN7C+iRwk6CHS3iC2HZbBHlafzWim6LIeRNVavS2 0aKft7vGIp6QhmwsI7ACNVlEevSFO+Nk4CS251UwYufZgc/Lq7XS0qD8G E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKsM80+tJV2Z/2dsb2JhbABFtmWBB4IYAQEBAwEBAQEPAVsLBQsCAQg/BycLFBECBA4FIodkBQuaI6BEizeFOmADlTWOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98390653" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2012 15:16:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q63FGsCT011214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 15:16:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.225]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 10:16:53 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyA Date: Tue, 3 Jul 2012 15:16:50 +0000 Message-ID: <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> In-Reply-To: <4FF30247.6080303@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003 x-tm-as-result: No--48.319100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <253CA2EEA4750A4697DE8D4B06B0593B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:16:49 -0000 Henning,=20 (Based on earlier discussions, *all* of this is from the perspective of a W= orking Group Participant, and a Draft co-author/editor)... Yes, the authors are still in discussions with regard to DLEP 5444 "compati= bility". There are still roughly 3 options I see for moving forward.=20 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue = of multiple address types vis-a-vis address blocks. Also, since the reactiv= e protocol drafts being considered by the WG don't necessarily require RFC = 5444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packets,= the WG mandate that everything use 5444 seems capricious at best.=20 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leavin= g the addressing internal to DLEP. This avoids the issue of carrying multip= le address families in 5444 address blocks. I've seen several recommendatio= ns on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so = as to carry everything in address blocks of a single length. However, I see= that as a hack, plain and simple. I'm adamant that this won't fly - not at= IESG review, at least. I'll lodge the complaint against the draft myself i= f I have to on that one. In order to do that, we'd need to=85. 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple ad= dress families with a single transmission.=20 Now, if the WG chooses option 2 or 3, I *still* see an issue with respect t= o the mandate of "we must use 5444 for all drafts"=85 especially since our = reactive drafts seem to be excluded from that mandate. Long story short? I= 'm leaning towards option 1. Regards, Stan On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: > Hello, >=20 > I think it is time to talk about the status of the DLEP draft. We stopped= the discussion to give the authors time to talk about the ideas of the WG = about how to change and improve the draft. >=20 > That was two months ago. >=20 > I would like to hear an update how we should go forward with DLEP in the = Manet WG, the concept is too important to just let it stay quiet for months= . >=20 > Has there been a decision what Cisco thinks about all the discussions we = had in March/April? Do you work on a -03 draft updated to RFC5444 compatibi= lity? >=20 > I think that many members of the Manet WG are very interested to push DLE= P forward. >=20 > Regards > 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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Jul 3 08:49: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 E038C11E8119 for ; Tue, 3 Jul 2012 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 eDkTmDD7H5u6 for ; Tue, 3 Jul 2012 08:49:15 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id DCDE111E815B for ; Tue, 3 Jul 2012 08:49:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,516,1336345200"; d="scan'208";a="251912587" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Jul 2012 16:49:21 +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 q63FnLKf021158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 16:49:21 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Tue, 3 Jul 2012 16:49:20 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSipkJPtrdHUq0SlS58HjbKfcpcXmqgAgAAR+ZA= Date: Tue, 3 Jul 2012 15:49:20 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> In-Reply-To: <72CFBF30-BB0C-4BC3-9906-C733B893598F@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: "Greg Harrison \(greharri\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:49:17 -0000 I think your option 2 is missing one point. The idea to use IPv6 addresses = was when it appeared that there might be multiple address types that might = all be used as a key. But later discussion indicated that all entities shou= ld be keyed by their MAC address, with other addresses as additional inform= ation. In that case at the 5444 level, the address type would simply be len= gth =3D 16, and MAC addresses would be used as-is. IPv4 and IPv6 addresses = would go in TLVs. It's fairly clean. (How clean it is depends on whether a = TLV that carries addresses allows for compression. For DLEP I think not.) With regard to point 3, I think the last draft of DYMO was 5444 compliant. = It was Charlie taking back over from Ian who suggested it didn't need to be= 5444 compliant (and should be called AODVv2). That's a discussion the WG h= asn't had. LOADng hasn't of course been developed in MANET, though has now= been suggested to MANET, again I think with no conclusions. I thus wouldn'= t characterise the WG mandate of required use of 5444 as capricious for rou= ting protocols. Specifically I think 5444 must be used (both because 5498 s= ays so and because otherwise things break) if using the allocated manet por= t/protocol. DLEP on the other hand is not a routing protocol, doesn't need = to use the same port, and the argument is not as strong. Subject to those caveats all three are theoretical possibilities. I'm stron= gly against number 3 because of its implications for NHDP, OLSRv2 and SMF. = (I also think it actually turns out not to help DLEP.) As I've said before,= I see good arguments relating to the other two (or three: 5444 as-DLEP-is,= better fit to 5444, not 5444), and that always makes things harder. Note t= hat's a DLEP discussion, it's different for DYMO/AODVv2/LOADng (where I do = have views, but I'm not going to muddy this discussion with them). --=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 (sratliff) Sent: 03 July 2012 16:17 To: Henning Rogge Cc: Greg Harrison (greharri); manet@ietf.org; Shawn Jury; Bo Berry (boberry= ) Subject: Re: [manet] Status of DLEP-draft at Cisco? ----------------------! 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,=20 (Based on earlier discussions, *all* of this is from the perspective of a W= orking Group Participant, and a Draft co-author/editor)... Yes, the authors are still in discussions with regard to DLEP 5444 "compati= bility". There are still roughly 3 options I see for moving forward.=20 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue = of multiple address types vis-a-vis address blocks. Also, since the reactiv= e protocol drafts being considered by the WG don't necessarily require RFC = 5444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packets,= the WG mandate that everything use 5444 seems capricious at best.=20 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leavin= g the addressing internal to DLEP. This avoids the issue of carrying multip= le address families in 5444 address blocks. I've seen several recommendatio= ns on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so = as to carry everything in address blocks of a single length. However, I see= that as a hack, plain and simple. I'm adamant that this won't fly - not at= IESG review, at least. I'll lodge the complaint against the draft myself i= f I have to on that one. In order to do that, we'd need to.. 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple ad= dress families with a single transmission.=20 Now, if the WG chooses option 2 or 3, I *still* see an issue with respect t= o the mandate of "we must use 5444 for all drafts". especially since our re= active drafts seem to be excluded from that mandate. Long story short? I'm= leaning towards option 1. Regards, Stan On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: > Hello, >=20 > I think it is time to talk about the status of the DLEP draft. We stopped= the discussion to give the authors time to talk about the ideas of the WG = about how to change and improve the draft. >=20 > That was two months ago. >=20 > I would like to hear an update how we should go forward with DLEP in the = Manet WG, the concept is too important to just let it stay quiet for months= . >=20 > Has there been a decision what Cisco thinks about all the discussions we = had in March/April? Do you work on a -03 draft updated to RFC5444 compatibi= lity? >=20 > I think that many members of the Manet WG are very interested to push DLE= P forward. >=20 > Regards > 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 >=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 ietf@thomasclausen.org Tue Jul 3 09:39: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 B861211E815B for ; Tue, 3 Jul 2012 09:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK0VUL6TwuPk for ; Tue, 3 Jul 2012 09:39:49 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 997EF11E8098 for ; Tue, 3 Jul 2012 09:39:49 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id F3617557F0A for ; Tue, 3 Jul 2012 09:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3DDE61C9BE5; Tue, 3 Jul 2012 09:39:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.69.253.25] (37-8-175-78.coucou-networks.fr [37.8.175.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C553B1C9BE4; Tue, 3 Jul 2012 09:39:49 -0700 (PDT) References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <9F9E5394-A5CA-4845-8324-09B000B736C6@thomasclausen.org> X-Mailer: iPhone Mail (9B206) From: Thomas Heide Clausen Date: Tue, 3 Jul 2012 18:38:23 +0200 To: "Dearlove, Christopher (UK)" Cc: "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:39:50 -0000 Just for information, the coming version of LOADng will use 5444 (cleanly).=20= --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 On 3 juil. 2012, at 17:49, "Dearlove, Christopher (UK)" wrote: > I think your option 2 is missing one point. The idea to use IPv6 addresses= was when it appeared that there might be multiple address types that might a= ll be used as a key. But later discussion indicated that all entities should= be keyed by their MAC address, with other addresses as additional informati= on. In that case at the 5444 level, the address type would simply be length =3D= 16, and MAC addresses would be used as-is. IPv4 and IPv6 addresses would go= in TLVs. It's fairly clean. (How clean it is depends on whether a TLV that c= arries addresses allows for compression. For DLEP I think not.) >=20 > With regard to point 3, I think the last draft of DYMO was 5444 compliant.= It was Charlie taking back over from Ian who suggested it didn't need to be= 5444 compliant (and should be called AODVv2). That's a discussion the WG ha= sn't had. LOADng hasn't of course been developed in MANET, though has now b= een suggested to MANET, again I think with no conclusions. I thus wouldn't c= haracterise the WG mandate of required use of 5444 as capricious for routing= protocols. Specifically I think 5444 must be used (both because 5498 says s= o and because otherwise things break) if using the allocated manet port/prot= ocol. DLEP on the other hand is not a routing protocol, doesn't need to use t= he same port, and the argument is not as strong. >=20 > Subject to those caveats all three are theoretical possibilities. I'm stro= ngly against number 3 because of its implications for NHDP, OLSRv2 and SMF. (= I also think it actually turns out not to help DLEP.) As I've said before, I= see good arguments relating to the other two (or three: 5444 as-DLEP-is, be= tter fit to 5444, not 5444), and that always makes things harder. Note that'= s a DLEP discussion, it's different for DYMO/AODVv2/LOADng (where I do have v= iews, but I'm not going to muddy this discussion with them). >=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 S= tan Ratliff (sratliff) > Sent: 03 July 2012 16:17 > To: Henning Rogge > Cc: Greg Harrison (greharri); manet@ietf.org; Shawn Jury; Bo Berry (boberr= y) > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=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 > Henning,=20 >=20 >=20 > (Based on earlier discussions, *all* of this is from the perspective of a W= orking Group Participant, and a Draft co-author/editor)... >=20 > Yes, the authors are still in discussions with regard to DLEP 5444 "compat= ibility". There are still roughly 3 options I see for moving forward.=20 >=20 > 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue= of multiple address types vis-a-vis address blocks. Also, since the reactiv= e protocol drafts being considered by the WG don't necessarily require RFC 5= 444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packets, t= he WG mandate that everything use 5444 seems capricious at best.=20 >=20 > 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leavi= ng the addressing internal to DLEP. This avoids the issue of carrying multip= le address families in 5444 address blocks. I've seen several recommendation= s on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so as= to carry everything in address blocks of a single length. However, I see th= at as a hack, plain and simple. I'm adamant that this won't fly - not at IES= G review, at least. I'll lodge the complaint against the draft myself if I h= ave to on that one. In order to do that, we'd need to.. >=20 > 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple a= ddress families with a single transmission.=20 >=20 > Now, if the WG chooses option 2 or 3, I *still* see an issue with respect t= o the mandate of "we must use 5444 for all drafts". especially since our rea= ctive drafts seem to be excluded from that mandate. Long story short? I'm l= eaning towards option 1. >=20 > Regards, > Stan >=20 >=20 >=20 >=20 > On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: >=20 >> Hello, >>=20 >> I think it is time to talk about the status of the DLEP draft. We stopped= the discussion to give the authors time to talk about the ideas of the WG a= bout how to change and improve the draft. >>=20 >> That was two months ago. >>=20 >> I would like to hear an update how we should go forward with DLEP in the M= anet WG, the concept is too important to just let it stay quiet for months. >>=20 >> Has there been a decision what Cisco thinks about all the discussions we h= ad in March/April? Do you work on a -03 draft updated to RFC5444 compatibili= ty? >>=20 >> I think that many members of the Manet WG are very interested to push DLE= P forward. >>=20 >> Regards >> Henning Rogge >> --=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 >>=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 > ******************************************************************** > 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 Tue Jul 3 09:41: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 953F611E8140 for ; Tue, 3 Jul 2012 09:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.877, 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 QYg8tgbclWaU for ; Tue, 3 Jul 2012 09:41:18 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49D11E8169 for ; Tue, 3 Jul 2012 09:41:18 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6087726ghb.31 for ; Tue, 03 Jul 2012 09:41: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=OcFa0884x8vRpRA65bcSm0Q2XxzVRCGSBnRRjSSz9AU=; b=WrZohwm4v3rgjlPmiSBQ5/Wk2PRN1pG06yeanvorz4c56HDA98xyIXxOkPSs9x5lYX mdp42IzIe4VmJqgx+ny0lkhMVEiKbXZ35kcnJqfDB9AP9LHh/3xoO1L5BGYGMEjpoCIv PIamPREUU+kvqRDPhgVmvl+36Iw93UN17aBRo= 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=OcFa0884x8vRpRA65bcSm0Q2XxzVRCGSBnRRjSSz9AU=; b=PN0XWHuevSMTc6skfSMVAJX1jDrOUfqYdcc6CfRj5pFoKIvIE4rMAUSVAgK4LuOG3+ 5MvjZSCwQmSqY13vIyyv+Z/ry4pYuFp7rzGW0ai7L3zWjknFy1/gvU5s7fRQ/UFlePlN 7rgVEmX45WOrvKppz2+kyWQX3AoJN1US016bHuwVhW1kGUp6/DTGMz2QvRIPcrx8oH8a A9NHcsaTBfZQli+joiOwcw2eSh+Mv5b7jMt6W1hqE9pZgoWEB0kTRd1KS6QaRWO0dXZC zml/o5QG42+qCsl+wfRAQ86U4Yvt1f6CQqzJEJxQDqFFFi39ED5XUDSa4HeYmG4b2qfX gMQQ== MIME-Version: 1.0 Received: by 10.68.238.166 with SMTP id vl6mr8577293pbc.96.1341333686089; Tue, 03 Jul 2012 09:41:26 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Tue, 3 Jul 2012 09:41:26 -0700 (PDT) In-Reply-To: <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> Date: Tue, 3 Jul 2012 09:41:26 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7b33cf62e2797304c3ef95d2 X-Gm-Message-State: ALoCoQlixqCCiA1v/dC+MVbd8wzE0vwDi0Si+66bbvCC7S8DDOkFbDYV0qq8QY3RXaxQdHYwB2Cm Cc: "Greg Harrison \(greharri\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:41:20 -0000 --047d7b33cf62e2797304c3ef95d2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stan, just one comment on RFC5444 for reactive MANET protocols: I believe that the reactive MANET protocol should use RFC5444. As a side note, LOADng is currently being updated to be RFC5444 compliant. Best Ulrich On Tue, Jul 3, 2012 at 8:16 AM, Stan Ratliff (sratliff) wrote: > Henning, > > > (Based on earlier discussions, *all* of this is from the perspective of a > Working Group Participant, and a Draft co-author/editor)... > > Yes, the authors are still in discussions with regard to DLEP 5444 > "compatibility". There are still roughly 3 options I see for moving > forward. > > 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issu= e > of multiple address types vis-a-vis address blocks. Also, since the > reactive protocol drafts being considered by the WG don't necessarily > require RFC 5444 (e.g., *both* LOADng and DYMO) don't require or have > non-5444 packets, the WG mandate that everything use 5444 seems capriciou= s > at best. > > 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, > leaving the addressing internal to DLEP. This avoids the issue of carryin= g > multiple address families in 5444 address blocks. I've seen several > recommendations on how to "pretend" that a MAC address (or an IPv4 addres= s) > is IPv6, so as to carry everything in address blocks of a single length. > However, I see that as a hack, plain and simple. I'm adamant that this > won't fly - not at IESG review, at least. I'll lodge the complaint agains= t > the draft myself if I have to on that one. In order to do that, we'd need > to=85. > > 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple > address families with a single transmission. > > Now, if the WG chooses option 2 or 3, I *still* see an issue with respect > to the mandate of "we must use 5444 for all drafts"=85 especially since o= ur > reactive drafts seem to be excluded from that mandate. Long story short? > I'm leaning towards option 1. > > Regards, > Stan > > > > > On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: > > > Hello, > > > > I think it is time to talk about the status of the DLEP draft. We > stopped the discussion to give the authors time to talk about the ideas o= f > the WG about how to change and improve the draft. > > > > That was two months ago. > > > > I would like to hear an update how we should go forward with DLEP in th= e > Manet WG, the concept is too important to just let it stay quiet for mont= hs. > > > > Has there been a decision what Cisco thinks about all the discussions w= e > had in March/April? Do you work on a -03 draft updated to RFC5444 > compatibility? > > > > I think that many members of the Manet WG are very interested to push > DLEP forward. > > > > Regards > > 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 > --047d7b33cf62e2797304c3ef95d2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stan,

just one comment on RFC5444 for reactive MANET protocols: I be= lieve that the reactive MANET protocol should use RFC5444. As a side note, = LOADng is currently being updated to be RFC5444 compliant.

Best
Ulrich

On Tue, Jul 3, 2012 at 8:16 AM, St= an Ratliff (sratliff) <sratliff@cisco.com> wrote:
Henning,


(Based on earlier discussions, *all* of this is from the perspective of a W= orking Group Participant, and a Draft co-author/editor)...

Yes, the authors are still in discussions with regard to DLEP 5444 "co= mpatibility". =A0There are still roughly 3 options I see for moving fo= rward.

1) Remove RFC 5444 compatibility as a requirement. This "solves" = the issue of multiple address types vis-a-vis address blocks. Also, since t= he reactive protocol drafts being considered by the WG don't necessaril= y require RFC 5444 (e.g., *both* LOADng and DYMO) don't require or have= non-5444 packets, the WG mandate that everything use 5444 seems capricious= at best.

2) Re-work DLEP to compress the "sub-TLV's" into 5444 message= TLV's, leaving the addressing internal to DLEP. This avoids the issue = of carrying multiple address families in 5444 address blocks. I've seen= several recommendations on how to "pretend" that a MAC address (= or an IPv4 address) is IPv6, so as to carry everything in address blocks of= a single length. However, I see that as a hack, plain and simple. I'm = adamant that this won't fly - not at IESG review, at least. I'll lo= dge the complaint against the draft myself if I have to on that one. In ord= er to do that, we'd need to=85.

3) Create RFC 54444 bis, or some other update to 5444 to handle multiple ad= dress families with a single transmission.

Now, if the WG chooses option 2 or 3, I *still* see an issue with respect t= o the mandate of "we must use 5444 for all drafts"=85 especially = since our reactive drafts seem to be excluded from that mandate. =A0Long st= ory short? I'm leaning towards option 1.

Regards,
Stan




On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote:

> Hello,
>
> I think it is time to talk about the status of the DLEP draft. We stop= ped the discussion to give the authors time to talk about the ideas of the = WG about how to change and improve the draft.
>
> That was two months ago.
>
> I would like to hear an update how we should go forward with DLEP in t= he Manet WG, the concept is too important to just let it stay quiet for mon= ths.
>
> Has there been a decision what Cisco thinks about all the discussions = we had in March/April? Do you work on a -03 draft updated to RFC5444 compat= ibility?
>
> I think that many members of the Manet WG are very interested to push = DLEP forward.
>
> Regards
> 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.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D9= 44 F80D 4487 C67C 55EC CFE0
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

--047d7b33cf62e2797304c3ef95d2-- From budden@nps.edu Tue Jul 3 09:41: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 98F5711E815C for ; Tue, 3 Jul 2012 09:41:38 -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 KGm+iUKfZKpu for ; Tue, 3 Jul 2012 09:41:37 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id E33D211E816E for ; Tue, 3 Jul 2012 09:41:36 -0700 (PDT) X-ASG-Debug-ID: 1341333704-036c92049435ca70001-Rp4q3q Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id 8AbieuLPZt0GmZCX; Tue, 03 Jul 2012 09:41:44 -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.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jul 2012 09:41:43 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] [its] Scenarios, potential topics... To: Alexandru Petrescu In-Reply-To: <4FF2A65E.2080000@gmail.com> References: <4FF2A65E.2080000@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 3 Jul 2012 09:40:53 -0700 Message-ID: <1341333653.6804.875.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1341333704 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.101648 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:41:38 -0000 Alex, You just HAD to go and ask: > I am interested to hear others' oppinions as well. > One of the handful of requirements differences between emergency services and the rest of us is higher availability and survivability needs. Skipping some analysis steps, this always boils down to >1 route. > >> Scenario : A router deployed in a moving vehicle, uses its egress > >> interface to connect to larger-area access network(s) or to other > >> vehicles. So the English in the above statement is not quite right: 'interface' MUST be plural in any practical situation: interfaces. LTE is likely to be the big player for the radio-WAN, but there won't be just one instantiation. A quick scenario: an instrumented ambulance may have one or more LANs within the vehicle to which several end systems are attached -- vital signs sensors, VOIP handset for the EMT, etc. quite possibly a WiFi hotspot ... All attached to a vehicle-mounted router. The router has interfaces to 1) wired ethernet (for use while in the garage), 2) commercial LTE (where coverage exists), 3) emergency services LTE (in US, this is earmarked for 700MHz band and does not yet in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite or other radio-WAN network for rural areas not reachable by other means. Any sane high Ao engineering will be picking at least two of the above. Any help? On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: > Hi Abdussalam and thanks for the reply. > > Le 01/07/2012 19:31, Abdussalam Baryun a écrit : > > Hi Alex and All, > > > >> Scenario : A router deployed in a moving vehicle, uses its egress > >> interface to connect to larger-area access network(s) or to other > >> vehicles. > > > > Should it use IPv6-over-LTE? > > In our context we consider indeed IPv6 over LTE, for several reasons. > The 3GPP specs about LTE seem to be very specific and detailed about the > use of IPv6. (In the past, before LTE, the earlier 3GPP specs were > mentioning IPv6 but more like an option feature.) > > However, the 3GPP specs about the use of IPv6 have some lack of > specification in the case that the UE (User Terminal) is actually a > Mobile Router. The Prefix Delegation part may be underspecified. > > > Should it use Mobile IP? > > Hmm... that is a good question and much can be said about it. I am > interested to liste others' oppinions as well. > > I think Mobile IP may be necessary but not sufficient. In the case of > direct vehicle-to-vehicle IP communications (non covered areas) Mobile > IP may not be necessary. It may be that extensions to Neighbor > Discovery and DHCP could help establish paths within local topologies. > > And, when that is done (e.g. exchange routes between two vehicles using > RA) it may become apparent that interactions between Mobile IP and this > mechanism may be necessary. > > >> Open to discussion: what are the scenarios? > > We are interested in describing the scenarios. There may exist several > possibilities. I think of the following lego-like approach: > > - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. > - scenario MR-to-MR - conceive prefixes in Router Advertisements, > compare to other dynamic routing approaches. > - scenario MR-to-MR-to-Infrastructure - combine the above two. > > Another direction is classify the kinds of vehicles. I think of > something like this: > > - Internet Vehicle (has a plethora of interfaces, long- and short- > range). > - Range Extending Vehicle - extends the range of reachability. > - Leaf Vehicle - like and end-node. > > Then there are other scenario statements that could open the path to the > following: > - addressability within vehicle, ULA, VIN. > - problem of bandwidth difference between inside and outside the > vehicle. > > > What are the potential work items? What might be needed, > > if anything at all? > > > > I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS > > issues and in your questions directions. I will join the ITS-WG which > > I think can have relation to MANET [RFC2501]. > > Well, hmm. I am happy to hear that but let us go easy about this. > > "ITS" at IETF is currently just an informal effort. Its future may be > ambitious but right now it's not a WG. To do that, we'd need to make a > BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward. > > Secod, RFC2501 and ad-hoc routing are just one possibility to continue > working on this. Some people may express positive technical feedback > about MANET and others less so. > > > IMO that vehicle routers communications depend on both their > > communication protocols and the used-network for such communication > > (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO > > there is no doubt that Mobile IP [RFC6275] is needed for the router's > > if the communication is through the Internet's domain(s), but if it > > is through Ad-hoc networks' domain(s) it MAY not be used. > > I tend to agree that Mobile IP may not be needed between vehicles which > communicate directly without infrastructure. Then one wonders _what_ is > needed? > > > The Internet is an infrastructure network and Ad-hoc networks are > > infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with > > the WG answers, and will read more into the WG inputs regarding these > > issues. > > (see above note about this "WG" acronym which ITS is not currently) > > > I will schedule to participate/prepare I-D in the future for ITS > > scenarios. I am preparing an I-D on DSRv2 routing which is a MANET > > routing protocol that fits the use-case of ITS and VANET as well. > > I am interested to work on scenario/reqs drafts for ITS. > > About "DSRv2" - is it still about Routing Headers? > > I am interested to hear others' oppinions as well. > > Yours, > > Alex > > > > > Regards > > > > Abdussalam Baryun University of Glamorgan, UK > > ======================================================= > > > > From: Alexandru Petrescu To: its > > at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] > > Scenarios, potential topics... > > -------------------------------------------------------------------------------- > > > > > > > > > > > Welcome to the ITS list at IETF, an informal discussion. > > > > Earlier at IETF discussions related to vehicular communications > > happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a > > few), drafts were published [*]. At times people expressed interest > > to meet f2f. Now there is this email list. > > > > Participants are solicited to work on the topic of using IP in > > Intelligent Transportation Systems. The term ITS is a placeholder > > that, in my oppinion, is generic enough to cover many aspects of > > vehicular communications; vehicles may be wheeled, watered, flown. > > Ambulance, fire engine, coastal ship are particular examples. > > > > Scenario : A router deployed in a moving vehicle, uses its egress > > interface to connect to larger-area access network(s) or to other > > vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? > > > > Example potential work items: - Reqs for IPv6 in vehicular networks > > - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and > > IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p > > (IPv6-over-foo). - open. > > > > I am told about other vehicular drafts and discussions, that I have > > not cited, existed and still exist (about e.g. ecall). I am > > interested to learn about all the vehicular activities at IETF. > > > > Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. > > > > Open to discussion: what are the scenarios? What are the potential > > work items? What might be needed, if anything at all? > > > > Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 > > draft-jhlee-mext-mnpp-00.txt, October 2009. > > draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. > > draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. > > draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. > > draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. > > draft-petrescu-mip4-tuntype-change-00.txt, March 2011. > > draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. > > draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 > > draft-rosen-ecrit-ecall-04.txt, March 2010. > > draft-singh-simple-vehicle-info, July 2007. > > draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. > > draft-bauer-mext-aero-solspace, Sep. 2009. > > draft-bauer-mext-aero-topology, Sep. 2009. > > draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. > > draft-rosen-ecrit-ecall-05.txt, March 2012. > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Tue Jul 3 09:58: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 31FD821F85A5; Tue, 3 Jul 2012 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 EovN-0L9gqZ3; Tue, 3 Jul 2012 09:57:59 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0821F85A7; Tue, 3 Jul 2012 09:57:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,516,1336345200"; d="scan'208";a="251928931" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Jul 2012 17:58:05 +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 q63Gw4B6030160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:58:04 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Tue, 3 Jul 2012 17:58:03 +0100 From: "Dearlove, Christopher (UK)" To: Rex Buddenberg , Alexandru Petrescu Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNV69n/KKbaGBgZUG5Yv9F4+0TIpcXI2UAgACRsYCAABR1kA== Date: Tue, 3 Jul 2012 16:58:03 +0000 Message-ID: References: <4FF2A65E.2080000@gmail.com> <1341333653.6804.875.camel@localhost.localdomain> In-Reply-To: <1341333653.6804.875.camel@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:58:01 -0000 There are emergency service requirements where even 1 route would be an imp= rovement on the otherwise available 0 routes. Communications down to the pl= atform on underground railway lines would have been one on 7/7 in London. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=C2=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of R= ex Buddenberg Sent: 03 July 2012 17:41 To: Alexandru Petrescu Cc: manet; its@ietf.org; Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... ----------------------! 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. -------------------------------------------------------- Alex, You just HAD to go and ask: > I am interested to hear others' oppinions as well. >=20 One of the handful of requirements differences between emergency services and the rest of us is higher availability and survivability needs. Skipping some analysis steps, this always boils down to >1 route. =20 > >> Scenario : A router deployed in a moving vehicle, uses its egress > >> interface to connect to larger-area access network(s) or to other > >> vehicles. So the English in the above statement is not quite right: 'interface' MUST be plural in any practical situation: interfaces. =20 LTE is likely to be the big player for the radio-WAN, but there won't be just one instantiation. A quick scenario: an instrumented ambulance may have one or more LANs within the vehicle to which several end systems are attached -- vital signs sensors, VOIP handset for the EMT, etc. quite possibly a WiFi hotspot ... All attached to a vehicle-mounted router. The router has interfaces to 1) wired ethernet (for use while in the garage), 2) commercial LTE (where coverage exists), 3) emergency services LTE (in US, this is earmarked for 700MHz band and does not yet in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite or other radio-WAN network for rural areas not reachable by other means. Any sane high Ao engineering will be picking at least two of the above. =20 Any help? On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: > Hi Abdussalam and thanks for the reply. >=20 > Le 01/07/2012 19:31, Abdussalam Baryun a =C3=A9crit : > > Hi Alex and All, > > > >> Scenario : A router deployed in a moving vehicle, uses its egress > >> interface to connect to larger-area access network(s) or to other > >> vehicles. > > > > Should it use IPv6-over-LTE? >=20 > In our context we consider indeed IPv6 over LTE, for several reasons. > The 3GPP specs about LTE seem to be very specific and detailed about the > use of IPv6. (In the past, before LTE, the earlier 3GPP specs were > mentioning IPv6 but more like an option feature.) >=20 > However, the 3GPP specs about the use of IPv6 have some lack of > specification in the case that the UE (User Terminal) is actually a > Mobile Router. The Prefix Delegation part may be underspecified. >=20 > > Should it use Mobile IP? >=20 > Hmm... that is a good question and much can be said about it. I am > interested to liste others' oppinions as well. >=20 > I think Mobile IP may be necessary but not sufficient. In the case of > direct vehicle-to-vehicle IP communications (non covered areas) Mobile > IP may not be necessary. It may be that extensions to Neighbor > Discovery and DHCP could help establish paths within local topologies. >=20 > And, when that is done (e.g. exchange routes between two vehicles using > RA) it may become apparent that interactions between Mobile IP and this > mechanism may be necessary. >=20 > >> Open to discussion: what are the scenarios? >=20 > We are interested in describing the scenarios. There may exist several > possibilities. I think of the following lego-like approach: >=20 > - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. > - scenario MR-to-MR - conceive prefixes in Router Advertisements, > compare to other dynamic routing approaches. > - scenario MR-to-MR-to-Infrastructure - combine the above two. >=20 > Another direction is classify the kinds of vehicles. I think of > something like this: >=20 > - Internet Vehicle (has a plethora of interfaces, long- and short- > range). > - Range Extending Vehicle - extends the range of reachability. > - Leaf Vehicle - like and end-node. >=20 > Then there are other scenario statements that could open the path to the > following: > - addressability within vehicle, ULA, VIN. > - problem of bandwidth difference between inside and outside the > vehicle. >=20 > > What are the potential work items? What might be needed, > > if anything at all? > > > > I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS > > issues and in your questions directions. I will join the ITS-WG which > > I think can have relation to MANET [RFC2501]. >=20 > Well, hmm. I am happy to hear that but let us go easy about this. >=20 > "ITS" at IETF is currently just an informal effort. Its future may be > ambitious but right now it's not a WG. To do that, we'd need to make a > BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward= . >=20 > Secod, RFC2501 and ad-hoc routing are just one possibility to continue > working on this. Some people may express positive technical feedback > about MANET and others less so. >=20 > > IMO that vehicle routers communications depend on both their > > communication protocols and the used-network for such communication > > (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO > > there is no doubt that Mobile IP [RFC6275] is needed for the router's > > if the communication is through the Internet's domain(s), but if it > > is through Ad-hoc networks' domain(s) it MAY not be used. >=20 > I tend to agree that Mobile IP may not be needed between vehicles which > communicate directly without infrastructure. Then one wonders _what_ is > needed? >=20 > > The Internet is an infrastructure network and Ad-hoc networks are > > infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with > > the WG answers, and will read more into the WG inputs regarding these > > issues. >=20 > (see above note about this "WG" acronym which ITS is not currently) >=20 > > I will schedule to participate/prepare I-D in the future for ITS > > scenarios. I am preparing an I-D on DSRv2 routing which is a MANET > > routing protocol that fits the use-case of ITS and VANET as well. >=20 > I am interested to work on scenario/reqs drafts for ITS. >=20 > About "DSRv2" - is it still about Routing Headers? >=20 > I am interested to hear others' oppinions as well. >=20 > Yours, >=20 > Alex >=20 > > > > Regards > > > > Abdussalam Baryun University of Glamorgan, UK > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > From: Alexandru Petrescu To: its > > at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] > > Scenarios, potential topics... > > -----------------------------------------------------------------------= --------- > > > > > > > > > > > Welcome to the ITS list at IETF, an informal discussion. > > > > Earlier at IETF discussions related to vehicular communications > > happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a > > few), drafts were published [*]. At times people expressed interest > > to meet f2f. Now there is this email list. > > > > Participants are solicited to work on the topic of using IP in > > Intelligent Transportation Systems. The term ITS is a placeholder > > that, in my oppinion, is generic enough to cover many aspects of > > vehicular communications; vehicles may be wheeled, watered, flown. > > Ambulance, fire engine, coastal ship are particular examples. > > > > Scenario : A router deployed in a moving vehicle, uses its egress > > interface to connect to larger-area access network(s) or to other > > vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? > > > > Example potential work items: - Reqs for IPv6 in vehicular networks > > - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and > > IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p > > (IPv6-over-foo). - open. > > > > I am told about other vehicular drafts and discussions, that I have > > not cited, existed and still exist (about e.g. ecall). I am > > interested to learn about all the vehicular activities at IETF. > > > > Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. > > > > Open to discussion: what are the scenarios? What are the potential > > work items? What might be needed, if anything at all? > > > > Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 > > draft-jhlee-mext-mnpp-00.txt, October 2009. > > draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. > > draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. > > draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. > > draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. > > draft-petrescu-mip4-tuntype-change-00.txt, March 2011. > > draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. > > draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 > > draft-rosen-ecrit-ecall-04.txt, March 2010. > > draft-singh-simple-vehicle-info, July 2007. > > draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. > > draft-bauer-mext-aero-solspace, Sep. 2009. > > draft-bauer-mext-aero-topology, Sep. 2009. > > draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. > > draft-rosen-ecrit-ecall-05.txt, March 2012. > > > > >=20 >=20 >=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 sratliff@cisco.com Tue Jul 3 09:59: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 BF1AF21F85A7 for ; Tue, 3 Jul 2012 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 DNUGHkiV0OGs for ; Tue, 3 Jul 2012 09:59:36 -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 DB6C011E8098 for ; Tue, 3 Jul 2012 09:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7585; q=dns/txt; s=iport; t=1341334783; x=1342544383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=klF7r2hU9JmXbI3pvln8Ra4/LiM3oRfRo3AmOfCW2jY=; b=WJ6KuofSRMD+mscX2PA1m3RXOoCOjgQTXexrVYwyXDvonjbNUru1RVDM 7Ga3oFvjAQnpAO+OyIh/eTvIf0Fl7+wW/MCeVytpF7BI8gfStA5AqSjGW TGnsoTWHVsKBo5nQ0ojS4As7AtNYpETepNjTs7N6MLk0w/TVSf+MKzSaD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJAj80+tJV2a/2dsb2JhbABEtwaBB4IYAQEBAwEBAQEPAUISBwMIBQcEAgEIEQQBAQEnBycLFAkIAgQOBSKHZAULmgygR4s3FA6FGGADlTWOHYFmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="95435419" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jul 2012 16:59:42 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q63Gxg7V017328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 16:59:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.225]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 11:59:42 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAA== Date: Tue, 3 Jul 2012 16:59:42 +0000 Message-ID: <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003 x-tm-as-result: No--57.182100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:59:37 -0000 Chris,=20 OK, that's fair enough. As you mention, since DLEP isn't a routing protocol= , and can exist quite cleanly on its own port, that's the direction I'm lea= ning. I think there are also uses outside the MANET WG where use of 5444 wo= uld actually cause more code to be employed, and increase packet overhead (= think ROLL)=85=20 Regards, Stan On Jul 3, 2012, at 11:49 AM, Dearlove, Christopher (UK) wrote: > I think your option 2 is missing one point. The idea to use IPv6 addresse= s was when it appeared that there might be multiple address types that migh= t all be used as a key. But later discussion indicated that all entities sh= ould be keyed by their MAC address, with other addresses as additional info= rmation. In that case at the 5444 level, the address type would simply be l= ength =3D 16, and MAC addresses would be used as-is. IPv4 and IPv6 addresse= s would go in TLVs. It's fairly clean. (How clean it is depends on whether = a TLV that carries addresses allows for compression. For DLEP I think not.) >=20 > With regard to point 3, I think the last draft of DYMO was 5444 compliant= . It was Charlie taking back over from Ian who suggested it didn't need to = be 5444 compliant (and should be called AODVv2). That's a discussion the WG= hasn't had. LOADng hasn't of course been developed in MANET, though has n= ow been suggested to MANET, again I think with no conclusions. I thus would= n't characterise the WG mandate of required use of 5444 as capricious for r= outing protocols. Specifically I think 5444 must be used (both because 5498= says so and because otherwise things break) if using the allocated manet p= ort/protocol. DLEP on the other hand is not a routing protocol, doesn't nee= d to use the same port, and the argument is not as strong. >=20 > Subject to those caveats all three are theoretical possibilities. I'm str= ongly against number 3 because of its implications for NHDP, OLSRv2 and SMF= . (I also think it actually turns out not to help DLEP.) As I've said befor= e, I see good arguments relating to the other two (or three: 5444 as-DLEP-i= s, better fit to 5444, not 5444), and that always makes things harder. Note= that's a DLEP discussion, it's different for DYMO/AODVv2/LOADng (where I d= o have views, but I'm not going to muddy this discussion with them). >=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= Stan Ratliff (sratliff) > Sent: 03 July 2012 16:17 > To: Henning Rogge > Cc: Greg Harrison (greharri); manet@ietf.org; Shawn Jury; Bo Berry (bober= ry) > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=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 > Henning,=20 >=20 >=20 > (Based on earlier discussions, *all* of this is from the perspective of a= Working Group Participant, and a Draft co-author/editor)... >=20 > Yes, the authors are still in discussions with regard to DLEP 5444 "compa= tibility". There are still roughly 3 options I see for moving forward.=20 >=20 > 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issu= e of multiple address types vis-a-vis address blocks. Also, since the react= ive protocol drafts being considered by the WG don't necessarily require RF= C 5444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packet= s, the WG mandate that everything use 5444 seems capricious at best.=20 >=20 > 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leav= ing the addressing internal to DLEP. This avoids the issue of carrying mult= iple address families in 5444 address blocks. I've seen several recommendat= ions on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, s= o as to carry everything in address blocks of a single length. However, I s= ee that as a hack, plain and simple. I'm adamant that this won't fly - not = at IESG review, at least. I'll lodge the complaint against the draft myself= if I have to on that one. In order to do that, we'd need to.. >=20 > 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple = address families with a single transmission.=20 >=20 > Now, if the WG chooses option 2 or 3, I *still* see an issue with respect= to the mandate of "we must use 5444 for all drafts". especially since our = reactive drafts seem to be excluded from that mandate. Long story short? I= 'm leaning towards option 1. >=20 > Regards, > Stan >=20 >=20 >=20 >=20 > On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: >=20 >> Hello, >>=20 >> I think it is time to talk about the status of the DLEP draft. We stoppe= d the discussion to give the authors time to talk about the ideas of the WG= about how to change and improve the draft. >>=20 >> That was two months ago. >>=20 >> I would like to hear an update how we should go forward with DLEP in the= Manet WG, the concept is too important to just let it stay quiet for month= s. >>=20 >> Has there been a decision what Cisco thinks about all the discussions we= had in March/April? Do you work on a -03 draft updated to RFC5444 compatib= ility? >>=20 >> I think that many members of the Manet WG are very interested to push DL= EP forward. >>=20 >> Regards >> 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 >>=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 > ******************************************************************** > 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 sratliff@cisco.com Tue Jul 3 10:10: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 AA60911E818C; Tue, 3 Jul 2012 10:10:56 -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 sT-xVa1nLsoL; Tue, 3 Jul 2012 10:10: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 83F4411E8175; Tue, 3 Jul 2012 10:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=12135; q=dns/txt; s=iport; t=1341335463; x=1342545063; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=srh5T3V8HtOVJ/mEapOnZoqAVpZuvuJyaSps1NJBV4Q=; b=SzZir+RkfiuBRAc+85KueHK+FgT2BkpXkgGZZ3wAia5Brqmby8Ga0xaM 9g42745V/NLFSUWFqHmZF/KGIW2kAhRgtHYt1+UHLxQQlbu0iWW+Xk6ji ZsCx8t8FzsL/dgyrs0jkijfaT6GgZTuTYLQJHIHEySnNYR8oPWEJXtLoi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFom80+tJXG+/2dsb2JhbABEtweBB4IYAQEBAwEBAQEPAUIZAwEHBQcEAgEIEQMBAQEBJwcnCxQJCAIEDgUih1sDBgULmg2Waw2JTos3FAQKhRhgA5U1gRKNC4Fmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98461343" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2012 17:11:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q63HB20X013309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:11:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.225]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 12:11:01 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNWPHLDBFsD3ureUy3hfl1S3YfnJcYFyaAgAAEzICAAAOeAA== Date: Tue, 3 Jul 2012 17:11:01 +0000 Message-ID: <756496F2-7B99-4434-AF52-4123CD281912@cisco.com> References: <4FF2A65E.2080000@gmail.com> <1341333653.6804.875.camel@localhost.localdomain> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003 x-tm-as-result: No--55.879000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <1DB4758DDDDA3A4B8F98928C0AEDBD33@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:10:57 -0000 Yes, I agree - 1 route is better than 0. But at least for me, the point is = that >1 route is always better than 1=85. hence, "interfaces" instead of "i= nterface"=85 ;-) And which link is better, etc, etc=85=20 Regards, Stan On Jul 3, 2012, at 12:58 PM, Dearlove, Christopher (UK) wrote: > There are emergency service requirements where even 1 route would be an i= mprovement on the otherwise available 0 routes. Communications down to the = platform on underground railway lines would have been one on 7/7 in London. >=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= Rex Buddenberg > Sent: 03 July 2012 17:41 > To: Alexandru Petrescu > Cc: manet; its@ietf.org; Abdussalam Baryun > Subject: Re: [manet] [its] Scenarios, potential topics... >=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 > Alex, >=20 > You just HAD to go and ask: >=20 >> I am interested to hear others' oppinions as well. >>=20 >=20 > One of the handful of requirements differences between emergency > services and the rest of us is higher availability and survivability > needs. Skipping some analysis steps, this always boils down to >1 > route. =20 >=20 >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. >=20 > So the English in the above statement is not quite right: 'interface' > MUST be plural in any practical situation: interfaces. =20 >=20 >=20 > LTE is likely to be the big player for the radio-WAN, but there won't be > just one instantiation. A quick scenario: an instrumented ambulance may > have one or more LANs within the vehicle to which several end systems > are attached -- vital signs sensors, VOIP handset for the EMT, etc. > quite possibly a WiFi hotspot ... All attached to a vehicle-mounted > router. The router has interfaces to 1) wired ethernet (for use while > in the garage), 2) commercial LTE (where coverage exists), 3) emergency > services LTE (in US, this is earmarked for 700MHz band and does not yet > in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite > or other radio-WAN network for rural areas not reachable by other means. > Any sane high Ao engineering will be picking at least two of the > above. =20 >=20 >=20 > Any help? >=20 >=20 >=20 > On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: >> Hi Abdussalam and thanks for the reply. >>=20 >> Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >>> Hi Alex and All, >>>=20 >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. >>>=20 >>> Should it use IPv6-over-LTE? >>=20 >> In our context we consider indeed IPv6 over LTE, for several reasons. >> The 3GPP specs about LTE seem to be very specific and detailed about the >> use of IPv6. (In the past, before LTE, the earlier 3GPP specs were >> mentioning IPv6 but more like an option feature.) >>=20 >> However, the 3GPP specs about the use of IPv6 have some lack of >> specification in the case that the UE (User Terminal) is actually a >> Mobile Router. The Prefix Delegation part may be underspecified. >>=20 >>> Should it use Mobile IP? >>=20 >> Hmm... that is a good question and much can be said about it. I am >> interested to liste others' oppinions as well. >>=20 >> I think Mobile IP may be necessary but not sufficient. In the case of >> direct vehicle-to-vehicle IP communications (non covered areas) Mobile >> IP may not be necessary. It may be that extensions to Neighbor >> Discovery and DHCP could help establish paths within local topologies. >>=20 >> And, when that is done (e.g. exchange routes between two vehicles using >> RA) it may become apparent that interactions between Mobile IP and this >> mechanism may be necessary. >>=20 >>>> Open to discussion: what are the scenarios? >>=20 >> We are interested in describing the scenarios. There may exist several >> possibilities. I think of the following lego-like approach: >>=20 >> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. >> - scenario MR-to-MR - conceive prefixes in Router Advertisements, >> compare to other dynamic routing approaches. >> - scenario MR-to-MR-to-Infrastructure - combine the above two. >>=20 >> Another direction is classify the kinds of vehicles. I think of >> something like this: >>=20 >> - Internet Vehicle (has a plethora of interfaces, long- and short- >> range). >> - Range Extending Vehicle - extends the range of reachability. >> - Leaf Vehicle - like and end-node. >>=20 >> Then there are other scenario statements that could open the path to the >> following: >> - addressability within vehicle, ULA, VIN. >> - problem of bandwidth difference between inside and outside the >> vehicle. >>=20 >>> What are the potential work items? What might be needed, >>> if anything at all? >>>=20 >>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS >>> issues and in your questions directions. I will join the ITS-WG which >>> I think can have relation to MANET [RFC2501]. >>=20 >> Well, hmm. I am happy to hear that but let us go easy about this. >>=20 >> "ITS" at IETF is currently just an informal effort. Its future may be >> ambitious but right now it's not a WG. To do that, we'd need to make a >> BoF first (Birds-of-a-Feather) and ask others' oppinion about way forwar= d. >>=20 >> Secod, RFC2501 and ad-hoc routing are just one possibility to continue >> working on this. Some people may express positive technical feedback >> about MANET and others less so. >>=20 >>> IMO that vehicle routers communications depend on both their >>> communication protocols and the used-network for such communication >>> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO >>> there is no doubt that Mobile IP [RFC6275] is needed for the router's >>> if the communication is through the Internet's domain(s), but if it >>> is through Ad-hoc networks' domain(s) it MAY not be used. >>=20 >> I tend to agree that Mobile IP may not be needed between vehicles which >> communicate directly without infrastructure. Then one wonders _what_ is >> needed? >>=20 >>> The Internet is an infrastructure network and Ad-hoc networks are >>> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with >>> the WG answers, and will read more into the WG inputs regarding these >>> issues. >>=20 >> (see above note about this "WG" acronym which ITS is not currently) >>=20 >>> I will schedule to participate/prepare I-D in the future for ITS >>> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET >>> routing protocol that fits the use-case of ITS and VANET as well. >>=20 >> I am interested to work on scenario/reqs drafts for ITS. >>=20 >> About "DSRv2" - is it still about Routing Headers? >>=20 >> I am interested to hear others' oppinions as well. >>=20 >> Yours, >>=20 >> Alex >>=20 >>>=20 >>> Regards >>>=20 >>> Abdussalam Baryun University of Glamorgan, UK >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> From: Alexandru Petrescu To: its >>> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>> Scenarios, potential topics... >>> -----------------------------------------------------------------------= --------- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >> Welcome to the ITS list at IETF, an informal discussion. >>>=20 >>> Earlier at IETF discussions related to vehicular communications >>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>> few), drafts were published [*]. At times people expressed interest >>> to meet f2f. Now there is this email list. >>>=20 >>> Participants are solicited to work on the topic of using IP in >>> Intelligent Transportation Systems. The term ITS is a placeholder >>> that, in my oppinion, is generic enough to cover many aspects of >>> vehicular communications; vehicles may be wheeled, watered, flown. >>> Ambulance, fire engine, coastal ship are particular examples. >>>=20 >>> Scenario : A router deployed in a moving vehicle, uses its egress >>> interface to connect to larger-area access network(s) or to other >>> vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >>>=20 >>> Example potential work items: - Reqs for IPv6 in vehicular networks >>> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and >>> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p >>> (IPv6-over-foo). - open. >>>=20 >>> I am told about other vehicular drafts and discussions, that I have >>> not cited, existed and still exist (about e.g. ecall). I am >>> interested to learn about all the vehicular activities at IETF. >>>=20 >>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>=20 >>> Open to discussion: what are the scenarios? What are the potential >>> work items? What might be needed, if anything at all? >>>=20 >>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. >>> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 >>> draft-rosen-ecrit-ecall-04.txt, March 2010. >>> draft-singh-simple-vehicle-info, July 2007. >>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>> draft-bauer-mext-aero-solspace, Sep. 2009. >>> draft-bauer-mext-aero-topology, Sep. 2009. >>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>=20 >>>=20 >>=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 > ******************************************************************** > 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 Ronald.intVelt@tno.nl Tue Jul 3 10:23: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 36C7021F869E for ; Tue, 3 Jul 2012 10:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcurWIXK2LZf for ; Tue, 3 Jul 2012 10:23:51 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id EAC8C21F869D for ; Tue, 3 Jul 2012 10:23:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,516,1336341600"; d="scan'208";a="71686861" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 03 Jul 2012 19:23:57 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.152]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 19:23:57 +0200 From: "Velt, R. (Ronald) in 't" To: "Dearlove, Christopher (UK)" , "manet@ietf.org" Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSipEHzKq60guk2ZGZSUxfX8BZcXieQAgAAJFQCAADswYA== Date: Tue, 3 Jul 2012 17:23:56 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A2DE904@EXC-MBX03.tsn.tno.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:23:52 -0000 Christopher, >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >Of Dearlove, Christopher (UK) >Sent: dinsdag 3 juli 2012 17:49 >To: Stan Ratliff (sratliff); Henning Rogge >Cc: Greg Harrison (greharri); manet@ietf.org; Shawn Jury; Bo Berry (boberr= y) >Subject: Re: [manet] Status of DLEP-draft at Cisco? > >I think your option 2 is missing one point. The idea to use IPv6 addresses= was >when it appeared that there might be multiple address types that might all= be >used as a key. But later discussion indicated that all entities should be = keyed >by their MAC address, with other addresses as additional information. In t= hat >case at the 5444 level, the address type would simply be length =3D 16, an= d MAC Did you mean: length =3D 6 ? :-) >addresses would be used as-is. IPv4 and IPv6 addresses would go in TLVs. I= t's >fairly clean. (How clean it is depends on whether a TLV that carries addre= sses >allows for compression. For DLEP I think not.) Regards, Ronald in 't Velt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From Chris.Dearlove@baesystems.com Tue Jul 3 10:27: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 5D3AF11E8175; Tue, 3 Jul 2012 10:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=1.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 jgjQfjdpCALH; Tue, 3 Jul 2012 10:27:10 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 54D2D11E80A4; Tue, 3 Jul 2012 10:27:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,516,1336345200"; d="scan'208";a="251933418" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Jul 2012 18:27:17 +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 q63HRGco013899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 18:27:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Tue, 3 Jul 2012 18:27:15 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNV69n/KKbaGBgZUG5Yv9F4+0TIpcXI2UAgACRsYCAABR1kP//8/aAgAAVCpA= Date: Tue, 3 Jul 2012 17:27:15 +0000 Message-ID: References: <4FF2A65E.2080000@gmail.com> <1341333653.6804.875.camel@localhost.localdomain> <756496F2-7B99-4434-AF52-4123CD281912@cisco.com> In-Reply-To: <756496F2-7B99-4434-AF52-4123CD281912@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: Rex Buddenberg , Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:27:12 -0000 The point about the 1 route (rather than 0 routes) case was just to note th= at the suggestion that the requirement for "always" >1 routes is too strong= , not to suggest it was undesirable. (Incidentally if you need redundancy, and are prepared to accept the additi= onal overheads, then >1 routes isn't sufficient, you also need to consider = whether they are disjoint or not.) --=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 (sratliff) [mailto:sratliff@cisco.com]=20 Sent: 03 July 2012 18:11 To: Dearlove, Christopher (UK) Cc: Rex Buddenberg; Alexandru Petrescu; manet; its@ietf.org; Abdussalam Bar= yun Subject: Re: [manet] [its] Scenarios, potential topics... ----------------------! 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. -------------------------------------------------------- Yes, I agree - 1 route is better than 0. But at least for me, the point is = that >1 route is always better than 1.. hence, "interfaces" instead of "int= erface". ;-) And which link is better, etc, etc.=20 Regards, Stan On Jul 3, 2012, at 12:58 PM, Dearlove, Christopher (UK) wrote: > There are emergency service requirements where even 1 route would be an i= mprovement on the otherwise available 0 routes. Communications down to the = platform on underground railway lines would have been one on 7/7 in London. >=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= Rex Buddenberg > Sent: 03 July 2012 17:41 > To: Alexandru Petrescu > Cc: manet; its@ietf.org; Abdussalam Baryun > Subject: Re: [manet] [its] Scenarios, potential topics... >=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 > Alex, >=20 > You just HAD to go and ask: >=20 >> I am interested to hear others' oppinions as well. >>=20 >=20 > One of the handful of requirements differences between emergency > services and the rest of us is higher availability and survivability > needs. Skipping some analysis steps, this always boils down to >1 > route. =20 >=20 >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. >=20 > So the English in the above statement is not quite right: 'interface' > MUST be plural in any practical situation: interfaces. =20 >=20 >=20 > LTE is likely to be the big player for the radio-WAN, but there won't be > just one instantiation. A quick scenario: an instrumented ambulance may > have one or more LANs within the vehicle to which several end systems > are attached -- vital signs sensors, VOIP handset for the EMT, etc. > quite possibly a WiFi hotspot ... All attached to a vehicle-mounted > router. The router has interfaces to 1) wired ethernet (for use while > in the garage), 2) commercial LTE (where coverage exists), 3) emergency > services LTE (in US, this is earmarked for 700MHz band and does not yet > in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite > or other radio-WAN network for rural areas not reachable by other means. > Any sane high Ao engineering will be picking at least two of the > above. =20 >=20 >=20 > Any help? >=20 >=20 >=20 > On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: >> Hi Abdussalam and thanks for the reply. >>=20 >> Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >>> Hi Alex and All, >>>=20 >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. >>>=20 >>> Should it use IPv6-over-LTE? >>=20 >> In our context we consider indeed IPv6 over LTE, for several reasons. >> The 3GPP specs about LTE seem to be very specific and detailed about the >> use of IPv6. (In the past, before LTE, the earlier 3GPP specs were >> mentioning IPv6 but more like an option feature.) >>=20 >> However, the 3GPP specs about the use of IPv6 have some lack of >> specification in the case that the UE (User Terminal) is actually a >> Mobile Router. The Prefix Delegation part may be underspecified. >>=20 >>> Should it use Mobile IP? >>=20 >> Hmm... that is a good question and much can be said about it. I am >> interested to liste others' oppinions as well. >>=20 >> I think Mobile IP may be necessary but not sufficient. In the case of >> direct vehicle-to-vehicle IP communications (non covered areas) Mobile >> IP may not be necessary. It may be that extensions to Neighbor >> Discovery and DHCP could help establish paths within local topologies. >>=20 >> And, when that is done (e.g. exchange routes between two vehicles using >> RA) it may become apparent that interactions between Mobile IP and this >> mechanism may be necessary. >>=20 >>>> Open to discussion: what are the scenarios? >>=20 >> We are interested in describing the scenarios. There may exist several >> possibilities. I think of the following lego-like approach: >>=20 >> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. >> - scenario MR-to-MR - conceive prefixes in Router Advertisements, >> compare to other dynamic routing approaches. >> - scenario MR-to-MR-to-Infrastructure - combine the above two. >>=20 >> Another direction is classify the kinds of vehicles. I think of >> something like this: >>=20 >> - Internet Vehicle (has a plethora of interfaces, long- and short- >> range). >> - Range Extending Vehicle - extends the range of reachability. >> - Leaf Vehicle - like and end-node. >>=20 >> Then there are other scenario statements that could open the path to the >> following: >> - addressability within vehicle, ULA, VIN. >> - problem of bandwidth difference between inside and outside the >> vehicle. >>=20 >>> What are the potential work items? What might be needed, >>> if anything at all? >>>=20 >>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS >>> issues and in your questions directions. I will join the ITS-WG which >>> I think can have relation to MANET [RFC2501]. >>=20 >> Well, hmm. I am happy to hear that but let us go easy about this. >>=20 >> "ITS" at IETF is currently just an informal effort. Its future may be >> ambitious but right now it's not a WG. To do that, we'd need to make a >> BoF first (Birds-of-a-Feather) and ask others' oppinion about way forwar= d. >>=20 >> Secod, RFC2501 and ad-hoc routing are just one possibility to continue >> working on this. Some people may express positive technical feedback >> about MANET and others less so. >>=20 >>> IMO that vehicle routers communications depend on both their >>> communication protocols and the used-network for such communication >>> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO >>> there is no doubt that Mobile IP [RFC6275] is needed for the router's >>> if the communication is through the Internet's domain(s), but if it >>> is through Ad-hoc networks' domain(s) it MAY not be used. >>=20 >> I tend to agree that Mobile IP may not be needed between vehicles which >> communicate directly without infrastructure. Then one wonders _what_ is >> needed? >>=20 >>> The Internet is an infrastructure network and Ad-hoc networks are >>> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with >>> the WG answers, and will read more into the WG inputs regarding these >>> issues. >>=20 >> (see above note about this "WG" acronym which ITS is not currently) >>=20 >>> I will schedule to participate/prepare I-D in the future for ITS >>> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET >>> routing protocol that fits the use-case of ITS and VANET as well. >>=20 >> I am interested to work on scenario/reqs drafts for ITS. >>=20 >> About "DSRv2" - is it still about Routing Headers? >>=20 >> I am interested to hear others' oppinions as well. >>=20 >> Yours, >>=20 >> Alex >>=20 >>>=20 >>> Regards >>>=20 >>> Abdussalam Baryun University of Glamorgan, UK >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> From: Alexandru Petrescu To: its >>> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>> Scenarios, potential topics... >>> -----------------------------------------------------------------------= --------- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >> Welcome to the ITS list at IETF, an informal discussion. >>>=20 >>> Earlier at IETF discussions related to vehicular communications >>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>> few), drafts were published [*]. At times people expressed interest >>> to meet f2f. Now there is this email list. >>>=20 >>> Participants are solicited to work on the topic of using IP in >>> Intelligent Transportation Systems. The term ITS is a placeholder >>> that, in my oppinion, is generic enough to cover many aspects of >>> vehicular communications; vehicles may be wheeled, watered, flown. >>> Ambulance, fire engine, coastal ship are particular examples. >>>=20 >>> Scenario : A router deployed in a moving vehicle, uses its egress >>> interface to connect to larger-area access network(s) or to other >>> vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >>>=20 >>> Example potential work items: - Reqs for IPv6 in vehicular networks >>> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and >>> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p >>> (IPv6-over-foo). - open. >>>=20 >>> I am told about other vehicular drafts and discussions, that I have >>> not cited, existed and still exist (about e.g. ecall). I am >>> interested to learn about all the vehicular activities at IETF. >>>=20 >>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>=20 >>> Open to discussion: what are the scenarios? What are the potential >>> work items? What might be needed, if anything at all? >>>=20 >>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. >>> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 >>> draft-rosen-ecrit-ecall-04.txt, March 2010. >>> draft-singh-simple-vehicle-info, July 2007. >>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>> draft-bauer-mext-aero-solspace, Sep. 2009. >>> draft-bauer-mext-aero-topology, Sep. 2009. >>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>=20 >>>=20 >>=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 > ******************************************************************** > 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 Tue Jul 3 10:29: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 DF24721F85A5 for ; Tue, 3 Jul 2012 10:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 BRy6fdNeDOka for ; Tue, 3 Jul 2012 10:29:18 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2011E81AC for ; Tue, 3 Jul 2012 10:29:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,516,1336345200"; d="scan'208";a="251933708" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 Jul 2012 18:29:25 +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 q63HTPaK014956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 18:29:25 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Tue, 3 Jul 2012 18:29:24 +0100 From: "Dearlove, Christopher (UK)" To: "Velt, R. (Ronald) in 't" , "manet@ietf.org" Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSipkJPtrdHUq0SlS58HjbKfcpcXmqgAgAAR+ZCAABGKAIAAEcRg Date: Tue, 3 Jul 2012 17:29:24 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <72FB622921C13746AD6349E70A8D9F307A2DE904@EXC-MBX03.tsn.tno.nl> In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A2DE904@EXC-MBX03.tsn.tno.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 Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:29:19 -0000 Yes, 6. Finger and/or brain error. Thanks for the catch. --=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: Velt, R. (Ronald) in 't [mailto:Ronald.intVelt@tno.nl]=20 Sent: 03 July 2012 18:24 To: Dearlove, Christopher (UK); manet@ietf.org Subject: RE: [manet] Status of DLEP-draft at Cisco? ----------------------! 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. -------------------------------------------------------- Christopher, >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >Of Dearlove, Christopher (UK) >Sent: dinsdag 3 juli 2012 17:49 >To: Stan Ratliff (sratliff); Henning Rogge >Cc: Greg Harrison (greharri); manet@ietf.org; Shawn Jury; Bo Berry (boberr= y) >Subject: Re: [manet] Status of DLEP-draft at Cisco? > >I think your option 2 is missing one point. The idea to use IPv6 addresses= was >when it appeared that there might be multiple address types that might all= be >used as a key. But later discussion indicated that all entities should be = keyed >by their MAC address, with other addresses as additional information. In t= hat >case at the 5444 level, the address type would simply be length =3D 16, an= d MAC Did you mean: length =3D 6 ? :-) >addresses would be used as-is. IPv4 and IPv6 addresses would go in TLVs. I= t's >fairly clean. (How clean it is depends on whether a TLV that carries addre= sses >allows for compression. For DLEP I think not.) Regards, Ronald in 't Velt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ******************************************************************** 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 Jul 3 10:34: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 5F22911E808F for ; Tue, 3 Jul 2012 10:34:20 -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 s-kD7CB-a-3A for ; Tue, 3 Jul 2012 10:34:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60C3A11E8073 for ; Tue, 3 Jul 2012 10:34:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6154604ghb.31 for ; Tue, 03 Jul 2012 10:34: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:content-transfer-encoding; bh=sVJyqSAzR0y0S9Xc7sI8wBZBE4U8aDyhs6KnIlF1en0=; b=OKROzswJJ2/aIuF44IeNhv7AYHgXNqKkuGz3dURC8g1fALsjbyWaJ6VYo3pee2FnQu 32+Y42rVrmSZ1qky5gvDWwMlPJA2yqG0W0+GbAILINDRqQwOvxo35S8qVqEo1w6cMWBO ZPWAb1ITrC4qTFjfbbOKLp1TQeTC/TXBHoLDGCh+bBeLLHwOGIUJVJJ4SZIzS+rSVvxh 2FH/FvbGSuZSmTyUYfVpVSSx9gVc7tLqBkT3vr7UogG+fuvta+uxkYxSbe3LhByt4xCu CK3agZ4cv3aOYTjP5m/K6lhKvp/mQppeam9IuGgkmNc+cytJJFuRt+xpLsLUzuacVNFM bsDQ== Received: by 10.68.232.232 with SMTP id tr8mr8937186pbc.73.1341336866953; Tue, 03 Jul 2012 10:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Tue, 3 Jul 2012 10:34:06 -0700 (PDT) In-Reply-To: <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> From: Henning Rogge Date: Tue, 3 Jul 2012 19:34:06 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:34:20 -0000 On Tue, Jul 3, 2012 at 6:59 PM, Stan Ratliff (sratliff) wrote: > Chris, > > OK, that's fair enough. As you mention, since DLEP isn't a routing protoc= ol, and can exist quite cleanly on its own port, that's the direction I'm l= eaning. I think there are also uses outside the MANET WG where use of 5444 = would actually cause more code to be employed, and increase packet overhead= (think ROLL)=85 I think the small overhead is pretty meaningless because DLEP is not sent over the mesh links, just between radio and router. Also the "use 6 byte addresses for MACs, use TLVs for IPv4/6" will work quite well for DLEP, because many radios will not even need the IPv4/6 part at all, especially with the bridged data-path DLEP describes. There should be the options to transmit IPv4/6 addresses over DLEP if they are available, but I wonder if this would be a common usecase. Most of the workinggroup seems to have the opinion that DLEP should move to full RFC5444 compliance, because it will fit the purpose of DLEP fine and spare the IETF "just another proprietary data format". With RFC5444 we can easily get to a point where we get a protocol that can be extended for more metrics without the need of a version field, which will simplify future DLEP revisions. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Tue Jul 3 10:48: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 9DE8411E80A0 for ; Tue, 3 Jul 2012 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 w87czmytKRsY for ; Tue, 3 Jul 2012 10:48:56 -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 B6C3D11E808F for ; Tue, 3 Jul 2012 10:48:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4845289vbb.31 for ; Tue, 03 Jul 2012 10:49:04 -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=zTbcWZdF9RIriOnyDqasG95LQjFuXCkq4mO6289XWvU=; b=hXvscO5elMuobT6ovpVRbrf/lis2acMLto9BjsjyJf+0JidgJcWFqLeYbqYbrtJ4Dc tCf8tLHfN2Z/gD0Vu6gs2Gsts2YP9hTPjy+hpvUS187cZfIaEu/zx9NjseJyf8Qd+RHr wjGAJWuF18OZt0OXqyPx9nqKpI7GYqrR5HVCdrdYuVMF93at+BGklvVtIGzohE9/Nwyc hUyGwK3UB9rcWzovt66aPUDjOAoA8WPj0jt/HYG69KvBt7+oANACsYK7bVBDZgi22OTB s6jC6baTo6k5NPuVxqSDOJfkVNN4NUp5HYhMnKQYOGpFCIGZW0N0N3RiKKSSqVfSKrWR dDUw== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr7296129vdf.127.1341337744807; Tue, 03 Jul 2012 10:49:04 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Tue, 3 Jul 2012 10:49:04 -0700 (PDT) Date: Tue, 3 Jul 2012 19:49:04 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: shawn.jury@netapp.com, boberry@cisco.com, sratliff@cisco.com Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:48:57 -0000 Hi It was mentioned in meeting 83 the interest of use RFC5444 and should not be mandatory, however, it is important that we notice the reasons why AODVv2 and DLEP may not use the RFC5444. It is understood so far that AODVv2 and DLEP workers are still investigating the use performance. On the other hand if more than one MANET routing draft (excluding DLEP) don't use RFC5444 then I will try to investigate how can we update RFC5444 so it can be more compatible to others without affecting OLSRv2 and RFC6130. Regarding my work for DSRv2, I am interested also like Henning to using DLEP. I am also considering the use of RFC5444 (even though I notice AODVv2 may not use it with reasons) until I get a good reason/result to not use it. However, IMO it is always a credit for the protocol that it has the both possibility to use and not use RFC5444 and let the industry/scenario decide. Overall using RFC5444 or a future updated one by all MANET routing is a big advantage for MANET. Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: Henning Rogge Subject: Re: [manet] Status of DLEP-draft at Cisco? From: "Stan Ratliff (sratliff)" Henning, (Based on earlier discussions, *all* of this is from the perspective of a Working Group Participant, and a Draft co-author/editor)... Yes, the authors are still in discussions with regard to DLEP 5444 "compatibility". There are still roughly 3 options I see for moving forward. 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue of multiple address types vis-a-vis address blocks. Also, since the reactive protocol drafts being considered by the WG don't necessarily require RFC 5444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packets, the WG mandate that everything use 5444 seems capricious at best. 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leaving the addressing internal to DLEP. This avoids the issue of carrying multiple address families in 5444 address blocks. I've seen several recommendations on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so as to carry everything in address blocks of a single length. However, I see that as a hack, plain and simple. I'm adamant that this won't fly - not at IESG review, at least. I'll lodge the complaint against the draft myself if I have to on that one. In order to do that, we'd need to=85. 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple address families with a single transmission. Now, if the WG chooses option 2 or 3, I *still* see an issue with respect to the mandate of "we must use 5444 for all drafts"=85 especially since our reactive drafts seem to be excluded from that mandate. Long story short? I'm leaning towards option 1. Regards, Stan On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote: > Hello, > > I think it is time to talk about the status of the DLEP draft. We stopped= the discussion to give the authors time to talk about the ideas of the WG = about how to change and improve the draft. > > That was two months ago. > > I would like to hear an update how we should go forward with DLEP in the = Manet WG, the concept is too important to just let it stay quiet for months= . > > Has there been a decision what Cisco thinks about all the discussions we = had in March/April? Do you work on a -03 draft updated to RFC5444 compatibi= lity? > > I think that many members of the Manet WG are very interested to push DLE= P forward. > > Regards > Henning Rogge From sratliff@cisco.com Tue Jul 3 10:55: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 6DF4711E808E for ; Tue, 3 Jul 2012 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 NDNo407S3SCA for ; Tue, 3 Jul 2012 10:55:40 -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 A0B7211E8096 for ; Tue, 3 Jul 2012 10:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2372; q=dns/txt; s=iport; t=1341338148; x=1342547748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LBjhHUFjhwW2L1IfYNfTkJqZF9+s4jgLYIGaQ4y/xCw=; b=UnVham9NrOnCbrVDz3r5Ra4BwDg86LDNCVdP06iF9tLtxFsgkNVUnVJ3 lf9BR8146MiMUVUbBBdd1dluzNVdhXQcmGjXZfGanaXgYTkMv9eEDdn99 Ezp2Onkb7X4ut+IOh0JuUsR3YPf9uvDa55U+LwbHW2vR2vLyq4Xw7h1ng M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANsx80+tJV2c/2dsb2JhbABEtwyBB4IYAQEBAwEBAQEPAVsLBQsCAQgOCi4nCyUCBA4FIodkBQuaCKBIBIs3hTpgA5U1jh2BZoJf X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98438718" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jul 2012 17:55:48 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q63Htlvf006059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:55:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.225]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 12:55:46 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAIAACZ8AgAAGDgA= Date: Tue, 3 Jul 2012 17:55:46 +0000 Message-ID: <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.005 x-tm-as-result: No--48.071900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <225BF47E0C8A35428361A16BA5D78A7E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:55:41 -0000 On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: > On Tue, Jul 3, 2012 at 6:59 PM, Stan Ratliff (sratliff) > wrote: >> Chris, >>=20 >> OK, that's fair enough. As you mention, since DLEP isn't a routing proto= col, and can exist quite cleanly on its own port, that's the direction I'm = leaning. I think there are also uses outside the MANET WG where use of 5444= would actually cause more code to be employed, and increase packet overhea= d (think ROLL)=85 >=20 > I think the small overhead is pretty meaningless because DLEP is not > sent over the mesh links, just between radio and router. I guess the amount of overhead (and introduction of 5444 parsers in environ= ments where they currently don't exist) is in the eye of the beholder=85=20 >=20 > Also the "use 6 byte addresses for MACs, use TLVs for IPv4/6" will > work quite well for DLEP, because many radios will not even need the > IPv4/6 part at all, especially with the bridged data-path DLEP > describes. Again the "work quite well" is subjective. Yes, we can make it work. >=20 > There should be the options to transmit IPv4/6 addresses over DLEP if > they are available, but I wonder if this would be a common use case. I most definitely hope it will become a common use case. As we've talked ab= out before, this addition helps to overcome issues like population of IPv4 = ARP caches=85. something that either needs a-priori knowledge, which is not= likely in my deployments, or some mechanism such as this.=20 >=20 > Most of the workinggroup seems to have the opinion that DLEP should > move to full RFC5444 compliance, because it will fit the purpose of > DLEP fine and spare the IETF "just another proprietary data format". > With RFC5444 we can easily get to a point where we get a protocol that > can be extended for more metrics without the need of a version field, > which will simplify future DLEP revisions. And again, we disagree on that point.=20 Regards, Stan >=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 Tue Jul 3 11:14: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 D5C4F11E80F2 for ; Tue, 3 Jul 2012 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 TSnYz5eEt6yO for ; Tue, 3 Jul 2012 11:14:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0C11E80FD for ; Tue, 3 Jul 2012 11:14:45 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4857389vcq.31 for ; Tue, 03 Jul 2012 11:14: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:content-transfer-encoding; bh=exZsZyEv4GfpSpDGiKJnw8TRsshIfWp8C73FF4v3RPg=; b=X3SZarT9GIANLN38i2WOf2o5/jjs3WcVoO3LjI28kJcgkgG4V3RuFAAfw7Z7BUnQa2 aaGCNxsU+VdbVG+Q6CcLSB1+/Qp3bG6U135NwLkaTjIQ4jinWjapkM5NNETPnwzeGEUk KQVq8dbltJWEpHLMKboZFJ7wbF+y/F4X37NIyf+OmeXu2VWWq8pNvt1lLh+VW3OHuwx4 0oJEYBitGS+6IL3hdWL4n3IIEINoCzDnkY4IWJ+mORdOfyRv0EY4mpWKHZFSVa/qKpMm 6ZXoPHJj4pjy4HufaSxxEQpweKHCISq8JwjxjNOZKsjyk0aGlEuLMMmZv+oPv2MAIKKk kZvw== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr7172013vdb.103.1341339293588; Tue, 03 Jul 2012 11:14:53 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Tue, 3 Jul 2012 11:14:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jul 2012 20:14:53 +0200 Message-ID: From: Abdussalam Baryun To: Jiazi YI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 18:14:49 -0000 Hi Jiazi, On 7/3/12, Jiazi YI wrote: > 1. I didn't get the scope of this document. The definitions are from > "Communication Medium" to protocol-specific term like "Route Reply Messag= e > (RREP)", and even security. I don't think it's necessary to go from the > general terms of telecommunication to some specified protocols -- if you > define RREP, why not HELLO, TC, and all other message types in the other > protocols? I will add TC and HELLO, and others if they are a general concept to be used by MANET. Usually the draft is the start, there will be more work to be added, > > 2. A lot of definitions are quite vague and do not make much sense, for > example: > >> "Upper layer" > this can be only used in certain context, but not a an depenent term. ok we may remove it, > >>Reactive Routing: >>An on-demand based routing protocol that operates route discover and >>maintainance the route(s), to reach the demanded destination(s). > > what's an on-demand based routing procotol then? A reactive routing? > ok will add this term as well > >>Message: >>A MANET data message or routing control message. > > You are trying to define "message" using "message"? And I will amend this > >>Routing control messages are either MANET routing protocol messages or/an= d >> RFC5444 >>messages. > > I'm confused with the relation between routing protocol message and RFC 5= 444 > messages when saying this... > Are you tying to say: a chicken can be either a white chicken or/and a > cock? > plus, RFC 5444 defines both packet and message... > Just trying to say the term "MANET message" doesn't always mean RFC5444 message. If you read RFC5444 (general MANET format) you will understand that all MANET messages are RFC5444. we still have active MANET RFCs that don't use RFC5444 (its a standard document). > > 3. There are a lot controversial terms (phy link, logic link, subnet > prefix...) and terms that rarely used in the protocols ( Protocol Sequenc= e > Number/Router Sequence Number, Distance Vector Metric/Link Stat Metric, o= r I > don't really know what they really are). > > Personally, I'm against to have this kind of document that "tries to defi= ne > everything", with the reasons that the others have stated before. > The document is only a informational document not a standard document, The document I am doing may clarify many terms more to the community (users) than to the designers (experts). > best > > Jiazi YI > I thank you for your input and comments, Best Regards, Abdussalam =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.jiaziyi.com > LIX, Ecole Polytechnique > Route de Saclay 91128 Palaiseau Cedex France > > > > > On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: > >> Dear All >> >> I completed the first version of draft on terminology and submited the >> draft yesterday (with getting some techniq problem), but needed to >> post to know the community feedback and advise. There are other terms >> that was not yet included which will need some advise from you. >> Thanking you, >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Abbreviations Used in The submitted Document >> >> AH Authentication Header >> DAD Duplicate Address Detection >> DPD Duplicate Packet Detection >> DoS Denial of Service >> ESP Encapsulating Security Payload >> IP IPv4 or IPv6 >> ICMP Internet Control Message Protocol >> IIB Interface Information Base >> ETX Estimated Expected number of Transmission >> FIB Forwarding Information Base >> LQI Link Quality Indicator >> L2 Data Link Layer (i.e. 2nd layer in ISO model) >> L3 Internet Layer (i.e. 3rd layer in ISO model) >> LLN Low power and Lossy Network >> MAC Mediam Access Control >> MIB Management Information Base >> MTU Maximum Transmission Unit >> NBMA Non-Broadcast Multi-Access link >> NHDP Neighborhood Discovery Protocol >> ND IP Neighbor Discovery >> OSPF Open Shortest Path First >> RIB Routing Information Base >> SMF Simplified Multicast Forwarding >> TCP Transmission Control Protocol >> UDP User Datagram Protocol >> >> 2.3 Definitions for MANET Terms >> >> 2.3.1 Terms Definition of MANET Communication: >> >> Communications=92 Technology or Facility: >> The means employed by two or more devices/subsystems to transfer >> and/or receive information between them in one way or two way >> communication. MANET communications often uses the wireless >> transmission medium(s) and MAY use some wired mediums (e.g. free >> space, air, water, antenna, coaxial cables, etc.) >> >> Communication Medium: >> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >> satellite system, etc.) that the routing device uses to communicates >> through the transmission medium(s), by providing connectionless and/or >> connection services that MAY be established. The system medium >> includes MAC layer and MAY include the physical Layer. >> >> Communication Channel: >> A subdivision of the physical communication medium (i.e. radio carrier >> signal bandwidth, or the system bandwidth) allowing possibly shared >> independent uses of the medium. Channels may be made available by >> subdividing the medium into; distinct time slots, distinct spectral >> bands, or coding sequence, etc. >> >> MANET Protocol: >> The communication system/subsystem that operates and maintains the >> ad hoc communication technology or facility within MANET. MANET routing >> Protocols often apply distributed algorithms/techniques to disseminate >> or forward routing messages within a MANET routing domain. >> >> Topology: >> An abstract representation of a network (physical or logical), as a >> graph (G) whose topology is defined by a set of routers/bridges (V) that >> communicate through set of links (E), where the G =3D (V, E). >> >> Physical-level Topology: >> A topology of the communication medium networks consists of routing >> devices and physical links. This topology information is updated by >> devices=92 technology in the L2 information Base. >> >> Network-level Topology: >> A topology of the communication system networks consists of routers and >> links. This topology information is updated by routers in its RIB. >> >> Multihop MANET: >> A MANET that its node(s) MAY need(s) more than one IP hop to reach the >> destination. >> >> Reactive Routing: >> An on-demand based routing protocol that operates route discover and >> maintainance the route(s), to reach the demanded destination(s). >> >> Proactive Routing: >> A topology RIB based routing protocol that operates routes and maintains >> the network topology, to reach its known destination(s). Each router >> maintains routes to all reachable destinations at all times, whether or >> not there is currently any demand to deliver packets to those >> destinations. >> >> Upper Layer: >> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >> >> MANET Domain: TBD >> >> MANET Signaling: >> Sending and exchanging some MANET messages/information. >> >> 2.3.2 Terms Definition of MANET Elements >> >> Node: >> A device/subsystem that MUST implement IP and SHOULD participate in >> MANET signaling. It either runs a MANET routing protocol or participate >> in MANET signaling. >> >> Router: >> A MANET node that MUST implement a MANET routing protocol and forwards >> IP packets not explicitly addressed to itself. >> >> Host: >> A node that is not a router. All destinations in MANET that receive >> delivered data are hosts. >> >> Link: >> A link between two node interfaces. This link may be Logical >> (i.e. virtual) link or physical link. Logical links are between two >> logical interfaces and physical links are between two physical >> interfaces. Links are either unidirectional or bidirectional >> (links may be on-link and off-link: see RFC4861). >> >> >> Physical Link: >> a communication facility or medium over which the nodes can >> communicate at the link layer, i.e., the layer immediately below >> IP. Physical interfaces are the nodes=92 attachment to physical links. >> Physical Link types are point-to-point, NBMA, multicast capable, >> and shared-media, etc (see link types in ND [RFC4861]). >> >> Logical (virtual) Link: >> a communication facility (at L3, or upper-layer) over which nodes can >> communicate. This logical link is between two MANET interfaces exists >> if either can be heard by the other. >> >> Link MTU: >> the maximum transmission unit (i.e. maximum unit size in octets), that >> can be conveyed in one transmission unit over the link. >> >> >> Node Interface: >> A node's point of attachment to a link. Each node MUST have at least one >> interface that SHOULD be assigned an IP address. If there is/are more >> than one interface(s) per node then the additional interface(s) MAY be >> assigned an IP address. If an interface is not assigned to an IP address >> it MUST be identified by the MANET routing protocol. An interface MAY be >> assigned one or more addresses. >> >> MANET Interface: >> A node interface that participate in; exchange MANET information used in >> MANET routing or exchange information in MANET neighbor node discovery >> (e.g as the term used in RFC6130). A MANET interface MUST be assigned to >> least one address to communicate. A router interface MUST be >> assigned a routable address which is the main address for the interface. >> >> >> 2.3.3 Terms Definition of MANET Identifications: >> >> An interface MAY be assigned one or more addresses. If the interface is >> a logical interface it MAY be assigned to only logical addresses, but if >> it is a physical interface MAY be assigned with physical address >> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >> MANET addresses). >> >> >> MANET Address >> A MANET-subnet, node, or interface address. Node and interface addresses >> are either IP addresses or RFC5444 addresses. All subnet addresses are >> unicast IP addresses. >> >> Address Block and TLV: as specified in RFC5444 >> >> Routable address: >> A subnet address which can be a destination address. A router MUST be >> able to distinguish a routable address from a non-routable address. >> Broadcast, and multicast addresses, limited in scope to less than the >> entire MANET, MUST NOT be considered as routable addresses. Anycast >> addresses MAY be considered as routable addresses. >> >> Main address >> A routable address (MANET address) that is assigned to one router's >> MANET interface. >> >> Originator address: >> A node address of the node that originated a MANET message (this message >> MUST include the originator address). It MAY be a routable or an >> unroutable address. >> >> subnet prefix >> A bit string that consists of some number of initial bits of an IP >> address. >> >> Interface identifier >> the remaining low-order bits in the node's IP address after the subnet >> prefix. A number used to identify a node's interface on a link. >> >> 2.3.4 Terms Definition of MANET exchange information formats: >> >> Packet: >> A MANET packet of a header plus payload. These packets are either >> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >> in IP packet. Packets are generated by nodes to be sent to >> destination(s) through MANET or through the Internet. RFC5444 packets >> information MAY not be used only by MANET routers. >> >> Message: >> A MANET data message or routing control message. Routing control >> messages are either MANET routing protocol messages or/and RFC5444 >> messages. >> >> Type Length Value coding (TLV): >> A generic way to represent MANET information (as in [RFC5444] and >> [RFC5497]). >> >> Frame: >> A L2 protocol TLV with a header and payload. In some technologies the L2 >> operates a MANET routing protocol as a local area networking system. >> Frames MAY encapsulate MANET packets to be tunneled through a >> telecommunication network. >> >> Route Request Message (RREQ) >> A message is used to discover a valid route to a particular >> destination address, called the RREQ Target Node. When a router >> processes a RREQ it learns routing information on how to Originator >> Node. >> >> Route Reply Message (RREP) >> A message is used to disseminate routing information about >> the RREP Target Node to the RREQ Originator Node and the intermediate >> routers. >> >> Route Error Message (RERR) >> A message is used to disseminate the information that a route is >> not available for one or more particular addresses. A RERR message is >> used to indicate that a router does not have a forwarding route >> to one or more particular addresses. >> >> 2.3.5 Terms Definition Related to MANET Protocol Operation: >> >> Hop-by-hop Routing: (TBD) >> A dynamic routing that routes to destination by routing table. >> >> Source Routing: (TBD) >> A dynamic routing that its route path is provided in the IP packet. >> >> Route Discovery: TBD >> >> Route Maintenance: TBD >> >> Neighbor discovery: (TBD) >> A node discovers neighbors only if the node receives from it's >> neighbors. >> >> >> Multipoint relay (MPR): (TBD) >> A router X1 is an MPR for a router Y1, if router Y1 has indicated >> its selection of router X1 as an MPR in a recent HELLO message. >> Router X1 may be a flooding MPR for Y1 if it is indicated to >> participate in the flooding process of messages received from >> router Y1, or it may be a routing MPR for Y1, if it is indicated to >> declare link-state information for the link from X1 to Y1. It may >> also be both at the same time. >> >> MPR selector: >> A router, Y, is a flooding/routing MPR selector of router X if >> router Y has selected router X as a flooding/routing MPR. >> >> Router Parameters: >> boolean or numerical values, specified for each router, and not >> specific to an interface. A router MAY change router parameter >> values at any time, subject to some MANET constraints. >> >> MANET Routing Metric: >> A MANET routing cost that is governed by specific rules and properties >> defined by the MANET routing protocol which captures specific link or >> node characteristics. Examples of basic metrics are hop-count, ETX, LQI, >> etc. >> >> Distance Vector Metric >> A metric class related to rules of the MANET interface and MANET path >> distance. The metric can be calculated by the distance vector routing >> algorithm class used by the MANET routing protocol. A metric of the >> distance a message or piece of information has traversed. The minimum >> value of distance is the number of IP hops traversed. >> >> Link State Metric >> A metric type related to the MANET network-topology status and logical >> links' states. This metric is calculated by the link state routing >> algorithm class used by the MANET routing protocol. A metric type maybe >> EXT, LQL, etc. >> >> Link Metric: TBD >> >> Neighbor Metric: TBD >> >> Path accumulated: >> The RREQ message accumulates intermediate routers that are in path to >> destination(s). >> >> Protocol Sequence Number: >> A Sequence Number related to a MANET protocol that maintained by each >> protocol subsystem process. This sequence number is used by other >> subsystems to identify the temporal order of protocol information >> generated. >> >> Router Sequence Number: >> A router sequence number is maintained by each router process. The >> sequence number is used by other routers to identify the temporal >> order of routing information generated and ensure loop-free routes. >> >> MANET Information Base: >> A collection of information (in Table or Cache structure) maintained >> by MANET protocols and which is to be made available to MANET routing >> protocols. An Information Base may be associated with a MANET router >> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB). >> >> RIB Entry: >> The RIB entry is a conceptual data structure. Implementations may use >> any internal representation that conforms to the semantics of a route >> as specified in the router specification. >> >> 3. IP Considerations and Terminology >> >> All MANET nodes MUST implement IP and all MANET routers MUST >> run/implement at least one MANET routing protocol. The >> terminologies described in this document can be used for >> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >> packets but IPv6 addresses MUST not be in IPv4 packets. >> >> IP address: >> IPv4 addresses or IPv6 addresses. >> >> IP Packet: >> The packet header plus payload as specified in [RFC791] and [RFC2460] >> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >> specified by RFC5498. >> >> Mobile IP considerations: >> Mobile IP terms are provided in [RFC6275], and this technology >> assists nodes while connected through the Internet domain(s). MANET >> is an infrastructure-less network that is able to communicate with >> the Internet (i.e. an IP infrastructure network). >> >> 4. Security Consideration and Terminology >> >> It is RECOMMENDED that MANET routing protocols consider security >> issues because the MANET's transmission medium is wireless which make >> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >> routing information while traversing the MANET MAY be used by an >> intruder node, to obtain MANET data traffic or/and attack the MANET >> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >> by using IPsec, AH, DAD, and ESP techniques, and other. However, >> it is RECOMMENDED that MANET detects attackers and possible threats. >> >> The following are some terminology related to MANET threats and >> security. >> >> Attacker: A node, present in the network and which intentionally seeks >> to compromise information based in MANET router(s). The Attacker MAY be >> a compromised MANET router if obtained MANET identity or routing >> information. >> >> Compromised MANET Router: An attacker router, present in MANET and >> which generates syntactically correct routing control messages. Control >> messages emitted by compromised router(s) may contain additional >> information, or omit information, as compared to a control message >> generated by a non-compromised router located in the same MANET >> topological position. >> >> Legitimate MANET Router: A MANET router, which is not a Compromised >> MANET Router. >> >> Jamming Attack: >> The attacker transmits massive amounts of interfering radio traffic, >> which will prevent legitimate traffic (e.g., routing and data traffic) >> on all or part of the MANET. Indirect jamming attacks MAY occur by >> influencing Legitimate MANET Router to transmit unnecessary information. >> >> Eavesdropping: >> Obtaining a copy by the attacker of the transmitted MANET routing >> information or the transmitted data information from its neighbor's >> transmitted radio packet. Attacker=92s processes MANY be used by attacke= r >> to mislead routing. Eavesdropping does not pose a direct threat to the >> MANET or to its routing. >> >> Identity Spoofing: >> Attacker sends routing messages, pretending to have the MANET identity >> of another node. >> >> Link Spoofing: >> Compromised MANET router sends routing messages to neighbor node(s) >> providing incorrect set of link information. >> >> Replay Attack: >> A Compromised router in one MANET region records control traffic >> information and replays the recorded information in a different MANET >> region (this type of attack is also called the Wormhole attack). >> >> Broadcast Storm: >> Compromised MANET router may attack the MANET by attempting to change >> the MANET flooding algorithm(s) to increase routing overheads or/and to >> increase the route discovery delay. Broadcast storm degrades the data >> traffic delivery and MANET performance. >> >> Falsification in MANET: >> The compromised MANET router sends false routing information into MANET. >> False routing information received in MANET, MAY create unrealistic >> information bases. >> >> ICMP Attacks: >> The generation of ICMPv6 error messages may be used by compromised MANET >> router to attempt DoS attacks by sending an error-causing source routing >> header in back-to-back datagrams. As the ICMP messages are passed to the >> upper-layer processes, it is possible to perform attacks on the upper >> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >> RECOMMENDED to perform some form of validation to ICMP messages (using >> the information contained in the payload of the ICMP message) before >> acting upon them. >> >> Source Routing Attacks: TBD >> >> Acknowledgments: >> >> This work has used/modified terms of the following documents: RFC2462, >> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >> Gratefully acknowledge to the IETF community and all contributions. >> >> Reference: >> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >> NHDP", Work in progress, March, 2012. >> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >> Networks", John Wiley & Sons, March 2007. >> ISBN: 978-0-471-75688-0. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> I hope to get some advise from the Internet community to make the >> definitions more suitable/accurate, because I MAY misunderstood. >> Thanking you, >> >> Best Regards >> >> Abdussalam Baryun >> University of Glamorgan, UK >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From abdussalambaryun@gmail.com Tue Jul 3 12:48: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 CC6EC21F8732 for ; Tue, 3 Jul 2012 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 zbBM4D90IpbI for ; Tue, 3 Jul 2012 12:48:01 -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 D157A21F872A for ; Tue, 3 Jul 2012 12:48:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4920033vbb.31 for ; Tue, 03 Jul 2012 12:48:09 -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=HMcXVNv6QkmZTFGvsjVW5hKnpJcfnK7xvKknRrWPWSo=; b=UdDVzLh4OQO+Afe/3KDZ79NSou0BP77k7zjfuwC0+QRk4ZMke5JxdmaNVXb6+fg7Db KSFwA5gf0dFYEY5WqzUATF/X3yG+c7ZlyEZFNLIXafoU7KYfFKSREIvhsoqhdViwgW8f uEhEshBM96bWokBhhf3dA8xnMcXZoGy8CjrWYpbMwz9wUNZVWzLCAhqsXu0PZxE/U7H9 XCEsfUixsblDDs9UOk5g6ho5lsbbTeLys7FZk6zCUcs3hOAYJBj0wk/TpYzAGRFGy+8h xj3madjN/FblVVhZ/5c8zYDOx229meS3bwnFhVWpusmNTM7YYpCQ53wv1tOizH++7VCh icMA== MIME-Version: 1.0 Received: by 10.220.219.137 with SMTP id hu9mr7152168vcb.4.1341344889088; Tue, 03 Jul 2012 12:48:09 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Tue, 3 Jul 2012 12:48:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jul 2012 21:48:09 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:48:01 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D possible duplication =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D +1 I still don't see good reasons of dlep-draft to leave 5444 (different from AODVv2), I support the investigation of using 5444. DLEP is like RFC6130 as discovery tool, but still we should not force the investigation result. Please note that RFC5444 was designed for routers exchange not for L2 technologies. I heard before two months a suggestion for DLEPv2, so we may give the first version it way and v2 may include 5444. AB =3D=3D=3D=3D=3D=3D=3D=3D=3D > On Tue, Jul 3, 2012 at 6:59 PM, Stan Ratliff (sratliff) > wrote: >> Chris, >> >> OK, that's fair enough. As you mention, since DLEP isn't a routing >> protocol, and can exist quite cleanly on its own port, that's the >> direction I'm leaning. I think there are also uses outside the MANET WG >> where use of 5444 would actually cause more code to be employed, and >> increase packet overhead (think ROLL)=85 > > I think the small overhead is pretty meaningless because DLEP is not > sent over the mesh links, just between radio and router. > > Also the "use 6 byte addresses for MACs, use TLVs for IPv4/6" will > work quite well for DLEP, because many radios will not even need the > IPv4/6 part at all, especially with the bridged data-path DLEP > describes. > > There should be the options to transmit IPv4/6 addresses over DLEP if > they are available, but I wonder if this would be a common usecase. > > Most of the workinggroup seems to have the opinion that DLEP should > move to full RFC5444 compliance, because it will fit the purpose of > DLEP fine and spare the IETF "just another proprietary data format". > With RFC5444 we can easily get to a point where we get a protocol that > can be extended for more metrics without the need of a version field, > which will simplify future DLEP revisions. > > 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 Jul 3 22:01: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 A9C4A21F86EC for ; Tue, 3 Jul 2012 22:01:36 -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 hra7g-YxfzeF for ; Tue, 3 Jul 2012 22:01:35 -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 5D46E21F86EA for ; Tue, 3 Jul 2012 22:01:30 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so4034169wib.13 for ; Tue, 03 Jul 2012 22:01: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=UgJnRMgtJPGlRrXuoGGfVp3LVXJb23LDFFB3m2IT9LY=; b=TMhMS5u2CnJuwYZDGMxDQ/xbK3ihYrX6CNfhLeclVd4mtgrz1oMC3Z/Dusv+WZ1jYR sVTtUjMrbX0yD1sru4AFWgjkIDoR9Qpz7lhh9VSrXQEo/K8jj28SXEMEYQ0CNzyQKq2d Ke4XBzfxJIvUq8lgRc8FMmXNHQc+WZJVizWTM3imKYTjjQ9LxepEzlNB5pdI/PMoVYJD Fii/S6HmDSEk8+WiSffNpm9YmdN6gTjxk0W3MpdPmmoniSrAk7oPNnbvP5qPfDCIlqNk xuWk0ThBTnJdXGR4tHyNNLS2fgaY5yTJgF4acWw0QfQ+5k+B6X8lfC9r2PeV6TlG4+iJ HpDg== Received: by 10.180.98.69 with SMTP id eg5mr30625208wib.3.1341378099726; Tue, 03 Jul 2012 22:01:39 -0700 (PDT) Received: from [10.87.3.145] ([80.187.201.33]) by mx.google.com with ESMTPS id fb20sm42693230wid.1.2012.07.03.22.01.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 22:01:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> Date: Wed, 4 Jul 2012 07:01:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkqx26JKbVd9vpiY3iRTJ+INcWzBM2ORQFcTsDT/ftdlArh+RBSDB+8rZnJC8X9n+cSlUkX Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:01:36 -0000 Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >=20 >> There should be the options to transmit IPv4/6 addresses over DLEP if >> they are available, but I wonder if this would be a common use case. >=20 > I most definitely hope it will become a common use case. As we've = talked about before, this addition helps to overcome issues like = population of IPv4 ARP caches=85. something that either needs a-priori = knowledge, which is not likely in my deployments, or some mechanism such = as this.=20 IMHO Cisco should update their ARP implementation, so it supports RFC = 5889. ND should not be a problem. Most .!!!! problems I have seen were caused by lost packets on last hop = router, not on transit links. Teco= From teco@inf-net.nl Tue Jul 3 22:41: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 B856721F86CA for ; Tue, 3 Jul 2012 22:41:57 -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 1-ODFEYvcd-s for ; Tue, 3 Jul 2012 22:41:57 -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 E7C8121F86A4 for ; Tue, 3 Jul 2012 22:41:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4753040wgb.13 for ; Tue, 03 Jul 2012 22:42:03 -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=hlnaIMPTFM8fynMcDZUsTvcsZTjlzam3D79Ce6w6Jgw=; b=GItU8eWeTGwgGXhC0CKVpLaFmZ450+kPY+p8gjS1iyHJpi/k9SXAPiBcMx9Ye5kZ6f PDYFRGx8CElZdC/KyxJDUMYWELavHYXj1OAuXc+mTAboYVSUwJVSTfgfSPhV1js9IbU/ 6EvA2V94ZTc2dr/EI9e7ruSiSgWG0ZRM3wGuj8CQb4IT3PNARUCpXcKLhXP+EdmuxyDY EZOk6TBb/ft7c2SwpW0cC2fpaMjkGJo4YQrAOedaJmTPQSD2KYZmIukoTs+FFfegEkJm MZRv4QRYc+sufttO4DV/DqQlKyiCi4an4UT9MNItV2SYGbEbUoNowZGtUaUNn2ltB4NF 7q7A== Received: by 10.180.83.234 with SMTP id t10mr23903330wiy.0.1341380523626; Tue, 03 Jul 2012 22:42:03 -0700 (PDT) Received: from [10.87.3.145] ([80.187.201.33]) by mx.google.com with ESMTPS id ce3sm63281895wib.11.2012.07.03.22.41.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jul 2012 22:42:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> Date: Wed, 4 Jul 2012 07:42:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn+CISN3AQ5TDFXCzEaWGP8dx8fMnkaSUFMC9p5GV9aUu6xrEHs6DDJ9XOjTXWHd/JteJZz Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:41:57 -0000 Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>=20 >> Most of the workinggroup seems to have the opinion that DLEP should >> move to full RFC5444 compliance, because it will fit the purpose of >> DLEP fine and spare the IETF "just another proprietary data format". >> With RFC5444 we can easily get to a point where we get a protocol = that >> can be extended for more metrics without the need of a version field, >> which will simplify future DLEP revisions. >=20 > And again, we disagree on that point.=20 Stan, you could set up a poll to find out the working group opinion. In the discussion on full RFC 5444 compliance, or just use it as a=20 transport container, my non-important opinion: - dlep-02 implements reliable transport, with tiny chunks of = to_be_acked=20 data and the ack messages=20 - this reliable transport requires (complex) state machines, but = provides=20 reduced data volume over the wire - when transferred data is highly variable, this reliable transport=20 doesn't make sense. A timer based refresh, with triggered fast = updates,=20 would better fit the required functionality - RFC 5444 provides a mechanism to compress larger arrays of data. This=20= could be used for MAC address TLV's, for transfer of ever changing = link=20 metrics - for reliable transfer, one option would be using another protocol,=20 already standardized. It is called TCP, if I remember well. For discovery, TCP doesn't work well...=20 - because dlep acts on local, often high speed links, reduction of = volume of transferred data has low priority. I guess we have to choose how to implement the link metrics exchange. If we opt for reliable transfer, I prefer TCP. For a straightforward stateless transfer, RFC 5444 MAC address TLV's looks an obvious choice. Opinions on address TLVs would be influenced on having the parser = already,=20 or facing something on the todo list. Dito the validity timer stuff. Teco From john.dowdell@cassidian.com Wed Jul 4 02:03: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 AE49F21F861D for ; Wed, 4 Jul 2012 02:03:10 -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 F+wWQASNjDuQ for ; Wed, 4 Jul 2012 02:03:10 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id C2A5621F85F7 for ; Wed, 4 Jul 2012 02:03:07 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 04 Jul 2012 11:03:16 +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); Wed, 4 Jul 2012 11:03:15 +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); Wed, 4 Jul 2012 11:03:14 +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, 4 Jul 2012 11:03:14 +0200 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 Jul 2012 10:03:12 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fDTNziis0TP2SHLy5OTALFAAH9JaA References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> From: "John Dowdell" To: "Teco Boot" , "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 04 Jul 2012 09:03:14.0830 (UTC) FILETIME=[D86F9AE0:01CD59C3] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19016.003 X-TM-AS-Result: No--31.375400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , manet@ietf.org, Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:03:10 -0000 Based on our experience with using DLEP, I would request that it becomes mandatory to supply either an IPv4 or IPv6 address of the far end router during a Neighbour Up/Down message as that would speed up the routing process. Total contact time between routers in a MANET could be very short, and anything that helps speed the establishment of the connection is welcome. As to the 5444 debate, I do not see the need for 5444 compliance in DLEP. I agree with the 'it's not a routing protocol' stance, and in my view it just adds unnecessary complexity, but I'm open to discussion on the extensibility issue. =20 John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot Sent: 04 July 2012 06:02 To: Stan Ratliff (sratliff) Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry (boberry); Greg Harrison (greharri) Subject: Re: [manet] Status of DLEP-draft at Cisco? Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende geschreven: >=20 > On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >=20 >> There should be the options to transmit IPv4/6 addresses over DLEP if >> they are available, but I wonder if this would be a common use case. >=20 > I most definitely hope it will become a common use case. As we've talked about before, this addition helps to overcome issues like population of IPv4 ARP caches.... something that either needs a-priori knowledge, which is not likely in my deployments, or some mechanism such as this.=20 IMHO Cisco should update their ARP implementation, so it supports RFC 5889. ND should not be a problem. Most .!!!! problems I have seen were caused by lost packets on last hop router, not on transit links. Teco _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Jul 4 02:46: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 E6D3821F87B2 for ; Wed, 4 Jul 2012 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.742 X-Spam-Level: X-Spam-Status: No, score=-9.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 9oUOMgcpA5XZ for ; Wed, 4 Jul 2012 02:46:20 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6721F873D for ; Wed, 4 Jul 2012 02:46:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,521,1336345200"; d="scan'208";a="252073030" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 04 Jul 2012 10:46:17 +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 q649kGFf025818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jul 2012 10:46:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Wed, 4 Jul 2012 10:46:16 +0100 From: "Dearlove, Christopher (UK)" To: John Dowdell , Teco Boot , "Stan Ratliff (sratliff)" Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fkJPtrdHUq0SlS58HjbKfcgAH9JaAAAHFq3A= Date: Wed, 4 Jul 2012 09:46:15 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.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: "Greg Harrison \(greharri\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:46:21 -0000 With regard to 5444, there is a (good in my opinion) argument that the curr= ent version is technically worse than either of the options of a better fit= to 5444 (which I think the shape of is clear, although there would need to= be work on the details) or a new non-5444 format. (A key question about th= e latter is flexibility for the future; that is offered by 5444.) Of course= the current version has the advantage that it is the current version. --=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: John Dowdell [mailto:John.Dowdell@Cassidian.com]=20 Sent: 04 July 2012 10:03 To: Teco Boot; Stan Ratliff (sratliff) Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry (bober= ry); Greg Harrison (greharri) Subject: RE: [manet] Status of DLEP-draft at Cisco? ----------------------! 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. -------------------------------------------------------- Based on our experience with using DLEP, I would request that it becomes mandatory to supply either an IPv4 or IPv6 address of the far end router during a Neighbour Up/Down message as that would speed up the routing process. Total contact time between routers in a MANET could be very short, and anything that helps speed the establishment of the connection is welcome. As to the 5444 debate, I do not see the need for 5444 compliance in DLEP. I agree with the 'it's not a routing protocol' stance, and in my view it just adds unnecessary complexity, but I'm open to discussion on the extensibility issue. =20 John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot Sent: 04 July 2012 06:02 To: Stan Ratliff (sratliff) Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry (boberry); Greg Harrison (greharri) Subject: Re: [manet] Status of DLEP-draft at Cisco? Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende geschreven: >=20 > On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >=20 >> There should be the options to transmit IPv4/6 addresses over DLEP if >> they are available, but I wonder if this would be a common use case. >=20 > I most definitely hope it will become a common use case. As we've talked about before, this addition helps to overcome issues like population of IPv4 ARP caches.... something that either needs a-priori knowledge, which is not likely in my deployments, or some mechanism such as this.=20 IMHO Cisco should update their ARP implementation, so it supports RFC 5889. ND should not be a problem. Most .!!!! problems I have seen were caused by lost packets on last hop router, not on transit links. Teco _______________________________________________ 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 Jul 4 03:57: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 69BA721F86EA for ; Wed, 4 Jul 2012 03:57: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 jOd6wy134VEr for ; Wed, 4 Jul 2012 03:57: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 4D21E21F87B2 for ; Wed, 4 Jul 2012 03:57: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 1SmNHA-0006ad-0b for manet@ietf.org; Wed, 04 Jul 2012 12:57: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 1SmNH9-0000V6-UE for manet@ietf.org; Wed, 04 Jul 2012 12:57: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, 4 Jul 2012 12:57:39 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Jul 2012 12:57:39 +0200 Message-ID: <4FF4219B.3080606@fkie.fraunhofer.de> Date: Wed, 4 Jul 2012 12:57:31 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000405040201060409060602" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Jul 2012 10:57:39.0775 (UTC) FILETIME=[D44314F0:01CD59D3] X-Virus-Scanned: yes (ClamAV 0.97.3/15109/Wed Jul 4 04:41:32 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7fbbc3bfe2de368a9522e1ccdb970b4 Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 10:57:34 -0000 --------------ms000405040201060409060602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/04/2012 11:03 AM, John Dowdell wrote: > Based on our experience with using DLEP, I would request that it become= s > mandatory to supply either an IPv4 or IPv6 address of the far end route= r > during a Neighbour Up/Down message as that would speed up the routing > process. Total contact time between routers in a MANET could be very > short, and anything that helps speed the establishment of the connectio= n > is welcome. I would say it should be mandatory if the knowledge is present on the=20 DLEP-capable device. If you do not know the IP addresses of each=20 partner, you can still use DLEP and leave this job to the router. > As to the 5444 debate, I do not see the need for 5444 compliance in > DLEP. If we can find a good fit for all the DLEP use cases with RFC5444, I see = no need to specify another packet format for it. DLEP transports=20 information (many of them optional) about the local radio/modem and=20 information (also many of them optional) about connection between=20 radios/modems. This seems to be a very good description of the concept=20 of RFC5444. It also needs multiple kinds of messages, which makes message=20 aggregation into a single block of information an useful feature. At last, it needs to interact with routing protocols (especially MANET=20 protocols), which makes reusing rfc5444 a good thing. > I agree with the 'it's not a routing protocol' stance, and in my > view it just adds unnecessary complexity, but I'm open to discussion=20 > on the extensibility issue. What do you think is the difference in implementing a custom DLEP=20 protocol language and a RFC5444 compliant one? In the second case, you=20 might be able to reuse code written for routing protocols, in the first=20 one you have to do it from scratch. 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 --------------ms000405040201060409060602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA3MDQxMDU3MzdaMCMGCSqGSIb3DQEJBDEWBBS1zmSMoVmiiqwzOnEOIEn228HmsDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAhhLBDO9ov1fh8zB0Ug7NOalpwSYtw4N9bBxNc5XwzACw xX33jocNuZPB7Ta1lFimBzCxgwLEAXo4mVB9HMgYyzG7KqXGGU0P8ZRwaXfyNvBdSR36CsKw DtOxdfPn664rAXH3m/Q7hkQskpzxn0QXRbO560eUSbtRadAUusyUUi+jAz6WO/WSc8V/Dxqc YMHLTwKgzFwZhagPtbD67hCYDfa8yBZOkBAgROO0F3eXYc1kVH+RaSIu3FSlEpcxagL4MJMJ Ut/vaSNv+Gss+98gT1tUgbuZSfG72nigUgozRxNdmgcM40700H6Zcd+fgDXNaoDb/X0tJWyB F/s/dp54ygAAAAAAAA== --------------ms000405040201060409060602-- From abdussalambaryun@gmail.com Wed Jul 4 04:17: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 ACBCB21F87CA for ; Wed, 4 Jul 2012 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 nwf7IbW7DEYx for ; Wed, 4 Jul 2012 04:17:21 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2272E21F87B7 for ; Wed, 4 Jul 2012 04:17:21 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6969621ggn.31 for ; Wed, 04 Jul 2012 04:17: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:cc:content-type; bh=E+Sosta9o8zRqvn/Zp3z22cwSH2uDYcbMXVcAeXga5E=; b=x2JTfmMup/zaHXpSImECMuXwckAxnmRwYA0Grif8v18Hq2CaMUE9wfBDpzCLEG0hTF PmebJqbplNKW5SgwLqHlFp+9gGcMCV8OvZDqQopnRYjpBfqfDbzXdgEurOvBHdWVKcQF 7vhF3/tQgGuNGSygXQ1iSvkhkMm1WburHriUfXoxS+aTOIA6AVuL+3w+Gx2CWdelyQXf F0zqBE3RhgMjkTHgcGRUb9QCgkwFSsbg/kqag2rfnyP0n84/gac1iV8RXyzV/s/4w4bh zCtHndthmS14EZHEQlCR6C8Su+vSyPRH2ZKIDq3ieWCfP1iqOuwsDiD/iyDUhlJPx72b F4+w== MIME-Version: 1.0 Received: by 10.50.187.233 with SMTP id fv9mr13227024igc.59.1341400651046; Wed, 04 Jul 2012 04:17:31 -0700 (PDT) Received: by 10.64.32.168 with HTTP; Wed, 4 Jul 2012 04:17:31 -0700 (PDT) Date: Wed, 4 Jul 2012 13:17:31 +0200 Message-ID: From: Abdussalam Baryun To: John Dowdell , "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Bo Berry , Stan Ratliff Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:17:21 -0000 Hi John and Chris I am more interested in DLEP (of any version) with RFC5444 (general manet format)because DLEP serves routers without a need of specifying routing protocol (it is general interaction with any router protocol), also complexity may not be an issue because DLEP use-case is mostly for complex networking (if I understood the use-case). If DLEP uses 5444 it may interact with NHDP for more advantages. Usually if we take the case of OLSRv2 with DLEP the channel can be through NHDP or direct between DLEP and router. Also if we consider that many other routings may use NHDP (MANET-interface) then it is nice to have DLEP with 5444 for its use flexibility, I recommend the DLEP designers to consider if they taking the general interaction with all routers, then it is more simpler design to use 5444, but if they choose specific interaction with routers they may not use 5444 but can be complex (e.g. routers: AODV, OLSR, LOAD, future-manet-routers) Regards Abdussalam Baryun University of Glamorgan, UK From teco@inf-net.nl Wed Jul 4 04:19: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 B715A21F85C9 for ; Wed, 4 Jul 2012 04:19:09 -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 pzGP3Nmxl4EK for ; Wed, 4 Jul 2012 04:19:08 -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 67C1121F87D8 for ; Wed, 4 Jul 2012 04:19:07 -0700 (PDT) Received: by eekd4 with SMTP id d4so3082330eek.31 for ; Wed, 04 Jul 2012 04:19:17 -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=Px6dPN7gxCqFqs+MIg09SEhRqHx2pDyIscSmP8/tPW4=; b=KICtofhTJpBLXvmdKMDcEGFdYJoXM5GImfY2qu1CU12IWGvq6SreE10CPwa9xlgKaA Xc+MkTJDabu5rclEhsKVvoqBKEB4aSR7WDYQ6zRSRvKoMCV9Y4dWHt6SpukjPHlRUybX MtRx8NBUC/U2Nq03F/hGLU//W0BOSIMxORxEqeHNAcoTlJX+z3PHhQ0t/BZ1HLCPrtif V2JT40pIn1YSzKdKdyySIGyzZOkwalJ/Q5Yibn0+YJc3ag89vLmCtFxrdcpUnA327PAr uIxlfWYrtVojYTYNzBTB9hrBr5HfxwTeW54NSOq7+cZ1U6+n2K0f2bgiLy/Ci19+GUg7 bPzA== Received: by 10.14.95.207 with SMTP id p55mr5204346eef.40.1341400757417; Wed, 04 Jul 2012 04:19:17 -0700 (PDT) Received: from [172.16.4.192] ([188.205.88.52]) by mx.google.com with ESMTPS id a16sm53100771eeg.0.2012.07.04.04.19.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jul 2012 04:19:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> Date: Wed, 4 Jul 2012 13:19:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> To: John Dowdell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnp4dZ0lVjwUgrkXN+DTSjg0i73vjiNl1ZPZFWqC/X+M2YSLmmLD5Uqus0I9W7ffjKsvtRQ Cc: "Dearlove, Christopher \(UK\)" , manet@ietf.org, Shawn Jury , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:19:09 -0000 Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: > Based on our experience with using DLEP, I would request that it = becomes > mandatory to supply either an IPv4 or IPv6 address of the far end = router > during a Neighbour Up/Down message as that would speed up the routing > process. I like fast convergence. The question is how to do it. Neighbor up/down would fire triggers in the L3 hello mechanism. Up would=20= start send out new hello's. Down would update the link state, and = optionally send out new hello's. The IP addresses, related to neighbor up, could be used for unicast = hello's or updates in neighbor tables directly. So it may help. But do we set = adjacency=20 to what DLEP provides? Or mandate verification with L3 hello's? Often, all info for neighbor cache is already available in the hello = packet.=20 There is running code that actually use it. Another approach is trigger = L2=20 address resolving for all next-hop IP addresses. IMHO good quality = routers=20 do that / should do that, also in a non-MANET environment. > Total contact time between routers in a MANET could be very > short, and anything that helps speed the establishment of the = connection > is welcome. Yes, with limits on "anything". Is header snooping acceptable? My main concern is, there are already enough methods that can do the = job. Teco From abdussalambaryun@gmail.com Wed Jul 4 04:43: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 3515A21F86D6 for ; Wed, 4 Jul 2012 04:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 4Zf57FHvUltr for ; Wed, 4 Jul 2012 04:43:31 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D021F87A4 for ; Wed, 4 Jul 2012 04:43:31 -0700 (PDT) Received: by yhq56 with SMTP id 56so8566017yhq.31 for ; Wed, 04 Jul 2012 04:43:36 -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=973aSjiFSMr3fiTPVnvu1zJGFdkn7SuUlQJHWzBG5Dw=; b=RKmf8Ym/Y2qu0OhghR0UXn5ssMAFyldaI2gG7uCe/D/Vqk0uEWgTUCG09eWbVKsW9j NnxxgCZAwD/Jl1evw1Z48OlnkGn32xAM8gAoCyXpRrHLPSWDPWvI3hVh9q2PLkJq5Wwn NLo2MCV1gIXeVnYAPq0pt3YaduXl34/OyOqOboQb/OZcpNUpfopN79BTwcUDcZP9pnnG xWGkCTZisDfjRPOU81Mf/q4A85+HZuDsft++Bi0oBBc5VcyZRPvl73W9lwt0241OmpAZ YH/u9nQGABuBxCYrcO/ck5tAO91aOSZr6C9qmhsdHpjq1ICgGuUGIgAV9wo5muP17PNd 5CWQ== MIME-Version: 1.0 Received: by 10.50.187.233 with SMTP id fv9mr13303190igc.59.1341402215958; Wed, 04 Jul 2012 04:43:35 -0700 (PDT) Received: by 10.64.32.168 with HTTP; Wed, 4 Jul 2012 04:43:35 -0700 (PDT) Date: Wed, 4 Jul 2012 13:43:35 +0200 Message-ID: From: Abdussalam Baryun To: ietf@thomasclausen.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Stan Ratliff Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:43:32 -0000 Hi Thomas, >Just for information, the coming version of LOADng will use 5444 (cleanly). but last draft: does not use RFC5444 I am interested to know about the LOADng, while you requested its consideration in MANET, but we still not much discussed the status of the work, as now some participant and I thought that LOADng didn't use RFC5444. Please give us some input of updated issues. As was waiting for the new version which was expected within June as per one co-author discussion. Thanking you, Best Regards Abdussalam Baryun =============== To: "Dearlove, Christopher (UK)" Subject: Re: [manet] Status of DLEP-draft at Cisco? From: Thomas Heide Clausen Just for information, the coming version of LOADng will use 5444 (cleanly). -- Thomas Heide Clausen http://www.thomasclausen.org ================================================ >Abdussalam, >we are aware that the LOADng draft needs some updates, before it could be considered by the MANET WG, notably support for RFC5444 and some editorial updates. We plan to work on these in the next days, and will submit a new revision likely next week. So, just stay tuned! >Best >Ulrich On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun wrote: > On 5/29/12, JP Vasseur wrote: >> >> We already have two different WG: MANET and ROLL. >> > > Yes we know. That is why LOADng authors should choose either to serve > LLN that is considered by ROLL WG or they choose serving MANET, and it > is considered by MANET WG. But the question is which suggestion option > do you think is better for LOADng-draft? > >>MANET is tasked, amongst other, to publish a reactive >>routing protocol. > > MANET is tasked to publish routing protocols that serve the MANET > network. IMO, MANET-WG is not tasked to publish protocols serving only > LLN just because the protocol is reactive. Please note that LOADng > protocol does not even mention MANET nor mobile routers in its draft, > which confuses its purpose, the authors should look into that. > > Abdussalam Baryun From ietf@thomasclausen.org Wed Jul 4 04:47: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 A471721F8839 for ; Wed, 4 Jul 2012 04:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKQmagDH+mpr for ; Wed, 4 Jul 2012 04:47:31 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA41B21F8838 for ; Wed, 4 Jul 2012 04:47:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E6BE4557FCF for ; Wed, 4 Jul 2012 04:47:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 92B021BD3BA4; Wed, 4 Jul 2012 04:47:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.77.58.141] (37-8-174-118.coucou-networks.fr [37.8.174.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A80FD1BD3BA3; Wed, 4 Jul 2012 04:47:37 -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: <0140CDDB-A528-4EE8-A4C8-FB7D3CBDBB76@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Wed, 4 Jul 2012 13:48:04 +0200 To: Abdussalam Baryun Cc: manet , Stan Ratliff Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:47:31 -0000 On 4 Jul 2012, at 13:43, Abdussalam Baryun wrot= e: > Hi Thomas, >=20 >> Just for information, the coming version of LOADng will use 5444 (cleanly= ). >=20 > but last draft: does not use RFC5444 >=20 Hence the use of the phrase "the coming version will....". Thomas > I am interested to know about the LOADng, while you requested its > consideration in MANET, but we still not much discussed the status of > the work, as now some participant and I thought that LOADng didn't use > RFC5444. Please give us some input of updated issues. As was waiting > for the new version which was expected within June as per one > co-author discussion. Thanking you, >=20 > Best Regards > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > To: "Dearlove, Christopher (UK)" > Subject: Re: [manet] Status of DLEP-draft at Cisco? > From: Thomas Heide Clausen >=20 > Just for information, the coming version of LOADng will use 5444 (cleanly)= . >=20 >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Abdussalam, >=20 >> we are aware that the LOADng draft needs some updates, before it could > be considered by the MANET WG, notably support for RFC5444 and some > editorial updates. We plan to work on these in the next days, and will > submit a new revision likely next week. So, just stay tuned! >=20 >> Best >> Ulrich >=20 > On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > wrote: >> On 5/29/12, JP Vasseur wrote: >>>=20 >>> We already have two different WG: MANET and ROLL. >>>=20 >>=20 >> Yes we know. That is why LOADng authors should choose either to serve >> LLN that is considered by ROLL WG or they choose serving MANET, and it >> is considered by MANET WG. But the question is which suggestion option >> do you think is better for LOADng-draft? >>=20 >>> MANET is tasked, amongst other, to publish a reactive >>> routing protocol. >>=20 >> MANET is tasked to publish routing protocols that serve the MANET >> network. IMO, MANET-WG is not tasked to publish protocols serving only >> LLN just because the protocol is reactive. Please note that LOADng >> protocol does not even mention MANET nor mobile routers in its draft, >> which confuses its purpose, the authors should look into that. >>=20 >> Abdussalam Baryun From abdussalambaryun@gmail.com Wed Jul 4 13:11: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 944D421F85DD for ; Wed, 4 Jul 2012 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 9vTuohYEb+9F for ; Wed, 4 Jul 2012 13:11:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5508D21F85D5 for ; Wed, 4 Jul 2012 13:11:07 -0700 (PDT) Received: by vcqp1 with SMTP id p1so5563977vcq.31 for ; Wed, 04 Jul 2012 13:11:13 -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=7n8rI9ynmPTEiXUlNWf6iT7BP/UFIUdMj92OiH9o+xk=; b=eeJCWKt+CbekSZqZvd0+MvwpqSQ81aTM5e6aCwKumojI2H8sQcAKjWzgqWu6ETbovP THusiO8M1K0q3wDFRYLqQxuNVaeQgiMKFLXyQQKzCMM2AvWXSv3oKNmeizT6Po1Rq/RA 1SFjyM1kx7wcTcaKppJAfpv/x2HFICtZgZ5nAaBSAlaA99+U3s7sjUZTrA214tAXlfir dW3B7jDCu/mvPfVxeHJY8xUd1qvB5HkeKjzw0PPbAYRRy5VVEaZMkSNaFE+TOcqalz53 HowSyFvFza1QHvYZScPmXh71UqyTL1P6cYM6iZ0pYRygRgDU6e+q44Pt+EvhyV+eGQcg Qz6A== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr9234812vdb.103.1341432672896; Wed, 04 Jul 2012 13:11:12 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Wed, 4 Jul 2012 13:11:12 -0700 (PDT) Date: Wed, 4 Jul 2012 22:11:12 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 20:11:11 -0000 Hi All, I want to propose draft-ietf work to be done on update the RFC2501, which I don't mind doing, on the following issues: 1- to include all active MANET routing RFCs as describing its network characteristics and its network context applicability, as mentioned by section-6. 2- to include the RFC5444 characteristics, or benefits to MANET performance. 3- to include NHDP RFC6130. 4- IPv6 considerations 5- Add more information in characteristic section on issue of reliability and scalability. RFC2501> 3. Characteristics of MANETs MANETs have several salient characteristics: AB>Add> 5) issue of variable E2E delay and node disconnecting from MANET. AB> suggest> to consider LLN 2501> 5. IP-Layer Mobile Routing AB> interfaces as physical layer technology, what about interfaces as logical? in some other parts we read wireless interface 2501> 5>Future interoperability may be achieved using mechanisms other than mobile IP. AB> Are we there, could we answer to add some? 2501>5>Supporting these features appears only to require identifying host and router interfaces with IP addresses, identifying a router with a separate Router ID, and permitting routers to have multiple wired and wireless interfaces. AB> replace "host and router" with " router" as it was done in DYMO and OLSRv2 2501> 4) Proactive operation: The flip-side of demand-based operation. AB> not clear 2501> Section 6.7, Duplex link and bidirectional link AB> why we use *duplex* with *link*, duplex is related to the interface system more than the link, so I recommend only using *bidirectional-link* and replace duplex-link. 2501> The following is a list of quantitative metrics that can be used to assess the performance of any routing protocol. AB> add examples of new metric used in industry or by active manet protocols 2501> 7. Security Considerations AB> Needs to be amended to consider new techniques The purpose of the proposed update, is first because RFC2501 is a reference to many new RFCs and that updates directs progress designs. Please note that I will not do this work until most active participant agree, thanking you, Best Regards Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/21/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > I didn't see what part of RFC 2501 needed to be revised. > Do you have a specific proposal? I think that, before you > could expect any discussion on revising that document, > you would have to point out what part or parts need > work. > > Regards, > Charlie P. > > On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>> Could we Update RFC2501? >> I see that RFC2501 some how defines MANET technologies, which will be >> a good reference in the draft I am writting of L2 subnets, but maybe >> RFC2501 is enough for the protocols, and no need for a new draft. >> However, that will depend on the WG discussion and decision :) >> >> I got no answer of the question so far, therefore, I will propose it >> to be discussed in the next meeting IETF 84. >> >> AB >> ===================================================== >> On 6/6/12, Abdussalam Baryun wrote: >>> Hi Folks, >>> >>> the RFC2501 is the best RFC I read and I like it because it is easy to >>> read, understandable, and covers solid issues of MANET. I hope the >>> authors give us a feedback if they want to make new one as Version 2. >>> >>> I see that it is old (1999), and it may be interesting to update it >>> some how, I hope the authors can update its issues and evaluation, now >>> we got new RFCs and industries have new needs than 90s, it does not >>> cover different devices constraints as sensors and LLNs, and IPv6, >>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>> getting renew versions. >>> >>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>> to update RFC2501 as well, it will only take few days or a month, to >>> draft and submit so why leave it old-documents with old >>> considerations? Please advise, >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>> ========================================================= >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From john.dowdell@cassidian.com Thu Jul 5 02:10: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 20E3121F8611 for ; Thu, 5 Jul 2012 02:10:45 -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 fOQLpQrabxxp for ; Thu, 5 Jul 2012 02:10:44 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id E047C21F85C2 for ; Thu, 5 Jul 2012 02:10:41 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 05 Jul 2012 11:10:52 +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, 5 Jul 2012 11:10:52 +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, 5 Jul 2012 11:10:52 +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, 5 Jul 2012 11:10:51 +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: Thu, 5 Jul 2012 10:10:50 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE0175D127@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Z0/PY8Vy+FVCeQc+ATtPq7D6OkQAt1Bsg References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> From: "John Dowdell" To: "Henning Rogge" , X-OriginalArrivalTime: 05 Jul 2012 09:10:51.0995 (UTC) FILETIME=[135732B0:01CD5A8E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19018.005 X-TM-AS-Result: No--31.450900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:10:45 -0000 OK can I modify my request below then to read as follows? If a DLEP client (radio) receives one or more IP addresses from its = immediately attached DLEP server (router) during the Peer Offer or Peer = Update message, it MUST pass that information across to the remote = client (by means of radio magic) and that information MUST be passed = from the remote client to the remote DLEP server during the Neighbour Up = and Neighbour Address Update messages. I cannot immediately think of a scenario where an IP address would not = be supplied from the server to the client, but I'm happy to allow for = that possibility. John=20 =20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: 04 July 2012 11:58 To: manet@ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? On 07/04/2012 11:03 AM, John Dowdell wrote: > Based on our experience with using DLEP, I would request that it = becomes > mandatory to supply either an IPv4 or IPv6 address of the far end = router > during a Neighbour Up/Down message as that would speed up the routing > process. Total contact time between routers in a MANET could be very > short, and anything that helps speed the establishment of the = connection > is welcome. I would say it should be mandatory if the knowledge is present on the=20 DLEP-capable device. If you do not know the IP addresses of each=20 partner, you can still use DLEP and leave this job to the router. > As to the 5444 debate, I do not see the need for 5444 compliance in > DLEP. If we can find a good fit for all the DLEP use cases with RFC5444, I see = no need to specify another packet format for it. DLEP transports=20 information (many of them optional) about the local radio/modem and=20 information (also many of them optional) about connection between=20 radios/modems. This seems to be a very good description of the concept=20 of RFC5444. It also needs multiple kinds of messages, which makes message=20 aggregation into a single block of information an useful feature. At last, it needs to interact with routing protocols (especially MANET=20 protocols), which makes reusing rfc5444 a good thing. > I agree with the 'it's not a routing protocol' stance, and in my > view it just adds unnecessary complexity, but I'm open to discussion=20 > on the extensibility issue. What do you think is the difference in implementing a custom DLEP=20 protocol language and a RFC5444 compliant one? In the second case, you=20 might be able to reuse code written for routing protocols, in the first=20 one you have to do it from scratch. 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 Thu Jul 5 02:14: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 419C921F8541 for ; Thu, 5 Jul 2012 02:14:26 -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 nFc2ZLJG0biZ for ; Thu, 5 Jul 2012 02:14:25 -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 182A921F853A for ; Thu, 5 Jul 2012 02:14:25 -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 1Smi8z-0006oX-HA; Thu, 05 Jul 2012 11:14: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 1Smi8z-0007pN-EV; Thu, 05 Jul 2012 11:14:37 +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, 5 Jul 2012 11:14:37 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Jul 2012 11:14:36 +0200 Message-ID: <4FF55AFB.7000200@fkie.fraunhofer.de> Date: Thu, 5 Jul 2012 11:14:35 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Dowdell References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <1B40484159234F4FB6FE11D4C2F408DE0175D127@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE0175D127@SUKNPT8108.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000902000900030701020303" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 05 Jul 2012 09:14:37.0272 (UTC) FILETIME=[999DBD80:01CD5A8E] X-Virus-Scanned: yes (ClamAV 0.97.3/15110/Thu Jul 5 03:29:32 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 7970b89edbb4ab82290785d35330ce4a Cc: manet@ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:14:26 -0000 --------------ms000902000900030701020303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/05/2012 11:10 AM, John Dowdell wrote: > OK can I modify my request below then to read as follows? > > If a DLEP client (radio) receives one or more IP addresses from its > immediately attached DLEP server (router) during the Peer Offer or > Peer Update message, it MUST pass that information across to the > remote client (by means of radio magic) and that information MUST be > passed from the remote client to the remote DLEP server during the > Neighbour Up and Neighbour Address Update messages. What is with radios that do NOT exchange IP addresses as part of their=20 "neighbor detection" (the radio magic is not present?) ? I don't think=20 it is a good idea to mandate DLEP to send data over the radio on its own.= If the radio supports this, I agree this is a MUST. But think about DLEP implementations for simpler devices (maybe as=20 simple as IEEE 802.11 embedded radios, connected to a central router=20 with ethernet). Henning Rogge > I cannot immediately think of a scenario where an IP address would > not be supplied from the server to the client, but I'm happy to allow > for that possibility. > > John > > > -----Original Message----- From: manet-bounces@ietf.org > [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 04 > July 2012 11:58 To: manet@ietf.org Subject: Re: [manet] Status of > DLEP-draft at Cisco? > > On 07/04/2012 11:03 AM, John Dowdell wrote: >> Based on our experience with using DLEP, I would request that it >> becomes mandatory to supply either an IPv4 or IPv6 address of the >> far end router during a Neighbour Up/Down message as that would >> speed up the routing process. Total contact time between routers in >> a MANET could be very short, and anything that helps speed the >> establishment of the connection is welcome. > > I would say it should be mandatory if the knowledge is present on > the DLEP-capable device. If you do not know the IP addresses of each > partner, you can still use DLEP and leave this job to the router. > >> As to the 5444 debate, I do not see the need for 5444 compliance >> in DLEP. > > If we can find a good fit for all the DLEP use cases with RFC5444, I > see no need to specify another packet format for it. DLEP transports > information (many of them optional) about the local radio/modem and > information (also many of them optional) about connection between > radios/modems. This seems to be a very good description of the > concept of RFC5444. > > It also needs multiple kinds of messages, which makes message > aggregation into a single block of information an useful feature. > > At last, it needs to interact with routing protocols (especially > MANET protocols), which makes reusing rfc5444 a good thing. > >> I agree with the 'it's not a routing protocol' stance, and in my >> view it just adds unnecessary complexity, but I'm open to >> discussion on the extensibility issue. > > What do you think is the difference in implementing a custom DLEP > protocol language and a RFC5444 compliant one? In the second case, > you might be able to reuse code written for routing protocols, in the > first one you have to do it from scratch. > > 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 --------------ms000902000900030701020303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA3MDUwOTE0MzVaMCMGCSqGSIb3DQEJBDEWBBS7KhBG8y4ySQwgryevFHQXzYttCDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEADxBM6Su7e3pCDfQi+yjfOkQHz8x/ptp2lPCva4958Sg7 9hwPulW5OtLxs2EEG+sDn2QZCYexP2SG8Ud2IFJoNsUMoXRaBs2kUluck6PL2UYPB6cNZw6M EEWD/Z9Vx0Ln3P2E2CfWUTQCZWnVz0J+O6k8T8Lona9zHmuEuSKB6QamntdVRYdqypJ0rMUn EA6wrq8qvsDny/RmysDb74gSpUTbZUegQgdnKpd7X6GyxD2yjRR1SJlhVs74/X5gp2H29I0k hsOzBVbnSwA6tttDGreh3bjfWqO9otfVTNuH+MzC13Y6//GcDOUOavCSnyoOA3+YMQXBPqF1 Gl2ZGG/Q8AAAAAAAAA== --------------ms000902000900030701020303-- From abdussalambaryun@gmail.com Thu Jul 5 04:17: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 6E99621F861E for ; Thu, 5 Jul 2012 04:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 iGuevCJCs7Yr for ; Thu, 5 Jul 2012 04:17:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0821F861B for ; Thu, 5 Jul 2012 04:17:15 -0700 (PDT) Received: by vcqp1 with SMTP id p1so5890941vcq.31 for ; Thu, 05 Jul 2012 04:17:28 -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=huc/OD2ycUtFlEho7VIQkdF3OQ1wHQIvA/d/jvAOmf4=; b=gRf6/jktalH702W3e6JomIFqFJUpYqLutrcRL0IJ3TismMuKkPa9ij6ISiVC7bsINC pLxkUE7qitAXYKcWpiC1i/BMjps/lt2rHpy3hmbKQwMb0esJgz6glgkFGyP5beQqwtJ/ 8yzAO3U6Ir/tgEmf0x+M4YrsVeTvM2QbVdrXXHVHB0rMjl+95IrpeOXvIqBRG66ypf/h OEaj4WxMcu1///JQLP34jzAYMoybs02djjvhDd4QYJBsCJDncS2uocZaWpmTiYUJ8dh1 4tQSpm5BCfGFQxAei5aod6APAeV5ZDHl+xfYwdO+yLWmN41V1FTVf4Aimwn9qOHXMEol LmuA== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr3652505vcw.43.1341487048136; Thu, 05 Jul 2012 04:17:28 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 04:17:27 -0700 (PDT) Date: Thu, 5 Jul 2012 13:17:27 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge , John Dowdell Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] Is the Protocol for Simple or Complex Devices? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:17:16 -0000 Hi John and Henning, The subject question was asked for protocols like OLSRv2 and AODVv2 and they do consider both type devices, but DLEP-02 is mostly for one type, I don't prefer using MAC nor IP addresses if using RFC5444 messaging as the presented/latest DLEP-02. I prefer using 5444 addresses specified only for the DLEP protocol. However, I don't mind to allow MAC or IP addresses if it has advantages for the neighbors. I understood by the draft-02 that it does use the radio to remote info with neighbors without router protocol, which this is the main point of its mechanism. DLEP uses radio layer 2 (L2) to detect links and communicate with neighbors at L2, then reports to L3. Simpler devices/technologies does not need DLEP services. IMHO, the DLEP is for complex devices (haveay weight technologies). Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 07/05/2012 11:10 AM, John Dowdell wrote: OK can I modify my request below then to read as follows? If a DLEP client (radio) receives one or more IP addresses from its immediately attached DLEP server (router) during the Peer Offer or Peer Update message, it MUST pass that information across to the remote client (by means of radio magic) and that information MUST be passed from the remote client to the remote DLEP server during the Neighbour Up and Neighbour Address Update messages. What is with radios that do NOT exchange IP addresses as part of their "neighbor detection" (the radio magic is not present?) ? I don't think it is a good idea to mandate DLEP to send data over the radio on its own. If the radio supports this, I agree this is a MUST. But think about DLEP implementations for simpler devices (maybe as simple as IEEE 802.11 embedded radios, connected to a central router with ethernet). Henning Rogge I cannot immediately think of a scenario where an IP address would not be supplied from the server to the client, but I'm happy to allow for that possibility. John -----Original Message----- From: manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On Behalf Of Henning Rogge Sent: 04 July 2012 11:58 To: manet at ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? On 07/04/2012 11:03 AM, John Dowdell wrote: Based on our experience with using DLEP, I would request that it becomes mandatory to supply either an IPv4 or IPv6 address of the far end router during a Neighbour Up/Down message as that would speed up the routing process. Total contact time between routers in a MANET could be very short, and anything that helps speed the establishment of the connection is welcome. I would say it should be mandatory if the knowledge is present on the DLEP-capable device. If you do not know the IP addresses of each partner, you can still use DLEP and leave this job to the router. As to the 5444 debate, I do not see the need for 5444 compliance in DLEP. If we can find a good fit for all the DLEP use cases with RFC5444, I see no need to specify another packet format for it. DLEP transports information (many of them optional) about the local radio/modem and information (also many of them optional) about connection between radios/modems. This seems to be a very good description of the concept of RFC5444. It also needs multiple kinds of messages, which makes message aggregation into a single block of information an useful feature. At last, it needs to interact with routing protocols (especially MANET protocols), which makes reusing rfc5444 a good thing. I agree with the 'it's not a routing protocol' stance, and in my view it just adds unnecessary complexity, but I'm open to discussion on the extensibility issue. What do you think is the difference in implementing a custom DLEP protocol language and a RFC5444 compliant one? In the second case, you might be able to reuse code written for routing protocols, in the first one you have to do it from scratch. Henning Rogge From henning.rogge@fkie.fraunhofer.de Thu Jul 5 04:23: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 B8D4221F852B for ; Thu, 5 Jul 2012 04:23:40 -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 tpGnKvgBhMG9 for ; Thu, 5 Jul 2012 04:23: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 91E0221F85A0 for ; Thu, 5 Jul 2012 04:23: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 1SmkA1-0000ZE-MY for manet@ietf.org; Thu, 05 Jul 2012 13:23:49 +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 1SmkA1-0003RF-Jz for manet@ietf.org; Thu, 05 Jul 2012 13:23:49 +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, 5 Jul 2012 13:23:49 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 5 Jul 2012 13:23:49 +0200 Message-ID: <4FF5793B.3010809@fkie.fraunhofer.de> Date: Thu, 5 Jul 2012 13:23:39 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020207050105010007050806" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 05 Jul 2012 11:23:49.0415 (UTC) FILETIME=[A640E370:01CD5AA0] X-Virus-Scanned: yes (ClamAV 0.97.3/15110/Thu Jul 5 03:29:32 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Subject: Re: [manet] Is the Protocol for Simple or Complex Devices? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:23:40 -0000 --------------ms020207050105010007050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/05/2012 01:17 PM, Abdussalam Baryun wrote: > Hi John and Henning, > > The subject question was asked for protocols like OLSRv2 and AODVv2 > and they do consider both type devices, but DLEP-02 is mostly for one > type, > > I don't prefer using MAC nor IP addresses if using RFC5444 messaging > as the presented/latest DLEP-02. I prefer using 5444 addresses > specified only for the DLEP protocol. However, I don't mind to allow > MAC or IP addresses if it has advantages for the neighbors. > > I understood by the draft-02 that it does use the radio to remote info > with neighbors without router protocol, which this is the main point > of its mechanism. DLEP uses radio layer 2 (L2) to detect links and > communicate with neighbors at L2, then reports to L3. > > Simpler devices/technologies does not need DLEP services. IMHO, the > DLEP is for complex devices (haveay weight technologies). The concept of DLEP works well both for heavy weight "Software Defined=20 Radios" and for lightweight devices as embedded IEEE 802.11 routers. The lightweight use case allows to easily build multi-radio IEEE 802.11=20 installations made from a number of weather-proof single-radio routers,=20 connected to a central router via ethernet. This is exactly the same usage scenario as the heavy-weight one, just=20 with other hardware. Do we really want to restrict DLEP to a certain type of device? Do we=20 want a "DLEP-for heavy weight devices" and another RFC with "DLEP for=20 light devices" ? 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 --------------ms020207050105010007050806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA3MDUxMTIzNDZaMCMGCSqGSIb3DQEJBDEWBBQRtJ8zantvSuuGr3vXRs4rGqSBETBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAQCkqlN+uWPpiaGNfHaJLb/Eoks6wjiabovzv/e/lfUOL dKbZ0ZHv0Rzlohj/22MDy7dEnaN3fIDLIEacIvqhi/Pv8vniAPk1mdoD0ZvSzXYAV9Sv1Sln lDTCVso9mXp3AoprRk+zhkcWitU16aWUvaNguMyHXXh6wZa1pk3ELDFe00Ww++1sZcLwWBYr SIt3ybEdRgbNaCGCP85Nixnc41T+t7RFWabzHh/r0/zuUVS7v9CbOA9TYxOyAYHh2PIiHfbO au12NJGrXpUmbFNQcpKIV/rTHIoP/yADSW78nzvg5wXuJkIWjRBKrI5FPvyNlcefdrJrvY5E CF6q+MeYdAAAAAAAAA== --------------ms020207050105010007050806-- From teco@inf-net.nl Thu Jul 5 05:00: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 427BA21F85A1 for ; Thu, 5 Jul 2012 05:00:15 -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 M2s5jqA+9nlY for ; Thu, 5 Jul 2012 05:00:12 -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 BDE8621F8638 for ; Thu, 5 Jul 2012 05:00:03 -0700 (PDT) Received: by eekd4 with SMTP id d4so3476493eek.31 for ; Thu, 05 Jul 2012 05:00:16 -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=INCN+CJ5bNSUV/MAaysZoksmvW08tqufXsokhBbr/w8=; b=Dc6n/j1oGaW5mRCdbNYufGATsHeewYzzzYwqQdnKGlba6zaYTVEAeTgNf8kp2hogqD SVuDMpztvVpSiHoS8n6mOSForVGFDjkpQL+9ZhvYtXsMLPJIKB1P2O/TlvBhieWsM202 tEknl0/r51eu6F6Rmi1+kC1DjkO4bK1zeEKiHfRkHqBP1GNQrCL7Aiv7c/0CbrCJLW9/ zn8VI/aICM7KSrfBPpjvLMatA3D9cmreDhzpm7oJz/Ky7nmcAW9ybdn7SG2rEVjxPU7E PHtB1pwWscpVtiWchh0e+UaEsJPU0gftL6SkiMaief3jrnm8gsVvEjU2utrrH0aCsc14 dmoA== Received: by 10.14.47.72 with SMTP id s48mr6333737eeb.130.1341489616296; Thu, 05 Jul 2012 05:00:16 -0700 (PDT) Received: from [172.16.4.192] ([188.205.88.52]) by mx.google.com with ESMTPS id e48sm62236466eea.12.2012.07.05.05.00.15 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 05:00:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE0175D127@SUKNPT8108.cogent-dsn.local> Date: Thu, 5 Jul 2012 14:00:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <427A82DC-E58E-4C11-933F-E4B4C48E7FE0@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <1B40484159234F4FB6FE11D4C2F408DE0175D127@SUKNPT8108.cogent-dsn.local> To: John Dowdell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmTK7wFYVkmS34T6hyYcdrJAdX6O4GVIz8mxzG9Vq9HYSoPcIla99hBYOqJhDFMnfrclHUm Cc: manet@ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:00:15 -0000 Op 5 jul. 2012, om 11:10 heeft John Dowdell het volgende geschreven: > OK can I modify my request below then to read as follows? >=20 > If a DLEP client (radio) receives one or more IP addresses from its = immediately attached DLEP server (router) during the Peer Offer or Peer = Update message, it MUST pass that information across to the remote = client (by means of radio magic) Having a standard would be great for interoperability. That is what we = try to achieve, isn't it? > and that information MUST be passed from the remote client to the = remote DLEP server during the Neighbour Up and Neighbour Address Update = messages. What if remote node doesn't use DLEP at all? And this information = exchange is optional, isn't it? Teco > I cannot immediately think of a scenario where an IP address would not = be supplied from the server to the client, but I'm happy to allow for = that possibility. >=20 > John=20 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge > Sent: 04 July 2012 11:58 > To: manet@ietf.org > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=20 > On 07/04/2012 11:03 AM, John Dowdell wrote: >> Based on our experience with using DLEP, I would request that it = becomes >> mandatory to supply either an IPv4 or IPv6 address of the far end = router >> during a Neighbour Up/Down message as that would speed up the routing >> process. Total contact time between routers in a MANET could be very >> short, and anything that helps speed the establishment of the = connection >> is welcome. >=20 > I would say it should be mandatory if the knowledge is present on the=20= > DLEP-capable device. If you do not know the IP addresses of each=20 > partner, you can still use DLEP and leave this job to the router. >=20 >> As to the 5444 debate, I do not see the need for 5444 compliance in >> DLEP. >=20 > If we can find a good fit for all the DLEP use cases with RFC5444, I = see=20 > no need to specify another packet format for it. DLEP transports=20 > information (many of them optional) about the local radio/modem and=20 > information (also many of them optional) about connection between=20 > radios/modems. This seems to be a very good description of the concept=20= > of RFC5444. >=20 > It also needs multiple kinds of messages, which makes message=20 > aggregation into a single block of information an useful feature. >=20 > At last, it needs to interact with routing protocols (especially MANET=20= > protocols), which makes reusing rfc5444 a good thing. >=20 >> I agree with the 'it's not a routing protocol' stance, and in my >> view it just adds unnecessary complexity, but I'm open to discussion=20= >> on the extensibility issue. >=20 > What do you think is the difference in implementing a custom DLEP=20 > protocol language and a RFC5444 compliant one? In the second case, you=20= > might be able to reuse code written for routing protocols, in the = first=20 > one you have to do it from scratch. >=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Thu Jul 5 05:20: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 BD77921F8638 for ; Thu, 5 Jul 2012 05:20:37 -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 rWNAGihXV+2S for ; Thu, 5 Jul 2012 05:20:33 -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 889F521F857D for ; Thu, 5 Jul 2012 05:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3060; q=dns/txt; s=iport; t=1341490846; x=1342700446; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=L3mXAM3VBjtdimTu0Ig4GMVz2XDkfP3XATip6566qYA=; b=OyQwac53J1iNkPYj75RsGawRz28CCdc/roolMzCE+qMHrN+CiMc7/RWY lGEttkZAOgy6rSglRLEqCGFfcRijeYINldaQRuYK9s+Gp/nDJ/VGl+XGL HOWvbbWbE/84TUTdqwSUtgDcmeKFSGfdZZ0blxl7ioi1VRCWkA2yQ+TXd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJSF9U+tJXG8/2dsb2JhbABFtyWBB4IYAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMbB4dkBQuaBZ9sizkUhUpgA5U3hVaIR4FmgnuBOgk X-IronPort-AV: E=Sophos;i="4.77,530,1336348800"; d="scan'208";a="95994437" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jul 2012 12:20:45 +0000 Received: from [192.168.1.213] (ggsg-vpn2-230-75.cisco.com [10.81.230.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65CKjmB001113; Thu, 5 Jul 2012 12:20:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Bo Berry In-Reply-To: <4FF5793B.3010809@fkie.fraunhofer.de> Date: Thu, 5 Jul 2012 08:20:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDF7DBE-731F-4CFA-A624-075641F2AF55@cisco.com> References: <4FF5793B.3010809@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] Is the Protocol for Simple or Complex Devices? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:20:38 -0000 Henning, All Few responses to the thread below -Bo On Jul 5, 2012, at 7:23 AM, Henning Rogge wrote: > On 07/05/2012 01:17 PM, Abdussalam Baryun wrote: >> Hi John and Henning, >>=20 >> The subject question was asked for protocols like OLSRv2 and AODVv2 >> and they do consider both type devices, but DLEP-02 is mostly for one >> type, >>=20 >> I don't prefer using MAC nor IP addresses if using RFC5444 messaging >> as the presented/latest DLEP-02. I prefer using 5444 addresses >> specified only for the DLEP protocol. However, I don't mind to allow >> MAC or IP addresses if it has advantages for the neighbors. >>=20 >> I understood by the draft-02 that it does use the radio to remote = info >> with neighbors without router protocol, which this is the main point >> of its mechanism. DLEP uses radio layer 2 (L2) to detect links and >> communicate with neighbors at L2, then reports to L3. >>=20 >> Simpler devices/technologies does not need DLEP services. IMHO, the >> DLEP is for complex devices (haveay weight technologies). >=20 > The concept of DLEP works well both for heavy weight "Software Defined = Radios" and for lightweight devices as embedded IEEE 802.11 routers. Yes, we have DLEP experiences with light and heavy weight radios (what = defines a light weight vrs a heavy weight radio?). We purposely = abstract the radio technology to avoid niche solutions. =20 DLEP should not be limited to a radio type as radio capabilities are = quickly changing. >=20 > The lightweight use case allows to easily build multi-radio IEEE = 802.11 installations made from a number of weather-proof single-radio = routers, connected to a central router via ethernet. > This is exactly the same usage scenario as the heavy-weight one, just = with other hardware. >=20 > Do we really want to restrict DLEP to a certain type of device? No, +1 > Do we want a "DLEP-for heavy weight devices" and another RFC with = "DLEP for light devices" ? No, +1 >=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 >=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 sratliff@cisco.com Thu Jul 5 07:06: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 2733321F8602 for ; Thu, 5 Jul 2012 07:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.385 X-Spam-Level: X-Spam-Status: No, score=-10.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 JpgwL2VUPjTZ for ; Thu, 5 Jul 2012 07:06:51 -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 2E20721F84C9 for ; Thu, 5 Jul 2012 07:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3045; q=dns/txt; s=iport; t=1341497225; x=1342706825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=G3HQ6OPJYqSClsgt7c9LetSo0wGHatoaU3Gz0DS8Jt4=; b=Wmmsbp51mZcMbt6qVLg8H0YTQkXaWxbvx5TgdOsXSugHx4E0KZsF7Mct NTZWxANbiWYQdZ0SQ2O987JUZQM5GuTQyitNa5gXO6+3La6nzSmWaK9vo yfEYVxYeK/gJaFJox5KVBtu85WGLxFY8GwYlmPqDNeVHJUwG9NqzrY4V2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALme9U+tJXG8/2dsb2JhbABFtyaBB4IYAQEBAwEBAQEPAVsDCAULAgEIGCcHJwsUEQEBBA4FIodkBQuZdp9wizmFXmADiBeNII4dgWaCXw X-IronPort-AV: E=Sophos;i="4.77,530,1336348800"; d="scan'208";a="99013304" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jul 2012 14:07:04 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65E74f4015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 14:07:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 09:07:04 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fTpCAFddlbEyMT95YMXvXBAAH9JaAAA7tmYAAOOkqgA== Date: Thu, 5 Jul 2012 14:07:03 +0000 Message-ID: <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> In-Reply-To: <4FF4219B.3080606@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--59.698800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:06:52 -0000 On Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: > On 07/04/2012 11:03 AM, John Dowdell wrote: >> Based on our experience with using DLEP, I would request that it becomes >> mandatory to supply either an IPv4 or IPv6 address of the far end router >> during a Neighbour Up/Down message as that would speed up the routing >> process. Total contact time between routers in a MANET could be very >> short, and anything that helps speed the establishment of the connection >> is welcome. >=20 > I would say it should be mandatory if the knowledge is present on the DLE= P-capable device. If you do not know the IP addresses of each partner, you = can still use DLEP and leave this job to the router. >=20 >> As to the 5444 debate, I do not see the need for 5444 compliance in >> DLEP. >=20 > If we can find a good fit for all the DLEP use cases with RFC5444, I see = no need to specify another packet format for it. DLEP transports informatio= n (many of them optional) about the local radio/modem and information (also= many of them optional) about connection between radios/modems. This seems = to be a very good description of the concept of RFC5444. >=20 > It also needs multiple kinds of messages, which makes message aggregation= into a single block of information an useful feature. >=20 > At last, it needs to interact with routing protocols (especially MANET pr= otocols), which makes reusing rfc5444 a good thing. That's a red herring, IMO. The fact that DLEP should interact with routing = protocols does *not* mean that 5444 use is, in and of itself, "a good thing= ". For example, the current DLEP offering I work on interacts with OSPFv3. = RFC 5444 compliance is actually a burden in that environment. Or, at a bare= minimum, it becomes "DLEP-specific". I believe DLEP has applicability outs= ide the MANET space, and as has been said before, it isn't a routing protoc= ol. So, I don't see a requirement to "make it fit" with 5444.=20 Regards, Stan >=20 > > I agree with the 'it's not a routing protocol' stance, and in my > > view it just adds unnecessary complexity, but I'm open to discussion > = on the extensibility issue. >=20 > What do you think is the difference in implementing a custom DLEP protoco= l language and a RFC5444 compliant one? In the second case, you might be ab= le to reuse code written for routing protocols, in the first one you have t= o do it from scratch. >=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Jul 5 07:11: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 651F921F8656 for ; Thu, 5 Jul 2012 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 t96sU6yeTo6v for ; Thu, 5 Jul 2012 07:11:17 -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 6142521F864B for ; Thu, 5 Jul 2012 07:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2397; q=dns/txt; s=iport; t=1341497491; x=1342707091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=piMXaPR4xTn6B6X30Z7yKRHHaQxDwiVmtuKeQN3ONXs=; b=NjOIB4OE0Sz5iHvTw6JAAOVrN1yn90Ol2j/u8mOD9FWP7tyYYrByQ99r O3lzIxOCQQ1bLg1cztGg6KUjZrOXhFaDCDq/TGisxB9KC3dE5iwXHv6/I NZrEQrsWMEM3I180dw0dgkqPbPJVBL997Q7cjNBtk1m/4NNBwxTRpzSyd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN6f9U+tJV2Y/2dsb2JhbABFtyaBB4IYAQEBAwESAWYQAgEIRjIlAQEEDieHZAWaAJ9wizmFXmADlTeOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,530,1336348800"; d="scan'208";a="99015101" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jul 2012 14:11:30 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65EBUQ5021539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 14:11:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 09:11:20 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fTpCAFddlbEyMT95YMXvXBAAH9JaAAA+x/4AAOExngA== Date: Thu, 5 Jul 2012 14:11:29 +0000 Message-ID: <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--37.471200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <3FB9B5E4FBECE54CBC3719F994D88345@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:11:18 -0000 On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: >=20 > Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: >=20 >> Based on our experience with using DLEP, I would request that it becomes >> mandatory to supply either an IPv4 or IPv6 address of the far end router >> during a Neighbour Up/Down message as that would speed up the routing >> process. > I like fast convergence. The question is how to do it. >=20 > Neighbor up/down would fire triggers in the L3 hello mechanism. Up would= =20 > start send out new hello's. Down would update the link state, and optiona= lly > send out new hello's. >=20 > The IP addresses, related to neighbor up, could be used for unicast hello= 's > or updates in neighbor tables directly. So it may help. But do we set adj= acency=20 > to what DLEP provides? Or mandate verification with L3 hello's? >=20 > Often, all info for neighbor cache is already available in the hello pack= et.=20 > There is running code that actually use it. Another approach is trigger L= 2=20 > address resolving for all next-hop IP addresses. IMHO good quality router= s=20 > do that / should do that, also in a non-MANET environment. >=20 >> Total contact time between routers in a MANET could be very >> short, and anything that helps speed the establishment of the connection >> is welcome. > Yes, with limits on "anything". Is header snooping acceptable? >=20 > My main concern is, there are already enough methods that can do the job. The problem with header snooping is that it has to be done *in the radio*. = With the DLEP mechanism, passing Layer 3 devices is as straightforward as:= =20 1. A router and it's *locally attached* radio establish DLEP session. The r= outer hands the radio it's addresses via "Peer Offer".=20 2. The radio does NOT need to know what these addresses are. Radio can trea= t the information as opaque TLV's. Radio stores that information.=20 3. When the radio detects a new potential neighbor (e.g., another radio), i= t can exchange the opaque TLV's as part of the radio handshake.=20 4. Each radio now builds a "Neighbor Up" back to the routers involved, appe= nding the opaque TLV's received from the other radio.=20 And presto, you have exchanged Layer 3 addresses, irrespective of subnet ma= sks, ARP quirkiness, etc=85 Regards, Stan >=20 > Teco >=20 >=20 From abdussalambaryun@gmail.com Thu Jul 5 07:12: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 BFB5721F864D for ; Thu, 5 Jul 2012 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 mxNQ4Oy6V7fY for ; Thu, 5 Jul 2012 07:12:17 -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 047FE21F864B for ; Thu, 5 Jul 2012 07:12:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6011424vbb.31 for ; Thu, 05 Jul 2012 07:12:30 -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=wk5IJVR4Hi3XNuA53K3BxuX6OA4zaiWka+aMMAfD3z8=; b=w5VV/4kCeO4nExVhOJGJVdDPPdNzCPshiOvfDXT/eai00Ks8ooivaCV2tHL6oUPMfy kKMnPdBnzj/qhwsUXyeK84SxU6Z2K3Srr8UyceFOXkEUo4BNQdz+GER2GFyCzqOIfdVA WfnYzXehY/Rg9ILTjHZuVMHvXinfD9nUQhfqh0hJ9P53/ufJQ6VKB6QymqbyaVRjzmks +OV8yi09gyMKGRCSItUl2SBg6zlblPVEgW04Tui58ltfmE+1rF81CGMs0HzaXVLXExIF Q6hfM/FzHvrfcSDNRV1P3OeRRnFbhgO+DPkXVYagxnB2ZQc9hd/H/Rm42jRNIcv5nj+E EYpg== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr3956741vcw.43.1341497550375; Thu, 05 Jul 2012 07:12:30 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 07:12:29 -0700 (PDT) Date: Thu, 5 Jul 2012 16:12:29 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:12:17 -0000 Hi All, I think it is useful to have in each WG a defined terminology I-D/RFC , so that there discussions be more focused and easy for readers in the Internet community to understand. IMO, most RFC MANET readers are not experts in the field, but still are interested to know about the field because they are the main users/customers of the MANET technologies. It is understood by many participants in IETF WGs that no WG is expert in all fields of others but still the interaction between WGs is important to future IETF documents. Getting each WG to produce a terminology document will help/ease non-experts in other WGs to understand issues/discussions/RFCs related to terme-defined-WG. For example it was admited in one meeting of MANET that security consideration for a protocol was needed and may advise the security WG. >From now I will use the terms in [MAN] and [ROLL] in my transmitted-messages (including my I-Ds), so that non-experts (may includ me) of the community does not misunderstand the thread, and the referencing will help to encode terms used in the message (may even reduce discussion/transmitted-messages contents). Best regards Abdussalam Baryun, [MAN] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt [ROLL] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt From hrogge@googlemail.com Thu Jul 5 07:48: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 761DF21F85A0 for ; Thu, 5 Jul 2012 07:48:26 -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 e9dINLcqazaR for ; Thu, 5 Jul 2012 07:48: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 6D77321F8598 for ; Thu, 5 Jul 2012 07:48:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13244705pbc.31 for ; Thu, 05 Jul 2012 07: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:content-transfer-encoding; bh=dntOt8aOXQ7FVPMlaNHcGulIRnyH8zt7BUxW+wottHA=; b=hzlIyqlZNig0mdLgzRKn6QSXu3G00vGglamMFjhIEtjtQfINsrAlaXh13sscMSJFtj mmpWEP0ZHtK7TQ+qVeqyoZMwlpG5BoXDEQScUBRr9FmMWYEeHqCF/ebqNJFaoQEFtdUv 2839AjqcqYRzrpapcTV8qOAYJVmAG76pdzvJyhZW3yU0a2bI1YPi02lXZbKaqW59C23w XGdwqf52oECm39Z4h0ouEuoDr5HmCzK5ougc2Zf1ZMKrcwX6CdD7oo5ysZjKVAaKGKAI 7nrUak5qG6vvBhT0jc9AEEW8gGWAwNcMNuogyzADjiEUz+3TcyMj/mrCkx0qIpUFJKOj T8HA== Received: by 10.68.225.42 with SMTP id rh10mr29019020pbc.116.1341499719110; Thu, 05 Jul 2012 07:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 07:48:18 -0700 (PDT) In-Reply-To: <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> From: Henning Rogge Date: Thu, 5 Jul 2012 16:48:18 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:48:26 -0000 If a radio has this mechanism, its a good idea to use it. The nice thing is that even if the radio does NOT have this feature, the network will still work. The Router will send the Radio IP-Addresses, which the radio will throw away because it cannot transport them over the air. This means the routers will not get IP-addresses as part of the information about the neighbors through DLEP... which means that they will not pre-fill the ARP-Table. and will just trigger the normal ARP mechanism. Of course it will be as slow as the normal ARP, which means that companies might integrate it in more radios. Which means the "IP over radio-layer2 handshake" has a good fallback for the case that the router DOES support "IP addresses over DLEP" but the radio does not. Henning Rogge On Thu, Jul 5, 2012 at 4:11 PM, Stan Ratliff (sratliff) wrote: > > On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: > >> >> Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: >> >>> Based on our experience with using DLEP, I would request that it become= s >>> mandatory to supply either an IPv4 or IPv6 address of the far end route= r >>> during a Neighbour Up/Down message as that would speed up the routing >>> process. >> I like fast convergence. The question is how to do it. >> >> Neighbor up/down would fire triggers in the L3 hello mechanism. Up would >> start send out new hello's. Down would update the link state, and option= ally >> send out new hello's. >> >> The IP addresses, related to neighbor up, could be used for unicast hell= o's >> or updates in neighbor tables directly. So it may help. But do we set ad= jacency >> to what DLEP provides? Or mandate verification with L3 hello's? >> >> Often, all info for neighbor cache is already available in the hello pac= ket. >> There is running code that actually use it. Another approach is trigger = L2 >> address resolving for all next-hop IP addresses. IMHO good quality route= rs >> do that / should do that, also in a non-MANET environment. >> >>> Total contact time between routers in a MANET could be very >>> short, and anything that helps speed the establishment of the connectio= n >>> is welcome. >> Yes, with limits on "anything". Is header snooping acceptable? >> >> My main concern is, there are already enough methods that can do the job= . > > The problem with header snooping is that it has to be done *in the radio*= . With the DLEP mechanism, passing Layer 3 devices is as straightforward as= : > > 1. A router and it's *locally attached* radio establish DLEP session. The= router hands the radio it's addresses via "Peer Offer". > 2. The radio does NOT need to know what these addresses are. Radio can tr= eat the information as opaque TLV's. Radio stores that information. > 3. When the radio detects a new potential neighbor (e.g., another radio),= it can exchange the opaque TLV's as part of the radio handshake. > 4. Each radio now builds a "Neighbor Up" back to the routers involved, ap= pending the opaque TLV's received from the other radio. > > And presto, you have exchanged Layer 3 addresses, irrespective of subnet = masks, ARP quirkiness, etc=85 > > Regards, > Stan > > > >> >> Teco >> >> > > _______________________________________________ > 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 Jul 5 07:53: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 B5BF721F8674 for ; Thu, 5 Jul 2012 07:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 8IDzs-3gWoeV for ; Thu, 5 Jul 2012 07:53:28 -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 1812C21F85DB for ; Thu, 5 Jul 2012 07:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2980; q=dns/txt; s=iport; t=1341500022; x=1342709622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XRqxL7kZPoKAhP1HhJDkkW2CM7m4yW8wGuhr4wMha6I=; b=LnbYQJncgql5KSspmoySDEEaoBQlLITC0mcJpy2xiTC/7htALXgVVfz6 tiZSp0+LqjQJ73Zk+hWrD6iiG5rI/NLuj3FA48jMnu39YcKqWfqGUuvvg OiUY1lTouxI+VDx7qU5sipNxd+ssLmh9SG7tBhAQqOfbym0HZtLLVsVaW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+p9U+tJV2Y/2dsb2JhbABFtyaBB4IYAQEBAwEBAQEPASc0CxACAQgYHhAnCyUCBAoEBSKHZAULmVyfawSLOYVeYAOVN44dgWaCXw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99065268" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2012 14:53:41 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65Erfea017047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 14:53:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 09:53:40 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAIAACZ8AgAAGDgCAAMVZAIACLG6A Date: Thu, 5 Jul 2012 14:53:39 +0000 Message-ID: <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--44.974200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:53:30 -0000 On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >=20 > Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >>=20 >> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>=20 >>> Most of the workinggroup seems to have the opinion that DLEP should >>> move to full RFC5444 compliance, because it will fit the purpose of >>> DLEP fine and spare the IETF "just another proprietary data format". >>> With RFC5444 we can easily get to a point where we get a protocol that >>> can be extended for more metrics without the need of a version field, >>> which will simplify future DLEP revisions. >>=20 >> And again, we disagree on that point.=20 >=20 > Stan, you could set up a poll to find out the working group opinion. >=20 > In the discussion on full RFC 5444 compliance, or just use it as a=20 > transport container, my non-important opinion: > - dlep-02 implements reliable transport, with tiny chunks of to_be_acked= =20 > data and the ack messages=20 > - this reliable transport requires (complex) state machines, but provides= =20 > reduced data volume over the wire > - when transferred data is highly variable, this reliable transport=20 > doesn't make sense. A timer based refresh, with triggered fast updates,= =20 > would better fit the required functionality Relying on "yet another independent timer" isn't the way to go, IMO. That w= ill only extend time to converge the network. It also doesn't cover the cas= e where some of this data might get dropped. Yes, DLEP flows are typically = on a high-speed wired link, and the theoretical drop rate would be small. H= owever, Murphy's Law says traffic *will* get dropped, and the traffic that = gets dropped will be that which is most important to you. There is also the= use case where the wireless link itself is used for DLEP traffic - what we= 've currently called the "Detached Discovery" mode.=20 Regards, Stan > - RFC 5444 provides a mechanism to compress larger arrays of data. This=20 > could be used for MAC address TLV's, for transfer of ever changing link= =20 > metrics > - for reliable transfer, one option would be using another protocol,=20 > already standardized. It is called TCP, if I remember well. For > discovery, TCP doesn't work well...=20 > - because dlep acts on local, often high speed links, reduction of volume > of transferred data has low priority. > I guess we have to choose how to implement the link metrics exchange. > If we opt for reliable transfer, I prefer TCP. For a straightforward > stateless transfer, RFC 5444 MAC address TLV's looks an obvious choice. > Opinions on address TLVs would be influenced on having the parser already= ,=20 > or facing something on the todo list. Dito the validity timer stuff. >=20 > Teco >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Jul 5 07:53: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 82A4421F86C3 for ; Thu, 5 Jul 2012 07:53: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 HeNlWTqknrRa for ; Thu, 5 Jul 2012 07:53:42 -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 2EB9A21F86B6 for ; Thu, 5 Jul 2012 07:53:41 -0700 (PDT) Received: by bkty7 with SMTP id y7so515597bkt.31 for ; Thu, 05 Jul 2012 07:53:54 -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=YSyTh0AlnDzV4yNHhSG9lTufcPLpAgSCAcFN+Ek6C+E=; b=WcMqksqtX2keaeme07ag4nWZiDERg6RhlAqf3nRwyWsOPHJbW9WMAo7rBf7R/Fz28U UW0TKe002DmrMEjn+HVEwNHMB+ldxjxLVT1H3PAfKA64/E9aOaqQcN3M3myK/gKR13Lb 7A+gVvxbsZwbqpBSOd3SmzMhT6eIcLc0j71gE64Ql3lU5Q36p8+sqGeG+V3ThuhZWpEb 6agGMbXFx8JcKQNw7GNAKrkVmNB8HJ6MCKKr/nUrNc4GFst28HpcwIZHP1sdWzzNo/A8 L+egmqu0I/X6oNNBazqalO1d/8w9XE6knulalJb+SxhXL+D2dnWn2Hy49NB/XMg2Quvf OKng== Received: by 10.205.120.18 with SMTP id fw18mr14201697bkc.64.1341500034450; Thu, 05 Jul 2012 07:53:54 -0700 (PDT) Received: from [10.87.17.104] ([80.187.201.33]) by mx.google.com with ESMTPS id 25sm499896bkx.9.2012.07.05.07.53.36 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 07:53:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> Date: Thu, 5 Jul 2012 16:53:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3631555C-6977-448E-967F-A860B69F2B36@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmX2e+xPWpScGlPiolfIXM6g15UE6eu2UmYJXRwhrxaCIkhGr5U3DC5Bhsxa0dSuzC9+/2Q Cc: "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:53:43 -0000 Op 5 jul. 2012, om 16:11 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: >=20 >>=20 >> Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: >>=20 >>> Based on our experience with using DLEP, I would request that it = becomes >>> mandatory to supply either an IPv4 or IPv6 address of the far end = router >>> during a Neighbour Up/Down message as that would speed up the = routing >>> process. >> I like fast convergence. The question is how to do it. >>=20 >> Neighbor up/down would fire triggers in the L3 hello mechanism. Up = would=20 >> start send out new hello's. Down would update the link state, and = optionally >> send out new hello's. >>=20 >> The IP addresses, related to neighbor up, could be used for unicast = hello's >> or updates in neighbor tables directly. So it may help. But do we set = adjacency=20 >> to what DLEP provides? Or mandate verification with L3 hello's? >>=20 >> Often, all info for neighbor cache is already available in the hello = packet.=20 >> There is running code that actually use it. Another approach is = trigger L2=20 >> address resolving for all next-hop IP addresses. IMHO good quality = routers=20 >> do that / should do that, also in a non-MANET environment. >>=20 >>> Total contact time between routers in a MANET could be very >>> short, and anything that helps speed the establishment of the = connection >>> is welcome. >> Yes, with limits on "anything". Is header snooping acceptable? >>=20 >> My main concern is, there are already enough methods that can do the = job. >=20 > The problem with header snooping is that it has to be done *in the = radio*. No, it is a mechanism in the router. Routing packets have L2 and L3 = headers, good info to populate adjacency tables. > With the DLEP mechanism, passing Layer 3 devices is as straightforward = as:=20 >=20 > 1. A router and it's *locally attached* radio establish DLEP session. = The router hands the radio it's addresses via "Peer Offer".=20 > 2. The radio does NOT need to know what these addresses are. Radio can = treat the information as opaque TLV's. Radio stores that information.=20 > 3. When the radio detects a new potential neighbor (e.g., another = radio), it can exchange the opaque TLV's as part of the radio handshake.=20= > 4. Each radio now builds a "Neighbor Up" back to the routers involved, = appending the opaque TLV's received from the other radio.=20 >=20 > And presto, you have exchanged Layer 3 addresses, irrespective of = subnet masks, ARP quirkiness, etc=85 First hello packet has all needed info. Using it needs no additional bit = over the air. Teco >=20 > Regards, > Stan >=20 >=20 >=20 >>=20 >> Teco >>=20 >>=20 >=20 From sratliff@cisco.com Thu Jul 5 07:54: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 75CF521F86F9 for ; Thu, 5 Jul 2012 07:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 FQj0Gbm8VtL6 for ; Thu, 5 Jul 2012 07:54:46 -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 30F1521F85C9 for ; Thu, 5 Jul 2012 07:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4080; q=dns/txt; s=iport; t=1341500099; x=1342709699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4vuKAYj7cwrIHllWnt1wYhzE3AHP1maQcN5Zq6QmBpI=; b=ZrdsQVeyRPw6zIjY5jTGsZkqwXWkDmsBF3uTxMhZsqJidrRpZpsxUbTH T1PyMdRIn/Rbjq8ehHqCkPbSJQqeJqGA2IBObpYL+W/tUpL9D63lwCYp8 O3w11kMuwNjLLbKFadYy+0s9SrJszDn+bEHroeqYInk75+MVNwsfa+ddr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJyq9U+tJV2Y/2dsb2JhbABFtyaBB4IYAQEBAwEBAQEPAVsLBQsCAQgOCi4nCyUBAQQOBSKHZAULmVmfawSLOYVeYAOVN44dgWaCXw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99062308" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jul 2012 14:54:38 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65Esc94018061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 14:54:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 09:54:38 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fTpCAFddlbEyMT95YMXvXBAAH9JaAAA+x/4AAOExngAABSSsAAAA4UwA= Date: Thu, 5 Jul 2012 14:54:36 +0000 Message-ID: <95E08F5F-1BB0-49A6-B6E8-A9E952D358E3@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--46.924900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <24DFEAEF63EC414E832E7F46EF515455@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:54:47 -0000 On Jul 5, 2012, at 10:48 AM, Henning Rogge wrote: > If a radio has this mechanism, its a good idea to use it. >=20 > The nice thing is that even if the radio does NOT have this feature, > the network will still work. >=20 > The Router will send the Radio IP-Addresses, which the radio will > throw away because it cannot transport them over the air. This means > the routers will not get IP-addresses as part of the information about > the neighbors through DLEP... which means that they will not pre-fill > the ARP-Table. >=20 > and will just trigger the normal ARP mechanism. Of course it will be > as slow as the normal ARP, which means that companies might integrate > it in more radios. >=20 > Which means the "IP over radio-layer2 handshake" has a good fallback > for the case that the router DOES support "IP addresses over DLEP" but > the radio does not. Yep, we're in agreement there. :-)=20 Regards, Stan >=20 > Henning Rogge >=20 > On Thu, Jul 5, 2012 at 4:11 PM, Stan Ratliff (sratliff) > wrote: >>=20 >> On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: >>>=20 >>>> Based on our experience with using DLEP, I would request that it becom= es >>>> mandatory to supply either an IPv4 or IPv6 address of the far end rout= er >>>> during a Neighbour Up/Down message as that would speed up the routing >>>> process. >>> I like fast convergence. The question is how to do it. >>>=20 >>> Neighbor up/down would fire triggers in the L3 hello mechanism. Up woul= d >>> start send out new hello's. Down would update the link state, and optio= nally >>> send out new hello's. >>>=20 >>> The IP addresses, related to neighbor up, could be used for unicast hel= lo's >>> or updates in neighbor tables directly. So it may help. But do we set a= djacency >>> to what DLEP provides? Or mandate verification with L3 hello's? >>>=20 >>> Often, all info for neighbor cache is already available in the hello pa= cket. >>> There is running code that actually use it. Another approach is trigger= L2 >>> address resolving for all next-hop IP addresses. IMHO good quality rout= ers >>> do that / should do that, also in a non-MANET environment. >>>=20 >>>> Total contact time between routers in a MANET could be very >>>> short, and anything that helps speed the establishment of the connecti= on >>>> is welcome. >>> Yes, with limits on "anything". Is header snooping acceptable? >>>=20 >>> My main concern is, there are already enough methods that can do the jo= b. >>=20 >> The problem with header snooping is that it has to be done *in the radio= *. With the DLEP mechanism, passing Layer 3 devices is as straightforward a= s: >>=20 >> 1. A router and it's *locally attached* radio establish DLEP session. Th= e router hands the radio it's addresses via "Peer Offer". >> 2. The radio does NOT need to know what these addresses are. Radio can t= reat the information as opaque TLV's. Radio stores that information. >> 3. When the radio detects a new potential neighbor (e.g., another radio)= , it can exchange the opaque TLV's as part of the radio handshake. >> 4. Each radio now builds a "Neighbor Up" back to the routers involved, a= ppending the opaque TLV's received from the other radio. >>=20 >> And presto, you have exchanged Layer 3 addresses, irrespective of subnet= masks, ARP quirkiness, etc=85 >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>>=20 >>> Teco >>>=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 From sratliff@cisco.com Thu Jul 5 08:06: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 2229021F8779 for ; Thu, 5 Jul 2012 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 bUpzIlKKgIT6 for ; Thu, 5 Jul 2012 08:06:39 -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 E4E4121F876F for ; Thu, 5 Jul 2012 08:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3158; q=dns/txt; s=iport; t=1341500812; x=1342710412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=epPpCFSYQwGdtdqskMSf2gEYTBVvtLZL+waXmLd+UO4=; b=AEajb0mF+0yXcMdNTTJ4iXVl4Kj9pNCmZQV+0fUIuZmRrLa8mdKVZReM o/J4XpJV7bRmUrA1c+BFbrzY9n/Yg7JdvfGtJcB414sNNhT/NtkQMK545 sqGPoNsJ1m2YrqBCNYjtOIiROd7Sa61YkTVgdryEXLZj7IZhX3TDWkNoQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALes9U+tJXHB/2dsb2JhbABFtyaBB4IYAQEBAwESAWYQAgEIGC4yJQEBBA4nh2QFmWCfb4s5hV5gA5U3jh2BZoJf X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99034004" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jul 2012 15:06:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q65F6qaO029771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 15:06:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 10:06:51 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fTpCAFddlbEyMT95YMXvXBAAH9JaAAA+x/4AAOExngAABduqAAAB4GoA= Date: Thu, 5 Jul 2012 15:06:51 +0000 Message-ID: <893D5C8C-A767-4ED1-9D8C-05245A4CAE2C@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> <3631555C-6977-448E-967F-A860B69F2B36@inf-net.nl> In-Reply-To: <3631555C-6977-448E-967F-A860B69F2B36@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--38.403600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:06:40 -0000 On Jul 5, 2012, at 10:53 AM, Teco Boot wrote: >=20 > Op 5 jul. 2012, om 16:11 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >>=20 >> On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven: >>>=20 >>>> Based on our experience with using DLEP, I would request that it becom= es >>>> mandatory to supply either an IPv4 or IPv6 address of the far end rout= er >>>> during a Neighbour Up/Down message as that would speed up the routing >>>> process. >>> I like fast convergence. The question is how to do it. >>>=20 >>> Neighbor up/down would fire triggers in the L3 hello mechanism. Up woul= d=20 >>> start send out new hello's. Down would update the link state, and optio= nally >>> send out new hello's. >>>=20 >>> The IP addresses, related to neighbor up, could be used for unicast hel= lo's >>> or updates in neighbor tables directly. So it may help. But do we set a= djacency=20 >>> to what DLEP provides? Or mandate verification with L3 hello's? >>>=20 >>> Often, all info for neighbor cache is already available in the hello pa= cket.=20 >>> There is running code that actually use it. Another approach is trigger= L2=20 >>> address resolving for all next-hop IP addresses. IMHO good quality rout= ers=20 >>> do that / should do that, also in a non-MANET environment. >>>=20 >>>> Total contact time between routers in a MANET could be very >>>> short, and anything that helps speed the establishment of the connecti= on >>>> is welcome. >>> Yes, with limits on "anything". Is header snooping acceptable? >>>=20 >>> My main concern is, there are already enough methods that can do the jo= b. >>=20 >> The problem with header snooping is that it has to be done *in the radio= *. > No, it is a mechanism in the router. Routing packets have L2 and L3 heade= rs, good info to populate adjacency tables. No, it's in the radio=85 especially where multicast is concerned.=20 >=20 >> With the DLEP mechanism, passing Layer 3 devices is as straightforward a= s:=20 >>=20 >> 1. A router and it's *locally attached* radio establish DLEP session. Th= e router hands the radio it's addresses via "Peer Offer".=20 >> 2. The radio does NOT need to know what these addresses are. Radio can t= reat the information as opaque TLV's. Radio stores that information.=20 >> 3. When the radio detects a new potential neighbor (e.g., another radio)= , it can exchange the opaque TLV's as part of the radio handshake.=20 >> 4. Each radio now builds a "Neighbor Up" back to the routers involved, a= ppending the opaque TLV's received from the other radio.=20 >>=20 >> And presto, you have exchanged Layer 3 addresses, irrespective of subnet= masks, ARP quirkiness, etc=85 > First hello packet has all needed info. Using it needs no additional bit = over the air. Not true. I don't know of a single HELLO packet, from any protocol, that co= ntains both IPv4 and IPv6 addresses.=20 Stan >=20 > Teco >=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>=20 >>>=20 >>> Teco >>>=20 >>>=20 >>=20 >=20 From teco@inf-net.nl Thu Jul 5 08:11: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 15F9321F8731 for ; Thu, 5 Jul 2012 08:11:18 -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 gC-4hYi4sP6J for ; Thu, 5 Jul 2012 08:11:17 -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 EE57C21F8722 for ; Thu, 5 Jul 2012 08:11:16 -0700 (PDT) Received: by bkty7 with SMTP id y7so536511bkt.31 for ; Thu, 05 Jul 2012 08:11: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=1HyVJUVE/PZQHNLemmxOzZoWSTpEp0nxy9uFTHpxkmw=; b=TTzwN0/crXtaekNzG2LU4BqR2ntVrRJUPC5h/YCmMkNEX6qS3yByknrbY8AsU5WQM1 3czAmlC2tTz98GXyAgUbdspQjMQK7q0UPiLtkhMbfMUPVxVuEDzcP3ma1OfuBWjMXXxX fR/hT8oJ+clDIL0YE4E+ajxaGwM8K9u1OYyYPHXvucz31eUYh5ns3rHHXsT11d8+CM3I S7IpbJg9gLxkdwPXxKI/Y4JNZVXB0fVOrKEoxVIS1dSwY/EDXxuoGqfwFnTftrKd3hnm 3LYh6v1iUvXtCaaig2tDD44ZVjSQNUnIIxjTklJlvFWG/8294tE+mJ+1jOFaAzRg7XLX fzUg== Received: by 10.204.153.15 with SMTP id i15mr13838609bkw.74.1341501089211; Thu, 05 Jul 2012 08:11:29 -0700 (PDT) Received: from [10.87.17.104] ([80.187.201.33]) by mx.google.com with ESMTPS id hs2sm20803556bkc.1.2012.07.05.08.11.27 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 08:11:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> Date: Thu, 5 Jul 2012 17:11:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkLK2V5PVHF4vfufuKFAznofdsncRgFBW/HfGU/5zjQmnKbMjpl3FB2DcApLVqNnDejTp6h Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:11:18 -0000 Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >=20 >>=20 >> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>=20 >>>> Most of the workinggroup seems to have the opinion that DLEP should >>>> move to full RFC5444 compliance, because it will fit the purpose of >>>> DLEP fine and spare the IETF "just another proprietary data = format". >>>> With RFC5444 we can easily get to a point where we get a protocol = that >>>> can be extended for more metrics without the need of a version = field, >>>> which will simplify future DLEP revisions. >>>=20 >>> And again, we disagree on that point.=20 >>=20 >> Stan, you could set up a poll to find out the working group opinion. >>=20 >> In the discussion on full RFC 5444 compliance, or just use it as a=20 >> transport container, my non-important opinion: >> - dlep-02 implements reliable transport, with tiny chunks of = to_be_acked=20 >> data and the ack messages=20 >> - this reliable transport requires (complex) state machines, but = provides=20 >> reduced data volume over the wire >> - when transferred data is highly variable, this reliable transport=20= >> doesn't make sense. A timer based refresh, with triggered fast = updates,=20 >> would better fit the required functionality >=20 > Relying on "yet another independent timer" isn't the way to go, IMO. = That will only extend time to converge the network. No, it isn't. Updates are send as fast as the reliable mechanism. Timers = are for auto-cleanup. It is in OSPF too.=20 > It also doesn't cover the case where some of this data might get = dropped. Wait for retransmit. When link is unstable, updates might be send quite = frequent. Probably faster than delayed ACKs. > Yes, DLEP flows are typically on a high-speed wired link, and the = theoretical drop rate would be small. However, Murphy's Law says traffic = *will* get dropped, OK. > and the traffic that gets dropped will be that which is most important = to you. Why? > There is also the use case where the wireless link itself is used for = DLEP traffic - what we've currently called the "Detached Discovery" = mode.=20 I am less interested in this mode. I would use a proxy, and reliable = protocol over the satcom link (scenario in I-D for this mode).=20 On satcom links, extremely efficient protocols is highly preferred. IMHO = few (one?) metric type is used, and address TLVs. For this satcom link scenario, is info provided the 2 links, for a 2-hop = system, for spoke-spoke traffic?=20 Teco. >=20 > Regards, > Stan >=20 >=20 >> - RFC 5444 provides a mechanism to compress larger arrays of data. = This=20 >> could be used for MAC address TLV's, for transfer of ever changing = link=20 >> metrics >> - for reliable transfer, one option would be using another protocol,=20= >> already standardized. It is called TCP, if I remember well. For >> discovery, TCP doesn't work well...=20 >> - because dlep acts on local, often high speed links, reduction of = volume >> of transferred data has low priority. >> I guess we have to choose how to implement the link metrics exchange. >> If we opt for reliable transfer, I prefer TCP. For a straightforward >> stateless transfer, RFC 5444 MAC address TLV's looks an obvious = choice. >> Opinions on address TLVs would be influenced on having the parser = already,=20 >> or facing something on the todo list. Dito the validity timer stuff. >>=20 >> Teco >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From hrogge@googlemail.com Thu Jul 5 08:17: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 1040221F8759 for ; Thu, 5 Jul 2012 08:17:27 -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 SZhCFhSzomMk for ; Thu, 5 Jul 2012 08:17:26 -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 43AD321F872A for ; Thu, 5 Jul 2012 08:17:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13279126pbc.31 for ; Thu, 05 Jul 2012 08:17: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; bh=/Y4hsKZfWJoXFzefh7nSs7JOXF633MNOfKDiUE+8JP8=; b=HzEt7rJxPSscWvQ5QrMxkVagk68LMvR7BgxVFqCUlsngi23+V/ujtWxisNtvhuRG9Z e5LENbFexNlM4lKsxY+c4Sq9M38Z4Juxts2f5Th3IrJ97IDg8nRrkUZ4TnGBvbqmtl/1 E8HF4C5QcXNjxQ6fPcIWwoFxr9kjy6ThTKquVPw5XAXfskSjX6fB909lXMBUgyR9u9vT GADpke6SylsyK8MSNavi0oDRWfbeQGjhgkmC6U4ZxLY61/VxTmzxFeJHo17xSGE8VP0c bvRUaECXcGKXfo5w2DqD6Kkf0xNpJIodfezb3G0zVHQlVnuXl8nVPeYSYx3SFQcwjzuK wrNQ== Received: by 10.68.232.232 with SMTP id tr8mr28640298pbc.73.1341501459850; Thu, 05 Jul 2012 08:17:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 08:17:19 -0700 (PDT) In-Reply-To: <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> From: Henning Rogge Date: Thu, 5 Jul 2012 17:17:19 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:17:27 -0000 Can we maybe agree that we want a protocol that supports multiple kinds of optimizations for quick IP resolution, if possible with the same protocol mechanism? If the router does want to handle the ARP-Cache prefilling itself by listening to incoming broadcast (or calculate them from the MAC address in case of linklocal unicasts), this should be easy... If the radio handles the ARP magic by doing packet snooping, this should be also possible with DLEP. Either the radio would implement some Arp-Cache on its own (in which case the router will never see whats happening), or it will supply the received IPs from the interface via DLEP to the router. Henning Rogge On Thu, Jul 5, 2012 at 5:11 PM, Teco Boot wrote: > > Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende geschreven: > >> >> On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >> >>> >>> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende geschreven: >>> >>>> >>>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>> >>>>> Most of the workinggroup seems to have the opinion that DLEP should >>>>> move to full RFC5444 compliance, because it will fit the purpose of >>>>> DLEP fine and spare the IETF "just another proprietary data format". >>>>> With RFC5444 we can easily get to a point where we get a protocol that >>>>> can be extended for more metrics without the need of a version field, >>>>> which will simplify future DLEP revisions. >>>> >>>> And again, we disagree on that point. >>> >>> Stan, you could set up a poll to find out the working group opinion. >>> >>> In the discussion on full RFC 5444 compliance, or just use it as a >>> transport container, my non-important opinion: >>> - dlep-02 implements reliable transport, with tiny chunks of to_be_acked >>> data and the ack messages >>> - this reliable transport requires (complex) state machines, but provides >>> reduced data volume over the wire >>> - when transferred data is highly variable, this reliable transport >>> doesn't make sense. A timer based refresh, with triggered fast updates, >>> would better fit the required functionality >> >> Relying on "yet another independent timer" isn't the way to go, IMO. That will only extend time to converge the network. > No, it isn't. Updates are send as fast as the reliable mechanism. Timers are for auto-cleanup. It is in OSPF too. > >> It also doesn't cover the case where some of this data might get dropped. > Wait for retransmit. When link is unstable, updates might be send quite frequent. Probably faster than delayed ACKs. > >> Yes, DLEP flows are typically on a high-speed wired link, and the theoretical drop rate would be small. However, Murphy's Law says traffic *will* get dropped, > OK. > >> and the traffic that gets dropped will be that which is most important to you. > Why? > >> There is also the use case where the wireless link itself is used for DLEP traffic - what we've currently called the "Detached Discovery" mode. > I am less interested in this mode. I would use a proxy, and reliable protocol over the satcom link (scenario in I-D for this mode). > On satcom links, extremely efficient protocols is highly preferred. IMHO few (one?) metric type is used, and address TLVs. > For this satcom link scenario, is info provided the 2 links, for a 2-hop system, for spoke-spoke traffic? > > Teco. > >> >> Regards, >> Stan >> >> >>> - RFC 5444 provides a mechanism to compress larger arrays of data. This >>> could be used for MAC address TLV's, for transfer of ever changing link >>> metrics >>> - for reliable transfer, one option would be using another protocol, >>> already standardized. It is called TCP, if I remember well. For >>> discovery, TCP doesn't work well... >>> - because dlep acts on local, often high speed links, reduction of volume >>> of transferred data has low priority. >>> I guess we have to choose how to implement the link metrics exchange. >>> If we opt for reliable transfer, I prefer TCP. For a straightforward >>> stateless transfer, RFC 5444 MAC address TLV's looks an obvious choice. >>> Opinions on address TLVs would be influenced on having the parser already, >>> or facing something on the todo list. Dito the validity timer stuff. >>> >>> 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 -- 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 Jul 5 08:20: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 4F8EC21F87A0 for ; Thu, 5 Jul 2012 08:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 DlOfZ2WVCGXJ for ; Thu, 5 Jul 2012 08:20:12 -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 9F6FD11E80B7 for ; Thu, 5 Jul 2012 08:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4073; q=dns/txt; s=iport; t=1341501625; x=1342711225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rsBwlQgjbmZdBuVHMQiAEpaU11Az5rabH33goShNxxs=; b=YlWyJ+OIcpmPVVn56XFa8JK2Oc+8owmF3jYsu3gamsGy3bzLnERVsesy 9pq0uewoLI7loLqlEKZqyqZnaM03GFJiRhlE7ryoEEhHjF/aFMWsy5IK4 MVStu02xFBvy2KyjXqVlUiicVHJkkv5vpLfLgVAJRT8O+YJKkGjbnXwq4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJGv9U+tJXHB/2dsb2JhbABFtyeBB4IYAQEBAwEBAQEPASc0CxACAQgYHhAnCyUCBAoEBSKHZAULmVWfZwSLOYVeYAOVN44dgWaCXw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99075247" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2012 15:20:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q65FKOiK012898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 15:20:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 10:20:24 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAIAACZ8AgAAGDgCAAMVZAIACLG6AgAAE94CAAAKAAA== Date: Thu, 5 Jul 2012 15:20:23 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> In-Reply-To: <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--44.627600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <793B45446BCC094D8B62B5296D10DDA4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:20:13 -0000 On Jul 5, 2012, at 11:11 AM, Teco Boot wrote: >=20 > Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >>=20 >> On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende ges= chreven: >>>=20 >>>>=20 >>>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>>=20 >>>>> Most of the workinggroup seems to have the opinion that DLEP should >>>>> move to full RFC5444 compliance, because it will fit the purpose of >>>>> DLEP fine and spare the IETF "just another proprietary data format". >>>>> With RFC5444 we can easily get to a point where we get a protocol tha= t >>>>> can be extended for more metrics without the need of a version field, >>>>> which will simplify future DLEP revisions. >>>>=20 >>>> And again, we disagree on that point.=20 >>>=20 >>> Stan, you could set up a poll to find out the working group opinion. >>>=20 >>> In the discussion on full RFC 5444 compliance, or just use it as a=20 >>> transport container, my non-important opinion: >>> - dlep-02 implements reliable transport, with tiny chunks of to_be_acke= d=20 >>> data and the ack messages=20 >>> - this reliable transport requires (complex) state machines, but provid= es=20 >>> reduced data volume over the wire >>> - when transferred data is highly variable, this reliable transport=20 >>> doesn't make sense. A timer based refresh, with triggered fast updates,= =20 >>> would better fit the required functionality >>=20 >> Relying on "yet another independent timer" isn't the way to go, IMO. Tha= t will only extend time to converge the network. > No, it isn't. Updates are send as fast as the reliable mechanism. Timers = are for auto-cleanup. It is in OSPF too.=20 >=20 Can't be. You have to wait on the timers to expire. Thus, you extend the ti= me.=20 Stan >> It also doesn't cover the case where some of this data might get dropped= . > Wait for retransmit. When link is unstable, updates might be send quite f= requent. Probably faster than delayed ACKs. >=20 >> Yes, DLEP flows are typically on a high-speed wired link, and the theore= tical drop rate would be small. However, Murphy's Law says traffic *will* g= et dropped, > OK. >=20 >> and the traffic that gets dropped will be that which is most important t= o you. > Why? >=20 >> There is also the use case where the wireless link itself is used for DL= EP traffic - what we've currently called the "Detached Discovery" mode.=20 > I am less interested in this mode. I would use a proxy, and reliable prot= ocol over the satcom link (scenario in I-D for this mode).=20 > On satcom links, extremely efficient protocols is highly preferred. IMHO = few (one?) metric type is used, and address TLVs. > For this satcom link scenario, is info provided the 2 links, for a 2-hop = system, for spoke-spoke traffic?=20 >=20 > Teco. >=20 >>=20 >> Regards, >> Stan >>=20 >>=20 >>> - RFC 5444 provides a mechanism to compress larger arrays of data. This= =20 >>> could be used for MAC address TLV's, for transfer of ever changing link= =20 >>> metrics >>> - for reliable transfer, one option would be using another protocol,=20 >>> already standardized. It is called TCP, if I remember well. For >>> discovery, TCP doesn't work well...=20 >>> - because dlep acts on local, often high speed links, reduction of volu= me >>> of transferred data has low priority. >>> I guess we have to choose how to implement the link metrics exchange. >>> If we opt for reliable transfer, I prefer TCP. For a straightforward >>> stateless transfer, RFC 5444 MAC address TLV's looks an obvious choice. >>> Opinions on address TLVs would be influenced on having the parser alrea= dy,=20 >>> or facing something on the todo list. Dito the validity timer stuff. >>>=20 >>> Teco >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From teco@inf-net.nl Thu Jul 5 08:20: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 28FD921F87A9 for ; Thu, 5 Jul 2012 08:20:32 -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 yS2tQlalKrx7 for ; Thu, 5 Jul 2012 08:20:31 -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 C1FA321F87A7 for ; Thu, 5 Jul 2012 08:20:29 -0700 (PDT) Received: by bkty7 with SMTP id y7so547776bkt.31 for ; Thu, 05 Jul 2012 08:20:42 -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=WSav8kxavU2aPytx8kLqou6q7ne3+pDaITFKjRzuPXE=; b=kjNzhfvHyMo2pX8P7Qmof99i3k0LCdIAV1tL58TcOiG2i2Lxnz/8abPKQH5s3OqD+z vtp4OeqMQ6tRLowyhxFIAq1ZR5EQ/7ZPyHELajvV6LphYfVCty2fu6b7b5JJcFSWIFBA MMxAnnf2GfJl+cbE/6xwsGsiLRFTy+SrrSx3B0SkTOVMqUokkOgJnejR8k7ZCNbey4Ey VhNm4PRSJlAvklRpynGASa2l8oLRNyUK0oohp096azM0bqeQCEztK2V9uJpQBoBPGb5Q lNOCyY+1V24drGLeHX0bIXGx/ni+2mTqaf5mYAWWY6f8dKx6uhhHy0Y+cv6sH6ljK41Y 7H+g== Received: by 10.204.128.65 with SMTP id j1mr5474700bks.93.1341501642718; Thu, 05 Jul 2012 08:20:42 -0700 (PDT) Received: from [10.87.17.104] ([80.187.201.33]) by mx.google.com with ESMTPS id t23sm13091739bks.4.2012.07.05.08.20.32 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 08:20:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <893D5C8C-A767-4ED1-9D8C-05245A4CAE2C@cisco.com> Date: Thu, 5 Jul 2012 17:20:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <089DC2EF-826D-4EF5-B100-0197A975508E@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <10217125-07F8-4F5F-81E6-096FF4DE95A5@cisco.com> <3631555C-6977-448E-967F-A860B69F2B36@inf-net.nl> <893D5C8C-A767-4ED1-9D8C-05245A4CAE2C@cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkdCrrqpRiTd5AU9J0ejicOrcY34BrzxF6/WSF8e0amIKNCAu+3OW2uq+eXX7p72V8YClkl Cc: "Dearlove, Christopher \(UK\)" , "" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:20:32 -0000 Op 5 jul. 2012, om 17:06 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 5, 2012, at 10:53 AM, Teco Boot wrote: >=20 >>=20 >> Op 5 jul. 2012, om 16:11 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Jul 4, 2012, at 7:19 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende = geschreven: >>>>=20 >>>>> Based on our experience with using DLEP, I would request that it = becomes >>>>> mandatory to supply either an IPv4 or IPv6 address of the far end = router >>>>> during a Neighbour Up/Down message as that would speed up the = routing >>>>> process. >>>> I like fast convergence. The question is how to do it. >>>>=20 >>>> Neighbor up/down would fire triggers in the L3 hello mechanism. Up = would=20 >>>> start send out new hello's. Down would update the link state, and = optionally >>>> send out new hello's. >>>>=20 >>>> The IP addresses, related to neighbor up, could be used for unicast = hello's >>>> or updates in neighbor tables directly. So it may help. But do we = set adjacency=20 >>>> to what DLEP provides? Or mandate verification with L3 hello's? >>>>=20 >>>> Often, all info for neighbor cache is already available in the = hello packet.=20 >>>> There is running code that actually use it. Another approach is = trigger L2=20 >>>> address resolving for all next-hop IP addresses. IMHO good quality = routers=20 >>>> do that / should do that, also in a non-MANET environment. >>>>=20 >>>>> Total contact time between routers in a MANET could be very >>>>> short, and anything that helps speed the establishment of the = connection >>>>> is welcome. >>>> Yes, with limits on "anything". Is header snooping acceptable? >>>>=20 >>>> My main concern is, there are already enough methods that can do = the job. >>>=20 >>> The problem with header snooping is that it has to be done *in the = radio*. >> No, it is a mechanism in the router. Routing packets have L2 and L3 = headers, good info to populate adjacency tables. >=20 > No, it's in the radio=85 especially where multicast is concerned.=20 Why should a radio snoop headers?=20 >=20 >>=20 >>> With the DLEP mechanism, passing Layer 3 devices is as = straightforward as:=20 >>>=20 >>> 1. A router and it's *locally attached* radio establish DLEP = session. The router hands the radio it's addresses via "Peer Offer".=20 >>> 2. The radio does NOT need to know what these addresses are. Radio = can treat the information as opaque TLV's. Radio stores that = information.=20 >>> 3. When the radio detects a new potential neighbor (e.g., another = radio), it can exchange the opaque TLV's as part of the radio handshake.=20= >>> 4. Each radio now builds a "Neighbor Up" back to the routers = involved, appending the opaque TLV's received from the other radio.=20 >>>=20 >>> And presto, you have exchanged Layer 3 addresses, irrespective of = subnet masks, ARP quirkiness, etc=85 >> First hello packet has all needed info. Using it needs no additional = bit over the air. >=20 > Not true. I don't know of a single HELLO packet, from any protocol, = that contains both IPv4 and IPv6 addresses.=20 There is no need for such. There are protocols that provide IPv4 and IPv6 topology with a single = protocol instance, so single hello packet. Before packets flow, a next-hop calculation is needed, on some = to_be_exchanged data. Teco > Stan >=20 >>=20 >> Teco >>=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>=20 >>=20 >=20 From teco@inf-net.nl Thu Jul 5 08:23: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 DDC1011E80D2 for ; Thu, 5 Jul 2012 08:23:17 -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 dzPAqyYxRSfG for ; Thu, 5 Jul 2012 08:23:17 -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 A1FF711E80D0 for ; Thu, 5 Jul 2012 08:23:16 -0700 (PDT) Received: by bkty7 with SMTP id y7so550944bkt.31 for ; Thu, 05 Jul 2012 08:23: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=01qvw9jXkzEAyFqba5Mp6ZGHIU1q5n3IzGu0GE27eDs=; b=YzRDut1q0qUzBim4FbCvas3E9t35eHpLfafNfh4vf2laGNNmraearA1IwzvGlWoJLh Qnk9KgiHap2YNP4BbffwidqJWUHvnrhz84kxo3yxgts4tJvvq6tUaaOLszwTLC+McHI1 12Q6fPeMHxiSlPjgO3Zy2EmJtGNxsCLNHj2aOjhE8GGAkIBHSfi7XyA7gXMgrW95abu6 yJlYUJ0/RNkcxUa0E8jxxEULwk/HmF5/zdS9ssnYD7MQkF6itw0YnXXc92UyI8buDh3g FiPhTM+raVMjTx9FWUo9fnCwBn9G1Lg/uWCWBtAnKrrxqjQkOcMXdmebkH16B8rgqeF7 LPXg== Received: by 10.204.156.4 with SMTP id u4mr14319250bkw.6.1341501809475; Thu, 05 Jul 2012 08:23:29 -0700 (PDT) Received: from [10.87.17.104] ([80.187.201.33]) by mx.google.com with ESMTPS id gq2sm14746614bkc.13.2012.07.05.08.23.17 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 08:23:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Thu, 5 Jul 2012 17:22:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmve0pmqGEmbvwl0vQLNc4Urj1OlWY+31HyOrhnUG/2al+poro3aiVW4G384JPPg1FHH69n Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:23:18 -0000 Op 5 jul. 2012, om 17:20 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 5, 2012, at 11:11 AM, Teco Boot wrote: >=20 >>=20 >> Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>>>=20 >>>>>=20 >>>>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>>>=20 >>>>>> Most of the workinggroup seems to have the opinion that DLEP = should >>>>>> move to full RFC5444 compliance, because it will fit the purpose = of >>>>>> DLEP fine and spare the IETF "just another proprietary data = format". >>>>>> With RFC5444 we can easily get to a point where we get a protocol = that >>>>>> can be extended for more metrics without the need of a version = field, >>>>>> which will simplify future DLEP revisions. >>>>>=20 >>>>> And again, we disagree on that point.=20 >>>>=20 >>>> Stan, you could set up a poll to find out the working group = opinion. >>>>=20 >>>> In the discussion on full RFC 5444 compliance, or just use it as a=20= >>>> transport container, my non-important opinion: >>>> - dlep-02 implements reliable transport, with tiny chunks of = to_be_acked=20 >>>> data and the ack messages=20 >>>> - this reliable transport requires (complex) state machines, but = provides=20 >>>> reduced data volume over the wire >>>> - when transferred data is highly variable, this reliable transport=20= >>>> doesn't make sense. A timer based refresh, with triggered fast = updates,=20 >>>> would better fit the required functionality >>>=20 >>> Relying on "yet another independent timer" isn't the way to go, IMO. = That will only extend time to converge the network. >> No, it isn't. Updates are send as fast as the reliable mechanism. = Timers are for auto-cleanup. It is in OSPF too.=20 >>=20 >=20 > Can't be. You have to wait on the timers to expire. Thus, you extend = the time. This is the wrong approach. Triggered updates make sense, especially if = bandwidth is no concern. Teco >=20 > Stan >=20 >=20 >=20 >>> It also doesn't cover the case where some of this data might get = dropped. >> Wait for retransmit. When link is unstable, updates might be send = quite frequent. Probably faster than delayed ACKs. >>=20 >>> Yes, DLEP flows are typically on a high-speed wired link, and the = theoretical drop rate would be small. However, Murphy's Law says traffic = *will* get dropped, >> OK. >>=20 >>> and the traffic that gets dropped will be that which is most = important to you. >> Why? >>=20 >>> There is also the use case where the wireless link itself is used = for DLEP traffic - what we've currently called the "Detached Discovery" = mode.=20 >> I am less interested in this mode. I would use a proxy, and reliable = protocol over the satcom link (scenario in I-D for this mode).=20 >> On satcom links, extremely efficient protocols is highly preferred. = IMHO few (one?) metric type is used, and address TLVs. >> For this satcom link scenario, is info provided the 2 links, for a = 2-hop system, for spoke-spoke traffic?=20 >>=20 >> Teco. >>=20 >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>> - RFC 5444 provides a mechanism to compress larger arrays of data. = This=20 >>>> could be used for MAC address TLV's, for transfer of ever changing = link=20 >>>> metrics >>>> - for reliable transfer, one option would be using another = protocol,=20 >>>> already standardized. It is called TCP, if I remember well. For >>>> discovery, TCP doesn't work well...=20 >>>> - because dlep acts on local, often high speed links, reduction of = volume >>>> of transferred data has low priority. >>>> I guess we have to choose how to implement the link metrics = exchange. >>>> If we opt for reliable transfer, I prefer TCP. For a = straightforward >>>> stateless transfer, RFC 5444 MAC address TLV's looks an obvious = choice. >>>> Opinions on address TLVs would be influenced on having the parser = already,=20 >>>> or facing something on the todo list. Dito the validity timer = stuff. >>>>=20 >>>> Teco >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 From sratliff@cisco.com Thu Jul 5 08:49: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 A760D21F879E for ; Thu, 5 Jul 2012 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 d8GdplNV+dqt for ; Thu, 5 Jul 2012 08:49:39 -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 80A4F21F862A for ; Thu, 5 Jul 2012 08:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4972; q=dns/txt; s=iport; t=1341503393; x=1342712993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qBJ0ZpDYURRjqhqdC5E4iMRul9QmZVfJq8od8p4+Ft8=; b=EAvmjFz2Avu/hi7IRCQroP6ruTRIqdc4fr+bg+5A1BuJrTTSuhYp3gwn imgGp/Ts/csW8flw2tM4mfUyZqDZlWGWysgOBDuYC63P/07a5ka1GMUUh dVWD512WeSnXeFQjE9iF1JpyLIMWEBYIwflN43HNYqIWYcybVMYldvBGJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKa29U+tJXG9/2dsb2JhbABFtymBB4IYAQEBAwEBAQEPAVsLEAIBCBguJwslAgQKBAUih2QFC5lWn2wEizmFXmADlTeOHYFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99085370" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2012 15:49:53 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q65FnrZx018998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 15:49:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 10:49:52 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAIAACZ8AgAAGDgCAAMVZAIACLG6AgAAE94CAAAKAAIAAALyAgAAHgYA= Date: Thu, 5 Jul 2012 15:49:51 +0000 Message-ID: <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> In-Reply-To: <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--48.482100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:49:40 -0000 On Jul 5, 2012, at 11:22 AM, Teco Boot wrote: >=20 > Op 5 jul. 2012, om 17:20 heeft Stan Ratliff (sratliff) het volgende gesch= reven: >=20 >>=20 >> On Jul 5, 2012, at 11:11 AM, Teco Boot wrote: >>=20 >>>=20 >>> Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende ges= chreven: >>>=20 >>>>=20 >>>> On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >>>>=20 >>>>>=20 >>>>> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende g= eschreven: >>>>>=20 >>>>>>=20 >>>>>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>>>>=20 >>>>>>> Most of the workinggroup seems to have the opinion that DLEP should >>>>>>> move to full RFC5444 compliance, because it will fit the purpose of >>>>>>> DLEP fine and spare the IETF "just another proprietary data format"= . >>>>>>> With RFC5444 we can easily get to a point where we get a protocol t= hat >>>>>>> can be extended for more metrics without the need of a version fiel= d, >>>>>>> which will simplify future DLEP revisions. >>>>>>=20 >>>>>> And again, we disagree on that point.=20 >>>>>=20 >>>>> Stan, you could set up a poll to find out the working group opinion. >>>>>=20 >>>>> In the discussion on full RFC 5444 compliance, or just use it as a=20 >>>>> transport container, my non-important opinion: >>>>> - dlep-02 implements reliable transport, with tiny chunks of to_be_ac= ked=20 >>>>> data and the ack messages=20 >>>>> - this reliable transport requires (complex) state machines, but prov= ides=20 >>>>> reduced data volume over the wire >>>>> - when transferred data is highly variable, this reliable transport=20 >>>>> doesn't make sense. A timer based refresh, with triggered fast update= s,=20 >>>>> would better fit the required functionality >>>>=20 >>>> Relying on "yet another independent timer" isn't the way to go, IMO. T= hat will only extend time to converge the network. >>> No, it isn't. Updates are send as fast as the reliable mechanism. Timer= s are for auto-cleanup. It is in OSPF too.=20 >>>=20 >>=20 >> Can't be. You have to wait on the timers to expire. Thus, you extend the= time. > This is the wrong approach. Triggered updates make sense, especially if b= andwidth is no concern. Wow. So in your earlier email, you say "A timer based refresh, with trigger= ed updates=85". Now it's just "triggered updates"? I'm confused - it looks = like you're trying to take all positions at once. And I'll also argue that = a "triggered update" pretty much *has* to be based on a timer the way you'v= e described it. So it also looks like a difference without a distinction=85 Stan >=20 > Teco >=20 >>=20 >> Stan >>=20 >>=20 >>=20 >>>> It also doesn't cover the case where some of this data might get dropp= ed. >>> Wait for retransmit. When link is unstable, updates might be send quite= frequent. Probably faster than delayed ACKs. >>>=20 >>>> Yes, DLEP flows are typically on a high-speed wired link, and the theo= retical drop rate would be small. However, Murphy's Law says traffic *will*= get dropped, >>> OK. >>>=20 >>>> and the traffic that gets dropped will be that which is most important= to you. >>> Why? >>>=20 >>>> There is also the use case where the wireless link itself is used for = DLEP traffic - what we've currently called the "Detached Discovery" mode.=20 >>> I am less interested in this mode. I would use a proxy, and reliable pr= otocol over the satcom link (scenario in I-D for this mode).=20 >>> On satcom links, extremely efficient protocols is highly preferred. IMH= O few (one?) metric type is used, and address TLVs. >>> For this satcom link scenario, is info provided the 2 links, for a 2-ho= p system, for spoke-spoke traffic?=20 >>>=20 >>> Teco. >>>=20 >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>>> - RFC 5444 provides a mechanism to compress larger arrays of data. Th= is=20 >>>>> could be used for MAC address TLV's, for transfer of ever changing li= nk=20 >>>>> metrics >>>>> - for reliable transfer, one option would be using another protocol,= =20 >>>>> already standardized. It is called TCP, if I remember well. For >>>>> discovery, TCP doesn't work well...=20 >>>>> - because dlep acts on local, often high speed links, reduction of vo= lume >>>>> of transferred data has low priority. >>>>> I guess we have to choose how to implement the link metrics exchange. >>>>> If we opt for reliable transfer, I prefer TCP. For a straightforward >>>>> stateless transfer, RFC 5444 MAC address TLV's looks an obvious choic= e. >>>>> Opinions on address TLVs would be influenced on having the parser alr= eady,=20 >>>>> or facing something on the todo list. Dito the validity timer stuff. >>>>>=20 >>>>> Teco >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >=20 From Chris.Dearlove@baesystems.com Thu Jul 5 09:15: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 0621221F8722 for ; Thu, 5 Jul 2012 09:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 gPFwwmYm8+4N for ; Thu, 5 Jul 2012 09:15:31 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7844C21F8751 for ; Thu, 5 Jul 2012 09:15:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="252532999" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 05 Jul 2012 17:15:43 +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 q65GFhc0008057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 17:15:43 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 5 Jul 2012 17:15:42 +0100 From: "Dearlove, Christopher (UK)" To: "Stan Ratliff (sratliff)" , Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fkJPtrdHUq0SlS58HjbKfcgAH9JaAAAJa84AAOOkpgAAGTm9g Date: Thu, 5 Jul 2012 16:15:42 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> In-Reply-To: <67AE596B-AD94-4448-A777-849C129311E8@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: "" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:15:32 -0000 I'm of the view - There is no compulsion for DLEP to use 5444. The only compulsion is 5498'= s that anything using the manet protocol/port uses 5444. - 5444 is a flexible format. I believe (but no one has yet done and publish= ed the work to support that) that 5444 could be used to represent DLEP at l= east quite well, maybe very well. - The currently proposed way to use 5444 to represent DLEP is not a very go= od use of 5444 to do that. - The pros and cons of a non-5444 representation of DLEP versus a good 5444= representation of DLEP are hard to judge when neither is well-defined yet. - A key question is future extensibility, adding new attributes. This is a = strength of 5444. How much is it needed by DLEP? - As an author of 5444 it's always gratifying when someone uses what you he= lped create. But that's not a factor in the choice. --=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 (sratliff) Sent: 05 July 2012 15:07 To: Henning Rogge Cc: Subject: Re: [manet] Status of DLEP-draft at Cisco? ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: > On 07/04/2012 11:03 AM, John Dowdell wrote: >> Based on our experience with using DLEP, I would request that it becomes >> mandatory to supply either an IPv4 or IPv6 address of the far end router >> during a Neighbour Up/Down message as that would speed up the routing >> process. Total contact time between routers in a MANET could be very >> short, and anything that helps speed the establishment of the connection >> is welcome. >=20 > I would say it should be mandatory if the knowledge is present on the DLE= P-capable device. If you do not know the IP addresses of each partner, you = can still use DLEP and leave this job to the router. >=20 >> As to the 5444 debate, I do not see the need for 5444 compliance in >> DLEP. >=20 > If we can find a good fit for all the DLEP use cases with RFC5444, I see = no need to specify another packet format for it. DLEP transports informatio= n (many of them optional) about the local radio/modem and information (also= many of them optional) about connection between radios/modems. This seems = to be a very good description of the concept of RFC5444. >=20 > It also needs multiple kinds of messages, which makes message aggregation= into a single block of information an useful feature. >=20 > At last, it needs to interact with routing protocols (especially MANET pr= otocols), which makes reusing rfc5444 a good thing. That's a red herring, IMO. The fact that DLEP should interact with routing = protocols does *not* mean that 5444 use is, in and of itself, "a good thing= ". For example, the current DLEP offering I work on interacts with OSPFv3. = RFC 5444 compliance is actually a burden in that environment. Or, at a bare= minimum, it becomes "DLEP-specific". I believe DLEP has applicability outs= ide the MANET space, and as has been said before, it isn't a routing protoc= ol. So, I don't see a requirement to "make it fit" with 5444.=20 Regards, Stan >=20 > > I agree with the 'it's not a routing protocol' stance, and in my > > view it just adds unnecessary complexity, but I'm open to discussion > = on the extensibility issue. >=20 > What do you think is the difference in implementing a custom DLEP protoco= l language and a RFC5444 compliant one? In the second case, you might be ab= le to reuse code written for routing protocols, in the first one you have t= o do it from scratch. >=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 >=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 ulrich@herberg.name Thu Jul 5 09:29: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 E20B221F879A for ; Thu, 5 Jul 2012 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.767, 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 RALjIaUwCGpu for ; Thu, 5 Jul 2012 09:29:30 -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 CAEAD21F8724 for ; Thu, 5 Jul 2012 09:29:29 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13362974pbc.31 for ; Thu, 05 Jul 2012 09:29:43 -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=QErssUjRPetLGdtEe9qQuv/g4obwAU0hKKI47Bwg13s=; b=CD/U7oqb2rMIwsx/ZhvljXsBA6GNb4+elX1An0/oxMAQPofz95It7F97cAzVc5yUui dR/liOL6y800P9R1BE3U4TUiXXI3sY3Y+OFJOlZqMN4bFu3icNqPhR/bVp1pwA+1cng0 HbaUhUhx/i+G+aeMJpje5gbEmIx3wptY9vSJA= 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=QErssUjRPetLGdtEe9qQuv/g4obwAU0hKKI47Bwg13s=; b=ihHBg60d4drF96l5OeSY2wyWxQz8ZDl3q0Ej8ZffbJGYNuQo0sx4dGGmqnxuGzxcvW ubsoRNYbQarvc5GOPBNc6jMvb/z9LmyjpFEzD9YxlKwg2gBnpoJ7Spb6gB/ULV+DjAWB gfhXZf08i39gyA1PIByzy17y7XinZeCAGZDJbyacOji14d/BhvFW62lCaywhAn7ie/Tt nbWlavw4ChwPOoPAi4k0GXDCWYVv2U0tGo1v74FtiKd8n16FefgSmvKeOdP2n6xCDoRX qcYrkeeDr2f6Y963HFT9YPbKIDSYOXFajVr/noL/FsS/So9blj4UoKqc/Zs7Wn76eelE berA== MIME-Version: 1.0 Received: by 10.68.191.201 with SMTP id ha9mr28955616pbc.75.1341505782652; Thu, 05 Jul 2012 09:29:42 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Thu, 5 Jul 2012 09:29:42 -0700 (PDT) In-Reply-To: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> Date: Thu, 5 Jul 2012 09:29:42 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=e89a8ff1c3caa39f4f04c417a786 X-Gm-Message-State: ALoCoQkZX9ePSMMgPZNYmcBLRK3FHJbEM4+KWkx3g2UTJRrWc0uGbTGtTW98RltEy4BsINWRG2F5 Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:29:32 -0000 --e89a8ff1c3caa39f4f04c417a786 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support that view (all of the arguments, besides the "as an author of RFC5444" in the last one ;-). Best Ulrich On Thu, Jul 5, 2012 at 9:15 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I'm of the view > - There is no compulsion for DLEP to use 5444. The only compulsion is > 5498's that anything using the manet protocol/port uses 5444. > - 5444 is a flexible format. I believe (but no one has yet done and > published the work to support that) that 5444 could be used to represent > DLEP at least quite well, maybe very well. > - The currently proposed way to use 5444 to represent DLEP is not a very > good use of 5444 to do that. > - The pros and cons of a non-5444 representation of DLEP versus a good > 5444 representation of DLEP are hard to judge when neither is well-define= d > yet. > - A key question is future extensibility, adding new attributes. This is = a > strength of 5444. How much is it needed by DLEP? > - As an author of 5444 it's always gratifying when someone uses what you > helped create. But that's not a factor in the choice. > > -- > 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 (sratliff) > Sent: 05 July 2012 15:07 > To: Henning Rogge > Cc: > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: > > > On 07/04/2012 11:03 AM, John Dowdell wrote: > >> Based on our experience with using DLEP, I would request that it becom= es > >> mandatory to supply either an IPv4 or IPv6 address of the far end rout= er > >> during a Neighbour Up/Down message as that would speed up the routing > >> process. Total contact time between routers in a MANET could be very > >> short, and anything that helps speed the establishment of the connecti= on > >> is welcome. > > > > I would say it should be mandatory if the knowledge is present on the > DLEP-capable device. If you do not know the IP addresses of each partner, > you can still use DLEP and leave this job to the router. > > > >> As to the 5444 debate, I do not see the need for 5444 compliance in > >> DLEP. > > > > If we can find a good fit for all the DLEP use cases with RFC5444, I se= e > no need to specify another packet format for it. DLEP transports > information (many of them optional) about the local radio/modem and > information (also many of them optional) about connection between > radios/modems. This seems to be a very good description of the concept of > RFC5444. > > > > It also needs multiple kinds of messages, which makes message > aggregation into a single block of information an useful feature. > > > > At last, it needs to interact with routing protocols (especially MANET > protocols), which makes reusing rfc5444 a good thing. > > That's a red herring, IMO. The fact that DLEP should interact with routin= g > protocols does *not* mean that 5444 use is, in and of itself, "a good > thing". For example, the current DLEP offering I work on interacts with > OSPFv3. RFC 5444 compliance is actually a burden in that environment. Or, > at a bare minimum, it becomes "DLEP-specific". I believe DLEP has > applicability outside the MANET space, and as has been said before, it > isn't a routing protocol. So, I don't see a requirement to "make it fit" > with 5444. > > Regards, > Stan > > > > > > > > I agree with the 'it's not a routing protocol' stance, and in my > > > view it just adds unnecessary complexity, but I'm open to discussion = > > on the extensibility issue. > > > > What do you think is the difference in implementing a custom DLEP > protocol language and a RFC5444 compliant one? In the second case, you > might be able to reuse code written for routing protocols, in the first o= ne > you have to do it from scratch. > > > > 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. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --e89a8ff1c3caa39f4f04c417a786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support that view (all of the arguments, besides the "as an author o= f RFC5444" in the last one ;-).

Best
Ulrich

On Thu, Jul 5, 2012 at 9:15 AM, Dearlove, Christopher (U= K) <Chris.Dearlove@baesystems.com> wrote:
I'm of the view
- There is no compulsion for DLEP to use 5444. The only compulsion is 5498&= #39;s that anything using the manet protocol/port uses 5444.
- 5444 is a flexible format. I believe (but no one has yet done and publish= ed the work to support that) that 5444 could be used to represent DLEP at l= east quite well, maybe very well.
- The currently proposed way to use 5444 to represent DLEP is not a very go= od use of 5444 to do that.
- The pros and cons of a non-5444 representation of DLEP versus a good 5444= representation of DLEP are hard to judge when neither is well-defined yet.=
- A key question is future extensibility, adding new attributes. This is a = strength of 5444. How much is it needed by DLEP?
- As an author of 5444 it's always gratifying when someone uses what yo= u helped create. But that's not a factor in the choice.

--
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://ww= w.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 (sratliff)
Sent: 05 July 2012 15:07
To: Henning Rogge
Cc: <manet@ietf.org>
Subject: Re: [manet] Status of DLEP-draft at Cisco?

----------------------! 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 Jul 4, 2012, at 6:57 AM, H= enning Rogge wrote:

> On 07/04/2012 11:03 AM, John Dowdell wrote:
>> Based on our experience with using DLEP, I would request that it b= ecomes
>> mandatory to supply either an IPv4 or IPv6 address of the far end = router
>> during a Neighbour Up/Down message as that would speed up the rout= ing
>> process. Total contact time between routers in a MANET could be ve= ry
>> short, and anything that helps speed the establishment of the conn= ection
>> is welcome.
>
> I would say it should be mandatory if the knowledge is present on the = DLEP-capable device. If you do not know the IP addresses of each partner, y= ou can still use DLEP and leave this job to the router.
>
>> As to the 5444 debate, I do not see the need for 5444 compliance i= n
>> DLEP.
>
> If we can find a good fit for all the DLEP use cases with RFC5444, I s= ee no need to specify another packet format for it. DLEP transports informa= tion (many of them optional) about the local radio/modem and information (a= lso many of them optional) about connection between radios/modems. This see= ms to be a very good description of the concept of RFC5444.
>
> It also needs multiple kinds of messages, which makes message aggregat= ion into a single block of information an useful feature.
>
> At last, it needs to interact with routing protocols (especially MANET= protocols), which makes reusing rfc5444 a good thing.

That's a red herring, IMO. The fact that DLEP should interact with rout= ing protocols does *not* mean that 5444 use is, in and of itself, "a g= ood thing". For example, the current DLEP offering I work on interacts= with OSPFv3. RFC 5444 compliance is actually a burden in that environment.= Or, at a bare minimum, it becomes "DLEP-specific". I believe DLE= P has applicability outside the MANET space, and as has been said before, i= t isn't a routing protocol. So, I don't see a requirement to "= make it fit" with 5444.

Regards,
Stan



>
> > I agree with the 'it's not a routing protocol' stance= , and in my
> > view it just adds unnecessary complexity, but I'm open to dis= cussion > on the extensibility issue.
>
> What do you think is the difference in implementing a custom DLEP prot= ocol language and a RFC5444 compliant one? In the second case, you might be= able to reuse code written for routing protocols, in the first one you hav= e to do it from scratch.
>
> 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.rog= ge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D9= 44 F80D 4487 C67C 55EC CFE0
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


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

--e89a8ff1c3caa39f4f04c417a786-- From hrogge@googlemail.com Thu Jul 5 09:29: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 3FF5521F8703 for ; Thu, 5 Jul 2012 09:29:58 -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=[AWL=-0.000, 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 zrOP1JWwMzW3 for ; Thu, 5 Jul 2012 09:29:57 -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 464D421F8722 for ; Thu, 5 Jul 2012 09:29:57 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wy7so13362974pbc.31 for ; Thu, 05 Jul 2012 09:30: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=+GSHOof873AvMJf09G6I1l0G5OVOYsgmcW2oQZTgLck=; b=Hrd/K551jFqybtoUYPp5QXekfIIQKykRvtHYrmKBpCqAkuJWBhMaYkGyfgB13RMbaw 2UAQmb5pygljXOCtwlHPFalr2BvM66srmSz/GkJJy69BhxZusazFjLwG3S1fERFf4Tqc kG8NimnDXSyuLyHxjM6JYVqPazxZ4SXSZ03fhjs4h1cA6fxqJfFuRtCZ8/OzzMI7tX4G rEitrb0Oc8bPNZPmr6aP/niV11yAjlxoarkueUY3vg/HTp4ffbl3P08DCNjxmptkHnan d+QMceCdDupYKGGnWSLR2l6hc86H97Su8GnlhrWqKw6vUauR1coa13cLQfDctRe+j53c IY2g== Received: by 10.68.129.198 with SMTP id ny6mr28865027pbb.22.1341505808511; Thu, 05 Jul 2012 09:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 09:29:48 -0700 (PDT) In-Reply-To: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> From: Henning Rogge Date: Thu, 5 Jul 2012 18:29:48 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:29:58 -0000 On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) wrote: > I'm of the view > - There is no compulsion for DLEP to use 5444. The only compulsion is 549= 8's that anything using the manet protocol/port uses 5444. Interesting question... do we need a different port for the DLEP protocol or can we just use what RFC5498 provides? If DLEP use its own message type (and most likely work on a different interface), it should not make any trouble with existing users. Otherwise we would need an UDP port and an IP multicast group for DLEP. > - 5444 is a flexible format. I believe (but no one has yet done and publi= shed the work to support that) that 5444 could be used to represent DLEP at= least quite well, maybe very well. I had an early draft for this, but I will work on an update. > - The currently proposed way to use 5444 to represent DLEP is not a very = good use of 5444 to do that. I think most of us agree to this. > - The pros and cons of a non-5444 representation of DLEP versus a good 54= 44 representation of DLEP are hard to judge when neither is well-defined ye= t. > - A key question is future extensibility, adding new attributes. This is = a strength of 5444. How much is it needed by DLEP? First of course would be adding of more routing metrics and statistical data from layer 2. My second argument for RFC5444 is that DLEP is primarily about delivering layer-2 data for networks/interfaces and layer-2 data for neighbors of interfaces. This maps very well on the concept of RFC5444 messages with message- and address-TLVs. There is also the discussion about optional features like the ARP-table entry generation through layer-2 transmitted IP-Addresses. Another point is the existence of multi-line radios, which need to be considered. A last argument for using something as flexible as RFC5444 is that the development Software Defined Radios is still fluid, especially with all the ideas about how to use them as Cognitive Radios later. Most likely we will have a much better view what we need to add in a few years, so having enough flexibility available without breaking the protocol by moving to "version 2/3" is a good thing. It would be of course possible to build a packet format that can do all of this without being RFC5444. But I don't think building another new packet format is a good way to reduce the complexity of a protocol. We should work to reduce complexity of DLEP (without killing features), not adding to it. Henning Rogge > - As an author of 5444 it's always gratifying when someone uses what you = helped create. But that's not a factor in the choice. > > -- > 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 (sratliff) > Sent: 05 July 2012 15:07 > To: Henning Rogge > Cc: > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: > >> On 07/04/2012 11:03 AM, John Dowdell wrote: >>> Based on our experience with using DLEP, I would request that it become= s >>> mandatory to supply either an IPv4 or IPv6 address of the far end route= r >>> during a Neighbour Up/Down message as that would speed up the routing >>> process. Total contact time between routers in a MANET could be very >>> short, and anything that helps speed the establishment of the connectio= n >>> is welcome. >> >> I would say it should be mandatory if the knowledge is present on the DL= EP-capable device. If you do not know the IP addresses of each partner, you= can still use DLEP and leave this job to the router. >> >>> As to the 5444 debate, I do not see the need for 5444 compliance in >>> DLEP. >> >> If we can find a good fit for all the DLEP use cases with RFC5444, I see= no need to specify another packet format for it. DLEP transports informati= on (many of them optional) about the local radio/modem and information (als= o many of them optional) about connection between radios/modems. This seems= to be a very good description of the concept of RFC5444. >> >> It also needs multiple kinds of messages, which makes message aggregatio= n into a single block of information an useful feature. >> >> At last, it needs to interact with routing protocols (especially MANET p= rotocols), which makes reusing rfc5444 a good thing. > > That's a red herring, IMO. The fact that DLEP should interact with routin= g protocols does *not* mean that 5444 use is, in and of itself, "a good thi= ng". For example, the current DLEP offering I work on interacts with OSPFv3= . RFC 5444 compliance is actually a burden in that environment. Or, at a ba= re minimum, it becomes "DLEP-specific". I believe DLEP has applicability ou= tside the MANET space, and as has been said before, it isn't a routing prot= ocol. So, I don't see a requirement to "make it fit" with 5444. > > Regards, > Stan > > > >> >> > I agree with the 'it's not a routing protocol' stance, and in my >> > view it just adds unnecessary complexity, but I'm open to discussion >= on the extensibility issue. >> >> What do you think is the difference in implementing a custom DLEP protoc= ol language and a RFC5444 compliant one? In the second case, you might be a= ble to reuse code written for routing protocols, in the first one you have = to do it from scratch. >> >> 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. > ******************************************************************** > > _______________________________________________ > 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 Thu Jul 5 09:38: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 9C80D21F86F8 for ; Thu, 5 Jul 2012 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 BR6yuWsv3D-u for ; Thu, 5 Jul 2012 09:38: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 86BFE21F8602 for ; Thu, 5 Jul 2012 09:38:10 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6125597vbb.31 for ; Thu, 05 Jul 2012 09:38:19 -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=laU3bSdratBekQvFgWW6S+jytOReVflFvYhE2w4C9N4=; b=Djj1+bikDkvK+83eFHv4TeNXqmhKpfalpsH4aOUV+pWKqgtySxU/e9WKFwVZrRdwZR YPS/UXiEnRzh+PgcuV3juCF7Lmcda80bFzwodza2Fdo+IpwsrL9+2E0E0smWugRl9lmv tnyZD2u67tZg8UZb2hwG2gkVjjKtTHCncaDh4EkQ0i0CoaUCACjwQfVvP/E0mZa4MSaC SZgNpFbSekqso04wUrLU+WIixh26GnhPVfvnlxaOhr0tcHy4BUdtSkfd/RB3JHeIZNhF OUs066n5AJS4e96oCM3gyFOwp6t77mD9Izns/zwkwKlkwIA/70GlSBdMCRH0v95D4P+H McRA== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr10939728vdb.10.1341506299808; Thu, 05 Jul 2012 09:38:19 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 09:38:19 -0700 (PDT) Date: Thu, 5 Jul 2012 18:38:19 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:38:24 -0000 +1 As a group participant, we want most MANET protocols to use RFC5498, but as I said before the messaging format is not the main issue (we can if needed to update 5444 if helps), the main issue is functionality, however, if not using RFC5498 there should be a good reason why? by the way DSRv2 draft will be using RFC5444 and RFC5498. Regards AB ===== > I'm of the view > - There is no compulsion for DLEP to use 5444. The only compulsion is > 5498's that anything using the manet protocol/port uses 5444. > - 5444 is a flexible format. I believe (but no one has yet done and > published the work to support that) that 5444 could be used to > represent DLEP at least quite well, maybe very well. > - The currently proposed way to use 5444 to represent DLEP is not a > very good use of 5444 to do that. > - The pros and cons of a non-5444 representation of DLEP versus a good > 5444 representation of DLEP are hard to judge when neither is > well-defined yet. > - A key question is future extensibility, adding new attributes. This > is a strength of 5444. How much is it needed by DLEP? > - As an author of 5444 it's always gratifying when someone uses what > you helped create. But that's not a factor in the choice. > > -- > 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 > > 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 at ietf.org [mailto:manet-bounces at ietf.org] On > Behalf Of Stan Ratliff (sratliff) > Sent: 05 July 2012 15:07 > To: Henning Rogge > Cc: > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! 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 Chris.Dearlove@baesystems.com Thu Jul 5 10:12: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 6BACD21F85A1 for ; Thu, 5 Jul 2012 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 bCy3V-Xjt8ic for ; Thu, 5 Jul 2012 10:12:57 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 75A2821F8573 for ; Thu, 5 Jul 2012 10:12:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="252547104" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 05 Jul 2012 18:13:10 +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 q65HD9MP008079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 18:13:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 5 Jul 2012 18:13:09 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fkJPtrdHUq0SlS58HjbKfcgAH9JaAAAJa84AAOOkpgAAGTm9g///1bgD//+TAQA== Date: Thu, 5 Jul 2012 17:13:08 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@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: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:12:58 -0000 We can't use the port (I'll ignore protocol for this email) that 5498 defin= es for non 5444 formatted traffic without violating 5444, and breaking the = whole multiplexing method that it mandates (although we were forced to put = into 5444 rather than it being in its proper place in 5498 directly). The 5= 444/5498 model is that a multiplexing entity sits on that port. It gets a p= acket, parses it as a 5444 packet, and then passes the messages to whatever= has registered as that message owner. (I'm simplifying here, for example I= 'm not discussing the packet TLV block, or protocols A modifying protocol B= 's messages.) If a non-5444 packet arrives on that port than the multiplexe= r should reject it. Yes, you could then send that somewhere else, create a = new packet format guaranteed to fail to parse as 5444 and so on. But that a= pproach and good design live on different continents. --=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: 05 July 2012 17:30 To: Dearlove, Christopher (UK) Cc: Stan Ratliff (sratliff); Henning Rogge; Subject: Re: [manet] Status of DLEP-draft at Cisco? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) wrote: > I'm of the view > - There is no compulsion for DLEP to use 5444. The only compulsion is 549= 8's that anything using the manet protocol/port uses 5444. Interesting question... do we need a different port for the DLEP protocol or can we just use what RFC5498 provides? If DLEP use its own message type (and most likely work on a different interface), it should not make any trouble with existing users. Otherwise we would need an UDP port and an IP multicast group for DLEP. > - 5444 is a flexible format. I believe (but no one has yet done and publi= shed the work to support that) that 5444 could be used to represent DLEP at= least quite well, maybe very well. I had an early draft for this, but I will work on an update. > - The currently proposed way to use 5444 to represent DLEP is not a very = good use of 5444 to do that. I think most of us agree to this. > - The pros and cons of a non-5444 representation of DLEP versus a good 54= 44 representation of DLEP are hard to judge when neither is well-defined ye= t. > - A key question is future extensibility, adding new attributes. This is = a strength of 5444. How much is it needed by DLEP? First of course would be adding of more routing metrics and statistical data from layer 2. My second argument for RFC5444 is that DLEP is primarily about delivering layer-2 data for networks/interfaces and layer-2 data for neighbors of interfaces. This maps very well on the concept of RFC5444 messages with message- and address-TLVs. There is also the discussion about optional features like the ARP-table entry generation through layer-2 transmitted IP-Addresses. Another point is the existence of multi-line radios, which need to be considered. A last argument for using something as flexible as RFC5444 is that the development Software Defined Radios is still fluid, especially with all the ideas about how to use them as Cognitive Radios later. Most likely we will have a much better view what we need to add in a few years, so having enough flexibility available without breaking the protocol by moving to "version 2/3" is a good thing. It would be of course possible to build a packet format that can do all of this without being RFC5444. But I don't think building another new packet format is a good way to reduce the complexity of a protocol. We should work to reduce complexity of DLEP (without killing features), not adding to it. Henning Rogge > - As an author of 5444 it's always gratifying when someone uses what you = helped create. But that's not a factor in the choice. > > -- > 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 (sratliff) > Sent: 05 July 2012 15:07 > To: Henning Rogge > Cc: > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: > >> On 07/04/2012 11:03 AM, John Dowdell wrote: >>> Based on our experience with using DLEP, I would request that it become= s >>> mandatory to supply either an IPv4 or IPv6 address of the far end route= r >>> during a Neighbour Up/Down message as that would speed up the routing >>> process. Total contact time between routers in a MANET could be very >>> short, and anything that helps speed the establishment of the connectio= n >>> is welcome. >> >> I would say it should be mandatory if the knowledge is present on the DL= EP-capable device. If you do not know the IP addresses of each partner, you= can still use DLEP and leave this job to the router. >> >>> As to the 5444 debate, I do not see the need for 5444 compliance in >>> DLEP. >> >> If we can find a good fit for all the DLEP use cases with RFC5444, I see= no need to specify another packet format for it. DLEP transports informati= on (many of them optional) about the local radio/modem and information (als= o many of them optional) about connection between radios/modems. This seems= to be a very good description of the concept of RFC5444. >> >> It also needs multiple kinds of messages, which makes message aggregatio= n into a single block of information an useful feature. >> >> At last, it needs to interact with routing protocols (especially MANET p= rotocols), which makes reusing rfc5444 a good thing. > > That's a red herring, IMO. The fact that DLEP should interact with routin= g protocols does *not* mean that 5444 use is, in and of itself, "a good thi= ng". For example, the current DLEP offering I work on interacts with OSPFv3= . RFC 5444 compliance is actually a burden in that environment. Or, at a ba= re minimum, it becomes "DLEP-specific". I believe DLEP has applicability ou= tside the MANET space, and as has been said before, it isn't a routing prot= ocol. So, I don't see a requirement to "make it fit" with 5444. > > Regards, > Stan > > > >> >> > I agree with the 'it's not a routing protocol' stance, and in my >> > view it just adds unnecessary complexity, but I'm open to discussion >= on the extensibility issue. >> >> What do you think is the difference in implementing a custom DLEP protoc= ol language and a RFC5444 compliant one? In the second case, you might be a= ble to reuse code written for routing protocols, in the first one you have = to do it from scratch. >> >> 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. > ******************************************************************** > > _______________________________________________ > 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 Thu Jul 5 10:18: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 71C6C21F864A for ; Thu, 5 Jul 2012 10:18:06 -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 Mlc7CrjRJzcB for ; Thu, 5 Jul 2012 10:18:05 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11D6021F85BB for ; Thu, 5 Jul 2012 10:18:04 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8499693ghb.31 for ; Thu, 05 Jul 2012 10:18: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=QT5miUokCffTIyM2WSEZQftX3b8LQ/3Oc/wsSKr0YXs=; b=GGA5gd4IJ+HirAK1ivHj4mlmnn76I8qkCLVxLAslNVgEmphBUe0lM67adkktTExGk+ beVrvb1g/8ovcRou2MS9Ms+wIo8zgP9vZ3Wc706MPy7Gu+xVZS1vU31UuNdmCGV2hRoq XStGjd/EleFdgofbU6zQ5tCGz2kSfEC2flPpn7h7NGglQTIrATdMVeNGgkWZfGYMxrkI e5I64cPY+DHGONh1Duj363zNSZ1hwXGMWpZVOTTKp9v9+LSr9ftyRFCAWYGDYZqh3Zb5 NHiq3swvwihytD5Dsqd3qTEgOjPR8EJJfe7Sdlnso6TrIeefK+tW46yuAxKcbUCNdPY5 CNLQ== Received: by 10.66.79.8 with SMTP id f8mr38678612pax.81.1341508697852; Thu, 05 Jul 2012 10:18:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 10:17:57 -0700 (PDT) In-Reply-To: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> From: Henning Rogge Date: Thu, 5 Jul 2012 19:17:57 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:18:06 -0000 On Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) wrote: > We can't use the port (I'll ignore protocol for this email) that 5498 def= ines for non 5444 formatted traffic without violating 5444, and breaking th= e whole multiplexing method that it mandates (although we were forced to pu= t into 5444 rather than it being in its proper place in 5498 directly). The= 5444/5498 model is that a multiplexing entity sits on that port. It gets a= packet, parses it as a 5444 packet, and then passes the messages to whatev= er has registered as that message owner. (I'm simplifying here, for example= I'm not discussing the packet TLV block, or protocols A modifying protocol= B's messages.) If a non-5444 packet arrives on that port than the multiple= xer should reject it. Yes, you could then send that somewhere else, create = a new packet format guaranteed to fail to parse as 5444 and so on. But that= approach and good design live on different continents. I was thinking about full compliant RFC5444 messages. There can be multiple receivers on the same UDP multicast port. So in either case (both with and without RFC5444 in DLEP) DLEP needs it own port and Multicast group. Henning Rogge > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 05 July 2012 17:30 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); Henning Rogge; > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) > wrote: >> I'm of the view >> - There is no compulsion for DLEP to use 5444. The only compulsion is 54= 98's that anything using the manet protocol/port uses 5444. > > Interesting question... do we need a different port for the DLEP > protocol or can we just use what RFC5498 provides? If DLEP use its own > message type (and most likely work on a different interface), it > should not make any trouble with existing users. Otherwise we would > need an UDP port and an IP multicast group for DLEP. > >> - 5444 is a flexible format. I believe (but no one has yet done and publ= ished the work to support that) that 5444 could be used to represent DLEP a= t least quite well, maybe very well. > > I had an early draft for this, but I will work on an update. > >> - The currently proposed way to use 5444 to represent DLEP is not a very= good use of 5444 to do that. > > I think most of us agree to this. > >> - The pros and cons of a non-5444 representation of DLEP versus a good 5= 444 representation of DLEP are hard to judge when neither is well-defined y= et. > >> - A key question is future extensibility, adding new attributes. This is= a strength of 5444. How much is it needed by DLEP? > First of course would be adding of more routing metrics and > statistical data from layer 2. > My second argument for RFC5444 is that DLEP is primarily about > delivering layer-2 data for networks/interfaces and layer-2 data for > neighbors of interfaces. This maps very well on the concept of RFC5444 > messages with message- and address-TLVs. > > There is also the discussion about optional features like the > ARP-table entry generation through layer-2 transmitted IP-Addresses. > Another point is the existence of multi-line radios, which need to be > considered. > > A last argument for using something as flexible as RFC5444 is that the > development Software Defined Radios is still fluid, especially with > all the ideas about how to use them as Cognitive Radios later. Most > likely we will have a much better view what we need to add in a few > years, so having enough flexibility available without breaking the > protocol by moving to "version 2/3" is a good thing. > > It would be of course possible to build a packet format that can do > all of this without being RFC5444. But I don't think building another > new packet format is a good way to reduce the complexity of a > protocol. We should work to reduce complexity of DLEP (without killing > features), not adding to it. > > Henning Rogge > >> - As an author of 5444 it's always gratifying when someone uses what you= helped create. But that's not a factor in the choice. >> >> -- >> 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 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 Stan Ratliff (sratliff) >> Sent: 05 July 2012 15:07 >> To: Henning Rogge >> Cc: >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >> >> ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >> >>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>> Based on our experience with using DLEP, I would request that it becom= es >>>> mandatory to supply either an IPv4 or IPv6 address of the far end rout= er >>>> during a Neighbour Up/Down message as that would speed up the routing >>>> process. Total contact time between routers in a MANET could be very >>>> short, and anything that helps speed the establishment of the connecti= on >>>> is welcome. >>> >>> I would say it should be mandatory if the knowledge is present on the D= LEP-capable device. If you do not know the IP addresses of each partner, yo= u can still use DLEP and leave this job to the router. >>> >>>> As to the 5444 debate, I do not see the need for 5444 compliance in >>>> DLEP. >>> >>> If we can find a good fit for all the DLEP use cases with RFC5444, I se= e no need to specify another packet format for it. DLEP transports informat= ion (many of them optional) about the local radio/modem and information (al= so many of them optional) about connection between radios/modems. This seem= s to be a very good description of the concept of RFC5444. >>> >>> It also needs multiple kinds of messages, which makes message aggregati= on into a single block of information an useful feature. >>> >>> At last, it needs to interact with routing protocols (especially MANET = protocols), which makes reusing rfc5444 a good thing. >> >> That's a red herring, IMO. The fact that DLEP should interact with routi= ng protocols does *not* mean that 5444 use is, in and of itself, "a good th= ing". For example, the current DLEP offering I work on interacts with OSPFv= 3. RFC 5444 compliance is actually a burden in that environment. Or, at a b= are minimum, it becomes "DLEP-specific". I believe DLEP has applicability o= utside the MANET space, and as has been said before, it isn't a routing pro= tocol. So, I don't see a requirement to "make it fit" with 5444. >> >> Regards, >> Stan >> >> >> >>> >>> > I agree with the 'it's not a routing protocol' stance, and in my >>> > view it just adds unnecessary complexity, but I'm open to discussion = > on the extensibility issue. >>> >>> What do you think is the difference in implementing a custom DLEP proto= col language and a RFC5444 compliant one? In the second case, you might be = able to reuse code written for routing protocols, in the first one you have= to do it from scratch. >>> >>> 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. >> ******************************************************************** >> >> _______________________________________________ >> 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 Chris.Dearlove@baesystems.com Thu Jul 5 10:24: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 F3E3C21F8717 for ; Thu, 5 Jul 2012 10:24:54 -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=[AWL=0.600, 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 nN4ts0B0hfpO for ; Thu, 5 Jul 2012 10:24:53 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0537021F8697 for ; Thu, 5 Jul 2012 10:24:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="252549454" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 05 Jul 2012 18:25:06 +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 q65HP6A0014309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 18:25:06 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 5 Jul 2012 18:25:05 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fkJPtrdHUq0SlS58HjbKfcgAH9JaAAAJa84AAOOkpgAAGTm9g///1bgD//+TAQIAAKLSA///uJUA= Date: Thu, 5 Jul 2012 17:25:04 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@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: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:24:55 -0000 I can see DLEP needing its own multicast group, that's quite different from= usual MANET case. I'm not quite so clear on why a different port is necess= ary if using 5444 and its own message type. (A different port is acceptable= , and may even be preferable, I just haven't understood why necessary.) --=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: 05 July 2012 18:18 To: Dearlove, Christopher (UK) Cc: Stan Ratliff (sratliff); Henning Rogge; Subject: Re: [manet] Status of DLEP-draft at Cisco? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) wrote: > We can't use the port (I'll ignore protocol for this email) that 5498 def= ines for non 5444 formatted traffic without violating 5444, and breaking th= e whole multiplexing method that it mandates (although we were forced to pu= t into 5444 rather than it being in its proper place in 5498 directly). The= 5444/5498 model is that a multiplexing entity sits on that port. It gets a= packet, parses it as a 5444 packet, and then passes the messages to whatev= er has registered as that message owner. (I'm simplifying here, for example= I'm not discussing the packet TLV block, or protocols A modifying protocol= B's messages.) If a non-5444 packet arrives on that port than the multiple= xer should reject it. Yes, you could then send that somewhere else, create = a new packet format guaranteed to fail to parse as 5444 and so on. But that= approach and good design live on different continents. I was thinking about full compliant RFC5444 messages. There can be multiple receivers on the same UDP multicast port. So in either case (both with and without RFC5444 in DLEP) DLEP needs it own port and Multicast group. Henning Rogge > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Henning Rogge [mailto:hrogge@googlemail.com] > Sent: 05 July 2012 17:30 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); Henning Rogge; > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) > wrote: >> I'm of the view >> - There is no compulsion for DLEP to use 5444. The only compulsion is 54= 98's that anything using the manet protocol/port uses 5444. > > Interesting question... do we need a different port for the DLEP > protocol or can we just use what RFC5498 provides? If DLEP use its own > message type (and most likely work on a different interface), it > should not make any trouble with existing users. Otherwise we would > need an UDP port and an IP multicast group for DLEP. > >> - 5444 is a flexible format. I believe (but no one has yet done and publ= ished the work to support that) that 5444 could be used to represent DLEP a= t least quite well, maybe very well. > > I had an early draft for this, but I will work on an update. > >> - The currently proposed way to use 5444 to represent DLEP is not a very= good use of 5444 to do that. > > I think most of us agree to this. > >> - The pros and cons of a non-5444 representation of DLEP versus a good 5= 444 representation of DLEP are hard to judge when neither is well-defined y= et. > >> - A key question is future extensibility, adding new attributes. This is= a strength of 5444. How much is it needed by DLEP? > First of course would be adding of more routing metrics and > statistical data from layer 2. > My second argument for RFC5444 is that DLEP is primarily about > delivering layer-2 data for networks/interfaces and layer-2 data for > neighbors of interfaces. This maps very well on the concept of RFC5444 > messages with message- and address-TLVs. > > There is also the discussion about optional features like the > ARP-table entry generation through layer-2 transmitted IP-Addresses. > Another point is the existence of multi-line radios, which need to be > considered. > > A last argument for using something as flexible as RFC5444 is that the > development Software Defined Radios is still fluid, especially with > all the ideas about how to use them as Cognitive Radios later. Most > likely we will have a much better view what we need to add in a few > years, so having enough flexibility available without breaking the > protocol by moving to "version 2/3" is a good thing. > > It would be of course possible to build a packet format that can do > all of this without being RFC5444. But I don't think building another > new packet format is a good way to reduce the complexity of a > protocol. We should work to reduce complexity of DLEP (without killing > features), not adding to it. > > Henning Rogge > >> - As an author of 5444 it's always gratifying when someone uses what you= helped create. But that's not a factor in the choice. >> >> -- >> 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 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 Stan Ratliff (sratliff) >> Sent: 05 July 2012 15:07 >> To: Henning Rogge >> Cc: >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >> >> ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >> >>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>> Based on our experience with using DLEP, I would request that it becom= es >>>> mandatory to supply either an IPv4 or IPv6 address of the far end rout= er >>>> during a Neighbour Up/Down message as that would speed up the routing >>>> process. Total contact time between routers in a MANET could be very >>>> short, and anything that helps speed the establishment of the connecti= on >>>> is welcome. >>> >>> I would say it should be mandatory if the knowledge is present on the D= LEP-capable device. If you do not know the IP addresses of each partner, yo= u can still use DLEP and leave this job to the router. >>> >>>> As to the 5444 debate, I do not see the need for 5444 compliance in >>>> DLEP. >>> >>> If we can find a good fit for all the DLEP use cases with RFC5444, I se= e no need to specify another packet format for it. DLEP transports informat= ion (many of them optional) about the local radio/modem and information (al= so many of them optional) about connection between radios/modems. This seem= s to be a very good description of the concept of RFC5444. >>> >>> It also needs multiple kinds of messages, which makes message aggregati= on into a single block of information an useful feature. >>> >>> At last, it needs to interact with routing protocols (especially MANET = protocols), which makes reusing rfc5444 a good thing. >> >> That's a red herring, IMO. The fact that DLEP should interact with routi= ng protocols does *not* mean that 5444 use is, in and of itself, "a good th= ing". For example, the current DLEP offering I work on interacts with OSPFv= 3. RFC 5444 compliance is actually a burden in that environment. Or, at a b= are minimum, it becomes "DLEP-specific". I believe DLEP has applicability o= utside the MANET space, and as has been said before, it isn't a routing pro= tocol. So, I don't see a requirement to "make it fit" with 5444. >> >> Regards, >> Stan >> >> >> >>> >>> > I agree with the 'it's not a routing protocol' stance, and in my >>> > view it just adds unnecessary complexity, but I'm open to discussion = > on the extensibility issue. >>> >>> What do you think is the difference in implementing a custom DLEP proto= col language and a RFC5444 compliant one? In the second case, you might be = able to reuse code written for routing protocols, in the first one you have= to do it from scratch. >>> >>> 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. >> ******************************************************************** >> >> _______________________________________________ >> 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 hrogge@googlemail.com Thu Jul 5 10:27: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 97F8421F879A for ; Thu, 5 Jul 2012 10:27:07 -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 6wlfPgp+h4vJ for ; Thu, 5 Jul 2012 10:27:06 -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 5E63B21F8795 for ; Thu, 5 Jul 2012 10:27:06 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13431465pbc.31 for ; Thu, 05 Jul 2012 10:27: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:content-transfer-encoding; bh=lgUB/9o29HfKAKtvh1GOJF7z7ttXu6UbBSnkYdn3hZ0=; b=m+m13a2OK4HoIq0tQQyaxDLADWC2FPsiDia4Vl1frY/gIaAYTBHQViU1n4+XWzCe7t niOT7jDwjKnBqxbUFaAyNCDNCSWud+6lcqwNegSKONrg3KnKDqyD3Wq0eEta6VqRHOFF md/7GHDGmSv8xvlz3NmwB6bLMwqZkNnWIvEDQGs4iQwE+XMlmsmQyKuYKXJFjIG7dmOG 21QlfuCkxZRsYTjr/s3eSegMOTO8XqJMx8SwnswjffsfdgrQ+MXoEz141CjuJ0KTHz0T R6+mUu3bl1AGB/nKK16w1IouRpCj02JnBQQhM48c2rzWc3e7fC/FSi6V+H7ikVOh0MNb 9AqQ== Received: by 10.68.129.198 with SMTP id ny6mr29228892pbb.22.1341509240125; Thu, 05 Jul 2012 10:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 10:26:59 -0700 (PDT) In-Reply-To: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> From: Henning Rogge Date: Thu, 5 Jul 2012 19:26:59 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:27:07 -0000 hm... I thought you just said we couldn't reuse the MANET port, even if DLEP becomes completely RFC5444 compliant? Maybe I misunderstood you... Henning Rogge On Thu, Jul 5, 2012 at 7:25 PM, Dearlove, Christopher (UK) wrote: > I can see DLEP needing its own multicast group, that's quite different fr= om usual MANET case. I'm not quite so clear on why a different port is nece= ssary if using 5444 and its own message type. (A different port is acceptab= le, and may even be preferable, I just haven't understood why necessary.) > > -- > 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: 05 July 2012 18:18 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); Henning Rogge; > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) > wrote: >> We can't use the port (I'll ignore protocol for this email) that 5498 de= fines for non 5444 formatted traffic without violating 5444, and breaking t= he whole multiplexing method that it mandates (although we were forced to p= ut into 5444 rather than it being in its proper place in 5498 directly). Th= e 5444/5498 model is that a multiplexing entity sits on that port. It gets = a packet, parses it as a 5444 packet, and then passes the messages to whate= ver has registered as that message owner. (I'm simplifying here, for exampl= e I'm not discussing the packet TLV block, or protocols A modifying protoco= l B's messages.) If a non-5444 packet arrives on that port than the multipl= exer should reject it. Yes, you could then send that somewhere else, create= a new packet format guaranteed to fail to parse as 5444 and so on. But tha= t approach and good design live on different continents. > > I was thinking about full compliant RFC5444 messages. There can be > multiple receivers on the same UDP multicast port. > > So in either case (both with and without RFC5444 in DLEP) DLEP needs > it own port and Multicast group. > > Henning Rogge > > >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 05 July 2012 17:30 >> To: Dearlove, Christopher (UK) >> Cc: Stan Ratliff (sratliff); Henning Rogge; >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) >> wrote: >>> I'm of the view >>> - There is no compulsion for DLEP to use 5444. The only compulsion is 5= 498's that anything using the manet protocol/port uses 5444. >> >> Interesting question... do we need a different port for the DLEP >> protocol or can we just use what RFC5498 provides? If DLEP use its own >> message type (and most likely work on a different interface), it >> should not make any trouble with existing users. Otherwise we would >> need an UDP port and an IP multicast group for DLEP. >> >>> - 5444 is a flexible format. I believe (but no one has yet done and pub= lished the work to support that) that 5444 could be used to represent DLEP = at least quite well, maybe very well. >> >> I had an early draft for this, but I will work on an update. >> >>> - The currently proposed way to use 5444 to represent DLEP is not a ver= y good use of 5444 to do that. >> >> I think most of us agree to this. >> >>> - The pros and cons of a non-5444 representation of DLEP versus a good = 5444 representation of DLEP are hard to judge when neither is well-defined = yet. >> >>> - A key question is future extensibility, adding new attributes. This i= s a strength of 5444. How much is it needed by DLEP? >> First of course would be adding of more routing metrics and >> statistical data from layer 2. >> My second argument for RFC5444 is that DLEP is primarily about >> delivering layer-2 data for networks/interfaces and layer-2 data for >> neighbors of interfaces. This maps very well on the concept of RFC5444 >> messages with message- and address-TLVs. >> >> There is also the discussion about optional features like the >> ARP-table entry generation through layer-2 transmitted IP-Addresses. >> Another point is the existence of multi-line radios, which need to be >> considered. >> >> A last argument for using something as flexible as RFC5444 is that the >> development Software Defined Radios is still fluid, especially with >> all the ideas about how to use them as Cognitive Radios later. Most >> likely we will have a much better view what we need to add in a few >> years, so having enough flexibility available without breaking the >> protocol by moving to "version 2/3" is a good thing. >> >> It would be of course possible to build a packet format that can do >> all of this without being RFC5444. But I don't think building another >> new packet format is a good way to reduce the complexity of a >> protocol. We should work to reduce complexity of DLEP (without killing >> features), not adding to it. >> >> Henning Rogge >> >>> - As an author of 5444 it's always gratifying when someone uses what yo= u helped create. But that's not a factor in the choice. >>> >>> -- >>> 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 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 Stan Ratliff (sratliff) >>> Sent: 05 July 2012 15:07 >>> To: Henning Rogge >>> Cc: >>> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>> >>> ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >>> >>>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>>> Based on our experience with using DLEP, I would request that it beco= mes >>>>> mandatory to supply either an IPv4 or IPv6 address of the far end rou= ter >>>>> during a Neighbour Up/Down message as that would speed up the routing >>>>> process. Total contact time between routers in a MANET could be very >>>>> short, and anything that helps speed the establishment of the connect= ion >>>>> is welcome. >>>> >>>> I would say it should be mandatory if the knowledge is present on the = DLEP-capable device. If you do not know the IP addresses of each partner, y= ou can still use DLEP and leave this job to the router. >>>> >>>>> As to the 5444 debate, I do not see the need for 5444 compliance in >>>>> DLEP. >>>> >>>> If we can find a good fit for all the DLEP use cases with RFC5444, I s= ee no need to specify another packet format for it. DLEP transports informa= tion (many of them optional) about the local radio/modem and information (a= lso many of them optional) about connection between radios/modems. This see= ms to be a very good description of the concept of RFC5444. >>>> >>>> It also needs multiple kinds of messages, which makes message aggregat= ion into a single block of information an useful feature. >>>> >>>> At last, it needs to interact with routing protocols (especially MANET= protocols), which makes reusing rfc5444 a good thing. >>> >>> That's a red herring, IMO. The fact that DLEP should interact with rout= ing protocols does *not* mean that 5444 use is, in and of itself, "a good t= hing". For example, the current DLEP offering I work on interacts with OSPF= v3. RFC 5444 compliance is actually a burden in that environment. Or, at a = bare minimum, it becomes "DLEP-specific". I believe DLEP has applicability = outside the MANET space, and as has been said before, it isn't a routing pr= otocol. So, I don't see a requirement to "make it fit" with 5444. >>> >>> Regards, >>> Stan >>> >>> >>> >>>> >>>> > I agree with the 'it's not a routing protocol' stance, and in my >>>> > view it just adds unnecessary complexity, but I'm open to discussion= > on the extensibility issue. >>>> >>>> What do you think is the difference in implementing a custom DLEP prot= ocol language and a RFC5444 compliant one? In the second case, you might be= able to reuse code written for routing protocols, in the first one you hav= e to do it from scratch. >>>> >>>> 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. >>> ******************************************************************** >>> >>> _______________________________________________ >>> 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." > --=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 Jul 5 10:36: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 10ABE21F8630 for ; Thu, 5 Jul 2012 10:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.546, 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 MEMt9ZiZ3r5c for ; Thu, 5 Jul 2012 10:35:58 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 714C521F85C0 for ; Thu, 5 Jul 2012 10:35:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="252551029" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 05 Jul 2012 18:36:10 +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 q65Ha9lb019966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 18:36:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Thu, 5 Jul 2012 18:36:09 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fkJPtrdHUq0SlS58HjbKfcgAH9JaAAAJa84AAOOkpgAAGTm9g///1bgD//+TAQIAAKLSA///uJUCAABRhgP//7XgQ Date: Thu, 5 Jul 2012 17:36:08 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@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: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:36:00 -0000 That's not what I intended to say. (I may not have been clear, I'm not goin= g to check.) I'm not saying definitely you can use the manet port, just tha= t I can't see why not. --=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: 05 July 2012 18:27 To: Dearlove, Christopher (UK) Cc: Stan Ratliff (sratliff); Henning Rogge; Subject: Re: [manet] Status of DLEP-draft at Cisco? ----------------------! 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. -------------------------------------------------------- hm... I thought you just said we couldn't reuse the MANET port, even if DLEP becomes completely RFC5444 compliant? Maybe I misunderstood you... Henning Rogge On Thu, Jul 5, 2012 at 7:25 PM, Dearlove, Christopher (UK) wrote: > I can see DLEP needing its own multicast group, that's quite different fr= om usual MANET case. I'm not quite so clear on why a different port is nece= ssary if using 5444 and its own message type. (A different port is acceptab= le, and may even be preferable, I just haven't understood why necessary.) > > -- > 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: 05 July 2012 18:18 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); Henning Rogge; > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > On Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) > wrote: >> We can't use the port (I'll ignore protocol for this email) that 5498 de= fines for non 5444 formatted traffic without violating 5444, and breaking t= he whole multiplexing method that it mandates (although we were forced to p= ut into 5444 rather than it being in its proper place in 5498 directly). Th= e 5444/5498 model is that a multiplexing entity sits on that port. It gets = a packet, parses it as a 5444 packet, and then passes the messages to whate= ver has registered as that message owner. (I'm simplifying here, for exampl= e I'm not discussing the packet TLV block, or protocols A modifying protoco= l B's messages.) If a non-5444 packet arrives on that port than the multipl= exer should reject it. Yes, you could then send that somewhere else, create= a new packet format guaranteed to fail to parse as 5444 and so on. But tha= t approach and good design live on different continents. > > I was thinking about full compliant RFC5444 messages. There can be > multiple receivers on the same UDP multicast port. > > So in either case (both with and without RFC5444 in DLEP) DLEP needs > it own port and Multicast group. > > Henning Rogge > > >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 05 July 2012 17:30 >> To: Dearlove, Christopher (UK) >> Cc: Stan Ratliff (sratliff); Henning Rogge; >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) >> wrote: >>> I'm of the view >>> - There is no compulsion for DLEP to use 5444. The only compulsion is 5= 498's that anything using the manet protocol/port uses 5444. >> >> Interesting question... do we need a different port for the DLEP >> protocol or can we just use what RFC5498 provides? If DLEP use its own >> message type (and most likely work on a different interface), it >> should not make any trouble with existing users. Otherwise we would >> need an UDP port and an IP multicast group for DLEP. >> >>> - 5444 is a flexible format. I believe (but no one has yet done and pub= lished the work to support that) that 5444 could be used to represent DLEP = at least quite well, maybe very well. >> >> I had an early draft for this, but I will work on an update. >> >>> - The currently proposed way to use 5444 to represent DLEP is not a ver= y good use of 5444 to do that. >> >> I think most of us agree to this. >> >>> - The pros and cons of a non-5444 representation of DLEP versus a good = 5444 representation of DLEP are hard to judge when neither is well-defined = yet. >> >>> - A key question is future extensibility, adding new attributes. This i= s a strength of 5444. How much is it needed by DLEP? >> First of course would be adding of more routing metrics and >> statistical data from layer 2. >> My second argument for RFC5444 is that DLEP is primarily about >> delivering layer-2 data for networks/interfaces and layer-2 data for >> neighbors of interfaces. This maps very well on the concept of RFC5444 >> messages with message- and address-TLVs. >> >> There is also the discussion about optional features like the >> ARP-table entry generation through layer-2 transmitted IP-Addresses. >> Another point is the existence of multi-line radios, which need to be >> considered. >> >> A last argument for using something as flexible as RFC5444 is that the >> development Software Defined Radios is still fluid, especially with >> all the ideas about how to use them as Cognitive Radios later. Most >> likely we will have a much better view what we need to add in a few >> years, so having enough flexibility available without breaking the >> protocol by moving to "version 2/3" is a good thing. >> >> It would be of course possible to build a packet format that can do >> all of this without being RFC5444. But I don't think building another >> new packet format is a good way to reduce the complexity of a >> protocol. We should work to reduce complexity of DLEP (without killing >> features), not adding to it. >> >> Henning Rogge >> >>> - As an author of 5444 it's always gratifying when someone uses what yo= u helped create. But that's not a factor in the choice. >>> >>> -- >>> 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 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 Stan Ratliff (sratliff) >>> Sent: 05 July 2012 15:07 >>> To: Henning Rogge >>> Cc: >>> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>> >>> ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >>> >>>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>>> Based on our experience with using DLEP, I would request that it beco= mes >>>>> mandatory to supply either an IPv4 or IPv6 address of the far end rou= ter >>>>> during a Neighbour Up/Down message as that would speed up the routing >>>>> process. Total contact time between routers in a MANET could be very >>>>> short, and anything that helps speed the establishment of the connect= ion >>>>> is welcome. >>>> >>>> I would say it should be mandatory if the knowledge is present on the = DLEP-capable device. If you do not know the IP addresses of each partner, y= ou can still use DLEP and leave this job to the router. >>>> >>>>> As to the 5444 debate, I do not see the need for 5444 compliance in >>>>> DLEP. >>>> >>>> If we can find a good fit for all the DLEP use cases with RFC5444, I s= ee no need to specify another packet format for it. DLEP transports informa= tion (many of them optional) about the local radio/modem and information (a= lso many of them optional) about connection between radios/modems. This see= ms to be a very good description of the concept of RFC5444. >>>> >>>> It also needs multiple kinds of messages, which makes message aggregat= ion into a single block of information an useful feature. >>>> >>>> At last, it needs to interact with routing protocols (especially MANET= protocols), which makes reusing rfc5444 a good thing. >>> >>> That's a red herring, IMO. The fact that DLEP should interact with rout= ing protocols does *not* mean that 5444 use is, in and of itself, "a good t= hing". For example, the current DLEP offering I work on interacts with OSPF= v3. RFC 5444 compliance is actually a burden in that environment. Or, at a = bare minimum, it becomes "DLEP-specific". I believe DLEP has applicability = outside the MANET space, and as has been said before, it isn't a routing pr= otocol. So, I don't see a requirement to "make it fit" with 5444. >>> >>> Regards, >>> Stan >>> >>> >>> >>>> >>>> > I agree with the 'it's not a routing protocol' stance, and in my >>>> > view it just adds unnecessary complexity, but I'm open to discussion= > on the extensibility issue. >>>> >>>> What do you think is the difference in implementing a custom DLEP prot= ocol language and a RFC5444 compliant one? In the second case, you might be= able to reuse code written for routing protocols, in the first one you hav= e to do it from scratch. >>>> >>>> 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. >>> ******************************************************************** >>> >>> _______________________________________________ >>> 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." > --=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 Jul 5 10:46: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 5DE7121F86EF for ; Thu, 5 Jul 2012 10:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 eITyIzreH-ct for ; Thu, 5 Jul 2012 10:46:40 -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 974B321F86EC for ; Thu, 5 Jul 2012 10:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6385; q=dns/txt; s=iport; t=1341510415; x=1342720015; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p738svCWD9RuR2GyJc2YI5wfKK8SFoIUluZWwh9+8PA=; b=GalzXxgSgh9cplI0HxVdN2y105XFaYO792vi1exzjtD+hdDwSYYKYh/x d2TtjqmzJKbAcAyNZWY54M81Uso031PhroRblLpA4p8SLLDwTuQVTsZH2 4+SvQCwgkpi2110FD/SNAp2QE001ntSGdjkZAtxX6ZXgbartip8eCKSHU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALjS9U+tJV2Z/2dsb2JhbABFtzCBB4IYAQEBAwEBAQEPAUIZAwgFBwQCAQgRBAEBAScHJwsUCQgBAQQOBSKHZAULmVifdYs5FA6FPGADiBeNII4dgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99125887" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jul 2012 17:46:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q65HksWb032577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 17:46:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 12:46:54 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1Zoi8fTpCAFddlbEyMT95YMXvXBAAH9JaAAA7tmYAAOOkqgAAEfjkAAAMvGAA= Date: Thu, 5 Jul 2012 17:46:53 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--66.245900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <61EF40A9FED59A449176F2A4321B2BF0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:46:42 -0000 Chris,=20 First off, I think this is a pretty good summarization. Thanks for putting = it on the list. One comment inline: On Jul 5, 2012, at 12:15 PM, Dearlove, Christopher (UK) wrote: > I'm of the view > - There is no compulsion for DLEP to use 5444. The only compulsion is 549= 8's that anything using the manet protocol/port uses 5444. > - 5444 is a flexible format. I believe (but no one has yet done and publi= shed the work to support that) that 5444 could be used to represent DLEP at= least quite well, maybe very well. > - The currently proposed way to use 5444 to represent DLEP is not a very = good use of 5444 to do that. > - The pros and cons of a non-5444 representation of DLEP versus a good 54= 44 representation of DLEP are hard to judge when neither is well-defined ye= t. > - A key question is future extensibility, adding new attributes. This is = a strength of 5444. How much is it needed by DLEP? Any protocol that is TLV based should be extensible. In removing the requir= ement for 5444, we (the co-authors) don't mean to imply that DLEP would sto= p being TLV based. So I would contend that the extensibility (such as addin= g new metric types) would be consistent.=20 Regards, Stan > - As an author of 5444 it's always gratifying when someone uses what you = helped create. But that's not a factor in the choice. >=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= Stan Ratliff (sratliff) > Sent: 05 July 2012 15:07 > To: Henning Rogge > Cc: > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >=20 >> On 07/04/2012 11:03 AM, John Dowdell wrote: >>> Based on our experience with using DLEP, I would request that it become= s >>> mandatory to supply either an IPv4 or IPv6 address of the far end route= r >>> during a Neighbour Up/Down message as that would speed up the routing >>> process. Total contact time between routers in a MANET could be very >>> short, and anything that helps speed the establishment of the connectio= n >>> is welcome. >>=20 >> I would say it should be mandatory if the knowledge is present on the DL= EP-capable device. If you do not know the IP addresses of each partner, you= can still use DLEP and leave this job to the router. >>=20 >>> As to the 5444 debate, I do not see the need for 5444 compliance in >>> DLEP. >>=20 >> If we can find a good fit for all the DLEP use cases with RFC5444, I see= no need to specify another packet format for it. DLEP transports informati= on (many of them optional) about the local radio/modem and information (als= o many of them optional) about connection between radios/modems. This seems= to be a very good description of the concept of RFC5444. >>=20 >> It also needs multiple kinds of messages, which makes message aggregatio= n into a single block of information an useful feature. >>=20 >> At last, it needs to interact with routing protocols (especially MANET p= rotocols), which makes reusing rfc5444 a good thing. >=20 > That's a red herring, IMO. The fact that DLEP should interact with routin= g protocols does *not* mean that 5444 use is, in and of itself, "a good thi= ng". For example, the current DLEP offering I work on interacts with OSPFv3= . RFC 5444 compliance is actually a burden in that environment. Or, at a ba= re minimum, it becomes "DLEP-specific". I believe DLEP has applicability ou= tside the MANET space, and as has been said before, it isn't a routing prot= ocol. So, I don't see a requirement to "make it fit" with 5444.=20 >=20 > Regards, > Stan >=20 >=20 >=20 >>=20 >>> I agree with the 'it's not a routing protocol' stance, and in my >>> view it just adds unnecessary complexity, but I'm open to discussion > = on the extensibility issue. >>=20 >> What do you think is the difference in implementing a custom DLEP protoc= ol language and a RFC5444 compliant one? In the second case, you might be a= ble to reuse code written for routing protocols, in the first one you have = to do it from scratch. >>=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 >>=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 > ******************************************************************** > 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 teco@inf-net.nl Thu Jul 5 12:08: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 07E2B21F86B7 for ; Thu, 5 Jul 2012 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 ij-M7AWnvhFG for ; Thu, 5 Jul 2012 12:07: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 27AD621F865F for ; Thu, 5 Jul 2012 12:07:58 -0700 (PDT) Received: by eekd4 with SMTP id d4so3648821eek.31 for ; Thu, 05 Jul 2012 12:08:12 -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=J3aTkw5TrqjfOJkpPvLu8ogBBW9wlx4PJ/lkp/1d+mY=; b=YcLs2Xj6vle9kxm445zCuqup0yGNprby0WHxHqe6QnBPV3wBVLSixcCGM4kK9Q2mSC VIMFmRAoqf6XkSTWwsCjkTHcg4cM/rNJ+5+zf0yOwkSP/tj9AQg4X0OQM30xlIyOMBKf TaYlIlDu4wzp6A0SbuP2G5T7I0xHo7Qwf8rl/LaRcTCn8tyACrmk6LfMQu95rfEdUIww mjaL/zWqhchDIaN7DRHbMthEHmoqWU/uFeBQmQB6+8pV3UmYiXQBW30Mg5DN+BFSW950 0aDXutSk/ZAJXb/9zqlU2OeAUUQiA6aTHJX/Epy25uW/wjHEMmiPoMS8Ek75bp3nXW8H OKPw== Received: by 10.14.94.139 with SMTP id n11mr6737199eef.86.1341515291799; Thu, 05 Jul 2012 12:08:11 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id z16sm5529099eef.16.2012.07.05.12.08.11 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 12:08:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> Date: Thu, 5 Jul 2012 21:08:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmDbejywnHTiiqHN0Z2TXR69Ofv1nj6ffYyzbDxpjq1jjEnPEfDtuUtV0vjTDzg4la9xvAr Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:08:01 -0000 Op 5 jul. 2012, om 17:49 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Jul 5, 2012, at 11:22 AM, Teco Boot wrote: >=20 >>=20 >> Op 5 jul. 2012, om 17:20 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>=20 >>>=20 >>> On Jul 5, 2012, at 11:11 AM, Teco Boot wrote: >>>=20 >>>>=20 >>>> Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende = geschreven: >>>>=20 >>>>>=20 >>>>> On Jul 4, 2012, at 1:42 AM, Teco Boot wrote: >>>>>=20 >>>>>>=20 >>>>>> Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het = volgende geschreven: >>>>>>=20 >>>>>>>=20 >>>>>>> On Jul 3, 2012, at 1:34 PM, Henning Rogge wrote: >>>>>>>>=20 >>>>>>>> Most of the workinggroup seems to have the opinion that DLEP = should >>>>>>>> move to full RFC5444 compliance, because it will fit the = purpose of >>>>>>>> DLEP fine and spare the IETF "just another proprietary data = format". >>>>>>>> With RFC5444 we can easily get to a point where we get a = protocol that >>>>>>>> can be extended for more metrics without the need of a version = field, >>>>>>>> which will simplify future DLEP revisions. >>>>>>>=20 >>>>>>> And again, we disagree on that point.=20 >>>>>>=20 >>>>>> Stan, you could set up a poll to find out the working group = opinion. >>>>>>=20 >>>>>> In the discussion on full RFC 5444 compliance, or just use it as = a=20 >>>>>> transport container, my non-important opinion: >>>>>> - dlep-02 implements reliable transport, with tiny chunks of = to_be_acked=20 >>>>>> data and the ack messages=20 >>>>>> - this reliable transport requires (complex) state machines, but = provides=20 >>>>>> reduced data volume over the wire >>>>>> - when transferred data is highly variable, this reliable = transport=20 >>>>>> doesn't make sense. A timer based refresh, with triggered fast = updates,=20 >>>>>> would better fit the required functionality >>>>>=20 >>>>> Relying on "yet another independent timer" isn't the way to go, = IMO. That will only extend time to converge the network. >>>> No, it isn't. Updates are send as fast as the reliable mechanism. = Timers are for auto-cleanup. It is in OSPF too.=20 >>>>=20 >>>=20 >>> Can't be. You have to wait on the timers to expire. Thus, you extend = the time. >> This is the wrong approach. Triggered updates make sense, especially = if bandwidth is no concern. >=20 > Wow. So in your earlier email, you say "A timer based refresh, with = triggered updates=85". Now it's just "triggered updates"? I'm confused - = it looks like you're trying to take all positions at once. And I'll also = argue that a "triggered update" pretty much *has* to be based on a timer = the way you've described it. So it also looks like a difference without = a distinction=85 Could you take a look at olsrv2? It provides a good example. TC = generation is "scheduled or triggered by a change of contents". When = congestion may occur, having a shaper is a good thing. Teco >=20 > Stan >=20 >=20 >>=20 >> Teco >>=20 >>>=20 >>> Stan >>>=20 >>>=20 >>>=20 >>>>> It also doesn't cover the case where some of this data might get = dropped. >>>> Wait for retransmit. When link is unstable, updates might be send = quite frequent. Probably faster than delayed ACKs. >>>>=20 >>>>> Yes, DLEP flows are typically on a high-speed wired link, and the = theoretical drop rate would be small. However, Murphy's Law says traffic = *will* get dropped, >>>> OK. >>>>=20 >>>>> and the traffic that gets dropped will be that which is most = important to you. >>>> Why? >>>>=20 >>>>> There is also the use case where the wireless link itself is used = for DLEP traffic - what we've currently called the "Detached Discovery" = mode.=20 >>>> I am less interested in this mode. I would use a proxy, and = reliable protocol over the satcom link (scenario in I-D for this mode).=20= >>>> On satcom links, extremely efficient protocols is highly preferred. = IMHO few (one?) metric type is used, and address TLVs. >>>> For this satcom link scenario, is info provided the 2 links, for a = 2-hop system, for spoke-spoke traffic?=20 >>>>=20 >>>> Teco. >>>>=20 >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>>=20 >>>>>> - RFC 5444 provides a mechanism to compress larger arrays of = data. This=20 >>>>>> could be used for MAC address TLV's, for transfer of ever = changing link=20 >>>>>> metrics >>>>>> - for reliable transfer, one option would be using another = protocol,=20 >>>>>> already standardized. It is called TCP, if I remember well. For >>>>>> discovery, TCP doesn't work well...=20 >>>>>> - because dlep acts on local, often high speed links, reduction = of volume >>>>>> of transferred data has low priority. >>>>>> I guess we have to choose how to implement the link metrics = exchange. >>>>>> If we opt for reliable transfer, I prefer TCP. For a = straightforward >>>>>> stateless transfer, RFC 5444 MAC address TLV's looks an obvious = choice. >>>>>> Opinions on address TLVs would be influenced on having the parser = already,=20 >>>>>> or facing something on the todo list. Dito the validity timer = stuff. >>>>>>=20 >>>>>> Teco >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From teco@inf-net.nl Thu Jul 5 12:15: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 B7E7311E80BA for ; Thu, 5 Jul 2012 12:15:56 -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=[AWL=0.600, 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 ITLEbuXt-B7R for ; Thu, 5 Jul 2012 12:15:55 -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 B709D11E80AA for ; Thu, 5 Jul 2012 12:15:54 -0700 (PDT) Received: by eaaq13 with SMTP id q13so3661173eaa.31 for ; Thu, 05 Jul 2012 12:16: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=WFcSFFYSSubEvHovmloxo+M/4/bv9gjqVC3YGC3gVZ0=; b=lqynv4OvJFfavU8jiFw5O3A3WHuOCCdUiQ16L4dywn+1CqnCunpv5HKPL7IXfjJtKT ZNFXI81QyO571wLEmMDot/1EwUHUT9b/avCvyxZUoL+nyE4tOqwuLwAogg78rbUtTq8v IVyMYEhpxvvtoLI6tF5h/GI7yImcHkA2e53Y6Ep9tmzqrh1A1H4E2rUcsPKGg4nrIRJS iIm9esL6/gqhCCG9Y8tv0ruRsqM/kqNO294PjFBjYkLi9lRzCsnOttEsEeT4WSsQGacL c+hcRLhnxDo3kRC2dui5f6g153OMY5zioi+obJYcV8u3PPWvrnBNZpZcELSqHVUmjwht Pjsw== Received: by 10.14.22.6 with SMTP id s6mr6799086ees.154.1341515767823; Thu, 05 Jul 2012 12:16:07 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e48sm65359199eea.12.2012.07.05.12.16.06 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 12:16:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Thu, 5 Jul 2012 21:16:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03634F42-49E6-44F2-BB9D-1200DDF42D23@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlOZKnExYFgMHzMbIAvNgiP2CkhRWGLvyYDyW7gKCk3zVqQpLFtj0oMywtNC6/uTYKReITC Cc: "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:15:56 -0000 Op 5 jul. 2012, om 19:25 heeft Dearlove, Christopher (UK) het volgende = geschreven: > I can see DLEP needing its own multicast group, that's quite different = from usual MANET case. Maybe two multicast groups. One for attached mode and one for detached = mode. Both can be IP link-local, but have different L2 scope. Teco > I'm not quite so clear on why a different port is necessary if using = 5444 and its own message type. (A different port is acceptable, and may = even be preferable, I just haven't understood why necessary.) >=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: Henning Rogge [mailto:hrogge@googlemail.com]=20 > Sent: 05 July 2012 18:18 > To: Dearlove, Christopher (UK) > Cc: Stan Ratliff (sratliff); Henning Rogge; > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=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 Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) > wrote: >> We can't use the port (I'll ignore protocol for this email) that 5498 = defines for non 5444 formatted traffic without violating 5444, and = breaking the whole multiplexing method that it mandates (although we = were forced to put into 5444 rather than it being in its proper place in = 5498 directly). The 5444/5498 model is that a multiplexing entity sits = on that port. It gets a packet, parses it as a 5444 packet, and then = passes the messages to whatever has registered as that message owner. = (I'm simplifying here, for example I'm not discussing the packet TLV = block, or protocols A modifying protocol B's messages.) If a non-5444 = packet arrives on that port than the multiplexer should reject it. Yes, = you could then send that somewhere else, create a new packet format = guaranteed to fail to parse as 5444 and so on. But that approach and = good design live on different continents. >=20 > I was thinking about full compliant RFC5444 messages. There can be > multiple receivers on the same UDP multicast port. >=20 > So in either case (both with and without RFC5444 in DLEP) DLEP needs > it own port and Multicast group. >=20 > Henning Rogge >=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: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 05 July 2012 17:30 >> To: Dearlove, Christopher (UK) >> Cc: Stan Ratliff (sratliff); Henning Rogge; >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>=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 Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) >> wrote: >>> I'm of the view >>> - There is no compulsion for DLEP to use 5444. The only compulsion = is 5498's that anything using the manet protocol/port uses 5444. >>=20 >> Interesting question... do we need a different port for the DLEP >> protocol or can we just use what RFC5498 provides? If DLEP use its = own >> message type (and most likely work on a different interface), it >> should not make any trouble with existing users. Otherwise we would >> need an UDP port and an IP multicast group for DLEP. >>=20 >>> - 5444 is a flexible format. I believe (but no one has yet done and = published the work to support that) that 5444 could be used to represent = DLEP at least quite well, maybe very well. >>=20 >> I had an early draft for this, but I will work on an update. >>=20 >>> - The currently proposed way to use 5444 to represent DLEP is not a = very good use of 5444 to do that. >>=20 >> I think most of us agree to this. >>=20 >>> - The pros and cons of a non-5444 representation of DLEP versus a = good 5444 representation of DLEP are hard to judge when neither is = well-defined yet. >>=20 >>> - A key question is future extensibility, adding new attributes. = This is a strength of 5444. How much is it needed by DLEP? >> First of course would be adding of more routing metrics and >> statistical data from layer 2. >> My second argument for RFC5444 is that DLEP is primarily about >> delivering layer-2 data for networks/interfaces and layer-2 data for >> neighbors of interfaces. This maps very well on the concept of = RFC5444 >> messages with message- and address-TLVs. >>=20 >> There is also the discussion about optional features like the >> ARP-table entry generation through layer-2 transmitted IP-Addresses. >> Another point is the existence of multi-line radios, which need to be >> considered. >>=20 >> A last argument for using something as flexible as RFC5444 is that = the >> development Software Defined Radios is still fluid, especially with >> all the ideas about how to use them as Cognitive Radios later. Most >> likely we will have a much better view what we need to add in a few >> years, so having enough flexibility available without breaking the >> protocol by moving to "version 2/3" is a good thing. >>=20 >> It would be of course possible to build a packet format that can do >> all of this without being RFC5444. But I don't think building another >> new packet format is a good way to reduce the complexity of a >> protocol. We should work to reduce complexity of DLEP (without = killing >> features), not adding to it. >>=20 >> Henning Rogge >>=20 >>> - As an author of 5444 it's always gratifying when someone uses what = you helped create. But that's not a factor in the choice. >>>=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 Stan Ratliff (sratliff) >>> Sent: 05 July 2012 15:07 >>> To: Henning Rogge >>> Cc: >>> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>>=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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >>>=20 >>>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>>> Based on our experience with using DLEP, I would request that it = becomes >>>>> mandatory to supply either an IPv4 or IPv6 address of the far end = router >>>>> during a Neighbour Up/Down message as that would speed up the = routing >>>>> process. Total contact time between routers in a MANET could be = very >>>>> short, and anything that helps speed the establishment of the = connection >>>>> is welcome. >>>>=20 >>>> I would say it should be mandatory if the knowledge is present on = the DLEP-capable device. If you do not know the IP addresses of each = partner, you can still use DLEP and leave this job to the router. >>>>=20 >>>>> As to the 5444 debate, I do not see the need for 5444 compliance = in >>>>> DLEP. >>>>=20 >>>> If we can find a good fit for all the DLEP use cases with RFC5444, = I see no need to specify another packet format for it. DLEP transports = information (many of them optional) about the local radio/modem and = information (also many of them optional) about connection between = radios/modems. This seems to be a very good description of the concept = of RFC5444. >>>>=20 >>>> It also needs multiple kinds of messages, which makes message = aggregation into a single block of information an useful feature. >>>>=20 >>>> At last, it needs to interact with routing protocols (especially = MANET protocols), which makes reusing rfc5444 a good thing. >>>=20 >>> That's a red herring, IMO. The fact that DLEP should interact with = routing protocols does *not* mean that 5444 use is, in and of itself, "a = good thing". For example, the current DLEP offering I work on interacts = with OSPFv3. RFC 5444 compliance is actually a burden in that = environment. Or, at a bare minimum, it becomes "DLEP-specific". I = believe DLEP has applicability outside the MANET space, and as has been = said before, it isn't a routing protocol. So, I don't see a requirement = to "make it fit" with 5444. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>>=20 >>>>=20 >>>>> I agree with the 'it's not a routing protocol' stance, and in my >>>>> view it just adds unnecessary complexity, but I'm open to = discussion > on the extensibility issue. >>>>=20 >>>> What do you think is the difference in implementing a custom DLEP = protocol language and a RFC5444 compliant one? In the second case, you = might be able to reuse code written for routing protocols, in the first = one you have to do it from scratch. >>>>=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 >>>>=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 >>>=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 >>=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 >=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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Thu Jul 5 12:19: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 556CC11E80BF for ; Thu, 5 Jul 2012 12:19:53 -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 p+1NiAUt1qrB for ; Thu, 5 Jul 2012 12:19:51 -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 AEA6D21F85B6 for ; Thu, 5 Jul 2012 12:19:51 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13564689pbc.31 for ; Thu, 05 Jul 2012 12:20: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:content-transfer-encoding; bh=evh+zQaqkephKLQjT79SClNksimWPGgo+Ex06ikENwY=; b=rMzH8NmPPkJFWTExT0xERSmTJgUF2fU5i87xpOW8yCRZ6/30jSdQ0+GvMiZZdhF+pk Ng9gV4IcdVtVpBu+/HwG3FICk3pwkUVlIftD3T89Ak0Y8UvMozgK4Yvskvhh9/oRdtKP tm8KPHPZGxvMkm2UhzY+kbkN0plW4lBqllnx3snon75bTslzOmWB0XUr17DPWex5wtBv K4ED9wN9wiVBpqrh0/gfq4RBpPvYEgqPDEwawe0lYbfPdi1vxELoKde/MPXBtW16x1g/ 1rvvqwCqnBBMUECotfsB+2GghmQui4dYPPlj/FcwK2MhvGQJTfZuZfoEexNe+QVXwEpx 8m/A== Received: by 10.68.203.40 with SMTP id kn8mr30023451pbc.162.1341516005652; Thu, 05 Jul 2012 12:20:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 12:19:44 -0700 (PDT) In-Reply-To: <03634F42-49E6-44F2-BB9D-1200DDF42D23@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <1B40484159234F4FB6FE11D4C2F408DE01711CA9@SUKNPT8108.cogent-dsn.local> <4FF4219B.3080606@fkie.fraunhofer.de> <67AE596B-AD94-4448-A777-849C129311E8@cisco.com> <03634F42-49E6-44F2-BB9D-1200DDF42D23@inf-net.nl> From: Henning Rogge Date: Thu, 5 Jul 2012 21:19:44 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:19:53 -0000 What do you mean with "attached" and "detached"? Henning Rogge On Thu, Jul 5, 2012 at 9:16 PM, Teco Boot wrote: > > Op 5 jul. 2012, om 19:25 heeft Dearlove, Christopher (UK) het volgende ge= schreven: > >> I can see DLEP needing its own multicast group, that's quite different f= rom usual MANET case. > Maybe two multicast groups. One for attached mode and one for detached mo= de. Both can be IP link-local, but have different L2 scope. > > Teco > > >> I'm not quite so clear on why a different port is necessary if using 544= 4 and its own message type. (A different port is acceptable, and may even b= e preferable, I just haven't understood why necessary.) >> >> -- >> 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 Centr= e, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> -----Original Message----- >> From: Henning Rogge [mailto:hrogge@googlemail.com] >> Sent: 05 July 2012 18:18 >> To: Dearlove, Christopher (UK) >> Cc: Stan Ratliff (sratliff); Henning Rogge; >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> On Thu, Jul 5, 2012 at 7:13 PM, Dearlove, Christopher (UK) >> wrote: >>> We can't use the port (I'll ignore protocol for this email) that 5498 d= efines for non 5444 formatted traffic without violating 5444, and breaking = the whole multiplexing method that it mandates (although we were forced to = put into 5444 rather than it being in its proper place in 5498 directly). T= he 5444/5498 model is that a multiplexing entity sits on that port. It gets= a packet, parses it as a 5444 packet, and then passes the messages to what= ever has registered as that message owner. (I'm simplifying here, for examp= le I'm not discussing the packet TLV block, or protocols A modifying protoc= ol B's messages.) If a non-5444 packet arrives on that port than the multip= lexer should reject it. Yes, you could then send that somewhere else, creat= e a new packet format guaranteed to fail to parse as 5444 and so on. But th= at approach and good design live on different continents. >> >> I was thinking about full compliant RFC5444 messages. There can be >> multiple receivers on the same UDP multicast port. >> >> So in either case (both with and without RFC5444 in DLEP) DLEP needs >> it own port and Multicast group. >> >> Henning Rogge >> >> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Cent= re, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> >>> -----Original Message----- >>> From: Henning Rogge [mailto:hrogge@googlemail.com] >>> Sent: 05 July 2012 17:30 >>> To: Dearlove, Christopher (UK) >>> Cc: Stan Ratliff (sratliff); Henning Rogge; >>> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> On Thu, Jul 5, 2012 at 6:15 PM, Dearlove, Christopher (UK) >>> wrote: >>>> I'm of the view >>>> - There is no compulsion for DLEP to use 5444. The only compulsion is = 5498's that anything using the manet protocol/port uses 5444. >>> >>> Interesting question... do we need a different port for the DLEP >>> protocol or can we just use what RFC5498 provides? If DLEP use its own >>> message type (and most likely work on a different interface), it >>> should not make any trouble with existing users. Otherwise we would >>> need an UDP port and an IP multicast group for DLEP. >>> >>>> - 5444 is a flexible format. I believe (but no one has yet done and pu= blished the work to support that) that 5444 could be used to represent DLEP= at least quite well, maybe very well. >>> >>> I had an early draft for this, but I will work on an update. >>> >>>> - The currently proposed way to use 5444 to represent DLEP is not a ve= ry good use of 5444 to do that. >>> >>> I think most of us agree to this. >>> >>>> - The pros and cons of a non-5444 representation of DLEP versus a good= 5444 representation of DLEP are hard to judge when neither is well-defined= yet. >>> >>>> - A key question is future extensibility, adding new attributes. This = is a strength of 5444. How much is it needed by DLEP? >>> First of course would be adding of more routing metrics and >>> statistical data from layer 2. >>> My second argument for RFC5444 is that DLEP is primarily about >>> delivering layer-2 data for networks/interfaces and layer-2 data for >>> neighbors of interfaces. This maps very well on the concept of RFC5444 >>> messages with message- and address-TLVs. >>> >>> There is also the discussion about optional features like the >>> ARP-table entry generation through layer-2 transmitted IP-Addresses. >>> Another point is the existence of multi-line radios, which need to be >>> considered. >>> >>> A last argument for using something as flexible as RFC5444 is that the >>> development Software Defined Radios is still fluid, especially with >>> all the ideas about how to use them as Cognitive Radios later. Most >>> likely we will have a much better view what we need to add in a few >>> years, so having enough flexibility available without breaking the >>> protocol by moving to "version 2/3" is a good thing. >>> >>> It would be of course possible to build a packet format that can do >>> all of this without being RFC5444. But I don't think building another >>> new packet format is a good way to reduce the complexity of a >>> protocol. We should work to reduce complexity of DLEP (without killing >>> features), not adding to it. >>> >>> Henning Rogge >>> >>>> - As an author of 5444 it's always gratifying when someone uses what y= ou helped create. But that's not a factor in the choice. >>>> >>>> -- >>>> 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 Cen= tre, 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 (sratliff) >>>> Sent: 05 July 2012 15:07 >>>> To: Henning Rogge >>>> Cc: >>>> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>>> >>>> ----------------------! 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 Jul 4, 2012, at 6:57 AM, Henning Rogge wrote: >>>> >>>>> On 07/04/2012 11:03 AM, John Dowdell wrote: >>>>>> Based on our experience with using DLEP, I would request that it bec= omes >>>>>> mandatory to supply either an IPv4 or IPv6 address of the far end ro= uter >>>>>> during a Neighbour Up/Down message as that would speed up the routin= g >>>>>> process. Total contact time between routers in a MANET could be very >>>>>> short, and anything that helps speed the establishment of the connec= tion >>>>>> is welcome. >>>>> >>>>> I would say it should be mandatory if the knowledge is present on the= DLEP-capable device. If you do not know the IP addresses of each partner, = you can still use DLEP and leave this job to the router. >>>>> >>>>>> As to the 5444 debate, I do not see the need for 5444 compliance in >>>>>> DLEP. >>>>> >>>>> If we can find a good fit for all the DLEP use cases with RFC5444, I = see no need to specify another packet format for it. DLEP transports inform= ation (many of them optional) about the local radio/modem and information (= also many of them optional) about connection between radios/modems. This se= ems to be a very good description of the concept of RFC5444. >>>>> >>>>> It also needs multiple kinds of messages, which makes message aggrega= tion into a single block of information an useful feature. >>>>> >>>>> At last, it needs to interact with routing protocols (especially MANE= T protocols), which makes reusing rfc5444 a good thing. >>>> >>>> That's a red herring, IMO. The fact that DLEP should interact with rou= ting protocols does *not* mean that 5444 use is, in and of itself, "a good = thing". For example, the current DLEP offering I work on interacts with OSP= Fv3. RFC 5444 compliance is actually a burden in that environment. Or, at a= bare minimum, it becomes "DLEP-specific". I believe DLEP has applicability= outside the MANET space, and as has been said before, it isn't a routing p= rotocol. So, I don't see a requirement to "make it fit" with 5444. >>>> >>>> Regards, >>>> Stan >>>> >>>> >>>> >>>>> >>>>>> I agree with the 'it's not a routing protocol' stance, and in my >>>>>> view it just adds unnecessary complexity, but I'm open to discussion= > on the extensibility issue. >>>>> >>>>> What do you think is the difference in implementing a custom DLEP pro= tocol language and a RFC5444 compliant one? In the second case, you might b= e able to reuse code written for routing protocols, in the first one you ha= ve to do it from scratch. >>>>> >>>>> 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. >>>> ******************************************************************** >>>> >>>> _______________________________________________ >>>> 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." >> >> _______________________________________________ >> 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 Jul 5 12:21: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 37B8D21F8722 for ; Thu, 5 Jul 2012 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 z23tcrIPm3Hw for ; Thu, 5 Jul 2012 12:21:42 -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 63F6F21F8653 for ; Thu, 5 Jul 2012 12:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=879; q=dns/txt; s=iport; t=1341516117; x=1342725717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E6DymD6Dcn3SRFAbmdmfWe7t9VcnmG2atq1FbVwX8DI=; b=PuaEhaFS2aF0Cu/+1Ev4uH+XR9yOoU4AUtptSfeG6a3XgnuFPWZ6egWk rabUJrDGa9SZXXeNJs0QKf4KHFdxpjC7ds9tEDtpAg/2zgt+C82VAyCk4 mSWzTGCgWqkEWa0CX+JM582e0XbKOP+YuyB5nYCZxbPIGsEv1nlYqatwI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMHo9U+tJV2Y/2dsb2JhbABFtzCBB4IZAQEEEgFmEAIBCEYyJQIEDieHaZlgoA6RF2ADlTeOHYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99152024" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jul 2012 19:21:56 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65JLtB3026847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 19:21:56 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 14:21:55 -0500 From: "Stan Ratliff (sratliff)" To: Teco Boot Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: AQHNWSibTpCAFddlbEyMT95YMXvXBJcX/zyAgAAJFgCAABOmAIAACZ8AgAAGDgCAAMVZAIACLG6AgAAE94CAAAKAAIAAALyAgAAHgYCAADdpAIAAA9YA Date: Thu, 5 Jul 2012 19:21:54 +0000 Message-ID: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> <8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> In-Reply-To: <8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.000 x-tm-as-result: No--35.024400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4CD1B00600BA3D4FB43247FFA50279AB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:21:43 -0000 [snip] >=20 > Could you take a look at olsrv2? It provides a good example. TC generatio= n is "scheduled or triggered by a change of contents". When congestion may= occur, having a shaper is a good thing. >=20 OK, that is a model=85. but from a router's perspective, how do you tell th= e difference between a radio that just hasn't hit any triggers (so it doesn= 't need to tell you anything), and one that's failed? I guess the answer wo= uld be that Layer 3 timers would eventually clear that up=85. but wait - th= at's what we were trying to avoid in the first place. The same question applies to a radio - how does it tell the difference betw= een a router that just doesn't have anything to say, and one that's crashed= ? We've gone around and around on this issue, and at this point, I don't see = either of us changing the other's mind... Stan From teco@inf-net.nl Thu Jul 5 12:41: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 517BD21F8631 for ; Thu, 5 Jul 2012 12:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 pN7+MZ+yx8IK for ; Thu, 5 Jul 2012 12:41:48 -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 14F0B21F8616 for ; Thu, 5 Jul 2012 12:41:47 -0700 (PDT) Received: by eekd4 with SMTP id d4so3656817eek.31 for ; Thu, 05 Jul 2012 12:42: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=VzI8xa60ag7hHUOfnuMw9jyWvSDy+JlcBVAiwPGkSQQ=; b=ACRKRWC4uXAIHi5qpQZ5AI2JM4cKhnIK3LATXfqeV+Tr79sCYi6uPLn1dC6xLhElnC 1rNS3HzJd2sNpTeJnIMLS/Hvqf4pGQDUuowtuUItUb/+7GDSXZXwQUc72Tl/wan37D42 6r5Qp1bjiuEu4iqk6vq4hX6N0tBgZK2TxKJ8Tb/mfVL3PSoLEMeHSESK1bBhLtmWAnMR t/D4wBUzrr5QnPFXGuZKdk0aFznIqRUdPcCqc2ihOmC5cFTkmYtyfFhYGajMaWacJCKR Gb/jLLokQGpXiA+EhH6JsKoREs9UWpJ1gfzgb5+I5Yvha3vS7kMk3DsHCG9UkhXQoeew qj9w== Received: by 10.14.37.206 with SMTP id y54mr6749572eea.218.1341517320836; Thu, 05 Jul 2012 12:42:00 -0700 (PDT) Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id z16sm5724879eef.16.2012.07.05.12.41.59 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 12:42:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Thu, 5 Jul 2012 21:41:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> <8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkCS0siVvLSqCuM3pIV13+nGnhXXtmLsZw/H+wpprIEcVIXz3nOKcPRSXUkcqrk3W1/UJWi Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:41:49 -0000 Op 5 jul. 2012, om 21:21 heeft Stan Ratliff (sratliff) het volgende = geschreven: > [snip] >>=20 >> Could you take a look at olsrv2? It provides a good example. TC = generation is "scheduled or triggered by a change of contents". When = congestion may occur, having a shaper is a good thing. >>=20 >=20 > OK, that is a model=85. but from a router's perspective, how do you = tell the difference between a radio that just hasn't hit any triggers = (so it doesn't need to tell you anything), and one that's failed? I = guess the answer would be that Layer 3 timers Just timers, not _layer 3_ timers. > would eventually clear that up=85. but wait - that's what we were = trying to avoid in the first place. I wonder how lost packets (no acks) are retransmitted, without timers. A simple implementation just has fixed timers. A more advanced mode is = sending updates more often when there is something to tell. In ROLL, = they have such a mechanism standardized.=20 > The same question applies to a radio - how does it tell the difference = between a router that just doesn't have anything to say, and one that's = crashed? I am not a fan of state in the radio. > We've gone around and around on this issue, and at this point, I don't = see either of us changing the other's mind... We agree on that :-) But IMHO it is important we know how our protocols actually work. Thanks, Teco > Stan >=20 >=20 From hrogge@googlemail.com Thu Jul 5 12: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 27EFB11E80AA for ; Thu, 5 Jul 2012 12:46:07 -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 One1CyzXlLc7 for ; Thu, 5 Jul 2012 12:46:06 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC90721F84F2 for ; Thu, 5 Jul 2012 12:46:05 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8658728ggn.31 for ; Thu, 05 Jul 2012 12:46: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=TEKQPz0meAafXpdY0xwt+3L/4Xk0gE0YvkgnNiNq8rw=; b=pWtl7+nmir5c05SmM+gZx3BCuFi5SBCIBu1ZpymCSHsyx+i/NkhhTtzjJUSQIgzAwk 36RrGd1A0OJrJgek4S8xzGUVALwG6JqGboyS5aFlle0dAu41IL9qUJTQwx4WiW4BCCH5 3+Cad5S6qVFkdTwMU4/e1ZyzYlNtsDwMr5AjSM7eICMS1ZXJLcR2sW/0JaoqZPe3vKL2 pbDo1OXA1oLtY/7QQiClPVlao+kQCXF+0aSxZOcDKgodTwpNpki+lcdz+HsQuTx9PSur RplZ62JxQq2zkWnSZVH1qEaLUxGu3l8gQIS7NFDtpmlLMKr1Hxw5ybEq2YjCPuIUWEzd R4GA== Received: by 10.68.203.40 with SMTP id kn8mr30194518pbc.162.1341517576320; Thu, 05 Jul 2012 12:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 5 Jul 2012 12:45:55 -0700 (PDT) In-Reply-To: References: <4FF30247.6080303@fkie.fraunhofer.de> <72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com> <54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com> <9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com> <7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com> <686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl> <2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl> <948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com> <8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> From: Henning Rogge Date: Thu, 5 Jul 2012 21:45:55 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Shawn Jury , "Bo Berry \(boberry\)" , "Greg Harrison \(greharri\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 19:46:07 -0000 On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff) wrote: > OK, that is a model=85. but from a router's perspective, how do you tell = the difference between a radio that just hasn't hit any triggers (so it doe= sn't need to tell you anything), and one that's failed? I guess the answer = would be that Layer 3 timers would eventually clear that up=85. but wait - = that's what we were trying to avoid in the first place. > > The same question applies to a radio - how does it tell the difference be= tween a router that just doesn't have anything to say, and one that's crash= ed? Typical answer is that the side that needs to be discovered sends regular packets with a validity time. If you do not hear anything for more than a validity time you assume that the other side is gone. That works very well for autodetection between services and does not need any state machine. 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 Thu Jul 5 17:20: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 ADACE11E8096 for ; Thu, 5 Jul 2012 17:20:53 -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 idPyEXFAIBjV for ; Thu, 5 Jul 2012 17:20:52 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD40911E808F for ; Thu, 5 Jul 2012 17:20:52 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8871863ggn.31 for ; Thu, 05 Jul 2012 17:21:07 -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=JYQTFaIqd9+FobB8xALbaeOdiZIdoVtMEfznw12G68k=; b=KF2hNTWJWlu+unVl1xPb7dIKMdpia1GSOeLmBU8oZpWuDWjPqIwMHFQZNYJZ7olz48 wr/jW9eDOHzgoUJTlmvpp9C2+iwitTfJxTSedL8IlrbSJILAS0Uh3GminJ7CXJ77FU0u 62GxYQ3TMqmM8W7tsZ0syJ2Y81Is6ZcF2aDbs= 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=JYQTFaIqd9+FobB8xALbaeOdiZIdoVtMEfznw12G68k=; b=BscLHxQ4O+HPOM+kLok3fA4oXWI/geyBWOcc96VQjz/keIh7R9yzBudO3zvuSMFv2x h1/jJHBArbJ9HuO0u8JhI6zanCkSFIVGIveRUKOCxhfUypd4QP1OImXrhLtc3nDKobnW 0Eg5dR1b+blyJxSHFmJYjUZyGGgnwkmbPn1z8S0ztMsPJcKiw2QWku0iyF6wcSi6ZwRG kZMKkICjvbRLdHL05NvZrp61t3Fcm5nxFLhOKauYpg61X5SaY/0pqmYgLOSwtHMES7LU msVumlfJDdOKOVk31nYWjA+BSz/si4NE3av6FrrUk1Mg1UfvLTH2plwkvTq4EGzg6FxI BLZg== Received: by 10.66.75.201 with SMTP id e9mr40925279paw.54.1341534066795; Thu, 05 Jul 2012 17:21:06 -0700 (PDT) Received: from [192.168.1.5] (c-24-5-73-168.hsd1.ca.comcast.net. [24.5.73.168]) by mx.google.com with ESMTPS id jz4sm20688812pbc.17.2012.07.05.17.21.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 17:21:06 -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: <48710E28-D24C-44CA-A959-25E3953967BA@herberg.name> X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Thu, 5 Jul 2012 17:21:06 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQnB1w9IhfxisdF+5OqDBSmzs4CDnEYybCVhPJn/MKQePFN0HLP7pRMc1dzFSqe+7Z2jIcb9 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 00:20:53 -0000 Abdussalam, I don't see the need for updating RFC2501. I prefer to focus on completing t= he charter items. Best Ulrich On Jul 4, 2012, at 13:11, Abdussalam Baryun wro= te: > Hi All, >=20 > I want to propose draft-ietf work to be done on update the RFC2501, > which I don't mind doing, on the following issues: >=20 > 1- to include all active MANET routing RFCs as describing its network > characteristics and its network context applicability, as mentioned by > section-6. > 2- to include the RFC5444 characteristics, or benefits to MANET performanc= e. > 3- to include NHDP RFC6130. > 4- IPv6 considerations > 5- Add more information in characteristic section on issue of > reliability and scalability. >=20 > RFC2501> 3. Characteristics of MANETs > MANETs have several salient characteristics: > AB>Add> 5) issue of variable E2E delay and node disconnecting from MANE= T. > AB> suggest> to consider LLN >=20 > 2501> 5. IP-Layer Mobile Routing > AB> interfaces as physical layer technology, what about interfaces as > logical? in some other parts we read wireless interface >=20 > 2501> 5>Future interoperability may be achieved using mechanisms other tha= n > mobile IP. > AB> Are we there, could we answer to add some? >=20 > 2501>5>Supporting these features appears only to require identifying > host and router interfaces with IP addresses, identifying a router > with a separate Router ID, and permitting routers to have multiple > wired and wireless interfaces. > AB> replace "host and router" with " router" as it was done in DYMO and OL= SRv2 >=20 > 2501> 4) Proactive operation: The flip-side of demand-based operation. > AB> not clear >=20 > 2501> Section 6.7, Duplex link and bidirectional link > AB> why we use *duplex* with *link*, duplex is related to the > interface system more than the link, so I recommend only using > *bidirectional-link* and replace duplex-link. >=20 > 2501> The following is a list of quantitative metrics that can be used to > assess the performance of any routing protocol. > AB> add examples of new metric used in industry or by active manet protoco= ls >=20 > 2501> 7. Security Considerations > AB> Needs to be amended to consider new techniques >=20 > The purpose of the proposed update, is first because RFC2501 is a > reference to many new RFCs and that updates directs progress designs. > Please note that I will not do this work until most active participant > agree, thanking you, >=20 > Best Regards > Abdussalam >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > On 6/21/12, Charles E. Perkins wrote: >>=20 >> Hello Abdussalam, >>=20 >> I didn't see what part of RFC 2501 needed to be revised. >> Do you have a specific proposal? I think that, before you >> could expect any discussion on revising that document, >> you would have to point out what part or parts need >> work. >>=20 >> Regards, >> Charlie P. >>=20 >> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>> Could we Update RFC2501? >>> I see that RFC2501 some how defines MANET technologies, which will be >>> a good reference in the draft I am writting of L2 subnets, but maybe >>> RFC2501 is enough for the protocols, and no need for a new draft. >>> However, that will depend on the WG discussion and decision :) >>>=20 >>> I got no answer of the question so far, therefore, I will propose it >>> to be discussed in the next meeting IETF 84. >>>=20 >>> AB >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> On 6/6/12, Abdussalam Baryun wrote: >>>> Hi Folks, >>>>=20 >>>> the RFC2501 is the best RFC I read and I like it because it is easy to >>>> read, understandable, and covers solid issues of MANET. I hope the >>>> authors give us a feedback if they want to make new one as Version 2. >>>>=20 >>>> I see that it is old (1999), and it may be interesting to update it >>>> some how, I hope the authors can update its issues and evaluation, now >>>> we got new RFCs and industries have new needs than 90s, it does not >>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>> getting renew versions. >>>>=20 >>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>>> to update RFC2501 as well, it will only take few days or a month, to >>>> draft and submit so why leave it old-documents with old >>>> considerations? Please advise, >>>>=20 >>>> Abdussalam Baryun >>>> University of Glamorgan, UK. >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >> -- >> Regards, >> Charlie P. >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jul 5 17: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 558DA21F85B1 for ; Thu, 5 Jul 2012 17:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=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 CwnBr+QOdXPX for ; Thu, 5 Jul 2012 17:29:28 -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 9FE3321F85AF for ; Thu, 5 Jul 2012 17:29:28 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13929117pbc.31 for ; Thu, 05 Jul 2012 17:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=cVv7AQrxA4xORbxUg1E7tJqjR4GUjsWS3AYFqpyMcwE=; b=Uhz5SSDDLuNwFIlD9cxP2JUXvWfWQ+LI/vZ74L+HzYmHH01zLZDBM+eQrMdxoKiCm+ sJ1e4UPZ44dhxvkIXY1s+p45h+q7j5D2naEOfg4oeT52jo6bjx0dV2t2c/PXx6eDot4g +WYEDV4to33oXbHjn6HRlQPIv67+s0x30sLVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=cVv7AQrxA4xORbxUg1E7tJqjR4GUjsWS3AYFqpyMcwE=; b=JlqhkcnXCCHEuEqAo97UHgGcbti4QqCKOS2YC7eQXV/3bfZJDCCFRKRCQyCBuX66yA Lk8XgvFzIfWqkwkltYpQ9vurwQUzaz57yRgtvhCVMmL5yq6nUIyGr6TlFbvAqynm3YHz Ms7/a0lg2XayijSGodrHki13qfhRMvz+Z6izJmbLHR8Udai1x1Ueq+jnBG9Am31chj6C voKV1urFri+DAzls2HbKNGJ/UtL6FZVUo7WzxA2SneSP+WWJI21F4pK/Lm9GhXgKRXWr xQ8rQQWZiN2SqdFfbArXvK0n9GtSHa+hpFKUKknn8yRsRLW6ByEtKxQv7diBNZajK53O EQfg== MIME-Version: 1.0 Received: by 10.68.227.198 with SMTP id sc6mr32158525pbc.138.1341534583190; Thu, 05 Jul 2012 17:29:43 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Thu, 5 Jul 2012 17:29:43 -0700 (PDT) Date: Thu, 5 Jul 2012 17:29:43 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7b2ed4ad48f49a04c41e5cc7 X-Gm-Message-State: ALoCoQmApia53IMF4BZ/Y8SvkbCFQEvS3TGTkv9WpbvRkKr1b3BzMBpEflIbDtlm7NTPjjfJ/QI1 Subject: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 00:29:29 -0000 --047d7b2ed4ad48f49a04c41e5cc7 Content-Type: text/plain; charset=ISO-8859-1 Hi, we are currently working on a revised ID of the NHDP-MIB, as follow-up on requests during the IESG review. Amongst others, one request from Thomas Nadeau may affect other MIB documents as well, which is why I post it on the mailing list. The current interface table in the NHDP-MIB is a copy of the interface MIB, with potentially many entries that are not MANET interfaces (but still waste space). What we are really interested in is monitoring and managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to specify a ifType=MANET (as allowed by RFC2863 and the IANAifType registry), and to list only those in the NHDP-MIB. Bob and I propose that IANA allocates such an ifType, which covers all MANET WG protocols, i.e. ifType=MANET would be used for interfaces running NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an additional boolean flag which determines whether the interface uses NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only interfaces would be listed in the nhdpIfTable, but the boolean flag is false). Best regards Ulrich --047d7b2ed4ad48f49a04c41e5cc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

we are currently working on a revised ID of the NHDP-MIB, as fol= low-up on requests during the IESG review. Amongst others, one request from= Thomas Nadeau may affect other MIB documents as well, which is why I post = it on the mailing list.

The current interface table in the NHDP-MIB is a copy of the=20 interface MIB, with potentially many entries that are not MANET=20 interfaces (but still waste space). What we are really interested in is=20 monitoring and managing NHDP interfaces. Thomas Nadeau suggested to ask=20 IANA to specify a=20 ifType=3DMANET (as allowed by RFC2863 and the=20 IANAifType registry), and to list only those in the NHDP-MIB. Bob and I pro= pose that IANA allocates such an ifType, which covers all MANET WG protocol= s, i.e. ifType=3DMANET would be used for interfaces running NHDP, OLSRv2, S= MF, DYMO, etc. In the NhdpIfTable, there is an additional boolean flag whic= h determines whether the interface uses NHDP or not (i.e., if a router runs= both DYMO and NHDP, the DYMO-only interfaces would be listed in the nhdpIf= Table, but the boolean flag is false).


Best regards
Ulrich

--047d7b2ed4ad48f49a04c41e5cc7-- From d.sturek@att.net Thu Jul 5 17:30: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 F0FFD11E80F9 for ; Thu, 5 Jul 2012 17:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 ZuYEEB-CRAvp for ; Thu, 5 Jul 2012 17:30:50 -0700 (PDT) Received: from nm9-vm3.bullet.mail.ne1.yahoo.com (nm9-vm3.bullet.mail.ne1.yahoo.com [98.138.91.139]) by ietfa.amsl.com (Postfix) with SMTP id 6305111E808F for ; Thu, 5 Jul 2012 17:30:50 -0700 (PDT) Received: from [98.138.90.56] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2012 00:31:00 -0000 Received: from [68.142.200.224] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2012 00:30:59 -0000 Received: from [66.94.237.101] by t5.bullet.mud.yahoo.com with NNFMP; 06 Jul 2012 00:30:59 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 06 Jul 2012 00:30:59 -0000 X-Yahoo-Newman-Id: 666727.77182.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 68474 invoked from network); 6 Jul 2012 00:30:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1341534659; bh=byftDU6vRXy/3u7HvLYR8M6wRlYP243AePgcHAjOQIs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=nqDoJEmHJDhkBkreen3cwkcSpO3dPMb6dIpphh6bYct/60OeEuq2PqlxoTQCKGSJkSHumdp6wPkkW/BhI9Z2ZiuG1Hv+IcPV2Sg+c8lFzRqoeWRbaxNl2LVq6OjtNVnd2IXj5yPo3bSUlz5lZYqdLb48N4VjZmuuoIUZfnNGbGo= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iTCkqRgVM1keCcxfsoqHjlVA.xeMvVtLdvwkjEXsapHNbhI YgUEkrDHILCyQU_XJVdEty1hWrTP3VSNHTHfzmspWTNXKkpAS2XGq8h.IF9x 9yVQ1B.TGwhtRkObJcu75_a0rmbCY8.xtQ9Bwmh1rWg0akGNlqXPtgu9OmuO 02HplICisCFFG5SgdwoQ70oCVOLZx6sITLyQT3gMBgXbFLbucHFg2Vrpqdsa NfL7mlj5lv2_YqnPVPGCvKVB1FNHZfJh5M9xHGRsz.JgoWBVxWkuCffKFOjE IYIimWAiwUy3YYWNCDVrzhkLlNvCcLZvAA2hrgNMo8UJ9IuTW71drUBNqOmw vnzuJYlXdNxIu7XxE5cIJ9JMr7SCz6Gfv.7K6aBwp3yDL23XkPvpzm8WQI0_ k.KQkfG1KA2JYwphLpNfqjUIrYj2_HrwJaXQ- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.197] (d.sturek@69.224.123.174 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 05 Jul 2012 17:30:58 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 05 Jul 2012 17:28:26 -0700 From: Don Sturek To: Ulrich Herberg , Abdussalam Baryun Message-ID: Thread-Topic: [manet] Propose update RFC2501 In-Reply-To: <48710E28-D24C-44CA-A959-25E3953967BA@herberg.name> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 00:30:57 -0000 +1 I also would like the group to focus on completing the existing charter items. Don On 7/5/12 5:21 PM, "Ulrich Herberg" wrote: >Abdussalam, > >I don't see the need for updating RFC2501. I prefer to focus on >completing the charter items. > >Best >Ulrich > >On Jul 4, 2012, at 13:11, Abdussalam Baryun >wrote: > >> Hi All, >> >> I want to propose draft-ietf work to be done on update the RFC2501, >> which I don't mind doing, on the following issues: >> >> 1- to include all active MANET routing RFCs as describing its network >> characteristics and its network context applicability, as mentioned by >> section-6. >> 2- to include the RFC5444 characteristics, or benefits to MANET >>performance. >> 3- to include NHDP RFC6130. >> 4- IPv6 considerations >> 5- Add more information in characteristic section on issue of >> reliability and scalability. >> >> RFC2501> 3. Characteristics of MANETs >> MANETs have several salient characteristics: >> AB>Add> 5) issue of variable E2E delay and node disconnecting from >>MANET. >> AB> suggest> to consider LLN >> >> 2501> 5. IP-Layer Mobile Routing >> AB> interfaces as physical layer technology, what about interfaces as >> logical? in some other parts we read wireless interface >> >> 2501> 5>Future interoperability may be achieved using mechanisms other >>than >> mobile IP. >> AB> Are we there, could we answer to add some? >> >> 2501>5>Supporting these features appears only to require identifying >> host and router interfaces with IP addresses, identifying a router >> with a separate Router ID, and permitting routers to have multiple >> wired and wireless interfaces. >> AB> replace "host and router" with " router" as it was done in DYMO and >>OLSRv2 >> >> 2501> 4) Proactive operation: The flip-side of demand-based operation. >> AB> not clear >> >> 2501> Section 6.7, Duplex link and bidirectional link >> AB> why we use *duplex* with *link*, duplex is related to the >> interface system more than the link, so I recommend only using >> *bidirectional-link* and replace duplex-link. >> >> 2501> The following is a list of quantitative metrics that can be used >>to >> assess the performance of any routing protocol. >> AB> add examples of new metric used in industry or by active manet >>protocols >> >> 2501> 7. Security Considerations >> AB> Needs to be amended to consider new techniques >> >> The purpose of the proposed update, is first because RFC2501 is a >> reference to many new RFCs and that updates directs progress designs. >> Please note that I will not do this work until most active participant >> agree, thanking you, >> >> Best Regards >> Abdussalam >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> On 6/21/12, Charles E. Perkins wrote: >>> >>> Hello Abdussalam, >>> >>> I didn't see what part of RFC 2501 needed to be revised. >>> Do you have a specific proposal? I think that, before you >>> could expect any discussion on revising that document, >>> you would have to point out what part or parts need >>> work. >>> >>> Regards, >>> Charlie P. >>> >>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>> Could we Update RFC2501? >>>> I see that RFC2501 some how defines MANET technologies, which will be >>>> a good reference in the draft I am writting of L2 subnets, but maybe >>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>> However, that will depend on the WG discussion and decision :) >>>> >>>> I got no answer of the question so far, therefore, I will propose it >>>> to be discussed in the next meeting IETF 84. >>>> >>>> AB >>>> ===================================================== >>>> On 6/6/12, Abdussalam Baryun wrote: >>>>> Hi Folks, >>>>> >>>>> the RFC2501 is the best RFC I read and I like it because it is easy >>>>>to >>>>> read, understandable, and covers solid issues of MANET. I hope the >>>>> authors give us a feedback if they want to make new one as Version 2. >>>>> >>>>> I see that it is old (1999), and it may be interesting to update it >>>>> some how, I hope the authors can update its issues and evaluation, >>>>>now >>>>> we got new RFCs and industries have new needs than 90s, it does not >>>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>>> getting renew versions. >>>>> >>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >>>>>try >>>>> to update RFC2501 as well, it will only take few days or a month, to >>>>> draft and submit so why leave it old-documents with old >>>>> considerations? Please advise, >>>>> >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK. >>>>> ========================================================= >>>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jul 5 17:43: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 3502C21F855F for ; Thu, 5 Jul 2012 17:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.644, 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 AjAJ0Jp6dHxC for ; Thu, 5 Jul 2012 17:43:04 -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 7794221F8522 for ; Thu, 5 Jul 2012 17:42:57 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13945336pbc.31 for ; Thu, 05 Jul 2012 17:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=v/0rVDU3mRQYPutcHTK0vFf55veZgx4FE3EGTEwBZdI=; b=1AzVAA037TiUaWhj7nJdzjRp8hscManJFezBR308Mm8LXXvIv624TAbJlHMZHKL6fU PyLwVZsXSUoiCNt6dkTi013QcHp7fLJ2tcZtyKLYbhtzrRP1xzxoKNW9M7O9WLRJOptn 0yyWjOM2AeYmQQ9tCI2GBJ2ZVsGjq0jNflPO4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=v/0rVDU3mRQYPutcHTK0vFf55veZgx4FE3EGTEwBZdI=; b=bFgB4sGxps1TNtXdzjBaez2KYf5nPwtat1BaQK87KOVub5KthJnu4d8tCnHpAIUYU8 c8P/t8IvGgd8UeqVCP4lO3mIW728NRqt2dbF4Kej40fqeTvDVPLvxgdDznfQIpSSFT2w nDEG4yid0W5AG+xwYKcE4YsAnbzbmSwnDw/Sn5fEgHABtFiAXRAebuXHztygKPQxTww9 0hH8ckw7eSTB2tD9TRNKBS8Ajq6+/W7j/ai85dzruvyRaSglqQyKDs0ZgtMQVgQVIHHi xj2n0QWLskA1BJMV3WYxF9QxuAh6V8ZusOPy7WInr1POAMaivvx5P3ZUAht6PEx5Vhzm 0Wcw== MIME-Version: 1.0 Received: by 10.68.226.102 with SMTP id rr6mr32144022pbc.99.1341535392373; Thu, 05 Jul 2012 17:43:12 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Thu, 5 Jul 2012 17:43:12 -0700 (PDT) Date: Thu, 5 Jul 2012 17:43:12 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff257b8841b2704c41e8c78 X-Gm-Message-State: ALoCoQmxeyEhqY50Uimei2L7JxoryIumwyfGfGCrUegTlANT/vzSXmjicQY4RIATE6rq0EzgkmRf Subject: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 00:43:05 -0000 --e89a8ff257b8841b2704c41e8c78 Content-Type: text/plain; charset=ISO-8859-1 Hi, we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB IESG evaluation to specify use cases how MANETs are monitored and managed using SNMP. After discussion with Benoit and Adrian, we agreed that such information would be useful, but that the MIB module (as pure APIs) would likely be the wrong place. Moreover, the use cases would not necessarily be specific to the NHDP-MIB, but concern all MIB modules. Benoit requested that we come up with a new informational draft in the WG, which discusses different MANET management use cases. Bob started working on collecting management and monitoring scenarios from the military experience. I believe that it would also be interesting to cover other use cases, such as in disaster recovery (e.g., monitoring and management of routers thrown out of an airplane over a disaster area) or in community networks (e.g., FreiFunk/FunkFeuer networks in Europe). Investigating these examples can help to come up with a more abstract model of different management and monitoring approaches. It would be helpful if participants in this WG with MANET deployment and management/monitoring experience could contribute to such an effort. As a side note, there is a new mailing list about management of constrained networks and devices (coma@ietf.org), which may be of interest for some of the WG participants. Best regards Ulrich --e89a8ff257b8841b2704c41e8c78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

we got a request (read: "DISCUSS") from Benoit Claise = during NHDP-MIB IESG evaluation to specify use cases how MANETs are monitor= ed and managed using SNMP. After discussion with Benoit and Adrian, we agre= ed that such information would be useful, but that the MIB module (as pure = APIs) would likely be the wrong place. Moreover, the use cases would not ne= cessarily be specific to the NHDP-MIB, but concern all MIB modules. Benoit = requested that we come up with a new informational draft in the WG, which d= iscusses different MANET management use cases.

Bob started working on collecting management and monitoring scenarios f= rom the military experience. I believe that it would also be interesting to= cover other use cases, such as in disaster recovery (e.g., monitoring and = management of routers thrown out of an airplane over a disaster area) or in= community networks (e.g., FreiFunk/FunkFeuer networks in Europe). Investig= ating these examples can help to come up with a more abstract model of diff= erent management and monitoring approaches. It would be helpful if particip= ants in this WG with MANET deployment and management/monitoring experience could contribute to such an effort.
As a side note, there is a new mailing list about management of constrain= ed networks and devices (coma@ietf.org= ), which may be of interest for some of the WG participants.

Best regards
Ulrich
--e89a8ff257b8841b2704c41e8c78-- From abdussalambaryun@gmail.com Thu Jul 5 21:37: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 1AEC411E8153 for ; Thu, 5 Jul 2012 21:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 8v5C56JpaaM9 for ; Thu, 5 Jul 2012 21:37:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB59911E808D for ; Thu, 5 Jul 2012 21:37:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6433714vcq.31 for ; Thu, 05 Jul 2012 21:37:18 -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=EQdNjQxRlF5cljbZ6ZVxmyDhd6cQlc3BD7SbZS3bJ80=; b=z230AsX1Kb84M7SWTMqJzaxpSFabbJbhJnHAwpsr/aKEx5NTAX1OvTsPh8XSjDqjSP nGlkY0osqtkVPbCPygwPiYRheA+BZi6iPGmwqSxHdQv2Sm4rsL2anArZRp/1KWlOFPNx i0LVIk4aktRyJaSr3aq0cZ6iFBxH59fASfRCGeUte9LUaXaIvdhdxVWqP4UG2CaV/J72 WtQHZvFxmnbKiS7buUXWGhgtv5VbUWVEb65Ow508g6QQPP7R3m+8wkBbTkuxcorLYqr7 aQmKsBraZUVfZ1gkQWIDxKXbb5d1wu7EAGJ1dXYx8uxgdJoUviiL2J70+xE2IxSa21hU a85w== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr11716931vdb.10.1341549438697; Thu, 05 Jul 2012 21:37:18 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 21:37:18 -0700 (PDT) In-Reply-To: References: <48710E28-D24C-44CA-A959-25E3953967BA@herberg.name> Date: Fri, 6 Jul 2012 06:37:18 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg , Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 04:37:05 -0000 Hi Ulrich and Don, > I prefer to focus on completing the charter items. That is the reason for updating RFCs in all WGs, is to be focused on their charter. I am trying to be focused on manet-charter, I-Ds, and RFCs related to MANET. My I-Ds I am working on need some references to be based on and I need these references to be UP to Date. Please note that IMHO RFC2501 is not Up to Date, for the reasons I presented, so do you think it was not correct. I see that RFC2501 is issued in 1999, missing many changes in the Internet and in MANET. Its update will not take time, its only an informational document. My intention is not to argue the issue, just want to understand the WG decision in updating its old works that are not consistent with others. Therefore, I will request a decision from the WG so we can go forward. I thank you for your reply and comments, Abdussalam Baryun University of Glamorgan, UK. ===================== On 7/6/12, Don Sturek wrote: > +1 > > I also would like the group to focus on completing the existing charter > items. > > Don > > > On 7/5/12 5:21 PM, "Ulrich Herberg" wrote: > >>Abdussalam, >> >>I don't see the need for updating RFC2501. I prefer to focus on >>completing the charter items. >> >>Best >>Ulrich >> >>On Jul 4, 2012, at 13:11, Abdussalam Baryun >>wrote: >> >>> Hi All, >>> >>> I want to propose draft-ietf work to be done on update the RFC2501, >>> which I don't mind doing, on the following issues: >>> >>> 1- to include all active MANET routing RFCs as describing its network >>> characteristics and its network context applicability, as mentioned by >>> section-6. >>> 2- to include the RFC5444 characteristics, or benefits to MANET >>>performance. >>> 3- to include NHDP RFC6130. >>> 4- IPv6 considerations >>> 5- Add more information in characteristic section on issue of >>> reliability and scalability. >>> >>> RFC2501> 3. Characteristics of MANETs >>> MANETs have several salient characteristics: >>> AB>Add> 5) issue of variable E2E delay and node disconnecting from >>>MANET. >>> AB> suggest> to consider LLN >>> >>> 2501> 5. IP-Layer Mobile Routing >>> AB> interfaces as physical layer technology, what about interfaces as >>> logical? in some other parts we read wireless interface >>> >>> 2501> 5>Future interoperability may be achieved using mechanisms other >>>than >>> mobile IP. >>> AB> Are we there, could we answer to add some? >>> >>> 2501>5>Supporting these features appears only to require identifying >>> host and router interfaces with IP addresses, identifying a router >>> with a separate Router ID, and permitting routers to have multiple >>> wired and wireless interfaces. >>> AB> replace "host and router" with " router" as it was done in DYMO and >>>OLSRv2 >>> >>> 2501> 4) Proactive operation: The flip-side of demand-based operation. >>> AB> not clear >>> >>> 2501> Section 6.7, Duplex link and bidirectional link >>> AB> why we use *duplex* with *link*, duplex is related to the >>> interface system more than the link, so I recommend only using >>> *bidirectional-link* and replace duplex-link. >>> >>> 2501> The following is a list of quantitative metrics that can be used >>>to >>> assess the performance of any routing protocol. >>> AB> add examples of new metric used in industry or by active manet >>>protocols >>> >>> 2501> 7. Security Considerations >>> AB> Needs to be amended to consider new techniques >>> >>> The purpose of the proposed update, is first because RFC2501 is a >>> reference to many new RFCs and that updates directs progress designs. >>> Please note that I will not do this work until most active participant >>> agree, thanking you, >>> >>> Best Regards >>> Abdussalam >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> On 6/21/12, Charles E. Perkins wrote: >>>> >>>> Hello Abdussalam, >>>> >>>> I didn't see what part of RFC 2501 needed to be revised. >>>> Do you have a specific proposal? I think that, before you >>>> could expect any discussion on revising that document, >>>> you would have to point out what part or parts need >>>> work. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>>> Could we Update RFC2501? >>>>> I see that RFC2501 some how defines MANET technologies, which will be >>>>> a good reference in the draft I am writting of L2 subnets, but maybe >>>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>>> However, that will depend on the WG discussion and decision :) >>>>> >>>>> I got no answer of the question so far, therefore, I will propose it >>>>> to be discussed in the next meeting IETF 84. >>>>> >>>>> AB >>>>> ===================================================== >>>>> On 6/6/12, Abdussalam Baryun wrote: >>>>>> Hi Folks, >>>>>> >>>>>> the RFC2501 is the best RFC I read and I like it because it is easy >>>>>>to >>>>>> read, understandable, and covers solid issues of MANET. I hope the >>>>>> authors give us a feedback if they want to make new one as Version 2. >>>>>> >>>>>> I see that it is old (1999), and it may be interesting to update it >>>>>> some how, I hope the authors can update its issues and evaluation, >>>>>>now >>>>>> we got new RFCs and industries have new needs than 90s, it does not >>>>>> cover different devices constraints as sensors and LLNs, and IPv6, >>>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>>>>> getting renew versions. >>>>>> >>>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't >>>>>>try >>>>>> to update RFC2501 as well, it will only take few days or a month, to >>>>>> draft and submit so why leave it old-documents with old >>>>>> considerations? Please advise, >>>>>> >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK. >>>>>> ========================================================= >>>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > > From abdussalambaryun@gmail.com Thu Jul 5 22:26: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 E6BB521F86D7 for ; Thu, 5 Jul 2012 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 WddMQjvi331k for ; Thu, 5 Jul 2012 22:26:48 -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 F134421F86D5 for ; Thu, 5 Jul 2012 22:26:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6461281vbb.31 for ; Thu, 05 Jul 2012 22:27:03 -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=O3XU0J6WZbDsEWfiD8dYF5Au4Jzi3PJSvU6Eqj3V2FY=; b=wEFzb2eF3iramsNnySTatSEwoLlnaI7zKDkPOOEYxs+Giur+C1IAGCqgaZ4j95PzL4 x9ZNGFKvYMGSb+/SkrzldtR2wjJw1ESI7/SKLAtFNzZiC0tcg+dqwNlKHLqiOdBGdAfQ x06TF14r6+2rKejodqmKLA71qnHMqk/rsOU/G4uwW7lbtAu0c2mekQrwEqj+Ep+YWKqK hYi11hADlQGH5s7tkHgWt069UDHmUO/GdE5fy/1Qy2LSaY1QoPn9c0lfutxYZRk1Ppiv i5379bhUtLt01Ct5GrfwGspHt6/9NNAXl/T35rAAT1iabAj3UcCSQsQeWR6sqAymba2d Mygw== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr11853787vdf.127.1341552423104; Thu, 05 Jul 2012 22:27:03 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 22:27:02 -0700 (PDT) Date: Fri, 6 Jul 2012 07:27:03 +0200 Message-ID: From: Abdussalam Baryun To: ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:26:49 -0000 Hi Ulrich, I thank you for this, I am happy that IESG have requested this. Mr. Cole in the meeting 82 had introduced the problem (please check his presentation), which I presented to the MANET. Yes we need in MANET to be focus on use-case, and how management is done. It is important that MANET documents interact with Internet drafts. I included Mr.Cole presentation (Nov.2011) in my I-D draft about MANET subnet technologies, and propose that any new I-D for management should take it into consideration. Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Hi, > > we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB > IESG evaluation to specify use cases how MANETs are monitored and > managed using SNMP. After discussion with Benoit and Adrian, we agreed > that such information would be useful, but that the MIB module (as > pure APIs) would likely be the wrong place. Moreover, the use cases > would not necessarily be specific to the NHDP-MIB, but concern all MIB > modules. Benoit requested that we come up with a new informational > draft in the WG, which discusses different MANET management use cases. > > Bob started working on collecting management and monitoring scenarios > from the military experience. I believe that it would also be > interesting to cover other use cases, such as in disaster recovery > (e.g., monitoring and management of routers thrown out of an airplane > over a disaster area) or in community networks (e.g., > FreiFunk/FunkFeuer networks in Europe). Investigating these examples > can help to come up with a more abstract model of different management > and monitoring approaches. It would be helpful if participants in this > WG with MANET deployment and management/monitoring experience could > contribute to such an effort. > > As a side note, there is a new mailing list about management of > constrained networks and devices (coma at ietf.org), which may be of > interest for some of the WG participants. > > Best regards > Ulrich > From ietf@thomasclausen.org Thu Jul 5 22:29: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 9CEE021F8700 for ; Thu, 5 Jul 2012 22:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, 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 PUQcFBBfCnj3 for ; Thu, 5 Jul 2012 22:29:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id CB45321F86FF for ; Thu, 5 Jul 2012 22:29:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 2516E557F11 for ; Thu, 5 Jul 2012 22:29:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2FF4A1C07C1; Thu, 5 Jul 2012 22:29:54 -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 1D4DB1C055C; Thu, 5 Jul 2012 22:29:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: Date: Fri, 6 Jul 2012 07:29:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Don Sturek X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:29:41 -0000 I fully agree with Ulrich and Don here. I went back to read RFC2501, and while I am sure that one could find a = nit or two to fix if *really* trying to, I believe that doing so would = be a pointless use of the WGs resources: the document is fine as a = reference, is an informational document, and updating it would = contribute absolutely nothing to the group making progress on its = protocol work - which is (always) the priority. Thomas On Jul 6, 2012, at 02:28 , Don Sturek wrote: > +1 >=20 > I also would like the group to focus on completing the existing = charter > items. >=20 > Don >=20 >=20 > On 7/5/12 5:21 PM, "Ulrich Herberg" wrote: >=20 >> Abdussalam, >>=20 >> I don't see the need for updating RFC2501. I prefer to focus on >> completing the charter items. >>=20 >> Best >> Ulrich >>=20 >> On Jul 4, 2012, at 13:11, Abdussalam Baryun = >> wrote: >>=20 >>> Hi All, >>>=20 >>> I want to propose draft-ietf work to be done on update the RFC2501, >>> which I don't mind doing, on the following issues: >>>=20 >>> 1- to include all active MANET routing RFCs as describing its = network >>> characteristics and its network context applicability, as mentioned = by >>> section-6. >>> 2- to include the RFC5444 characteristics, or benefits to MANET >>> performance. >>> 3- to include NHDP RFC6130. >>> 4- IPv6 considerations >>> 5- Add more information in characteristic section on issue of >>> reliability and scalability. >>>=20 >>> RFC2501> 3. Characteristics of MANETs >>> MANETs have several salient characteristics: >>> AB>Add> 5) issue of variable E2E delay and node disconnecting = from >>> MANET. >>> AB> suggest> to consider LLN >>>=20 >>> 2501> 5. IP-Layer Mobile Routing >>> AB> interfaces as physical layer technology, what about interfaces = as >>> logical? in some other parts we read wireless interface >>>=20 >>> 2501> 5>Future interoperability may be achieved using mechanisms = other >>> than >>> mobile IP. >>> AB> Are we there, could we answer to add some? >>>=20 >>> 2501>5>Supporting these features appears only to require identifying >>> host and router interfaces with IP addresses, identifying a router >>> with a separate Router ID, and permitting routers to have multiple >>> wired and wireless interfaces. >>> AB> replace "host and router" with " router" as it was done in DYMO = and >>> OLSRv2 >>>=20 >>> 2501> 4) Proactive operation: The flip-side of demand-based = operation. >>> AB> not clear >>>=20 >>> 2501> Section 6.7, Duplex link and bidirectional link >>> AB> why we use *duplex* with *link*, duplex is related to the >>> interface system more than the link, so I recommend only using >>> *bidirectional-link* and replace duplex-link. >>>=20 >>> 2501> The following is a list of quantitative metrics that can be = used >>> to >>> assess the performance of any routing protocol. >>> AB> add examples of new metric used in industry or by active manet >>> protocols >>>=20 >>> 2501> 7. Security Considerations >>> AB> Needs to be amended to consider new techniques >>>=20 >>> The purpose of the proposed update, is first because RFC2501 is a >>> reference to many new RFCs and that updates directs progress = designs. >>> Please note that I will not do this work until most active = participant >>> agree, thanking you, >>>=20 >>> Best Regards >>> Abdussalam >>>=20 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> On 6/21/12, Charles E. Perkins wrote: >>>>=20 >>>> Hello Abdussalam, >>>>=20 >>>> I didn't see what part of RFC 2501 needed to be revised. >>>> Do you have a specific proposal? I think that, before you >>>> could expect any discussion on revising that document, >>>> you would have to point out what part or parts need >>>> work. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>>> Could we Update RFC2501? >>>>> I see that RFC2501 some how defines MANET technologies, which will = be >>>>> a good reference in the draft I am writting of L2 subnets, but = maybe >>>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>>> However, that will depend on the WG discussion and decision :) >>>>>=20 >>>>> I got no answer of the question so far, therefore, I will propose = it >>>>> to be discussed in the next meeting IETF 84. >>>>>=20 >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> On 6/6/12, Abdussalam Baryun wrote: >>>>>> Hi Folks, >>>>>>=20 >>>>>> the RFC2501 is the best RFC I read and I like it because it is = easy >>>>>> to >>>>>> read, understandable, and covers solid issues of MANET. I hope = the >>>>>> authors give us a feedback if they want to make new one as = Version 2. >>>>>>=20 >>>>>> I see that it is old (1999), and it may be interesting to update = it >>>>>> some how, I hope the authors can update its issues and = evaluation, >>>>>> now >>>>>> we got new RFCs and industries have new needs than 90s, it does = not >>>>>> cover different devices constraints as sensors and LLNs, and = IPv6, >>>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 = are >>>>>> getting renew versions. >>>>>>=20 >>>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we = don't >>>>>> try >>>>>> to update RFC2501 as well, it will only take few days or a month, = to >>>>>> draft and submit so why leave it old-documents with old >>>>>> considerations? Please advise, >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK. >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=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 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu Jul 5 22:34: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 1745321F873B for ; Thu, 5 Jul 2012 22:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_65=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 jVARwDcJ3I-L for ; Thu, 5 Jul 2012 22:34:11 -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 7D06121F8739 for ; Thu, 5 Jul 2012 22:34:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6463845vbb.31 for ; Thu, 05 Jul 2012 22:34:26 -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=P8TCIIKHBFrA2gzxLVSLTi1N6NfgQNYQ8Ibfw52gQC8=; b=A1VTHNp/D8j57WnM+ZduVBqhV6NAY4K84vaLepr22tk4VfpYAmtrgpHT7YeC8+E0Ob 3QvEgf+AWlEYOum4JtV6ICK/l45ktLHWXfsDwPdDtoWUgh9+S/60njrfH4jfyQ33CWIM G+oHcsxPNN9XFWi1B4giuMKEslzRtCBeMFSF1EcJHWWVouP5RLWqHiu99ojCvn0LMfK/ cQZOcuELW9StmWVe26EUvHmUcaupXEEWR3QaESMF5uDzzwLi7aG/CZ2tUruLG/YNGAlR S+fw6QChjABQuGBlMUy3pHzAu2V1XdxSOgs9QVuUpzW3su8el3g36TNB57N/kEhqlV0a p7bA== MIME-Version: 1.0 Received: by 10.52.90.144 with SMTP id bw16mr11565457vdb.129.1341552866609; Thu, 05 Jul 2012 22:34:26 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 22:34:26 -0700 (PDT) Date: Fri, 6 Jul 2012 07:34:26 +0200 Message-ID: From: Abdussalam Baryun To: ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:34:12 -0000 +1 I need the NHDP as a MANET interface for the DSRv2, which I suggested for DSRv2 before, so I like/agree that you consider the flag ifType, thanks very much, It is interesting if most manet routings use NHDP or even be possible to use in future, because I think it is a MANET interface as specified in OLSRv2. AB ++++++++ > Hi, > > we are currently working on a revised ID of the NHDP-MIB, as follow-up > on requests during the IESG review. Amongst others, one request from > Thomas Nadeau may affect other MIB documents as well, which is why I > post it on the mailing list. > > The current interface table in the NHDP-MIB is a copy of the interface > MIB, with potentially many entries that are not MANET interfaces (but > still waste space). What we are really interested in is monitoring and > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType > registry), and to list only those in the NHDP-MIB. Bob and I propose > that IANA allocates such an ifType, which covers all MANET WG > protocols, i.e. ifType=MANET would be used for interfaces running > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an > additional boolean flag which determines whether the interface uses > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only > interfaces would be listed in the nhdpIfTable, but the boolean flag is > false). > > > Best regards > Ulrich > From abdussalambaryun@gmail.com Thu Jul 5 22:47: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 C1ECA21F8758 for ; Thu, 5 Jul 2012 22:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 foN3kjPYVmnE for ; Thu, 5 Jul 2012 22:47:01 -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 D2DCF21F8740 for ; Thu, 5 Jul 2012 22:47:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6468522vbb.31 for ; Thu, 05 Jul 2012 22:47:16 -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=ZvqeEwuDMzLI0cAkY+rsXTkmOtUQ3uTguktAjWIKdHk=; b=XRS5qK6G9LtRHoWuXi60on/2/XtRijvs16AjdrQ29caNR9Yurs03bokagCyUc1jY4H MVTy04b9Ny5w1k7bp9OjcS6sEc2L1uvW7a14Qev+GXm189xDc9aEGxoxlwefRTejNyPG wqt4QR2NUMqvHKFGLgZzkrl8OhEuXfX/dEkn8L1XypLXzCa936QTcKh2faArb4Usnlth rziez6KLBqcXH0q4VrL1rt9Yte8jgl6o1M4BvVeuz2P/r01Mhsdig4jXd52sn+ToWi1d AQx3O2GXbe1WZI/CPxU1o03ejbjdOgfmN5Q0b9Ki3vBhjQNkRfx11WZfBunsxMSktxjB +GHw== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr13887100vcv.12.1341553635982; Thu, 05 Jul 2012 22:47:15 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 22:47:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 07:47:15 +0200 Message-ID: From: Abdussalam Baryun To: ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:47:02 -0000 Hi Ulrich, I got a question I heard before on the list by one participant that MANET routing does not mandatory need MIB for each protocol. Is this true? I had a feeling that there is many type of managements when we consider ad hoc networks which are self-managed somehow, thanking you AB > Hi Ulrich, > > I thank you for this, I am happy that IESG have requested this. Mr. > Cole in the meeting 82 had introduced the problem (please check his > presentation), which I presented to the MANET. Yes we need in MANET to > be focus on use-case, and how management is done. It is important that > MANET documents interact with Internet drafts. > > I included Mr.Cole presentation (Nov.2011) in my I-D draft about > MANET subnet technologies, and propose that any new I-D for management > should take it into consideration. > > Abdussalam Baryun > University of Glamorgan, UK > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Hi, >> >> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >> IESG evaluation to specify use cases how MANETs are monitored and >> managed using SNMP. After discussion with Benoit and Adrian, we agreed >> that such information would be useful, but that the MIB module (as >> pure APIs) would likely be the wrong place. Moreover, the use cases >> would not necessarily be specific to the NHDP-MIB, but concern all MIB >> modules. Benoit requested that we come up with a new informational >> draft in the WG, which discusses different MANET management use cases. >> >> Bob started working on collecting management and monitoring scenarios >> from the military experience. I believe that it would also be >> interesting to cover other use cases, such as in disaster recovery >> (e.g., monitoring and management of routers thrown out of an airplane >> over a disaster area) or in community networks (e.g., >> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >> can help to come up with a more abstract model of different management >> and monitoring approaches. It would be helpful if participants in this >> WG with MANET deployment and management/monitoring experience could >> contribute to such an effort. >> >> As a side note, there is a new mailing list about management of >> constrained networks and devices (coma at ietf.org), which may be of >> interest for some of the WG participants. >> >> Best regards >> Ulrich >> > From thomas@thomasclausen.org Thu Jul 5 22:50: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 B543B21F8796 for ; Thu, 5 Jul 2012 22:50:12 -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 Ea8VmkEVZ9-Q for ; Thu, 5 Jul 2012 22:50:11 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6121F8773 for ; Thu, 5 Jul 2012 22:50:10 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 81F85A394D for ; Thu, 5 Jul 2012 22:50:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 17D4C1C0824; Thu, 5 Jul 2012 22:50:26 -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 F3E971C055C; Thu, 5 Jul 2012 22:50:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: Date: Fri, 6 Jul 2012 07:50:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: manet , Jiazi YI Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:50:12 -0000 I do not see the need for this terminology document in MANET: o The RFCs published by the WG all do a good job of = defining their proper=20 terminology and conventions in the sections, aptly named = to this=20 effect -- and something which both the WG and the IESG = has been very=20 vigilant in ensuring. o Extracting this terminology, to present without the = context of the RFC in=20 which they are introduced and used, is both futile and a = source=20 of errors and confusion. o The domain evolves, new protocols appear and introduce = new concepts,=20 terms. This is captured by carefully defining such in = the RFC specifying=20 that protocol. Any terminology document (aside from all = its other issues, indicated in this list) would likely be obsolete and = incomplete before the ink with which it was written was dry. o All RFCs in MANET uses no more than a small subset of = the total MANET (and Internet) terminology. A collective terminology = document would, therefore, necessarily be adding entropy to any single = RFC and to the=20 WG (and to implementers of the WG protocols). o Certainly, a large number of terms in this document are = entirely out of scope (such as those pertaining to non-MANET developed = concepts or protocols,=20 e.g., those developed in other parts of the IETF), are = useless for the WG (such as, but not exclusively, "communication channel" = and "communication=20 medium"), are by nature ambiguous (such as, but not = exclusively, "Upper Layer" and "Node"), carry a legacy that renders them difficult = to use (such as, but=20 not exclusively, "Logical (virtual) Link", "Physical = Link", and "Link"). Thomas =09 On Jul 3, 2012, at 20:14 , Abdussalam Baryun wrote: > Hi Jiazi, >=20 > On 7/3/12, Jiazi YI wrote: >> 1. I didn't get the scope of this document. The definitions are from >> "Communication Medium" to protocol-specific term like "Route Reply = Message >> (RREP)", and even security. I don't think it's necessary to go from = the >> general terms of telecommunication to some specified protocols -- if = you >> define RREP, why not HELLO, TC, and all other message types in the = other >> protocols? >=20 > I will add TC and HELLO, and others if they are a general concept to > be used by MANET. Usually the draft is the start, there will be more > work to be added, >=20 >>=20 >> 2. A lot of definitions are quite vague and do not make much sense, = for >> example: >>=20 >>> "Upper layer" >> this can be only used in certain context, but not a an depenent term. >=20 > ok we may remove it, >=20 >>=20 >>> Reactive Routing: >>> An on-demand based routing protocol that operates route discover and >>> maintainance the route(s), to reach the demanded destination(s). >>=20 >> what's an on-demand based routing procotol then? A reactive routing? >>=20 >=20 > ok will add this term as well >=20 >>=20 >>> Message: >>> A MANET data message or routing control message. >>=20 >> You are trying to define "message" using "message"? And >=20 > I will amend this >=20 >>=20 >>> Routing control messages are either MANET routing protocol messages = or/and >>> RFC5444 >>> messages. >>=20 >> I'm confused with the relation between routing protocol message and = RFC 5444 >> messages when saying this... >> Are you tying to say: a chicken can be either a white chicken or/and = a >> cock? >> plus, RFC 5444 defines both packet and message... >>=20 >=20 > Just trying to say the term "MANET message" doesn't always mean > RFC5444 message. If you read RFC5444 (general MANET format) you will > understand that all MANET messages are RFC5444. we still have active > MANET RFCs that don't use RFC5444 (its a standard document). >=20 >>=20 >> 3. There are a lot controversial terms (phy link, logic link, subnet >> prefix...) and terms that rarely used in the protocols ( Protocol = Sequence >> Number/Router Sequence Number, Distance Vector Metric/Link Stat = Metric, or I >> don't really know what they really are). >>=20 >> Personally, I'm against to have this kind of document that "tries to = define >> everything", with the reasons that the others have stated before. >>=20 >=20 > The document is only a informational document not a standard document, > The document I am doing may clarify many terms more to the community > (users) than to the designers (experts). >=20 >> best >>=20 >> Jiazi YI >>=20 >=20 > I thank you for your input and comments, >=20 > Best Regards, > Abdussalam > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> http://www.jiaziyi.com >> LIX, Ecole Polytechnique >> Route de Saclay 91128 Palaiseau Cedex France >>=20 >>=20 >>=20 >>=20 >> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>=20 >>> Dear All >>>=20 >>> I completed the first version of draft on terminology and submited = the >>> draft yesterday (with getting some techniq problem), but needed to >>> post to know the community feedback and advise. There are other = terms >>> that was not yet included which will need some advise from you. >>> Thanking you, >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Abbreviations Used in The submitted Document >>>=20 >>> AH Authentication Header >>> DAD Duplicate Address Detection >>> DPD Duplicate Packet Detection >>> DoS Denial of Service >>> ESP Encapsulating Security Payload >>> IP IPv4 or IPv6 >>> ICMP Internet Control Message Protocol >>> IIB Interface Information Base >>> ETX Estimated Expected number of Transmission >>> FIB Forwarding Information Base >>> LQI Link Quality Indicator >>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>> LLN Low power and Lossy Network >>> MAC Mediam Access Control >>> MIB Management Information Base >>> MTU Maximum Transmission Unit >>> NBMA Non-Broadcast Multi-Access link >>> NHDP Neighborhood Discovery Protocol >>> ND IP Neighbor Discovery >>> OSPF Open Shortest Path First >>> RIB Routing Information Base >>> SMF Simplified Multicast Forwarding >>> TCP Transmission Control Protocol >>> UDP User Datagram Protocol >>>=20 >>> 2.3 Definitions for MANET Terms >>>=20 >>> 2.3.1 Terms Definition of MANET Communication: >>>=20 >>> Communications=92 Technology or Facility: >>> The means employed by two or more devices/subsystems to transfer >>> and/or receive information between them in one way or two way >>> communication. MANET communications often uses the wireless >>> transmission medium(s) and MAY use some wired mediums (e.g. free >>> space, air, water, antenna, coaxial cables, etc.) >>>=20 >>> Communication Medium: >>> The transceiver system (e.g. such as L2 systems, IEEE802.11 = systems, >>> satellite system, etc.) that the routing device uses to = communicates >>> through the transmission medium(s), by providing connectionless = and/or >>> connection services that MAY be established. The system medium >>> includes MAC layer and MAY include the physical Layer. >>>=20 >>> Communication Channel: >>> A subdivision of the physical communication medium (i.e. radio = carrier >>> signal bandwidth, or the system bandwidth) allowing possibly shared >>> independent uses of the medium. Channels may be made available by >>> subdividing the medium into; distinct time slots, distinct spectral >>> bands, or coding sequence, etc. >>>=20 >>> MANET Protocol: >>> The communication system/subsystem that operates and maintains the >>> ad hoc communication technology or facility within MANET. MANET = routing >>> Protocols often apply distributed algorithms/techniques to = disseminate >>> or forward routing messages within a MANET routing domain. >>>=20 >>> Topology: >>> An abstract representation of a network (physical or logical), as a >>> graph (G) whose topology is defined by a set of routers/bridges (V) = that >>> communicate through set of links (E), where the G =3D (V, E). >>>=20 >>> Physical-level Topology: >>> A topology of the communication medium networks consists of routing >>> devices and physical links. This topology information is updated by >>> devices=92 technology in the L2 information Base. >>>=20 >>> Network-level Topology: >>> A topology of the communication system networks consists of routers = and >>> links. This topology information is updated by routers in its RIB. >>>=20 >>> Multihop MANET: >>> A MANET that its node(s) MAY need(s) more than one IP hop to reach = the >>> destination. >>>=20 >>> Reactive Routing: >>> An on-demand based routing protocol that operates route discover and >>> maintainance the route(s), to reach the demanded destination(s). >>>=20 >>> Proactive Routing: >>> A topology RIB based routing protocol that operates routes and = maintains >>> the network topology, to reach its known destination(s). Each router >>> maintains routes to all reachable destinations at all times, whether = or >>> not there is currently any demand to deliver packets to those >>> destinations. >>>=20 >>> Upper Layer: >>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>=20 >>> MANET Domain: TBD >>>=20 >>> MANET Signaling: >>> Sending and exchanging some MANET messages/information. >>>=20 >>> 2.3.2 Terms Definition of MANET Elements >>>=20 >>> Node: >>> A device/subsystem that MUST implement IP and SHOULD participate in >>> MANET signaling. It either runs a MANET routing protocol or = participate >>> in MANET signaling. >>>=20 >>> Router: >>> A MANET node that MUST implement a MANET routing protocol and = forwards >>> IP packets not explicitly addressed to itself. >>>=20 >>> Host: >>> A node that is not a router. All destinations in MANET that receive >>> delivered data are hosts. >>>=20 >>> Link: >>> A link between two node interfaces. This link may be Logical >>> (i.e. virtual) link or physical link. Logical links are between two >>> logical interfaces and physical links are between two physical >>> interfaces. Links are either unidirectional or bidirectional >>> (links may be on-link and off-link: see RFC4861). >>>=20 >>>=20 >>> Physical Link: >>> a communication facility or medium over which the nodes can >>> communicate at the link layer, i.e., the layer immediately below >>> IP. Physical interfaces are the nodes=92 attachment to physical = links. >>> Physical Link types are point-to-point, NBMA, multicast capable, >>> and shared-media, etc (see link types in ND [RFC4861]). >>>=20 >>> Logical (virtual) Link: >>> a communication facility (at L3, or upper-layer) over which nodes = can >>> communicate. This logical link is between two MANET interfaces = exists >>> if either can be heard by the other. >>>=20 >>> Link MTU: >>> the maximum transmission unit (i.e. maximum unit size in octets), = that >>> can be conveyed in one transmission unit over the link. >>>=20 >>>=20 >>> Node Interface: >>> A node's point of attachment to a link. Each node MUST have at least = one >>> interface that SHOULD be assigned an IP address. If there is/are = more >>> than one interface(s) per node then the additional interface(s) MAY = be >>> assigned an IP address. If an interface is not assigned to an IP = address >>> it MUST be identified by the MANET routing protocol. An interface = MAY be >>> assigned one or more addresses. >>>=20 >>> MANET Interface: >>> A node interface that participate in; exchange MANET information = used in >>> MANET routing or exchange information in MANET neighbor node = discovery >>> (e.g as the term used in RFC6130). A MANET interface MUST be = assigned to >>> least one address to communicate. A router interface MUST be >>> assigned a routable address which is the main address for the = interface. >>>=20 >>>=20 >>> 2.3.3 Terms Definition of MANET Identifications: >>>=20 >>> An interface MAY be assigned one or more addresses. If the interface = is >>> a logical interface it MAY be assigned to only logical addresses, = but if >>> it is a physical interface MAY be assigned with physical address >>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>> MANET addresses). >>>=20 >>>=20 >>> MANET Address >>> A MANET-subnet, node, or interface address. Node and interface = addresses >>> are either IP addresses or RFC5444 addresses. All subnet addresses = are >>> unicast IP addresses. >>>=20 >>> Address Block and TLV: as specified in RFC5444 >>>=20 >>> Routable address: >>> A subnet address which can be a destination address. A router MUST = be >>> able to distinguish a routable address from a non-routable address. >>> Broadcast, and multicast addresses, limited in scope to less than = the >>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>> addresses MAY be considered as routable addresses. >>>=20 >>> Main address >>> A routable address (MANET address) that is assigned to one router's >>> MANET interface. >>>=20 >>> Originator address: >>> A node address of the node that originated a MANET message (this = message >>> MUST include the originator address). It MAY be a routable or an >>> unroutable address. >>>=20 >>> subnet prefix >>> A bit string that consists of some number of initial bits of an IP >>> address. >>>=20 >>> Interface identifier >>> the remaining low-order bits in the node's IP address after the = subnet >>> prefix. A number used to identify a node's interface on a link. >>>=20 >>> 2.3.4 Terms Definition of MANET exchange information formats: >>>=20 >>> Packet: >>> A MANET packet of a header plus payload. These packets are either >>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>> in IP packet. Packets are generated by nodes to be sent to >>> destination(s) through MANET or through the Internet. RFC5444 = packets >>> information MAY not be used only by MANET routers. >>>=20 >>> Message: >>> A MANET data message or routing control message. Routing control >>> messages are either MANET routing protocol messages or/and RFC5444 >>> messages. >>>=20 >>> Type Length Value coding (TLV): >>> A generic way to represent MANET information (as in [RFC5444] and >>> [RFC5497]). >>>=20 >>> Frame: >>> A L2 protocol TLV with a header and payload. In some technologies = the L2 >>> operates a MANET routing protocol as a local area networking system. >>> Frames MAY encapsulate MANET packets to be tunneled through a >>> telecommunication network. >>>=20 >>> Route Request Message (RREQ) >>> A message is used to discover a valid route to a particular >>> destination address, called the RREQ Target Node. When a router >>> processes a RREQ it learns routing information on how to Originator >>> Node. >>>=20 >>> Route Reply Message (RREP) >>> A message is used to disseminate routing information about >>> the RREP Target Node to the RREQ Originator Node and the = intermediate >>> routers. >>>=20 >>> Route Error Message (RERR) >>> A message is used to disseminate the information that a route is >>> not available for one or more particular addresses. A RERR message = is >>> used to indicate that a router does not have a forwarding route >>> to one or more particular addresses. >>>=20 >>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>=20 >>> Hop-by-hop Routing: (TBD) >>> A dynamic routing that routes to destination by routing table. >>>=20 >>> Source Routing: (TBD) >>> A dynamic routing that its route path is provided in the IP packet. >>>=20 >>> Route Discovery: TBD >>>=20 >>> Route Maintenance: TBD >>>=20 >>> Neighbor discovery: (TBD) >>> A node discovers neighbors only if the node receives from it's >>> neighbors. >>>=20 >>>=20 >>> Multipoint relay (MPR): (TBD) >>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>> its selection of router X1 as an MPR in a recent HELLO message. >>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>> participate in the flooding process of messages received from >>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>> declare link-state information for the link from X1 to Y1. It may >>> also be both at the same time. >>>=20 >>> MPR selector: >>> A router, Y, is a flooding/routing MPR selector of router X if >>> router Y has selected router X as a flooding/routing MPR. >>>=20 >>> Router Parameters: >>> boolean or numerical values, specified for each router, and not >>> specific to an interface. A router MAY change router parameter >>> values at any time, subject to some MANET constraints. >>>=20 >>> MANET Routing Metric: >>> A MANET routing cost that is governed by specific rules and = properties >>> defined by the MANET routing protocol which captures specific link = or >>> node characteristics. Examples of basic metrics are hop-count, ETX, = LQI, >>> etc. >>>=20 >>> Distance Vector Metric >>> A metric class related to rules of the MANET interface and MANET = path >>> distance. The metric can be calculated by the distance vector = routing >>> algorithm class used by the MANET routing protocol. A metric of the >>> distance a message or piece of information has traversed. The = minimum >>> value of distance is the number of IP hops traversed. >>>=20 >>> Link State Metric >>> A metric type related to the MANET network-topology status and = logical >>> links' states. This metric is calculated by the link state routing >>> algorithm class used by the MANET routing protocol. A metric type = maybe >>> EXT, LQL, etc. >>>=20 >>> Link Metric: TBD >>>=20 >>> Neighbor Metric: TBD >>>=20 >>> Path accumulated: >>> The RREQ message accumulates intermediate routers that are in path = to >>> destination(s). >>>=20 >>> Protocol Sequence Number: >>> A Sequence Number related to a MANET protocol that maintained by = each >>> protocol subsystem process. This sequence number is used by other >>> subsystems to identify the temporal order of protocol information >>> generated. >>>=20 >>> Router Sequence Number: >>> A router sequence number is maintained by each router process. The >>> sequence number is used by other routers to identify the temporal >>> order of routing information generated and ensure loop-free routes. >>>=20 >>> MANET Information Base: >>> A collection of information (in Table or Cache structure) maintained >>> by MANET protocols and which is to be made available to MANET = routing >>> protocols. An Information Base may be associated with a MANET router >>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, = MIB). >>>=20 >>> RIB Entry: >>> The RIB entry is a conceptual data structure. Implementations may = use >>> any internal representation that conforms to the semantics of a = route >>> as specified in the router specification. >>>=20 >>> 3. IP Considerations and Terminology >>>=20 >>> All MANET nodes MUST implement IP and all MANET routers MUST >>> run/implement at least one MANET routing protocol. The >>> terminologies described in this document can be used for >>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>=20 >>> IP address: >>> IPv4 addresses or IPv6 addresses. >>>=20 >>> IP Packet: >>> The packet header plus payload as specified in [RFC791] and = [RFC2460] >>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets = as >>> specified by RFC5498. >>>=20 >>> Mobile IP considerations: >>> Mobile IP terms are provided in [RFC6275], and this technology >>> assists nodes while connected through the Internet domain(s). MANET >>> is an infrastructure-less network that is able to communicate with >>> the Internet (i.e. an IP infrastructure network). >>>=20 >>> 4. Security Consideration and Terminology >>>=20 >>> It is RECOMMENDED that MANET routing protocols consider security >>> issues because the MANET's transmission medium is wireless which = make >>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>> routing information while traversing the MANET MAY be used by an >>> intruder node, to obtain MANET data traffic or/and attack the MANET >>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>> it is RECOMMENDED that MANET detects attackers and possible = threats. >>>=20 >>> The following are some terminology related to MANET threats and >>> security. >>>=20 >>> Attacker: A node, present in the network and which intentionally = seeks >>> to compromise information based in MANET router(s). The Attacker MAY = be >>> a compromised MANET router if obtained MANET identity or routing >>> information. >>>=20 >>> Compromised MANET Router: An attacker router, present in MANET and >>> which generates syntactically correct routing control messages. = Control >>> messages emitted by compromised router(s) may contain additional >>> information, or omit information, as compared to a control message >>> generated by a non-compromised router located in the same MANET >>> topological position. >>>=20 >>> Legitimate MANET Router: A MANET router, which is not a Compromised >>> MANET Router. >>>=20 >>> Jamming Attack: >>> The attacker transmits massive amounts of interfering radio traffic, >>> which will prevent legitimate traffic (e.g., routing and data = traffic) >>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>> influencing Legitimate MANET Router to transmit unnecessary = information. >>>=20 >>> Eavesdropping: >>> Obtaining a copy by the attacker of the transmitted MANET routing >>> information or the transmitted data information from its neighbor's >>> transmitted radio packet. Attacker=92s processes MANY be used by = attacker >>> to mislead routing. Eavesdropping does not pose a direct threat to = the >>> MANET or to its routing. >>>=20 >>> Identity Spoofing: >>> Attacker sends routing messages, pretending to have the MANET = identity >>> of another node. >>>=20 >>> Link Spoofing: >>> Compromised MANET router sends routing messages to neighbor node(s) >>> providing incorrect set of link information. >>>=20 >>> Replay Attack: >>> A Compromised router in one MANET region records control traffic >>> information and replays the recorded information in a different = MANET >>> region (this type of attack is also called the Wormhole attack). >>>=20 >>> Broadcast Storm: >>> Compromised MANET router may attack the MANET by attempting to = change >>> the MANET flooding algorithm(s) to increase routing overheads or/and = to >>> increase the route discovery delay. Broadcast storm degrades the = data >>> traffic delivery and MANET performance. >>>=20 >>> Falsification in MANET: >>> The compromised MANET router sends false routing information into = MANET. >>> False routing information received in MANET, MAY create unrealistic >>> information bases. >>>=20 >>> ICMP Attacks: >>> The generation of ICMPv6 error messages may be used by compromised = MANET >>> router to attempt DoS attacks by sending an error-causing source = routing >>> header in back-to-back datagrams. As the ICMP messages are passed to = the >>> upper-layer processes, it is possible to perform attacks on the = upper >>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>> RECOMMENDED to perform some form of validation to ICMP messages = (using >>> the information contained in the payload of the ICMP message) before >>> acting upon them. >>>=20 >>> Source Routing Attacks: TBD >>>=20 >>> Acknowledgments: >>>=20 >>> This work has used/modified terms of the following documents: = RFC2462, >>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>> Gratefully acknowledge to the IETF community and all contributions. >>>=20 >>> Reference: >>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>> NHDP", Work in progress, March, 2012. >>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad = Hoc >>> Networks", John Wiley & Sons, March 2007. >>> ISBN: 978-0-471-75688-0. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>> I hope to get some advise from the Internet community to make the >>> definitions more suitable/accurate, because I MAY misunderstood. >>> Thanking you, >>>=20 >>> Best Regards >>>=20 >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Thu Jul 5 22:51: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 53EA921F8796 for ; Thu, 5 Jul 2012 22:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.266, 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 DrtDHRW95Rp7 for ; Thu, 5 Jul 2012 22:51:42 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE1721F8773 for ; Thu, 5 Jul 2012 22:51:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id F06F5A394D for ; Thu, 5 Jul 2012 22:51:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A06DF1C07C1; Thu, 5 Jul 2012 22:51:53 -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 E2B661C055C; Thu, 5 Jul 2012 22:51:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: Date: Fri, 6 Jul 2012 07:51:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: manet Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:51:43 -0000 On Jul 6, 2012, at 07:47 , Abdussalam Baryun wrote: > Hi Ulrich, >=20 > I got a question I heard before on the list by one participant that > MANET routing does not mandatory need MIB for each protocol. Is this > true? I had a feeling that there is many type of managements when we > consider ad hoc networks which are self-managed somehow, >=20 MIBs specify a very different "kind" of management, than what is meant = by those describing an ad hoc network as "self-managed". Thomas > thanking you >=20 > AB >=20 >> Hi Ulrich, >>=20 >> I thank you for this, I am happy that IESG have requested this. Mr. >> Cole in the meeting 82 had introduced the problem (please check his >> presentation), which I presented to the MANET. Yes we need in MANET = to >> be focus on use-case, and how management is done. It is important = that >> MANET documents interact with Internet drafts. >>=20 >> I included Mr.Cole presentation (Nov.2011) in my I-D draft about >> MANET subnet technologies, and propose that any new I-D for = management >> should take it into consideration. >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >>=20 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Hi, >>>=20 >>> we got a request (read: "DISCUSS") from Benoit Claise during = NHDP-MIB >>> IESG evaluation to specify use cases how MANETs are monitored and >>> managed using SNMP. After discussion with Benoit and Adrian, we = agreed >>> that such information would be useful, but that the MIB module (as >>> pure APIs) would likely be the wrong place. Moreover, the use cases >>> would not necessarily be specific to the NHDP-MIB, but concern all = MIB >>> modules. Benoit requested that we come up with a new informational >>> draft in the WG, which discusses different MANET management use = cases. >>>=20 >>> Bob started working on collecting management and monitoring = scenarios >>> from the military experience. I believe that it would also be >>> interesting to cover other use cases, such as in disaster recovery >>> (e.g., monitoring and management of routers thrown out of an = airplane >>> over a disaster area) or in community networks (e.g., >>> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >>> can help to come up with a more abstract model of different = management >>> and monitoring approaches. It would be helpful if participants in = this >>> WG with MANET deployment and management/monitoring experience could >>> contribute to such an effort. >>>=20 >>> As a side note, there is a new mailing list about management of >>> constrained networks and devices (coma at ietf.org), which may be of >>> interest for some of the WG participants. >>>=20 >>> Best regards >>> Ulrich >>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Thu Jul 5 23: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 EE18011E80A2 for ; Thu, 5 Jul 2012 23:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 oZypURmY1A9f for ; Thu, 5 Jul 2012 23:16:34 -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 DE7AC11E8097 for ; Thu, 5 Jul 2012 23:16:24 -0700 (PDT) Received: by eekd4 with SMTP id d4so3744124eek.31 for ; Thu, 05 Jul 2012 23:16:40 -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=DrwCeFi3QY73Hfx1SaBdhyQPJ0MVrwCGzj720yKcc/c=; b=aVewbM7cYXnJu+v2429cMiozedYokG/xBjz77umwoAJDfmiGzljt2bRsOpQQNtP6E9 IP8jqMjoj6i8ma4JK/dZC8P1JlrIXmPW9mWlS70V4XZWMUGUnxALfLUz7URIiFqz4oPY S0t/Au9MHOaguAYA9qJ2WiLKBaofcndIXBV0IxLFXClYTCMxjcy/COmN3wpCa4qA58ke dsyus/kubJ6oncTMn77h4N4IqBc3kl/0XhTZyXsqp+/3IUM3uWfDhN95O1c+sMm8lbB1 sVvWKcDjEgHWvnrgh0GAuY8q2E6gQhLudR4Na0dDruOZbgjTYa+hvcBcvGpvssibW4xb VlMw== Received: by 10.14.101.79 with SMTP id a55mr6542820eeg.32.1341555399758; Thu, 05 Jul 2012 23:16:39 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id a16sm68627436eeg.0.2012.07.05.23.16.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 23:16:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 6 Jul 2012 08:16:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk9hbbviDFrAbevjjnpFO8A90be2w14PIr6O1jjXQN4UgNg2KFeaEI7yfCXSUFN3l/ruRzO Cc: manet , Abdussalam Baryun Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 06:16:36 -0000 +1. I am completely open to _new work_, e.g. descriptions on MANET = deployments, potential shortcomings. =46rom there, we can work on = enhancements. Teco Op 6 jul. 2012, om 07:29 heeft Thomas Heide Clausen het volgende = geschreven: > I fully agree with Ulrich and Don here. >=20 > I went back to read RFC2501, and while I am sure that one could find a = nit or two to fix if *really* trying to, I believe that doing so would = be a pointless use of the WGs resources: the document is fine as a = reference, is an informational document, and updating it would = contribute absolutely nothing to the group making progress on its = protocol work - which is (always) the priority. >=20 > Thomas >=20 >=20 > On Jul 6, 2012, at 02:28 , Don Sturek wrote: >=20 >> +1 >>=20 >> I also would like the group to focus on completing the existing = charter >> items. >>=20 >> Don >>=20 >>=20 >> On 7/5/12 5:21 PM, "Ulrich Herberg" wrote: >>=20 >>> Abdussalam, >>>=20 >>> I don't see the need for updating RFC2501. I prefer to focus on >>> completing the charter items. >>>=20 >>> Best >>> Ulrich >>>=20 >>> On Jul 4, 2012, at 13:11, Abdussalam Baryun = >>> wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> I want to propose draft-ietf work to be done on update the RFC2501, >>>> which I don't mind doing, on the following issues: >>>>=20 >>>> 1- to include all active MANET routing RFCs as describing its = network >>>> characteristics and its network context applicability, as mentioned = by >>>> section-6. >>>> 2- to include the RFC5444 characteristics, or benefits to MANET >>>> performance. >>>> 3- to include NHDP RFC6130. >>>> 4- IPv6 considerations >>>> 5- Add more information in characteristic section on issue of >>>> reliability and scalability. >>>>=20 >>>> RFC2501> 3. Characteristics of MANETs >>>> MANETs have several salient characteristics: >>>> AB>Add> 5) issue of variable E2E delay and node disconnecting = from >>>> MANET. >>>> AB> suggest> to consider LLN >>>>=20 >>>> 2501> 5. IP-Layer Mobile Routing >>>> AB> interfaces as physical layer technology, what about interfaces = as >>>> logical? in some other parts we read wireless interface >>>>=20 >>>> 2501> 5>Future interoperability may be achieved using mechanisms = other >>>> than >>>> mobile IP. >>>> AB> Are we there, could we answer to add some? >>>>=20 >>>> 2501>5>Supporting these features appears only to require = identifying >>>> host and router interfaces with IP addresses, identifying a router >>>> with a separate Router ID, and permitting routers to have multiple >>>> wired and wireless interfaces. >>>> AB> replace "host and router" with " router" as it was done in DYMO = and >>>> OLSRv2 >>>>=20 >>>> 2501> 4) Proactive operation: The flip-side of demand-based = operation. >>>> AB> not clear >>>>=20 >>>> 2501> Section 6.7, Duplex link and bidirectional link >>>> AB> why we use *duplex* with *link*, duplex is related to the >>>> interface system more than the link, so I recommend only using >>>> *bidirectional-link* and replace duplex-link. >>>>=20 >>>> 2501> The following is a list of quantitative metrics that can be = used >>>> to >>>> assess the performance of any routing protocol. >>>> AB> add examples of new metric used in industry or by active manet >>>> protocols >>>>=20 >>>> 2501> 7. Security Considerations >>>> AB> Needs to be amended to consider new techniques >>>>=20 >>>> The purpose of the proposed update, is first because RFC2501 is a >>>> reference to many new RFCs and that updates directs progress = designs. >>>> Please note that I will not do this work until most active = participant >>>> agree, thanking you, >>>>=20 >>>> Best Regards >>>> Abdussalam >>>>=20 >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> On 6/21/12, Charles E. Perkins wrote: >>>>>=20 >>>>> Hello Abdussalam, >>>>>=20 >>>>> I didn't see what part of RFC 2501 needed to be revised. >>>>> Do you have a specific proposal? I think that, before you >>>>> could expect any discussion on revising that document, >>>>> you would have to point out what part or parts need >>>>> work. >>>>>=20 >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>> On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>>>>>> Could we Update RFC2501? >>>>>> I see that RFC2501 some how defines MANET technologies, which = will be >>>>>> a good reference in the draft I am writting of L2 subnets, but = maybe >>>>>> RFC2501 is enough for the protocols, and no need for a new draft. >>>>>> However, that will depend on the WG discussion and decision :) >>>>>>=20 >>>>>> I got no answer of the question so far, therefore, I will propose = it >>>>>> to be discussed in the next meeting IETF 84. >>>>>>=20 >>>>>> AB >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>> On 6/6/12, Abdussalam Baryun wrote: >>>>>>> Hi Folks, >>>>>>>=20 >>>>>>> the RFC2501 is the best RFC I read and I like it because it is = easy >>>>>>> to >>>>>>> read, understandable, and covers solid issues of MANET. I hope = the >>>>>>> authors give us a feedback if they want to make new one as = Version 2. >>>>>>>=20 >>>>>>> I see that it is old (1999), and it may be interesting to update = it >>>>>>> some how, I hope the authors can update its issues and = evaluation, >>>>>>> now >>>>>>> we got new RFCs and industries have new needs than 90s, it does = not >>>>>>> cover different devices constraints as sensors and LLNs, and = IPv6, >>>>>>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 = are >>>>>>> getting renew versions. >>>>>>>=20 >>>>>>> As I can see OLSRv2 and AODVv2 are going in progress, why we = don't >>>>>>> try >>>>>>> to update RFC2501 as well, it will only take few days or a = month, to >>>>>>> draft and submit so why leave it old-documents with old >>>>>>> considerations? Please advise, >>>>>>>=20 >>>>>>> Abdussalam Baryun >>>>>>> University of Glamorgan, UK. >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>>=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 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jul 6 01:06: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 337A521F8622 for ; Fri, 6 Jul 2012 01:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 NC8Yt2w0GzVj for ; Fri, 6 Jul 2012 01:05:59 -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 E397321F8620 for ; Fri, 6 Jul 2012 01:05:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6528664vbb.31 for ; Fri, 06 Jul 2012 01:06:14 -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=Xn7I6f9/g/dinjstakC2Tc0n93ExX5FaJ2n1hF59d7E=; b=aaZb+PYRSOXvtoWysHBk7I5DNcTapId7n9BpLISSBNOExH3PrkFqpft9QgGZjSNtDO fjDNMy/e4EsyuO3JV6bS71AE3CJI6CnhfnNytXQY7w9eu79Tt7aMxhX8A0VHn5WUUfnC riFXclj6ght3DyKZUo9mI3dw7Zv8wY/m4BUXeRd+sZciBo/PYvPsNkx5tHewuDC0/0a4 4v6KofLvYOcccId2Mb4F+z5WwF/iGJ/JlBGq6Va0vvaDkhsGlJkwYl6RAUhjk2NqvEIq pWbJt97jYrMg/l7v3iPJsNNVRBcadz5MPh9eZRfRbRrHEwnHDasLZMO1g2twS409kUtd 1cbA== MIME-Version: 1.0 Received: by 10.52.97.227 with SMTP id ed3mr496629vdb.103.1341561974194; Fri, 06 Jul 2012 01:06:14 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 01:06:14 -0700 (PDT) In-Reply-To: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> Date: Fri, 6 Jul 2012 10:06:14 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 08:06:01 -0000 Dear Thomas, I thank you for your reply and comments, Best Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/6/12, Thomas Heide Clausen wrote: > I do not see the need for this terminology document in MANET: > > o The RFCs published by the WG all do a good job of defining their prope= r > terminology and conventions in the sections, aptly named to this > effect -- and something which both the WG and the IESG has been very > vigilant in ensuring. > > o Extracting this terminology, to present without the context of the RFC= in > > which they are introduced and used, is both futile and a source > of errors and confusion. > > o The domain evolves, new protocols appear and introduce new concepts, > terms. This is captured by carefully defining such in the RFC specifyin= g > that protocol. Any terminology document (aside from all its other issue= s, > indicated in this list) would likely be obsolete and incomplete before > the > ink with which it was written was dry. > > o All RFCs in MANET uses no more than a small subset of the total MANET > (and Internet) terminology. A collective terminology document would, > therefore, necessarily be adding entropy to any single RFC and to the > WG (and to implementers of the WG protocols). > > o Certainly, a large number of terms in this document are entirely out o= f > scope > (such as those pertaining to non-MANET developed concepts or protocols, > e.g., those developed in other parts of the IETF), are useless for the = WG > (such as, but not exclusively, "communication channel" and "communicati= on > > medium"), are by nature ambiguous (such as, but not exclusively, "Upper > Layer" > and "Node"), carry a legacy that renders them difficult to use (such as= , > but > not exclusively, "Logical (virtual) Link", "Physical Link", and "Link")= . > > Thomas > =09 > > On Jul 3, 2012, at 20:14 , Abdussalam Baryun wrote: > >> Hi Jiazi, >> >> On 7/3/12, Jiazi YI wrote: >>> 1. I didn't get the scope of this document. The definitions are from >>> "Communication Medium" to protocol-specific term like "Route Reply >>> Message >>> (RREP)", and even security. I don't think it's necessary to go from the >>> general terms of telecommunication to some specified protocols -- if yo= u >>> define RREP, why not HELLO, TC, and all other message types in the othe= r >>> protocols? >> >> I will add TC and HELLO, and others if they are a general concept to >> be used by MANET. Usually the draft is the start, there will be more >> work to be added, >> >>> >>> 2. A lot of definitions are quite vague and do not make much sense, for >>> example: >>> >>>> "Upper layer" >>> this can be only used in certain context, but not a an depenent term. >> >> ok we may remove it, >> >>> >>>> Reactive Routing: >>>> An on-demand based routing protocol that operates route discover and >>>> maintainance the route(s), to reach the demanded destination(s). >>> >>> what's an on-demand based routing procotol then? A reactive routing? >>> >> >> ok will add this term as well >> >>> >>>> Message: >>>> A MANET data message or routing control message. >>> >>> You are trying to define "message" using "message"? And >> >> I will amend this >> >>> >>>> Routing control messages are either MANET routing protocol messages >>>> or/and >>>> RFC5444 >>>> messages. >>> >>> I'm confused with the relation between routing protocol message and RFC >>> 5444 >>> messages when saying this... >>> Are you tying to say: a chicken can be either a white chicken or/and a >>> cock? >>> plus, RFC 5444 defines both packet and message... >>> >> >> Just trying to say the term "MANET message" doesn't always mean >> RFC5444 message. If you read RFC5444 (general MANET format) you will >> understand that all MANET messages are RFC5444. we still have active >> MANET RFCs that don't use RFC5444 (its a standard document). >> >>> >>> 3. There are a lot controversial terms (phy link, logic link, subnet >>> prefix...) and terms that rarely used in the protocols ( Protocol >>> Sequence >>> Number/Router Sequence Number, Distance Vector Metric/Link Stat Metric, >>> or I >>> don't really know what they really are). >>> >>> Personally, I'm against to have this kind of document that "tries to >>> define >>> everything", with the reasons that the others have stated before. >>> >> >> The document is only a informational document not a standard document, >> The document I am doing may clarify many terms more to the community >> (users) than to the designers (experts). >> >>> best >>> >>> Jiazi YI >>> >> >> I thank you for your input and comments, >> >> Best Regards, >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> http://www.jiaziyi.com >>> LIX, Ecole Polytechnique >>> Route de Saclay 91128 Palaiseau Cedex France >>> >>> >>> >>> >>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>> >>>> Dear All >>>> >>>> I completed the first version of draft on terminology and submited the >>>> draft yesterday (with getting some techniq problem), but needed to >>>> post to know the community feedback and advise. There are other terms >>>> that was not yet included which will need some advise from you. >>>> Thanking you, >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> Abbreviations Used in The submitted Document >>>> >>>> AH Authentication Header >>>> DAD Duplicate Address Detection >>>> DPD Duplicate Packet Detection >>>> DoS Denial of Service >>>> ESP Encapsulating Security Payload >>>> IP IPv4 or IPv6 >>>> ICMP Internet Control Message Protocol >>>> IIB Interface Information Base >>>> ETX Estimated Expected number of Transmission >>>> FIB Forwarding Information Base >>>> LQI Link Quality Indicator >>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>> LLN Low power and Lossy Network >>>> MAC Mediam Access Control >>>> MIB Management Information Base >>>> MTU Maximum Transmission Unit >>>> NBMA Non-Broadcast Multi-Access link >>>> NHDP Neighborhood Discovery Protocol >>>> ND IP Neighbor Discovery >>>> OSPF Open Shortest Path First >>>> RIB Routing Information Base >>>> SMF Simplified Multicast Forwarding >>>> TCP Transmission Control Protocol >>>> UDP User Datagram Protocol >>>> >>>> 2.3 Definitions for MANET Terms >>>> >>>> 2.3.1 Terms Definition of MANET Communication: >>>> >>>> Communications=92 Technology or Facility: >>>> The means employed by two or more devices/subsystems to transfer >>>> and/or receive information between them in one way or two way >>>> communication. MANET communications often uses the wireless >>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>> space, air, water, antenna, coaxial cables, etc.) >>>> >>>> Communication Medium: >>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>> satellite system, etc.) that the routing device uses to communicates >>>> through the transmission medium(s), by providing connectionless and/o= r >>>> connection services that MAY be established. The system medium >>>> includes MAC layer and MAY include the physical Layer. >>>> >>>> Communication Channel: >>>> A subdivision of the physical communication medium (i.e. radio carrier >>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>> independent uses of the medium. Channels may be made available by >>>> subdividing the medium into; distinct time slots, distinct spectral >>>> bands, or coding sequence, etc. >>>> >>>> MANET Protocol: >>>> The communication system/subsystem that operates and maintains the >>>> ad hoc communication technology or facility within MANET. MANET routin= g >>>> Protocols often apply distributed algorithms/techniques to disseminate >>>> or forward routing messages within a MANET routing domain. >>>> >>>> Topology: >>>> An abstract representation of a network (physical or logical), as a >>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>> that >>>> communicate through set of links (E), where the G =3D (V, E). >>>> >>>> Physical-level Topology: >>>> A topology of the communication medium networks consists of routing >>>> devices and physical links. This topology information is updated by >>>> devices=92 technology in the L2 information Base. >>>> >>>> Network-level Topology: >>>> A topology of the communication system networks consists of routers an= d >>>> links. This topology information is updated by routers in its RIB. >>>> >>>> Multihop MANET: >>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach the >>>> destination. >>>> >>>> Reactive Routing: >>>> An on-demand based routing protocol that operates route discover and >>>> maintainance the route(s), to reach the demanded destination(s). >>>> >>>> Proactive Routing: >>>> A topology RIB based routing protocol that operates routes and >>>> maintains >>>> the network topology, to reach its known destination(s). Each router >>>> maintains routes to all reachable destinations at all times, whether o= r >>>> not there is currently any demand to deliver packets to those >>>> destinations. >>>> >>>> Upper Layer: >>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>> >>>> MANET Domain: TBD >>>> >>>> MANET Signaling: >>>> Sending and exchanging some MANET messages/information. >>>> >>>> 2.3.2 Terms Definition of MANET Elements >>>> >>>> Node: >>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>> MANET signaling. It either runs a MANET routing protocol or participat= e >>>> in MANET signaling. >>>> >>>> Router: >>>> A MANET node that MUST implement a MANET routing protocol and forwards >>>> IP packets not explicitly addressed to itself. >>>> >>>> Host: >>>> A node that is not a router. All destinations in MANET that receive >>>> delivered data are hosts. >>>> >>>> Link: >>>> A link between two node interfaces. This link may be Logical >>>> (i.e. virtual) link or physical link. Logical links are between two >>>> logical interfaces and physical links are between two physical >>>> interfaces. Links are either unidirectional or bidirectional >>>> (links may be on-link and off-link: see RFC4861). >>>> >>>> >>>> Physical Link: >>>> a communication facility or medium over which the nodes can >>>> communicate at the link layer, i.e., the layer immediately below >>>> IP. Physical interfaces are the nodes=92 attachment to physical links. >>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>> and shared-media, etc (see link types in ND [RFC4861]). >>>> >>>> Logical (virtual) Link: >>>> a communication facility (at L3, or upper-layer) over which nodes can >>>> communicate. This logical link is between two MANET interfaces exists >>>> if either can be heard by the other. >>>> >>>> Link MTU: >>>> the maximum transmission unit (i.e. maximum unit size in octets), that >>>> can be conveyed in one transmission unit over the link. >>>> >>>> >>>> Node Interface: >>>> A node's point of attachment to a link. Each node MUST have at least >>>> one >>>> interface that SHOULD be assigned an IP address. If there is/are more >>>> than one interface(s) per node then the additional interface(s) MAY be >>>> assigned an IP address. If an interface is not assigned to an IP >>>> address >>>> it MUST be identified by the MANET routing protocol. An interface MAY >>>> be >>>> assigned one or more addresses. >>>> >>>> MANET Interface: >>>> A node interface that participate in; exchange MANET information used >>>> in >>>> MANET routing or exchange information in MANET neighbor node discovery >>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned >>>> to >>>> least one address to communicate. A router interface MUST be >>>> assigned a routable address which is the main address for the >>>> interface. >>>> >>>> >>>> 2.3.3 Terms Definition of MANET Identifications: >>>> >>>> An interface MAY be assigned one or more addresses. If the interface i= s >>>> a logical interface it MAY be assigned to only logical addresses, but >>>> if >>>> it is a physical interface MAY be assigned with physical address >>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>> MANET addresses). >>>> >>>> >>>> MANET Address >>>> A MANET-subnet, node, or interface address. Node and interface >>>> addresses >>>> are either IP addresses or RFC5444 addresses. All subnet addresses are >>>> unicast IP addresses. >>>> >>>> Address Block and TLV: as specified in RFC5444 >>>> >>>> Routable address: >>>> A subnet address which can be a destination address. A router MUST be >>>> able to distinguish a routable address from a non-routable address. >>>> Broadcast, and multicast addresses, limited in scope to less than the >>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>> addresses MAY be considered as routable addresses. >>>> >>>> Main address >>>> A routable address (MANET address) that is assigned to one router's >>>> MANET interface. >>>> >>>> Originator address: >>>> A node address of the node that originated a MANET message (this >>>> message >>>> MUST include the originator address). It MAY be a routable or an >>>> unroutable address. >>>> >>>> subnet prefix >>>> A bit string that consists of some number of initial bits of an IP >>>> address. >>>> >>>> Interface identifier >>>> the remaining low-order bits in the node's IP address after the subnet >>>> prefix. A number used to identify a node's interface on a link. >>>> >>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>> >>>> Packet: >>>> A MANET packet of a header plus payload. These packets are either >>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>> in IP packet. Packets are generated by nodes to be sent to >>>> destination(s) through MANET or through the Internet. RFC5444 packets >>>> information MAY not be used only by MANET routers. >>>> >>>> Message: >>>> A MANET data message or routing control message. Routing control >>>> messages are either MANET routing protocol messages or/and RFC5444 >>>> messages. >>>> >>>> Type Length Value coding (TLV): >>>> A generic way to represent MANET information (as in [RFC5444] and >>>> [RFC5497]). >>>> >>>> Frame: >>>> A L2 protocol TLV with a header and payload. In some technologies the >>>> L2 >>>> operates a MANET routing protocol as a local area networking system. >>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>> telecommunication network. >>>> >>>> Route Request Message (RREQ) >>>> A message is used to discover a valid route to a particular >>>> destination address, called the RREQ Target Node. When a router >>>> processes a RREQ it learns routing information on how to Originator >>>> Node. >>>> >>>> Route Reply Message (RREP) >>>> A message is used to disseminate routing information about >>>> the RREP Target Node to the RREQ Originator Node and the intermediate >>>> routers. >>>> >>>> Route Error Message (RERR) >>>> A message is used to disseminate the information that a route is >>>> not available for one or more particular addresses. A RERR message is >>>> used to indicate that a router does not have a forwarding route >>>> to one or more particular addresses. >>>> >>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>> >>>> Hop-by-hop Routing: (TBD) >>>> A dynamic routing that routes to destination by routing table. >>>> >>>> Source Routing: (TBD) >>>> A dynamic routing that its route path is provided in the IP packet. >>>> >>>> Route Discovery: TBD >>>> >>>> Route Maintenance: TBD >>>> >>>> Neighbor discovery: (TBD) >>>> A node discovers neighbors only if the node receives from it's >>>> neighbors. >>>> >>>> >>>> Multipoint relay (MPR): (TBD) >>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>> its selection of router X1 as an MPR in a recent HELLO message. >>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>> participate in the flooding process of messages received from >>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>> declare link-state information for the link from X1 to Y1. It may >>>> also be both at the same time. >>>> >>>> MPR selector: >>>> A router, Y, is a flooding/routing MPR selector of router X if >>>> router Y has selected router X as a flooding/routing MPR. >>>> >>>> Router Parameters: >>>> boolean or numerical values, specified for each router, and not >>>> specific to an interface. A router MAY change router parameter >>>> values at any time, subject to some MANET constraints. >>>> >>>> MANET Routing Metric: >>>> A MANET routing cost that is governed by specific rules and properties >>>> defined by the MANET routing protocol which captures specific link or >>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>> LQI, >>>> etc. >>>> >>>> Distance Vector Metric >>>> A metric class related to rules of the MANET interface and MANET path >>>> distance. The metric can be calculated by the distance vector routing >>>> algorithm class used by the MANET routing protocol. A metric of the >>>> distance a message or piece of information has traversed. The minimum >>>> value of distance is the number of IP hops traversed. >>>> >>>> Link State Metric >>>> A metric type related to the MANET network-topology status and logical >>>> links' states. This metric is calculated by the link state routing >>>> algorithm class used by the MANET routing protocol. A metric type mayb= e >>>> EXT, LQL, etc. >>>> >>>> Link Metric: TBD >>>> >>>> Neighbor Metric: TBD >>>> >>>> Path accumulated: >>>> The RREQ message accumulates intermediate routers that are in path to >>>> destination(s). >>>> >>>> Protocol Sequence Number: >>>> A Sequence Number related to a MANET protocol that maintained by each >>>> protocol subsystem process. This sequence number is used by other >>>> subsystems to identify the temporal order of protocol information >>>> generated. >>>> >>>> Router Sequence Number: >>>> A router sequence number is maintained by each router process. The >>>> sequence number is used by other routers to identify the temporal >>>> order of routing information generated and ensure loop-free routes. >>>> >>>> MANET Information Base: >>>> A collection of information (in Table or Cache structure) maintained >>>> by MANET protocols and which is to be made available to MANET routing >>>> protocols. An Information Base may be associated with a MANET router >>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB)= . >>>> >>>> RIB Entry: >>>> The RIB entry is a conceptual data structure. Implementations may use >>>> any internal representation that conforms to the semantics of a route >>>> as specified in the router specification. >>>> >>>> 3. IP Considerations and Terminology >>>> >>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>> run/implement at least one MANET routing protocol. The >>>> terminologies described in this document can be used for >>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>> >>>> IP address: >>>> IPv4 addresses or IPv6 addresses. >>>> >>>> IP Packet: >>>> The packet header plus payload as specified in [RFC791] and [RFC2460] >>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >>>> specified by RFC5498. >>>> >>>> Mobile IP considerations: >>>> Mobile IP terms are provided in [RFC6275], and this technology >>>> assists nodes while connected through the Internet domain(s). MANET >>>> is an infrastructure-less network that is able to communicate with >>>> the Internet (i.e. an IP infrastructure network). >>>> >>>> 4. Security Consideration and Terminology >>>> >>>> It is RECOMMENDED that MANET routing protocols consider security >>>> issues because the MANET's transmission medium is wireless which make >>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>> routing information while traversing the MANET MAY be used by an >>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>> >>>> The following are some terminology related to MANET threats and >>>> security. >>>> >>>> Attacker: A node, present in the network and which intentionally seeks >>>> to compromise information based in MANET router(s). The Attacker MAY b= e >>>> a compromised MANET router if obtained MANET identity or routing >>>> information. >>>> >>>> Compromised MANET Router: An attacker router, present in MANET and >>>> which generates syntactically correct routing control messages. Contro= l >>>> messages emitted by compromised router(s) may contain additional >>>> information, or omit information, as compared to a control message >>>> generated by a non-compromised router located in the same MANET >>>> topological position. >>>> >>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>> MANET Router. >>>> >>>> Jamming Attack: >>>> The attacker transmits massive amounts of interfering radio traffic, >>>> which will prevent legitimate traffic (e.g., routing and data traffic) >>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>> influencing Legitimate MANET Router to transmit unnecessary >>>> information. >>>> >>>> Eavesdropping: >>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>> information or the transmitted data information from its neighbor's >>>> transmitted radio packet. Attacker=92s processes MANY be used by attac= ker >>>> to mislead routing. Eavesdropping does not pose a direct threat to the >>>> MANET or to its routing. >>>> >>>> Identity Spoofing: >>>> Attacker sends routing messages, pretending to have the MANET identity >>>> of another node. >>>> >>>> Link Spoofing: >>>> Compromised MANET router sends routing messages to neighbor node(s) >>>> providing incorrect set of link information. >>>> >>>> Replay Attack: >>>> A Compromised router in one MANET region records control traffic >>>> information and replays the recorded information in a different MANET >>>> region (this type of attack is also called the Wormhole attack). >>>> >>>> Broadcast Storm: >>>> Compromised MANET router may attack the MANET by attempting to change >>>> the MANET flooding algorithm(s) to increase routing overheads or/and t= o >>>> increase the route discovery delay. Broadcast storm degrades the data >>>> traffic delivery and MANET performance. >>>> >>>> Falsification in MANET: >>>> The compromised MANET router sends false routing information into >>>> MANET. >>>> False routing information received in MANET, MAY create unrealistic >>>> information bases. >>>> >>>> ICMP Attacks: >>>> The generation of ICMPv6 error messages may be used by compromised >>>> MANET >>>> router to attempt DoS attacks by sending an error-causing source >>>> routing >>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>> the >>>> upper-layer processes, it is possible to perform attacks on the upper >>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>> RECOMMENDED to perform some form of validation to ICMP messages (using >>>> the information contained in the payload of the ICMP message) before >>>> acting upon them. >>>> >>>> Source Routing Attacks: TBD >>>> >>>> Acknowledgments: >>>> >>>> This work has used/modified terms of the following documents: RFC2462, >>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>> Gratefully acknowledge to the IETF community and all contributions. >>>> >>>> Reference: >>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>> NHDP", Work in progress, March, 2012. >>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>> Networks", John Wiley & Sons, March 2007. >>>> ISBN: 978-0-471-75688-0. >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> I hope to get some advise from the Internet community to make the >>>> definitions more suitable/accurate, because I MAY misunderstood. >>>> Thanking you, >>>> >>>> Best Regards >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From Chris.Dearlove@baesystems.com Fri Jul 6 02:52: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 217A821F876F for ; Fri, 6 Jul 2012 02:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_65=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 Q2TxZqeWU3Tb for ; Fri, 6 Jul 2012 02:52:35 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC321F8764 for ; Fri, 6 Jul 2012 02:52:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,536,1336345200"; d="scan'208";a="252691208" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 06 Jul 2012 10:52:49 +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 q669qnci002964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 10:52:49 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Fri, 6 Jul 2012 10:52:49 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "ulrich@herberg.name" Thread-Topic: [manet] NHDP-MIB: ifType Thread-Index: AQHNWzkB6Ui4Di9suEuEkdTMuo7UFZccAlaw Date: Fri, 6 Jul 2012 09:52:48 +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 Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:52:36 -0000 I'll also note that the WG doesn't need DSRv2, even if you have permission = from the original authors to use their work (which I see no sign of). The W= G is charted to produce one reactive protocol. Multiplicity of protocols is= a bad, not a good, thing, unless there is a pressing reason for it. In the= reactive space the WG's adopted solution has been DYMO. Now that having st= alled - though it may now be out of that stall - may (no stronger than that= ) open up the possibility that another protocol already developed to a simi= lar maturity could be considered. LOADng claims to be that, I haven't exami= ned that claim. But a new protocol is clearly not that. --=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 A= bdussalam Baryun Sent: 06 July 2012 06:34 To: ulrich@herberg.name Cc: manet Subject: Re: [manet] NHDP-MIB: ifType ----------------------! 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 I need the NHDP as a MANET interface for the DSRv2, which I suggested for DSRv2 before, so I like/agree that you consider the flag ifType, thanks very much, It is interesting if most manet routings use NHDP or even be possible to use in future, because I think it is a MANET interface as specified in OLSRv2. AB ++++++++ > Hi, > > we are currently working on a revised ID of the NHDP-MIB, as follow-up > on requests during the IESG review. Amongst others, one request from > Thomas Nadeau may affect other MIB documents as well, which is why I > post it on the mailing list. > > The current interface table in the NHDP-MIB is a copy of the interface > MIB, with potentially many entries that are not MANET interfaces (but > still waste space). What we are really interested in is monitoring and > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to > specify a ifType=3DMANET (as allowed by RFC2863 and the IANAifType > registry), and to list only those in the NHDP-MIB. Bob and I propose > that IANA allocates such an ifType, which covers all MANET WG > protocols, i.e. ifType=3DMANET would be used for interfaces running > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an > additional boolean flag which determines whether the interface uses > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only > interfaces would be listed in the nhdpIfTable, but the boolean flag is > false). > > > Best 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. ******************************************************************** From john.dowdell@cassidian.com Fri Jul 6 04:59: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 7895C21F879F for ; Fri, 6 Jul 2012 04:59:04 -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.000, 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 9alLPtldeN4l for ; Fri, 6 Jul 2012 04:59: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 94F3A21F8783 for ; Fri, 6 Jul 2012 04:59:01 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 06 Jul 2012 13:59: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); Fri, 6 Jul 2012 13:59:15 +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, 6 Jul 2012 13:59:14 +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, 6 Jul 2012 13:59:14 +0200 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, 6 Jul 2012 12:59:03 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE0175D6CC@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1a5upXPADgBrxfTTOqeTJAxbG8TwAhv/SA References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com><686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl><2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl><948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com><8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> From: "John Dowdell" To: "Henning Rogge" , "Stan Ratliff (sratliff)" X-OriginalArrivalTime: 06 Jul 2012 11:59:14.0735 (UTC) FILETIME=[C374BBF0:01CD5B6E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19022.006 X-TM-AS-Result: No--27.034200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Greg Harrison \(greharri\)" , "Dearlove, Christopher \(UK\)" , manet@ietf.org, Shawn Jury , "Bo Berry \(boberry\)" Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:59:04 -0000 We had some problems in testing a few months back where the DLEP client on the radio crashed and failed to restart. The immediately attached router didn't catch this condition either. Unless there is something in the protocol that maybe has not been implemented yet, I would like to see something that does this kind of housekeeping. John =20 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 05 July 2012 20:46 To: Stan Ratliff (sratliff) Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry (boberry); Greg Harrison (greharri) Subject: Re: [manet] Status of DLEP-draft at Cisco? On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff) wrote: > OK, that is a model.... but from a router's perspective, how do you tell the difference between a radio that just hasn't hit any triggers (so it doesn't need to tell you anything), and one that's failed? I guess the answer would be that Layer 3 timers would eventually clear that up.... but wait - that's what we were trying to avoid in the first place. > > The same question applies to a radio - how does it tell the difference between a router that just doesn't have anything to say, and one that's crashed? Typical answer is that the side that needs to be discovered sends regular packets with a validity time. If you do not hear anything for more than a validity time you assume that the other side is gone. That works very well for autodetection between services and does not need any state machine. 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 Fri Jul 6 05:05: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 969E921F879A for ; Fri, 6 Jul 2012 05:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 gBuU7YwG+vdT for ; Fri, 6 Jul 2012 05:05:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A621F8794 for ; Fri, 6 Jul 2012 05:05:24 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6637918vcq.31 for ; Fri, 06 Jul 2012 05:05: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 :content-type:content-transfer-encoding; bh=QKz9h8nxssEyddiNqSOIcKJrIuml30BbEWt2ouZ0ECg=; b=qltJpr2BR8WxNcZQjTrssTukPFoGLk8+gdJOSjZJ3kI62mvo9mgMQiMeDgT1m6ukyU C6jRzCwA+FMoMT0LZ/lZ/3T0Fvb5fZondSfDYf8oSQufZFJxf9JAVkBScXch3MUComip 8nhRfp32mY3xx0NosQWgXgAjLriIy2NcCBwOH0OH595oWim7cyGwWiWGCHRmCKFdfd2j ddXAax9p6auqhifH7REv2KzW9pxpcQE4lCoAn1yukM/8see9uf3wMnAAMIagbsB0ZFu7 gNb26H5G/z5lWg4ByG8h5JnfZVEQbxsc+4BDWyUIzaj6C5re7+iec/AHhn0pmTZbAf87 xrfA== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr12013379vdb.66.1341576340525; Fri, 06 Jul 2012 05:05:40 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 05:05:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:05:40 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [manet] How is DLEP Timings and Radio Detections? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:05:25 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Possible Duplication= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +1 with Teco, It is understood from discussion that DLEP is popular and needed by many, I hope this [draft-dlep-02] future will consider dlep technical requirements first and consider the community interests directions. In its abstract; *DLEP* is about : serving the needs of router [MANET] of a *timely* and *accurate* knowledge of the characteristics of the link (speed, state, etc.) in order for the routers [MANET] to make forwarding decisions. IMHO, timer at L2 within abstract of [draft-dlep-02] is a MUST. As mentioned before in discussions DLEP server and client have timer because they time the metric [MAN] in there messaging using RFC5497 (as suggested by one of its authors, and I not sure why not referenced way of timing in [draft-dlep-02]?) . Questions to [draft-dlep-02] Authors: Does DLEP depend on L2 technology[MAN] (e.g. IEEE802.11) to radio-detect for any link-metric or DLEP is doing radio-detection? if depends, how is there detection exchange between dlep-L2 peers with timings. (I don't want to repeat inputs requests below messages pointed, so please consider them as well). I decided to postpone my submission of full review on the [draft-dlep-02] (I already gave many comments on DLEP, and was about to submit my full before 84 meeting), because authors may not use RFC5444 (still not understand their position), but I will try after the new draft-dlep-03, to summary all list comments and review the future draft again after, so we can progress. Previous Timer Discussion Input Messages: ++++++++++++++++++++++++++++++++ http://www.ietf.org/mail-archive/web/manet/current/msg12828.html http://www.ietf.org/mail-archive/web/manet/current/msg12776.html http://www.ietf.org/mail-archive/web/manet/current/msg12408.html References: =3D=3D=3D=3D=3D=3D=3D=3D=3D [draft-dlep-02] http://tools.ietf.org/html/draft-ietf-manet-dlep-02 [MANET] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Best Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D To: Stan Ratliff (sratliff) Subject: Re: [manet] Status of DLEP-draft at Cisco? From: Teco Boot Date: Thu, 5 Jul 2012 21:41:59 +0200 > [snip] >> >> Could you take a look at olsrv2? It provides a good example. TC generati= on is "scheduled or triggered by a change of contents". When congestion ma= y occur, having a shaper is a good thing. >> > > OK, that is a model=85. but from a router's perspective, how do you tell = the difference between a radio that just hasn't hit any triggers (so it doe= sn't need to tell you anything), and one that's failed? I guess the answer = would be that Layer 3 timers Just timers, not _layer 3_ timers. > would eventually clear that up=85. but wait - that's what we were trying = to avoid in the first place. I wonder how lost packets (no acks) are retransmitted, without timers. A simple implementation just has fixed timers. A more advanced mode is sending updates more often when there is something to tell. In ROLL, they have such a mechanism standardized. > The same question applies to a radio - how does it tell the difference be= tween a router that just doesn't have anything to say, and one that's crash= ed? I am not a fan of state in the radio. > We've gone around and around on this issue, and at this point, I don't se= e either of us changing the other's mind... We agree on that :-) But IMHO it is important we know how our protocols actually work. Thanks, Teco From abdussalambaryun@gmail.com Fri Jul 6 05:13: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 25BB721F85F9 for ; Fri, 6 Jul 2012 05:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_65=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 Af0-ZTNy67jN for ; Fri, 6 Jul 2012 05:13:08 -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 52C2D21F85F1 for ; Fri, 6 Jul 2012 05:13:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6653523vbb.31 for ; Fri, 06 Jul 2012 05:13: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=aeyqinQeuCJvaTAlbcGWgJCJQGYC15AJkVe4952sw4o=; b=fDxMOWaqMRwJmuI0RxxcoE6a3v7lQWat0iYZHDm0x4pfue/efJnXVpZo7iEEtJkcMm oI+b+ADG4A48apqjWJ0SwgyUihy4EatgCKa5k2KUmOhbUxG8qQIdSOe4MsBF9Z3YLGje 03bEPDtEK5c0ZvGeu7S1cnHOWu0CynVDyfnEvi6rrBwe3ZPMfxChWy4u+D2sdlU6YheF +ExzdOOxJ0xD5VYs0hc/UsflSow4piPK2NJGDd+3TrgXfL1emskzLTiaSIpbA9hw7uUM Ln0d1fy6xUk1KvtnhbW1PmyCbyUfhW8tAGoIOOC7vZvTqfXt0Ox7MVw6/ITe/XdFG1y9 Nfdw== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr12251165vdi.86.1341576801221; Fri, 06 Jul 2012 05:13:21 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 05:13:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:13:21 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:13:09 -0000 Hi Chris, the point for me is not an individual understanding of the charter, MY effort is aimed to the community needs. So I RECOMMEND that any IETF-WG respects the community or even IETF-participant needs. I respect the WG charter and I am participating, so I hope the WG comments on my work. I know there is a need in DSRv2 and the future will prove my point, I will remind you of this in the future don't worry, AB ========= On 7/6/12, Dearlove, Christopher (UK) wrote: > I'll also note that the WG doesn't need DSRv2, even if you have permission > from the original authors to use their work (which I see no sign of). The WG > is charted to produce one reactive protocol. Multiplicity of protocols is a > bad, not a good, thing, unless there is a pressing reason for it. In the > reactive space the WG's adopted solution has been DYMO. Now that having > stalled - though it may now be out of that stall - may (no stronger than > that) open up the possibility that another protocol already developed to a > similar maturity could be considered. LOADng claims to be that, I haven't > examined that claim. But a new protocol is clearly not that. > > -- > 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 > Abdussalam Baryun > Sent: 06 July 2012 06:34 > To: ulrich@herberg.name > Cc: manet > Subject: Re: [manet] NHDP-MIB: ifType > > ----------------------! 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 > > I need the NHDP as a MANET interface for the DSRv2, which I suggested > for DSRv2 before, so I like/agree that you consider the flag ifType, > thanks very much, > > It is interesting if most manet routings use NHDP or even be possible > to use in future, because I think it is a MANET interface as specified > in OLSRv2. > > AB > ++++++++ >> Hi, >> >> we are currently working on a revised ID of the NHDP-MIB, as follow-up >> on requests during the IESG review. Amongst others, one request from >> Thomas Nadeau may affect other MIB documents as well, which is why I >> post it on the mailing list. >> >> The current interface table in the NHDP-MIB is a copy of the interface >> MIB, with potentially many entries that are not MANET interfaces (but >> still waste space). What we are really interested in is monitoring and >> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >> registry), and to list only those in the NHDP-MIB. Bob and I propose >> that IANA allocates such an ifType, which covers all MANET WG >> protocols, i.e. ifType=MANET would be used for interfaces running >> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >> additional boolean flag which determines whether the interface uses >> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >> interfaces would be listed in the nhdpIfTable, but the boolean flag is >> false). >> >> >> Best 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. > ******************************************************************** > > From Chris.Dearlove@baesystems.com Fri Jul 6 05:18: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 BE04221F8658 for ; Fri, 6 Jul 2012 05:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, J_CHICKENPOX_65=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 Nhz8MIp1zNSe for ; Fri, 6 Jul 2012 05:18:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3C21F8657 for ; Fri, 6 Jul 2012 05:18:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,536,1336345200"; d="scan'208";a="252748870" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 06 Jul 2012 13:19:09 +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 q66CJ9Wh008780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 13:19:09 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.01.0355.002; Fri, 6 Jul 2012 13:19:09 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] NHDP-MIB: ifType Thread-Index: AQHNWzkB6Ui4Di9suEuEkdTMuo7UFZccAlawgAAX7ICAABISQA== Date: Fri, 6 Jul 2012 12:19:08 +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 Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:18:55 -0000 How can you know there is a need for DSRv2? It's not in the WG charter, and= I've not seen anyone else on the list support the idea. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: 06 July 2012 13:13 To: Dearlove, Christopher (UK) Cc: ulrich@herberg.name; manet Subject: Re: [manet] NHDP-MIB: ifType ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, the point for me is not an individual understanding of the charter, MY effort is aimed to the community needs. So I RECOMMEND that any IETF-WG respects the community or even IETF-participant needs. I respect the WG charter and I am participating, so I hope the WG comments on my work. I know there is a need in DSRv2 and the future will prove my point, I will remind you of this in the future don't worry, AB =3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/6/12, Dearlove, Christopher (UK) wrote= : > I'll also note that the WG doesn't need DSRv2, even if you have permissio= n > from the original authors to use their work (which I see no sign of). The= WG > is charted to produce one reactive protocol. Multiplicity of protocols is= a > bad, not a good, thing, unless there is a pressing reason for it. In the > reactive space the WG's adopted solution has been DYMO. Now that having > stalled - though it may now be out of that stall - may (no stronger than > that) open up the possibility that another protocol already developed to = a > similar maturity could be considered. LOADng claims to be that, I haven't > examined that claim. But a new protocol is clearly not that. > > -- > 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 > Abdussalam Baryun > Sent: 06 July 2012 06:34 > To: ulrich@herberg.name > Cc: manet > Subject: Re: [manet] NHDP-MIB: ifType > > ----------------------! 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 > > I need the NHDP as a MANET interface for the DSRv2, which I suggested > for DSRv2 before, so I like/agree that you consider the flag ifType, > thanks very much, > > It is interesting if most manet routings use NHDP or even be possible > to use in future, because I think it is a MANET interface as specified > in OLSRv2. > > AB > ++++++++ >> Hi, >> >> we are currently working on a revised ID of the NHDP-MIB, as follow-up >> on requests during the IESG review. Amongst others, one request from >> Thomas Nadeau may affect other MIB documents as well, which is why I >> post it on the mailing list. >> >> The current interface table in the NHDP-MIB is a copy of the interface >> MIB, with potentially many entries that are not MANET interfaces (but >> still waste space). What we are really interested in is monitoring and >> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >> specify a ifType=3DMANET (as allowed by RFC2863 and the IANAifType >> registry), and to list only those in the NHDP-MIB. Bob and I propose >> that IANA allocates such an ifType, which covers all MANET WG >> protocols, i.e. ifType=3DMANET would be used for interfaces running >> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >> additional boolean flag which determines whether the interface uses >> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >> interfaces would be listed in the nhdpIfTable, but the boolean flag is >> false). >> >> >> Best 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. > ******************************************************************** > > From henning.rogge@fkie.fraunhofer.de Fri Jul 6 05:57: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 02D6421F8501 for ; Fri, 6 Jul 2012 05:57:45 -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 gns-szWmBZy3 for ; Fri, 6 Jul 2012 05:57:44 -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 B2AF921F86A2 for ; Fri, 6 Jul 2012 05:57: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 1Sn86h-0001Ig-3I for manet@ietf.org; Fri, 06 Jul 2012 14:57: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 1Sn86h-0004Vl-0f for manet@ietf.org; Fri, 06 Jul 2012 14:57: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); Fri, 6 Jul 2012 14:57:58 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 6 Jul 2012 14:57:58 +0200 Message-ID: <4FF6E0CD.5010701@fkie.fraunhofer.de> Date: Fri, 6 Jul 2012 14:57:49 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com><686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl><2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl><948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com><8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl> <1B40484159234F4FB6FE11D4C2F408DE0175D6CC@SUKNPT8108.cogent-dsn.local> In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE0175D6CC@SUKNPT8108.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020704060009090608060103" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 06 Jul 2012 12:57:58.0826 (UTC) FILETIME=[F7FA58A0:01CD5B76] X-Virus-Scanned: yes (ClamAV 0.97.3/15114/Fri Jul 6 05:42:19 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: a92cd3ae807afda4389f93ede93df287 Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:57:45 -0000 --------------ms020704060009090608060103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable That is why I (and Teco Boot) suggest moving to a timer based connection = between DLEP radio and router instead of the session system included in=20 Draft 02. The radio just keeps repeating its Discovery message, which all contain=20 a Validity time. If the radio crashes the Discovery messages cease to be = received by the router, which allows the router to detect the connection = loss. The same can be done for information sent by the router in the other=20 direction. Because the radio and the router do not change their state, it should be = much easier to (re)establish a connection between radio and router. With the specified validity-time there is a guaranteed time interval=20 after which the stored information on the other side of the connection=20 will be cleaned up. Henning Rogge On 07/06/2012 01:59 PM, John Dowdell wrote: > We had some problems in testing a few months back where the DLEP client= > on the radio crashed and failed to restart. The immediately attached > router didn't catch this condition either. Unless there is something in= > the protocol that maybe has not been implemented yet, I would like to > see something that does this kind of housekeeping. > > John > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Henning Rogge > Sent: 05 July 2012 20:46 > To: Stan Ratliff (sratliff) > Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry > (boberry); Greg Harrison (greharri) > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff) > wrote: >> OK, that is a model.... but from a router's perspective, how do you > tell the difference between a radio that just hasn't hit any triggers > (so it doesn't need to tell you anything), and one that's failed? I > guess the answer would be that Layer 3 timers would eventually clear > that up.... but wait - that's what we were trying to avoid in the first= > place. >> >> The same question applies to a radio - how does it tell the difference= > between a router that just doesn't have anything to say, and one that's= > crashed? > > Typical answer is that the side that needs to be discovered sends > regular packets with a validity time. If you do not hear anything for > more than a validity time you assume that the other side is gone. > > That works very well for autodetection between services and does not > need any state machine. > > 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 --------------ms020704060009090608060103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA3MDYxMjU3NTZaMCMGCSqGSIb3DQEJBDEWBBQCjoFkU0pXBaOm5hQudjmxz5XWXDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAufyX9m8pLhEoFbgBuO2+nKPZiViWU1lwFT4gdhUgrHwf HjhB1qOw80BNfMjE17hVXILN6Mfo9P2i/+PEW1HJW3Om6+XFfh1VHuoBh8COsGwOLe3rneSe uLwVQdiraWfK67BhG+2W3iFsEZiRmLlYvejcxbRJVApGIiVz9pxR7RDsElBdhcUPibdqwz/9 zcVfyefMvxVfgd+QQtsUPzMvHDaNoXyo38Nm2/WQZ2KDwGE1GNrxpeEFjj2wbm7JveqFLJaf hdE3uYphbpBZMqw949A1YEQFvznv6HlcVW8GDzSssITPkMYjikLnakJ+IBo7Z6fhs2bix5jC HPaRglU5zAAAAAAAAA== --------------ms020704060009090608060103-- From alexandru.petrescu@gmail.com Fri Jul 6 08:12: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 633AD21F869E; Fri, 6 Jul 2012 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-3.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvAVdJSPZq1b; Fri, 6 Jul 2012 08:12:10 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0121F8697; Fri, 6 Jul 2012 08:12:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q66FCN3b016538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 17:12:23 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q66FCNXl020292; Fri, 6 Jul 2012 17:12:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q66FCJcZ005344; Fri, 6 Jul 2012 17:12:23 +0200 Message-ID: <4FF70054.8020301@gmail.com> Date: Fri, 06 Jul 2012 17:12:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rex Buddenberg References: <4FF2A65E.2080000@gmail.com> <1341333653.6804.875.camel@localhost.localdomain> In-Reply-To: <1341333653.6804.875.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:12:11 -0000 Rex, Yes, suggesting that several routes are needed in the case of emergency services like ambulance (and not only emergency, but also simply with train platforms where the service loss is undesirable) should be considered in the design of vehicular communications. Also, I agree that the topology of a single vehicle is something with subnet(s) inside, subnet(s) outside, and a router in the middle. The multiplicity of routes is something natural with this topology of a vehicle: it would need a route towards the inside, another towards the outside and maybe a default route. Alex Le 03/07/2012 18:40, Rex Buddenberg a écrit : > Alex, > > You just HAD to go and ask: > >> I am interested to hear others' oppinions as well. >> > > One of the handful of requirements differences between emergency > services and the rest of us is higher availability and survivability > needs. Skipping some analysis steps, this always boils down to >1 > route. > >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. > > So the English in the above statement is not quite right: 'interface' > MUST be plural in any practical situation: interfaces. > > > LTE is likely to be the big player for the radio-WAN, but there won't be > just one instantiation. A quick scenario: an instrumented ambulance may > have one or more LANs within the vehicle to which several end systems > are attached -- vital signs sensors, VOIP handset for the EMT, etc. > quite possibly a WiFi hotspot ... All attached to a vehicle-mounted > router. The router has interfaces to 1) wired ethernet (for use while > in the garage), 2) commercial LTE (where coverage exists), 3) emergency > services LTE (in US, this is earmarked for 700MHz band and does not yet > in fact exist), 4) WiFi -- pick up a neighborhood hotspot, 5) satellite > or other radio-WAN network for rural areas not reachable by other means. > Any sane high Ao engineering will be picking at least two of the > above. > > > Any help? > > > > On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: >> Hi Abdussalam and thanks for the reply. >> >> Le 01/07/2012 19:31, Abdussalam Baryun a écrit : >>> Hi Alex and All, >>> >>>> Scenario : A router deployed in a moving vehicle, uses its egress >>>> interface to connect to larger-area access network(s) or to other >>>> vehicles. >>> >>> Should it use IPv6-over-LTE? >> >> In our context we consider indeed IPv6 over LTE, for several reasons. >> The 3GPP specs about LTE seem to be very specific and detailed about the >> use of IPv6. (In the past, before LTE, the earlier 3GPP specs were >> mentioning IPv6 but more like an option feature.) >> >> However, the 3GPP specs about the use of IPv6 have some lack of >> specification in the case that the UE (User Terminal) is actually a >> Mobile Router. The Prefix Delegation part may be underspecified. >> >>> Should it use Mobile IP? >> >> Hmm... that is a good question and much can be said about it. I am >> interested to liste others' oppinions as well. >> >> I think Mobile IP may be necessary but not sufficient. In the case of >> direct vehicle-to-vehicle IP communications (non covered areas) Mobile >> IP may not be necessary. It may be that extensions to Neighbor >> Discovery and DHCP could help establish paths within local topologies. >> >> And, when that is done (e.g. exchange routes between two vehicles using >> RA) it may become apparent that interactions between Mobile IP and this >> mechanism may be necessary. >> >>>> Open to discussion: what are the scenarios? >> >> We are interested in describing the scenarios. There may exist several >> possibilities. I think of the following lego-like approach: >> >> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. >> - scenario MR-to-MR - conceive prefixes in Router Advertisements, >> compare to other dynamic routing approaches. >> - scenario MR-to-MR-to-Infrastructure - combine the above two. >> >> Another direction is classify the kinds of vehicles. I think of >> something like this: >> >> - Internet Vehicle (has a plethora of interfaces, long- and short- >> range). >> - Range Extending Vehicle - extends the range of reachability. >> - Leaf Vehicle - like and end-node. >> >> Then there are other scenario statements that could open the path to the >> following: >> - addressability within vehicle, ULA, VIN. >> - problem of bandwidth difference between inside and outside the >> vehicle. >> >>> What are the potential work items? What might be needed, >>> if anything at all? >>> >>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS >>> issues and in your questions directions. I will join the ITS-WG which >>> I think can have relation to MANET [RFC2501]. >> >> Well, hmm. I am happy to hear that but let us go easy about this. >> >> "ITS" at IETF is currently just an informal effort. Its future may be >> ambitious but right now it's not a WG. To do that, we'd need to make a >> BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward. >> >> Secod, RFC2501 and ad-hoc routing are just one possibility to continue >> working on this. Some people may express positive technical feedback >> about MANET and others less so. >> >>> IMO that vehicle routers communications depend on both their >>> communication protocols and the used-network for such communication >>> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO >>> there is no doubt that Mobile IP [RFC6275] is needed for the router's >>> if the communication is through the Internet's domain(s), but if it >>> is through Ad-hoc networks' domain(s) it MAY not be used. >> >> I tend to agree that Mobile IP may not be needed between vehicles which >> communicate directly without infrastructure. Then one wonders _what_ is >> needed? >> >>> The Internet is an infrastructure network and Ad-hoc networks are >>> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with >>> the WG answers, and will read more into the WG inputs regarding these >>> issues. >> >> (see above note about this "WG" acronym which ITS is not currently) >> >>> I will schedule to participate/prepare I-D in the future for ITS >>> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET >>> routing protocol that fits the use-case of ITS and VANET as well. >> >> I am interested to work on scenario/reqs drafts for ITS. >> >> About "DSRv2" - is it still about Routing Headers? >> >> I am interested to hear others' oppinions as well. >> >> Yours, >> >> Alex >> >>> >>> Regards >>> >>> Abdussalam Baryun University of Glamorgan, UK >>> ======================================================= >>> >>> From: Alexandru Petrescu To: its >>> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>> Scenarios, potential topics... >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> >> Welcome to the ITS list at IETF, an informal discussion. >>> >>> Earlier at IETF discussions related to vehicular communications >>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>> few), drafts were published [*]. At times people expressed interest >>> to meet f2f. Now there is this email list. >>> >>> Participants are solicited to work on the topic of using IP in >>> Intelligent Transportation Systems. The term ITS is a placeholder >>> that, in my oppinion, is generic enough to cover many aspects of >>> vehicular communications; vehicles may be wheeled, watered, flown. >>> Ambulance, fire engine, coastal ship are particular examples. >>> >>> Scenario : A router deployed in a moving vehicle, uses its egress >>> interface to connect to larger-area access network(s) or to other >>> vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >>> >>> Example potential work items: - Reqs for IPv6 in vehicular networks >>> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and >>> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p >>> (IPv6-over-foo). - open. >>> >>> I am told about other vehicular drafts and discussions, that I have >>> not cited, existed and still exist (about e.g. ecall). I am >>> interested to learn about all the vehicular activities at IETF. >>> >>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>> >>> Open to discussion: what are the scenarios? What are the potential >>> work items? What might be needed, if anything at all? >>> >>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. >>> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 >>> draft-rosen-ecrit-ecall-04.txt, March 2010. >>> draft-singh-simple-vehicle-info, July 2007. >>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>> draft-bauer-mext-aero-solspace, Sep. 2009. >>> draft-bauer-mext-aero-topology, Sep. 2009. >>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>> >>> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > > > From john.dowdell@cassidian.com Fri Jul 6 08:14: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 9D99221F8609 for ; Fri, 6 Jul 2012 08:14:24 -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 SIAyicoOAHCn for ; Fri, 6 Jul 2012 08:14:23 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id B601921F86FD for ; Fri, 6 Jul 2012 08:14:22 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 06 Jul 2012 17:14: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); Fri, 6 Jul 2012 17:14:36 +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); Fri, 6 Jul 2012 17:14: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); Fri, 6 Jul 2012 17:14:36 +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: Fri, 6 Jul 2012 16:14:36 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE0175D815@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Status of DLEP-draft at Cisco? Thread-Index: Ac1bdyGhVLXFiGjgRwyGwAUeyCfGZQAENTqw References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com><686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl><2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl><948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com><8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl><1B40484159234F4FB6FE11D4C2F408DE0175D6CC@SUKNPT8108.cogent-dsn.local> From: "John Dowdell" To: "Henning Rogge" , X-OriginalArrivalTime: 06 Jul 2012 15:14:36.0050 (UTC) FILETIME=[0DE77720:01CD5B8A] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19022.007 X-TM-AS-Result: No--23.630700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:14:24 -0000 I'd just like to say that this is not a problem with DLEP per se. After = a number of missed heartbeats from an AWOL radio, DLEP will correctly = mark the link as down. It's then a question of what the routing protocol = does. MANET radio links can be quite unstable by their very nature, so = the routing protocol could then decide to wait, to decide if the radio = link is really gone or has just had a short temporary outage. In our = case the wait was too long, and this has since been fixed. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge Sent: 06 July 2012 13:58 To: manet@ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? That is why I (and Teco Boot) suggest moving to a timer based connection = between DLEP radio and router instead of the session system included in=20 Draft 02. The radio just keeps repeating its Discovery message, which all contain=20 a Validity time. If the radio crashes the Discovery messages cease to be = received by the router, which allows the router to detect the connection = loss. The same can be done for information sent by the router in the other=20 direction. Because the radio and the router do not change their state, it should be = much easier to (re)establish a connection between radio and router. With the specified validity-time there is a guaranteed time interval=20 after which the stored information on the other side of the connection=20 will be cleaned up. Henning Rogge On 07/06/2012 01:59 PM, John Dowdell wrote: > We had some problems in testing a few months back where the DLEP = client > on the radio crashed and failed to restart. The immediately attached > router didn't catch this condition either. Unless there is something = in > the protocol that maybe has not been implemented yet, I would like to > see something that does this kind of housekeeping. > > John > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Henning Rogge > Sent: 05 July 2012 20:46 > To: Stan Ratliff (sratliff) > Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry > (boberry); Greg Harrison (greharri) > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff) > wrote: >> OK, that is a model.... but from a router's perspective, how do you > tell the difference between a radio that just hasn't hit any triggers > (so it doesn't need to tell you anything), and one that's failed? I > guess the answer would be that Layer 3 timers would eventually clear > that up.... but wait - that's what we were trying to avoid in the = first > place. >> >> The same question applies to a radio - how does it tell the = difference > between a router that just doesn't have anything to say, and one = that's > crashed? > > Typical answer is that the side that needs to be discovered sends > regular packets with a validity time. If you do not hear anything for > more than a validity time you assume that the other side is gone. > > That works very well for autodetection between services and does not > need any state machine. > > 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 teco@inf-net.nl Fri Jul 6 09:09: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 D21A021F878A for ; Fri, 6 Jul 2012 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 zMomMyvuTkZC for ; Fri, 6 Jul 2012 09:09:09 -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 116B421F87A9 for ; Fri, 6 Jul 2012 09:09:08 -0700 (PDT) Received: by eekd4 with SMTP id d4so3962495eek.31 for ; Fri, 06 Jul 2012 09:09:23 -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=8KeTH0rGRXWU3NNjrlrWjm1FqO4AKiEZcIdMlx6CWAc=; b=pGIAigireSuuxtTAbjDSVNw1vI9V+dtdVPXjOQgztfVWEUUhNx9Ln1dPM7h/S9gpy5 2Xu7h6r+IAsSS7srCszzNDzX2zf5LRhh6GTSSPWiBJzMOV21p8CqYmDXz9VP5uoaWUQ3 Jqzv9sWJztDGJmMB0OKzvwJeeOVFMoT7PlS3mQD2/BOYhO5OHPDsUQ+93k6pZnoDq48N MRA3qLyS5gKqvvhMHMjslb9rrCjVa95RLq1jvjzMMigtedlL8lqEEgNVxqSepy6RCFVM 2N7yGbqcXVJ3GTcNj9dbWjSgM0G3kXBYfQHEFOjncd3LUZkokBvnipTGg+CxAymoJViT 5RuQ== Received: by 10.14.40.20 with SMTP id e20mr7579660eeb.119.1341590962884; Fri, 06 Jul 2012 09:09:22 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id e45sm72683168eeb.6.2012.07.06.09.09.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 09:09:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE0175D815@SUKNPT8108.cogent-dsn.local> Date: Fri, 6 Jul 2012 18:09:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E08EB4C-D06A-49E3-8CF7-C534BFE53740@inf-net.nl> References: <4FF30247.6080303@fkie.fraunhofer.de><72CFBF30-BB0C-4BC3-9906-C733B893598F@cisco.com><54E54670-7CB2-4FDB-9F75-DC95BA916C1D@cisco.com><9F80A277-AFE6-41EB-93BC-CBE1C3DB44B1@cisco.com><7FBE6F47-D1AC-4B46-8471-0090E5552C3A@cisco.com><686F36BF-ACEF-4C3B-AA88-878CD37B8AC2@inf-net.nl><2DC30B2E-9CE0-4A45-9334-6EA4A22EE008@inf-net.nl><948DDB15-DE48-4CE0-9A4D-E4DF8C39C39D@cisco.com><8E95727E-AC3C-4652-8C25-75DD650528BB@inf-net.nl><1B40484159234F4FB6FE11D4C2F408DE0175D6CC@SUKNPT8108.cogent-dsn.local> <1B40484159234F4FB6FE11D4C2F408DE0175D815@SUKNPT8108.cogent-dsn.local> To: John Dowdell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmPLik3cEVJwDshzU62/+S3SJwZSm/iS5cz7NteWsYh7PV13lKaAkTKnLcAyYOwWlzQu+bY Cc: manet@ietf.org Subject: Re: [manet] Status of DLEP-draft at Cisco? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:09:11 -0000 Op 6 jul. 2012, om 17:14 heeft John Dowdell het volgende geschreven: > I'd just like to say that this is not a problem with DLEP per se. = After a number of missed heartbeats from an AWOL radio, DLEP will = correctly mark the link as down. It's then a question of what the = routing protocol does. MANET radio links can be quite unstable by their = very nature, so the routing protocol could then decide to wait, to = decide if the radio link is really gone or has just had a short = temporary outage. In our case the wait was too long, and this has since = been fixed. The reported problem could be an implementation bug. Probably it is. = Maybe a missing piece in recovery of unexpected conditions in state = machines, in the DLEP protocol. This is a reason we should keep = protocols as simple as possible. Maybe at cost of less efficiency. Reminder: I do not have a strong opinion on using a reliable protocol, = or the expiration timer based approach. I dislike strong options, with = lack of understanding other approaches. But yes, I do suggest using = timer based approach for fluent data. At least, we can take a look at = it. Teco >=20 > John >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge > Sent: 06 July 2012 13:58 > To: manet@ietf.org > Subject: Re: [manet] Status of DLEP-draft at Cisco? >=20 > That is why I (and Teco Boot) suggest moving to a timer based = connection=20 > between DLEP radio and router instead of the session system included = in=20 > Draft 02. >=20 > The radio just keeps repeating its Discovery message, which all = contain=20 > a Validity time. If the radio crashes the Discovery messages cease to = be=20 > received by the router, which allows the router to detect the = connection=20 > loss. >=20 > The same can be done for information sent by the router in the other=20= > direction. >=20 > Because the radio and the router do not change their state, it should = be=20 > much easier to (re)establish a connection between radio and router. >=20 > With the specified validity-time there is a guaranteed time interval=20= > after which the stored information on the other side of the connection=20= > will be cleaned up. >=20 > Henning Rogge >=20 > On 07/06/2012 01:59 PM, John Dowdell wrote: >> We had some problems in testing a few months back where the DLEP = client >> on the radio crashed and failed to restart. The immediately attached >> router didn't catch this condition either. Unless there is something = in >> the protocol that maybe has not been implemented yet, I would like to >> see something that does this kind of housekeeping. >>=20 >> John >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >> Of Henning Rogge >> Sent: 05 July 2012 20:46 >> To: Stan Ratliff (sratliff) >> Cc: Dearlove, Christopher (UK); manet@ietf.org; Shawn Jury; Bo Berry >> (boberry); Greg Harrison (greharri) >> Subject: Re: [manet] Status of DLEP-draft at Cisco? >>=20 >> On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff) >> wrote: >>> OK, that is a model.... but from a router's perspective, how do you >> tell the difference between a radio that just hasn't hit any triggers >> (so it doesn't need to tell you anything), and one that's failed? I >> guess the answer would be that Layer 3 timers would eventually clear >> that up.... but wait - that's what we were trying to avoid in the = first >> place. >>>=20 >>> The same question applies to a radio - how does it tell the = difference >> between a router that just doesn't have anything to say, and one = that's >> crashed? >>=20 >> Typical answer is that the side that needs to be discovered sends >> regular packets with a validity time. If you do not hear anything for >> more than a validity time you assume that the other side is gone. >>=20 >> That works very well for autodetection between services and does not >> need any state machine. >>=20 >> Henning Rogge >>=20 >=20 >=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Jul 6 09: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 DF77A21F86A7 for ; Fri, 6 Jul 2012 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=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 VNdoGU+EYaRV for ; Fri, 6 Jul 2012 09:41:40 -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 2651921F86A2 for ; Fri, 6 Jul 2012 09:41:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so15174566pbc.31 for ; Fri, 06 Jul 2012 09:41: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=y9y5XSmJj3TD5mlfsKjRZ0d7Kx1iL0h48IWeeTgChWc=; b=bjqPgpH4ljhCHFUeQPmiANJvj3APlABx5jbUXtxWr0VLJ4j9lasRMKx3WVG51tRaNO jSAO6kiyrJ8imYvxuvdkILzowCtWl3I7ywQioeUV95PDtijhQNASGOxwVolOQFNf+e+p dvl2NRw/tdCZy335vp4bCIf/QoRjQ6Oalzdfo= 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=y9y5XSmJj3TD5mlfsKjRZ0d7Kx1iL0h48IWeeTgChWc=; b=aSnOU0VWeGc8eaV4lELdfuYTQlUCeyhFFcyZuLGdqSvT1faHpHV5PsbjYWZv60YvJY lTiu44FSwBfpY6WnQyFbwxiProhgJgoHAQNyKgDZueJR79XjsjJ+IkYLabrL2+6vZ0T1 ldl7c0aJiAvijnRq23lzMCImUopfKsdLGBWwPCObr8kRY53Z5enFUcnuiCzgMbAt5nKb d9V10g1ih50ibz12QSTWId+fEfT0be3HxY/r4LsmdAlpmR35lbmJmmg3Npumbl9ide1D LPA15mK8CNijD4e0IJz+9ZkrUR/TFhkXZl1EgOEBW54I18qDwH4BJOUczX2o7yoyDWFN sPMw== MIME-Version: 1.0 Received: by 10.68.218.7 with SMTP id pc7mr38241434pbc.88.1341592916868; Fri, 06 Jul 2012 09:41:56 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Fri, 6 Jul 2012 09:41:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 09:41:56 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=e89a8ff244cf3e3c5a04c42bf1de X-Gm-Message-State: ALoCoQn31RtTTVofs70km00OP4E3oHAw6Z2I7CGtmwxB6mCcnr6PTYDivxTLXqHkp/mLKRFLjSx/ Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:41:41 -0000 --e89a8ff244cf3e3c5a04c42bf1de Content-Type: text/plain; charset=ISO-8859-1 Abdussalam, note that this has nothing to do with the protocol itself, but only for the MIB. So, unless you draft a MIB module, you will not need the ifType. If you want to discuss DSRv2 (which I doubt the WG should work on), please open a new email thread, since this thread was only about the NHDP-MIB draft. Best Ulrich On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > +1 > > I need the NHDP as a MANET interface for the DSRv2, which I suggested > for DSRv2 before, so I like/agree that you consider the flag ifType, > thanks very much, > > It is interesting if most manet routings use NHDP or even be possible > to use in future, because I think it is a MANET interface as specified > in OLSRv2. > > AB > ++++++++ > > Hi, > > > > we are currently working on a revised ID of the NHDP-MIB, as follow-up > > on requests during the IESG review. Amongst others, one request from > > Thomas Nadeau may affect other MIB documents as well, which is why I > > post it on the mailing list. > > > > The current interface table in the NHDP-MIB is a copy of the interface > > MIB, with potentially many entries that are not MANET interfaces (but > > still waste space). What we are really interested in is monitoring and > > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to > > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType > > registry), and to list only those in the NHDP-MIB. Bob and I propose > > that IANA allocates such an ifType, which covers all MANET WG > > protocols, i.e. ifType=MANET would be used for interfaces running > > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an > > additional boolean flag which determines whether the interface uses > > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only > > interfaces would be listed in the nhdpIfTable, but the boolean flag is > > false). > > > > > > Best regards > > Ulrich > > > --e89a8ff244cf3e3c5a04c42bf1de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Abdussalam,

note that this has nothing to do with the protocol itsel= f, but only for the MIB. So, unless you draft a MIB module, you will not ne= ed the ifType.

If you want to discuss DSRv2 (which I doubt the WG s= hould work on), please open a new email thread, since this thread was only = about the NHDP-MIB draft.

Best
Ulrich

On Thu, Jul 5, 2012 at= 10:34 PM, Abdussalam Baryun <abdussalambaryun@gmail.com><= /span> wrote:
+1

I need the NHDP as a MANET interface for the DSRv2, which I suggested
for DSRv2 before, so I like/agree that you consider the flag ifType,
thanks very much,

It is interesting if most manet routings use NHDP or even be possible
to use in future, because I think it is a MANET interface as specified
in OLSRv2.

AB
++++++++
> Hi,
>
> we are currently working on a revised ID of the NHDP-MIB, as follow-up=
> on requests during the IESG review. Amongst others, one request from > Thomas Nadeau may affect other MIB documents as well, which is why I > post it on the mailing list.
>
> The current interface table in the NHDP-MIB is a copy of the interface=
> MIB, with potentially many entries that are not MANET interfaces (but<= br> > still waste space). What we are really interested in is monitoring and=
> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to
> specify a ifType=3DMANET (as allowed by RFC2863 and the IANAifType
> registry), and to list only those in the NHDP-MIB. Bob and I propose > that IANA allocates such an ifType, which covers all MANET WG
> protocols, i.e. ifType=3DMANET would be used for interfaces running > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an
> additional boolean flag which determines whether the interface uses > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only<= br> > interfaces would be listed in the nhdpIfTable, but the boolean flag is=
> false).
>
>
> Best regards
> Ulrich
>

--e89a8ff244cf3e3c5a04c42bf1de-- From abdussalambaryun@gmail.com Fri Jul 6 14:12: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 AE38521F85FD for ; Fri, 6 Jul 2012 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_65=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 BgzzjhpY-ZtU for ; Fri, 6 Jul 2012 14:12:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAC3821F85FB for ; Fri, 6 Jul 2012 14:12:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6965576vcq.31 for ; Fri, 06 Jul 2012 14:12: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=Qt//nw3APHHMsCPi6B1040f9XivEMXpyjt2r3x15+8w=; b=CuGooXoe+J3uNRn8K0pmfQAYWgz5HmS05eMIZ6+4kwHW6iEBgxujUKUjpsY6PvwSmu tDlLkdx2YwmX8HNR/9fYdQTF/+eAtvo8e5jqijUCr9grEzB33tkNUICF3/0H0aba9gJF VmSv67Atq1f2T4Z6A5KOVI2sZ9kX0DhdJhplf++XSzlWa2dI4DKay3d0rHHlYXD9Ztr7 EAl3/N++bPxHjOM/G6IdPSohV4J1puYU4TrgfafRl/i9VtaJFtVaP8N2YNIIVqAonZdw 3u4gsvAO4uREB344WduSU44rfi9ocR8ziycK/hjC0vcHxK19Ef3d9aukBoxXD2cbTLnQ nXng== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr15196296vcv.12.1341609140624; Fri, 06 Jul 2012 14:12:20 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 14:12:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 23:12:20 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 21:12:04 -0000 I am sorry I will never post in your threads, if you like that, AB On 7/6/12, Ulrich Herberg wrote: > Abdussalam, > > note that this has nothing to do with the protocol itself, but only for the > MIB. So, unless you draft a MIB module, you will not need the ifType. > > If you want to discuss DSRv2 (which I doubt the WG should work on), please > open a new email thread, since this thread was only about the NHDP-MIB > draft. > > Best > Ulrich > > On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> +1 >> >> I need the NHDP as a MANET interface for the DSRv2, which I suggested >> for DSRv2 before, so I like/agree that you consider the flag ifType, >> thanks very much, >> >> It is interesting if most manet routings use NHDP or even be possible >> to use in future, because I think it is a MANET interface as specified >> in OLSRv2. >> >> AB >> ++++++++ >> > Hi, >> > >> > we are currently working on a revised ID of the NHDP-MIB, as follow-up >> > on requests during the IESG review. Amongst others, one request from >> > Thomas Nadeau may affect other MIB documents as well, which is why I >> > post it on the mailing list. >> > >> > The current interface table in the NHDP-MIB is a copy of the interface >> > MIB, with potentially many entries that are not MANET interfaces (but >> > still waste space). What we are really interested in is monitoring and >> > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >> > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >> > registry), and to list only those in the NHDP-MIB. Bob and I propose >> > that IANA allocates such an ifType, which covers all MANET WG >> > protocols, i.e. ifType=MANET would be used for interfaces running >> > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >> > additional boolean flag which determines whether the interface uses >> > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >> > interfaces would be listed in the nhdpIfTable, but the boolean flag is >> > false). >> > >> > >> > Best regards >> > Ulrich >> > >> > From abdussalambaryun@gmail.com Fri Jul 6 14:21: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 C357B11E80F3 for ; Fri, 6 Jul 2012 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_65=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 M-O2pU2OlXHG for ; Fri, 6 Jul 2012 14:21:16 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A31111E808F for ; Fri, 6 Jul 2012 14:21:16 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6969250vcq.31 for ; Fri, 06 Jul 2012 14:21:33 -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=h9AlqAdCKQTj8hgagGQJCuR+Bl4ZD9sHbONFUKYwL/U=; b=MsLCQvTs6G1rFhvHBusLaZ+FxgwCnYqRPvqlM8vOEZ9zylw/dsLd0glKqW5kHdFidT cVP84D32HRg3q3iOj4KcX/bAOuRGRPS4oHACtRum0Dou8vVFB47OXyCosDBUc9f6fTUw xwY3uj5yQzlLUkrZJXIBApqD901P9KqqAvgAdCZ6MVbTCCyVkCbEYn2JUOnrKvP7veUF Ak8go3ZpbZ2o4IT/YOsRetBbBIRt7py5ZUHNeotNKGL+uwqBPIHtw0+MCUHZj8Wa8AcB /Q+pIHwhzlAmKVeM07GKn+lACOLXPZ3KEOcG9YoPT2FY/KzWfbyalYbQO+jj0Z388bE1 rNNQ== MIME-Version: 1.0 Received: by 10.220.108.1 with SMTP id d1mr15310503vcp.19.1341609693327; Fri, 06 Jul 2012 14:21:33 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 14:21:33 -0700 (PDT) Date: Fri, 6 Jul 2012 23:21:33 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] DSRv2 the first effort idea of Reactive using NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 21:21:17 -0000 Please note that I am working on DSRv2 which will submit to MANET WG. My idea of NHDP used in a reactive protocol was not worked on yet, the DSRv2 was the first to announce this use of NHDP with reactive. Furthermore, I don't think there is restrictions on submitting I-Ds to MANET WG, please read the charter and give me an excluding statement. If yes there is this issue as you refer, I recommend only the Chair or AD to educate me on stop the work I already am doing for weeks. I think when I submit WG then can discuss further, AB ======= On 7/6/12, Dearlove, Christopher (UK) wrote: > How can you know there is a need for DSRv2? It's not in the WG charter, and > I've not seen anyone else on the list support the idea. > > -- > 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 06 July 2012 13:13 > To: Dearlove, Christopher (UK) > Cc: ulrich@herberg.name; manet > Subject: Re: [manet] NHDP-MIB: ifType > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Chris, > > the point for me is not an individual understanding of the charter, MY > effort is aimed to the community needs. So I RECOMMEND that any > IETF-WG respects the community or even IETF-participant needs. I > respect the WG charter and I am participating, so I hope the WG > comments on my work. I know there is a need in DSRv2 and the future > will prove my point, I will remind you of this in the future don't > worry, > > AB > ========= > On 7/6/12, Dearlove, Christopher (UK) > wrote: >> I'll also note that the WG doesn't need DSRv2, even if you have >> permission >> from the original authors to use their work (which I see no sign of). The >> WG >> is charted to produce one reactive protocol. Multiplicity of protocols is >> a >> bad, not a good, thing, unless there is a pressing reason for it. In the >> reactive space the WG's adopted solution has been DYMO. Now that having >> stalled - though it may now be out of that stall - may (no stronger than >> that) open up the possibility that another protocol already developed to >> a >> similar maturity could be considered. LOADng claims to be that, I haven't >> examined that claim. But a new protocol is clearly not that. >> >> -- >> 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 >> Abdussalam Baryun >> Sent: 06 July 2012 06:34 >> To: ulrich@herberg.name >> Cc: manet >> Subject: Re: [manet] NHDP-MIB: ifType >> >> ----------------------! 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 >> >> I need the NHDP as a MANET interface for the DSRv2, which I suggested >> for DSRv2 before, so I like/agree that you consider the flag ifType, >> thanks very much, >> >> It is interesting if most manet routings use NHDP or even be possible >> to use in future, because I think it is a MANET interface as specified >> in OLSRv2. >> >> AB >> ++++++++ >>> Hi, >>> >>> we are currently working on a revised ID of the NHDP-MIB, as follow-up >>> on requests during the IESG review. Amongst others, one request from >>> Thomas Nadeau may affect other MIB documents as well, which is why I >>> post it on the mailing list. >>> >>> The current interface table in the NHDP-MIB is a copy of the interface >>> MIB, with potentially many entries that are not MANET interfaces (but >>> still waste space). What we are really interested in is monitoring and >>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>> that IANA allocates such an ifType, which covers all MANET WG >>> protocols, i.e. ifType=MANET would be used for interfaces running >>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>> additional boolean flag which determines whether the interface uses >>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >>> interfaces would be listed in the nhdpIfTable, but the boolean flag is >>> false). >>> >>> >>> Best 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. >> ******************************************************************** >> >> > > From ulrich@herberg.name Fri Jul 6 14:24: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 8871011E80F3 for ; Fri, 6 Jul 2012 14:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=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 d8z78HJcIlW7 for ; Fri, 6 Jul 2012 14:24:03 -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 7566211E808F for ; Fri, 6 Jul 2012 14:24:03 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so15509870pbc.31 for ; Fri, 06 Jul 2012 14:24:20 -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=9x9vQOR11FrGsVmePFFt67WomqMXdR/P39Hh5NxKsbk=; b=OPZfBnzDRSj4o6souYltFcwEjE2Y774Xsxw/FWr9e1VCOu/72mCatLOfM/KhxkNPM9 zsrAWGRH46wySyjGF+PYqWeAD4ZyeS2SSGPpYS+mAEK1tDZBE+PkrMegQNZWnoSBZr70 ZHtJnjnhBZd92kPMfOa4SqxuL7lh63gYeYXwg= 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=9x9vQOR11FrGsVmePFFt67WomqMXdR/P39Hh5NxKsbk=; b=FhGuMOC7yIY9b/F5CwjYQ/b3Ae4flvCpEuVPS7AYIna8mYyScgFrSaucZaVup5+Mjk xmQc3ywrwAnq2uOl4vP13VKA8WL1WbYRA7HC+7bJW2sCpLYd3MU78E6y6mLC8+uqdwe+ Bu0qOZjXXYspik+qMG+q9PMdZpeMulX+qPlEFHiFRBizg6KlQyGKhhF8FSdbs6PrSScd dsWiVKdikVX3mkUoI/b4xP20M/pho+ILh28ntJ3avC4rsrGBgoFQ+Rbd/t47FyGNS9cb oKCiKuxdwu82rrq+4Qo50AMTGFgKhIZ7jsAqZk7zfyXsLVHu/zh4gDRgOw36gXHKlLTu 9GOQ== MIME-Version: 1.0 Received: by 10.68.218.7 with SMTP id pc7mr40077638pbc.88.1341609860616; Fri, 06 Jul 2012 14:24:20 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Fri, 6 Jul 2012 14:24:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 14:24:20 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=e89a8ff244cf2b500a04c42fe360 X-Gm-Message-State: ALoCoQnJIIS4EBBOVWcSkU1XeBjY/MkMvx0XE68iU6iHnBAo0gTUVRTiLV4SVaAF6bi7/loGy2b9 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 21:24:06 -0000 --e89a8ff244cf2b500a04c42fe360 Content-Type: text/plain; charset=ISO-8859-1 That is not what I said. I just recommended that this email thread is about the ifType in the NHDP-MIB, not about DSRv2, and that such a discussion (if desired) should be in another email with different subject. Best Ulrich On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I am sorry I will never post in your threads, if you like that, > > AB > > On 7/6/12, Ulrich Herberg wrote: > > Abdussalam, > > > > note that this has nothing to do with the protocol itself, but only for > the > > MIB. So, unless you draft a MIB module, you will not need the ifType. > > > > If you want to discuss DSRv2 (which I doubt the WG should work on), > please > > open a new email thread, since this thread was only about the NHDP-MIB > > draft. > > > > Best > > Ulrich > > > > On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < > > abdussalambaryun@gmail.com> wrote: > > > >> +1 > >> > >> I need the NHDP as a MANET interface for the DSRv2, which I suggested > >> for DSRv2 before, so I like/agree that you consider the flag ifType, > >> thanks very much, > >> > >> It is interesting if most manet routings use NHDP or even be possible > >> to use in future, because I think it is a MANET interface as specified > >> in OLSRv2. > >> > >> AB > >> ++++++++ > >> > Hi, > >> > > >> > we are currently working on a revised ID of the NHDP-MIB, as follow-up > >> > on requests during the IESG review. Amongst others, one request from > >> > Thomas Nadeau may affect other MIB documents as well, which is why I > >> > post it on the mailing list. > >> > > >> > The current interface table in the NHDP-MIB is a copy of the interface > >> > MIB, with potentially many entries that are not MANET interfaces (but > >> > still waste space). What we are really interested in is monitoring and > >> > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to > >> > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType > >> > registry), and to list only those in the NHDP-MIB. Bob and I propose > >> > that IANA allocates such an ifType, which covers all MANET WG > >> > protocols, i.e. ifType=MANET would be used for interfaces running > >> > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an > >> > additional boolean flag which determines whether the interface uses > >> > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only > >> > interfaces would be listed in the nhdpIfTable, but the boolean flag is > >> > false). > >> > > >> > > >> > Best regards > >> > Ulrich > >> > > >> > > > --e89a8ff244cf2b500a04c42fe360 Content-Type: text/html; charset=ISO-8859-1 That is not what I said. I just recommended that this email thread is about the ifType in the NHDP-MIB, not about DSRv2, and that such a discussion (if desired) should be in another email with different subject.

Best
Ulrich

On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
I am sorry I will never post in your threads, if you like that,

AB

On 7/6/12, Ulrich Herberg <ulrich@herberg.name> wrote:
> Abdussalam,
>
> note that this has nothing to do with the protocol itself, but only for the
> MIB. So, unless you draft a MIB module, you will not need the ifType.
>
> If you want to discuss DSRv2 (which I doubt the WG should work on), please
> open a new email thread, since this thread was only about the NHDP-MIB
> draft.
>
> Best
> Ulrich
>
> On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun <
> abdussalambaryun@gmail.com> wrote:
>
>> +1
>>
>> I need the NHDP as a MANET interface for the DSRv2, which I suggested
>> for DSRv2 before, so I like/agree that you consider the flag ifType,
>> thanks very much,
>>
>> It is interesting if most manet routings use NHDP or even be possible
>> to use in future, because I think it is a MANET interface as specified
>> in OLSRv2.
>>
>> AB
>> ++++++++
>> > Hi,
>> >
>> > we are currently working on a revised ID of the NHDP-MIB, as follow-up
>> > on requests during the IESG review. Amongst others, one request from
>> > Thomas Nadeau may affect other MIB documents as well, which is why I
>> > post it on the mailing list.
>> >
>> > The current interface table in the NHDP-MIB is a copy of the interface
>> > MIB, with potentially many entries that are not MANET interfaces (but
>> > still waste space). What we are really interested in is monitoring and
>> > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to
>> > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType
>> > registry), and to list only those in the NHDP-MIB. Bob and I propose
>> > that IANA allocates such an ifType, which covers all MANET WG
>> > protocols, i.e. ifType=MANET would be used for interfaces running
>> > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an
>> > additional boolean flag which determines whether the interface uses
>> > NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only
>> > interfaces would be listed in the nhdpIfTable, but the boolean flag is
>> > false).
>> >
>> >
>> > Best regards
>> > Ulrich
>> >
>>
>

--e89a8ff244cf2b500a04c42fe360-- From abdussalambaryun@gmail.com Fri Jul 6 14:34: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 815E211E8121 for ; Fri, 6 Jul 2012 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_65=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 r4Y1veEdewf2 for ; Fri, 6 Jul 2012 14:34:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDDB111E80F3 for ; Fri, 6 Jul 2012 14:34:40 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6975279vcq.31 for ; Fri, 06 Jul 2012 14:34: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=lXhL2rx5njcpunEVjc//6Rp3xQe4LRMcTKgDQEXNDvE=; b=MRa5Zai00koEU7r4w4xLzdVZikfJ+ThfC33bqw06WE09Gxign6XN2VyTff8NwyfvUm K5z4xdXoRjeUzi+DYV9qZUAnFAm5P8m9PUm0ShQKW5FGklnMWRJqQGswibYnMEo3kIH1 oBpEAkqa++5O5z4dRHh5DpVCg585H53tipfpKFAZPdCwlOuagDoe7ff48uxppCebn/Ij q9m9nqY8zXng9CtvT9VCJybIhn1dRpBmsyYusvGYVoB4MIZ6Rxutu8T3Zh+ieUejYyuT hjtdd9G1NdWgW2TjObfBGZllT9tqLtWcwxyJ4DIJTP152hzfTs1COeiS5cjAUAy4kTby h6fg== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr12772932vds.117.1341610498078; Fri, 06 Jul 2012 14:34:58 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 14:34:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jul 2012 23:34:58 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 21:34:47 -0000 Hi Ulrich, You mention routing protocols already please read in your thread, > additional boolean flag which determines whether the interface uses > NHDP or not (i.e., if a router runs both DYMO and NHDP, the > DYMO-only Please note that DYMO will not use NHDP, only if using RFC5444. I just mentioned the DSRv2 I am doing, AB ============================================================ On 7/6/12, Ulrich Herberg wrote: > That is not what I said. I just recommended that this email thread is about > the ifType in the NHDP-MIB, not about DSRv2, and that such a discussion (if > desired) should be in another email with different subject. > > Best > Ulrich > > On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> I am sorry I will never post in your threads, if you like that, >> >> AB >> >> On 7/6/12, Ulrich Herberg wrote: >> > Abdussalam, >> > >> > note that this has nothing to do with the protocol itself, but only for >> the >> > MIB. So, unless you draft a MIB module, you will not need the ifType. >> > >> > If you want to discuss DSRv2 (which I doubt the WG should work on), >> please >> > open a new email thread, since this thread was only about the NHDP-MIB >> > draft. >> > >> > Best >> > Ulrich >> > >> > On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < >> > abdussalambaryun@gmail.com> wrote: >> > >> >> +1 >> >> >> >> I need the NHDP as a MANET interface for the DSRv2, which I suggested >> >> for DSRv2 before, so I like/agree that you consider the flag ifType, >> >> thanks very much, >> >> >> >> It is interesting if most manet routings use NHDP or even be possible >> >> to use in future, because I think it is a MANET interface as specified >> >> in OLSRv2. >> >> >> >> AB >> >> ++++++++ >> >> > Hi, >> >> > >> >> > we are currently working on a revised ID of the NHDP-MIB, as >> >> > follow-up >> >> > on requests during the IESG review. Amongst others, one request from >> >> > Thomas Nadeau may affect other MIB documents as well, which is why I >> >> > post it on the mailing list. >> >> > >> >> > The current interface table in the NHDP-MIB is a copy of the >> >> > interface >> >> > MIB, with potentially many entries that are not MANET interfaces >> >> > (but >> >> > still waste space). What we are really interested in is monitoring >> >> > and >> >> > managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >> >> > specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >> >> > registry), and to list only those in the NHDP-MIB. Bob and I propose >> >> > that IANA allocates such an ifType, which covers all MANET WG >> >> > protocols, i.e. ifType=MANET would be used for interfaces running >> >> > NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >> >> > additional boolean flag which determines whether the interface uses >> >> > NHDP or not (i.e., if a router runs both DYMO and NHDP, the >> >> > DYMO-only >> >> > interfaces would be listed in the nhdpIfTable, but the boolean flag >> >> > is >> >> > false). >> >> > >> >> > >> >> > Best regards >> >> > Ulrich >> >> > >> >> >> > >> > From charliep@computer.org Fri Jul 6 15:04: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 07D5B11E8127 for ; Fri, 6 Jul 2012 15:04:08 -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=-1.004, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, SARE_BAYES_5x8=0.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 evcIs9cFYlyC for ; Fri, 6 Jul 2012 15:04:06 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 8775611E80F3 for ; Fri, 6 Jul 2012 15:04:05 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SnGdG-00073e-BX; Fri, 06 Jul 2012 18:04:10 -0400 Message-ID: <4FF760D4.2060803@computer.org> Date: Fri, 06 Jul 2012 15:04:04 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865174ee40cac4c052f3a92b8192a762b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] DSRv2 the first effort idea of Reactive using NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 22:04:08 -0000 Hello Abdussalam, The idea of DYMO, renamed AODVv2 in the last revision, was exactly to integrate AODV and DSR. The previous protocols were published as Experimental, and the integrated protocol is to be published as a Proposed Standard. In this way, publication of a new protocol named "DSRv2" is likely to inhibit the intended effect of having a single Proposed Standard reactive protocol. Moreover, it is not true that AODVv2 would not use NHDP. In fact, the intention is exactly the opposite. The Proposed Standard reactive protocol SHOULD be able to use NHDP, as presumably should any future protocols promulgated within [manet]. Finally, please observe that a major distinguishing factor for DSR was the inclusion of source routing, which survived in DYMO until we obtained results showing that inclusion of the source route did actually cause a loss of performance in many cases. It would be a big contribution if you were able to exhibit clear results that would resolve the mystery behind these results, but in the meantime it seems unlikely that we should include Path Accumulation or the more restricted version of Source Routing as specified in DSR. Even if we had those results, and thus the mystery were resolved, the proper course of action would not be to specify DSRv2. Instead, we should then specify an extension to the Proposed Standard reactive protocol enabling the proper use of Path Accumulation. Regards, Charlie P. On 7/6/2012 2:21 PM, Abdussalam Baryun wrote: > Please note that I am working on DSRv2 which will submit to MANET WG. > My idea of NHDP used in a reactive protocol was not worked on yet, the > DSRv2 was the first to announce this use of NHDP with reactive. > Furthermore, I don't think there is restrictions on submitting I-Ds > to MANET WG, please read the charter and give me an excluding > statement. If yes there is this issue as you refer, I recommend only > the Chair or AD to educate me on stop the work I already am doing for > weeks. I think when I submit WG then can discuss further, > > AB > ======= > > On 7/6/12, Dearlove, Christopher (UK) wrote: >> How can you know there is a need for DSRv2? It's not in the WG charter, and >> I've not seen anyone else on the list support the idea. >> >> -- >> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 06 July 2012 13:13 >> To: Dearlove, Christopher (UK) >> Cc: ulrich@herberg.name; manet >> Subject: Re: [manet] NHDP-MIB: ifType >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Hi Chris, >> >> the point for me is not an individual understanding of the charter, MY >> effort is aimed to the community needs. So I RECOMMEND that any >> IETF-WG respects the community or even IETF-participant needs. I >> respect the WG charter and I am participating, so I hope the WG >> comments on my work. I know there is a need in DSRv2 and the future >> will prove my point, I will remind you of this in the future don't >> worry, >> >> AB >> ========= >> On 7/6/12, Dearlove, Christopher (UK) >> wrote: >>> I'll also note that the WG doesn't need DSRv2, even if you have >>> permission >>> from the original authors to use their work (which I see no sign of). The >>> WG >>> is charted to produce one reactive protocol. Multiplicity of protocols is >>> a >>> bad, not a good, thing, unless there is a pressing reason for it. In the >>> reactive space the WG's adopted solution has been DYMO. Now that having >>> stalled - though it may now be out of that stall - may (no stronger than >>> that) open up the possibility that another protocol already developed to >>> a >>> similar maturity could be considered. LOADng claims to be that, I haven't >>> examined that claim. But a new protocol is clearly not that. >>> >>> -- >>> 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 >>> Abdussalam Baryun >>> Sent: 06 July 2012 06:34 >>> To: ulrich@herberg.name >>> Cc: manet >>> Subject: Re: [manet] NHDP-MIB: ifType >>> >>> ----------------------! 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 >>> >>> I need the NHDP as a MANET interface for the DSRv2, which I suggested >>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>> thanks very much, >>> >>> It is interesting if most manet routings use NHDP or even be possible >>> to use in future, because I think it is a MANET interface as specified >>> in OLSRv2. >>> >>> AB >>> ++++++++ >>>> Hi, >>>> >>>> we are currently working on a revised ID of the NHDP-MIB, as follow-up >>>> on requests during the IESG review. Amongst others, one request from >>>> Thomas Nadeau may affect other MIB documents as well, which is why I >>>> post it on the mailing list. >>>> >>>> The current interface table in the NHDP-MIB is a copy of the interface >>>> MIB, with potentially many entries that are not MANET interfaces (but >>>> still waste space). What we are really interested in is monitoring and >>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>>> that IANA allocates such an ifType, which covers all MANET WG >>>> protocols, i.e. ifType=MANET would be used for interfaces running >>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>> additional boolean flag which determines whether the interface uses >>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >>>> interfaces would be listed in the nhdpIfTable, but the boolean flag is >>>> false). >>>> >>>> >>>> Best 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. >>> ******************************************************************** >>> >>> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From ietf@thomasclausen.org Fri Jul 6 15:06: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 9CDD911E8127 for ; Fri, 6 Jul 2012 15:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, 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 hI4nkWIcR2r9 for ; Fri, 6 Jul 2012 15:06:15 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 71D8B11E80BF for ; Fri, 6 Jul 2012 15:06:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 70FD3558329 for ; Fri, 6 Jul 2012 15:06:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 667D961291; Fri, 6 Jul 2012 15:06:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.247] (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 95A2F6128F; Fri, 6 Jul 2012 15:06: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: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Sat, 7 Jul 2012 00:07:03 +0200 To: Abdussalam Baryun Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DSRv2 the first effort idea of Reactive using NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 22:06:16 -0000 Very Incorrect postulate.=20 LOADng, AODV, and other reactive protocols can well be used with NHDP -- and= this, without requiring any special provisioning. The reason there's no I-D stating that is that it's....well...obvious and re= quires no special provisioning or considerations for interoperability.... Should we have a specification for how to use HTTP with TCP also? --=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 6 Jul 2012, at 23:21, Abdussalam Baryun wrot= e: > Please note that I am working on DSRv2 which will submit to MANET WG. > My idea of NHDP used in a reactive protocol was not worked on yet, the > DSRv2 was the first to announce this use of NHDP with reactive. > Furthermore, I don't think there is restrictions on submitting I-Ds > to MANET WG, please read the charter and give me an excluding > statement. If yes there is this issue as you refer, I recommend only > the Chair or AD to educate me on stop the work I already am doing for > weeks. I think when I submit WG then can discuss further, >=20 > AB > =3D=3D=3D=3D=3D=3D=3D >=20 > On 7/6/12, Dearlove, Christopher (UK) wrot= e: >> How can you know there is a need for DSRv2? It's not in the WG charter, a= nd >> I've not seen anyone else on the list support the idea. >>=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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 06 July 2012 13:13 >> To: Dearlove, Christopher (UK) >> Cc: ulrich@herberg.name; manet >> Subject: Re: [manet] NHDP-MIB: ifType >>=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 >> Hi Chris, >>=20 >> the point for me is not an individual understanding of the charter, MY >> effort is aimed to the community needs. So I RECOMMEND that any >> IETF-WG respects the community or even IETF-participant needs. I >> respect the WG charter and I am participating, so I hope the WG >> comments on my work. I know there is a need in DSRv2 and the future >> will prove my point, I will remind you of this in the future don't >> worry, >>=20 >> AB >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 7/6/12, Dearlove, Christopher (UK) >> wrote: >>> I'll also note that the WG doesn't need DSRv2, even if you have >>> permission >>> from the original authors to use their work (which I see no sign of). Th= e >>> WG >>> is charted to produce one reactive protocol. Multiplicity of protocols i= s >>> a >>> bad, not a good, thing, unless there is a pressing reason for it. In the= >>> reactive space the WG's adopted solution has been DYMO. Now that having >>> stalled - though it may now be out of that stall - may (no stronger than= >>> that) open up the possibility that another protocol already developed to= >>> a >>> similar maturity could be considered. LOADng claims to be that, I haven'= t >>> examined that claim. But a new protocol is clearly not that. >>>=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 O= f >>> Abdussalam Baryun >>> Sent: 06 July 2012 06:34 >>> To: ulrich@herberg.name >>> Cc: manet >>> Subject: Re: [manet] NHDP-MIB: ifType >>>=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 >>> +1 >>>=20 >>> I need the NHDP as a MANET interface for the DSRv2, which I suggested >>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>> thanks very much, >>>=20 >>> It is interesting if most manet routings use NHDP or even be possible >>> to use in future, because I think it is a MANET interface as specified >>> in OLSRv2. >>>=20 >>> AB >>> ++++++++ >>>> Hi, >>>>=20 >>>> we are currently working on a revised ID of the NHDP-MIB, as follow-up >>>> on requests during the IESG review. Amongst others, one request from >>>> Thomas Nadeau may affect other MIB documents as well, which is why I >>>> post it on the mailing list. >>>>=20 >>>> The current interface table in the NHDP-MIB is a copy of the interface >>>> MIB, with potentially many entries that are not MANET interfaces (but >>>> still waste space). What we are really interested in is monitoring and >>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>> specify a ifType=3DMANET (as allowed by RFC2863 and the IANAifType >>>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>>> that IANA allocates such an ifType, which covers all MANET WG >>>> protocols, i.e. ifType=3DMANET would be used for interfaces running >>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>> additional boolean flag which determines whether the interface uses >>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >>>> interfaces would be listed in the nhdpIfTable, but the boolean flag is >>>> false). >>>>=20 >>>>=20 >>>> Best regards >>>> Ulrich >>>>=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 >>>=20 >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jul 6 15:43: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 4094D21F85C0 for ; Fri, 6 Jul 2012 15:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_65=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 lhzI6FTVKAwh for ; Fri, 6 Jul 2012 15:43:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7F1C21F85B5 for ; Fri, 6 Jul 2012 15:43:33 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6999532vcq.31 for ; Fri, 06 Jul 2012 15:43:51 -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=cmNl/Il5IStAkSN6WG+q3Al6fegnfutZ7EsRK03wfdg=; b=knYG8H+BHK2lr7L0EBqAuhcqlbQNepZpkYVwxIJUM30rxsp75g+o72hDDuWP3svGDO JIvdUAnQBROlB8MLUDL6Yz7jM+XziPeOMQii6npdg+PiUHllUnmINOVl0+5pa+hNUAs3 k6wuA4zeoa5uR7pQmIeowSHbEEjLl8BICALERsLuthKI0gyY9bRAkLXUw7UjBZmGKAvM weOr+cz3QG0i3qNCVIGuGU2fzUworO11Zn72QcbzWrcDfKPtdNyccGo6vj51ie9VLgWp ywi1m/H1tKZUhqygyCbfUAxk9vTRD5m4ck0jsNR/6ofzO8+NTCqj2AWUxNwFvXr3Z1Uk i5tA== MIME-Version: 1.0 Received: by 10.220.108.1 with SMTP id d1mr15407563vcp.19.1341614631122; Fri, 06 Jul 2012 15:43:51 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 15:43:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 7 Jul 2012 00:43:51 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] DSRv2 the first effort idea of Reactive using NHDP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 22:43:35 -0000 I thought that one participant say that we need only one reactive, so if we include LOAD we can include others, AB On 7/7/12, Thomas Heide Clausen wrote: > Very Incorrect postulate. > > LOADng, AODV, and other reactive protocols can well be used with NHDP -- and > this, without requiring any special provisioning. > > The reason there's no I-D stating that is that it's....well...obvious and > requires no special provisioning or considerations for interoperability.... > > Should we have a specification for how to use HTTP with TCP also? > > -- > 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 6 Jul 2012, at 23:21, Abdussalam Baryun > wrote: > >> Please note that I am working on DSRv2 which will submit to MANET WG. >> My idea of NHDP used in a reactive protocol was not worked on yet, the >> DSRv2 was the first to announce this use of NHDP with reactive. >> Furthermore, I don't think there is restrictions on submitting I-Ds >> to MANET WG, please read the charter and give me an excluding >> statement. If yes there is this issue as you refer, I recommend only >> the Chair or AD to educate me on stop the work I already am doing for >> weeks. I think when I submit WG then can discuss further, >> >> AB >> ======= >> >> On 7/6/12, Dearlove, Christopher (UK) >> wrote: >>> How can you know there is a need for DSRv2? It's not in the WG charter, >>> and >>> I've not seen anyone else on the list support the idea. >>> >>> -- >>> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> Sent: 06 July 2012 13:13 >>> To: Dearlove, Christopher (UK) >>> Cc: ulrich@herberg.name; manet >>> Subject: Re: [manet] NHDP-MIB: ifType >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Hi Chris, >>> >>> the point for me is not an individual understanding of the charter, MY >>> effort is aimed to the community needs. So I RECOMMEND that any >>> IETF-WG respects the community or even IETF-participant needs. I >>> respect the WG charter and I am participating, so I hope the WG >>> comments on my work. I know there is a need in DSRv2 and the future >>> will prove my point, I will remind you of this in the future don't >>> worry, >>> >>> AB >>> ========= >>> On 7/6/12, Dearlove, Christopher (UK) >>> wrote: >>>> I'll also note that the WG doesn't need DSRv2, even if you have >>>> permission >>>> from the original authors to use their work (which I see no sign of). >>>> The >>>> WG >>>> is charted to produce one reactive protocol. Multiplicity of protocols >>>> is >>>> a >>>> bad, not a good, thing, unless there is a pressing reason for it. In >>>> the >>>> reactive space the WG's adopted solution has been DYMO. Now that having >>>> stalled - though it may now be out of that stall - may (no stronger >>>> than >>>> that) open up the possibility that another protocol already developed >>>> to >>>> a >>>> similar maturity could be considered. LOADng claims to be that, I >>>> haven't >>>> examined that claim. But a new protocol is clearly not that. >>>> >>>> -- >>>> 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 >>>> Abdussalam Baryun >>>> Sent: 06 July 2012 06:34 >>>> To: ulrich@herberg.name >>>> Cc: manet >>>> Subject: Re: [manet] NHDP-MIB: ifType >>>> >>>> ----------------------! 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 >>>> >>>> I need the NHDP as a MANET interface for the DSRv2, which I suggested >>>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>>> thanks very much, >>>> >>>> It is interesting if most manet routings use NHDP or even be possible >>>> to use in future, because I think it is a MANET interface as specified >>>> in OLSRv2. >>>> >>>> AB >>>> ++++++++ >>>>> Hi, >>>>> >>>>> we are currently working on a revised ID of the NHDP-MIB, as follow-up >>>>> on requests during the IESG review. Amongst others, one request from >>>>> Thomas Nadeau may affect other MIB documents as well, which is why I >>>>> post it on the mailing list. >>>>> >>>>> The current interface table in the NHDP-MIB is a copy of the interface >>>>> MIB, with potentially many entries that are not MANET interfaces (but >>>>> still waste space). What we are really interested in is monitoring and >>>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>>>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>>>> that IANA allocates such an ifType, which covers all MANET WG >>>>> protocols, i.e. ifType=MANET would be used for interfaces running >>>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>> additional boolean flag which determines whether the interface uses >>>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >>>>> interfaces would be listed in the nhdpIfTable, but the boolean flag is >>>>> false). >>>>> >>>>> >>>>> Best 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. >>>> ******************************************************************** >>>> >>>> >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From charliep@computer.org Fri Jul 6 16:02: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 E6CD911E80AA for ; Fri, 6 Jul 2012 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, J_CHICKENPOX_65=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 y+0fXxGe4pkr for ; Fri, 6 Jul 2012 16:02:42 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id AA71211E8093 for ; Fri, 6 Jul 2012 16:02:42 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SnHYB-0007pv-T2; Fri, 06 Jul 2012 19:03:00 -0400 Message-ID: <4FF76E9E.60305@computer.org> Date: Fri, 06 Jul 2012 16:02:54 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Abdussalam Baryun , manet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b3a4a713e190bf8a2fe37bd0a544919c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Subject: [manet] Re: AODVv2 as the reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 23:02:44 -0000 Hello Abdussalam, Actually, I don't mean to say that there must only be one reactive protocol. But I don't see what would motivate the separate development of DSRv2 specifically. My current belief is that few people in [manet] would desire to see such a development; I would not. My *preference* would be to make every attempt to insure that the IETF Proposed Standard reactive protocol serves the widest feasible applicability for ad hoc networks. So, for instance it is understood that for some networks, proactive protocols are better. And, I understand that some networks might need a reactive protocol other than AODV, the simplest example being networks that cannot sustain a network-layer protocol. Regards, Charlie P. PS. I forgot to CC: manet in my previous reply. On 7/6/2012 3:42 PM, Abdussalam Baryun wrote: > Hi Charlie, > > I thank you for your comments. I agree that AODVv2 is the first > reactive protocol effort (is the needed one) and in the meeting 83 I > heard of the LOADng as I think is a second recommended. After I am > thinking of the DSRv2. So do you mean we should only have one reactive > protocol and no work should be done (while doing another) as a new > reactive protocol. I see no restriction in charter, it does mentions > one reactive (at least) and proactive, but not mentioned at most > reactive and proactive. > > Abdussalam > ========== > On 7/7/12, Charles E. Perkins wrote: >> Hello Abdussalam, >> >> The idea of DYMO, renamed AODVv2 in the last revision, was exactly >> to integrate AODV and DSR. The previous protocols were published >> as Experimental, and the integrated protocol is to be published as a >> Proposed Standard. In this way, publication of a new protocol named >> "DSRv2" is likely to inhibit the intended effect of having a single >> Proposed Standard reactive protocol. >> >> Moreover, it is not true that AODVv2 would not use NHDP. In fact, >> the intention is exactly the opposite. The Proposed Standard reactive >> protocol SHOULD be able to use NHDP, as presumably should any >> future protocols promulgated within [manet]. >> >> Finally, please observe that a major distinguishing factor for DSR >> was the inclusion of source routing, which survived in DYMO until >> we obtained results showing that inclusion of the source route did >> actually cause a loss of performance in many cases. It would be a >> big contribution if you were able to exhibit clear results that would >> resolve the mystery behind these results, but in the meantime it >> seems unlikely that we should include Path Accumulation or the >> more restricted version of Source Routing as specified in DSR. >> >> Even if we had those results, and thus the mystery were resolved, >> the proper course of action would not be to specify DSRv2. Instead, >> we should then specify an extension to the Proposed Standard >> reactive protocol enabling the proper use of Path Accumulation. >> >> Regards, >> Charlie P. >> >> >> On 7/6/2012 2:21 PM, Abdussalam Baryun wrote: >>> Please note that I am working on DSRv2 which will submit to MANET WG. >>> My idea of NHDP used in a reactive protocol was not worked on yet, the >>> DSRv2 was the first to announce this use of NHDP with reactive. >>> Furthermore, I don't think there is restrictions on submitting I-Ds >>> to MANET WG, please read the charter and give me an excluding >>> statement. If yes there is this issue as you refer, I recommend only >>> the Chair or AD to educate me on stop the work I already am doing for >>> weeks. I think when I submit WG then can discuss further, >>> >>> AB >>> ======= >>> >>> On 7/6/12, Dearlove, Christopher (UK) >>> wrote: >>>> How can you know there is a need for DSRv2? It's not in the WG charter, >>>> and >>>> I've not seen anyone else on the list support the idea. >>>> >>>> -- >>>> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>> Sent: 06 July 2012 13:13 >>>> To: Dearlove, Christopher (UK) >>>> Cc: ulrich@herberg.name; manet >>>> Subject: Re: [manet] NHDP-MIB: ifType >>>> >>>> ----------------------! WARNING ! ---------------------- >>>> This message originates from outside our organisation, >>>> either from an external partner or from the internet. >>>> Keep this in mind if you answer this message. >>>> Follow the 'Report Suspicious Emails' link on IT matters >>>> for instructions on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>> >>>> Hi Chris, >>>> >>>> the point for me is not an individual understanding of the charter, MY >>>> effort is aimed to the community needs. So I RECOMMEND that any >>>> IETF-WG respects the community or even IETF-participant needs. I >>>> respect the WG charter and I am participating, so I hope the WG >>>> comments on my work. I know there is a need in DSRv2 and the future >>>> will prove my point, I will remind you of this in the future don't >>>> worry, >>>> >>>> AB >>>> ========= >>>> On 7/6/12, Dearlove, Christopher (UK) >>>> wrote: >>>>> I'll also note that the WG doesn't need DSRv2, even if you have >>>>> permission >>>>> from the original authors to use their work (which I see no sign of). >>>>> The >>>>> WG >>>>> is charted to produce one reactive protocol. Multiplicity of protocols >>>>> is >>>>> a >>>>> bad, not a good, thing, unless there is a pressing reason for it. In >>>>> the >>>>> reactive space the WG's adopted solution has been DYMO. Now that having >>>>> stalled - though it may now be out of that stall - may (no stronger >>>>> than >>>>> that) open up the possibility that another protocol already developed >>>>> to >>>>> a >>>>> similar maturity could be considered. LOADng claims to be that, I >>>>> haven't >>>>> examined that claim. But a new protocol is clearly not that. >>>>> >>>>> -- >>>>> 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 >>>>> Abdussalam Baryun >>>>> Sent: 06 July 2012 06:34 >>>>> To: ulrich@herberg.name >>>>> Cc: manet >>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>> >>>>> ----------------------! 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 >>>>> >>>>> I need the NHDP as a MANET interface for the DSRv2, which I suggested >>>>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>>>> thanks very much, >>>>> >>>>> It is interesting if most manet routings use NHDP or even be possible >>>>> to use in future, because I think it is a MANET interface as specified >>>>> in OLSRv2. >>>>> >>>>> AB >>>>> ++++++++ >>>>>> Hi, >>>>>> >>>>>> we are currently working on a revised ID of the NHDP-MIB, as follow-up >>>>>> on requests during the IESG review. Amongst others, one request from >>>>>> Thomas Nadeau may affect other MIB documents as well, which is why I >>>>>> post it on the mailing list. >>>>>> >>>>>> The current interface table in the NHDP-MIB is a copy of the interface >>>>>> MIB, with potentially many entries that are not MANET interfaces (but >>>>>> still waste space). What we are really interested in is monitoring and >>>>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>>>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>>>>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>>>>> that IANA allocates such an ifType, which covers all MANET WG >>>>>> protocols, i.e. ifType=MANET would be used for interfaces running >>>>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>>> additional boolean flag which determines whether the interface uses >>>>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-only >>>>>> interfaces would be listed in the nhdpIfTable, but the boolean flag is >>>>>> false). >>>>>> >>>>>> >>>>>> Best 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. >>>>> ******************************************************************** >>>>> >>>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> -- >> Regards, >> Charlie P. >> >> -- Regards, Charlie P. From sratliff@cisco.com Fri Jul 6 20:07: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 B2C3711E808C for ; Fri, 6 Jul 2012 20:07:52 -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_65=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 80D2mUnvxPc1 for ; Fri, 6 Jul 2012 20:07:51 -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 762CE11E8072 for ; Fri, 6 Jul 2012 20:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=11627; q=dns/txt; s=iport; t=1341630488; x=1342840088; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NRmF1/+FG4HaIcbEzlLMSPfK4AXRC7Q7zcG1H3UsvH4=; b=mqni3ZtlKRBzPAfpKFKVHSPWIsNf++WO1u3U8S+JvQtfFrVUfBGq/ZfI N+YqDTuIVtThXsxOwe2Wd7denxPHjzrh+sr0RAozzq0QR1D1S2VqgmM5f jZ5v1DRChQbN+aO3XuuTnTSmRKjbbFfKOLLbPvfPr7Ljel4+7u0v5thnq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADWn90+tJV2Z/2dsb2JhbABFt1+BB4IYAQEBAwEBAQEPAScbGQMIDAQCAQgRBAEBAR4JByEGCxQJCAIEDgUUBweHWwMGBQuaTpYvDYlOilNmFA6FCmADlTeLA4MagWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,541,1336348800"; d="scan'208";a="99590462" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2012 03:08:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q673875o021579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jul 2012 03:08:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Fri, 6 Jul 2012 22:08:07 -0500 From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" Thread-Topic: [manet] Re: AODVv2 as the reactive protocol Thread-Index: AQHNW8uBX27PM8jCUUC+j9LjmaMrtJcdd66A Date: Sat, 7 Jul 2012 03:08:06 +0000 Message-ID: <5DBAA85B-47D1-4A29-B2C1-F8DD65FF1575@cisco.com> References: <4FF76E9E.60305@computer.org> In-Reply-To: <4FF76E9E.60305@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.179.214] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.003 x-tm-as-result: No--67.907700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Re: AODVv2 as the reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 03:07:52 -0000 The working group is chartered to produce a reactive protocol. By that, we'= ve always assumed only one. Multiple specifications would, IMO, require a c= lear requirements definition of *why* they are needed - why some deployment= s would need "protocol Y" instead of "protocol X".=20 Regards, Stan On Jul 6, 2012, at 7:02 PM, Charles E. Perkins wrote: >=20 > Hello Abdussalam, >=20 > Actually, I don't mean to say that there must only be one reactive > protocol. But I don't see what would motivate the separate > development of DSRv2 specifically. My current belief is that > few people in [manet] would desire to see such a development; > I would not. >=20 > My *preference* would be to make every attempt to insure that > the IETF Proposed Standard reactive protocol serves the widest > feasible applicability for ad hoc networks. So, for instance it is > understood that for some networks, proactive protocols are better. > And, I understand that some networks might need a reactive > protocol other than AODV, the simplest example being networks > that cannot sustain a network-layer protocol. >=20 > Regards, > Charlie P. >=20 > PS. I forgot to CC: manet in my previous reply. >=20 >=20 > On 7/6/2012 3:42 PM, Abdussalam Baryun wrote: >> Hi Charlie, >>=20 >> I thank you for your comments. I agree that AODVv2 is the first >> reactive protocol effort (is the needed one) and in the meeting 83 I >> heard of the LOADng as I think is a second recommended. After I am >> thinking of the DSRv2. So do you mean we should only have one reactive >> protocol and no work should be done (while doing another) as a new >> reactive protocol. I see no restriction in charter, it does mentions >> one reactive (at least) and proactive, but not mentioned at most >> reactive and proactive. >>=20 >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 7/7/12, Charles E. Perkins wrote: >>> Hello Abdussalam, >>>=20 >>> The idea of DYMO, renamed AODVv2 in the last revision, was exactly >>> to integrate AODV and DSR. The previous protocols were published >>> as Experimental, and the integrated protocol is to be published as a >>> Proposed Standard. In this way, publication of a new protocol named >>> "DSRv2" is likely to inhibit the intended effect of having a single >>> Proposed Standard reactive protocol. >>>=20 >>> Moreover, it is not true that AODVv2 would not use NHDP. In fact, >>> the intention is exactly the opposite. The Proposed Standard reactive >>> protocol SHOULD be able to use NHDP, as presumably should any >>> future protocols promulgated within [manet]. >>>=20 >>> Finally, please observe that a major distinguishing factor for DSR >>> was the inclusion of source routing, which survived in DYMO until >>> we obtained results showing that inclusion of the source route did >>> actually cause a loss of performance in many cases. It would be a >>> big contribution if you were able to exhibit clear results that would >>> resolve the mystery behind these results, but in the meantime it >>> seems unlikely that we should include Path Accumulation or the >>> more restricted version of Source Routing as specified in DSR. >>>=20 >>> Even if we had those results, and thus the mystery were resolved, >>> the proper course of action would not be to specify DSRv2. Instead, >>> we should then specify an extension to the Proposed Standard >>> reactive protocol enabling the proper use of Path Accumulation. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> On 7/6/2012 2:21 PM, Abdussalam Baryun wrote: >>>> Please note that I am working on DSRv2 which will submit to MANET WG. >>>> My idea of NHDP used in a reactive protocol was not worked on yet, the >>>> DSRv2 was the first to announce this use of NHDP with reactive. >>>> Furthermore, I don't think there is restrictions on submitting I-Ds >>>> to MANET WG, please read the charter and give me an excluding >>>> statement. If yes there is this issue as you refer, I recommend only >>>> the Chair or AD to educate me on stop the work I already am doing for >>>> weeks. I think when I submit WG then can discuss further, >>>>=20 >>>> AB >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> On 7/6/12, Dearlove, Christopher (UK) >>>> wrote: >>>>> How can you know there is a need for DSRv2? It's not in the WG charte= r, >>>>> and >>>>> I've not seen anyone else on the list support the idea. >>>>>=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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>>> Sent: 06 July 2012 13:13 >>>>> To: Dearlove, Christopher (UK) >>>>> Cc: ulrich@herberg.name; manet >>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>>=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 >>>>> Hi Chris, >>>>>=20 >>>>> the point for me is not an individual understanding of the charter, M= Y >>>>> effort is aimed to the community needs. So I RECOMMEND that any >>>>> IETF-WG respects the community or even IETF-participant needs. I >>>>> respect the WG charter and I am participating, so I hope the WG >>>>> comments on my work. I know there is a need in DSRv2 and the future >>>>> will prove my point, I will remind you of this in the future don't >>>>> worry, >>>>>=20 >>>>> AB >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> On 7/6/12, Dearlove, Christopher (UK) >>>>> wrote: >>>>>> I'll also note that the WG doesn't need DSRv2, even if you have >>>>>> permission >>>>>> from the original authors to use their work (which I see no sign of)= . >>>>>> The >>>>>> WG >>>>>> is charted to produce one reactive protocol. Multiplicity of protoco= ls >>>>>> is >>>>>> a >>>>>> bad, not a good, thing, unless there is a pressing reason for it. In >>>>>> the >>>>>> reactive space the WG's adopted solution has been DYMO. Now that hav= ing >>>>>> stalled - though it may now be out of that stall - may (no stronger >>>>>> than >>>>>> that) open up the possibility that another protocol already develope= d >>>>>> to >>>>>> a >>>>>> similar maturity could be considered. LOADng claims to be that, I >>>>>> haven't >>>>>> examined that claim. But a new protocol is clearly not that. >>>>>>=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 Beha= lf >>>>>> Of >>>>>> Abdussalam Baryun >>>>>> Sent: 06 July 2012 06:34 >>>>>> To: ulrich@herberg.name >>>>>> Cc: manet >>>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>>>=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 >>>>>> +1 >>>>>>=20 >>>>>> I need the NHDP as a MANET interface for the DSRv2, which I suggeste= d >>>>>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>>>>> thanks very much, >>>>>>=20 >>>>>> It is interesting if most manet routings use NHDP or even be possibl= e >>>>>> to use in future, because I think it is a MANET interface as specifi= ed >>>>>> in OLSRv2. >>>>>>=20 >>>>>> AB >>>>>> ++++++++ >>>>>>> Hi, >>>>>>>=20 >>>>>>> we are currently working on a revised ID of the NHDP-MIB, as follow= -up >>>>>>> on requests during the IESG review. Amongst others, one request fro= m >>>>>>> Thomas Nadeau may affect other MIB documents as well, which is why = I >>>>>>> post it on the mailing list. >>>>>>>=20 >>>>>>> The current interface table in the NHDP-MIB is a copy of the interf= ace >>>>>>> MIB, with potentially many entries that are not MANET interfaces (b= ut >>>>>>> still waste space). What we are really interested in is monitoring = and >>>>>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>>>>> specify a ifType=3DMANET (as allowed by RFC2863 and the IANAifType >>>>>>> registry), and to list only those in the NHDP-MIB. Bob and I propos= e >>>>>>> that IANA allocates such an ifType, which covers all MANET WG >>>>>>> protocols, i.e. ifType=3DMANET would be used for interfaces running >>>>>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>>>> additional boolean flag which determines whether the interface uses >>>>>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the DYMO-on= ly >>>>>>> interfaces would be listed in the nhdpIfTable, but the boolean flag= is >>>>>>> false). >>>>>>>=20 >>>>>>>=20 >>>>>>> Best regards >>>>>>> Ulrich >>>>>>>=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 >>>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> -- >>> Regards, >>> Charlie P. >>>=20 >>>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Jul 7 01:53: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 4BEF321F851C for ; Sat, 7 Jul 2012 01:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_65=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 h+6ne47mtpUF for ; Sat, 7 Jul 2012 01:52:59 -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 1F2DD21F851A for ; Sat, 7 Jul 2012 01:52:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7139477vbb.31 for ; Sat, 07 Jul 2012 01:53:15 -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=DQrYGLz0EhJSNLNIV+8ziSDrynqQ+H1Yf7wudp7AmMc=; b=AyO7MwyXdDauuILTHsX1va5Gmk4qX+BCIN9qd0NEHRVjX0k+pTIjqZcfOpiaFLXikb aEky4YvzKdgp/3SkJVGazYvCTCuYzsj1xj7E35ZE/vTMSbjNXTGcv4LVKwOTARx73mmi uiV+Ow/GQzGwBllGj3LfPRvq0/xOdYDTaAGn151j7XvYK3gBLzjbNtNYK+Wwax+7g8p2 FiRuSumC8bLAHaBgIzYZVdt8ne4UM9uTbLliIXaA9njEmLsfydum1y9Kp+xp05zxOjmH sXgYij2UH9NY10Of5VraNWJNOnExPzlmjh8jVclv1eavtH5jHGVSr4N+6aEmanm3l0T4 30DA== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr7159296vcw.43.1341651195446; Sat, 07 Jul 2012 01:53:15 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Sat, 7 Jul 2012 01:53:15 -0700 (PDT) In-Reply-To: <4FF76D1D.8070804@computer.org> References: <4FF76D1D.8070804@computer.org> Date: Sat, 7 Jul 2012 10:53:15 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] AODVv2 as the reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 08:53:01 -0000 Hello Charlie, I thank you for your comments, I agree to consider this in my work, Regards Abdussalam On 7/7/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > Actually, I don't mean to say that there must only be one reactive > protocol. But I don't see what would motivate the separate > development of DSRv2 specifically. My current belief is that > few people in [manet] would desire to see such a development; > I would not. > > My *preference* would be to make every attempt to insure that > the IETF Proposed Standard reactive protocol serves the widest > feasible applicability for ad hoc networks. So, for instance it is well > understood that for some networks, proactive protocols are better. > And, I understand that some networks might need a reactive > protocol other than AODV, the simplest example being networks > that cannot sustain a network-layer protocol. > > Regards, > Charlie P. > > > > On 7/6/2012 3:42 PM, Abdussalam Baryun wrote: >> Hi Charlie, >> >> I thank you for your comments. I agree that AODVv2 is the first >> reactive protocol effort (is the needed one) and in the meeting 83 I >> heard of the LOADng as I think is a second recommended. After I am >> thinking of the DSRv2. So do you mean we should only have one reactive >> protocol and no work should be done (while doing another) as a new >> reactive protocol. I see no restriction in charter, it does mentions >> one reactive (at least) and proactive, but not mentioned at most >> reactive and proactive. >> >> Abdussalam >> ========== >> On 7/7/12, Charles E. Perkins wrote: >>> Hello Abdussalam, >>> >>> The idea of DYMO, renamed AODVv2 in the last revision, was exactly >>> to integrate AODV and DSR. The previous protocols were published >>> as Experimental, and the integrated protocol is to be published as a >>> Proposed Standard. In this way, publication of a new protocol named >>> "DSRv2" is likely to inhibit the intended effect of having a single >>> Proposed Standard reactive protocol. >>> >>> Moreover, it is not true that AODVv2 would not use NHDP. In fact, >>> the intention is exactly the opposite. The Proposed Standard reactive >>> protocol SHOULD be able to use NHDP, as presumably should any >>> future protocols promulgated within [manet]. >>> >>> Finally, please observe that a major distinguishing factor for DSR >>> was the inclusion of source routing, which survived in DYMO until >>> we obtained results showing that inclusion of the source route did >>> actually cause a loss of performance in many cases. It would be a >>> big contribution if you were able to exhibit clear results that would >>> resolve the mystery behind these results, but in the meantime it >>> seems unlikely that we should include Path Accumulation or the >>> more restricted version of Source Routing as specified in DSR. >>> >>> Even if we had those results, and thus the mystery were resolved, >>> the proper course of action would not be to specify DSRv2. Instead, >>> we should then specify an extension to the Proposed Standard >>> reactive protocol enabling the proper use of Path Accumulation. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 7/6/2012 2:21 PM, Abdussalam Baryun wrote: >>>> Please note that I am working on DSRv2 which will submit to MANET WG. >>>> My idea of NHDP used in a reactive protocol was not worked on yet, the >>>> DSRv2 was the first to announce this use of NHDP with reactive. >>>> Furthermore, I don't think there is restrictions on submitting I-Ds >>>> to MANET WG, please read the charter and give me an excluding >>>> statement. If yes there is this issue as you refer, I recommend only >>>> the Chair or AD to educate me on stop the work I already am doing for >>>> weeks. I think when I submit WG then can discuss further, >>>> >>>> AB >>>> ======= >>>> >>>> On 7/6/12, Dearlove, Christopher (UK) >>>> wrote: >>>>> How can you know there is a need for DSRv2? It's not in the WG >>>>> charter, >>>>> and >>>>> I've not seen anyone else on the list support the idea. >>>>> >>>>> -- >>>>> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>>> Sent: 06 July 2012 13:13 >>>>> To: Dearlove, Christopher (UK) >>>>> Cc: ulrich@herberg.name; manet >>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>> >>>>> ----------------------! WARNING ! ---------------------- >>>>> This message originates from outside our organisation, >>>>> either from an external partner or from the internet. >>>>> Keep this in mind if you answer this message. >>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>> for instructions on reporting suspicious email messages. >>>>> -------------------------------------------------------- >>>>> >>>>> Hi Chris, >>>>> >>>>> the point for me is not an individual understanding of the charter, MY >>>>> effort is aimed to the community needs. So I RECOMMEND that any >>>>> IETF-WG respects the community or even IETF-participant needs. I >>>>> respect the WG charter and I am participating, so I hope the WG >>>>> comments on my work. I know there is a need in DSRv2 and the future >>>>> will prove my point, I will remind you of this in the future don't >>>>> worry, >>>>> >>>>> AB >>>>> ========= >>>>> On 7/6/12, Dearlove, Christopher (UK) >>>>> wrote: >>>>>> I'll also note that the WG doesn't need DSRv2, even if you have >>>>>> permission >>>>>> from the original authors to use their work (which I see no sign of). >>>>>> The >>>>>> WG >>>>>> is charted to produce one reactive protocol. Multiplicity of >>>>>> protocols >>>>>> is >>>>>> a >>>>>> bad, not a good, thing, unless there is a pressing reason for it. In >>>>>> the >>>>>> reactive space the WG's adopted solution has been DYMO. Now that >>>>>> having >>>>>> stalled - though it may now be out of that stall - may (no stronger >>>>>> than >>>>>> that) open up the possibility that another protocol already developed >>>>>> to >>>>>> a >>>>>> similar maturity could be considered. LOADng claims to be that, I >>>>>> haven't >>>>>> examined that claim. But a new protocol is clearly not that. >>>>>> >>>>>> -- >>>>>> 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 >>>>>> Abdussalam Baryun >>>>>> Sent: 06 July 2012 06:34 >>>>>> To: ulrich@herberg.name >>>>>> Cc: manet >>>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>>> >>>>>> ----------------------! 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 >>>>>> >>>>>> I need the NHDP as a MANET interface for the DSRv2, which I suggested >>>>>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>>>>> thanks very much, >>>>>> >>>>>> It is interesting if most manet routings use NHDP or even be possible >>>>>> to use in future, because I think it is a MANET interface as >>>>>> specified >>>>>> in OLSRv2. >>>>>> >>>>>> AB >>>>>> ++++++++ >>>>>>> Hi, >>>>>>> >>>>>>> we are currently working on a revised ID of the NHDP-MIB, as >>>>>>> follow-up >>>>>>> on requests during the IESG review. Amongst others, one request from >>>>>>> Thomas Nadeau may affect other MIB documents as well, which is why I >>>>>>> post it on the mailing list. >>>>>>> >>>>>>> The current interface table in the NHDP-MIB is a copy of the >>>>>>> interface >>>>>>> MIB, with potentially many entries that are not MANET interfaces >>>>>>> (but >>>>>>> still waste space). What we are really interested in is monitoring >>>>>>> and >>>>>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>>>>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>>>>>> registry), and to list only those in the NHDP-MIB. Bob and I propose >>>>>>> that IANA allocates such an ifType, which covers all MANET WG >>>>>>> protocols, i.e. ifType=MANET would be used for interfaces running >>>>>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>>>> additional boolean flag which determines whether the interface uses >>>>>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the >>>>>>> DYMO-only >>>>>>> interfaces would be listed in the nhdpIfTable, but the boolean flag >>>>>>> is >>>>>>> false). >>>>>>> >>>>>>> >>>>>>> Best 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. >>>>>> ******************************************************************** >>>>>> >>>>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> -- >>> Regards, >>> Charlie P. >>> >>> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Sat Jul 7 01:58: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 7207B21F8585 for ; Sat, 7 Jul 2012 01:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_65=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 YrvitLFp9O2c for ; Sat, 7 Jul 2012 01:58:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F41EB21F8566 for ; Sat, 7 Jul 2012 01:58:52 -0700 (PDT) Received: by vcqp1 with SMTP id p1so7130079vcq.31 for ; Sat, 07 Jul 2012 01:59:11 -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=AyYO1HqfE8+e/hu2lUDD9CGIE9qG/VVrnH9u3Zq2fkU=; b=AoZ13nwXGSOIxAUp2dvUNkLbesBCC4IasfYbhGlhM/Dd30TJn6k0f6BnkXbbUFcHQy LjZnTMFD9S4EFxHN42zbdXPtCCMJMN2s9pGLk2ENqbffqIYTC+UxAbC7Z0n+TQQEnnk4 aXrQiuWzBQw5PqpWFd1n8xncKBZw/NLNCUcE2wnzCijm2q3rE/BSev0RYZCIaaHHVW+b mxBN1A8dhri+kgmWjVJ5x1P1cOa6KctKao/Shs8gK3MpVYKeUB1JhKrCLraIp2YumwJa ITwORy1y/+AWpLohcI5uIW0G6kWX8wkgb0fWnlOeLA3S7ltIb+aE2Ay2F4FV6nUKksYJ O//g== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr13337283vds.117.1341651551175; Sat, 07 Jul 2012 01:59:11 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Sat, 7 Jul 2012 01:59:11 -0700 (PDT) In-Reply-To: <5DBAA85B-47D1-4A29-B2C1-F8DD65FF1575@cisco.com> References: <4FF76E9E.60305@computer.org> <5DBAA85B-47D1-4A29-B2C1-F8DD65FF1575@cisco.com> Date: Sat, 7 Jul 2012 10:59:11 +0200 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Re: AODVv2 as the reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 08:58:57 -0000 +1 this will apply to any new reactive or/and proagtive protocol that MANET-WG accomodates. Thanking you Abdussalam Baryun University of Glamorgan, UK ===================== On 7/7/12, Stan Ratliff (sratliff) wrote: > The working group is chartered to produce a reactive protocol. By that, > we've always assumed only one. Multiple specifications would, IMO, require a > clear requirements definition of *why* they are needed - why some > deployments would need "protocol Y" instead of "protocol X". > > Regards, > Stan > > On Jul 6, 2012, at 7:02 PM, Charles E. Perkins wrote: > >> >> Hello Abdussalam, >> >> Actually, I don't mean to say that there must only be one reactive >> protocol. But I don't see what would motivate the separate >> development of DSRv2 specifically. My current belief is that >> few people in [manet] would desire to see such a development; >> I would not. >> >> My *preference* would be to make every attempt to insure that >> the IETF Proposed Standard reactive protocol serves the widest >> feasible applicability for ad hoc networks. So, for instance it is >> understood that for some networks, proactive protocols are better. >> And, I understand that some networks might need a reactive >> protocol other than AODV, the simplest example being networks >> that cannot sustain a network-layer protocol. >> >> Regards, >> Charlie P. >> >> PS. I forgot to CC: manet in my previous reply. >> >> >> On 7/6/2012 3:42 PM, Abdussalam Baryun wrote: >>> Hi Charlie, >>> >>> I thank you for your comments. I agree that AODVv2 is the first >>> reactive protocol effort (is the needed one) and in the meeting 83 I >>> heard of the LOADng as I think is a second recommended. After I am >>> thinking of the DSRv2. So do you mean we should only have one reactive >>> protocol and no work should be done (while doing another) as a new >>> reactive protocol. I see no restriction in charter, it does mentions >>> one reactive (at least) and proactive, but not mentioned at most >>> reactive and proactive. >>> >>> Abdussalam >>> ========== >>> On 7/7/12, Charles E. Perkins wrote: >>>> Hello Abdussalam, >>>> >>>> The idea of DYMO, renamed AODVv2 in the last revision, was exactly >>>> to integrate AODV and DSR. The previous protocols were published >>>> as Experimental, and the integrated protocol is to be published as a >>>> Proposed Standard. In this way, publication of a new protocol named >>>> "DSRv2" is likely to inhibit the intended effect of having a single >>>> Proposed Standard reactive protocol. >>>> >>>> Moreover, it is not true that AODVv2 would not use NHDP. In fact, >>>> the intention is exactly the opposite. The Proposed Standard reactive >>>> protocol SHOULD be able to use NHDP, as presumably should any >>>> future protocols promulgated within [manet]. >>>> >>>> Finally, please observe that a major distinguishing factor for DSR >>>> was the inclusion of source routing, which survived in DYMO until >>>> we obtained results showing that inclusion of the source route did >>>> actually cause a loss of performance in many cases. It would be a >>>> big contribution if you were able to exhibit clear results that would >>>> resolve the mystery behind these results, but in the meantime it >>>> seems unlikely that we should include Path Accumulation or the >>>> more restricted version of Source Routing as specified in DSR. >>>> >>>> Even if we had those results, and thus the mystery were resolved, >>>> the proper course of action would not be to specify DSRv2. Instead, >>>> we should then specify an extension to the Proposed Standard >>>> reactive protocol enabling the proper use of Path Accumulation. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> On 7/6/2012 2:21 PM, Abdussalam Baryun wrote: >>>>> Please note that I am working on DSRv2 which will submit to MANET WG. >>>>> My idea of NHDP used in a reactive protocol was not worked on yet, the >>>>> DSRv2 was the first to announce this use of NHDP with reactive. >>>>> Furthermore, I don't think there is restrictions on submitting I-Ds >>>>> to MANET WG, please read the charter and give me an excluding >>>>> statement. If yes there is this issue as you refer, I recommend only >>>>> the Chair or AD to educate me on stop the work I already am doing for >>>>> weeks. I think when I submit WG then can discuss further, >>>>> >>>>> AB >>>>> ======= >>>>> >>>>> On 7/6/12, Dearlove, Christopher (UK) >>>>> wrote: >>>>>> How can you know there is a need for DSRv2? It's not in the WG >>>>>> charter, >>>>>> and >>>>>> I've not seen anyone else on the list support the idea. >>>>>> >>>>>> -- >>>>>> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>>>>> Sent: 06 July 2012 13:13 >>>>>> To: Dearlove, Christopher (UK) >>>>>> Cc: ulrich@herberg.name; manet >>>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>>> >>>>>> ----------------------! WARNING ! ---------------------- >>>>>> This message originates from outside our organisation, >>>>>> either from an external partner or from the internet. >>>>>> Keep this in mind if you answer this message. >>>>>> Follow the 'Report Suspicious Emails' link on IT matters >>>>>> for instructions on reporting suspicious email messages. >>>>>> -------------------------------------------------------- >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> the point for me is not an individual understanding of the charter, >>>>>> MY >>>>>> effort is aimed to the community needs. So I RECOMMEND that any >>>>>> IETF-WG respects the community or even IETF-participant needs. I >>>>>> respect the WG charter and I am participating, so I hope the WG >>>>>> comments on my work. I know there is a need in DSRv2 and the future >>>>>> will prove my point, I will remind you of this in the future don't >>>>>> worry, >>>>>> >>>>>> AB >>>>>> ========= >>>>>> On 7/6/12, Dearlove, Christopher (UK) >>>>>> wrote: >>>>>>> I'll also note that the WG doesn't need DSRv2, even if you have >>>>>>> permission >>>>>>> from the original authors to use their work (which I see no sign >>>>>>> of). >>>>>>> The >>>>>>> WG >>>>>>> is charted to produce one reactive protocol. Multiplicity of >>>>>>> protocols >>>>>>> is >>>>>>> a >>>>>>> bad, not a good, thing, unless there is a pressing reason for it. In >>>>>>> the >>>>>>> reactive space the WG's adopted solution has been DYMO. Now that >>>>>>> having >>>>>>> stalled - though it may now be out of that stall - may (no stronger >>>>>>> than >>>>>>> that) open up the possibility that another protocol already >>>>>>> developed >>>>>>> to >>>>>>> a >>>>>>> similar maturity could be considered. LOADng claims to be that, I >>>>>>> haven't >>>>>>> examined that claim. But a new protocol is clearly not that. >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> Abdussalam Baryun >>>>>>> Sent: 06 July 2012 06:34 >>>>>>> To: ulrich@herberg.name >>>>>>> Cc: manet >>>>>>> Subject: Re: [manet] NHDP-MIB: ifType >>>>>>> >>>>>>> ----------------------! 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 >>>>>>> >>>>>>> I need the NHDP as a MANET interface for the DSRv2, which I >>>>>>> suggested >>>>>>> for DSRv2 before, so I like/agree that you consider the flag ifType, >>>>>>> thanks very much, >>>>>>> >>>>>>> It is interesting if most manet routings use NHDP or even be >>>>>>> possible >>>>>>> to use in future, because I think it is a MANET interface as >>>>>>> specified >>>>>>> in OLSRv2. >>>>>>> >>>>>>> AB >>>>>>> ++++++++ >>>>>>>> Hi, >>>>>>>> >>>>>>>> we are currently working on a revised ID of the NHDP-MIB, as >>>>>>>> follow-up >>>>>>>> on requests during the IESG review. Amongst others, one request >>>>>>>> from >>>>>>>> Thomas Nadeau may affect other MIB documents as well, which is why >>>>>>>> I >>>>>>>> post it on the mailing list. >>>>>>>> >>>>>>>> The current interface table in the NHDP-MIB is a copy of the >>>>>>>> interface >>>>>>>> MIB, with potentially many entries that are not MANET interfaces >>>>>>>> (but >>>>>>>> still waste space). What we are really interested in is monitoring >>>>>>>> and >>>>>>>> managing NHDP interfaces. Thomas Nadeau suggested to ask IANA to >>>>>>>> specify a ifType=MANET (as allowed by RFC2863 and the IANAifType >>>>>>>> registry), and to list only those in the NHDP-MIB. Bob and I >>>>>>>> propose >>>>>>>> that IANA allocates such an ifType, which covers all MANET WG >>>>>>>> protocols, i.e. ifType=MANET would be used for interfaces running >>>>>>>> NHDP, OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>>>>> additional boolean flag which determines whether the interface uses >>>>>>>> NHDP or not (i.e., if a router runs both DYMO and NHDP, the >>>>>>>> DYMO-only >>>>>>>> interfaces would be listed in the nhdpIfTable, but the boolean flag >>>>>>>> is >>>>>>>> false). >>>>>>>> >>>>>>>> >>>>>>>> Best 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. >>>>>>> ******************************************************************** >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> >>>> -- >>>> Regards, >>>> Charlie P. >>>> >>>> >> >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From robert.g.cole.civ@mail.mil Sat Jul 7 10:00: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 6639421F86AA for ; Sat, 7 Jul 2012 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, J_CHICKENPOX_65=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 nqQQyKseNBqg for ; Sat, 7 Jul 2012 10:00:34 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA821F869E for ; Sat, 7 Jul 2012 10:00:33 -0700 (PDT) Received: from UCOLHP3I.easf.csd.disa.mil (131.64.100.150) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 7 Jul 2012 17:00:26 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.172]) by UCOLHP3I.easf.csd.disa.mil ([131.64.100.150]) with mapi id 14.02.0283.003; Sat, 7 Jul 2012 17:00:24 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Abdussalam Baryun , Ulrich Herberg Thread-Topic: [manet] NHDP-MIB: ifType (UNCLASSIFIED) Thread-Index: AQHNWzkB5SpXq37qykC//U2ptCyf6JccdhAAgABLjACAAANbAIAAAvgAgAFFO3A= Date: Sat, 7 Jul 2012 17:00:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.14] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CD5C40.7F1B2480" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:00:35 -0000 ------=_NextPart_000_0016_01CD5C40.7F1B2480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Our proposal is not mandating the use of NHDP. Instead it is flexible and allows whatever combination of MANET control protocols that makes sense. Thanks, Bob -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: Friday, July 06, 2012 5:35 PM To: Ulrich Herberg Cc: manet Subject: Re: [manet] NHDP-MIB: ifType Hi Ulrich, You mention routing protocols already please read in your thread, > additional boolean flag which determines whether the interface uses > NHDP or not (i.e., if a router runs both DYMO and NHDP, the > DYMO-only Please note that DYMO will not use NHDP, only if using RFC5444. I just mentioned the DSRv2 I am doing, AB ============================================================ On 7/6/12, Ulrich Herberg wrote: > That is not what I said. I just recommended that this email thread is > about the ifType in the NHDP-MIB, not about DSRv2, and that such a > discussion (if > desired) should be in another email with different subject. > > Best > Ulrich > > On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> I am sorry I will never post in your threads, if you like that, >> >> AB >> >> On 7/6/12, Ulrich Herberg wrote: >> > Abdussalam, >> > >> > note that this has nothing to do with the protocol itself, but only >> > for >> the >> > MIB. So, unless you draft a MIB module, you will not need the ifType. >> > >> > If you want to discuss DSRv2 (which I doubt the WG should work on), >> please >> > open a new email thread, since this thread was only about the >> > NHDP-MIB draft. >> > >> > Best >> > Ulrich >> > >> > On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < >> > abdussalambaryun@gmail.com> wrote: >> > >> >> +1 >> >> >> >> I need the NHDP as a MANET interface for the DSRv2, which I >> >> suggested for DSRv2 before, so I like/agree that you consider the >> >> flag ifType, thanks very much, >> >> >> >> It is interesting if most manet routings use NHDP or even be >> >> possible to use in future, because I think it is a MANET interface >> >> as specified in OLSRv2. >> >> >> >> AB >> >> ++++++++ >> >> > Hi, >> >> > >> >> > we are currently working on a revised ID of the NHDP-MIB, as >> >> > follow-up on requests during the IESG review. Amongst others, >> >> > one request from Thomas Nadeau may affect other MIB documents as >> >> > well, which is why I post it on the mailing list. >> >> > >> >> > The current interface table in the NHDP-MIB is a copy of the >> >> > interface MIB, with potentially many entries that are not MANET >> >> > interfaces (but still waste space). What we are really >> >> > interested in is monitoring and managing NHDP interfaces. Thomas >> >> > Nadeau suggested to ask IANA to specify a ifType=MANET (as >> >> > allowed by RFC2863 and the IANAifType registry), and to list >> >> > only those in the NHDP-MIB. Bob and I propose that IANA >> >> > allocates such an ifType, which covers all MANET WG protocols, >> >> > i.e. ifType=MANET would be used for interfaces running NHDP, >> >> > OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >> >> > additional boolean flag which determines whether the interface >> >> > uses NHDP or not (i.e., if a router runs both DYMO and NHDP, the >> >> > DYMO-only interfaces would be listed in the nhdpIfTable, but the >> >> > boolean flag is false). >> >> > >> >> > >> >> > Best regards >> >> > Ulrich >> >> > >> >> >> > >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0016_01CD5C40.7F1B2480 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MDcxNzAwMzRaMCMGCSqGSIb3 DQEJBDEWBBQv4ZKpDMX6uT6izJSmR94Tu0f37zAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEARekRhRQzx4O5Tay6ehzm1+5urnvB MbcfFI+ouftzVcba5jKsfgNZaO7zw7H4msX371/u5zviwbJpu9tmiMKf4ViYxSgj4igHD4fCdtdN d9mtG/i16xwbeYeuV1Zhnia9SVxkGqlrqxlPFYBQd22ig8Fe8utzm6QBBuENeBCgwSKLgCO7fyVZ Kz5k4Zf54vch+IXJosavTYdeADsNqKXTPUvpPtXKwd6VjseIQl562LSQyfV/sV0wyhIjpETxezpN /lTahx7yYXZJvAp77znCqkubIuQzT8QUqWWZap9Jr9w80/rVVba9DrINxctqdZleFPwC9/B8rBL6 KVjdn49OtwAAAAAAAA== ------=_NextPart_000_0016_01CD5C40.7F1B2480-- From Chris.Dearlove@baesystems.com Mon Jul 9 04:35: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 5396721F8627 for ; Mon, 9 Jul 2012 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 lYM64hkmHkbj for ; Mon, 9 Jul 2012 04:35:34 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 15F0D21F861D for ; Mon, 9 Jul 2012 04:35:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,552,1336345200"; d="scan'208";a="253416015" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 09 Jul 2012 12:35:57 +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 q69BZuMM024316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Jul 2012 12:35:56 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.251]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Mon, 9 Jul 2012 12:35:56 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: OLSRv2 metrics rational Thread-Index: Ac1dxa/Zv4eGhBwNQIS9ATW3EZMqNQ== Date: Mon, 9 Jul 2012 11:35:56 +0000 Message-ID: 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: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" , "Joe Macker \(joseph.macker@nrl.navy.mil\)" , "'Stan Ratliff' \(sratliff@cisco.com\)" Subject: [manet] OLSRv2 metrics rational X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:35:35 -0000 We have reissued draft-dearlove-olsrv2-metrics, now -06, changing its purpo= se. Formerly this was a document that said "this is how we propose to add m= etrics to OLSRv2". That was agreed by the WG, some simplifications made, an= d metrics were incorporated in the draft, which is currently with our AD an= d I hope will go onwards soon.=20 However there was significant information "left behind" in the metrics draf= t as to why things were done the way they were. It was proposed at the Pari= s meeting that this be retained, and I think the mood of the meeting was th= at this was a good idea. Hence the authors have reworked the draft to be "t= his is what we added and why", and offer it for consideration to the WG for= adoption and progress to an Informational RFC. We therefore request a slot at the Vancouver meeting to discuss this and to= consider the above suggestion. Unfortunately I won't be in Vancouver, but = Thomas Clausen will be and can present 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 ******************************************************************** 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 Tue Jul 10 04:26: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 9645A21F8778 for ; Tue, 10 Jul 2012 04:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 zdYfF1pmioHP for ; Tue, 10 Jul 2012 04:26:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4DE821F8771 for ; Tue, 10 Jul 2012 04:26:35 -0700 (PDT) Received: by vcqp1 with SMTP id p1so8614396vcq.31 for ; Tue, 10 Jul 2012 04:27:03 -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=17npuvJEgByfkkfMehgELJMT1uCKLVzDuDNTItgUWDg=; b=AYY2wSZEuNNUI7vTp2buqNP1fxOMHCWKpI1znHgim9aMnrJjIxOZOeu2ddkFLr//m+ a3OcEcfDfPdXyJyr9H1WW3Ql9B0zFLfaFb+7qUmX3z/fAPaMllHpYVI/Xlf076hrG12M PCSkaNiBJ6M5AZncvz4//+O9YLyx0NNw0IQ05tqd2EEoWa+bwgfyYfiw9CbUg86hJeS2 mT+uWJgt2+eTQcR7+c+7ijfBNkbxE9YeRJEjjp6B1xNoEXhKeX/N8olKtRo0bd8KW2Oq 9B9vrfldgP/6/y53UOjRnnIZWPA3ZMGw55+yKZGi/lOuxwaoi/R0K6fST77nX+0Bsv+3 w5BA== MIME-Version: 1.0 Received: by 10.220.108.1 with SMTP id d1mr20961003vcp.19.1341919622696; Tue, 10 Jul 2012 04:27:02 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Tue, 10 Jul 2012 04:27:02 -0700 (PDT) Date: Tue, 10 Jul 2012 13:27:02 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] OLSRv2 metrics rational X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:26:36 -0000 +1 I read the draft-05 and notice its importance in paris meeting and for the OLSRv2, thanks for submiting new version -6 *, also hope to see the ETX draft as well, * http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 AB > > We have reissued draft-dearlove-olsrv2-metrics, now -06, changing its > purpose. Formerly this was a document that said "this is how we propose to > add metrics to OLSRv2". That was agreed by the WG, some simplifications > made, and metrics were incorporated in the draft, which is currently with > our AD and I hope will go onwards soon. > > However there was significant information "left behind" in the metrics draft > as to why things were done the way they were. It was proposed at the Paris > meeting that this be retained, and I think the mood of the meeting was that > this was a good idea. Hence the authors have reworked the draft to be "this > is what we added and why", and offer it for consideration to the WG for > adoption and progress to an Informational RFC. > > We therefore request a slot at the Vancouver meeting to discuss this and to > consider the above suggestion. Unfortunately I won't be in Vancouver, but > Thomas Clausen will be and can present this. > > -- > 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 > > > End of manet Digest, Vol 98, Issue 33 > ************************************* > From abdussalambaryun@gmail.com Thu Jul 12 08:41: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 E028721F870F for ; Thu, 12 Jul 2012 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_34=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 keEyu9+ki3JB for ; Thu, 12 Jul 2012 08:41:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3393221F8707 for ; Thu, 12 Jul 2012 08:41:30 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1746829vcq.31 for ; Thu, 12 Jul 2012 08:42:03 -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=YQ8Chcx2KmiRVh96pb152GHwHr/V+eQCyobbKjts1qc=; b=vLZhbA8bNA3CBV3SwYNzqun18rH4mH64fwcPn6sa5tIL/+yomErithYavykpGQjBGX neXxJ8cD7UkZwwGoVpRgZg34BXGxho+3P7aUTpAmfTF4Vu/Qv+u6Ncn4hPhhkI1iV9do lP0xpU+6ZOIfX7QSZ4HKwvpb7SL3xVZgDje2ANnqXLucXsOi2aL4Jlh/3mfRQSmESYjd K9xhP5C7FLBHRB2+3EpVu66DAtCaFi3x9rgLzkQROZGuyTtSGE8BVbgbuia17HTuf6JH O9An3jAOv6MU3C9v58nCE0QbVhZBOwWVOB6EsLrnXY+Ehj2xdY6JITgSG7IX+o/4RhKN zqxw== MIME-Version: 1.0 Received: by 10.220.108.1 with SMTP id d1mr25515973vcp.19.1342107723429; Thu, 12 Jul 2012 08:42:03 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 12 Jul 2012 08:42:03 -0700 (PDT) Date: Thu, 12 Jul 2012 17:42:03 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" Subject: [manet] Route Metric Type Consideration for MANET Routers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 12 Jul 2012 15:41:31 -0000 Dear All, *************** metric draft suggestions ************************* [draft-05] draft-dearlove-olsrv2-metrics-05 [draft-06] draft-dearlove-olsrv2-metrics-06 Regarding OLSRv2 metrics as in [draft-06]: suggested that OLSRv2 Router uses new metric type: physical or non-physical. --------------------------------------------------------------------------------------- In [draft-06] it distinguishes between dimensionless-metric physical type, and non-physical, However, it does not specify method of metrics for routers nor requires IANA considerations. Please note that : OLSRv2-15 draft in page 87, IANA section, mentions: "assignment of link metric MUST specify the physical meaning" what about non-physical? ********************************************************************* I agree to some updates in the above new draft-06 (e.g. amend: router to neighbor, and non-technical to non-physical), but disagree of deleting some ideas or deleting sections 4.5 and 6. I suggest to make the metric type flexible like in the draft-05 used, and to make the draft intended status: standard. If there are reasons of the delete I would like to understand. The suggestion can be for any other MANET Router [AB] (e.g. AODVv2-metrics ). IMHO we need a specification for metrics related to such router for many reasons [1] and [2]. It was suggested in [1] that some MANET Packets' [AB] header needs to include metric-type, or in the meaning of standardizing information exchange of metrics between MANET Routers [AB]. On the other hand, many participants like the idea of dimensionless-type metrics. Therefore, I suggest the draft-06 specifies OLSRv2 metrics (dimensionless-type) as standard for OLSRv2 routers. Also in the draft-06 it suggested metrics in the messaging as information between OLSRv2 neighbor-routers. So does it mean that the metric configuration is decided by the network or node manager (or even its future change), we need to be sure. Another suggestion is to have the metric type configured/decided by the NHDP so to be flexible (we may need to update RFC6130). This will require a standard for MANET Routers of Metric Types. I am using this approach in my work of DSRv2 Interfaces' behaviors. I may write a draft about MANET Routers Metric in future. However, I am preparing another standard draft as I posted in June [3] [4] about NAP protocol (to be submitted to ROLL WG), which will specify node ability in many node-activities including routing and all-types-metrics. DSRv2 may use NAP+NHDP at its MANET Interfaces [AB] as well. If you have any advise, comment, or suggestion on this message, please feel free to reply, thanking you, [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt [1] http://www.ietf.org/mail-archive/web/manet/current/msg12430.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg12881.html [3] http://www.ietf.org/mail-archive/web/6lowpan/current/msg03525.html [4] http://www.ietf.org/mail-archive/web/manet/current/msg13070.html Best Regards Abdussalam Baryun University of Glamorgan, UK From abdussalambaryun@gmail.com Thu Jul 12 11:52: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 C4E3B21F8634 for ; Thu, 12 Jul 2012 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 riW-3VcJdpzq for ; Thu, 12 Jul 2012 11:52:37 -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 CC22B21F8627 for ; Thu, 12 Jul 2012 11:52:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1885237vbb.31 for ; Thu, 12 Jul 2012 11:53:10 -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=LYiG6VSc4wRXiB4miiu3xGx4Oep9CWC5VIGYSdKG+TU=; b=gaX6nw9uJaWNhHVRfGoaVldFRMMO8g7SetGS3OB5Cgq6n66dllCQL9Lx0M21jIU3h4 t+OJfBlOd+UmXbvACShRbxMNu4RWxJkWvs+54rvfg5kHbO/a/EVEm1zjAr5WsIKeczZd e525XOpNkZT8+UY4SithZJO45avraNotv69N6TPmLP3ZWBV/W6iLjPeM8HdXrQ+kVezD 5JF7WfwS+E3Bm3R3u6DpojGgpUQqn7uZervhbcfRx555pE9yl3CMpbSD+yQchSSSdf+1 k29cAtMmdSsAe+UjzpHkki0fbokrqBFXnRG7xYdK2d6ef2jKNE4v259vHEc7ZMl+9EeM zEJg== MIME-Version: 1.0 Received: by 10.220.219.137 with SMTP id hu9mr24358644vcb.4.1342119190058; Thu, 12 Jul 2012 11:53:10 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 12 Jul 2012 11:53:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 20:53:07 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 12 Jul 2012 18:52:37 -0000 >>Investigating examples can help to come up with a more abstract model of different management and monitoring approaches. Please note that the presenter of [Radio, SatCom, and considerations] in 82 meeting stated that it is not possible to define a manange model before defining layer 2 subnet model, which I agreed from before [1] and worked on the draft of MANET L2 subnets starting on 8 June [2]. [1] http://www.ietf.org/mail-archive/web/manet/current/msg12961.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13032.html AB ====== On 7/6/12, Abdussalam Baryun wrote: > Hi Ulrich, > > I thank you for this, I am happy that IESG have requested this. Mr. > Cole in the meeting 82 had introduced the problem (please check his > presentation), which I presented to the MANET. Yes we need in MANET to > be focus on use-case, and how management is done. It is important that > MANET documents interact with Internet drafts. > > I included Mr.Cole presentation (Nov.2011) in my I-D draft about > MANET subnet technologies, and propose that any new I-D for management > should take it into consideration. > > Abdussalam Baryun > University of Glamorgan, UK > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: manet at ietf.org Subject: [manet] MANET management use cases From: Ulrich Herberg Date: Thu, 5 Jul 2012 17:43:12 -0700 >> Hi, >> >> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >> IESG evaluation to specify use cases how MANETs are monitored and >> managed using SNMP. After discussion with Benoit and Adrian, we agreed >> that such information would be useful, but that the MIB module (as >> pure APIs) would likely be the wrong place. Moreover, the use cases >> would not necessarily be specific to the NHDP-MIB, but concern all MIB >> modules. Benoit requested that we come up with a new informational >> draft in the WG, which discusses different MANET management use cases. >> >> Bob started working on collecting management and monitoring scenarios >> from the military experience. I believe that it would also be >> interesting to cover other use cases, such as in disaster recovery >> (e.g., monitoring and management of routers thrown out of an airplane >> over a disaster area) or in community networks (e.g., >> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >> can help to come up with a more abstract model of different management >> and monitoring approaches. It would be helpful if participants in this >> WG with MANET deployment and management/monitoring experience could >> contribute to such an effort. >> >> As a side note, there is a new mailing list about management of >> constrained networks and devices (coma at ietf.org), which may be of >> interest for some of the WG participants. >> >> Best regards >> Ulrich >> > From ulrich@herberg.name Thu Jul 12 12:07: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 C150711E80ED for ; Thu, 12 Jul 2012 12:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.541, 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 eAfQZcc5lVGo for ; Thu, 12 Jul 2012 12:07:37 -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 747F011E80F9 for ; Thu, 12 Jul 2012 12:07:37 -0700 (PDT) Received: by yenq13 with SMTP id q13so3034507yen.31 for ; Thu, 12 Jul 2012 12:08: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=BR0qsvzymUzGo5AVe/+PTalwHNsm4MgPUxf7yxC+Ksk=; b=xq3CM1wQoK/I5OeQKPYSfqthu1vkezdbHBWRDRCNtzxxGg/YDWfvYfUT4SzN9RcYAP gL8pQU0VtGv+TjIeFQ7scPH6VOfgsRtI4J6G4a+bcvO+PVnI/7f4cc6RcWq4yGkrq7My 4kSiQnrPCQp3m0EGsC+yb6v7O9USe2ud2EETA= 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=BR0qsvzymUzGo5AVe/+PTalwHNsm4MgPUxf7yxC+Ksk=; b=H0sT0QKE/gs0I/K7+Yl5q544Oq7s6VZCoaz5Sb8hdfYlqMp6EGbLU11uOq1LuAVl5q vUweEb7Wca+hxZTmTcLT17N5Z8+FgE1+wPG4L6wRl9Pd8B/SJvsa9rt9Pz14XQoy2Jm0 F/mRNB77gYLSDVDft5SS4XLlJVHNbJuO7Mz9PkjHz99XLFOoMKlPEKYwZ+KjPaA+FfDg ojJ3qck6PJvvH9szQKhip2JNPPoECnmfBnk9QjqgrXBLf6UnP8Hfh2dPM/NhnWodwQpj vGve3usuw7C9EVgdsnuAUZ6UpYDC2fl6aNLr1S8qA4O90csfnK4wbcPquKKe+oD/AvW0 EjFA== MIME-Version: 1.0 Received: by 10.66.74.97 with SMTP id s1mr92131727pav.11.1342120090680; Thu, 12 Jul 2012 12:08:10 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Thu, 12 Jul 2012 12:08:10 -0700 (PDT) In-Reply-To: References: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> Date: Thu, 12 Jul 2012 12:08:10 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=f46d042ef5fb403dad04c4a6af39 X-Gm-Message-State: ALoCoQkm+ieGvpIbzeSoGC15XTCZx5veHuz4tFqI7kz/fdu6di1Hb9NBEVb0F/Y40dVOHPylSOLX Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:07:38 -0000 --f46d042ef5fb403dad04c4a6af39 Content-Type: text/plain; charset=ISO-8859-1 Dear Chris, I agree that we need to provide similar mechanisms as in NHDP-sec for TC messages as well. I don't think that signing the packet is enough, since that does not provide end-to-end security. Instead, I suggest to submit a draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and how to handle these messages in OLSRv2. However, I believe that it would be beneficial for certain applications to also be able to sign/verify packets. But I don't think that the NHDP-sec document is the right place for this, since other applications (e.g. DYMO) may not use HELLO messages at all, but would still like to sign/verify packets. Maybe it would be better to have an extra document "packet-sec" which specifies how to sign/verify packets? Best Ulrich On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > (Sending again, to sort out the formatting problem with the last attempt.) > > As I read it, this draft is proposing using the RFC 6622 mechanism to sign > HELLO messages. RFC 6622 actually allows for signing packets as well as > signing messages (both, either, or neither to be used as required). There > isn't a major difference when considering HELLO messages, as few if any > packets will contain more than one HELLO message, and the packet and the > message will be signed by the same party. > > However NHDP doesn't exist in a vacuum, in particular it is used by > OLSRv2. Any security mechanism that is described in what will be an RFC for > NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has > TC messages to consider, and they don't satisfy the points noted above (on > number or on who signs them). And one option for OLSRv2 is to sign all > packets, not messages. This can be a sensible decision there, for several > reasons, in some real circumstances. > > Consequently, I don't believe that this draft should describe only signing > HELLO messages as the correct thing to do, that it should also allow > signing packets as an equal status option. If someone wants to raise the > possibility of signing (possibly by methods with different properties) both > at the message and packet level, that may have its use cases too. > > Incidentally, even within the limited framework of just NHDP, it is > possible that packets need protection. If an NHDP implementation chooses to > use packet sequence number as part of its link quality mechanism, as it > may, then an unprotected packet header is a vulnerability. > > (For the sake of completeness, RFC 6622 also allows address block > signatures. I don't have a reason to suggest using this within NHDP or > OLSRv2.) > > -- > 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 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobile Ad-hoc Networks > Working Group of the IETF. > > Title : Using Integrity Check Values and Timestamps For > Router Admittance in NHDP > Author(s) : Ulrich Herberg > Thomas Heide Clausen > Filename : draft-ietf-manet-nhdp-sec-02.txt > Pages : 12 > Date : 2012-05-29 > > This document specifies a security extension to the MANET > Neighborhood Discovery Protocol (NHDP). The extension introduces the > use of Integrity Check Values (ICVs) and Timestamps in HELLO messages > in order to provide a router admittance mechanism, and therefore to > counter 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-02.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-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > > _______________________________________________ > 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. > ******************************************************************** > > --f46d042ef5fb403dad04c4a6af39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Chris,

I agree that we need to provide similar mechanisms as in= NHDP-sec for TC messages as well. I don't think that signing the packe= t is enough, since that does not provide end-to-end security. Instead, I su= ggest to submit a draft OLSRv2-sec that specifies how to calculate ICVs for= TC messages, and how to handle these messages in OLSRv2.

However, I believe that it would be beneficial for certain applications= to also be able to sign/verify packets. But I don't think that the NHD= P-sec document is the right place for this, since other applications (e.g. = DYMO) may not use HELLO messages at all, but would still like to sign/verif= y packets.
Maybe it would be better to have an extra document "packet-sec" w= hich specifies how to sign/verify packets?

Best
Ulrich

On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christop= her (UK) <Chris.Dearlove@baesystems.com> wrote:<= br>
(Sending again, to sort out the formatting p= roblem with the last attempt.)

As I read it, this draft is proposing using the RFC 6622 mechanism to sign = HELLO messages. RFC 6622 actually allows for signing packets as well as sig= ning messages (both, either, or neither to be used as required). There isn&= #39;t a major difference when considering HELLO messages, as few if any pac= kets will contain more than one HELLO message, and the packet and the messa= ge will be signed by the same party.

However NHDP doesn't exist in a vacuum, in particular it is used by OLS= Rv2. Any security mechanism that is described in what will be an RFC for NH= DP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also ha= s TC messages to consider, and they don't satisfy the points noted abov= e (on number or on who signs them). And one option for OLSRv2 is to sign al= l packets, not messages. This can be a sensible decision there, for several= reasons, in some real circumstances.

Consequently, I don't believe that this draft should describe only sign= ing HELLO messages as the correct thing to do, that it should also allow si= gning packets as an equal status option. If someone wants to raise the poss= ibility of signing (possibly by methods with different properties) both at = the message and packet level, that may have its use cases too.

Incidentally, even within the limited framework of just NHDP, it is possibl= e that packets need protection. If an NHDP implementation chooses to use pa= cket sequence number as part of its link quality mechanism, as it may, then= an unprotected packet header is a vulnerability.

(For the sake of completeness, RFC 6622 also allows address block signature= s. I don't have a reason to suggest using this within NHDP or OLSRv2.)<= br>
--
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://ww= w.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


A New Internet-Draft is avail= able from the on-line Internet-Drafts directories. This draft is a work ite= m of the Mobile Ad-hoc Networks Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Integrity Check Values an= d Timestamps For Router Admittance in NHDP
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ulrich Herberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas Heide Clausen =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-nhdp-sec-02.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-29

=A0 =A0This document specifies a security extension to the MANET
=A0 =A0Neighborhood Discovery Protocol (NHDP). =A0The extension introduces = the
=A0 =A0use of Integrity Check Values (ICVs) and Timestamps in HELLO message= s
=A0 =A0in order to provide a router admittance mechanism, and therefore to<= br> =A0 =A0counter a selection of security threats to NHDP.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mane= t-nhdp-sec-02.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-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/<= /a>

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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.
********************************************************************


--f46d042ef5fb403dad04c4a6af39-- From hrogge@googlemail.com Thu Jul 12 12:11: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 3439511E8114 for ; Thu, 12 Jul 2012 12:11:02 -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 osHcmuISAhqu for ; Thu, 12 Jul 2012 12:11:01 -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 D19ED11E80F9 for ; Thu, 12 Jul 2012 12:11:00 -0700 (PDT) Received: by yenq13 with SMTP id q13so3038815yen.31 for ; Thu, 12 Jul 2012 12:11: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; bh=bp9quVr0qA09BQRp+1kC2OfLz8pKcMp9/BSHA1AUswU=; b=u89OgI+0hTWtprFXLdWODKH+QE62ILv0YZWMavLAQNLYelstPzD9FJ+fclvPFcf0zq X6xe2sqQFrmazzq/VAzUKq8AJ5cw65ELUxcN8P4OJxhLK04+nHIIDlijD6lCta6Wj4iT BW5A2YvOb/IQFNiyylnvQ3psQspzPSlzA2klTnm7qi7BNs1vpd/cgbJjNXcjXQ9p91Vr whPY2Ei0BMrOhpO5e1qnT6+ocldP6KAb1LgXZPN6JJM8Pg5PVbSNi4/TUpf2BgjJKg5Q umkhiPCgg7nKeKiDembjaSbzyNrup4ok8zEjG/vMBgxp2qT7uPwOmswiTUHGPPGnuDRe dWPQ== Received: by 10.68.232.232 with SMTP id tr8mr7840514pbc.73.1342120294369; Thu, 12 Jul 2012 12:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.241.131 with HTTP; Thu, 12 Jul 2012 12:11:14 -0700 (PDT) In-Reply-To: References: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Thu, 12 Jul 2012 21:11:14 +0200 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 19:11:02 -0000 I agree, packet signatures are a different kind of context. Instead of authenticating a message for the rest of the network, they deal with neighbor authentication. The packet signature will never be forwarded and might even work on a totally different key-scheme. Henning Rogge On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg wrote: > Dear Chris, > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > messages as well. I don't think that signing the packet is enough, since > that does not provide end-to-end security. Instead, I suggest to submit a > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and > how to handle these messages in OLSRv2. > > However, I believe that it would be beneficial for certain applications to > also be able to sign/verify packets. But I don't think that the NHDP-sec > document is the right place for this, since other applications (e.g. DYMO) > may not use HELLO messages at all, but would still like to sign/verify > packets. > Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets? > > Best > Ulrich > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > wrote: >> >> (Sending again, to sort out the formatting problem with the last attempt.) >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to sign >> HELLO messages. RFC 6622 actually allows for signing packets as well as >> signing messages (both, either, or neither to be used as required). There >> isn't a major difference when considering HELLO messages, as few if any >> packets will contain more than one HELLO message, and the packet and the >> message will be signed by the same party. >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> OLSRv2. Any security mechanism that is described in what will be an RFC for >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has >> TC messages to consider, and they don't satisfy the points noted above (on >> number or on who signs them). And one option for OLSRv2 is to sign all >> packets, not messages. This can be a sensible decision there, for several >> reasons, in some real circumstances. >> >> Consequently, I don't believe that this draft should describe only signing >> HELLO messages as the correct thing to do, that it should also allow signing >> packets as an equal status option. If someone wants to raise the possibility >> of signing (possibly by methods with different properties) both at the >> message and packet level, that may have its use cases too. >> >> Incidentally, even within the limited framework of just NHDP, it is >> possible that packets need protection. If an NHDP implementation chooses to >> use packet sequence number as part of its link quality mechanism, as it may, >> then an unprotected packet header is a vulnerability. >> >> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP or >> OLSRv2.) >> >> -- >> 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 >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobile Ad-hoc Networks Working >> Group of the IETF. >> >> Title : Using Integrity Check Values and Timestamps For >> Router Admittance in NHDP >> Author(s) : Ulrich Herberg >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> Pages : 12 >> Date : 2012-05-29 >> >> This document specifies a security extension to the MANET >> Neighborhood Discovery Protocol (NHDP). The extension introduces the >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages >> in order to provide a router admittance mechanism, and therefore to >> counter 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-02.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-02.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- 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 Thu Jul 12 13:38: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 863F111E8096 for ; Thu, 12 Jul 2012 13:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 MyJAEebEaK13 for ; Thu, 12 Jul 2012 13:38:47 -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 890B411E8080 for ; Thu, 12 Jul 2012 13:38:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1954390vbb.31 for ; Thu, 12 Jul 2012 13:39:14 -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=gR0zYDGxrov1jVv4SixE26E/gbNjrHmdUqEODsWUT+w=; b=V7SF49V7MsZI3zy99/AujI63PueJKJLb6PrD1XaquFNw7GhgS4hAgTOD57nKljgE6h lTpgPNXhjrIJzLwWGq0m2PlsjztpQELAMNmMWPju/T6yclzhJA3e3UQKmcp3rpEcCLJ1 PdS91fU0q6G1CiIPEu1Fowgq0oU93nL0NMZSyXvhn0HyZ19uQTqQl6DYJ8d/H6LDk2cE Cagf8UIj2d45ZDjp4VKmPyUc1SLCedPO4fQHorggdkRKlHe2b4DxeRNFWJ7Wr0CevE5V XGOx1upf4FZ0dx9xvyDNb8+SGyUjFPV8EpnGyExDRel2QQx5ECD3vtYM40vG5RzBkx9Y GUzA== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr22620640vdf.127.1342125554009; Thu, 12 Jul 2012 13:39:14 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 12 Jul 2012 13:39:13 -0700 (PDT) Date: Thu, 12 Jul 2012 22:39:13 +0200 Message-ID: From: Abdussalam Baryun To: ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:38:48 -0000 Hi Ulrich, I am not expert in security issues, but IMHO, I agree with Chris to recommend to include in draft-02 both securing messages and packets (in general for packets), so the document should specify NHDP messages and MANET packets [AB]. The reasons are first, because NHDP is a MANET Interface protocol between neighbor routers. secondly it uses RFC5444 format that the future MANET routers will use. Third, NHDP uses RFC5444 which was specified for information exchange between MANET routers. [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Regards Abdussalam ======= On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg wrote: > Dear Chris, > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > messages as well. I don't think that signing the packet is enough, since > that does not provide end-to-end security. Instead, I suggest to submit a > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and > how to handle these messages in OLSRv2. > > However, I believe that it would be beneficial for certain applications to > also be able to sign/verify packets. But I don't think that the NHDP-sec > document is the right place for this, since other applications (e.g. DYMO) > may not use HELLO messages at all, but would still like to sign/verify > packets. > Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets? > > Best > Ulrich > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > wrote: >> >> (Sending again, to sort out the formatting problem with the last attempt.) >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to sign >> HELLO messages. RFC 6622 actually allows for signing packets as well as >> signing messages (both, either, or neither to be used as required). There >> isn't a major difference when considering HELLO messages, as few if any >> packets will contain more than one HELLO message, and the packet and the >> message will be signed by the same party. >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> OLSRv2. Any security mechanism that is described in what will be an RFC for >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has >> TC messages to consider, and they don't satisfy the points noted above (on >> number or on who signs them). And one option for OLSRv2 is to sign all >> packets, not messages. This can be a sensible decision there, for several >> reasons, in some real circumstances. >> >> Consequently, I don't believe that this draft should describe only signing >> HELLO messages as the correct thing to do, that it should also allow signing >> packets as an equal status option. If someone wants to raise the possibility >> of signing (possibly by methods with different properties) both at the >> message and packet level, that may have its use cases too. >> >> Incidentally, even within the limited framework of just NHDP, it is >> possible that packets need protection. If an NHDP implementation chooses to >> use packet sequence number as part of its link quality mechanism, as it may, >> then an unprotected packet header is a vulnerability. >> >> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP or >> OLSRv2.) >> >> -- >> 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 >> >> 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 >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobile Ad-hoc Networks Working >> Group of the IETF. >> >> Title : Using Integrity Check Values and Timestamps For >> Router Admittance in NHDP >> Author(s) : Ulrich Herberg >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> Pages : 12 >> Date : 2012-05-29 >> >> This document specifies a security extension to the MANET >> Neighborhood Discovery Protocol (NHDP). The extension introduces the >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages >> in order to provide a router admittance mechanism, and therefore to >> counter 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-02.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-02.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> _______________________________________________ >> manet mailing list >> manet at 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 ulrich@herberg.name Thu Jul 12 13:54: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 618C311E80AD for ; Thu, 12 Jul 2012 13:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.503, 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 V2cciPNVWRH2 for ; Thu, 12 Jul 2012 13:54:27 -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 020E211E8096 for ; Thu, 12 Jul 2012 13:54:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4542412pbc.31 for ; Thu, 12 Jul 2012 13:55:01 -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=wx+yHd0TASGTHrG9vHW4mEq1LAG44uZUxZrrtO8HxAg=; b=Dr8pGm+M/c+MK98sAzjn9kCQe3c+o+2wpgbc+LGgw6N+SevA7brY61eeUMvW9c6pFB /Fs4S4rGgZe/w2iYK2FhpGC4ZE6XbHfHJtZXPpUtQROCZWOdK4kiM++WN1I3G0lEmtAC Gf+g0oVkibYDU0Na7yLXsaI2XSQ7dUs5xluyk= 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=wx+yHd0TASGTHrG9vHW4mEq1LAG44uZUxZrrtO8HxAg=; b=LH6u0gsoKfiGSViAa+KOahE0aRWerCk0Xl2hoybzHkBmPmQMWUrELas6UgHrt/Qmh0 lwWKL5t8zsKP9FdZMzLNmaPGObVHyLamf5HVC8MHsGyjSGwO6z3/WPVS6C3/hfuBRAzJ +NA4nG2PvDntYxj1USUTwulyrcXCn1wYvrAioU5DhxT59cxGxSAT78P6K7OlcrTakcCK 6EJthn8EOP/e6XLwWu/o1brV4/tA4v+yTXQP7QeM07GBCM8CVPxgculdhQpcZTMOElZg 1icTLWPnYX6NQh03eeWYixKk202FiIqMVQxOjIQrOOPWqzvJqGbo8hZI6H4U8dpg/L7V WwZg== MIME-Version: 1.0 Received: by 10.68.226.102 with SMTP id rr6mr8432899pbc.99.1342126500828; Thu, 12 Jul 2012 13:55:00 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Thu, 12 Jul 2012 13:54:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 13:54:59 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=e89a8ff257b85355aa04c4a82ddb X-Gm-Message-State: ALoCoQk49Dzpz12gofAQNoFqEWfk+MoJui3de/rbQ3ET7UVZlhm3OxIWMDDeo0cAEW45NfFW9gPI Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:54:28 -0000 --e89a8ff257b85355aa04c4a82ddb Content-Type: text/plain; charset=ISO-8859-1 The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets. Regards Ulrich On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ulrich, > > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. > > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt > > Regards > Abdussalam > ======= > > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: > > Dear Chris, > > > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > > messages as well. I don't think that signing the packet is enough, since > > that does not provide end-to-end security. Instead, I suggest to submit a > > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, > and > > how to handle these messages in OLSRv2. > > > > However, I believe that it would be beneficial for certain applications > to > > also be able to sign/verify packets. But I don't think that the NHDP-sec > > document is the right place for this, since other applications (e.g. > DYMO) > > may not use HELLO messages at all, but would still like to sign/verify > > packets. > > Maybe it would be better to have an extra document "packet-sec" which > > specifies how to sign/verify packets? > > > > Best > > Ulrich > > > > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: > >> > >> (Sending again, to sort out the formatting problem with the last > attempt.) > >> > >> As I read it, this draft is proposing using the RFC 6622 mechanism to > sign > >> HELLO messages. RFC 6622 actually allows for signing packets as well as > >> signing messages (both, either, or neither to be used as required). > There > >> isn't a major difference when considering HELLO messages, as few if any > >> packets will contain more than one HELLO message, and the packet and the > >> message will be signed by the same party. > >> > >> However NHDP doesn't exist in a vacuum, in particular it is used by > >> OLSRv2. Any security mechanism that is described in what will be an RFC > for > >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also > has > >> TC messages to consider, and they don't satisfy the points noted above > (on > >> number or on who signs them). And one option for OLSRv2 is to sign all > >> packets, not messages. This can be a sensible decision there, for > several > >> reasons, in some real circumstances. > >> > >> Consequently, I don't believe that this draft should describe only > signing > >> HELLO messages as the correct thing to do, that it should also allow > signing > >> packets as an equal status option. If someone wants to raise the > possibility > >> of signing (possibly by methods with different properties) both at the > >> message and packet level, that may have its use cases too. > >> > >> Incidentally, even within the limited framework of just NHDP, it is > >> possible that packets need protection. If an NHDP implementation > chooses to > >> use packet sequence number as part of its link quality mechanism, as it > may, > >> then an unprotected packet header is a vulnerability. > >> > >> (For the sake of completeness, RFC 6622 also allows address block > >> signatures. I don't have a reason to suggest using this within NHDP or > >> OLSRv2.) > >> > >> -- > >> 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 > >> > >> 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 > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Mobile Ad-hoc Networks > Working > >> Group of the IETF. > >> > >> Title : Using Integrity Check Values and Timestamps > For > >> Router Admittance in NHDP > >> Author(s) : Ulrich Herberg > >> Thomas Heide Clausen > >> Filename : draft-ietf-manet-nhdp-sec-02.txt > >> Pages : 12 > >> Date : 2012-05-29 > >> > >> This document specifies a security extension to the MANET > >> Neighborhood Discovery Protocol (NHDP). The extension introduces the > >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages > >> in order to provide a router admittance mechanism, and therefore to > >> counter 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-02.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-02.txt > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > >> > >> _______________________________________________ > >> manet mailing list > >> manet at 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. > >> ******************************************************************** > >> > > > --e89a8ff257b85355aa04c4a82ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The document specifies signing/verifying NHDP messages. RFC5444 packets are= not specific to NHDP, and therefore should IMO not be discussed in a docum= ent entitled "Using Integrity Check Values and Timestamps For Router A= dmittance in NHDP". That's why I suggested to handle this in an ad= ditional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 201= 2 at 1:39 PM, Abdussalam Baryun <abdussalambaryun@gmail.com&g= t; wrote:
Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminol= ogy-00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D

On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for = TC
> messages as well. I don't think that signing the packet is enough,= since
> that does not provide end-to-end security. Instead, I suggest to submi= t a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages,= and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain application= s to
> also be able to sign/verify packets. But I don't think that the NH= DP-sec
> document is the right place for this, since other applications (e.g. D= YMO)
> may not use HELLO messages at all, but would still like to sign/verify=
> packets.
> Maybe it would be better to have an extra document "packet-sec&qu= ot; which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)
> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last a= ttempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism= to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as we= ll as
>> signing messages (both, either, or neither to be used as required)= . There
>> isn't a major difference when considering HELLO messages, as f= ew if any
>> packets will contain more than one HELLO message, and the packet a= nd the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is us= ed by
>> OLSRv2. Any security mechanism that is described in what will be a= n RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLS= Rv2 also has
>> TC messages to consider, and they don't satisfy the points not= ed above (on
>> number or on who signs them). And one option for OLSRv2 is to sign= all
>> packets, not messages. This can be a sensible decision there, for = several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe = only signing
>> HELLO messages as the correct thing to do, that it should also all= ow signing
>> packets as an equal status option. If someone wants to raise the p= ossibility
>> of signing (possibly by methods with different properties) both at= the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it i= s
>> possible that packets need protection. If an NHDP implementation c= hooses to
>> use packet sequence number as part of its link quality mechanism, = as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block<= br> >> signatures. I don't have a reason to suggest using this within= NHDP or
>> OLSRv2.)
>>
>> --
>> 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.dearlove at 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
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories. This draft is a work item of the Mobile Ad-hoc Networ= ks Working
>> Group of the IETF.
>>
>> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Integrity Check = Values and Timestamps For
>> Router Admittance in NHDP
>> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ulrich Herberg
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas Heide C= lausen
>> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-nhdp-se= c-02.txt
>> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
>> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-29
>>
>> =A0 =A0This document specifies a security extension to the MANET >> =A0 =A0Neighborhood Discovery Protocol (NHDP). =A0The extension in= troduces the
>> =A0 =A0use of Integrity Check Values (ICVs) and Timestamps in HELL= O messages
>> =A0 =A0in order to provide a router admittance mechanism, and ther= efore to
>> =A0 =A0counter 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-02.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-ie= tf-manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-n= hdp-sec/
>>
>> _______________________________________________
>> manet mailing list
>> manet at ietf.org
>> https://www.ietf.org/mailma= n/listinfo/manet
>>
>>
>> ******************************************************************= **
>> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended<= br> >> 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.
>> ******************************************************************= **
>>
>

--e89a8ff257b85355aa04c4a82ddb-- From thomas@thomasclausen.org Thu Jul 12 15:07: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 E4FFB11E80EE for ; Thu, 12 Jul 2012 15:07:39 -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 kf6Qg-kz4rDl for ; Thu, 12 Jul 2012 15:07:38 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3758811E80E3 for ; Thu, 12 Jul 2012 15:07:38 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 760415580D0 for ; Thu, 12 Jul 2012 15:08:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 010311C5B4E; Thu, 12 Jul 2012 15:08:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 132511C060D; Thu, 12 Jul 2012 15:08:10 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6DC61FEB-0E24-4357-B2B9-07ACBC1BF4A6 Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 13 Jul 2012 00:08:51 +0200 To: Ulrich Herberg Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:07:40 -0000 --Apple-Mail-6DC61FEB-0E24-4357-B2B9-07ACBC1BF4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Ulrich.=20 Note that this is all about "messages" in as much as NHDP is concerned. 1) NHDP specifies something akin to "an implementation may recognize additio= nal reasons for considering a HELLO message invalid for processing"; this I-= D specifies such an additional reason, by way of a TLV in HELLO messages. 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming H= ELLO message post-demultiplication. Including the ICV Message TLV in HELLO m= essages therefore makes sense. Ad 1), I note that this I-D is intended to exactly plug in at that place in 6= 130. 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 12 Jul 2012, at 22:54, Ulrich Herberg wrote: > The document specifies signing/verifying NHDP messages. RFC5444 packets ar= e not specific to NHDP, and therefore should IMO not be discussed in a docum= ent entitled "Using Integrity Check Values and Timestamps For Router Admitta= nce in NHDP". That's why I suggested to handle this in an additional documen= t for RFC5444 packets. >=20 > Regards > Ulrich >=20 > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun wrote: > Hi Ulrich, >=20 > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. >=20 > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >=20 > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D >=20 > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg w= rote: > > Dear Chris, > > > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC= > > messages as well. I don't think that signing the packet is enough, since= > > that does not provide end-to-end security. Instead, I suggest to submit a= > > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, a= nd > > how to handle these messages in OLSRv2. > > > > However, I believe that it would be beneficial for certain applications t= o > > also be able to sign/verify packets. But I don't think that the NHDP-sec= > > document is the right place for this, since other applications (e.g. DYM= O) > > may not use HELLO messages at all, but would still like to sign/verify > > packets. > > Maybe it would be better to have an extra document "packet-sec" which > > specifies how to sign/verify packets? > > > > Best > > Ulrich > > > > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: > >> > >> (Sending again, to sort out the formatting problem with the last attemp= t.) > >> > >> As I read it, this draft is proposing using the RFC 6622 mechanism to s= ign > >> HELLO messages. RFC 6622 actually allows for signing packets as well as= > >> signing messages (both, either, or neither to be used as required). The= re > >> isn't a major difference when considering HELLO messages, as few if any= > >> packets will contain more than one HELLO message, and the packet and th= e > >> message will be signed by the same party. > >> > >> However NHDP doesn't exist in a vacuum, in particular it is used by > >> OLSRv2. Any security mechanism that is described in what will be an RFC= for > >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also h= as > >> TC messages to consider, and they don't satisfy the points noted above (= on > >> number or on who signs them). And one option for OLSRv2 is to sign all > >> packets, not messages. This can be a sensible decision there, for sever= al > >> reasons, in some real circumstances. > >> > >> Consequently, I don't believe that this draft should describe only sign= ing > >> HELLO messages as the correct thing to do, that it should also allow si= gning > >> packets as an equal status option. If someone wants to raise the possib= ility > >> of signing (possibly by methods with different properties) both at the > >> message and packet level, that may have its use cases too. > >> > >> Incidentally, even within the limited framework of just NHDP, it is > >> possible that packets need protection. If an NHDP implementation choose= s to > >> use packet sequence number as part of its link quality mechanism, as it= may, > >> then an unprotected packet header is a vulnerability. > >> > >> (For the sake of completeness, RFC 6622 also allows address block > >> signatures. I don't have a reason to suggest using this within NHDP or > >> OLSRv2.) > >> > >> -- > >> 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 > >> > >> 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 > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Mobile Ad-hoc Networks Wo= rking > >> Group of the IETF. > >> > >> Title : Using Integrity Check Values and Timestamps Fo= r > >> Router Admittance in NHDP > >> Author(s) : Ulrich Herberg > >> Thomas Heide Clausen > >> Filename : draft-ietf-manet-nhdp-sec-02.txt > >> Pages : 12 > >> Date : 2012-05-29 > >> > >> This document specifies a security extension to the MANET > >> Neighborhood Discovery Protocol (NHDP). The extension introduces th= e > >> use of Integrity Check Values (ICVs) and Timestamps in HELLO message= s > >> in order to provide a router admittance mechanism, and therefore to > >> counter 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-02.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-02.txt > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > >> > >> _______________________________________________ > >> manet mailing list > >> manet at 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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-6DC61FEB-0E24-4357-B2B9-07ACBC1BF4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I agree with Ulrich. =

Note that this is all about "messages" in as much a= s NHDP is concerned.

1) NHDP specifies something aki= n to "an implementation may recognize additional reasons for considering a H= ELLO message invalid for processing"; this I-D specifies such an additional r= eason, by way of a TLV in HELLO messages.

2)= NHDP "owns" HELLO messages, and therefore gets first dip on an incoming HEL= LO message post-demultiplication. Including the ICV Message TLV in HELLO mes= sages therefore makes sense.

Ad 1), I note that thi= s I-D is intended to exactly plug in at that place in 6130.

Thomas

-- 
Thomas Heide Clausen

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

On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:

The document specifies signing/verifying NHDP messag= es. RFC5444 packets are not specific to NHDP, and therefore should IMO not b= e discussed in a document entitled "Using Integrity Check Values and Timesta= mps For Router Admittance in NHDP". That's why I suggested to handle this in= an additional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 2012= at 1:39 PM, Abdussalam Baryun <abdussalambaryun@gmail.com><= /span> wrote:
Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminolog= y-00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D

On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for T= C
> messages as well. I don't think that signing the packet is enough, sinc= e
> that does not provide end-to-end security. Instead, I suggest to submit= a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, a= nd
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain applications= to
> also be able to sign/verify packets. But I don't think that the NHDP-se= c
> document is the right place for this, since other applications (e.g. DY= MO)
> may not use HELLO messages at all, but would still like to sign/verify<= br> > packets.
> Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)
> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last at= tempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism t= o sign
>> HELLO messages. RFC 6622 actually allows for signing packets as wel= l as
>> signing messages (both, either, or neither to be used as required).= There
>> isn't a major difference when considering HELLO messages, as few if= any
>> packets will contain more than one HELLO message, and the packet an= d the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used by=
>> OLSRv2. Any security mechanism that is described in what will be an= RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 a= lso has
>> TC messages to consider, and they don't satisfy the points noted ab= ove (on
>> number or on who signs them). And one option for OLSRv2 is to sign a= ll
>> packets, not messages. This can be a sensible decision there, for s= everal
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only s= igning
>> HELLO messages as the correct thing to do, that it should also allo= w signing
>> packets as an equal status option. If someone wants to raise the po= ssibility
>> of signing (possibly by methods with different properties) both at t= he
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it is=
>> possible that packets need protection. If an NHDP implementation ch= ooses to
>> use packet sequence number as part of its link quality mechanism, a= s it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP= or
>> OLSRv2.)
>>
>> --
>> 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
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace C= entre,
>> Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts<= br> >> directories. This draft is a work item of the Mobile Ad-hoc Network= s Working
>> Group of the IETF.
>>
>>         Title          = ; : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulrich= Herberg
>>                   &nbs= p;       Thomas Heide Clausen
>>         Filename        : d= raft-ietf-manet-nhdp-sec-02.txt
>>         Pages          = ; : 12
>>         Date          =  : 2012-05-29
>>
>>    This document specifies a security extension to the MA= NET
>>    Neighborhood Discovery Protocol (NHDP).  The exte= nsion introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps in= HELLO messages
>>    in order to provide a router admittance mechanism, and= therefore to
>>    counter a selection of security threats to NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ie= tf-manet-nhdp-sec-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> f= tp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf= -manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhd= p-sec/
>>
>> _______________________________________________
>> manet mailing list
>> manet at = 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.<= br> >> 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/mai= lman/listinfo/manet
= --Apple-Mail-6DC61FEB-0E24-4357-B2B9-07ACBC1BF4A6-- From abdussalambaryun@gmail.com Thu Jul 12 19:09: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 D44ED21F8569 for ; Thu, 12 Jul 2012 19:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 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 QUJ5m2hO+8Ot for ; Thu, 12 Jul 2012 19:09:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B980621F8565 for ; Thu, 12 Jul 2012 19:09:44 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so318330vcb.31 for ; Thu, 12 Jul 2012 19:10:19 -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=kJKEk7Sw0WyzcTmHN+gfc8/REwK23M4jgTjVG15AY0o=; b=db2KBwNpzgj5sbEaWk3bi9Sk9APjzmFwKK5BxR7q0Fu2sLBvpQEnqj9zyqelkTblbo kKmhRlhBS+fyV/r1Eejc1DQWYdgGCPp0ip10vPVn0jv9Ay7iBLnv/hsNzHqY0Hg6/N7J cmHgQ1VdA+TperlV7NrYZCsaZU1vjlz1eO3WydX68f05JI8xfbHS0Pa+GtNB8SB8Mp4u DJ8rGQtMTnb78YOAGg5Cf0wMn3Cx/mLTfhfqsGGNblfHkjmovMslGPHyKqt1L/Id+f6S GLWZ3MNlJJ7D+GoASYxdsvZCW8qXxAGVlByU9UfdShG9jJwmEtXs9PxUxR/+yycPzC+m 3Thg== MIME-Version: 1.0 Received: by 10.220.228.193 with SMTP id jf1mr227446vcb.73.1342145419008; Thu, 12 Jul 2012 19:10:19 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 12 Jul 2012 19:10:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jul 2012 04:10:17 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 02:09:49 -0000 Hi Ulrich, I will need to read Chris message reasons again. However, when the RFC6130 document was written/updating maybe no one asked for adding packet specification that is why RFC6130 does not specify packet, also does not object it. So in future a request/update may appear. RFC6130 seams to be designed for All MANET Routings, so for example including reactives as AODV, DSR, DYMO, and LOAD. I think it is important for Reactive protocols to have packet specified. RFC6130>page 9> Is applicable to networks, especially wireless networks, in which unknown neighbors can be reached by local broadcast or multicast packets. meaning> Reaches neighbors by local broadcast OR multicast [RFC5444] packets. I will request/suggest (after issuing draft-dsrv2) to consider to update RFC6130 (I don't mind doing draft) to specify packets as a tool for neighbor discovery. In DSRv2 source-routing neighbor discovery specified in packets is needed, which MANET Packets [AB] are used by NHDP. I suggest that it will be interesting for AODVv2 (the needed reactive in WG) as well to use *optional* packets in its neighbor discovery with metric-type in MANET Packet instead of only the hello message. [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Abdussalam =============== On 7/12/12, Ulrich Herberg wrote: > The document specifies signing/verifying NHDP messages. RFC5444 packets are > not specific to NHDP, and therefore should IMO not be discussed in a > document entitled "Using Integrity Check Values and Timestamps For Router > Admittance in NHDP". That's why I suggested to handle this in an additional > document for RFC5444 packets. > > Regards > Ulrich > > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Ulrich, >> >> I am not expert in security issues, but IMHO, I agree with Chris to >> recommend to include in draft-02 both securing messages and packets >> (in general for packets), so the document should specify NHDP messages >> and MANET packets [AB]. The reasons are first, because NHDP is a MANET >> Interface protocol between neighbor routers. secondly it uses RFC5444 >> format that the future MANET routers will use. Third, NHDP uses >> RFC5444 which was specified for information exchange between MANET >> routers. >> >> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >> >> Regards >> Abdussalam >> ======= >> >> On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg >> wrote: >> > Dear Chris, >> > >> > I agree that we need to provide similar mechanisms as in NHDP-sec for >> > TC >> > messages as well. I don't think that signing the packet is enough, >> > since >> > that does not provide end-to-end security. Instead, I suggest to submit >> > a >> > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, >> and >> > how to handle these messages in OLSRv2. >> > >> > However, I believe that it would be beneficial for certain applications >> to >> > also be able to sign/verify packets. But I don't think that the >> > NHDP-sec >> > document is the right place for this, since other applications (e.g. >> DYMO) >> > may not use HELLO messages at all, but would still like to sign/verify >> > packets. >> > Maybe it would be better to have an extra document "packet-sec" which >> > specifies how to sign/verify packets? >> > >> > Best >> > Ulrich >> > >> > >> > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) >> > wrote: >> >> >> >> (Sending again, to sort out the formatting problem with the last >> attempt.) >> >> >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to >> sign >> >> HELLO messages. RFC 6622 actually allows for signing packets as well >> >> as >> >> signing messages (both, either, or neither to be used as required). >> There >> >> isn't a major difference when considering HELLO messages, as few if >> >> any >> >> packets will contain more than one HELLO message, and the packet and >> >> the >> >> message will be signed by the same party. >> >> >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> >> OLSRv2. Any security mechanism that is described in what will be an >> >> RFC >> for >> >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also >> has >> >> TC messages to consider, and they don't satisfy the points noted above >> (on >> >> number or on who signs them). And one option for OLSRv2 is to sign all >> >> packets, not messages. This can be a sensible decision there, for >> several >> >> reasons, in some real circumstances. >> >> >> >> Consequently, I don't believe that this draft should describe only >> signing >> >> HELLO messages as the correct thing to do, that it should also allow >> signing >> >> packets as an equal status option. If someone wants to raise the >> possibility >> >> of signing (possibly by methods with different properties) both at the >> >> message and packet level, that may have its use cases too. >> >> >> >> Incidentally, even within the limited framework of just NHDP, it is >> >> possible that packets need protection. If an NHDP implementation >> chooses to >> >> use packet sequence number as part of its link quality mechanism, as >> >> it >> may, >> >> then an unprotected packet header is a vulnerability. >> >> >> >> (For the sake of completeness, RFC 6622 also allows address block >> >> signatures. I don't have a reason to suggest using this within NHDP or >> >> OLSRv2.) >> >> >> >> -- >> >> 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 >> >> >> >> 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 >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. This draft is a work item of the Mobile Ad-hoc Networks >> Working >> >> Group of the IETF. >> >> >> >> Title : Using Integrity Check Values and Timestamps >> For >> >> Router Admittance in NHDP >> >> Author(s) : Ulrich Herberg >> >> Thomas Heide Clausen >> >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> >> Pages : 12 >> >> Date : 2012-05-29 >> >> >> >> This document specifies a security extension to the MANET >> >> Neighborhood Discovery Protocol (NHDP). The extension introduces >> >> the >> >> use of Integrity Check Values (ICVs) and Timestamps in HELLO >> >> messages >> >> in order to provide a router admittance mechanism, and therefore to >> >> counter 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-02.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-02.txt >> >> >> >> The IETF datatracker page for this Internet-Draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> >> >> _______________________________________________ >> >> manet mailing list >> >> manet at ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> >> ******************************************************************** >> >> This email and any attachments are confidential to the intended >> >> recipient and may also be privileged. If you are not the intended >> >> recipient please delete it from your system and notify the sender. >> >> You should not copy it or use it for any purpose nor disclose or >> >> distribute its contents to any other person. >> >> ******************************************************************** >> >> >> > >> > From abdussalambaryun@gmail.com Thu Jul 12 19:25: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 99CE811E8085 for ; Thu, 12 Jul 2012 19:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 yhUL8OeynC1x for ; Thu, 12 Jul 2012 19:25:48 -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 D073011E8072 for ; Thu, 12 Jul 2012 19:25:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2106112vbb.31 for ; Thu, 12 Jul 2012 19:26:22 -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=QftL5/FBJy26FFbjJDLkGhAE0VpJSs0qIUsGoqhrbeE=; b=BZ9Twl0lmRHQTmRxaVwowUdeqeuEyPAlgNTyq30yXcJXz5YwJMZP9jeFkOsmflBqiH zACQMTWCCCywNBgNhNyTCA+IesCbPcrZbtar/muYUcqJI/7hoRRYeZWQKCIt0geQDNTu 7EOBcy6iC6vK8FVVdoP36c8aAJWQCnVUNHDqPBoeyxlIuf7DVYznZbTPmE1VRIZV1L1v MGbK4G15nfNGae31dAqBarIfWcXBr5302FoQCBZhOUHkOHYSDV1X4l6nhD7BvC0XSKPF mZW+4bzIuBJBcjcdY9Zx20NzjjeE4USlqFehok/XWUj6pjiiq5/2fp9eSpjFbJjh4YtF 6Maw== MIME-Version: 1.0 Received: by 10.52.97.227 with SMTP id ed3mr224809vdb.103.1342146382408; Thu, 12 Jul 2012 19:26:22 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Thu, 12 Jul 2012 19:26:22 -0700 (PDT) Date: Fri, 13 Jul 2012 04:26:22 +0200 Message-ID: From: Abdussalam Baryun To: thomas@thomasclausen.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 02:25:48 -0000 Hi Thomas, > I agree with Ulrich. > > > Note that this is all about "messages" in as much as NHDP is concerned. > It is about securing neighbor discovery, the draft: manet-nhdp-sec-02 > > 1) NHDP specifies something akin to "an implementation may recognize > additional reasons for considering a HELLO message invalid for > processing"; this I-D specifies such an additional reason, by way of a > TLV in HELLO messages. > yes it does in NHDP, but it does not restrict to messages only, because it uses/understands [RFC5444] packets. > > 2) NHDP "owns" HELLO messages, and therefore gets first dip on an > incoming HELLO message post-demultiplication. Including the ICV > Message TLV in HELLO messages therefore makes sense. > It may own/create the [5444] packet carrying the hello messages AB ============== > > > On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: > > > The document specifies signing/verifying NHDP messages. RFC5444 > packets are not specific to NHDP, and therefore should IMO not be > discussed in a document entitled "Using Integrity Check Values and > Timestamps For Router Admittance in NHDP". That's why I suggested to > handle this in an additional document for RFC5444 packets. > > Regards > Ulrich > > > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun at gmail.com> wrote: > > Hi Ulrich, > > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. > > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt > > Regards > Abdussalam > ======= > From thomas@thomasclausen.org Thu Jul 12 19:38: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 F0F4721F85E0 for ; Thu, 12 Jul 2012 19:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 VgBj4omiX3qd for ; Thu, 12 Jul 2012 19:38:56 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED921F85DF for ; Thu, 12 Jul 2012 19:38:56 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B614A55800F for ; Thu, 12 Jul 2012 19:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F140B1BD4AF5; Thu, 12 Jul 2012 19:39:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8DDF51BD487D; Thu, 12 Jul 2012 19:39:28 -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: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 13 Jul 2012 04:40:06 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 02:38:57 -0000 On 13 Jul 2012, at 04:26, Abdussalam Baryun wro= te: > Hi Thomas, >=20 >> I agree with Ulrich. >>=20 >>=20 >> Note that this is all about "messages" in as much as NHDP is concerned. >>=20 >=20 > It is about securing neighbor discovery, the draft: manet-nhdp-sec-02 No. It is about securing a specific neighborhood discovery protocol - a prot= ocol, whose signaling is carried in RFC5444 _messages_. >> 1) NHDP specifies something akin to "an implementation may recognize >> additional reasons for considering a HELLO message invalid for >> processing"; this I-D specifies such an additional reason, by way of a >> TLV in HELLO messages. >>=20 >=20 > yes it does in NHDP, but it does not restrict to messages only, > because it uses/understands [RFC5444] packets. Irrelevant. RFC6130 speaks of reasons for considering messages invalid. >> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >> incoming HELLO message post-demultiplication. Including the ICV >> Message TLV in HELLO messages therefore makes sense. >>=20 >=20 > It may own/create the [5444] packet carrying the hello messages >=20 No, it may not. See how demultiplexing of RFC5444 messages work, as well as w= hat RFC6130 says for HELLO messages. Thomas > AB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >> On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: >>=20 >>=20 >> The document specifies signing/verifying NHDP messages. RFC5444 >> packets are not specific to NHDP, and therefore should IMO not be >> discussed in a document entitled "Using Integrity Check Values and >> Timestamps For Router Admittance in NHDP". That's why I suggested to >> handle this in an additional document for RFC5444 packets. >>=20 >> Regards >> Ulrich >>=20 >>=20 >> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun > at gmail.com> wrote: >>=20 >> Hi Ulrich, >>=20 >> I am not expert in security issues, but IMHO, I agree with Chris to >> recommend to include in draft-02 both securing messages and packets >> (in general for packets), so the document should specify NHDP messages >> and MANET packets [AB]. The reasons are first, because NHDP is a MANET >> Interface protocol between neighbor routers. secondly it uses RFC5444 >> format that the future MANET routers will use. Third, NHDP uses >> RFC5444 which was specified for information exchange between MANET >> routers. >>=20 >> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>=20 >> Regards >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D >>=20 From ietf@thomasclausen.org Thu Jul 12 19:51: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 217AB11E80D6 for ; Thu, 12 Jul 2012 19:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, 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 nVrJd2ZIJGEx for ; Thu, 12 Jul 2012 19:51:55 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2811E8085 for ; Thu, 12 Jul 2012 19:51:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 9E6A7558086 for ; Thu, 12 Jul 2012 19:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 29DBC1C084C; Thu, 12 Jul 2012 19:52:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6CECB1C060D; Thu, 12 Jul 2012 19:52:16 -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: <8F7EED3D-F0BD-4059-9B0E-C6EB3B3B7E55@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 13 Jul 2012 04:52:57 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 02:51:56 -0000 On 13 Jul 2012, at 04:10, Abdussalam Baryun wro= te: > Hi Ulrich, >=20 > I will need to read Chris message reasons again. However, when the > RFC6130 document was written/updating maybe no one asked for adding > packet specification that is why RFC6130 does not specify packet, also > does not object it. Incorrect. RFC6130 specifies use of RFC5444. All messages are carried in pac= kets in RFC5444. > So in future a request/update may appear. RFC6130 > seams to be designed for All MANET Routings, so for example including > reactives as AODV, DSR, DYMO, and LOAD. I think it is important for > Reactive protocols to have packet specified. ???? > RFC6130>page 9> Is applicable to networks, especially wireless > networks, in which > unknown neighbors can be reached by local broadcast or multicast packets. >=20 > meaning> Reaches neighbors by local broadcast OR multicast [RFC5444] packe= ts. >=20 > I will request/suggest (after issuing draft-dsrv2) to consider to > update RFC6130 (I don't mind doing draft) to specify packets as a tool > for neighbor discovery. In DSRv2 source-routing neighbor discovery > specified in packets is needed, which MANET Packets [AB] are used by > NHDP. I suggest that it will be interesting for AODVv2 (the needed > reactive in WG) as well to use *optional* packets in its neighbor > discovery with metric-type in MANET Packet instead of only the hello > message. I am sorry to be blunt, but it appears clear to me from the above, that you'= ve not understood RFC5444 nor RFC5498. Do you understand that, in RFC5444, a message _always_ is contained in a _pa= cket_? That a _packet_ serves as a mechanism for efficiency for containing m= ultiple _messages_ in a single transmission? That a _message_ serves for rel= ating information conveyed to a specific protocol and so as a demultiplexing= mechanism? I would suggest studying and understanding the different protocols, before r= ushing to call for their update. Best, Thomas > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >=20 > Abdussalam > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On 7/12/12, Ulrich Herberg wrote: >> The document specifies signing/verifying NHDP messages. RFC5444 packets a= re >> not specific to NHDP, and therefore should IMO not be discussed in a >> document entitled "Using Integrity Check Values and Timestamps For Router= >> Admittance in NHDP". That's why I suggested to handle this in an addition= al >> document for RFC5444 packets. >>=20 >> Regards >> Ulrich >>=20 >> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >>=20 >>> Hi Ulrich, >>>=20 >>> I am not expert in security issues, but IMHO, I agree with Chris to >>> recommend to include in draft-02 both securing messages and packets >>> (in general for packets), so the document should specify NHDP messages >>> and MANET packets [AB]. The reasons are first, because NHDP is a MANET >>> Interface protocol between neighbor routers. secondly it uses RFC5444 >>> format that the future MANET routers will use. Third, NHDP uses >>> RFC5444 which was specified for information exchange between MANET >>> routers. >>>=20 >>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>=20 >>> Regards >>> Abdussalam >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg = >>> wrote: >>>> Dear Chris, >>>>=20 >>>> I agree that we need to provide similar mechanisms as in NHDP-sec for >>>> TC >>>> messages as well. I don't think that signing the packet is enough, >>>> since >>>> that does not provide end-to-end security. Instead, I suggest to submit= >>>> a >>>> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, >>> and >>>> how to handle these messages in OLSRv2. >>>>=20 >>>> However, I believe that it would be beneficial for certain applications= >>> to >>>> also be able to sign/verify packets. But I don't think that the >>>> NHDP-sec >>>> document is the right place for this, since other applications (e.g. >>> DYMO) >>>> may not use HELLO messages at all, but would still like to sign/verify >>>> packets. >>>> Maybe it would be better to have an extra document "packet-sec" which >>>> specifies how to sign/verify packets? >>>>=20 >>>> Best >>>> Ulrich >>>>=20 >>>>=20 >>>> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) >>>> wrote: >>>>>=20 >>>>> (Sending again, to sort out the formatting problem with the last >>> attempt.) >>>>>=20 >>>>> As I read it, this draft is proposing using the RFC 6622 mechanism to >>> sign >>>>> HELLO messages. RFC 6622 actually allows for signing packets as well >>>>> as >>>>> signing messages (both, either, or neither to be used as required). >>> There >>>>> isn't a major difference when considering HELLO messages, as few if >>>>> any >>>>> packets will contain more than one HELLO message, and the packet and >>>>> the >>>>> message will be signed by the same party. >>>>>=20 >>>>> However NHDP doesn't exist in a vacuum, in particular it is used by >>>>> OLSRv2. Any security mechanism that is described in what will be an >>>>> RFC >>> for >>>>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also= >>> has >>>>> TC messages to consider, and they don't satisfy the points noted above= >>> (on >>>>> number or on who signs them). And one option for OLSRv2 is to sign all= >>>>> packets, not messages. This can be a sensible decision there, for >>> several >>>>> reasons, in some real circumstances. >>>>>=20 >>>>> Consequently, I don't believe that this draft should describe only >>> signing >>>>> HELLO messages as the correct thing to do, that it should also allow >>> signing >>>>> packets as an equal status option. If someone wants to raise the >>> possibility >>>>> of signing (possibly by methods with different properties) both at the= >>>>> message and packet level, that may have its use cases too. >>>>>=20 >>>>> Incidentally, even within the limited framework of just NHDP, it is >>>>> possible that packets need protection. If an NHDP implementation >>> chooses to >>>>> use packet sequence number as part of its link quality mechanism, as >>>>> it >>> may, >>>>> then an unprotected packet header is a vulnerability. >>>>>=20 >>>>> (For the sake of completeness, RFC 6622 also allows address block >>>>> signatures. I don't have a reason to suggest using this within NHDP or= >>>>> OLSRv2.) >>>>>=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 >>>>>=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 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. This draft is a work item of the Mobile Ad-hoc Networks >>> Working >>>>> Group of the IETF. >>>>>=20 >>>>> Title : Using Integrity Check Values and Timestamps >>> For >>>>> Router Admittance in NHDP >>>>> Author(s) : Ulrich Herberg >>>>> Thomas Heide Clausen >>>>> Filename : draft-ietf-manet-nhdp-sec-02.txt >>>>> Pages : 12 >>>>> Date : 2012-05-29 >>>>>=20 >>>>> This document specifies a security extension to the MANET >>>>> Neighborhood Discovery Protocol (NHDP). The extension introduces >>>>> the >>>>> use of Integrity Check Values (ICVs) and Timestamps in HELLO >>>>> messages >>>>> in order to provide a router admittance mechanism, and therefore to >>>>> counter a selection of security threats to NHDP. >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt >>>>>=20 >>>>> The IETF datatracker page for this Internet-Draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet at 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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jul 12 20:28: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 F310511E8096 for ; Thu, 12 Jul 2012 20:28: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 TTdrVru8lFsY for ; Thu, 12 Jul 2012 20:28: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 ABEA911E8093 for ; Thu, 12 Jul 2012 20:28:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5023165pbc.31 for ; Thu, 12 Jul 2012 20:29: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=2N/oTo5tRQOYnP/iakxf4Ux8/kgPpuZq2TySs6Ev3f8=; b=ulL6cWLRBMStQCVHru3XdfcZDjuMxXhPLfdKv7uG+j33gVDSDDkk8D5VX96Ndwen2b tG2PPQxuCGQVXmcDbQhf/1+eM/33P33Phd+/QL+6XlSSbUiygBEB6KH6FSpP3N5eYQXP 30VuWbt4HNO88telqkuFVs4pk+wNnBV2o7Vg8= 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=2N/oTo5tRQOYnP/iakxf4Ux8/kgPpuZq2TySs6Ev3f8=; b=UzH1ARmaI1bVljz5GUBkncq3553SR8L2GIAb2Y3q5uwIhNbUbwfXefmYz6ZjS/ZWKU YxWd5fZPktNkr+4gSBeTqPN5f57sF41N8hm1ryaor5jXXFXxdpMcKzpWJEFewTTuJH0A qm2szvGPchFxRN4qdzc0MqXJ0A9oLiy4iOD7fIsXeO78bBXblLz40aqfowqhNX+Y0fvG +i49MwDK+AS3yx6sA5y74+IMY2E1Cr3PbvHbYmwn1Rt4azZhM+09nBFo5IsHGSYPF2+3 we4746+nRu1H2nknZWz07U2q/O302Ea4xNL5N7VKR1EabIQ4xwVSbz3y3SyARcMhfAyQ ez3g== Received: by 10.66.84.33 with SMTP id v1mr1546792pay.44.1342150140645; Thu, 12 Jul 2012 20:29:00 -0700 (PDT) Received: from [192.168.1.5] (c-24-5-73-168.hsd1.ca.comcast.net. [24.5.73.168]) by mx.google.com with ESMTPS id oq4sm5090153pbb.21.2012.07.12.20.28.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 20:28:59 -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: <153855B3-8A6A-45F0-A11C-150C49717E11@herberg.name> X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Thu, 12 Jul 2012 20:29:02 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQm5AD8/bQDVYuozDMVPSf3Qhez/J4weCYjq/5KYYkQfLPFWTiA9OH6I68FzeiWHHvAl1rJo Cc: manet Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 03:28:27 -0000 There was no WG consensus to work on subnet models back at IETF82 (or anytim= e after that).=20 Ulrich On Jul 12, 2012, at 11:53, Abdussalam Baryun wr= ote: >>> Investigating examples can help to come up with a more abstract model of= different management and monitoring approaches. >=20 > Please note that the presenter of [Radio, SatCom, and considerations] > in 82 meeting stated that it is not possible to define a manange model > before defining layer 2 subnet model, which I agreed from before [1] > and worked on the draft of MANET L2 subnets starting on 8 June [2]. >=20 > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12961.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13032.html >=20 > AB > =3D=3D=3D=3D=3D=3D >=20 > On 7/6/12, Abdussalam Baryun wrote: >> Hi Ulrich, >>=20 >> I thank you for this, I am happy that IESG have requested this. Mr. >> Cole in the meeting 82 had introduced the problem (please check his >> presentation), which I presented to the MANET. Yes we need in MANET to >> be focus on use-case, and how management is done. It is important that >> MANET documents interact with Internet drafts. >>=20 >> I included Mr.Cole presentation (Nov.2011) in my I-D draft about >> MANET subnet technologies, and propose that any new I-D for management >> should take it into consideration. >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >>=20 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > To: manet at ietf.org > Subject: [manet] MANET management use cases > From: Ulrich Herberg > Date: Thu, 5 Jul 2012 17:43:12 -0700 >>> Hi, >>>=20 >>> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >>> IESG evaluation to specify use cases how MANETs are monitored and >>> managed using SNMP. After discussion with Benoit and Adrian, we agreed >>> that such information would be useful, but that the MIB module (as >>> pure APIs) would likely be the wrong place. Moreover, the use cases >>> would not necessarily be specific to the NHDP-MIB, but concern all MIB >>> modules. Benoit requested that we come up with a new informational >>> draft in the WG, which discusses different MANET management use cases. >>>=20 >>> Bob started working on collecting management and monitoring scenarios >>> from the military experience. I believe that it would also be >>> interesting to cover other use cases, such as in disaster recovery >>> (e.g., monitoring and management of routers thrown out of an airplane >>> over a disaster area) or in community networks (e.g., >>> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >>> can help to come up with a more abstract model of different management >>> and monitoring approaches. It would be helpful if participants in this >>> WG with MANET deployment and management/monitoring experience could >>> contribute to such an effort. >>>=20 >>> As a side note, there is a new mailing list about management of >>> constrained networks and devices (coma at ietf.org), which may be of >>> interest for some of the WG participants. >>>=20 >>> Best regards >>> Ulrich >>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jul 12 20:31: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 7155F11E809A for ; Thu, 12 Jul 2012 20:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, 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 v3Xj7RdS7n9x for ; Thu, 12 Jul 2012 20:31:11 -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 9297C11E8096 for ; Thu, 12 Jul 2012 20:31:11 -0700 (PDT) Received: by yenq13 with SMTP id q13so3424283yen.31 for ; Thu, 12 Jul 2012 20:31:46 -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=2LbfAXb/BdlMQZuSwJRmzeGAeifbifi2AIXOIvPv2TE=; b=ndxQVOmD5ES8DbLw45T4N6ecCf3J2f/isxOI2C/4dWnYxOQhGWFNxANRNg6H4mD4EW T7XiZkAZxxosegYe6z+Y1rZOJ3eJ7YIC5yaxICRAjQ568iFNGQN573mJo0VmkUi6ijXm 33v0S0yWhm0M3CnwhjotbPhg54UGVylvkdd+Y= 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=2LbfAXb/BdlMQZuSwJRmzeGAeifbifi2AIXOIvPv2TE=; b=gUqkBoYy3b9WXZMa3Jg7bQSSTrNqDcDtnY2OnnkUjGEBac+Qk0g8N6abQsR9KP+cOY mXob3AkDNrCcU2U3m9Ix+RUmVAReNfKOSiOGgmEZxtebpKBQuf2mEr+AHUsJXY+iGfyp FnaR+mFeDogemTY31ZJcjpkveV7T59fm4UBfBbgUJTxAplw6admkI1GcECjq9tHMhMtM GtskC4cXrUB2NmE4ESi2o+yBPZRyggxNU0SfNTjvlWVcMZgeKcvWRbB2jEgnUIjuk7Tf O8w52NMocLYAMUqevQ5hY+1YNIE0oIOIoBnr/4vxxEk1C7IAvjn9e9XepHrj8lzAnfv0 FUuA== Received: by 10.66.80.34 with SMTP id o2mr1593338pax.36.1342150305846; Thu, 12 Jul 2012 20:31:45 -0700 (PDT) Received: from [192.168.1.5] (c-24-5-73-168.hsd1.ca.comcast.net. [24.5.73.168]) by mx.google.com with ESMTPS id qp9sm5097359pbc.9.2012.07.12.20.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 20:31:45 -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: <71F98B5B-C225-467D-B90A-69DB96FAAD8C@herberg.name> X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Thu, 12 Jul 2012 20:31:47 -0700 To: "Cole, Robert G CIV USARMY CERDEC (US)" X-Gm-Message-State: ALoCoQnox8tojOjeA+Sd3RcOX67tp5VEi3q3lGrJHNcv4d4w62+7L7y8hty5t+D3jIODPyVT4AJw Cc: manet , Abdussalam Baryun Subject: Re: [manet] NHDP-MIB: ifType (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 03:31:12 -0000 I agree with Bob Ulrich On Jul 7, 2012, at 10:00, "Cole, Robert G CIV USARMY CERDEC (US)" wrote: > Classification: UNCLASSIFIED > Caveats: NONE >=20 > Our proposal is not mandating the use of NHDP. Instead it is flexible and= > allows whatever combination of MANET control protocols that makes sense. >=20 > Thanks, Bob=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: Friday, July 06, 2012 5:35 PM > To: Ulrich Herberg > Cc: manet > Subject: Re: [manet] NHDP-MIB: ifType >=20 > Hi Ulrich, >=20 > You mention routing protocols already please read in your thread, >=20 >> additional boolean flag which determines whether the interface uses > > NHDP or not (i.e., if a router runs both DYMO and NHDP, the > DYMO-only >=20 > Please note that DYMO will not use NHDP, only if using RFC5444. I just > mentioned the DSRv2 I am doing, >=20 > AB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > On 7/6/12, Ulrich Herberg wrote: >> That is not what I said. I just recommended that this email thread is=20 >> about the ifType in the NHDP-MIB, not about DSRv2, and that such a=20 >> discussion (if >> desired) should be in another email with different subject. >>=20 >> Best >> Ulrich >>=20 >> On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun <=20 >> abdussalambaryun@gmail.com> wrote: >>=20 >>> I am sorry I will never post in your threads, if you like that, >>>=20 >>> AB >>>=20 >>> On 7/6/12, Ulrich Herberg wrote: >>>> Abdussalam, >>>>=20 >>>> note that this has nothing to do with the protocol itself, but only=20 >>>> for >>> the >>>> MIB. So, unless you draft a MIB module, you will not need the ifType. >>>>=20 >>>> If you want to discuss DSRv2 (which I doubt the WG should work on), >>> please >>>> open a new email thread, since this thread was only about the=20 >>>> NHDP-MIB draft. >>>>=20 >>>> Best >>>> Ulrich >>>>=20 >>>> On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun <=20 >>>> abdussalambaryun@gmail.com> wrote: >>>>=20 >>>>> +1 >>>>>=20 >>>>> I need the NHDP as a MANET interface for the DSRv2, which I=20 >>>>> suggested for DSRv2 before, so I like/agree that you consider the=20 >>>>> flag ifType, thanks very much, >>>>>=20 >>>>> It is interesting if most manet routings use NHDP or even be=20 >>>>> possible to use in future, because I think it is a MANET interface=20 >>>>> as specified in OLSRv2. >>>>>=20 >>>>> AB >>>>> ++++++++ >>>>>> Hi, >>>>>>=20 >>>>>> we are currently working on a revised ID of the NHDP-MIB, as=20 >>>>>> follow-up on requests during the IESG review. Amongst others,=20 >>>>>> one request from Thomas Nadeau may affect other MIB documents as=20 >>>>>> well, which is why I post it on the mailing list. >>>>>>=20 >>>>>> The current interface table in the NHDP-MIB is a copy of the=20 >>>>>> interface MIB, with potentially many entries that are not MANET=20 >>>>>> interfaces (but still waste space). What we are really=20 >>>>>> interested in is monitoring and managing NHDP interfaces. Thomas=20 >>>>>> Nadeau suggested to ask IANA to specify a ifType=3DMANET (as=20 >>>>>> allowed by RFC2863 and the IANAifType registry), and to list=20 >>>>>> only those in the NHDP-MIB. Bob and I propose that IANA=20 >>>>>> allocates such an ifType, which covers all MANET WG protocols,=20 >>>>>> i.e. ifType=3DMANET would be used for interfaces running NHDP,=20 >>>>>> OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an=20 >>>>>> additional boolean flag which determines whether the interface=20 >>>>>> uses NHDP or not (i.e., if a router runs both DYMO and NHDP, the=20 >>>>>> DYMO-only interfaces would be listed in the nhdpIfTable, but the=20 >>>>>> boolean flag is false). >>>>>>=20 >>>>>>=20 >>>>>> Best regards >>>>>> Ulrich >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 > Classification: UNCLASSIFIED > Caveats: NONE >=20 >=20 From abdussalambaryun@gmail.com Fri Jul 13 02:35: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 3CC8A21F867D for ; Fri, 13 Jul 2012 02:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 RdZDCAEj7ZJ0 for ; Fri, 13 Jul 2012 02:35:33 -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 39C0421F867B for ; Fri, 13 Jul 2012 02:35:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2298097vbb.31 for ; Fri, 13 Jul 2012 02:36:08 -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=JQsw32FSmL7k01jOFkdPsbArkH1rks4MwdKdHwDHVCQ=; b=WMIkEbVWKy3JKYxwrZ+TAlIxPJ0Jo1qt8eDjeEXkHStAe5nK7MM+lPp71fON48iMny ZWK9XJVITeAHKENC67JSWBAhkJ+rlMcJqsWqxpP/ik3raPVXtJNs6nfE/E5m8Dg2SL5A GfHyzFtOYoRxO1+Pe5TacNh3yRhwpm5/+9WkU0tE8mOz/0fu5HdNBLNcqVEKosQHUfj4 xxoBUBDbOu/GuUQzI4tBhC9/YUS+pCLHyD1dgXJJIeP4gg20221rY/6Cz7APn4DYxp0z kSSqxWVdWTG5EmHrXwlxwYNN5tCciQP8WsL36WfnQP7fulGQGuIaotR0QzI3RfZCaDIF s2iA== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr140513vds.117.1342172168658; Fri, 13 Jul 2012 02:36:08 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 02:36:08 -0700 (PDT) Date: Fri, 13 Jul 2012 11:36:08 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 09:35:34 -0000 >Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt >From: Henning Rogge >Date: Thu, 12 Jul 2012 21:11:14 +0200 > > I agree, > > packet signatures are a different kind of context. Instead of > authenticating a message for the rest of the network, they deal with > neighbor authentication. The packet signature will never be forwarded > and might even work on a totally different key-scheme. Please note that NHDP's packets may be used in the control plane with DLEP or it may be bridged between node neighbors (encapsulated in frames instead of IP packets), so it does not always need forwarding. AB > > Henning Rogge > > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: >> Dear Chris, >> >> I agree that we need to provide similar mechanisms as in NHDP-sec for TC >> messages as well. I don't think that signing the packet is enough, since >> that does not provide end-to-end security. Instead, I suggest to submit a >> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, >> and >> how to handle these messages in OLSRv2. >> >> However, I believe that it would be beneficial for certain applications >> to >> also be able to sign/verify packets. But I don't think that the NHDP-sec >> document is the right place for this, since other applications (e.g. >> DYMO) >> may not use HELLO messages at all, but would still like to sign/verify >> packets. >> Maybe it would be better to have an extra document "packet-sec" which >> specifies how to sign/verify packets? >> >> Best >> Ulrich >> >> > From abdussalambaryun@gmail.com Fri Jul 13 03:02: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 15BFF21F86A8 for ; Fri, 13 Jul 2012 03:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 f+MNkPBFIOmx for ; Fri, 13 Jul 2012 03:02:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD221F86B3 for ; Fri, 13 Jul 2012 03:02:50 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so530955vcb.31 for ; Fri, 13 Jul 2012 03:03:26 -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=C1GyOL5MPVofF3EQeyJB19uSvGLV0Cw+zNVc323ilsw=; b=MJyj/ORhNXjOTOuWodncWKAzt8jFSVzkbu1GW1ok9kPhmyPfV+FtVmlzwyiA0TGUtj whs3mYTX6advRGbt4jH/57mVUxI3ERuPN1SzVa2N1OKBWz4Gk+c64h3VnNsn6YUgiCMm b0YBf/XlpFdi1I7L33M6rIo/1MzSV5rLJuGM6xw5H18EzpXZ1QcDR5Nao+JMVVikN+ZR mWZbe9eGi9x/iqZRnO4q1Eu3dl3lM0SFOC9DfG99mY0+R5n/mk7AjQwGXkuQfviqwiC+ As7gFH4mFdQB8NuD4OvksjqI9FptdoX9MZpf5xAAxbv6O+qUx3SX3jrKcor1hRW1UC8s ZrPw== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr178762vds.117.1342173806153; Fri, 13 Jul 2012 03:03:26 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 03:03:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jul 2012 12:03:26 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 10:02:53 -0000 Hi, AB>> It is about securing neighbor discovery, the draft: manet-nhdp-sec-02 > > No. It is about securing a specific neighborhood discovery protocol - a > protocol, whose signaling is carried in RFC5444 _messages_. > NHDP was not designed for specific purpose of one proactive routing, but for All MANET Routers. I agree that it specifies messages not packets as Ulrich mentioned before, but there is no MUST in RFC6130 that its signalling MUST be only messages, we need to consider the specification's requirement language (MUST, SHOULD, MAY,..etc), there is no restrictions, there is room for update :) >>> 1) NHDP specifies something akin to "an implementation may recognize >>> additional reasons for considering a HELLO message invalid for >>> processing"; this I-D specifies such an additional reason, by way of a >>> TLV in HELLO messages. >>> >> AB>> yes it does in NHDP, but it does not restrict to messages only, >> because it uses/understands [RFC5444] packets. > > Irrelevant. RFC6130 speaks of reasons for considering messages invalid. > Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry specified NHDP-messages. yes, also speaks of invalid NHDP-messages please read: RFC6130> page 40> A router *MAY* recognize additional reasons for identifying that a message is badly formed and therefore invalid for processing. meaning> there may be a use of NHDP packet check as well >>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >>> incoming HELLO message post-demultiplication. Including the ICV >>> Message TLV in HELLO messages therefore makes sense. >>> >> >> It may own/create the [5444] packet carrying the hello messages >> > > No, it may not. See how demultiplexing of RFC5444 messages work, as well as > what RFC6130 says for HELLO messages. > Please provide me which page or sentence mentions your understanding as: *MAY NOT* create 5444-packets. I will do your advise to look into the RFC6130 again for demultiplexing of NHDP-messages, and will reply. Thanking you, Abdussalam Baryun, ========================================== >>> >>> >>> On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: >>> >>> >>> The document specifies signing/verifying NHDP messages. RFC5444 >>> packets are not specific to NHDP, and therefore should IMO not be >>> discussed in a document entitled "Using Integrity Check Values and >>> Timestamps For Router Admittance in NHDP". That's why I suggested to >>> handle this in an additional document for RFC5444 packets. >>> >>> Regards >>> Ulrich >>> >>> >>> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun >> at gmail.com> wrote: >>> >>> Hi Ulrich, >>> >>> I am not expert in security issues, but IMHO, I agree with Chris to >>> recommend to include in draft-02 both securing messages and packets >>> (in general for packets), so the document should specify NHDP messages >>> and MANET packets [AB]. The reasons are first, because NHDP is a MANET >>> Interface protocol between neighbor routers. secondly it uses RFC5444 >>> format that the future MANET routers will use. Third, NHDP uses >>> RFC5444 which was specified for information exchange between MANET >>> routers. >>> >>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>> >>> Regards >>> Abdussalam >>> ======= >>> > From thomas@thomasclausen.org Fri Jul 13 03: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 9847421F86A4 for ; Fri, 13 Jul 2012 03:34:39 -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 WYl3lT6i2c4A for ; Fri, 13 Jul 2012 03:34:38 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C5C4721F86A3 for ; Fri, 13 Jul 2012 03:34:38 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id BC79D557F70 for ; Fri, 13 Jul 2012 03:35:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 21A751BD77D3; Fri, 13 Jul 2012 03:35:13 -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 688F41BD77D2; Fri, 13 Jul 2012 03:35:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: Date: Fri, 13 Jul 2012 12:35:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: manet Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 10:34:39 -0000 On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote: > Hi, >=20 > AB>> It is about securing neighbor discovery, the draft: = manet-nhdp-sec-02 >>=20 >> No. It is about securing a specific neighborhood discovery protocol - = a >> protocol, whose signaling is carried in RFC5444 _messages_. >>=20 >=20 > NHDP was not designed for specific purpose of one proactive routing, > but for All MANET Routers. I agree that it specifies messages not > packets as Ulrich mentioned before, but there is no MUST in RFC6130 > that its signalling MUST be only messages, we need to consider the > specification's requirement language (MUST, SHOULD, MAY,..etc), there > is no restrictions, there is room for update :) No, that is wrong. RFC6130 specifies the use of RFC5444 messages. If you want to use smoke-signals, carved potatoes or something else not = specified in RFC6130, then you're simply not using RFC6130. This has nothing to do with requirements language. >>>> 1) NHDP specifies something akin to "an implementation may = recognize >>>> additional reasons for considering a HELLO message invalid for >>>> processing"; this I-D specifies such an additional reason, by way = of a >>>> TLV in HELLO messages. >>>>=20 >>>=20 > AB>> yes it does in NHDP, but it does not restrict to messages only, >>> because it uses/understands [RFC5444] packets. >>=20 >> Irrelevant. RFC6130 speaks of reasons for considering messages = invalid. >>=20 >=20 > Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry > specified NHDP-messages. yes, also speaks of invalid NHDP-messages > please read: >=20 > RFC6130> page 40> A router *MAY* recognize additional reasons for > identifying that a message is badly formed and therefore invalid for > processing. >=20 > meaning> there may be a use of NHDP packet check as well For exactly the reasons I gave in the above. Plus, that for RFC6130 to use packet header content would constitute a = layer violation (and a very badly designed system). >=20 >>>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >>>> incoming HELLO message post-demultiplication. Including the ICV >>>> Message TLV in HELLO messages therefore makes sense. >>>>=20 >>>=20 >>> It may own/create the [5444] packet carrying the hello messages >>>=20 >>=20 >> No, it may not. See how demultiplexing of RFC5444 messages work, as = well as >> what RFC6130 says for HELLO messages. >>=20 >=20 > Please provide me which page or sentence mentions your understanding > as: *MAY NOT* create 5444-packets. I will do your advise to look into > the RFC6130 again for demultiplexing of NHDP-messages, and will reply. I don't think that you understand RFC6130 or RFC5444 at all.=20 RFC6130 generates RFC5444 messages, which are carried (as are all = RFC5444 messages) in RFC5444 packets. A protocol generating something not specified in RFC6130 is not RFC6130. I do not know how it can be made more clear. Thomas > Thanking you, > Abdussalam Baryun, > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>=20 >>>> On 12 Jul 2012, at 22:54, Ulrich Herberg = wrote: >>>>=20 >>>>=20 >>>> The document specifies signing/verifying NHDP messages. RFC5444 >>>> packets are not specific to NHDP, and therefore should IMO not be >>>> discussed in a document entitled "Using Integrity Check Values and >>>> Timestamps For Router Admittance in NHDP". That's why I suggested = to >>>> handle this in an additional document for RFC5444 packets. >>>>=20 >>>> Regards >>>> Ulrich >>>>=20 >>>>=20 >>>> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun = >>> at gmail.com> wrote: >>>>=20 >>>> Hi Ulrich, >>>>=20 >>>> I am not expert in security issues, but IMHO, I agree with Chris to >>>> recommend to include in draft-02 both securing messages and packets >>>> (in general for packets), so the document should specify NHDP = messages >>>> and MANET packets [AB]. The reasons are first, because NHDP is a = MANET >>>> Interface protocol between neighbor routers. secondly it uses = RFC5444 >>>> format that the future MANET routers will use. Third, NHDP uses >>>> RFC5444 which was specified for information exchange between MANET >>>> routers. >>>>=20 >>>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>=20 >>>> Regards >>>> Abdussalam >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>=20 From abdussalambaryun@gmail.com Fri Jul 13 03:53: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 DE6E721F85F7 for ; Fri, 13 Jul 2012 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 V2NPKVzgEtR8 for ; Fri, 13 Jul 2012 03:53:48 -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 0499921F8599 for ; Fri, 13 Jul 2012 03:53:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2341740vbb.31 for ; Fri, 13 Jul 2012 03:54:23 -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=RyfoKNsztU05BywY4f2pj+gUOR5wqH8GcVfacl5sKeU=; b=tGC4P7VYD1sedgn/3zISClGHDlNUayfsqaeGW+T8fsGIns0urGtJuHQNJj78Olr/oS YDtjwCByMDMM8Ad24DLOp7n8R7RSkE26m/zl4Cfl5TywogWCt7jKOMsqq1kYvxU6dfVO 0161n7MwKJ8NssadTAakiuFi7sRcTFiB3c8B9kU0pSi4Pj3iooB2lFQJhwWt6TpisxMx l7ipz4rz2Md9cbrlihNYe1Jo9FXs1H1XOUKXvxc6xH1lFPGi7gsym5sFnC01puglVzPP 7qUbhiV2l9sn5QvSvOCdfy5FdYH3ZSGbljaH01Lq71RGiTy/wqBTup5KzSDLYmCBfvsJ wrdw== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr258205vds.117.1342176863521; Fri, 13 Jul 2012 03:54:23 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 03:54:23 -0700 (PDT) In-Reply-To: <8F7EED3D-F0BD-4059-9B0E-C6EB3B3B7E55@thomasclausen.org> References: <8F7EED3D-F0BD-4059-9B0E-C6EB3B3B7E55@thomasclausen.org> Date: Fri, 13 Jul 2012 12:54:23 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 10:53:50 -0000 Hi Thomas, >> I will need to read Chris message reasons again. However, when the >> RFC6130 document was written/updating maybe no one asked for adding >> packet specification that is why RFC6130 does not specify packet, also >> does not object it. > > Incorrect. RFC6130 specifies use of RFC5444. All messages are carried in > packets in RFC5444. > I agree that RFC6130 specify use of RFC5444, and all NHDP-messages are carried in RFC5444-packets. But I am correct that there is no mention of the requirement language that: NHDP *MUST NOT* be creating RFC5444-Packets or using them in signalling. >> So in future a request/update may appear. RFC6130 >> seams to be designed for All MANET Routings, so for example including >> reactives as AODV, DSR, DYMO, and LOAD. I think it is important for >> Reactive protocols to have packet specified. > > ???? no information to reply ! > >> RFC6130>page 9> Is applicable to networks, especially wireless >> networks, in which >> unknown neighbors can be reached by local broadcast or multicast packets. >> >> meaning> Reaches neighbors by local broadcast OR multicast [RFC5444] >> packets. >> >> I will request/suggest (after issuing draft-dsrv2) to consider to >> update RFC6130 (I don't mind doing draft) to specify packets as a tool >> for neighbor discovery. In DSRv2 source-routing neighbor discovery >> specified in packets is needed, which MANET Packets [AB] are used by >> NHDP. I suggest that it will be interesting for AODVv2 (the needed >> reactive in WG) as well to use *optional* packets in its neighbor >> discovery with metric-type in MANET Packet instead of only the hello >> message. > > I am sorry to be blunt, but it appears clear to me from the above, that > you've not understood RFC5444 nor RFC5498. > Why I don't understand? I see that the language used in RFC5444, RFC5498, and RFC6130, does not mention, *MUST NOT*, or other restrictions is having NHDP specifying packets for its behavior. If you think I am incorrect please point to a reference paragraph in these documents. > Do you understand that, in RFC5444, a message _always_ is contained in a > _packet_? That a _packet_ serves as a mechanism for efficiency for > containing multiple _messages_ in a single transmission? That a _message_ > serves for relating information conveyed to a specific protocol and so as a > demultiplexing mechanism? Yes I do understand, that a RFC5444 packet MAY contain RFC5444-messages (RFC5444 page 24), and that a RFC5444-message May be encapsulated in RFC5444-packets ( RFC5444 section 5.2). we always need to follow the requirement language in Standards documents. > > I would suggest studying and understanding the different protocols, before > rushing to call for their update. > I am sorry if desturbed, but I am really interested in NHDP and would like to make the better use of it. However, I will do your advise and not rush into the call, but will discuss the idea of the updates on the list, I thank you for your comment and advises, Best Regards Abdussalam Baryun ================================================== >> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >> >> Abdussalam >> =============== >> >> On 7/12/12, Ulrich Herberg wrote: >>> The document specifies signing/verifying NHDP messages. RFC5444 packets >>> are >>> not specific to NHDP, and therefore should IMO not be discussed in a >>> document entitled "Using Integrity Check Values and Timestamps For >>> Router >>> Admittance in NHDP". That's why I suggested to handle this in an >>> additional >>> document for RFC5444 packets. >>> >>> Regards >>> Ulrich >>> >>> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> Hi Ulrich, >>>> >>>> I am not expert in security issues, but IMHO, I agree with Chris to >>>> recommend to include in draft-02 both securing messages and packets >>>> (in general for packets), so the document should specify NHDP messages >>>> and MANET packets [AB]. The reasons are first, because NHDP is a MANET >>>> Interface protocol between neighbor routers. secondly it uses RFC5444 >>>> format that the future MANET routers will use. Third, NHDP uses >>>> RFC5444 which was specified for information exchange between MANET >>>> routers. >>>> >>>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>> >>>> Regards >>>> Abdussalam >>>> ======= >>>> >>>> On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg >>> herberg.name> >>>> wrote: >>>>> Dear Chris, >>>>> >>>>> I agree that we need to provide similar mechanisms as in NHDP-sec for >>>>> TC >>>>> messages as well. I don't think that signing the packet is enough, >>>>> since >>>>> that does not provide end-to-end security. Instead, I suggest to >>>>> submit >>>>> a >>>>> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, >>>> and >>>>> how to handle these messages in OLSRv2. >>>>> >>>>> However, I believe that it would be beneficial for certain >>>>> applications >>>> to >>>>> also be able to sign/verify packets. But I don't think that the >>>>> NHDP-sec >>>>> document is the right place for this, since other applications (e.g. >>>> DYMO) >>>>> may not use HELLO messages at all, but would still like to sign/verify >>>>> packets. >>>>> Maybe it would be better to have an extra document "packet-sec" which >>>>> specifies how to sign/verify packets? >>>>> >>>>> Best >>>>> Ulrich >>>>> >>>>> >>>>> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) >>>>> wrote: >>>>>> >>>>>> (Sending again, to sort out the formatting problem with the last >>>> attempt.) >>>>>> >>>>>> As I read it, this draft is proposing using the RFC 6622 mechanism to >>>> sign >>>>>> HELLO messages. RFC 6622 actually allows for signing packets as well >>>>>> as >>>>>> signing messages (both, either, or neither to be used as required). >>>> There >>>>>> isn't a major difference when considering HELLO messages, as few if >>>>>> any >>>>>> packets will contain more than one HELLO message, and the packet and >>>>>> the >>>>>> message will be signed by the same party. >>>>>> >>>>>> However NHDP doesn't exist in a vacuum, in particular it is used by >>>>>> OLSRv2. Any security mechanism that is described in what will be an >>>>>> RFC >>>> for >>>>>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 >>>>>> also >>>> has >>>>>> TC messages to consider, and they don't satisfy the points noted >>>>>> above >>>> (on >>>>>> number or on who signs them). And one option for OLSRv2 is to sign >>>>>> all >>>>>> packets, not messages. This can be a sensible decision there, for >>>> several >>>>>> reasons, in some real circumstances. >>>>>> >>>>>> Consequently, I don't believe that this draft should describe only >>>> signing >>>>>> HELLO messages as the correct thing to do, that it should also allow >>>> signing >>>>>> packets as an equal status option. If someone wants to raise the >>>> possibility >>>>>> of signing (possibly by methods with different properties) both at >>>>>> the >>>>>> message and packet level, that may have its use cases too. >>>>>> >>>>>> Incidentally, even within the limited framework of just NHDP, it is >>>>>> possible that packets need protection. If an NHDP implementation >>>> chooses to >>>>>> use packet sequence number as part of its link quality mechanism, as >>>>>> it >>>> may, >>>>>> then an unprotected packet header is a vulnerability. >>>>>> >>>>>> (For the sake of completeness, RFC 6622 also allows address block >>>>>> signatures. I don't have a reason to suggest using this within NHDP >>>>>> or >>>>>> OLSRv2.) >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. This draft is a work item of the Mobile Ad-hoc Networks >>>> Working >>>>>> Group of the IETF. >>>>>> >>>>>> Title : Using Integrity Check Values and Timestamps >>>> For >>>>>> Router Admittance in NHDP >>>>>> Author(s) : Ulrich Herberg >>>>>> Thomas Heide Clausen >>>>>> Filename : draft-ietf-manet-nhdp-sec-02.txt >>>>>> Pages : 12 >>>>>> Date : 2012-05-29 >>>>>> >>>>>> This document specifies a security extension to the MANET >>>>>> Neighborhood Discovery Protocol (NHDP). The extension introduces >>>>>> the >>>>>> use of Integrity Check Values (ICVs) and Timestamps in HELLO >>>>>> messages >>>>>> in order to provide a router admittance mechanism, and therefore to >>>>>> counter 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-02.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-02.txt >>>>>> >>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet at ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>>> ******************************************************************** >>>>>> This email and any attachments are confidential to the intended >>>>>> recipient and may also be privileged. If you are not the intended >>>>>> recipient please delete it from your system and notify the sender. >>>>>> You should not copy it or use it for any purpose nor disclose or >>>>>> distribute its contents to any other person. >>>>>> ******************************************************************** >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Jul 13 04: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 31C0121F8694 for ; Fri, 13 Jul 2012 04:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 9qi6vH6PwseT for ; Fri, 13 Jul 2012 04:01:45 -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 5793221F8681 for ; Fri, 13 Jul 2012 04:01:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2346146vbb.31 for ; Fri, 13 Jul 2012 04:02: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=QTFV5KjZeWW5YSWyOfLEQF9Cym5Ja6p24KYnabG5b3s=; b=jk/SJ8TaDMx2uQFT/g7cpzMpRdoKwUwyojdk2YPNuq4NQFtY8Bwx5SUnr2en6ykvX5 ifnWOYXIiVnEWSs2zI8X2vu/DJPu8u7b/wbCUpVe9lAKh5EKvhmGSzeqU3FoXZAtzpqY sBMKTd8E7PXWNah/HXqyDwnzOCW5neVoq0rPjQQwaKAxG0LoXt4ILeX5Uru+Q3hx/IlR vH6BzIelsjB2FAg7CNRzpyYGMsCijyBsfjIKpPwwivSu7VZgi7gqt6kpixEAbsCQUzNb 8E4OOrYRG7XLg+clHQZCOFpqBKpW/f0n313zLm7lODbY/e965M/GtyH2UCaRO/8j8rPy +ogA== MIME-Version: 1.0 Received: by 10.220.149.15 with SMTP id r15mr370892vcv.1.1342177340956; Fri, 13 Jul 2012 04:02:20 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 04:02:20 -0700 (PDT) In-Reply-To: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> References: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> Date: Fri, 13 Jul 2012 13:02:20 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 11:01:46 -0000 Hi Thomas, > RFC6130 generates RFC5444 messages, which are carried (as are all RFC5444 > messages) in RFC5444 packets. > A protocol generating something not specified in RFC6130 is not RFC6130. > I do not know how it can be made more clear. I agreed from before that RFC6130 not specify packets, that was the point for the discussing the update, however, I beleive NHDP idea can be extended, and RFC6130 MAY be updated in future. Please note that RFC5444 mentions in page 7: Packets MAY be unicast or multicast and may use any appropriate transport protocol or none. Best regards Abdussalam ================================================== On 7/13/12, Thomas Heide Clausen wrote: > > On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote: > >> Hi, >> >> AB>> It is about securing neighbor discovery, the draft: >> manet-nhdp-sec-02 >>> >>> No. It is about securing a specific neighborhood discovery protocol - a >>> protocol, whose signaling is carried in RFC5444 _messages_. >>> >> >> NHDP was not designed for specific purpose of one proactive routing, >> but for All MANET Routers. I agree that it specifies messages not >> packets as Ulrich mentioned before, but there is no MUST in RFC6130 >> that its signalling MUST be only messages, we need to consider the >> specification's requirement language (MUST, SHOULD, MAY,..etc), there >> is no restrictions, there is room for update :) > > No, that is wrong. RFC6130 specifies the use of RFC5444 messages. > > If you want to use smoke-signals, carved potatoes or something else not > specified in RFC6130, then you're simply not using RFC6130. > > This has nothing to do with requirements language. > >>>>> 1) NHDP specifies something akin to "an implementation may recognize >>>>> additional reasons for considering a HELLO message invalid for >>>>> processing"; this I-D specifies such an additional reason, by way of a >>>>> TLV in HELLO messages. >>>>> >>>> >> AB>> yes it does in NHDP, but it does not restrict to messages only, >>>> because it uses/understands [RFC5444] packets. >>> >>> Irrelevant. RFC6130 speaks of reasons for considering messages invalid. >>> >> >> Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry >> specified NHDP-messages. yes, also speaks of invalid NHDP-messages >> please read: >> >> RFC6130> page 40> A router *MAY* recognize additional reasons for >> identifying that a message is badly formed and therefore invalid for >> processing. >> >> meaning> there may be a use of NHDP packet check as well > > For exactly the reasons I gave in the above. > > Plus, that for RFC6130 to use packet header content would constitute a layer > violation (and a very badly designed system). > >> >>>>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >>>>> incoming HELLO message post-demultiplication. Including the ICV >>>>> Message TLV in HELLO messages therefore makes sense. >>>>> >>>> >>>> It may own/create the [5444] packet carrying the hello messages >>>> >>> >>> No, it may not. See how demultiplexing of RFC5444 messages work, as well >>> as >>> what RFC6130 says for HELLO messages. >>> >> >> Please provide me which page or sentence mentions your understanding >> as: *MAY NOT* create 5444-packets. I will do your advise to look into >> the RFC6130 again for demultiplexing of NHDP-messages, and will reply. > > I don't think that you understand RFC6130 or RFC5444 at all. > > RFC6130 generates RFC5444 messages, which are carried (as are all RFC5444 > messages) in RFC5444 packets. > > A protocol generating something not specified in RFC6130 is not RFC6130. > > I do not know how it can be made more clear. > > Thomas > > From abdussalambaryun@gmail.com Fri Jul 13 04:19: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 6652321F86A3 for ; Fri, 13 Jul 2012 04:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 pt9IAh11mqGq for ; Fri, 13 Jul 2012 04:19:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6220E21F86A2 for ; Fri, 13 Jul 2012 04:19:30 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so573815vcb.31 for ; Fri, 13 Jul 2012 04:20: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=R++t9MJzEkVdNNmcAWr+Wby+8GkHUoJmVIpSOUur0pc=; b=v0IOJJeQvDfCy398ouS5zj7RLMZuFvwH+LdVdXZjMardy0E1yYlGnTxtw8rB4B8Jlh eQa3tdezmh7Hw1fnIpf4dcv//htdoURfk6dd9gLyvhKXUSNlW4PsdLDvKAXI/SJPDNo6 cgrlRYO+JUIROy96htOPgPXasOf6DdNT6I8YhGM8Jmv1JVm/c+9clAptyfV+7Fk7TtIY rCSwPwDGhcY6UUrBcChjdDgpK2J2EMf4w2sh1CxiAeOAPBAIvLcHlyn9is8P3+W2XOEw Sy9XDH6G7Y0Mbdzp3MVIzb9cSDsDBZYVUTnb2Qx3NUfGjlw00YVLZXuONWH/tfETwbdn 1IPA== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr313955vdi.86.1342178405598; Fri, 13 Jul 2012 04:20:05 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 04:20:05 -0700 (PDT) In-Reply-To: <153855B3-8A6A-45F0-A11C-150C49717E11@herberg.name> References: <153855B3-8A6A-45F0-A11C-150C49717E11@herberg.name> Date: Fri, 13 Jul 2012 13:20:05 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET management use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 11:19:31 -0000 Hi Ulrich, There was no sound objection either (please check it again), which I understood, furthermore, there was no call for consensus. Please note that the reasons of defining were clear, but the reasons for not defining were not clear. The IETF82 MANET WG did not convince Mr. Cole, and discussion is still open the list because the meeting was short and the chair was trying to close the discussion because limited time. However, I see now that Mr.Benoit input agreed with Mr.Cole somehow that management issues needs such MANET definitions. AB ========= On 7/13/12, Ulrich Herberg wrote: > There was no WG consensus to work on subnet models back at IETF82 (or > anytime after that). > > Ulrich > > On Jul 12, 2012, at 11:53, Abdussalam Baryun > wrote: > >>>> Investigating examples can help to come up with a more abstract model of >>>> different management and monitoring approaches. >> >> Please note that the presenter of [Radio, SatCom, and considerations] >> in 82 meeting stated that it is not possible to define a manange model >> before defining layer 2 subnet model, which I agreed from before [1] >> and worked on the draft of MANET L2 subnets starting on 8 June [2]. >> >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12961.html >> [2] http://www.ietf.org/mail-archive/web/manet/current/msg13032.html >> >> AB >> ====== >> >> On 7/6/12, Abdussalam Baryun wrote: >>> Hi Ulrich, >>> >>> I thank you for this, I am happy that IESG have requested this. Mr. >>> Cole in the meeting 82 had introduced the problem (please check his >>> presentation), which I presented to the MANET. Yes we need in MANET to >>> be focus on use-case, and how management is done. It is important that >>> MANET documents interact with Internet drafts. >>> >>> I included Mr.Cole presentation (Nov.2011) in my I-D draft about >>> MANET subnet technologies, and propose that any new I-D for management >>> should take it into consideration. >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> To: manet at ietf.org >> Subject: [manet] MANET management use cases >> From: Ulrich Herberg >> Date: Thu, 5 Jul 2012 17:43:12 -0700 >>>> Hi, >>>> >>>> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >>>> IESG evaluation to specify use cases how MANETs are monitored and >>>> managed using SNMP. After discussion with Benoit and Adrian, we agreed >>>> that such information would be useful, but that the MIB module (as >>>> pure APIs) would likely be the wrong place. Moreover, the use cases >>>> would not necessarily be specific to the NHDP-MIB, but concern all MIB >>>> modules. Benoit requested that we come up with a new informational >>>> draft in the WG, which discusses different MANET management use cases. >>>> >>>> Bob started working on collecting management and monitoring scenarios >>>> from the military experience. I believe that it would also be >>>> interesting to cover other use cases, such as in disaster recovery >>>> (e.g., monitoring and management of routers thrown out of an airplane >>>> over a disaster area) or in community networks (e.g., >>>> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >>>> can help to come up with a more abstract model of different management >>>> and monitoring approaches. It would be helpful if participants in this >>>> WG with MANET deployment and management/monitoring experience could >>>> contribute to such an effort. >>>> >>>> As a side note, there is a new mailing list about management of >>>> constrained networks and devices (coma at ietf.org), which may be of >>>> interest for some of the WG participants. >>>> >>>> Best regards >>>> Ulrich >>>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Fri Jul 13 04:23: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 DBAF121F8682 for ; Fri, 13 Jul 2012 04:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_65=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 S7EfeaBIqQW7 for ; Fri, 13 Jul 2012 04:23:15 -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 AAFC121F8673 for ; Fri, 13 Jul 2012 04:23:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2358227vbb.31 for ; Fri, 13 Jul 2012 04:23:50 -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=jacdqR/TjfHrU9innxEAS9Odc+w25YjrgncqH9oa3O4=; b=wLTOk/c0P8/Ts/BsPA7c2VBZ83W3K82O0THNpE2xWTWEbzeOG/J/Z+fre0ug4UrDhD hf5jKk4rEAu1xs4BtiWNhZXEpkd6zyzochiJ+ZUl39Tz01ZytuwvaOaGGnwaD34+vb1e m7iH88ewIv95HOju8dnZdtqxdUFZmpqAioc35eup7ynsRPYuH1ChkkjYN2QTBlbysilS kUx9Wyh604mex7aTDRJdk/64gdjOk4LQB6X9lpB35vDrbKoTk6emfxC98wZmWhyF7an3 i8at0Rg/lId94DIgu32O2CHvi0MYQu5xPOd0al92XaOMr8oHHT5+VPMg102zlyYhscgi ctlQ== MIME-Version: 1.0 Received: by 10.220.204.212 with SMTP id fn20mr369436vcb.43.1342178630311; Fri, 13 Jul 2012 04:23:50 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 04:23:50 -0700 (PDT) In-Reply-To: <71F98B5B-C225-467D-B90A-69DB96FAAD8C@herberg.name> References: <71F98B5B-C225-467D-B90A-69DB96FAAD8C@herberg.name> Date: Fri, 13 Jul 2012 13:23:50 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] NHDP-MIB: ifType (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 11:23:17 -0000 +1 Flexible is always good for a general neighbor discover technique as NHDP, AB ====================== On 7/13/12, Ulrich Herberg wrote: > I agree with Bob > > Ulrich > > On Jul 7, 2012, at 10:00, "Cole, Robert G CIV USARMY CERDEC (US)" > wrote: > >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> Our proposal is not mandating the use of NHDP. Instead it is flexible >> and >> allows whatever combination of MANET control protocols that makes sense. >> >> Thanks, Bob >> >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Abdussalam Baryun >> Sent: Friday, July 06, 2012 5:35 PM >> To: Ulrich Herberg >> Cc: manet >> Subject: Re: [manet] NHDP-MIB: ifType >> >> Hi Ulrich, >> >> You mention routing protocols already please read in your thread, >> >>> additional boolean flag which determines whether the interface uses > >> NHDP or not (i.e., if a router runs both DYMO and NHDP, the > DYMO-only >> >> Please note that DYMO will not use NHDP, only if using RFC5444. I just >> mentioned the DSRv2 I am doing, >> >> AB >> ============================================================ >> On 7/6/12, Ulrich Herberg wrote: >>> That is not what I said. I just recommended that this email thread is >>> about the ifType in the NHDP-MIB, not about DSRv2, and that such a >>> discussion (if >>> desired) should be in another email with different subject. >>> >>> Best >>> Ulrich >>> >>> On Fri, Jul 6, 2012 at 2:12 PM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> I am sorry I will never post in your threads, if you like that, >>>> >>>> AB >>>> >>>> On 7/6/12, Ulrich Herberg wrote: >>>>> Abdussalam, >>>>> >>>>> note that this has nothing to do with the protocol itself, but only >>>>> for >>>> the >>>>> MIB. So, unless you draft a MIB module, you will not need the ifType. >>>>> >>>>> If you want to discuss DSRv2 (which I doubt the WG should work on), >>>> please >>>>> open a new email thread, since this thread was only about the >>>>> NHDP-MIB draft. >>>>> >>>>> Best >>>>> Ulrich >>>>> >>>>> On Thu, Jul 5, 2012 at 10:34 PM, Abdussalam Baryun < >>>>> abdussalambaryun@gmail.com> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> I need the NHDP as a MANET interface for the DSRv2, which I >>>>>> suggested for DSRv2 before, so I like/agree that you consider the >>>>>> flag ifType, thanks very much, >>>>>> >>>>>> It is interesting if most manet routings use NHDP or even be >>>>>> possible to use in future, because I think it is a MANET interface >>>>>> as specified in OLSRv2. >>>>>> >>>>>> AB >>>>>> ++++++++ >>>>>>> Hi, >>>>>>> >>>>>>> we are currently working on a revised ID of the NHDP-MIB, as >>>>>>> follow-up on requests during the IESG review. Amongst others, >>>>>>> one request from Thomas Nadeau may affect other MIB documents as >>>>>>> well, which is why I post it on the mailing list. >>>>>>> >>>>>>> The current interface table in the NHDP-MIB is a copy of the >>>>>>> interface MIB, with potentially many entries that are not MANET >>>>>>> interfaces (but still waste space). What we are really >>>>>>> interested in is monitoring and managing NHDP interfaces. Thomas >>>>>>> Nadeau suggested to ask IANA to specify a ifType=MANET (as >>>>>>> allowed by RFC2863 and the IANAifType registry), and to list >>>>>>> only those in the NHDP-MIB. Bob and I propose that IANA >>>>>>> allocates such an ifType, which covers all MANET WG protocols, >>>>>>> i.e. ifType=MANET would be used for interfaces running NHDP, >>>>>>> OLSRv2, SMF, DYMO, etc. In the NhdpIfTable, there is an >>>>>>> additional boolean flag which determines whether the interface >>>>>>> uses NHDP or not (i.e., if a router runs both DYMO and NHDP, the >>>>>>> DYMO-only interfaces would be listed in the nhdpIfTable, but the >>>>>>> boolean flag is false). >>>>>>> >>>>>>> >>>>>>> Best regards >>>>>>> Ulrich >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> Classification: UNCLASSIFIED >> Caveats: NONE >> >> > From henning.rogge@fkie.fraunhofer.de Fri Jul 13 04:41: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 6C55D21F86C2 for ; Fri, 13 Jul 2012 04:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_56=0.6, 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 aips2DqNx7Ub for ; Fri, 13 Jul 2012 04:41:17 -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 45CD221F86B8 for ; Fri, 13 Jul 2012 04:41: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 1SpeFs-0001Ux-3r for manet@ietf.org; Fri, 13 Jul 2012 13:41: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 1SpeFs-0003Oq-1G for manet@ietf.org; Fri, 13 Jul 2012 13:41: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, 13 Jul 2012 13:41:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 13 Jul 2012 13:41:51 +0200 Message-ID: <5000097A.1060909@fkie.fraunhofer.de> Date: Fri, 13 Jul 2012 13:41:46 +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: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050105020204070000000609" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 13 Jul 2012 11:41:51.0898 (UTC) FILETIME=[7EC4AFA0:01CD60EC] X-Virus-Scanned: yes (ClamAV 0.97.3/15134/Fri Jul 13 04:53:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 3227f0690b92e74c5d151b48a7980dce Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 11:41:18 -0000 --------------ms050105020204070000000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 13.07.2012 11:36, schrieb Abdussalam Baryun: >> From: Henning Rogge >> I agree, >> >> packet signatures are a different kind of context. Instead of >> authenticating a message for the rest of the network, they deal with >> neighbor authentication. The packet signature will never be forwarded >> and might even work on a totally different key-scheme. > > Please note that NHDP's packets may be used in the control plane with > DLEP or it may be bridged between node neighbors (encapsulated in > frames instead of IP packets), so it does not always need forwarding. NHDP messages will notbe sent over the control plane of DLEP, because=20 DLEP keeps control traffic and data-traffic separated and the=20 control-plane will be definitely no MANET interface, so you wont use=20 NHDP on it. 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 --------------ms050105020204070000000609 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 Fw0xMjA3MTMxMTQxNDlaMCMGCSqGSIb3DQEJBDEWBBQmNRAPvPZnhIfPPmZoGGW2LB8sMjBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAs3yw/vpGujMHoICJQs/BfVZ5JS1ITvYqcG4j6km5mZ9IbBPevjvx0CYsCVuWI Oi39obDGvNEc9ZzstYpFFSU6LU4a00hJi6ubigNz3zf0yq5kjXRugtsrC6jotxOfwcuuDPvu 1zMWN9zA4kntmaNldRyMUC074uomOuGw+14JimnlNYxoXFSokkU/guwsGqqzvZX2UMYoOksL 7OEAGv1Pns+UNjBhz4ry7bzFWMpwVhORYQhmaZM2GHdBHbutH5AnaNZHttAHSYaX1AaGJ5qB DgECv3Z4HYKiaTLdQWYw4VihNF8MOgpylWP/U4PJIXJ2rOhtZuQlNkaglJ5+ZwXZAAAAAAAA --------------ms050105020204070000000609-- From henning.rogge@fkie.fraunhofer.de Fri Jul 13 04:43: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 7879021F8624 for ; Fri, 13 Jul 2012 04:43:36 -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.050, 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 bIjuL8yKGwSX for ; Fri, 13 Jul 2012 04:43:36 -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 9DF0421F8617 for ; Fri, 13 Jul 2012 04:43:35 -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 1SpeI7-0001Y8-6R for manet@ietf.org; Fri, 13 Jul 2012 13:44: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 1SpeI7-0003Pm-3p for manet@ietf.org; Fri, 13 Jul 2012 13:44: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); Fri, 13 Jul 2012 13:44:10 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 13 Jul 2012 13:44:10 +0200 Message-ID: <50000A09.7030101@fkie.fraunhofer.de> Date: Fri, 13 Jul 2012 13:44:09 +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: <8F7EED3D-F0BD-4059-9B0E-C6EB3B3B7E55@thomasclausen.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010208010003080601040902" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 13 Jul 2012 11:44:10.0977 (UTC) FILETIME=[D1AA7510:01CD60EC] X-Virus-Scanned: yes (ClamAV 0.97.3/15134/Fri Jul 13 04:53:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: cf4e294f566e9b0166dbdd65a574298f Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 11:43:36 -0000 --------------ms010208010003080601040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 13.07.2012 12:54, schrieb Abdussalam Baryun: >> Do you understand that, in RFC5444, a message _always_ is contained in= a >> _packet_? That a _packet_ serves as a mechanism for efficiency for >> containing multiple _messages_ in a single transmission? That a _messa= ge_ >> serves for relating information conveyed to a specific protocol and so= as a >> demultiplexing mechanism? > > Yes I do understand, that a RFC5444 packet MAY contain > RFC5444-messages (RFC5444 page 24), and that a RFC5444-message May be > encapsulated in RFC5444-packets ( RFC5444 section 5.2). we always need > to follow the requirement language in Standards documents. This is the key misconception. RFC5444 packets MAY contain RFC5444 messages. RFC5444 messages MUST be contained in RFC5444 packets. Otherwise, they would not be RFC5444 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 --------------ms010208010003080601040902 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 Fw0xMjA3MTMxMTQ0MDlaMCMGCSqGSIb3DQEJBDEWBBTjXU7J5OX2nhqvlaZM0TrDOJ02+jBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQCoODscUMgxxQPu9QYt9TnbhFU82Ec8VSB2lH3klvTTLPywLMqLFb53sMQZr4we SBhmP+7OwHIbeLMyknRy/1607unIGXL70KQsNH90clkEx5jpASV3pQmLKLEH8uHDJ8teH5Bz yVxhTrduiYDc1pcpQcu5MTCAkeK6Y4lS0lwCg6XgXFjdTYHPNQk5M9mnQKbjTsskxT6mvxfi 6EN1L1gbGKp7FdWuS016sD8UcOFr6WZCoJ3/WiP6wHGaEtLfU2bfDHH7478P4PG7HIO1Xvqf m+w4FjEAa8hrhPFiVTJn/QLvtjeJlSR+dRGSnErDFo3593/n5gNmI3jR2xN2DX3uAAAAAAAA --------------ms010208010003080601040902-- From robert.g.cole.civ@mail.mil Fri Jul 13 05:06: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 01C6A21F870E for ; Fri, 13 Jul 2012 05:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 6ZiQEvGZPL5w for ; Fri, 13 Jul 2012 05:06:18 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 84A3321F8704 for ; Fri, 13 Jul 2012 05:06:18 -0700 (PDT) Received: from UCOLHP3O.easf.csd.disa.mil (131.64.100.154) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Jul 2012 12:06:10 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.54]) by UCOLHP3O.easf.csd.disa.mil ([131.64.100.154]) with mapi id 14.02.0283.003; Fri, 13 Jul 2012 12:03:15 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Abdussalam Baryun , manet Thread-Topic: [manet] MANET management use cases (UNCLASSIFIED) Thread-Index: AQHNWzf5CQHv+ZFfWEOeFKt8jxVf+pcmCLaAgAEfDeA= Date: Fri, 13 Jul 2012 12:03:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CD60CD.FFBE5BC0" MIME-Version: 1.0 Subject: Re: [manet] MANET management use cases (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 12:06:20 -0000 ------=_NextPart_000_0000_01CD60CD.FFBE5BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE Abdussalam, In your reference, I was specifically referring to the development of a management model for a radio subnet, which would be instantiated in, e.g., a MIB module. However, I believe that we can have meaningful discussions about the use cases for management of MANET technologies, without such a model of a radio. Thanks, Bob -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: Thursday, July 12, 2012 2:53 PM To: manet Subject: Re: [manet] MANET management use cases >>Investigating examples can help to come up with a more abstract model of different management and monitoring approaches. Please note that the presenter of [Radio, SatCom, and considerations] in 82 meeting stated that it is not possible to define a manange model before defining layer 2 subnet model, which I agreed from before [1] and worked on the draft of MANET L2 subnets starting on 8 June [2]. [1] http://www.ietf.org/mail-archive/web/manet/current/msg12961.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13032.html AB ====== On 7/6/12, Abdussalam Baryun wrote: > Hi Ulrich, > > I thank you for this, I am happy that IESG have requested this. Mr. > Cole in the meeting 82 had introduced the problem (please check his > presentation), which I presented to the MANET. Yes we need in MANET to > be focus on use-case, and how management is done. It is important that > MANET documents interact with Internet drafts. > > I included Mr.Cole presentation (Nov.2011) in my I-D draft about > MANET subnet technologies, and propose that any new I-D for management > should take it into consideration. > > Abdussalam Baryun > University of Glamorgan, UK > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: manet at ietf.org Subject: [manet] MANET management use cases From: Ulrich Herberg Date: Thu, 5 Jul 2012 17:43:12 -0700 >> Hi, >> >> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >> IESG evaluation to specify use cases how MANETs are monitored and >> managed using SNMP. After discussion with Benoit and Adrian, we >> agreed that such information would be useful, but that the MIB module >> (as pure APIs) would likely be the wrong place. Moreover, the use >> cases would not necessarily be specific to the NHDP-MIB, but concern >> all MIB modules. Benoit requested that we come up with a new >> informational draft in the WG, which discusses different MANET management use cases. >> >> Bob started working on collecting management and monitoring scenarios >> from the military experience. I believe that it would also be >> interesting to cover other use cases, such as in disaster recovery >> (e.g., monitoring and management of routers thrown out of an airplane >> over a disaster area) or in community networks (e.g., >> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >> can help to come up with a more abstract model of different >> management and monitoring approaches. It would be helpful if >> participants in this WG with MANET deployment and >> management/monitoring experience could contribute to such an effort. >> >> As a side note, there is a new mailing list about management of >> constrained networks and devices (coma at ietf.org), which may be of >> interest for some of the WG participants. >> >> Best regards >> Ulrich >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0000_01CD60CD.FFBE5BC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS3DCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEwTCCA6mgAwIBAgIDDNszMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcN MTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKU7 jo5hPKcK6V92Cni9Bu445V7UQJBLIu1eX3brV/yB6uFNd+lIdV5n6RBpE1QcsIUEyS1GVDvTR/Qs kbUInPJC8ioZCX/V5Y2J8nRNidXoLX4SdeQ3Gc6jLPn+1W8KHRdATHy+SYGcrHnePyRAhTO73rN3 97CqgOaxnS4wo/Eanw9Re5UGq70cN/G7376Oxa7A2xdtY9w8gLUilFmcYXuwR7FGxcnDhsqAW3fv tgM18ZWn/hioEhmRZz514jXPnHCvSPAkofjb4Mjucnku8uNowu+PMw5Yqv9wimBEitvQGPnyac41 MNtsflnmVqWswTwhzVzIGdodKZTw2h6byTcCAwEAAaOCAWwwggFoMB8GA1UdIwQYMBaAFFSqcyrH s3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0 Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/BAQDAgUgMCMGA1UdIAQcMBowCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUyGOLOF3I71SMIzwNIujoox8W0CowbQYIKwYB BQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRpc2EubWlsL2dldHNpZ24/RE9EJTIw RU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwJAYDVR0RBB0w G4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVT MA0GCSqGSIb3DQEBBQUAA4IBAQAVD+rqDKxhGbV78baC+EUC3jiDUO6C41wsmB4ckt5akJPvVrB4 mjlnoG0lm19qovC98eO0vPQMUx1F6/jP9/xg32W2Ks2HZUR3ipZWBEqVi8i20Wz4sVFgXHkJjoP5 bju0XvJk/d6wze65iZqFuILuPplugaHg7iC5B/NAMELTGx8hoK3LVqmIIyMpEFlrxTygIkyuI+NK IqcbLtBOEW0bP7TNyBh/VShmtrXAtpPP0AAi+kaUURcG1x2xdPCR3cD2bjWYkfxQYeZRl2zTuOMg Mpr9pG3MuImao/C+v6IaXGuAU8xS8hSEbHGNLrXjJ9UIxw0K45WxjR7CrPFIJ4R5MIIFDDCCA/Sg AwIBAgIDDNswMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjQwHhcNMTAwMjI1MDAwMDAwWhcNMTMwMjI0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UE CxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJPQkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOsVn1k8Ax7kkzWXvrNf7oI7iy5zEeLACdGKrODL9riDBNUF HvD4JtafUcwq03s4Daq0tscNL8J1ONDeML5s0X8UeNfCyexrkSpPwY9g/zVO6mJmG4OunTz/7fc2 G0ZR64VYlEBZeQ88JIMIs6bYXiO9SxuOCS47aGx/CGqdpFwt713bBAQvzAjLUSWBvjZN2bviTQrY wAg1/1AnlxY6Zl4YPBSV9c1TbtTQNjbRyFRabiqNMh0XaQ0ZHxQgsGOqNwfyMlmadL2m3ILhKpFh oMfOV01at2eDj8+wFvDXLXAL1f3HAQKv5W5GEoBYNDqp/ULDBJcXVPT8mYWzxMkca/MCAwEAAaOC AbcwggGzMB8GA1UdIwQYMBaAFFSqcyrHs3fqzSJAeUh7EfunmSKCMD8GA1UdHwQ4MDYwNKAyoDCG Lmh0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjQwDgYDVR0PAQH/ BAQDAgbAMCMGA1UdIAQcMBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUBeVx RkqbKuf17SKV2ZZOsCXLQ+gwbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3Js LmRpc2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yNDAgBggrBgEFBQcwAYYUaHR0cDov L29jc3AuZGlzYS5taWwwRAYDVR0RBD0wO4EZcm9iZXJ0LmcuY29sZUB1cy5hcm15Lm1pbKAeBgor BgEEAYI3FAIDoBAMDjEzNjY1NjAzOTBAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMw KQYDVR0lBCIwIAYKKwYBBAGCNxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUA A4IBAQBhwXMphuaV+lhIZbI35yGpZ7zy/uXNyr41+/dibahnAIisIIHFSTeEk9GFepxqV45hagTo //0UycQ/ShOIHzV/+u3l/97k+l8imMdbjhgklb2UFROSz7TJzhO3w4S7g7DpU+GTxE2Uax+iD2t0 Bmio3ut9fr/dWvi6OTYVFMTW7M6pd8gOPqmg8ADGdljGsSotMAhXzFJgAPtnsca5HfyYpGi0NQj0 ucT/sWUGwnnjlqtYyP+SY2pOPpbN9gACkv8UKJMkik5GEFobaHbI8KWr4FFOXAIAauW1DvGFq5Pe WdDgj39r6PkdOLg3v+B9/hnkP6uOyH5Oi9pcHb+d/hPuMIIFjzCCBHegAwIBAgIBRTANBgkqhkiG 9w0BAQUFADBbMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNRG9EIFJvb3QgQ0EgMjAeFw0wOTAxMjYyMDI2 MTVaFw0xNTAxMjUyMDI2MTVaMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClLlh6od7mmlv2AvHV1Nw1I5p7bihkdBpw PJYdzMKfdAQ8DDmSIQgNEk6g1zeo0snGJ50o+lXXshcEGc4yvPB5nvVoqy7MzzcEsvgKZZpJIBQl wbwSaqBCbRsItIehQiKrE5naAgE5H14IV2tg3hN+aGp+QfWJgDh6/Zey0uKWSzaAYrbsJbvQD6ej zVGo99J5VZA0JqPkXM27aCZ0CTeh5q/N5D6ZR/9/wke8ZYS6MimjDvDColt66rJKfQvGw26svRB/ T6l2Oj0CASwqMLT3yKDSmDp8CNBaiQ+1ioL6DTAeftbRx7ZDJ7EoqQzjswd432JkmkWMTs2vDq6c WDbfAgMBAAGjggJaMIICVjAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAUSXS7DF66ev4CVO97 oMaVxgmAcJYwHQYDVR0OBBYEFFSqcyrHs3fqzSJAeUh7EfunmSKCMAwGA1UdJAQFMAOAAQAwEgYD VR0TAQH/BAgwBgEB/wIBADCBnwYDVR0gBIGXMIGUMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkw CwYJYIZIAWUCAQsKMAsGCWCGSAFlAgELEjALBglghkgBZQIBCxMwCwYJYIZIAWUCAQsUMAwGCmCG SAFlAwIBAwYwDAYKYIZIAWUDAgEDBzAMBgpghkgBZQMCAQMIMAwGCmCGSAFlAwIBAw0wDAYKYIZI AWUDAgEDETA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9Eb0Ql MjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/BggrBgEFBQcwAoYzaHR0cDovL2Ny bC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0ElMjAyMCAGCCsGAQUFBzABhhRo dHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6Ly9jcmwuZ2RzLmRpc2EubWls L2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5T LiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwDQYJKoZIhvcNAQEF BQADggEBAHIW3DlzY02T6Tccz7LtnNhN9wwySomes8q68wSscWYxpiq9un1U2C8JY0qICOhsE6Hs XntWFzAtyNLt141HRGnPEW/L2OdSdbVRyKodafAZHzDwB8c2vc4M3jt2/QrOy7YTutaFi/FcEpHK r+h/EqisLYvWdlCU7Db6ow/fxjLqx3NG/IQami/E6CccSMJGNvYX7O1nMg+4ouC30l6QBhOUIWFD bH3zO2tl7ePbqP/Fm7KS5+tf7u+/8zmMs/UX0obVw2xKOmw/nq/oWx02W6YmFUYLRmvH1ICq564c uCtO+iFyn1+fga+07lvJlymJfOnceOJO4HSf0oZ4ZqLHmKgxggL+MIIC+gIBATBkMF0xCzAJBgNV BAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMD UEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAwzbMDAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MTMxMjAzMzNaMCMGCSqGSIb3 DQEJBDEWBBSTstC3wNylsQbbk3g6KGu3EdJXejAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMH MAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFmMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0yNAIDDNszMHUGCyqGSIb3DQEJEAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9E IEVNQUlMIENBLTI0AgMM2zMwDQYJKoZIhvcNAQEBBQAEggEAevcfzGbCzbfhmNrrlA8KHBTVDzEO ++Lk9drjT3te35Ho9DNNtUAowB2zfMQ1lzjvJFX9D7QwsamPHSEerL0VHC+i8CQ29ZdFgBq55HMa WoQqDoxkfGx0m+do6UTxUhPUVeot9kKtsVnTLWc7M7kQpoKUFkmbMrCHPd6OYmWQP9MkA8p0nprK +yrAqdMzHJLoJn31UKORrFBPfSHl9kCRoS46cQxaOajhp8htwxhvUVHjAHYvVXve0HVlGAPqDsk9 FOy7LLAPEbbUvpfr/aqVYQ6UBCX/9C+BrZNDK+YnLbXNK/RRnfz5hlsuDSTxHG/5HfbU5cFCPExq O0U70tjomAAAAAAAAA== ------=_NextPart_000_0000_01CD60CD.FFBE5BC0-- From Chris.Dearlove@baesystems.com Fri Jul 13 05:18: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 BFC4121F8528 for ; Fri, 13 Jul 2012 05:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.158 X-Spam-Level: X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.440, 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 ydBQQJyUrKLh for ; Fri, 13 Jul 2012 05:18:25 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5D80A21F8525 for ; Fri, 13 Jul 2012 05:18:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,579,1336345200"; d="scan'208,217";a="255697761" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 13 Jul 2012 13:18:59 +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 q6DCIwlI000478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 13:18:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.251]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Fri, 13 Jul 2012 13:18:58 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: AQHNYG5lMWs8L8nJvUmskMYRmizNvpcmD5KAgAAUo4CAAPwpAA== Date: Fri, 13 Jul 2012 12:18:57 +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_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97035GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:18:27 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97035GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb24ndCBhZ3JlZS4gTm90ZSB0aGF0IGlmIGFsbCB5b3UgYXJlIHJ1bm5pbmcgaXMgTkhEUCwg dGhlbiBzaWduaW5nIHBhY2tldHMgaXMgbW9yZSBzZWN1cmUgdGhhbiBzaWduaW5nIG1lc3NhZ2Vz LCBhcyB5b3UgZ2V0IHRvIGNvdmVyIHRoZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIGFzIHdlbGwu DQpXaGF0IEkgdGhpbmsgaXMgd3JvbmcgaXMgdG8gc3VnZ2VzdCB0aGF0IHRoZSBvbmx5IGNvcnJl Y3Qgd2F5IHRvIHByb3RlY3QgTkhEUCBpcyB0byBzaWduIEhFTExPIG1lc3NhZ2VzLiBXaGV0aGVy IGJ5IGluY2x1c2lvbiBvciBleHRlcm5hbCByZWZlcmVuY2UsIHNpZ25pbmcgcGFja2V0cyBzaG91 bGQgYmUgYWxzbyBhbiBvcHRpb24uDQoNCkknbGwgdGFrZSB0aGF0IGZ1cnRoZXIgdG8gT0xTcnYy IGFzIHdlbGwuIE5vdyB0aGVyZSBzaWduaW5nIG1lc3NhZ2VzIHZzIHNpZ25pbmcgcGFja2V0cyBo YXMgYWR2YW50YWdlcyB0byB0aGUgZm9ybWVyLiBCdXQgc2lnbmluZyBwYWNrZXRzIGFsc28gaGFz IGFkdmFudGFnZXMgb2Ygc2ltcGxpY2l0eSBhbmQgY292ZXJpbmcgcGFja2V0IGhlYWRlci4gSXQg aXMgaW5jaWRlbnRhbGx5IG5vdCBjb3JyZWN0IHRvIHNheSB0aGF0IHNpZ25pbmcgVEMgbWVzc2Fn ZXMgcHJvdmlkZXMgZW5kIHRvIGVuZCBzZWN1cml0eS4gSXQncyBhY3R1YWxseSBsYXN0LWJpdC1v bmUtZnJvbS1lbmQgdG8gZW5kLCBhbmQgc3RpbGwgcmVsaWVzIG9uIGEgZm9ybSBvZiB0cmFuc2l0 aXZlIHRydXN0LiBQYWNrZXQgYmFzZWQgc2lnbmF0dXJlcyByZWx5IG9uIGEgZ3JlYXRlciBkZWdy ZWUgb2YgdHJhbnNpdGl2ZSB0cnVzdC4gVGhlcmUgaXMgYSBkaWZmZXJlbmNlIGluIHRocmVhdCBt b2RlbHMgYW5kIHZ1bG5lcmFiaWxpdGllcywgYW5kIHRoYXQgbWF5IG1hdHRlciwgYnV0IGl0J3Mg bm90ICh1bmZvcnR1bmF0ZWx5KSBhcyBzaW1wbGUgYXMgb25lIGJlaW5nIGVuZCB0byBlbmQgYW5k IHRodXMgYXZvaWRpbmcgdHJhbnNpdGl2aXR5IGlzc3Vlcy4NCg0KLS0NCkNocmlzdG9waGVyIERl YXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBDb21tdW5pY2F0aW9ucyBHcm91cA0K Q29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpC QUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQg Um9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0 NSAyNDIxOTQgfCAgRmF4OiArNDQgMTI0NSAyNDIxMjQNCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4gfCBodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdp c3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3VzZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJv c3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5OTY2ODcNCg0KRnJvbTogVGhvbWFzIEhlaWRlIENs YXVzZW4gW21haWx0bzp0aG9tYXNAdGhvbWFzY2xhdXNlbi5vcmddDQpTZW50OiAxMiBKdWx5IDIw MTIgMjM6MDkNClRvOiBVbHJpY2ggSGVyYmVyZw0KQ2M6IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAo VUspOyBtYW5ldA0KU3ViamVjdDogUmU6IFttYW5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1t YW5ldC1uaGRwLXNlYy0wMi50eHQNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCktlZXAgdGhpcyBpbiBtaW5kIGlmIHlv dSBhbnN3ZXIgdGhpcyBtZXNzYWdlLg0KUGxlYXNlIHNlZSB0aGlzIHByb2Nlc3M8aHR0cDovL2lu dHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9E b2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4gb24gaG93 IHRvIGRlYWwgd2l0aCBzdXNwaWNpb3VzIGVtYWlscy4NCkkgYWdyZWUgd2l0aCBVbHJpY2guDQoN Ck5vdGUgdGhhdCB0aGlzIGlzIGFsbCBhYm91dCAibWVzc2FnZXMiIGluIGFzIG11Y2ggYXMgTkhE UCBpcyBjb25jZXJuZWQuDQoNCjEpIE5IRFAgc3BlY2lmaWVzIHNvbWV0aGluZyBha2luIHRvICJh biBpbXBsZW1lbnRhdGlvbiBtYXkgcmVjb2duaXplIGFkZGl0aW9uYWwgcmVhc29ucyBmb3IgY29u c2lkZXJpbmcgYSBIRUxMTyBtZXNzYWdlIGludmFsaWQgZm9yIHByb2Nlc3NpbmciOyB0aGlzIEkt RCBzcGVjaWZpZXMgc3VjaCBhbiBhZGRpdGlvbmFsIHJlYXNvbiwgYnkgd2F5IG9mIGEgVExWIGlu IEhFTExPIG1lc3NhZ2VzLg0KDQoyKSBOSERQICJvd25zIiBIRUxMTyBtZXNzYWdlcywgYW5kIHRo ZXJlZm9yZSBnZXRzIGZpcnN0IGRpcCBvbiBhbiBpbmNvbWluZyBIRUxMTyBtZXNzYWdlIHBvc3Qt ZGVtdWx0aXBsaWNhdGlvbi4gSW5jbHVkaW5nIHRoZSBJQ1YgTWVzc2FnZSBUTFYgaW4gSEVMTE8g bWVzc2FnZXMgdGhlcmVmb3JlIG1ha2VzIHNlbnNlLg0KDQpBZCAxKSwgSSBub3RlIHRoYXQgdGhp cyBJLUQgaXMgaW50ZW5kZWQgdG8gZXhhY3RseSBwbHVnIGluIGF0IHRoYXQgcGxhY2UgaW4gNjEz MC4NCg0KVGhvbWFzDQoNCi0tDQpUaG9tYXMgSGVpZGUgQ2xhdXNlbg0KaHR0cDovL3d3dy50aG9t YXNjbGF1c2VuLm9yZy8NCg0KDQoiQW55IHNpbXBsZSBwcm9ibGVtIGNhbiBiZSBtYWRlIGluc29s dWJsZSBpZiBlbm91Z2ggbWVldGluZ3MgYXJlIGhlbGQgdG8NCiBkaXNjdXNzIGl0LiINCiAgIC0t IE1pdGNoZWxsJ3MgTGF3IG9mIENvbW1pdHRlZXMNCg0KDQpPbiAxMiBKdWwgMjAxMiwgYXQgMjI6 NTQsIFVscmljaCBIZXJiZXJnIDx1bHJpY2hAaGVyYmVyZy5uYW1lPG1haWx0bzp1bHJpY2hAaGVy YmVyZy5uYW1lPj4gd3JvdGU6DQpUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIHNpZ25pbmcvdmVyaWZ5 aW5nIE5IRFAgbWVzc2FnZXMuIFJGQzU0NDQgcGFja2V0cyBhcmUgbm90IHNwZWNpZmljIHRvIE5I RFAsIGFuZCB0aGVyZWZvcmUgc2hvdWxkIElNTyBub3QgYmUgZGlzY3Vzc2VkIGluIGEgZG9jdW1l bnQgZW50aXRsZWQgIlVzaW5nIEludGVncml0eSBDaGVjayBWYWx1ZXMgYW5kIFRpbWVzdGFtcHMg Rm9yIFJvdXRlciBBZG1pdHRhbmNlIGluIE5IRFAiLiBUaGF0J3Mgd2h5IEkgc3VnZ2VzdGVkIHRv IGhhbmRsZSB0aGlzIGluIGFuIGFkZGl0aW9uYWwgZG9jdW1lbnQgZm9yIFJGQzU0NDQgcGFja2V0 cy4NCg0KUmVnYXJkcw0KVWxyaWNoDQpPbiBUaHUsIEp1bCAxMiwgMjAxMiBhdCAxOjM5IFBNLCBB YmR1c3NhbGFtIEJhcnl1biA8YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb208bWFpbHRvOmFiZHVz c2FsYW1iYXJ5dW5AZ21haWwuY29tPj4gd3JvdGU6DQpIaSBVbHJpY2gsDQoNCkkgYW0gbm90IGV4 cGVydCBpbiBzZWN1cml0eSBpc3N1ZXMsIGJ1dCBJTUhPLCBJIGFncmVlIHdpdGggQ2hyaXMgdG8N CnJlY29tbWVuZCB0byBpbmNsdWRlIGluIGRyYWZ0LTAyIGJvdGggc2VjdXJpbmcgbWVzc2FnZXMg YW5kIHBhY2tldHMNCihpbiBnZW5lcmFsIGZvciBwYWNrZXRzKSwgc28gdGhlIGRvY3VtZW50IHNo b3VsZCBzcGVjaWZ5IE5IRFAgbWVzc2FnZXMNCmFuZCBNQU5FVCBwYWNrZXRzIFtBQl0uIFRoZSBy ZWFzb25zIGFyZSBmaXJzdCwgYmVjYXVzZSBOSERQIGlzIGEgTUFORVQNCkludGVyZmFjZSBwcm90 b2NvbCBiZXR3ZWVuIG5laWdoYm9yIHJvdXRlcnMuIHNlY29uZGx5IGl0IHVzZXMgUkZDNTQ0NA0K Zm9ybWF0IHRoYXQgdGhlIGZ1dHVyZSBNQU5FVCByb3V0ZXJzIHdpbGwgdXNlLiBUaGlyZCwgTkhE UCB1c2VzDQpSRkM1NDQ0IHdoaWNoIHdhcyBzcGVjaWZpZWQgZm9yIGluZm9ybWF0aW9uIGV4Y2hh bmdlIGJldHdlZW4gTUFORVQNCnJvdXRlcnMuDQoNCltBQl0gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWJhcnl1bi1tYW5ldC10ZXJtaW5vbG9neS0wMC50eHQNCg0KUmVnYXJkcw0KQWJk dXNzYWxhbQ0KPT09PT09PQ0KDQpPbiBUaHUsIEp1bCAxMiwgMjAxMiBhdCA5OjA4IFBNLCBVbHJp Y2ggSGVyYmVyZyA8dWxyaWNoIGF0IGhlcmJlcmcubmFtZTxodHRwOi8vaGVyYmVyZy5uYW1lPj4g d3JvdGU6DQo+IERlYXIgQ2hyaXMsDQo+DQo+IEkgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIHByb3Zp ZGUgc2ltaWxhciBtZWNoYW5pc21zIGFzIGluIE5IRFAtc2VjIGZvciBUQw0KPiBtZXNzYWdlcyBh cyB3ZWxsLiBJIGRvbid0IHRoaW5rIHRoYXQgc2lnbmluZyB0aGUgcGFja2V0IGlzIGVub3VnaCwg c2luY2UNCj4gdGhhdCBkb2VzIG5vdCBwcm92aWRlIGVuZC10by1lbmQgc2VjdXJpdHkuIEluc3Rl YWQsIEkgc3VnZ2VzdCB0byBzdWJtaXQgYQ0KPiBkcmFmdCBPTFNSdjItc2VjIHRoYXQgc3BlY2lm aWVzIGhvdyB0byBjYWxjdWxhdGUgSUNWcyBmb3IgVEMgbWVzc2FnZXMsIGFuZA0KPiBob3cgdG8g aGFuZGxlIHRoZXNlIG1lc3NhZ2VzIGluIE9MU1J2Mi4NCj4NCj4gSG93ZXZlciwgSSBiZWxpZXZl IHRoYXQgaXQgd291bGQgYmUgYmVuZWZpY2lhbCBmb3IgY2VydGFpbiBhcHBsaWNhdGlvbnMgdG8N Cj4gYWxzbyBiZSBhYmxlIHRvIHNpZ24vdmVyaWZ5IHBhY2tldHMuIEJ1dCBJIGRvbid0IHRoaW5r IHRoYXQgdGhlIE5IRFAtc2VjDQo+IGRvY3VtZW50IGlzIHRoZSByaWdodCBwbGFjZSBmb3IgdGhp cywgc2luY2Ugb3RoZXIgYXBwbGljYXRpb25zIChlLmcuIERZTU8pDQo+IG1heSBub3QgdXNlIEhF TExPIG1lc3NhZ2VzIGF0IGFsbCwgYnV0IHdvdWxkIHN0aWxsIGxpa2UgdG8gc2lnbi92ZXJpZnkN Cj4gcGFja2V0cy4NCj4gTWF5YmUgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgYW4gZXh0cmEg ZG9jdW1lbnQgInBhY2tldC1zZWMiIHdoaWNoDQo+IHNwZWNpZmllcyBob3cgdG8gc2lnbi92ZXJp ZnkgcGFja2V0cz8NCj4NCj4gQmVzdA0KPiBVbHJpY2gNCj4NCj4NCj4gT24gV2VkLCBNYXkgMzAs IDIwMTIgYXQgNjoyMSBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCj4gPENocmlzLkRl YXJsb3ZlIGF0IGJhZXN5c3RlbXMuY29tPGh0dHA6Ly9iYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0K Pj4NCj4+IChTZW5kaW5nIGFnYWluLCB0byBzb3J0IG91dCB0aGUgZm9ybWF0dGluZyBwcm9ibGVt IHdpdGggdGhlIGxhc3QgYXR0ZW1wdC4pDQo+Pg0KPj4gQXMgSSByZWFkIGl0LCB0aGlzIGRyYWZ0 IGlzIHByb3Bvc2luZyB1c2luZyB0aGUgUkZDIDY2MjIgbWVjaGFuaXNtIHRvIHNpZ24NCj4+IEhF TExPIG1lc3NhZ2VzLiBSRkMgNjYyMiBhY3R1YWxseSBhbGxvd3MgZm9yIHNpZ25pbmcgcGFja2V0 cyBhcyB3ZWxsIGFzDQo+PiBzaWduaW5nIG1lc3NhZ2VzIChib3RoLCBlaXRoZXIsIG9yIG5laXRo ZXIgdG8gYmUgdXNlZCBhcyByZXF1aXJlZCkuIFRoZXJlDQo+PiBpc24ndCBhIG1ham9yIGRpZmZl cmVuY2Ugd2hlbiBjb25zaWRlcmluZyBIRUxMTyBtZXNzYWdlcywgYXMgZmV3IGlmIGFueQ0KPj4g cGFja2V0cyB3aWxsIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSBIRUxMTyBtZXNzYWdlLCBhbmQgdGhl IHBhY2tldCBhbmQgdGhlDQo+PiBtZXNzYWdlIHdpbGwgYmUgc2lnbmVkIGJ5IHRoZSBzYW1lIHBh cnR5Lg0KPj4NCj4+IEhvd2V2ZXIgTkhEUCBkb2Vzbid0IGV4aXN0IGluIGEgdmFjdXVtLCBpbiBw YXJ0aWN1bGFyIGl0IGlzIHVzZWQgYnkNCj4+IE9MU1J2Mi4gQW55IHNlY3VyaXR5IG1lY2hhbmlz bSB0aGF0IGlzIGRlc2NyaWJlZCBpbiB3aGF0IHdpbGwgYmUgYW4gUkZDIGZvcg0KPj4gTkhEUCBt dXN0IGFsc28gYmUgd2hhdCdzIHJpZ2h0IGZvciBOSERQIGFzIHVzZWQgYnkgT0xTUnYyLiBPTFNS djIgYWxzbyBoYXMNCj4+IFRDIG1lc3NhZ2VzIHRvIGNvbnNpZGVyLCBhbmQgdGhleSBkb24ndCBz YXRpc2Z5IHRoZSBwb2ludHMgbm90ZWQgYWJvdmUgKG9uDQo+PiBudW1iZXIgb3Igb24gd2hvIHNp Z25zIHRoZW0pLiBBbmQgb25lIG9wdGlvbiBmb3IgT0xTUnYyIGlzIHRvIHNpZ24gYWxsDQo+PiBw YWNrZXRzLCBub3QgbWVzc2FnZXMuIFRoaXMgY2FuIGJlIGEgc2Vuc2libGUgZGVjaXNpb24gdGhl cmUsIGZvciBzZXZlcmFsDQo+PiByZWFzb25zLCBpbiBzb21lIHJlYWwgY2lyY3Vtc3RhbmNlcy4N Cj4+DQo+PiBDb25zZXF1ZW50bHksIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgc2hv dWxkIGRlc2NyaWJlIG9ubHkgc2lnbmluZw0KPj4gSEVMTE8gbWVzc2FnZXMgYXMgdGhlIGNvcnJl Y3QgdGhpbmcgdG8gZG8sIHRoYXQgaXQgc2hvdWxkIGFsc28gYWxsb3cgc2lnbmluZw0KPj4gcGFj a2V0cyBhcyBhbiBlcXVhbCBzdGF0dXMgb3B0aW9uLiBJZiBzb21lb25lIHdhbnRzIHRvIHJhaXNl IHRoZSBwb3NzaWJpbGl0eQ0KPj4gb2Ygc2lnbmluZyAocG9zc2libHkgYnkgbWV0aG9kcyB3aXRo IGRpZmZlcmVudCBwcm9wZXJ0aWVzKSBib3RoIGF0IHRoZQ0KPj4gbWVzc2FnZSBhbmQgcGFja2V0 IGxldmVsLCB0aGF0IG1heSBoYXZlIGl0cyB1c2UgY2FzZXMgdG9vLg0KPj4NCj4+IEluY2lkZW50 YWxseSwgZXZlbiB3aXRoaW4gdGhlIGxpbWl0ZWQgZnJhbWV3b3JrIG9mIGp1c3QgTkhEUCwgaXQg aXMNCj4+IHBvc3NpYmxlIHRoYXQgcGFja2V0cyBuZWVkIHByb3RlY3Rpb24uIElmIGFuIE5IRFAg aW1wbGVtZW50YXRpb24gY2hvb3NlcyB0bw0KPj4gdXNlIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIg YXMgcGFydCBvZiBpdHMgbGluayBxdWFsaXR5IG1lY2hhbmlzbSwgYXMgaXQgbWF5LA0KPj4gdGhl biBhbiB1bnByb3RlY3RlZCBwYWNrZXQgaGVhZGVyIGlzIGEgdnVsbmVyYWJpbGl0eS4NCj4+DQo+ PiAoRm9yIHRoZSBzYWtlIG9mIGNvbXBsZXRlbmVzcywgUkZDIDY2MjIgYWxzbyBhbGxvd3MgYWRk cmVzcyBibG9jaw0KPj4gc2lnbmF0dXJlcy4gSSBkb24ndCBoYXZlIGEgcmVhc29uIHRvIHN1Z2dl c3QgdXNpbmcgdGhpcyB3aXRoaW4gTkhEUCBvcg0KPj4gT0xTUnYyLikNCj4+DQo+PiAtLQ0KPj4g Q2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4+IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIENvbW11 bmljYXRpb25zIEdyb3VwDQo+PiBDb21tdW5pY2F0aW9ucywgTmV0d29ya3MgYW5kIEltYWdlIEFu YWx5c2lzIENhcGFiaWxpdHkNCj4+IEJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2Vu dHJlDQo+PiBXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IENNMiA4SE4sIFVLDQo+PiBUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0NCAxMjQ1IDI0 MjEyNA0KPj4gY2hyaXMuZGVhcmxvdmUgYXQgYmFlc3lzdGVtcy5jb208aHR0cDovL2JhZXN5c3Rl bXMuY29tPiB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCj4+DQo+PiBCQUUgU3lzdGVtcyAo T3BlcmF0aW9ucykgTGltaXRlZA0KPj4gUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sgSG91c2Us IFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwNCj4+IEZhcm5ib3JvdWdo LCBIYW50cywgR1UxNCA2WVUsIFVLDQo+PiBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBO bzogMTk5NjY4Nw0KPj4NCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+IGRpcmVjdG9yaWVzLiBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcN Cj4+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDog VXNpbmcgSW50ZWdyaXR5IENoZWNrIFZhbHVlcyBhbmQgVGltZXN0YW1wcyBGb3INCj4+IFJvdXRl ciBBZG1pdHRhbmNlIGluIE5IRFANCj4+ICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogVWxyaWNo IEhlcmJlcmcNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhvbWFzIEhlaWRlIENsYXVz ZW4NCj4+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLXNl Yy0wMi50eHQNCj4+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTINCj4+ICAgICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAxMi0wNS0yOQ0KPj4NCj4+ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGEgc2VjdXJpdHkgZXh0ZW5zaW9uIHRvIHRoZSBNQU5FVA0KPj4gICAgTmVpZ2hib3Job29k IERpc2NvdmVyeSBQcm90b2NvbCAoTkhEUCkuICBUaGUgZXh0ZW5zaW9uIGludHJvZHVjZXMgdGhl DQo+PiAgICB1c2Ugb2YgSW50ZWdyaXR5IENoZWNrIFZhbHVlcyAoSUNWcykgYW5kIFRpbWVzdGFt cHMgaW4gSEVMTE8gbWVzc2FnZXMNCj4+ICAgIGluIG9yZGVyIHRvIHByb3ZpZGUgYSByb3V0ZXIg YWRtaXR0YW5jZSBtZWNoYW5pc20sIGFuZCB0aGVyZWZvcmUgdG8NCj4+ICAgIGNvdW50ZXIgYSBz ZWxlY3Rpb24gb2Ygc2VjdXJpdHkgdGhyZWF0cyB0byBOSERQLg0KPj4NCj4+DQo+PiBBIFVSTCBm b3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0DQo+Pg0KPj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+DQo+PiBUaGlzIEludGVybmV0LURy YWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0DQo+Pg0KPj4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMvDQo+Pg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1h bmV0IG1haWxpbmcgbGlzdA0KPj4gbWFuZXQgYXQgaWV0Zi5vcmc8aHR0cDovL2lldGYub3JnPg0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4NCj4+DQo+ PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQo+PiByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4gcmVjaXBpZW50IHBsZWFz ZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+PiBZ b3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Ns b3NlIG9yDQo+PiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0K Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCj4+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0 bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97035GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbid0 IGFncmVlLiBOb3RlIHRoYXQgaWYgYWxsIHlvdSBhcmUgcnVubmluZyBpcyBOSERQLCB0aGVuIHNp Z25pbmcgcGFja2V0cyBpcyBtb3JlIHNlY3VyZSB0aGFuIHNpZ25pbmcgbWVzc2FnZXMsIGFzIHlv dSBnZXQgdG8gY292ZXIgdGhlIHBhY2tldCBzZXF1ZW5jZQ0KIG51bWJlciBhcyB3ZWxsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IEkgdGhpbmsgaXMgd3JvbmcgaXMgdG8gc3Vn Z2VzdCB0aGF0IHRoZSBvbmx5IGNvcnJlY3Qgd2F5IHRvIHByb3RlY3QgTkhEUCBpcyB0byBzaWdu IEhFTExPIG1lc3NhZ2VzLiBXaGV0aGVyIGJ5IGluY2x1c2lvbiBvciBleHRlcm5hbCByZWZlcmVu Y2UsIHNpZ25pbmcNCiBwYWNrZXRzIHNob3VsZCBiZSBhbHNvIGFuIG9wdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkknbGwgdGFrZSB0aGF0IGZ1cnRoZXIgdG8gT0xTcnYyIGFzIHdlbGwuIE5vdyB0aGVyZSBzaWdu aW5nIG1lc3NhZ2VzIHZzIHNpZ25pbmcgcGFja2V0cyBoYXMgYWR2YW50YWdlcyB0byB0aGUgZm9y bWVyLiBCdXQgc2lnbmluZyBwYWNrZXRzIGFsc28gaGFzIGFkdmFudGFnZXMNCiBvZiBzaW1wbGlj aXR5IGFuZCBjb3ZlcmluZyBwYWNrZXQgaGVhZGVyLiBJdCBpcyBpbmNpZGVudGFsbHkgbm90IGNv cnJlY3QgdG8gc2F5IHRoYXQgc2lnbmluZyBUQyBtZXNzYWdlcyBwcm92aWRlcyBlbmQgdG8gZW5k IHNlY3VyaXR5LiBJdCdzIGFjdHVhbGx5IGxhc3QtYml0LW9uZS1mcm9tLWVuZCB0byBlbmQsIGFu ZCBzdGlsbCByZWxpZXMgb24gYSBmb3JtIG9mIHRyYW5zaXRpdmUgdHJ1c3QuIFBhY2tldCBiYXNl ZCBzaWduYXR1cmVzIHJlbHkNCiBvbiBhIGdyZWF0ZXIgZGVncmVlIG9mIHRyYW5zaXRpdmUgdHJ1 c3QuIFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBpbiB0aHJlYXQgbW9kZWxzIGFuZCB2dWxuZXJhYmls aXRpZXMsIGFuZCB0aGF0IG1heSBtYXR0ZXIsIGJ1dCBpdCdzIG5vdCAodW5mb3J0dW5hdGVseSkg YXMgc2ltcGxlIGFzIG9uZSBiZWluZyBlbmQgdG8gZW5kIGFuZCB0aHVzIGF2b2lkaW5nIHRyYW5z aXRpdml0eSBpc3N1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RvcGhlciBEZWFybG92ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBD b21tdW5pY2F0aW9ucyBHcm91cDxicj4NCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1h Z2UgQW5hbHlzaXMgQ2FwYWJpbGl0eTxicj4NCkJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xv Z3kgQ2VudHJlPGJyPg0KV2VzdCBIYW5uaW5nZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVs bXNmb3JkLCBDTTIgOEhOLCBVSzxicj4NClRlbDogJiM0Mzs0NCAxMjQ1IDI0MjE5NCZuYnNwO3wm bmJzcDsgRmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9zcGFuPjwvYT4NCiB8 IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb208YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkJBRSBTeXN0ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6 IFdhcndpY2sgSG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwg RmFybmJvcm91Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUs8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xh bmQgJmFtcDsgV2FsZXMgTm86IDE5OTY2ODc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGhvbWFzIEhlaWRlIENsYXVzZW4gW21haWx0bzp0aG9t YXNAdGhvbWFzY2xhdXNlbi5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTIgSnVseSAyMDEyIDIz OjA5PGJyPg0KPGI+VG86PC9iPiBVbHJpY2ggSGVyYmVyZzxicj4NCjxiPkNjOjwvYj4gRGVhcmxv dmUsIENocmlzdG9waGVyIChVSyk7IG1hbmV0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFu ZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3Bh ZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2VlcCB0 aGlzIGluIG1pbmQgaWYgeW91IGFuc3dlciB0aGlzIG1lc3NhZ2UuPC9zcGFuPjwvZW0+PGJyPg0K PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5QbGVhc2Ugc2VlIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxp bmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPiBv biBob3cgdG8gZGVhbCB3aXRoIHN1c3BpY2lvdXMgZW1haWxzLjwvc3Bhbj48L2VtPjwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YWdyZWUgd2l0aCBVbHJpY2guJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGlzIGlzIGFsbCBhYm91dCAmcXVvdDtt ZXNzYWdlcyZxdW90OyBpbiBhcyBtdWNoIGFzIE5IRFAgaXMgY29uY2VybmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xKSBOSERQIHNwZWNp ZmllcyBzb21ldGhpbmcgYWtpbiB0byAmcXVvdDthbiBpbXBsZW1lbnRhdGlvbiBtYXkgcmVjb2du aXplIGFkZGl0aW9uYWwgcmVhc29ucyBmb3IgY29uc2lkZXJpbmcgYSBIRUxMTyBtZXNzYWdlIGlu dmFsaWQgZm9yIHByb2Nlc3NpbmcmcXVvdDs7IHRoaXMgSS1EIHNwZWNpZmllcyBzdWNoIGFuIGFk ZGl0aW9uYWwgcmVhc29uLCBieSB3YXkgb2YgYSBUTFYgaW4gSEVMTE8gbWVzc2FnZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIpIE5IRFAg JnF1b3Q7b3ducyZxdW90OyBIRUxMTyBtZXNzYWdlcywgYW5kIHRoZXJlZm9yZSBnZXRzIGZpcnN0 IGRpcCBvbiBhbiBpbmNvbWluZyBIRUxMTyBtZXNzYWdlIHBvc3QtZGVtdWx0aXBsaWNhdGlvbi4g SW5jbHVkaW5nIHRoZSBJQ1YgTWVzc2FnZSBUTFYgaW4gSEVMTE8gbWVzc2FnZXMgdGhlcmVmb3Jl IG1ha2VzIHNlbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BZCAxKSwgSSBub3RlIHRoYXQgdGhpcyBJLUQgaXMgaW50ZW5kZWQgdG8gZXhh Y3RseSBwbHVnIGluIGF0IHRoYXQgcGxhY2UgaW4gNjEzMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvbWFzIEhlaWRlIENsYXVzZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHA6Ly93d3cudGhvbWFzY2xhdXNlbi5vcmcvIj5odHRwOi8vd3d3LnRob21hc2NsYXVzZW4u b3JnLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+JnF1b3Q7QW55IHNpbXBsZSBwcm9i bGVtIGNhbiBiZSBtYWRlIGluc29sdWJsZSBpZiBlbm91Z2ggbWVldGluZ3MgYXJlIGhlbGQgdG88 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPiZuYnNwO2Rpc2N1c3MgaXQuJnF1b3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDst LSBNaXRjaGVsbCdzIExhdyBvZiBDb21taXR0ZWVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDEyIEp1bCAyMDEyLCBhdCAyMjo1NCwgVWxyaWNoIEhl cmJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzp1bHJpY2hAaGVyYmVyZy5uYW1lIj51bHJpY2hAaGVy YmVyZy5uYW1lPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRv Y3VtZW50IHNwZWNpZmllcyBzaWduaW5nL3ZlcmlmeWluZyBOSERQIG1lc3NhZ2VzLiBSRkM1NDQ0 IHBhY2tldHMgYXJlIG5vdCBzcGVjaWZpYyB0byBOSERQLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBJ TU8gbm90IGJlIGRpc2N1c3NlZCBpbiBhIGRvY3VtZW50IGVudGl0bGVkICZxdW90O1VzaW5nIElu dGVncml0eSBDaGVjayBWYWx1ZXMgYW5kIFRpbWVzdGFtcHMNCiBGb3IgUm91dGVyIEFkbWl0dGFu Y2UgaW4gTkhEUCZxdW90Oy4gVGhhdCdzIHdoeSBJIHN1Z2dlc3RlZCB0byBoYW5kbGUgdGhpcyBp biBhbiBhZGRpdGlvbmFsIGRvY3VtZW50IGZvciBSRkM1NDQ0IHBhY2tldHMuPGJyPg0KPGJyPg0K UmVnYXJkczxicj4NClVscmljaDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFRodSwgSnVsIDEyLCAyMDEyIGF0IDE6MzkgUE0sIEFiZHVzc2FsYW0gQmFyeXVu ICZsdDs8YSBocmVmPSJtYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5hYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVWxyaWNoLDxicj4NCjxicj4NCkkgYW0g bm90IGV4cGVydCBpbiBzZWN1cml0eSBpc3N1ZXMsIGJ1dCBJTUhPLCBJIGFncmVlIHdpdGggQ2hy aXMgdG88YnI+DQpyZWNvbW1lbmQgdG8gaW5jbHVkZSBpbiBkcmFmdC0wMiBib3RoIHNlY3VyaW5n IG1lc3NhZ2VzIGFuZCBwYWNrZXRzPGJyPg0KKGluIGdlbmVyYWwgZm9yIHBhY2tldHMpLCBzbyB0 aGUgZG9jdW1lbnQgc2hvdWxkIHNwZWNpZnkgTkhEUCBtZXNzYWdlczxicj4NCmFuZCBNQU5FVCBw YWNrZXRzIFtBQl0uIFRoZSByZWFzb25zIGFyZSBmaXJzdCwgYmVjYXVzZSBOSERQIGlzIGEgTUFO RVQ8YnI+DQpJbnRlcmZhY2UgcHJvdG9jb2wgYmV0d2VlbiBuZWlnaGJvciByb3V0ZXJzLiBzZWNv bmRseSBpdCB1c2VzIFJGQzU0NDQ8YnI+DQpmb3JtYXQgdGhhdCB0aGUgZnV0dXJlIE1BTkVUIHJv dXRlcnMgd2lsbCB1c2UuIFRoaXJkLCBOSERQIHVzZXM8YnI+DQpSRkM1NDQ0IHdoaWNoIHdhcyBz cGVjaWZpZWQgZm9yIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gTUFORVQ8YnI+DQpyb3V0 ZXJzLjxicj4NCjxicj4NCltBQl0gPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWJhcnl1bi1tYW5ldC10ZXJtaW5vbG9neS0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1iYXJ5dW4tbWFuZXQtdGVybWlub2xvZ3ktMDAu dHh0PC9hPjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQpBYmR1c3NhbGFtPGJyPg0KPT09PT09PTxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIFRodSwg SnVsIDEyLCAyMDEyIGF0IDk6MDggUE0sIFVscmljaCBIZXJiZXJnICZsdDt1bHJpY2ggYXQgPGEg aHJlZj0iaHR0cDovL2hlcmJlcmcubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPg0KaGVyYmVyZy5uYW1l PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBEZWFyIENocmlzLDxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIHByb3ZpZGUgc2ltaWxhciBtZWNoYW5pc21zIGFzIGlu IE5IRFAtc2VjIGZvciBUQzxicj4NCiZndDsgbWVzc2FnZXMgYXMgd2VsbC4gSSBkb24ndCB0aGlu ayB0aGF0IHNpZ25pbmcgdGhlIHBhY2tldCBpcyBlbm91Z2gsIHNpbmNlPGJyPg0KJmd0OyB0aGF0 IGRvZXMgbm90IHByb3ZpZGUgZW5kLXRvLWVuZCBzZWN1cml0eS4gSW5zdGVhZCwgSSBzdWdnZXN0 IHRvIHN1Ym1pdCBhPGJyPg0KJmd0OyBkcmFmdCBPTFNSdjItc2VjIHRoYXQgc3BlY2lmaWVzIGhv dyB0byBjYWxjdWxhdGUgSUNWcyBmb3IgVEMgbWVzc2FnZXMsIGFuZDxicj4NCiZndDsgaG93IHRv IGhhbmRsZSB0aGVzZSBtZXNzYWdlcyBpbiBPTFNSdjIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSG93 ZXZlciwgSSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgYmVuZWZpY2lhbCBmb3IgY2VydGFpbiBh cHBsaWNhdGlvbnMgdG88YnI+DQomZ3Q7IGFsc28gYmUgYWJsZSB0byBzaWduL3ZlcmlmeSBwYWNr ZXRzLiBCdXQgSSBkb24ndCB0aGluayB0aGF0IHRoZSBOSERQLXNlYzxicj4NCiZndDsgZG9jdW1l bnQgaXMgdGhlIHJpZ2h0IHBsYWNlIGZvciB0aGlzLCBzaW5jZSBvdGhlciBhcHBsaWNhdGlvbnMg KGUuZy4gRFlNTyk8YnI+DQomZ3Q7IG1heSBub3QgdXNlIEhFTExPIG1lc3NhZ2VzIGF0IGFsbCwg YnV0IHdvdWxkIHN0aWxsIGxpa2UgdG8gc2lnbi92ZXJpZnk8YnI+DQomZ3Q7IHBhY2tldHMuPGJy Pg0KJmd0OyBNYXliZSBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSBhbiBleHRyYSBkb2N1bWVu dCAmcXVvdDtwYWNrZXQtc2VjJnF1b3Q7IHdoaWNoPGJyPg0KJmd0OyBzcGVjaWZpZXMgaG93IHRv IHNpZ24vdmVyaWZ5IHBhY2tldHM/PGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdDxicj4NCiZndDsg VWxyaWNoPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFdlZCwgTWF5IDMwLCAyMDEy IGF0IDY6MjEgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmbHQ7Q2hyaXMu RGVhcmxvdmUgYXQgPGEgaHJlZj0iaHR0cDovL2JhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFu ayI+DQpiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgKFNlbmRpbmcgYWdhaW4sIHRvIHNvcnQgb3V0IHRoZSBmb3JtYXR0aW5nIHByb2JsZW0g d2l0aCB0aGUgbGFzdCBhdHRlbXB0Lik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFzIEkg cmVhZCBpdCwgdGhpcyBkcmFmdCBpcyBwcm9wb3NpbmcgdXNpbmcgdGhlIFJGQyA2NjIyIG1lY2hh bmlzbSB0byBzaWduPGJyPg0KJmd0OyZndDsgSEVMTE8gbWVzc2FnZXMuIFJGQyA2NjIyIGFjdHVh bGx5IGFsbG93cyBmb3Igc2lnbmluZyBwYWNrZXRzIGFzIHdlbGwgYXM8YnI+DQomZ3Q7Jmd0OyBz aWduaW5nIG1lc3NhZ2VzIChib3RoLCBlaXRoZXIsIG9yIG5laXRoZXIgdG8gYmUgdXNlZCBhcyBy ZXF1aXJlZCkuIFRoZXJlPGJyPg0KJmd0OyZndDsgaXNuJ3QgYSBtYWpvciBkaWZmZXJlbmNlIHdo ZW4gY29uc2lkZXJpbmcgSEVMTE8gbWVzc2FnZXMsIGFzIGZldyBpZiBhbnk8YnI+DQomZ3Q7Jmd0 OyBwYWNrZXRzIHdpbGwgY29udGFpbiBtb3JlIHRoYW4gb25lIEhFTExPIG1lc3NhZ2UsIGFuZCB0 aGUgcGFja2V0IGFuZCB0aGU8YnI+DQomZ3Q7Jmd0OyBtZXNzYWdlIHdpbGwgYmUgc2lnbmVkIGJ5 IHRoZSBzYW1lIHBhcnR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSG93ZXZlciBOSERQ IGRvZXNuJ3QgZXhpc3QgaW4gYSB2YWN1dW0sIGluIHBhcnRpY3VsYXIgaXQgaXMgdXNlZCBieTxi cj4NCiZndDsmZ3Q7IE9MU1J2Mi4gQW55IHNlY3VyaXR5IG1lY2hhbmlzbSB0aGF0IGlzIGRlc2Ny aWJlZCBpbiB3aGF0IHdpbGwgYmUgYW4gUkZDIGZvcjxicj4NCiZndDsmZ3Q7IE5IRFAgbXVzdCBh bHNvIGJlIHdoYXQncyByaWdodCBmb3IgTkhEUCBhcyB1c2VkIGJ5IE9MU1J2Mi4gT0xTUnYyIGFs c28gaGFzPGJyPg0KJmd0OyZndDsgVEMgbWVzc2FnZXMgdG8gY29uc2lkZXIsIGFuZCB0aGV5IGRv bid0IHNhdGlzZnkgdGhlIHBvaW50cyBub3RlZCBhYm92ZSAob248YnI+DQomZ3Q7Jmd0OyBudW1i ZXIgb3Igb24gd2hvIHNpZ25zIHRoZW0pLiBBbmQgb25lIG9wdGlvbiBmb3IgT0xTUnYyIGlzIHRv IHNpZ24gYWxsPGJyPg0KJmd0OyZndDsgcGFja2V0cywgbm90IG1lc3NhZ2VzLiBUaGlzIGNhbiBi ZSBhIHNlbnNpYmxlIGRlY2lzaW9uIHRoZXJlLCBmb3Igc2V2ZXJhbDxicj4NCiZndDsmZ3Q7IHJl YXNvbnMsIGluIHNvbWUgcmVhbCBjaXJjdW1zdGFuY2VzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQ29uc2VxdWVudGx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIGRyYWZ0IHNob3Vs ZCBkZXNjcmliZSBvbmx5IHNpZ25pbmc8YnI+DQomZ3Q7Jmd0OyBIRUxMTyBtZXNzYWdlcyBhcyB0 aGUgY29ycmVjdCB0aGluZyB0byBkbywgdGhhdCBpdCBzaG91bGQgYWxzbyBhbGxvdyBzaWduaW5n PGJyPg0KJmd0OyZndDsgcGFja2V0cyBhcyBhbiBlcXVhbCBzdGF0dXMgb3B0aW9uLiBJZiBzb21l b25lIHdhbnRzIHRvIHJhaXNlIHRoZSBwb3NzaWJpbGl0eTxicj4NCiZndDsmZ3Q7IG9mIHNpZ25p bmcgKHBvc3NpYmx5IGJ5IG1ldGhvZHMgd2l0aCBkaWZmZXJlbnQgcHJvcGVydGllcykgYm90aCBh dCB0aGU8YnI+DQomZ3Q7Jmd0OyBtZXNzYWdlIGFuZCBwYWNrZXQgbGV2ZWwsIHRoYXQgbWF5IGhh dmUgaXRzIHVzZSBjYXNlcyB0b28uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbmNpZGVu dGFsbHksIGV2ZW4gd2l0aGluIHRoZSBsaW1pdGVkIGZyYW1ld29yayBvZiBqdXN0IE5IRFAsIGl0 IGlzPGJyPg0KJmd0OyZndDsgcG9zc2libGUgdGhhdCBwYWNrZXRzIG5lZWQgcHJvdGVjdGlvbi4g SWYgYW4gTkhEUCBpbXBsZW1lbnRhdGlvbiBjaG9vc2VzIHRvPGJyPg0KJmd0OyZndDsgdXNlIHBh Y2tldCBzZXF1ZW5jZSBudW1iZXIgYXMgcGFydCBvZiBpdHMgbGluayBxdWFsaXR5IG1lY2hhbmlz bSwgYXMgaXQgbWF5LDxicj4NCiZndDsmZ3Q7IHRoZW4gYW4gdW5wcm90ZWN0ZWQgcGFja2V0IGhl YWRlciBpcyBhIHZ1bG5lcmFiaWxpdHkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAoRm9y IHRoZSBzYWtlIG9mIGNvbXBsZXRlbmVzcywgUkZDIDY2MjIgYWxzbyBhbGxvd3MgYWRkcmVzcyBi bG9jazxicj4NCiZndDsmZ3Q7IHNpZ25hdHVyZXMuIEkgZG9uJ3QgaGF2ZSBhIHJlYXNvbiB0byBz dWdnZXN0IHVzaW5nIHRoaXMgd2l0aGluIE5IRFAgb3I8YnI+DQomZ3Q7Jmd0OyBPTFNSdjIuKTxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyBDaHJpc3RvcGhlciBE ZWFybG92ZTxicj4NCiZndDsmZ3Q7IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIsIENvbW11bmlj YXRpb25zIEdyb3VwPGJyPg0KJmd0OyZndDsgQ29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJ bWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5PGJyPg0KJmd0OyZndDsgQkFFIFN5c3RlbXMgQWR2YW5j ZWQgVGVjaG5vbG9neSBDZW50cmU8YnI+DQomZ3Q7Jmd0OyBXZXN0IEhhbm5pbmdmaWVsZCBSb2Fk LCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLPGJyPg0KJmd0OyZndDsgVGVs OiAmIzQzOzQ0IDEyNDUgMjQyMTk0IHwgJm5ic3A7RmF4OiAmIzQzOzQ0IDEyNDUgMjQyMTI0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZn dDsgY2hyaXMuZGVhcmxvdmUgYXQgPGEgaHJlZj0iaHR0cDovL2JhZXN5c3RlbXMuY29tIiB0YXJn ZXQ9Il9ibGFuayI+DQpiYWVzeXN0ZW1zLmNvbTwvYT4gfCA8YSBocmVmPSJodHRwOi8vd3d3LmJh ZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbTwv YT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBCQUUgU3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZDxicj4N CiZndDsmZ3Q7IFJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZh cm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsPGJyPg0KJmd0OyZndDsgRmFybmJvcm91Z2gsIEhh bnRzLCBHVTE0IDZZVSwgVUs8YnI+DQomZ3Q7Jmd0OyBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFt cDsgV2FsZXMgTm86IDE5OTY2ODc8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyZndDsgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZzxicj4NCiZn dDsmZ3Q7IEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgOiBVc2luZyBJbnRlZ3JpdHkgQ2hlY2sgVmFsdWVzIGFuZCBUaW1lc3RhbXBzIEZv cjxicj4NCiZndDsmZ3Q7IFJvdXRlciBBZG1pdHRhbmNlIGluIE5IRFA8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogVWxyaWNoIEhlcmJlcmc8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVGhvbWFzIEhlaWRlIENsYXVzZW48YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFm dC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog MTI8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMi0wNS0yOTxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEg c2VjdXJpdHkgZXh0ZW5zaW9uIHRvIHRoZSBNQU5FVDxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJz cDtOZWlnaGJvcmhvb2QgRGlzY292ZXJ5IFByb3RvY29sIChOSERQKS4gJm5ic3A7VGhlIGV4dGVu c2lvbiBpbnRyb2R1Y2VzIHRoZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt1c2Ugb2YgSW50 ZWdyaXR5IENoZWNrIFZhbHVlcyAoSUNWcykgYW5kIFRpbWVzdGFtcHMgaW4gSEVMTE8gbWVzc2Fn ZXM8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7aW4gb3JkZXIgdG8gcHJvdmlkZSBhIHJvdXRl ciBhZG1pdHRhbmNlIG1lY2hhbmlzbSwgYW5kIHRoZXJlZm9yZSB0bzxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDtjb3VudGVyIGEgc2VsZWN0aW9uIG9mIHNlY3VyaXR5IHRocmVhdHMgdG8gTkhE UC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQSBVUkwgZm9yIHRo aXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLXNlYy0wMi50eHQi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0PC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Ojxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy88L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGlzIEludGVybmV0LURyYWZ0IGNh biBiZSByZXRyaWV2ZWQgYXQ6PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dCIgdGFy Z2V0PSJfYmxhbmsiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFRoZSBJRVRGIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJy Pg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tYW5ldC1uaGRwLXNlYy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMvPC9hPjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBtYW5ldCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBtYW5ldCBh dCA8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8YnI+DQomZ3Q7Jmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQomZ3Q7Jmd0OyByZWNpcGllbnQgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4NCiZn dDsmZ3Q7IHJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5v dGlmeSB0aGUgc2VuZGVyLjxicj4NCiZndDsmZ3Q7IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3Ig dXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQomZ3Q7Jmd0OyBkaXN0 cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCiZndDsmZ3Q7ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5l dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97035GLKXM0002VGREEN_-- From thomas@thomasclausen.org Fri Jul 13 05:35: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 4795A21F87F1 for ; Fri, 13 Jul 2012 05:35:46 -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, 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 w0aN7umDgkf3 for ; Fri, 13 Jul 2012 05:35:44 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6620921F87EF for ; Fri, 13 Jul 2012 05:35:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id CF2AF557F17 for ; Fri, 13 Jul 2012 05:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7A3E91C07C4; Fri, 13 Jul 2012 05:36:18 -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 336DC1C060D; Fri, 13 Jul 2012 05:36:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_728E1A98-AD19-4F85-B132-E9E4B6DA2F2D" From: Thomas Heide Clausen In-Reply-To: Date: Fri, 13 Jul 2012 14:36:15 +0200 Message-Id: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> References: To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1278) Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:35:46 -0000 --Apple-Mail=_728E1A98-AD19-4F85-B132-E9E4B6DA2F2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Chris, I figured that you wouldn't agree. I agree, of course, with your observation that none of the signature = models yields end-to-end security, but I don't think that that's the = issue here.=20 Personally, I do not see packet ICVs as being appropriate for neither = NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am = not saying that they do not exist. I could make an argument that a = packet ICV would have to be validated before knowing that a HELLO = message was delivered to an NHDP instance, and that the validation might = be based on different principles (or, even layers) for packet/messages.=20= I see what you say about protecting packet sequence numbers by way of a = packet-level ICV, but I would argue that: o As packet sequence numbers are generated "outside" NHDP, = and are incremented for all=20 packets (not just those with HELLOs), specifying the = validation of a packet-level ICV in NHDP would be inappropriate (as in: potentially conflicting with = another mechanism) o Whatever mechanism would provide "packet sequence number = statistics" to NHDP (such as the demultiplexer) would want to be the entity doing that = packet-level ICV validation, in part as I would _suspect_ that inability to validate a = packet-level ICV should cause the whole packet with all contained messages to be dropped. That said, with reference to the I-D, I think I speak for the authors = when saying that we're welcoming a suggestion that would address the = issue that you raise? Best, Thomas On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote: > I don't agree. Note that if all you are running is NHDP, then signing = packets is more secure than signing messages, as you get to cover the = packet sequence number as well. > What I think is wrong is to suggest that the only correct way to = protect NHDP is to sign HELLO messages. Whether by inclusion or external = reference, signing packets should be also an option. > =20 > I'll take that further to OLSrv2 as well. Now there signing messages = vs signing packets has advantages to the former. But signing packets = also has advantages of simplicity and covering packet header. It is = incidentally not correct to say that signing TC messages provides end to = end security. It's actually last-bit-one-from-end to end, and still = relies on a form of transitive trust. Packet based signatures rely on a = greater degree of transitive trust. There is a difference in threat = models and vulnerabilities, and that may matter, but it's not = (unfortunately) as simple as one being end to end and thus avoiding = transitivity issues. > =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 > From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 12 July 2012 23:09 > To: Ulrich Herberg > Cc: Dearlove, Christopher (UK); manet > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt > =20 > =20 > *** 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. >=20 > I agree with Ulrich.=20 > =20 > Note that this is all about "messages" in as much as NHDP is = concerned. > =20 > 1) NHDP specifies something akin to "an implementation may recognize = additional reasons for considering a HELLO message invalid for = processing"; this I-D specifies such an additional reason, by way of a = TLV in HELLO messages. > =20 > 2) NHDP "owns" HELLO messages, and therefore gets first dip on an = incoming HELLO message post-demultiplication. Including the ICV Message = TLV in HELLO messages therefore makes sense. > =20 > Ad 1), I note that this I-D is intended to exactly plug in at that = place in 6130. > =20 > Thomas > =20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 >=20 > "Any simple problem can be made insoluble if enough meetings are held = to > discuss it." > -- Mitchell's Law of Committees > =20 >=20 > On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: >=20 > The document specifies signing/verifying NHDP messages. RFC5444 = packets are not specific to NHDP, and therefore should IMO not be = discussed in a document entitled "Using Integrity Check Values and = Timestamps For Router Admittance in NHDP". That's why I suggested to = handle this in an additional document for RFC5444 packets. >=20 > Regards > Ulrich >=20 > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun = wrote: > Hi Ulrich, >=20 > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. >=20 > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >=20 > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D >=20 > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg wrote: > > Dear Chris, > > > > I agree that we need to provide similar mechanisms as in NHDP-sec = for TC > > messages as well. I don't think that signing the packet is enough, = since > > that does not provide end-to-end security. Instead, I suggest to = submit a > > draft OLSRv2-sec that specifies how to calculate ICVs for TC = messages, and > > how to handle these messages in OLSRv2. > > > > However, I believe that it would be beneficial for certain = applications to > > also be able to sign/verify packets. But I don't think that the = NHDP-sec > > document is the right place for this, since other applications (e.g. = DYMO) > > may not use HELLO messages at all, but would still like to = sign/verify > > packets. > > Maybe it would be better to have an extra document "packet-sec" = which > > specifies how to sign/verify packets? > > > > Best > > Ulrich > > > > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: > >> > >> (Sending again, to sort out the formatting problem with the last = attempt.) > >> > >> As I read it, this draft is proposing using the RFC 6622 mechanism = to sign > >> HELLO messages. RFC 6622 actually allows for signing packets as = well as > >> signing messages (both, either, or neither to be used as required). = There > >> isn't a major difference when considering HELLO messages, as few if = any > >> packets will contain more than one HELLO message, and the packet = and the > >> message will be signed by the same party. > >> > >> However NHDP doesn't exist in a vacuum, in particular it is used by > >> OLSRv2. Any security mechanism that is described in what will be an = RFC for > >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 = also has > >> TC messages to consider, and they don't satisfy the points noted = above (on > >> number or on who signs them). And one option for OLSRv2 is to sign = all > >> packets, not messages. This can be a sensible decision there, for = several > >> reasons, in some real circumstances. > >> > >> Consequently, I don't believe that this draft should describe only = signing > >> HELLO messages as the correct thing to do, that it should also = allow signing > >> packets as an equal status option. If someone wants to raise the = possibility > >> of signing (possibly by methods with different properties) both at = the > >> message and packet level, that may have its use cases too. > >> > >> Incidentally, even within the limited framework of just NHDP, it is > >> possible that packets need protection. If an NHDP implementation = chooses to > >> use packet sequence number as part of its link quality mechanism, = as it may, > >> then an unprotected packet header is a vulnerability. > >> > >> (For the sake of completeness, RFC 6622 also allows address block > >> signatures. I don't have a reason to suggest using this within NHDP = or > >> OLSRv2.) > >> > >> -- > >> 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 > >> > >> 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 > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Mobile Ad-hoc = Networks Working > >> Group of the IETF. > >> > >> Title : Using Integrity Check Values and = Timestamps For > >> Router Admittance in NHDP > >> Author(s) : Ulrich Herberg > >> Thomas Heide Clausen > >> Filename : draft-ietf-manet-nhdp-sec-02.txt > >> Pages : 12 > >> Date : 2012-05-29 > >> > >> This document specifies a security extension to the MANET > >> Neighborhood Discovery Protocol (NHDP). The extension = introduces the > >> use of Integrity Check Values (ICVs) and Timestamps in HELLO = messages > >> in order to provide a router admittance mechanism, and therefore = to > >> counter 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-02.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-02.txt > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > >> > >> _______________________________________________ > >> manet mailing list > >> manet at 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 > _______________________________________________ > 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=_728E1A98-AD19-4F85-B132-E9E4B6DA2F2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Chris,

I figured that = you wouldn't agree.

I agree, of course, with = your observation that none of the signature models yields end-to-end = security, but I don't think that that's the issue = here. 

Personally, I do not see packet = ICVs as being appropriate for neither NHDP nor OLSRv2 - at least, not = for the uses that I see/have, but I am not saying that they do not = exist. I could make an argument that a packet ICV would have to be = validated before knowing that a HELLO message was delivered to an NHDP = instance, and that the validation might be based on different principles = (or, even layers) for packet/messages. 

I = see what you say about protecting packet sequence numbers by way of a = packet-level ICV, but I would argue that:

o As packet = sequence numbers are generated "outside" NHDP, and are incremented for = all 
packets (not just those = with HELLOs), specifying the validation of a packet-level ICV in NHDP = would
= be inappropriate (as in: potentially conflicting with = another mechanism)

o Whatever mechanism would provide = "packet sequence number statistics" to NHDP (such as the
= demultiplexer) would want to be the entity doing that = packet-level ICV validation, in part as
I = would _suspect_ that inability to validate a packet-level ICV should = cause the whole packet
with all contained = messages to be dropped.

That said, with reference to = the I-D, I think I speak for the authors when saying that we're = welcoming a suggestion that would address the issue that you = raise?

Best,

Thomas
On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) = wrote:

I don't agree. Note that if all = you are running is NHDP, then signing packets is more secure than = signing messages, as you get to cover the packet sequence number as = well.
What = I think is wrong is to suggest that the only correct way to protect NHDP = is to sign HELLO messages. Whether by inclusion or external reference, = signing packets should be also an option.
I'll = take that further to OLSrv2 as well. Now there signing messages vs = signing packets has advantages to the former. But signing packets also = has advantages of simplicity and covering packet header. It is = incidentally not correct to say that signing TC messages provides end to = end security. It's actually last-bit-one-from-end to end, and still = relies on a form of transitive trust. Packet based signatures rely on a = greater degree of transitive trust. There is a difference in threat = models and vulnerabilities, and that may matter, but it's not = (unfortunately) as simple as one being end to end and thus avoiding = transitivity issues.
 
Note that this is all = about "messages" in as much as NHDP is = concerned.
1) NHDP specifies = something akin to "an implementation may recognize additional reasons = for considering a HELLO message invalid for processing"; this I-D = specifies such an additional reason, by way of a TLV in HELLO = messages.
2) NHDP "owns" HELLO = messages, and therefore gets first dip on an incoming HELLO message = post-demultiplication. Including the ICV Message TLV in HELLO messages = therefore makes sense.
 
Ad 1), I note that this I-D is intended to exactly plug = in at that place in 6130.
 
Thomas

The document = specifies signing/verifying NHDP messages. RFC5444 packets are not = specific to NHDP, and therefore should IMO not be discussed in a = document entitled "Using Integrity Check Values and Timestamps For = Router Admittance in NHDP". That's why I suggested to handle this in an = additional document for RFC5444 = packets.

Regards
Ulrich

On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun = <Hi Ulrich,

I am not expert in security issues, = but IMHO, I agree with Chris to
recommend to include in draft-02 both = securing messages and packets
(in general for packets), so the = document should specify NHDP messages
and MANET packets [AB]. The = reasons are first, because NHDP is a MANET
Interface protocol between = neighbor routers. secondly it uses RFC5444
format that the future = MANET routers will use. Third, NHDP uses
RFC5444 which was specified = for information exchange between MANET
routers.

[AB] 
On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg = <ulrich at herberg.name> wrote:
> Dear = Chris,
>
> I agree that we need to provide similar = mechanisms as in NHDP-sec for TC
> messages as well. I don't think = that signing the packet is enough, since
> that does not provide = end-to-end security. Instead, I suggest to submit a
> draft = OLSRv2-sec that specifies how to calculate ICVs for TC messages, = and
> how to handle these messages in OLSRv2.
>
> = However, I believe that it would be beneficial for certain applications = to
> also be able to sign/verify packets. But I don't think that = the NHDP-sec
> document is the right place for this, since other = applications (e.g. DYMO)
> may not use HELLO messages at all, but = would still like to sign/verify
> packets.
> Maybe it would = be better to have an extra document "packet-sec" which
> specifies = how to sign/verify packets?
>
> Best
> = Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, = Dearlove, Christopher (UK)
> <Chris.Dearlove at baesystems.com> = wrote:
>>
>> (Sending again, to sort out the = formatting problem with the last attempt.)
>>
>> As I = read it, this draft is proposing using the RFC 6622 mechanism to = sign
>> HELLO messages. RFC 6622 actually allows for signing = packets as well as
>> signing messages (both, either, or = neither to be used as required). There
>> isn't a major = difference when considering HELLO messages, as few if any
>> = packets will contain more than one HELLO message, and the packet and = the
>> message will be signed by the same = party.
>>
>> However NHDP doesn't exist in a vacuum, = in particular it is used by
>> OLSRv2. Any security mechanism = that is described in what will be an RFC for
>> NHDP must also = be what's right for NHDP as used by OLSRv2. OLSRv2 also has
>> = TC messages to consider, and they don't satisfy the points noted above = (on
>> number or on who signs them). And one option for OLSRv2 = is to sign all
>> packets, not messages. This can be a sensible = decision there, for several
>> reasons, in some real = circumstances.
>>
>> Consequently, I don't believe = that this draft should describe only signing
>> HELLO messages = as the correct thing to do, that it should also allow = signing
>> packets as an equal status option. If someone wants = to raise the possibility
>> of signing (possibly by methods = with different properties) both at the
>> message and packet = level, that may have its use cases too.
>>
>> = Incidentally, even within the limited framework of just NHDP, it = is
>> possible that packets need protection. If an NHDP = implementation chooses to
>> use packet sequence number as part = of its link quality mechanism, as it may,
>> then an = unprotected packet header is a vulnerability.
>>
>> = (For the sake of completeness, RFC 6622 also allows address = block
>> signatures. I don't have a reason to suggest using = this within NHDP or
>> OLSRv2.)
>>
>> = --
>> 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 | >>
>> 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
>>
>>
>> A New Internet-Draft is = available from the on-line Internet-Drafts
>> directories. This = draft is a work item of the Mobile Ad-hoc Networks Working
>> = Group of the IETF.
>>
>>         = Title           : Using Integrity Check Values = and Timestamps For
>> Router Admittance in NHDP
>> =         Author(s)       : Ulrich = Herberg
>>               =             Thomas Heide = Clausen
>>         Filename     =    : draft-ietf-manet-nhdp-sec-02.txt
>>   =       Pages           : = 12
>>         Date       =      : 2012-05-29
>>
>>   =  This document specifies a security extension to the = MANET
>>    Neighborhood Discovery Protocol (NHDP). =  The extension introduces the
>>    use of = Integrity Check Values (ICVs) and Timestamps in HELLO = messages
>>    in order to provide a router = admittance mechanism, and therefore to
>>    counter = a selection of security threats to = NHDP.
>>
>>
>> A URL for this Internet-Draft = is:
>>    >> manet at >> 
manet@ietf.org
manet@ietf.org
To: Thomas Heide Clausen Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: AQHNYG5lMWs8L8nJvUmskMYRmizNvpcmD5KAgAAUo4CAAPwpAP//9jGAgAAS0PA= Date: Fri, 13 Jul 2012 12:52:18 +0000 Message-ID: References: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> In-Reply-To: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97122GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:51:49 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97122GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This partly depends on what your planned document structure is, Ulrich just= mentioned the possibility of a generic 5444 document. I'm actually not sur= e that wouldn't be more relevant, as it is hard to actually separate these = things. But I think this is jumping in with solutions before considering a threat m= odel. Let's suppose that we have hardware that (a) stores key materials in = secure tamperproof storage, (b) doesn't make mistakes, and (c) we use a si= gnature method that's cryptographically infeasible to break. Then in this c= ase (not uniquely) packet signatures actually provide as much security as m= essage signatures. Of course I can also think of threat models that do favo= ur message signatures. But this is exactly like the choice of signature met= hods, which is not mandated because different threats require different sol= utions. The same is true of packet and message signatures. Each (and indeed= the third option of both) should be allowed, we should not have a document= that prefers one above the other except following a security analysis - wh= ich is not on offer. -- 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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 13 July 2012 13:36 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt *** 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. Chris, I figured that you wouldn't agree. I agree, of course, with your observation that none of the signature models= yields end-to-end security, but I don't think that that's the issue here. Personally, I do not see packet ICVs as being appropriate for neither NHDP = nor OLSRv2 - at least, not for the uses that I see/have, but I am not sayin= g that they do not exist. I could make an argument that a packet ICV would = have to be validated before knowing that a HELLO message was delivered to a= n NHDP instance, and that the validation might be based on different princi= ples (or, even layers) for packet/messages. I see what you say about protecting packet sequence numbers by way of a pac= ket-level ICV, but I would argue that: o As packet sequence numbers are generated "outside" N= HDP, and are incremented for all packets (not just those with HELLOs), specifying th= e validation of a packet-level ICV in NHDP would be inappropriate (as in: potentially conflicting wi= th another mechanism) o Whatever mechanism would provide "packet sequence nu= mber statistics" to NHDP (such as the demultiplexer) would want to be the entity doing th= at packet-level ICV validation, in part as I would _suspect_ that inability to validate a pack= et-level ICV should cause the whole packet with all contained messages to be dropped. That said, with reference to the I-D, I think I speak for the authors when = saying that we're welcoming a suggestion that would address the issue that = you raise? Best, Thomas On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote: I don't agree. Note that if all you are running is NHDP, then signing packe= ts is more secure than signing messages, as you get to cover the packet seq= uence number as well. What I think is wrong is to suggest that the only correct way to protect NH= DP is to sign HELLO messages. Whether by inclusion or external reference, s= igning packets should be also an option. I'll take that further to OLSrv2 as well. Now there signing messages vs sig= ning packets has advantages to the former. But signing packets also has adv= antages of simplicity and covering packet header. It is incidentally not co= rrect to say that signing TC messages provides end to end security. It's ac= tually last-bit-one-from-end to end, and still relies on a form of transiti= ve trust. Packet based signatures rely on a greater degree of transitive tr= ust. There is a difference in threat models and vulnerabilities, and that m= ay matter, but it's not (unfortunately) as simple as one being end to end a= nd thus avoiding transitivity issues. -- 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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] Sent: 12 July 2012 23:09 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt *** 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. I agree with Ulrich. Note that this is all about "messages" in as much as NHDP is concerned. 1) NHDP specifies something akin to "an implementation may recognize additi= onal reasons for considering a HELLO message invalid for processing"; this = I-D specifies such an additional reason, by way of a TLV in HELLO messages. 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming = HELLO message post-demultiplication. Including the ICV Message TLV in HELLO= messages therefore makes sense. Ad 1), I note that this I-D is intended to exactly plug in at that place in= 6130. 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 12 Jul 2012, at 22:54, Ulrich Herberg > wrote: The document specifies signing/verifying NHDP messages. RFC5444 packets are= not specific to NHDP, and therefore should IMO not be discussed in a docum= ent entitled "Using Integrity Check Values and Timestamps For Router Admitt= ance in NHDP". That's why I suggested to handle this in an additional docum= ent for RFC5444 packets. Regards Ulrich On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun > wrote: Hi Ulrich, I am not expert in security issues, but IMHO, I agree with Chris to recommend to include in draft-02 both securing messages and packets (in general for packets), so the document should specify NHDP messages and MANET packets [AB]. The reasons are first, because NHDP is a MANET Interface protocol between neighbor routers. secondly it uses RFC5444 format that the future MANET routers will use. Third, NHDP uses RFC5444 which was specified for information exchange between MANET routers. [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: > Dear Chris, > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > messages as well. I don't think that signing the packet is enough, since > that does not provide end-to-end security. Instead, I suggest to submit a > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, an= d > how to handle these messages in OLSRv2. > > However, I believe that it would be beneficial for certain applications t= o > also be able to sign/verify packets. But I don't think that the NHDP-sec > document is the right place for this, since other applications (e.g. DYMO= ) > may not use HELLO messages at all, but would still like to sign/verify > packets. > Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets? > > Best > Ulrich > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: >> >> (Sending again, to sort out the formatting problem with the last attempt= .) >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to si= gn >> HELLO messages. RFC 6622 actually allows for signing packets as well as >> signing messages (both, either, or neither to be used as required). Ther= e >> isn't a major difference when considering HELLO messages, as few if any >> packets will contain more than one HELLO message, and the packet and the >> message will be signed by the same party. >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> OLSRv2. Any security mechanism that is described in what will be an RFC = for >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also h= as >> TC messages to consider, and they don't satisfy the points noted above (= on >> number or on who signs them). And one option for OLSRv2 is to sign all >> packets, not messages. This can be a sensible decision there, for severa= l >> reasons, in some real circumstances. >> >> Consequently, I don't believe that this draft should describe only signi= ng >> HELLO messages as the correct thing to do, that it should also allow sig= ning >> packets as an equal status option. If someone wants to raise the possibi= lity >> of signing (possibly by methods with different properties) both at the >> message and packet level, that may have its use cases too. >> >> Incidentally, even within the limited framework of just NHDP, it is >> possible that packets need protection. If an NHDP implementation chooses= to >> use packet sequence number as part of its link quality mechanism, as it = may, >> then an unprotected packet header is a vulnerability. >> >> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP or >> OLSRv2.) >> >> -- >> 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.bae= systems.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 >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobile Ad-hoc Networks Wor= king >> Group of the IETF. >> >> Title : Using Integrity Check Values and Timestamps Fo= r >> Router Admittance in NHDP >> Author(s) : Ulrich Herberg >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> Pages : 12 >> Date : 2012-05-29 >> >> This document specifies a security extension to the MANET >> Neighborhood Discovery Protocol (NHDP). The extension introduces the >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages >> in order to provide a router admittance mechanism, and therefore to >> counter 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-02.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-02.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> _______________________________________________ >> manet mailing list >> manet at ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> > _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97122GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This partly depends on wh= at your planned document structure is, Ulrich just mentioned the possibilit= y of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these things= .

 <= /p>

But I think this is jumpi= ng in with solutions before considering a threat model. Let's suppose that = we have hardware that (a) stores key materials in secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a sig= nature method that's cryptographically infeasible to break. Then in this ca= se (not uniquely) packet signatures actually provide as much security as me= ssage signatures. Of course I can also think of threat models that do favour message signatures. But this is exac= tly like the choice of signature methods, which is not mandated because dif= ferent threats require different solutions. The same is true of packet and = message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document= that prefers one above the other except following a security analysis - wh= ich is not on offer.

 <= /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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org= ]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

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

Chris,

 

I figured that you wouldn't agree.

 

I agree, of course, with your observation that none = of the signature models yields end-to-end security, but I don't think that = that's the issue here. 

 

Personally, I do not see packet ICVs as being approp= riate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/h= ave, but I am not saying that they do not exist. I could make an argument t= hat a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP ins= tance, and that the validation might be based on different principles (or, = even layers) for packet/messages. 

 

I see what you say about protecting packet sequence = numbers by way of a packet-level ICV, but I would argue that:

 

   &nb= sp;        o          As packet sequence numbers are generated "outside" NHDP, a= nd are incremented for all 

   &nb= sp;            =         packets (not just those with HELLOs), specifying the validation of a packet= -level ICV in NHDP would

   &nb= sp;            =         be inappropriate (as in: potentially conflicting with another mechanism)

 

   &nb= sp;        o          Whatever mechanism would provide "packet sequence number statis= tics" to NHDP (such as the

   &nb= sp;            =         demultiplexer) would want to be the entity doing that packet-level ICV vali= dation, in part as

   &nb= sp;            =         I would _suspect_ that inability to validate a packet-level ICV should caus= e the whole packet

   &nb= sp;            =         with all contained messages to be dropped.

 

That said, with reference to the I-D, I think I spea= k for the authors when saying that we're welcoming a suggestion that would = address the issue that you raise?

 

Best,

 

Thomas

 

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (U= K) wrote:



I don't agree. Note that = if all you are running is NHDP, then signing packets is more secure than si= gning messages, as you get to cover the packet sequence number as well.

What I think is wrong is = to suggest that the only correct way to protect NHDP is to sign HELLO messa= ges. Whether by inclusion or external reference, signing packets should be also an option.

 <= /p>

I'll take that further to= OLSrv2 as well. Now there signing messages vs signing packets has advantag= es to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct t= o say that signing TC messages provides end to end security. It's actually = last-bit-one-from-end to end, and still relies on a form of transitive trus= t. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat m= odels and vulnerabilities, and that may matter, but it's not (unfortunately= ) as simple as one being end to end and thus avoiding transitivity issues.<= /span>

 <= /p>

--

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<= /o:p>

= 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

 <= /p>

From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 12 July 2012= 23:09
To: Ulrich Herberg=
Cc: Dearlove, Chri= stopher (UK); manet
Subject: Re: [mane= t] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

*** 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 agree with Ulrich. 

 

Note that this is all about "messages" in = as much as NHDP is concerned.

 

1) NHDP specifies something akin to "an impleme= ntation may recognize additional reasons for considering a HELLO message in= valid for processing"; this I-D specifies such an additional reason, b= y way of a TLV in HELLO messages.

 

2) NHDP "owns" HELLO messages, and therefo= re gets first dip on an incoming HELLO message post-demultiplication. Inclu= ding the ICV Message TLV in HELLO messages therefore makes sense.

 

Ad 1), I note that this I-D is intended to exactly p= lug in at that place in 6130.

 

Thomas

 

-- 

Thomas Heide Clausen




"Any simple pr= oblem can be made insoluble if enough meetings are held to

 discuss it.&q= uot;

   -- Mitchell's Law of Committees

 


On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:

The document specifie= s signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP= , and therefore should IMO not be discussed in a document entitled "Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this= in an additional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] ht= tp://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D


On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for = TC
> messages as well. I don't think that signing the packet is enough, sin= ce
> that does not provide end-to-end security. Instead, I suggest to submi= t a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages,= and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain application= s to
> also be able to sign/verify packets. But I don't think that the NHDP-s= ec
> document is the right place for this, since other applications (e.g. D= YMO)
> may not use HELLO messages at all, but would still like to sign/verify=
> packets.
> Maybe it would be better to have an extra document "packet-sec&qu= ot; which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)=

> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last a= ttempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism= to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as we= ll as
>> signing messages (both, either, or neither to be used as required)= . There
>> isn't a major difference when considering HELLO messages, as few i= f any
>> packets will contain more than one HELLO message, and the packet a= nd the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used b= y
>> OLSRv2. Any security mechanism that is described in what will be a= n RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 = also has
>> TC messages to consider, and they don't satisfy the points noted a= bove (on
>> number or on who signs them). And one option for OLSRv2 is to sign= all
>> packets, not messages. This can be a sensible decision there, for = several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only= signing
>> HELLO messages as the correct thing to do, that it should also all= ow signing
>> packets as an equal status option. If someone wants to raise the p= ossibility
>> of signing (possibly by methods with different properties) both at= the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it i= s
>> possible that packets need protection. If an NHDP implementation c= hooses to
>> use packet sequence number as part of its link quality mechanism, = as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block<= br> >> signatures. I don't have a reason to suggest using this within NHD= P or
>> OLSRv2.)
>>
>> --
>> 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

>>
>> 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
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories. This draft is a work item of the Mobile Ad-hoc Networ= ks Working
>> Group of the IETF.
>>
>>         Title         &nbs= p; : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulric= h Herberg
>>                   &nb= sp;       Thomas Heide Clausen
>>         Filename        : = draft-ietf-manet-nhdp-sec-02.txt
>>         Pages         &nbs= p; : 12
>>         Date          = ;  : 2012-05-29
>>
>>    This document specifies a security extension to the M= ANET
>>    Neighborhood Discovery Protocol (NHDP).  The ext= ension introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps i= n HELLO messages
>>    in order to provide a router admittance mechanism, an= d therefore to
>>    counter 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-02.tx= t
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/intern= et-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt<= /a>
>>
>> The IETF datatracker page for this Internet-Draft is:
>> h= ttps://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list

>> manet at ietf.org<= o:p>

>> = 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<= br> >> 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.or= g/mailman/listinfo/manet

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

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24E97122GLKXM0002VGREEN_-- From ulrich@herberg.name Fri Jul 13 08:27: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 EADE721F878A for ; Fri, 13 Jul 2012 08:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.100, 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 kj7HOrGIh+-Q for ; Fri, 13 Jul 2012 08:27:05 -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 E786321F8787 for ; Fri, 13 Jul 2012 08:27:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5960715pbc.31 for ; Fri, 13 Jul 2012 08:27:41 -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=qwGaldBI7zGsAVrMVLmYfAfkDAgUufMSHH3T0FwzSOs=; b=hyVj0fR96MpRd4dv5Qp5ECFiUUIqsv3wRicosDhnbTZYV2PDnMnQVcp3GUxZPimYV5 kqPCtmqUTSIov6wKQPn+q02KHmXm7FrD5BEJv8VcP7+W28xxJnWvbwJoxpXkJ7Fo0YEw DXDdg7Nn/6L7ORqR6/17CmP0NLklbx9/lW2dY= 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=qwGaldBI7zGsAVrMVLmYfAfkDAgUufMSHH3T0FwzSOs=; b=lzCUtproVn5ZQ6i04QPpsp2fQi517SXNTUfiRyxqWK8fHoWJbLUcsN/heHAf6+Vxu1 2rh23x3XWpRV2iinp+k541sIlksQUmWdFAK2NWge5+QKido7T9yg46H1WuLXs7hAUkMz ilv1iYavKw0e4pw1S10vHwP2HnJMwA8GE+EIIRCOno7D8BZd2O335M6fTxhGCv9HRZ// d9Ij8iAi1lBEKHkRDn4DzarSjFZtvJ7ThE2h5R2Rl6XtSCjPhAcf5ylRr8B4xSuvRzS0 umvfyGbtRf7g4xCMsJtwV0nBEOOkzzldQm/0sIuHiVElLFt3gnj6vNI2TIH7BO+U0ci8 MOJg== Received: by 10.68.224.70 with SMTP id ra6mr4863785pbc.11.1342193261190; Fri, 13 Jul 2012 08:27:41 -0700 (PDT) Received: from [192.168.1.5] (c-24-5-73-168.hsd1.ca.comcast.net. [24.5.73.168]) by mx.google.com with ESMTPS id of1sm6204839pbb.15.2012.07.13.08.27.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2012 08:27:40 -0700 (PDT) References: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> In-Reply-To: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Fri, 13 Jul 2012 08:27:40 -0700 To: Thomas Heide Clausen X-Gm-Message-State: ALoCoQlV1xR4zpbG/Xa9DfQLMDHZfoHZlFxxljgyr7pIo7z4LQsVHZ3swvVC853JpQmQ8qRxH538 Cc: manet , Abdussalam Baryun Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 15:27:06 -0000 I agree with Thomas. What you propose is a layer violation. It's like sticki= ng application payload in an IPv6 Extension Header or an L2 frame header. Ulrich On Jul 13, 2012, at 3:35, Thomas Heide Clausen wr= ote: >=20 > On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote: >=20 >> Hi, >>=20 >> AB>> It is about securing neighbor discovery, the draft: manet-nhdp-sec-0= 2 >>>=20 >>> No. It is about securing a specific neighborhood discovery protocol - a >>> protocol, whose signaling is carried in RFC5444 _messages_. >>>=20 >>=20 >> NHDP was not designed for specific purpose of one proactive routing, >> but for All MANET Routers. I agree that it specifies messages not >> packets as Ulrich mentioned before, but there is no MUST in RFC6130 >> that its signalling MUST be only messages, we need to consider the >> specification's requirement language (MUST, SHOULD, MAY,..etc), there >> is no restrictions, there is room for update :) >=20 > No, that is wrong. RFC6130 specifies the use of RFC5444 messages. >=20 > If you want to use smoke-signals, carved potatoes or something else not sp= ecified in RFC6130, then you're simply not using RFC6130. >=20 > This has nothing to do with requirements language. >=20 >>>>> 1) NHDP specifies something akin to "an implementation may recognize >>>>> additional reasons for considering a HELLO message invalid for >>>>> processing"; this I-D specifies such an additional reason, by way of a= >>>>> TLV in HELLO messages. >>>>>=20 >>>>=20 >> AB>> yes it does in NHDP, but it does not restrict to messages only, >>>> because it uses/understands [RFC5444] packets. >>>=20 >>> Irrelevant. RFC6130 speaks of reasons for considering messages invalid. >>>=20 >>=20 >> Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry >> specified NHDP-messages. yes, also speaks of invalid NHDP-messages >> please read: >>=20 >> RFC6130> page 40> A router *MAY* recognize additional reasons for >> identifying that a message is badly formed and therefore invalid for >> processing. >>=20 >> meaning> there may be a use of NHDP packet check as well >=20 > For exactly the reasons I gave in the above. >=20 > Plus, that for RFC6130 to use packet header content would constitute a lay= er violation (and a very badly designed system). >=20 >>=20 >>>>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >>>>> incoming HELLO message post-demultiplication. Including the ICV >>>>> Message TLV in HELLO messages therefore makes sense. >>>>>=20 >>>>=20 >>>> It may own/create the [5444] packet carrying the hello messages >>>>=20 >>>=20 >>> No, it may not. See how demultiplexing of RFC5444 messages work, as well= as >>> what RFC6130 says for HELLO messages. >>>=20 >>=20 >> Please provide me which page or sentence mentions your understanding >> as: *MAY NOT* create 5444-packets. I will do your advise to look into >> the RFC6130 again for demultiplexing of NHDP-messages, and will reply. >=20 > I don't think that you understand RFC6130 or RFC5444 at all.=20 >=20 > RFC6130 generates RFC5444 messages, which are carried (as are all RFC5444 m= essages) in RFC5444 packets. >=20 > A protocol generating something not specified in RFC6130 is not RFC6130. >=20 > I do not know how it can be made more clear. >=20 > Thomas >=20 >=20 >=20 >> Thanking you, >> Abdussalam Baryun, >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>>=20 >>>>> On 12 Jul 2012, at 22:54, Ulrich Herberg wrot= e: >>>>>=20 >>>>>=20 >>>>> The document specifies signing/verifying NHDP messages. RFC5444 >>>>> packets are not specific to NHDP, and therefore should IMO not be >>>>> discussed in a document entitled "Using Integrity Check Values and >>>>> Timestamps For Router Admittance in NHDP". That's why I suggested to >>>>> handle this in an additional document for RFC5444 packets. >>>>>=20 >>>>> Regards >>>>> Ulrich >>>>>=20 >>>>>=20 >>>>> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun >>>> at gmail.com> wrote: >>>>>=20 >>>>> Hi Ulrich, >>>>>=20 >>>>> I am not expert in security issues, but IMHO, I agree with Chris to >>>>> recommend to include in draft-02 both securing messages and packets >>>>> (in general for packets), so the document should specify NHDP messages= >>>>> and MANET packets [AB]. The reasons are first, because NHDP is a MANET= >>>>> Interface protocol between neighbor routers. secondly it uses RFC5444 >>>>> format that the future MANET routers will use. Third, NHDP uses >>>>> RFC5444 which was specified for information exchange between MANET >>>>> routers. >>>>>=20 >>>>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>=20 >>>>> Regards >>>>> Abdussalam >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Jul 13 09:54: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 C884E11E808A for ; Fri, 13 Jul 2012 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.469, 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 B6DJ-dxm7Lna for ; Fri, 13 Jul 2012 09:54:26 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A675511E80CF for ; Fri, 13 Jul 2012 09:54:25 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4139152ghb.31 for ; Fri, 13 Jul 2012 09:55:01 -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=niWG58O2NWqQG9W40d0TVLDuugF9P65R7Q+60okiC5k=; b=eqXysZMJMku51J8W/k4v0QNINmasUUK2bJw1iHn80PiGIJcHUQC9vXjiXjxi0qi3+i 1XzxWuUXmsp0uJ9ZFbj4JkaC89XfDpkdSrLXLog8hO6ettAX66TxzdbHMhnXMdjq93zs 7XHC5rAAMQjfcrznxryYjLmGVTJK4Nj6w1qz0= 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=niWG58O2NWqQG9W40d0TVLDuugF9P65R7Q+60okiC5k=; b=jIZLTkMgE3hJq/ojOnWqitVrkz4J3GlX4N3xseUnEvNdDM797oGjDk54GlCZ6fD1a+ 1V3TZtP9830L6Pm8qKuvRsVqdGeqmC+J/89ncncILweHVP6iq+tkAoE9pWgph6541xo7 CT01xfW5u1uEOUPjw4Fon0zGCS5MJKwJl097+LGFdVhOdhQrfl7ifGjpmf8euO435AEX QhwK2hbLmP3W8JGjjyoJSX1N80lw7Th2SU1b6bBGa3Gm/H+7Zt2FyfOsNqFDb0tLGVqw IC43xXDslcSNLKYqEVd/eWoBMS2fqnkBteKcEmzn4Oi2U2MatqaiehaN9nGK5EqtRce7 Mr3A== MIME-Version: 1.0 Received: by 10.66.79.8 with SMTP id f8mr3262777pax.81.1342198500963; Fri, 13 Jul 2012 09:55:00 -0700 (PDT) Received: by 10.66.218.198 with HTTP; Fri, 13 Jul 2012 09:55:00 -0700 (PDT) In-Reply-To: References: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> Date: Fri, 13 Jul 2012 09:55:00 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=f46d042f9712de358804c4b8f03b X-Gm-Message-State: ALoCoQkTuveAxLoJhhljKtfxCXCITDOmfpexacJUO3FoAZcVhInHHxZVznAeHs9NyajT5ubdymyh Cc: manet , Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:54:30 -0000 --f46d042f9712de358804c4b8f03b Content-Type: text/plain; charset=ISO-8859-1 Chris, On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > This partly depends on what your planned document structure is, Ulrich > just mentioned the possibility of a generic 5444 document. I'm actually not > sure that wouldn't be more relevant, as it is hard to actually separate > these things. > My concern is, if you want to specify packet signing in the NHDP-sec document, that NHDP itself would never see the packet. The RFC5444 multiplexing would see a HELLO message in the packet and send it to NHDP (which can use the mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is tied to the RFC5444 parser itself, which would accept or reject the whole packet. So in my view, it would actually be much easier to separate it into an additional draft, rather than combining it with NHDP. Moreover, protocols that do not use NHDP but use RFC5444 would probably like to use packet ICV verification as well, but they don't need all the NHDP part. > **** > > ** ** > > But I think this is jumping in with solutions before considering a threat > model. Let's suppose that we have hardware that (a) stores key materials in > secure tamperproof storage, (b) doesn't make mistakes, and (c) we use a > signature method that's cryptographically infeasible to break. Then in this > case (not uniquely) packet signatures actually provide as much security as > message signatures. > If you assume a transitive trust model. If a router receives a TC message (unsigned) in a correctly signed packet, the receiving router can be sure that the TC has not been modified after transmission by the previous hop. It has no information what happened before that. But I agree that for certain deployments that may be enough. > Of course I can also think of threat models that do favour message > signatures. But this is exactly like the choice of signature methods, which > is not mandated because different threats require different solutions. > Right. I am absolutely in favor of specifying packet ICV handling. The only question for me is where to do that. > The same is true of packet and message signatures. Each (and indeed the > third option of both) should be allowed, we should not have a document that > prefers one above the other > Correct. > except following a security analysis - which is not on offer. > Yes. There was some emails about the nhdp-sec-threats document by Jiazi several months ago, but there was not much activity on the mailing list.. Do you think that that document should contain such an analysis? Best regards Ulrich > **** > > ** ** > > -- **** > > 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:* Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > *Sent:* 13 July 2012 13:36 > *To:* Dearlove, Christopher (UK) > *Cc:* Ulrich Herberg; manet > > *Subject:* Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt**** > > ** ** > > ** ** > > **** 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. > ***** > > Chris,**** > > ** ** > > I figured that you wouldn't agree.**** > > ** ** > > I agree, of course, with your observation that none of the signature > models yields end-to-end security, but I don't think that that's the issue > here. **** > > ** ** > > Personally, I do not see packet ICVs as being appropriate for neither NHDP > nor OLSRv2 - at least, not for the uses that I see/have, but I am not > saying that they do not exist. I could make an argument that a packet ICV > would have to be validated before knowing that a HELLO message was > delivered to an NHDP instance, and that the validation might be based on > different principles (or, even layers) for packet/messages. **** > > ** ** > > I see what you say about protecting packet sequence numbers by way of a > packet-level ICV, but I would argue that:**** > > ** ** > > o As packet sequence numbers are generated "outside" > NHDP, and are incremented for all **** > > packets (not just those with HELLOs), specifying > the validation of a packet-level ICV in NHDP would**** > > be inappropriate (as in: potentially conflicting > with another mechanism)**** > > ** ** > > o Whatever mechanism would provide "packet sequence > number statistics" to NHDP (such as the**** > > demultiplexer) would want to be the entity doing > that packet-level ICV validation, in part as**** > > I would _suspect_ that inability to validate a > packet-level ICV should cause the whole packet**** > > with all contained messages to be dropped.**** > > ** ** > > That said, with reference to the I-D, I think I speak for the authors when > saying that we're welcoming a suggestion that would address the issue that > you raise?**** > > ** ** > > Best,**** > > ** ** > > Thomas**** > > ** ** > > On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:**** > > > > **** > > I don't agree. Note that if all you are running is NHDP, then signing > packets is more secure than signing messages, as you get to cover the > packet sequence number as well.**** > > What I think is wrong is to suggest that the only correct way to protect > NHDP is to sign HELLO messages. Whether by inclusion or external reference, > signing packets should be also an option.**** > > **** > > I'll take that further to OLSrv2 as well. Now there signing messages vs > signing packets has advantages to the former. But signing packets also has > advantages of simplicity and covering packet header. It is incidentally not > correct to say that signing TC messages provides end to end security. It's > actually last-bit-one-from-end to end, and still relies on a form of > transitive trust. Packet based signatures rely on a greater degree of > transitive trust. There is a difference in threat models and > vulnerabilities, and that may matter, but it's not (unfortunately) as > simple as one being end to end and thus avoiding transitivity issues.**** > > **** > > --**** > > 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:* Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > *Sent:* 12 July 2012 23:09 > *To:* Ulrich Herberg > *Cc:* Dearlove, Christopher (UK); manet > *Subject:* Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt**** > > **** > > **** > > **** 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.***** > > I agree with Ulrich. **** > > **** > > Note that this is all about "messages" in as much as NHDP is concerned.*** > * > > **** > > 1) NHDP specifies something akin to "an implementation may recognize > additional reasons for considering a HELLO message invalid for processing"; > this I-D specifies such an additional reason, by way of a TLV in HELLO > messages.**** > > **** > > 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming > HELLO message post-demultiplication. Including the ICV Message TLV in HELLO > messages therefore makes sense.**** > > **** > > Ad 1), I note that this I-D is intended to exactly plug in at that place > in 6130.**** > > **** > > 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 12 Jul 2012, at 22:54, Ulrich Herberg wrote:**** > > The document specifies signing/verifying NHDP messages. RFC5444 packets > are not specific to NHDP, and therefore should IMO not be discussed in a > document entitled "Using Integrity Check Values and Timestamps For Router > Admittance in NHDP". That's why I suggested to handle this in an additional > document for RFC5444 packets. > > Regards > Ulrich**** > > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote:**** > > Hi Ulrich, > > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. > > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt > > Regards > Abdussalam > =======**** > > > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: > > Dear Chris, > > > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > > messages as well. I don't think that signing the packet is enough, since > > that does not provide end-to-end security. Instead, I suggest to submit a > > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, > and > > how to handle these messages in OLSRv2. > > > > However, I believe that it would be beneficial for certain applications > to > > also be able to sign/verify packets. But I don't think that the NHDP-sec > > document is the right place for this, since other applications (e.g. > DYMO) > > may not use HELLO messages at all, but would still like to sign/verify > > packets. > > Maybe it would be better to have an extra document "packet-sec" which > > specifies how to sign/verify packets? > > > > Best > > Ulrich > > > > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)**** > > > wrote: > >> > >> (Sending again, to sort out the formatting problem with the last > attempt.) > >> > >> As I read it, this draft is proposing using the RFC 6622 mechanism to > sign > >> HELLO messages. RFC 6622 actually allows for signing packets as well as > >> signing messages (both, either, or neither to be used as required). > There > >> isn't a major difference when considering HELLO messages, as few if any > >> packets will contain more than one HELLO message, and the packet and the > >> message will be signed by the same party. > >> > >> However NHDP doesn't exist in a vacuum, in particular it is used by > >> OLSRv2. Any security mechanism that is described in what will be an RFC > for > >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also > has > >> TC messages to consider, and they don't satisfy the points noted above > (on > >> number or on who signs them). And one option for OLSRv2 is to sign all > >> packets, not messages. This can be a sensible decision there, for > several > >> reasons, in some real circumstances. > >> > >> Consequently, I don't believe that this draft should describe only > signing > >> HELLO messages as the correct thing to do, that it should also allow > signing > >> packets as an equal status option. If someone wants to raise the > possibility > >> of signing (possibly by methods with different properties) both at the > >> message and packet level, that may have its use cases too. > >> > >> Incidentally, even within the limited framework of just NHDP, it is > >> possible that packets need protection. If an NHDP implementation > chooses to > >> use packet sequence number as part of its link quality mechanism, as it > may, > >> then an unprotected packet header is a vulnerability. > >> > >> (For the sake of completeness, RFC 6622 also allows address block > >> signatures. I don't have a reason to suggest using this within NHDP or > >> OLSRv2.) > >> > >> -- > >> 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**** > > >> > >> 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 > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Mobile Ad-hoc Networks > Working > >> Group of the IETF. > >> > >> Title : Using Integrity Check Values and Timestamps > For > >> Router Admittance in NHDP > >> Author(s) : Ulrich Herberg > >> Thomas Heide Clausen > >> Filename : draft-ietf-manet-nhdp-sec-02.txt > >> Pages : 12 > >> Date : 2012-05-29 > >> > >> This document specifies a security extension to the MANET > >> Neighborhood Discovery Protocol (NHDP). The extension introduces the > >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages > >> in order to provide a router admittance mechanism, and therefore to > >> counter 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-02.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-02.txt > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > >> > >> _______________________________________________ > >> manet mailing list**** > > >> manet at ietf.org**** > > >> https://www.ietf.org/mailman/listinfo/manet > >> > >> > >> ******************************************************************** > >> This email and any attachments are confidential to the intended > >> recipient and may also be privileged. If you are not the intended > >> recipient please delete it from your system and notify the sender. > >> You should not copy it or use it for any purpose nor disclose or > >> distribute its contents to any other person. > >> ******************************************************************** > >> > >**** > > **** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet**** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet**** > > ** ** > --f46d042f9712de358804c4b8f03b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chris,

On Fri, Jul 13, 2012 at 5:52 AM, D= earlove, Christopher (UK) <Chris.Dearlove@baesystems.com&g= t; wrote:

This partly depends on wh= at your planned document structure is, Ulrich just mentioned the possibilit= y of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these th= ings.


My concern is, if you wan= t to specify packet signing in the NHDP-sec document, that NHDP itself woul= d never see the packet. The RFC5444 multiplexing would see a HELLO message = in the packet and send it to NHDP (which can use the mechanisms specified i= n NHDP-sec to reject or accept the message). I think that a packet signer/v= erifier is tied to the RFC5444 parser itself, which would accept or reject = the whole packet. So in my view, it would actually be much easier to separa= te it into an additional draft, rather than combining it with NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably lik= e to use packet ICV verification as well, but they don't need all the N= HDP part.

=A0

=A0<= /p>

But I think this is jumpi= ng in with solutions before considering a threat model. Let's suppose t= hat we have hardware that (a) stores key materials in secure tamperproof storage, =A0(b) doesn't make mistakes, and (c) we use a si= gnature method that's cryptographically infeasible to break. Then in th= is case (not uniquely) packet signatures actually provide as much security = as message signatures.


If you assume a transitive trust model. I= f a router receives a TC message (unsigned) in a correctly signed packet, t= he receiving router can be sure that the TC has not been modified after tra= nsmission by the previous hop. It has no information what happened before t= hat. But I agree that for certain deployments that may be enough.
=A0

Of course I can also think of threat models that do favour message signatures. But this is exac= tly like the choice of signature methods, which is not mandated because dif= ferent threats require different solutions.


Right. I am absolutely in favor of specifying packet ICV handling.= The only question for me is where to do that.
=A0

The same is true of packet and message = signatures. Each (and indeed the third option of both) should be allowed, we should not have a document= that prefers one above the other

<= br>Correct.
=A0

except following a security analysis -= which is not on offer.


Yes. There was some emails about the nhdp= -sec-threats document by Jiazi several months ago, but there was not much a= ctivity on the mailing list.. Do you think that that document should contai= n such an analysis?

Best regards
Ulrich
=A0

=A0<= /p>

--

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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet


Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt=

=A0

=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Kee= p this in mind if you answer this message.
Ple= ase see this process on how to deal with suspicious emails.

Chris,

=A0

I figured that you wouldn't agree.=

=A0

I agree, of course, with your observation that none = of the signature models yields end-to-end security, but I don't think t= hat that's the issue here.=A0

=A0

Personally, I do not see packet ICVs as being approp= riate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/h= ave, but I am not saying that they do not exist. I could make an argument t= hat a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP ins= tance, and that the validation might be based on different principles (or, = even layers) for packet/messages.=A0

=A0

I see what you say about protecting packet sequence = numbers by way of a packet-level ICV, but I would argue that:=

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0=A0=A0=A0=A0=A0=A0=A0 As packet sequence numbers are generated "outside" NHDP, a= nd are incremented for all=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 packets (not just those with HELLOs), specifying the validation of a packet= -level ICV in NHDP would

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 be inappropriate (as in: potentially conflicting with another mechanism)=

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0=A0=A0=A0=A0=A0=A0=A0 Whatever mechanism would provide "packet sequence number statis= tics" to NHDP (such as the

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 demultiplexer) would want to be the entity doing that packet-level ICV vali= dation, in part as

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 I would _suspect_ that inability to validate a packet-level ICV should caus= e the whole packet

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 with all contained messages to be dropped.

=A0

That said, with reference to the I-D, I think I spea= k for the authors when saying that we're welcoming a suggestion that wo= uld address the issue that you raise?

=A0

Best,

=A0

Thomas

=A0

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (U= K) wrote:



I don't agree. Note t= hat if all you are running is NHDP, then signing packets is more secure tha= n signing messages, as you get to cover the packet sequence number as well.

What I think is wrong is = to suggest that the only correct way to protect NHDP is to sign HELLO messa= ges. Whether by inclusion or external reference, signing packets should be also an option.

=A0<= /p>

I'll take that furthe= r to OLSrv2 as well. Now there signing messages vs signing packets has adva= ntages to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct t= o say that signing TC messages provides end to end security. It's actua= lly last-bit-one-from-end to end, and still relies on a form of transitive = trust. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat m= odels and vulnerabilities, and that may matter, but it's not (unfortuna= tely) as simple as one being end to end and thus avoiding transitivity issu= es.

=A0<= /p>

--

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=A0|= =A0htt= p://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>

From:= =A0Thom= as Heide Clausen [mailto:thomas@thomasclausen.org]=A0
Sent:=A012 July 2012 23:09
To:=A0Ulrich Herberg
Cc:=A0Dearlove, Christopher (UK); manet
Subject:=A0Re: [manet] I-D Action: draft-ietf-manet-nhd= p-sec-02.txt

=A0

=A0

*** WARNING ***

This message originates from outside our organi= sation, either from an external partner or the internet.
Kee= p this in mind if you answer this message.
Ple= ase see=A0this process=A0on how to deal with suspicious emails.<= /span>

I agree with Ulrich.=A0

=A0

Note that this is all about "messages" in = as much as NHDP is concerned.

=A0

1) NHDP specifies something akin to "an impleme= ntation may recognize additional reasons for considering a HELLO message in= valid for processing"; this I-D specifies such an additional reason, b= y way of a TLV in HELLO messages.

=A0

2) NHDP "owns" HELLO messages, and therefo= re gets first dip on an incoming HELLO message post-demultiplication. Inclu= ding the ICV Message TLV in HELLO messages therefore makes sense.=

=A0

Ad 1), I note that this I-D is intended to exactly p= lug in at that place in 6130.

=A0

Thomas

=A0

--=A0

Thomas Heide Clausen




"Any simple problem can be made insoluble= if enough meetings are held to

=A0discuss it."

=A0 =A0-- Mitchell's Law of Committees=

=A0


On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:=

The document specifie= s signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP= , and therefore should IMO not be discussed in a document entitled "Us= ing Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle = this in an additional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB]=A0http://tools.ietf.org/id/draft-baryun= -manet-terminology-00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D


On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at=A0herberg.name> wr= ote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for = TC
> messages as well. I don't think that signing the packet is enough,= since
> that does not provide end-to-end security. Instead, I suggest to submi= t a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages,= and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain application= s to
> also be able to sign/verify packets. But I don't think that the NH= DP-sec
> document is the right place for this, since other applications (e.g. D= YMO)
> may not use HELLO messages at all, but would still like to sign/verify=
> packets.
> Maybe it would be better to have an extra document "packet-sec&qu= ot; which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)<= /u>

> <Chris.Dearlove at=A0baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last a= ttempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism= to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as we= ll as
>> signing messages (both, either, or neither to be used as required)= . There
>> isn't a major difference when considering HELLO messages, as f= ew if any
>> packets will contain more than one HELLO message, and the packet a= nd the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is us= ed by
>> OLSRv2. Any security mechanism that is described in what will be a= n RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLS= Rv2 also has
>> TC messages to consider, and they don't satisfy the points not= ed above (on
>> number or on who signs them). And one option for OLSRv2 is to sign= all
>> packets, not messages. This can be a sensible decision there, for = several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe = only signing
>> HELLO messages as the correct thing to do, that it should also all= ow signing
>> packets as an equal status option. If someone wants to raise the p= ossibility
>> of signing (possibly by methods with different properties) both at= the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it i= s
>> possible that packets need protection. If an NHDP implementation c= hooses to
>> use packet sequence number as part of its link quality mechanism, = as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block<= br> >> signatures. I don't have a reason to suggest using this within= NHDP or
>> OLSRv2.)
>>
>> --
>> 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.dearlove at=A0baesystems.com=A0|=A0h= ttp://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
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories. This draft is a work item of the Mobile Ad-hoc Networ= ks Working
>> Group of the IETF.
>>
>> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Integrity Check = Values and Timestamps For
>> Router Admittance in NHDP
>> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ulrich Herberg
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thomas Heide C= lausen
>> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-manet-nhdp-se= c-02.txt
>> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
>> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-29
>>
>> =A0 =A0This document specifies a security extension to the MANET >> =A0 =A0Neighborhood Discovery Protocol (NHDP). =A0The extension in= troduces the
>> =A0 =A0use of Integrity Check Values (ICVs) and Timestamps in HELL= O messages
>> =A0 =A0in order to provide a router admittance mechanism, and ther= efore to
>> =A0 =A0counter a selection of security threats to NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>>=A0http://www.ietf.org/interne= t-drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>>=A0ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>>=A0ftp://ftp.ietf.org/internet-= drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>>=A0https://datatracker.ietf.org/doc/dra= ft-ietf-manet-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list

>> manet at=A0ietf.org

>>=A0https://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<= br> >> 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.
>> ******************************************************************= **
>>
>

=A0

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

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

=A0


--f46d042f9712de358804c4b8f03b-- From abdussalambaryun@gmail.com Fri Jul 13 14:43: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 D20B921F8691 for ; Fri, 13 Jul 2012 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Cv7zPaKW3MJy for ; Fri, 13 Jul 2012 14:43:13 -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 1D5A521F867E for ; Fri, 13 Jul 2012 14:43:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2778073vbb.31 for ; Fri, 13 Jul 2012 14:43: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=fpECGrY0e8RTy4VA6Wh6ctipSdNA/7TINg5eD8oY9YU=; b=XCkJAQG1ksMifAP+S1nTZQ+bJ0a/47NnCFl17jGpm05FWvGAX8cBHQTVgx3h0WnO8O LvPosf0kZM31f731OOyldN0vr8NthghOLhKL+JWjs3KjRl6Y5qZgS+Q8pxuN8ozVefrx Yilqwc5RxX76bWRj/zVpcZUWLD9UBfOsnCnRAUwVso9bTnEUI+km1FRmko170v2jueD4 QFXjndSSlJKCs2ROSci+3/6aNO+ZgKY/WeMEK4nANDyPtE2F/iA5qvcmfabAxqnfrDVC uGlFwBQxJ7whKEI2Fa0e0B/UEQgVohFxsRhHYZpB2y6GL1Zn/nZA7HK6B4k8HvYve002 gGzA== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr1153209vdb.66.1342215824692; Fri, 13 Jul 2012 14:43:44 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 14:43:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jul 2012 23:43:44 +0200 Message-ID: From: Abdussalam Baryun To: "Cole, Robert G CIV USARMY CERDEC (US)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET management use cases (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 21:43:15 -0000 > Classification: UNCLASSIFIED > Caveats: NONE Hi Bob, I thank you for your reply and comment, I tried to reach you to know your opinion on this matter before, however, I taken the work to follow your opinion as your input in Nov. 2011 was that you wanted the layer 2 defined. Now your reply may want only the MANET use-case. I recommended the use case defined from 8 June [1], and I changed from defining L2 to considering the requirements [2], because of participants feedback. IMHO after I checked the WG feedback I noticed that consensus wanted defining L2 out of the MANET WG, therefore I directed my work to combined both matters use-case [1] and L2 considerations, without defining directly [2] (even my draft title changed), so that the purpose is informational for both designers and users. [1] http://www.ietf.org/mail-archive/web/manet/current/msg13022.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13049.html Best Regards, AB ======= On 7/13/12, Cole, Robert G CIV USARMY CERDEC (US) wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Abdussalam, > > In your reference, I was specifically referring to the development of a > management model for a radio subnet, which would be instantiated in, e.g., > a > MIB module. However, I believe that we can have meaningful discussions > about the use cases for management of MANET technologies, without such a > model of a radio. > > Thanks, > Bob > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: Thursday, July 12, 2012 2:53 PM > To: manet > Subject: Re: [manet] MANET management use cases > >>>Investigating examples can help to come up with a more abstract model of > different management and monitoring approaches. > > Please note that the presenter of [Radio, SatCom, and considerations] in 82 > meeting stated that it is not possible to define a manange model before > defining layer 2 subnet model, which I agreed from before [1] and worked on > the draft of MANET L2 subnets starting on 8 June [2]. > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12961.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13032.html > > AB > ====== > > On 7/6/12, Abdussalam Baryun wrote: >> Hi Ulrich, >> >> I thank you for this, I am happy that IESG have requested this. Mr. >> Cole in the meeting 82 had introduced the problem (please check his >> presentation), which I presented to the MANET. Yes we need in MANET to >> be focus on use-case, and how management is done. It is important that >> MANET documents interact with Internet drafts. >> >> I included Mr.Cole presentation (Nov.2011) in my I-D draft about >> MANET subnet technologies, and propose that any new I-D for management >> should take it into consideration. >> >> Abdussalam Baryun >> University of Glamorgan, UK >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > To: manet at ietf.org > Subject: [manet] MANET management use cases > From: Ulrich Herberg > Date: Thu, 5 Jul 2012 17:43:12 -0700 >>> Hi, >>> >>> we got a request (read: "DISCUSS") from Benoit Claise during NHDP-MIB >>> IESG evaluation to specify use cases how MANETs are monitored and >>> managed using SNMP. After discussion with Benoit and Adrian, we >>> agreed that such information would be useful, but that the MIB module >>> (as pure APIs) would likely be the wrong place. Moreover, the use >>> cases would not necessarily be specific to the NHDP-MIB, but concern >>> all MIB modules. Benoit requested that we come up with a new >>> informational draft in the WG, which discusses different MANET >>> management > use cases. >>> >>> Bob started working on collecting management and monitoring scenarios >>> from the military experience. I believe that it would also be >>> interesting to cover other use cases, such as in disaster recovery >>> (e.g., monitoring and management of routers thrown out of an airplane >>> over a disaster area) or in community networks (e.g., >>> FreiFunk/FunkFeuer networks in Europe). Investigating these examples >>> can help to come up with a more abstract model of different >>> management and monitoring approaches. It would be helpful if >>> participants in this WG with MANET deployment and >>> management/monitoring experience could contribute to such an effort. >>> >>> As a side note, there is a new mailing list about management of >>> constrained networks and devices (coma at ietf.org), which may be of >>> interest for some of the WG participants. >>> >>> Best regards >>> Ulrich >>> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > Classification: UNCLASSIFIED > Caveats: NONE > > > From abdussalambaryun@gmail.com Fri Jul 13 15:04: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 52D0111E80F2 for ; Fri, 13 Jul 2012 15:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 GbQ8ni67UibD for ; Fri, 13 Jul 2012 15:04:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4390E11E811B for ; Fri, 13 Jul 2012 15:04:24 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1002449vcb.31 for ; Fri, 13 Jul 2012 15:05:01 -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=wqps85MP/VEGEmdk27r25qhTXIZhHK19N3bs1EK5Li4=; b=vH0poIFes6JueI3Ty7KuipoqQNo2dRhKd4VhFQiR9E9KvxtfiFrZYWHrpHGAIxc7Sx 3XR/vYJxzfKN5Fk92j0HH5/5NAX5e7YBu0/3UnhCzqRNdFim4n7ydm2fQHITCEc/Zaa9 EcyM5TemsVFFoYIv7zWGVLe8PjinbnYOODBlhL7NKukYqObDPQ5yEEbhjEi2eVwnPq/2 bvLIKvRoUDGS1bhomnM/8fT9ONCk5OfSr0aPPksT2VifHUC7xbqujuxdm8S3cjA6knZV VvacUPevC72VUexoxJbARINySbbgvrEEqpvJz27AX04YAlb33n3q525CcQoT13RIsVrZ THBw== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr1216826vdb.10.1342217101128; Fri, 13 Jul 2012 15:05:01 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 15:05:01 -0700 (PDT) In-Reply-To: References: <1D2B6459-2780-420E-A04B-5AC7F8D57C81@thomasclausen.org> Date: Sat, 14 Jul 2012 00:05:01 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Thomas Heide Clausen Subject: Re: [manet] NHDP's Packet and Message X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Jul 2012 22:04:25 -0000 Hi Ulrich, Please note that I don't mind your approach in (so I am not against, but abstained), I presented my comments more to support another participant opinion and showing my preferance, but I will need to study the matter more further to see how I can use NHDP. Thanking you, Regards Abdussalam Baryun ================== On 7/13/12, Ulrich Herberg wrote: > I agree with Thomas. What you propose is a layer violation. It's like > sticking application payload in an IPv6 Extension Header or an L2 frame > header. > > Ulrich > > On Jul 13, 2012, at 3:35, Thomas Heide Clausen > wrote: > >> >> On Jul 13, 2012, at 12:03 , Abdussalam Baryun wrote: >> >>> Hi, >>> >>> AB>> It is about securing neighbor discovery, the draft: >>> manet-nhdp-sec-02 >>>> >>>> No. It is about securing a specific neighborhood discovery protocol - a >>>> protocol, whose signaling is carried in RFC5444 _messages_. >>>> >>> >>> NHDP was not designed for specific purpose of one proactive routing, >>> but for All MANET Routers. I agree that it specifies messages not >>> packets as Ulrich mentioned before, but there is no MUST in RFC6130 >>> that its signalling MUST be only messages, we need to consider the >>> specification's requirement language (MUST, SHOULD, MAY,..etc), there >>> is no restrictions, there is room for update :) >> >> No, that is wrong. RFC6130 specifies the use of RFC5444 messages. >> >> If you want to use smoke-signals, carved potatoes or something else not >> specified in RFC6130, then you're simply not using RFC6130. >> >> This has nothing to do with requirements language. >> >>>>>> 1) NHDP specifies something akin to "an implementation may recognize >>>>>> additional reasons for considering a HELLO message invalid for >>>>>> processing"; this I-D specifies such an additional reason, by way of >>>>>> a >>>>>> TLV in HELLO messages. >>>>>> >>>>> >>> AB>> yes it does in NHDP, but it does not restrict to messages only, >>>>> because it uses/understands [RFC5444] packets. >>>> >>>> Irrelevant. RFC6130 speaks of reasons for considering messages invalid. >>>> >>> >>> Why irrelevant? RFC6130 speaks of using [RFC5444] packets to carry >>> specified NHDP-messages. yes, also speaks of invalid NHDP-messages >>> please read: >>> >>> RFC6130> page 40> A router *MAY* recognize additional reasons for >>> identifying that a message is badly formed and therefore invalid for >>> processing. >>> >>> meaning> there may be a use of NHDP packet check as well >> >> For exactly the reasons I gave in the above. >> >> Plus, that for RFC6130 to use packet header content would constitute a >> layer violation (and a very badly designed system). >> >>> >>>>>> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an >>>>>> incoming HELLO message post-demultiplication. Including the ICV >>>>>> Message TLV in HELLO messages therefore makes sense. >>>>>> >>>>> >>>>> It may own/create the [5444] packet carrying the hello messages >>>>> >>>> >>>> No, it may not. See how demultiplexing of RFC5444 messages work, as well >>>> as >>>> what RFC6130 says for HELLO messages. >>>> >>> >>> Please provide me which page or sentence mentions your understanding >>> as: *MAY NOT* create 5444-packets. I will do your advise to look into >>> the RFC6130 again for demultiplexing of NHDP-messages, and will reply. >> >> I don't think that you understand RFC6130 or RFC5444 at all. >> >> RFC6130 generates RFC5444 messages, which are carried (as are all RFC5444 >> messages) in RFC5444 packets. >> >> A protocol generating something not specified in RFC6130 is not RFC6130. >> >> I do not know how it can be made more clear. >> >> Thomas >> >> >> >>> Thanking you, >>> Abdussalam Baryun, >>> ========================================== >>>>>> >>>>>> >>>>>> On 12 Jul 2012, at 22:54, Ulrich Herberg >>>>>> wrote: >>>>>> >>>>>> >>>>>> The document specifies signing/verifying NHDP messages. RFC5444 >>>>>> packets are not specific to NHDP, and therefore should IMO not be >>>>>> discussed in a document entitled "Using Integrity Check Values and >>>>>> Timestamps For Router Admittance in NHDP". That's why I suggested to >>>>>> handle this in an additional document for RFC5444 packets. >>>>>> >>>>>> Regards >>>>>> Ulrich >>>>>> >>>>>> >>>>>> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun >>>>> at gmail.com> wrote: >>>>>> >>>>>> Hi Ulrich, >>>>>> >>>>>> I am not expert in security issues, but IMHO, I agree with Chris to >>>>>> recommend to include in draft-02 both securing messages and packets >>>>>> (in general for packets), so the document should specify NHDP >>>>>> messages >>>>>> and MANET packets [AB]. The reasons are first, because NHDP is a >>>>>> MANET >>>>>> Interface protocol between neighbor routers. secondly it uses RFC5444 >>>>>> format that the future MANET routers will use. Third, NHDP uses >>>>>> RFC5444 which was specified for information exchange between MANET >>>>>> routers. >>>>>> >>>>>> [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >>>>>> >>>>>> Regards >>>>>> Abdussalam >>>>>> ======= >>>>>> >>>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Sat Jul 14 03:52: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 9934721F8711 for ; Sat, 14 Jul 2012 03:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 wxce3yrdgCUs for ; Sat, 14 Jul 2012 03:52:25 -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 8B5B621F86EE for ; Sat, 14 Jul 2012 03:52:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2983676vbb.31 for ; Sat, 14 Jul 2012 03:53:04 -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=BvmGmigxwYg/REn/rpYuW3BqXKwIf42x+yyoSqrZJcQ=; b=fZSmqlMFEKPb66tM6HSaqwm1hMlztw2+Sdj62RfiZ6guVCU29VNvfn7itakT5sfg4R tJYIopl9Qs8IDoRpyxsoQ+LqwtVxjiKCQLkNxBImqoYvuV3tqjkFF+2dW5IR4W/zgnvb lWKcrNtbdpmZoG0ygn1dX6S/aZ+F9ki2qKdUJpx0tX7wqNMc/qxhr6fcKUzotE5MnOgo iRzs4emm6VRp6jxu1+Fx9L659H+A/oExj5hBXIgVFzJIUsVm6oyqlvo2xFnOd2P3NbzK uIGbmok1dUHvJiNaXuAOusgFspXpcmPKZCUenOTUp6RKLjnmdqes6/a/z8rgQiooNOpt crAw== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr1872104vdi.86.1342263183746; Sat, 14 Jul 2012 03:53:03 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Sat, 14 Jul 2012 03:53:03 -0700 (PDT) Date: Sat, 14 Jul 2012 12:53:03 +0200 Message-ID: From: Abdussalam Baryun To: ulrich@herberg.name Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] NHDP Security Threats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 14 Jul 2012 10:52:26 -0000 Hi Ulrich, ------------------------------------------------------------------------------------------------------ Regarding NHDP security documents: [nhdp-threats] : , work in progress [nhdp-sec] : , work in progress ------------------------------------------------------------------------------------------------------ I RECOMMEND that the draft [nhdp-threats] includes [nhdp-sec] in its normative references and to include abstract information of discussions [1- 3] into [nhdp-threats] and/or [nhdp-sec]. [1] http://www.ietf.org/mail-archive/web/manet/current/msg12897.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg12935.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg13170.html Best Regards Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++ On 7/14/12, Abdussalam Baryun wrote: > Hi Ulrich, > > Please note that I don't mind your approach in (so I > am not against, but abstained), I presented my comments more to > support another participant opinion and showing my preferance, but I > will need to study the matter more further to see how I can use NHDP. > Thanking you, > > Regards > Abdussalam Baryun > ================== +++++++++++++++++++++++++++++++++++++++++++++++++++++ To: ietf at jiaziyi.com Subject: Re: [manet] On the scope of NHDP-sec-threats From: Abdussalam Baryun Date: Wed, 16 May 2012 13:59:31 +0200 > Hi > >>In the Paris IETF, we had lots of valuable comments on the nhdp-sec-threats >> >document, and it was adopted as wg document. >>In the discussion, the issue concerned most is the scope of the document: >> should >we include the common attacks for networks, and the interaction >> with protocols >using NHDP (OLSRv2, SMF, ...). > > In general, both common and interaction attacks need to be documented > per protocol, it is more useful to have the scope of protocol's > vulnerability without excluding common network attacks and issues. Any > additional attacks should be considered, otherwise the document scope > section should specify if it excludes something. > >>The current revision of the document also includes a section for the >> impacts on >protocols using NHDP. The rationale is that, as a neighbor >> discovery protocol, >NHDP is used in combination with other protocols most >> of the time. Therefore, the >document describes how the those protocols >> might be disrupted by the >misbehavior of NHDP (in common sense, such as >> MPR calculation, data sinkhole, >etc. ). If we are going to produce more >> threats documents in the future, there is no >need to worry about those >> common ones in NHDP (for example, we probably don't >want to discuss the >> threats in MPR selection in both SMF-threats and OLSRv2->threats). > > Maybe you mean only threats-documents that use NHDP, so they need to > refer to this NHDP-sec-threats document, but if a protocol is not > using NHDP, it is important that its threat document scope includes > all attacks/threats possibilities. > > Abdussalam Baryun > University of Glamorgan, UK. > From internet-drafts@ietf.org Sat Jul 14 17:12: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 2BFE621F85E4; Sat, 14 Jul 2012 17:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 thDh5U+rGb8a; Sat, 14 Jul 2012 17:12:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAFE21F85E6; Sat, 14 Jul 2012 17:12:55 -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.30p3 Message-ID: <20120715001255.30212.68577.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 17:12:55 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-15.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, 15 Jul 2012 00:12:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-15.txt Pages : 66 Date : 2012-07-14 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-15 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Sat Jul 21 06:31: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 B87D621F86D4 for ; Sat, 21 Jul 2012 06:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 D36bvsFf3-M5 for ; Sat, 21 Jul 2012 06:31:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D37221F86D1 for ; Sat, 21 Jul 2012 06:31:44 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3971467vcb.31 for ; Sat, 21 Jul 2012 06:32:43 -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=Iq3CpLGGUU2ilKUY5jxbrix0l/IyiGSHKEmJJ2B27Bc=; b=Hg07ZJavG6hfWQbzTELdyy2SShYSwddjSFFqyj9SeK3wDhEQYnndaYxEt3SAHoSngz xoDTbgzN3p9Bvz9Yma0qOJmsqbmaNFyw2HKtMWjhqnCXuFmtYiBhdZ+g39Kp6gl5VXbY 89Y5detfeZe/DPUSL01QV5wiBmld5FAnPVUXlNUnCwYxdmBXLDM5L9GEHOhBNXyDU31x vMdkOp/MClqWASI5/r5oqEwmduyNKBUqeCDTD9w04CFqUrbAg6HMc0yuzQi1zUUeQcIY UOOnZLeliYYgbigDCVYKuQP4j1V1d2RsMLXP+B7/R7iC/0JV3k9KbUW9noYB0/nlRlh+ 3HAg== MIME-Version: 1.0 Received: by 10.220.149.131 with SMTP id t3mr7343958vcv.1.1342877563592; Sat, 21 Jul 2012 06:32:43 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Sat, 21 Jul 2012 06:32:43 -0700 (PDT) Date: Sat, 21 Jul 2012 15:32:43 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 13:31:45 -0000 Hi I started working on a new draft to make some updates to the RFC5444, so manet-packets can be more used by AODVv2, DLEP, and other possible protocols. I will consider your input below of the discussions regarding 5444-packets, also in the past there was a request that there is a need for how to use 5444, so this draft may include as well, http://www.ietf.org/mail-archive/web/manet/current/msg13212.html http://www.ietf.org/mail-archive/web/manet/current/msg13105.html http://www.ietf.org/mail-archive/web/manet/current/msg12430.html If you have any comment or advise to this started work please reply, AB From abdussalambaryun@gmail.com Sun Jul 22 22:35: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 6984E21F84E1 for ; Sun, 22 Jul 2012 22:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 IsUUsus7YXWD for ; Sun, 22 Jul 2012 22:35:04 -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 B097411E8073 for ; Sun, 22 Jul 2012 22:35:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4749717vbb.31 for ; Sun, 22 Jul 2012 22:35:04 -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=CpY6C9niNpEK5YPdFScrjTODHi8pS+nY7dCZ8nAnEbc=; b=doEyoHvLVjKoTn+igCXLpMp0GaSOyR4oysW+lo9hckR8ElZmN5PPjX81hIzBr0eRQw wUyRf2+LSdOUEsah/zdHzB8cnp3I9r9x8TJSHHedbTYISvV39lutr+IaiL8jRI+DsFVk rDcY2de0d3v3RAQEyd5NIyvdAw6EEL31gS1NV+9kbT8g9mGRfCIMP1vxuByynv/Vjo/0 7e3x4S+zhWyMqJp+RLniomZBKhA7Pk6loN9Ock9aQ1t3TCAvexziIz2RwR/QfNkbzXJf xB3dG8HogRtN2/Y19f8zowAqYmqLZLxUUDdLaMAwW4Le33zGBs1ulzZc4+K076cfTscZ upXQ== MIME-Version: 1.0 Received: by 10.220.152.67 with SMTP id f3mr1005676vcw.19.1343021704110; Sun, 22 Jul 2012 22:35:04 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Sun, 22 Jul 2012 22:35:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jul 2012 07:35:03 +0200 Message-ID: From: Abdussalam Baryun To: corson , "jpmacker@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Propose update RFC2501 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 05:35:06 -0000 Dear Scott and Joseph, The authors of RFC2501 I would need your feedback if possible on the below message and the proposal. Your input comment will help in the discussion and the future ideas/direction. Thanking you, Regards Abdussalam Baryun =============== To: manet Subject: [manet] Propose update RFC2501 From: Abdussalam Baryun Date: Wed, 4 Jul 2012 22:11:12 +0200 Hi All, I want to propose draft-ietf work to be done on update the RFC2501, which I don't mind doing, on the following issues: 1- to include all active MANET routing RFCs as describing its network characteristics and its network context applicability, as mentioned by section-6. 2- to include the RFC5444 characteristics, or benefits to MANET performance. 3- to include NHDP RFC6130. 4- IPv6 considerations 5- Add more information in characteristic section on issue of reliability and scalability. RFC2501> 3. Characteristics of MANETs MANETs have several salient characteristics: AB>Add> 5) issue of variable E2E delay and node disconnecting from MANET. AB> suggest> to consider LLN 2501> 5. IP-Layer Mobile Routing AB> interfaces as physical layer technology, what about interfaces as logical? in some other parts we read wireless interface 2501> 5>Future interoperability may be achieved using mechanisms other than mobile IP. AB> Are we there, could we answer to add some? 2501>5>Supporting these features appears only to require identifying host and router interfaces with IP addresses, identifying a router with a separate Router ID, and permitting routers to have multiple wired and wireless interfaces. AB> replace "host and router" with " router" as it was done in DYMO and OLSRv2 2501> 4) Proactive operation: The flip-side of demand-based operation. AB> not clear 2501> Section 6.7, Duplex link and bidirectional link AB> why we use *duplex* with *link*, duplex is related to the interface system more than the link, so I recommend only using *bidirectional-link* and replace duplex-link. 2501> The following is a list of quantitative metrics that can be used to assess the performance of any routing protocol. AB> add examples of new metric used in industry or by active manet protocols 2501> 7. Security Considerations AB> Needs to be amended to consider new techniques The purpose of the proposed update, is first because RFC2501 is a reference to many new RFCs and that updates directs progress designs. Please note that I will not do this work until most active participant agree, thanking you, Best Regards Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/21/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > I didn't see what part of RFC 2501 needed to be revised. > Do you have a specific proposal? I think that, before you > could expect any discussion on revising that document, > you would have to point out what part or parts need > work. > > Regards, > Charlie P. > > On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>> Could we Update RFC2501? >> I see that RFC2501 some how defines MANET technologies, which will be >> a good reference in the draft I am writting of L2 subnets, but maybe >> RFC2501 is enough for the protocols, and no need for a new draft. >> However, that will depend on the WG discussion and decision :) >> >> I got no answer of the question so far, therefore, I will propose it >> to be discussed in the next meeting IETF 84. >> >> AB >> ===================================================== >> On 6/6/12, Abdussalam Baryun wrote: >>> Hi Folks, >>> >>> the RFC2501 is the best RFC I read and I like it because it is easy to >>> read, understandable, and covers solid issues of MANET. I hope the >>> authors give us a feedback if they want to make new one as Version 2. >>> >>> I see that it is old (1999), and it may be interesting to update it >>> some how, I hope the authors can update its issues and evaluation, now >>> we got new RFCs and industries have new needs than 90s, it does not >>> cover different devices constraints as sensors and LLNs, and IPv6, >>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>> getting renew versions. >>> >>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>> to update RFC2501 as well, it will only take few days or a month, to >>> draft and submit so why leave it old-documents with old >>> considerations? Please advise, >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>> ========================================================= >>> >> _______________________________________________ >> manet mailing list >> manet at ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Sun Jul 22 23:59: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 25FCA21F84A0 for ; Sun, 22 Jul 2012 23:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=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 9eN7f8NOjj4k for ; Sun, 22 Jul 2012 23:59:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B176E21F84BD for ; Sun, 22 Jul 2012 23:58:59 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4767546vcb.31 for ; Sun, 22 Jul 2012 23:58: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:content-transfer-encoding; bh=z1A73uZ/emLaJLzIXX9ZSvWYtdis/WYx2363dgUwmYo=; b=vplo5o94QIB2yTYCCdlf/zCn/KsaGNGRF8dXdguddBU0/+Wb4IQuj7P3Ta+kdWMNAv G16MftX+CKLKwV/gaLsi/eyqgdXs2gYZpPYhL5MeAdxaD1G6UwFwz9nAah5bPyXsCCwf 4ki/i60x1aBcZVfsd+afPxlZvFf4+MIsUXuqEQYT7PrnP+XGi+/5Tx8gJSvHUhR+42DY xWiRNUIx6qq1SdomCdtdSu/6gbkUK25BDDFp9CQsKaw3FgI/FNsw6L+iy5JSQ4ve8x6S zObKs/iNKnAfJ3J8yjMgejCOzWNRxmNC6JWirwPV8k4ns1j5y0kwJVfRqNTUy0FQhF+s SaOA== MIME-Version: 1.0 Received: by 10.52.71.79 with SMTP id s15mr9925143vdu.86.1343026739065; Sun, 22 Jul 2012 23:58:59 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Sun, 22 Jul 2012 23:58:58 -0700 (PDT) In-Reply-To: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> Date: Mon, 23 Jul 2012 08:58:58 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Thomas Heide Clausen Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 06:59:02 -0000 Hi Comment inline below: On 7/6/12, Thomas Heide Clausen wrote: > I do not see the need for this terminology document in MANET: > > o The RFCs published by the WG all do a good job of defining their prope= r > terminology and conventions in the sections, aptly named to this > effect -- and something which both the WG and the IESG has been very > vigilant in ensuring. Agree > > o Extracting this terminology, to present without the context of the RFC= in > > which they are introduced and used, is both futile and a source > of errors and confusion. It is not extracting any thing it is locating information in easy location to be reached efficiently by researchers, or other WG participants. In another reason, for example the RFC5444 and RFC6130 is providing a MANET standard, while any RFC in this WG is specifying its own terminology and message format, but the reason was to bring RFCs to have similar formating functions. The terminology RFCs in many WGs does the same. RFC2501 is doing a good job to bring understanding of MANET which the terminology informational RFCs are doing in each concept/group-charter. > > o The domain evolves, new protocols appear and introduce new concepts, > terms. This is captured by carefully defining such in the RFC specifyin= g > that protocol. Any terminology document (aside from all its other issue= s, > indicated in this list) would likely be obsolete and incomplete before > the > ink with which it was written was dry. So when new concepts appear any WG needs to prepare updates I-D to their information/standards/experiments so that knowledge is consistent and concepts are updated as will (including terminology document can be updated). Please note that our documents in MANET are a source of information to any participant in IETF, so we need to focus to not only produce new concepts/work but we see into update/obsolete previous work if possible/necessary. other wise why did the IETF make an option possibility to *update* and *obsolete* if they are not needed for WGs. > > o All RFCs in MANET uses no more than a small subset of the total MANET > (and Internet) terminology. A collective terminology document would, > therefore, necessarily be adding entropy to any single RFC and to the > WG (and to implementers of the WG protocols). Please note that the bigest reason of terminology is that when WG participants discuss things they don't misunderstand. Please note there are many times in MANET WG there are misunderstood in technical terms (I have references on the list to many incidence if you ask), so if experts have this problem we need to solve it by a RFC document, also we need to give the protocol user a sense of the general/specific terminology (as we have MANET general format, MANET general understanding, MANET general direction). > > o Certainly, a large number of terms in this document are entirely out o= f > scope > (such as those pertaining to non-MANET developed concepts or protocols, > e.g., those developed in other parts of the IETF), are useless for the = WG > (such as, but not exclusively, "communication channel" and "communicati= on > > medium"), are by nature ambiguous (such as, but not exclusively, "Upper > Layer" > and "Node"), carry a legacy that renders them difficult to use (such as= , > but > not exclusively, "Logical (virtual) Link", "Physical Link", and "Link")= . > I disagree that thoes terms are out of scope of the I-D of the MANETs context terminology, because those terms you mentioned were used in one/some MANET RFCs, so they need to be explained to bring all terms together to make overall knowledge to internet community. Your argument is right only if we are not specifying network-protocols, so because we are doing a type of network, then our documents for it SHOULD be *connected* by some combined meaning/knowledge *words*, so other (i.e. all internet community) can understand, without any possibility of misunderstanding (there are many examples I can give if you want). I thank you for your comments, and I will prepare a new version for the I-D= , Best Regards Abdussalam Baryun =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>> >>>> Dear All >>>> >>>> I completed the first version of draft on terminology and submited the >>>> draft yesterday (with getting some techniq problem), but needed to >>>> post to know the community feedback and advise. There are other terms >>>> that was not yet included which will need some advise from you. >>>> Thanking you, >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> Abbreviations Used in The submitted Document >>>> >>>> AH Authentication Header >>>> DAD Duplicate Address Detection >>>> DPD Duplicate Packet Detection >>>> DoS Denial of Service >>>> ESP Encapsulating Security Payload >>>> IP IPv4 or IPv6 >>>> ICMP Internet Control Message Protocol >>>> IIB Interface Information Base >>>> ETX Estimated Expected number of Transmission >>>> FIB Forwarding Information Base >>>> LQI Link Quality Indicator >>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>> LLN Low power and Lossy Network >>>> MAC Mediam Access Control >>>> MIB Management Information Base >>>> MTU Maximum Transmission Unit >>>> NBMA Non-Broadcast Multi-Access link >>>> NHDP Neighborhood Discovery Protocol >>>> ND IP Neighbor Discovery >>>> OSPF Open Shortest Path First >>>> RIB Routing Information Base >>>> SMF Simplified Multicast Forwarding >>>> TCP Transmission Control Protocol >>>> UDP User Datagram Protocol >>>> >>>> 2.3 Definitions for MANET Terms >>>> >>>> 2.3.1 Terms Definition of MANET Communication: >>>> >>>> Communications=92 Technology or Facility: >>>> The means employed by two or more devices/subsystems to transfer >>>> and/or receive information between them in one way or two way >>>> communication. MANET communications often uses the wireless >>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>> space, air, water, antenna, coaxial cables, etc.) >>>> >>>> Communication Medium: >>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>> satellite system, etc.) that the routing device uses to communicates >>>> through the transmission medium(s), by providing connectionless and/o= r >>>> connection services that MAY be established. The system medium >>>> includes MAC layer and MAY include the physical Layer. >>>> >>>> Communication Channel: >>>> A subdivision of the physical communication medium (i.e. radio carrier >>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>> independent uses of the medium. Channels may be made available by >>>> subdividing the medium into; distinct time slots, distinct spectral >>>> bands, or coding sequence, etc. >>>> >>>> MANET Protocol: >>>> The communication system/subsystem that operates and maintains the >>>> ad hoc communication technology or facility within MANET. MANET routin= g >>>> Protocols often apply distributed algorithms/techniques to disseminate >>>> or forward routing messages within a MANET routing domain. >>>> >>>> Topology: >>>> An abstract representation of a network (physical or logical), as a >>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>> that >>>> communicate through set of links (E), where the G =3D (V, E). >>>> >>>> Physical-level Topology: >>>> A topology of the communication medium networks consists of routing >>>> devices and physical links. This topology information is updated by >>>> devices=92 technology in the L2 information Base. >>>> >>>> Network-level Topology: >>>> A topology of the communication system networks consists of routers an= d >>>> links. This topology information is updated by routers in its RIB. >>>> >>>> Multihop MANET: >>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach the >>>> destination. >>>> >>>> Reactive Routing: >>>> An on-demand based routing protocol that operates route discover and >>>> maintainance the route(s), to reach the demanded destination(s). >>>> >>>> Proactive Routing: >>>> A topology RIB based routing protocol that operates routes and >>>> maintains >>>> the network topology, to reach its known destination(s). Each router >>>> maintains routes to all reachable destinations at all times, whether o= r >>>> not there is currently any demand to deliver packets to those >>>> destinations. >>>> >>>> Upper Layer: >>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>> >>>> MANET Domain: TBD >>>> >>>> MANET Signaling: >>>> Sending and exchanging some MANET messages/information. >>>> >>>> 2.3.2 Terms Definition of MANET Elements >>>> >>>> Node: >>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>> MANET signaling. It either runs a MANET routing protocol or participat= e >>>> in MANET signaling. >>>> >>>> Router: >>>> A MANET node that MUST implement a MANET routing protocol and forwards >>>> IP packets not explicitly addressed to itself. >>>> >>>> Host: >>>> A node that is not a router. All destinations in MANET that receive >>>> delivered data are hosts. >>>> >>>> Link: >>>> A link between two node interfaces. This link may be Logical >>>> (i.e. virtual) link or physical link. Logical links are between two >>>> logical interfaces and physical links are between two physical >>>> interfaces. Links are either unidirectional or bidirectional >>>> (links may be on-link and off-link: see RFC4861). >>>> >>>> >>>> Physical Link: >>>> a communication facility or medium over which the nodes can >>>> communicate at the link layer, i.e., the layer immediately below >>>> IP. Physical interfaces are the nodes=92 attachment to physical links. >>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>> and shared-media, etc (see link types in ND [RFC4861]). >>>> >>>> Logical (virtual) Link: >>>> a communication facility (at L3, or upper-layer) over which nodes can >>>> communicate. This logical link is between two MANET interfaces exists >>>> if either can be heard by the other. >>>> >>>> Link MTU: >>>> the maximum transmission unit (i.e. maximum unit size in octets), that >>>> can be conveyed in one transmission unit over the link. >>>> >>>> >>>> Node Interface: >>>> A node's point of attachment to a link. Each node MUST have at least >>>> one >>>> interface that SHOULD be assigned an IP address. If there is/are more >>>> than one interface(s) per node then the additional interface(s) MAY be >>>> assigned an IP address. If an interface is not assigned to an IP >>>> address >>>> it MUST be identified by the MANET routing protocol. An interface MAY >>>> be >>>> assigned one or more addresses. >>>> >>>> MANET Interface: >>>> A node interface that participate in; exchange MANET information used >>>> in >>>> MANET routing or exchange information in MANET neighbor node discovery >>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned >>>> to >>>> least one address to communicate. A router interface MUST be >>>> assigned a routable address which is the main address for the >>>> interface. >>>> >>>> >>>> 2.3.3 Terms Definition of MANET Identifications: >>>> >>>> An interface MAY be assigned one or more addresses. If the interface i= s >>>> a logical interface it MAY be assigned to only logical addresses, but >>>> if >>>> it is a physical interface MAY be assigned with physical address >>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>> MANET addresses). >>>> >>>> >>>> MANET Address >>>> A MANET-subnet, node, or interface address. Node and interface >>>> addresses >>>> are either IP addresses or RFC5444 addresses. All subnet addresses are >>>> unicast IP addresses. >>>> >>>> Address Block and TLV: as specified in RFC5444 >>>> >>>> Routable address: >>>> A subnet address which can be a destination address. A router MUST be >>>> able to distinguish a routable address from a non-routable address. >>>> Broadcast, and multicast addresses, limited in scope to less than the >>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>> addresses MAY be considered as routable addresses. >>>> >>>> Main address >>>> A routable address (MANET address) that is assigned to one router's >>>> MANET interface. >>>> >>>> Originator address: >>>> A node address of the node that originated a MANET message (this >>>> message >>>> MUST include the originator address). It MAY be a routable or an >>>> unroutable address. >>>> >>>> subnet prefix >>>> A bit string that consists of some number of initial bits of an IP >>>> address. >>>> >>>> Interface identifier >>>> the remaining low-order bits in the node's IP address after the subnet >>>> prefix. A number used to identify a node's interface on a link. >>>> >>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>> >>>> Packet: >>>> A MANET packet of a header plus payload. These packets are either >>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>> in IP packet. Packets are generated by nodes to be sent to >>>> destination(s) through MANET or through the Internet. RFC5444 packets >>>> information MAY not be used only by MANET routers. >>>> >>>> Message: >>>> A MANET data message or routing control message. Routing control >>>> messages are either MANET routing protocol messages or/and RFC5444 >>>> messages. >>>> >>>> Type Length Value coding (TLV): >>>> A generic way to represent MANET information (as in [RFC5444] and >>>> [RFC5497]). >>>> >>>> Frame: >>>> A L2 protocol TLV with a header and payload. In some technologies the >>>> L2 >>>> operates a MANET routing protocol as a local area networking system. >>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>> telecommunication network. >>>> >>>> Route Request Message (RREQ) >>>> A message is used to discover a valid route to a particular >>>> destination address, called the RREQ Target Node. When a router >>>> processes a RREQ it learns routing information on how to Originator >>>> Node. >>>> >>>> Route Reply Message (RREP) >>>> A message is used to disseminate routing information about >>>> the RREP Target Node to the RREQ Originator Node and the intermediate >>>> routers. >>>> >>>> Route Error Message (RERR) >>>> A message is used to disseminate the information that a route is >>>> not available for one or more particular addresses. A RERR message is >>>> used to indicate that a router does not have a forwarding route >>>> to one or more particular addresses. >>>> >>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>> >>>> Hop-by-hop Routing: (TBD) >>>> A dynamic routing that routes to destination by routing table. >>>> >>>> Source Routing: (TBD) >>>> A dynamic routing that its route path is provided in the IP packet. >>>> >>>> Route Discovery: TBD >>>> >>>> Route Maintenance: TBD >>>> >>>> Neighbor discovery: (TBD) >>>> A node discovers neighbors only if the node receives from it's >>>> neighbors. >>>> >>>> >>>> Multipoint relay (MPR): (TBD) >>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>> its selection of router X1 as an MPR in a recent HELLO message. >>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>> participate in the flooding process of messages received from >>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>> declare link-state information for the link from X1 to Y1. It may >>>> also be both at the same time. >>>> >>>> MPR selector: >>>> A router, Y, is a flooding/routing MPR selector of router X if >>>> router Y has selected router X as a flooding/routing MPR. >>>> >>>> Router Parameters: >>>> boolean or numerical values, specified for each router, and not >>>> specific to an interface. A router MAY change router parameter >>>> values at any time, subject to some MANET constraints. >>>> >>>> MANET Routing Metric: >>>> A MANET routing cost that is governed by specific rules and properties >>>> defined by the MANET routing protocol which captures specific link or >>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>> LQI, >>>> etc. >>>> >>>> Distance Vector Metric >>>> A metric class related to rules of the MANET interface and MANET path >>>> distance. The metric can be calculated by the distance vector routing >>>> algorithm class used by the MANET routing protocol. A metric of the >>>> distance a message or piece of information has traversed. The minimum >>>> value of distance is the number of IP hops traversed. >>>> >>>> Link State Metric >>>> A metric type related to the MANET network-topology status and logical >>>> links' states. This metric is calculated by the link state routing >>>> algorithm class used by the MANET routing protocol. A metric type mayb= e >>>> EXT, LQL, etc. >>>> >>>> Link Metric: TBD >>>> >>>> Neighbor Metric: TBD >>>> >>>> Path accumulated: >>>> The RREQ message accumulates intermediate routers that are in path to >>>> destination(s). >>>> >>>> Protocol Sequence Number: >>>> A Sequence Number related to a MANET protocol that maintained by each >>>> protocol subsystem process. This sequence number is used by other >>>> subsystems to identify the temporal order of protocol information >>>> generated. >>>> >>>> Router Sequence Number: >>>> A router sequence number is maintained by each router process. The >>>> sequence number is used by other routers to identify the temporal >>>> order of routing information generated and ensure loop-free routes. >>>> >>>> MANET Information Base: >>>> A collection of information (in Table or Cache structure) maintained >>>> by MANET protocols and which is to be made available to MANET routing >>>> protocols. An Information Base may be associated with a MANET router >>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB)= . >>>> >>>> RIB Entry: >>>> The RIB entry is a conceptual data structure. Implementations may use >>>> any internal representation that conforms to the semantics of a route >>>> as specified in the router specification. >>>> >>>> 3. IP Considerations and Terminology >>>> >>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>> run/implement at least one MANET routing protocol. The >>>> terminologies described in this document can be used for >>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>> >>>> IP address: >>>> IPv4 addresses or IPv6 addresses. >>>> >>>> IP Packet: >>>> The packet header plus payload as specified in [RFC791] and [RFC2460] >>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >>>> specified by RFC5498. >>>> >>>> Mobile IP considerations: >>>> Mobile IP terms are provided in [RFC6275], and this technology >>>> assists nodes while connected through the Internet domain(s). MANET >>>> is an infrastructure-less network that is able to communicate with >>>> the Internet (i.e. an IP infrastructure network). >>>> >>>> 4. Security Consideration and Terminology >>>> >>>> It is RECOMMENDED that MANET routing protocols consider security >>>> issues because the MANET's transmission medium is wireless which make >>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>> routing information while traversing the MANET MAY be used by an >>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>> >>>> The following are some terminology related to MANET threats and >>>> security. >>>> >>>> Attacker: A node, present in the network and which intentionally seeks >>>> to compromise information based in MANET router(s). The Attacker MAY b= e >>>> a compromised MANET router if obtained MANET identity or routing >>>> information. >>>> >>>> Compromised MANET Router: An attacker router, present in MANET and >>>> which generates syntactically correct routing control messages. Contro= l >>>> messages emitted by compromised router(s) may contain additional >>>> information, or omit information, as compared to a control message >>>> generated by a non-compromised router located in the same MANET >>>> topological position. >>>> >>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>> MANET Router. >>>> >>>> Jamming Attack: >>>> The attacker transmits massive amounts of interfering radio traffic, >>>> which will prevent legitimate traffic (e.g., routing and data traffic) >>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>> influencing Legitimate MANET Router to transmit unnecessary >>>> information. >>>> >>>> Eavesdropping: >>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>> information or the transmitted data information from its neighbor's >>>> transmitted radio packet. Attacker=92s processes MANY be used by attac= ker >>>> to mislead routing. Eavesdropping does not pose a direct threat to the >>>> MANET or to its routing. >>>> >>>> Identity Spoofing: >>>> Attacker sends routing messages, pretending to have the MANET identity >>>> of another node. >>>> >>>> Link Spoofing: >>>> Compromised MANET router sends routing messages to neighbor node(s) >>>> providing incorrect set of link information. >>>> >>>> Replay Attack: >>>> A Compromised router in one MANET region records control traffic >>>> information and replays the recorded information in a different MANET >>>> region (this type of attack is also called the Wormhole attack). >>>> >>>> Broadcast Storm: >>>> Compromised MANET router may attack the MANET by attempting to change >>>> the MANET flooding algorithm(s) to increase routing overheads or/and t= o >>>> increase the route discovery delay. Broadcast storm degrades the data >>>> traffic delivery and MANET performance. >>>> >>>> Falsification in MANET: >>>> The compromised MANET router sends false routing information into >>>> MANET. >>>> False routing information received in MANET, MAY create unrealistic >>>> information bases. >>>> >>>> ICMP Attacks: >>>> The generation of ICMPv6 error messages may be used by compromised >>>> MANET >>>> router to attempt DoS attacks by sending an error-causing source >>>> routing >>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>> the >>>> upper-layer processes, it is possible to perform attacks on the upper >>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>> RECOMMENDED to perform some form of validation to ICMP messages (using >>>> the information contained in the payload of the ICMP message) before >>>> acting upon them. >>>> >>>> Source Routing Attacks: TBD >>>> >>>> Acknowledgments: >>>> >>>> This work has used/modified terms of the following documents: RFC2462, >>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>> Gratefully acknowledge to the IETF community and all contributions. >>>> >>>> Reference: >>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>> NHDP", Work in progress, March, 2012. >>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>> Networks", John Wiley & Sons, March 2007. >>>> ISBN: 978-0-471-75688-0. >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> I hope to get some advise from the Internet community to make the >>>> definitions more suitable/accurate, because I MAY misunderstood. >>>> Thanking you, >>>> >>>> Best Regards >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From rick.taylor@cassidian.com Mon Jul 23 02:16: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 4C81121F8681 for ; Mon, 23 Jul 2012 02:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 RpBmOzySlRmD for ; Mon, 23 Jul 2012 02:16:57 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 67B4F21F86D0 for ; Mon, 23 Jul 2012 02:16:53 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 23 Jul 2012 11:16: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); Mon, 23 Jul 2012 11:16: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); Mon, 23 Jul 2012 11:16: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); Mon, 23 Jul 2012 11:16:45 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 10:16: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: Mon, 23 Jul 2012 10:16:44 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Start work: update draft for RFC5444-Packets Thread-Index: Ac1nRVEzMuHwaCOfSAK5+3IAXIHhBwBbSaUg References: From: "Rick Taylor" To: "Abdussalam Baryun" , "manet" X-OriginalArrivalTime: 23 Jul 2012 09:16:09.0965 (UTC) FILETIME=[CC4D11D0:01CD68B3] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19058.006 X-TM-AS-Result: No--18.357900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 09:16:58 -0000 Hi Abdussalam, I would recommend that you be very careful about attempting to adapt/extend RFC5444, particularly with respect to DLEP, because it is still open to debate whether any future DLEP draft will use RFC5444 for its packet format, and I believe the authors are leaning away from it. Also, there has been a lot of comment on this mailing list about not updating RFC5444 yet as there appears little consensus about the actual failings of the format w.r.t applicable protocols, i.e. all the 'complaints' about the format appear to be short-comings in the consuming protocols, not the packetBB format itself. Can you perhaps outline what you see as the failings of RFC5444 here before you produce a lengthy document, in order to gather some quick peer-review comments, as many on this list struggle to find time to digest long formal drafts, and I wouldn't want you to suffer from TL;DR ('too-long; didn't-read'). Rick Taylor Cassidian Systems > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 21 July 2012 14:33 > To: manet > Subject: [manet] Start work: update draft for RFC5444-Packets >=20 > Hi >=20 > I started working on a new draft to make some updates to the RFC5444, > so manet-packets can be more used by AODVv2, DLEP, and other possible > protocols. >=20 > I will consider your input below of the discussions regarding > 5444-packets, also in the past there was a request that there is a > need for how to use 5444, so this draft may include as well, >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13212.html > http://www.ietf.org/mail-archive/web/manet/current/msg13105.html > http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >=20 > If you have any comment or advise to this started work please reply, >=20 > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Jul 23 03:03: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 92F0021F86B0 for ; Mon, 23 Jul 2012 03:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_22=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 tuWjc5bO2174 for ; Mon, 23 Jul 2012 03:03:04 -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 ACB7521F84F6 for ; Mon, 23 Jul 2012 03:03:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4931778vbb.31 for ; Mon, 23 Jul 2012 03:03:04 -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=uvLXyoGBGT8xMOIqgm8HoUfboOS4l5Lxt9qSvZF++mU=; b=b72vcWVlc2GRVpAPYiBHKmUs4k2ZGaW/G49hiRAp0EsI/o7NEdOJuU8afODijNjnIb MkXDeorEEpesrTEOzYN7UDPJD2ZTCuEDhvLndc0EfNuFf/efh+Hokfg/v61YuMCBmww4 ZB9IH46Zf5tvVHARarrws+Uk1ACJGvpAlO04fu/iGkSPFbGUd6ZFch8wl8RzpC8TdWVC alOJdYLjsPYAw4YgeDtXSqhLd+2fiDUSzwyvYU5mv0OJpF4jhnm5KIpgbDQwWeITM6vK NggSxW5dTivTmWvzPsClyB+0+qdIRjl2CbCCSgYdCgVf2fb3KJ9vHfWbtx+TONaIWTdB N1zw== MIME-Version: 1.0 Received: by 10.220.152.67 with SMTP id f3mr1511689vcw.19.1343037784032; Mon, 23 Jul 2012 03:03:04 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Mon, 23 Jul 2012 03:03:03 -0700 (PDT) In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> Date: Mon, 23 Jul 2012 12:03:03 +0200 Message-ID: From: Abdussalam Baryun To: Rick Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 10:03:05 -0000 Hi Rick, I thank you for your comments, but I mentioned references to the reason why I am updating. Regarding DLEP, I was one of the first participants to oppose that it uses RFC5444 (the document is for routers formats), but I am with the idea of having similar format for MANET R2RIs, which can be added as a section in this new I-D I am working on. The aim of this work is routers first, then optional related protocols like DLEP or other R2RI. However, I will send shortly an outline as you requested. Regards Abdussalam ============== On 7/23/12, Rick Taylor wrote: > Hi Abdussalam, > > I would recommend that you be very careful about attempting to > adapt/extend RFC5444, particularly with respect to DLEP, because it is > still open to debate whether any future DLEP draft will use RFC5444 for > its packet format, and I believe the authors are leaning away from it. > > Also, there has been a lot of comment on this mailing list about not > updating RFC5444 yet as there appears little consensus about the actual > failings of the format w.r.t applicable protocols, i.e. all the > 'complaints' about the format appear to be short-comings in the > consuming protocols, not the packetBB format itself. > > Can you perhaps outline what you see as the failings of RFC5444 here > before you produce a lengthy document, in order to gather some quick > peer-review comments, as many on this list struggle to find time to > digest long formal drafts, and I wouldn't want you to suffer from TL;DR > ('too-long; didn't-read'). > > Rick Taylor > Cassidian Systems > >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of >> Abdussalam Baryun >> Sent: 21 July 2012 14:33 >> To: manet >> Subject: [manet] Start work: update draft for RFC5444-Packets >> >> Hi >> >> I started working on a new draft to make some updates to the RFC5444, >> so manet-packets can be more used by AODVv2, DLEP, and other possible >> protocols. >> >> I will consider your input below of the discussions regarding >> 5444-packets, also in the past there was a request that there is a >> need for how to use 5444, so this draft may include as well, >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >> >> If you have any comment or advise to this started work please reply, >> >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From thomas@thomasclausen.org Mon Jul 23 03:42: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 589F321F8665 for ; Mon, 23 Jul 2012 03:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8E4ve5fbeyzk for ; Mon, 23 Jul 2012 03:42:14 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5E021F84FC for ; Mon, 23 Jul 2012 03:42:14 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id D1B8C55800A for ; Mon, 23 Jul 2012 03:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2EE471BC34F0; Mon, 23 Jul 2012 03:42:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.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 mailc2.tigertech.net (Postfix) with ESMTPSA id 158091BC34E8; Mon, 23 Jul 2012 03:42:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Clausen In-Reply-To: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> Date: Mon, 23 Jul 2012 12:42:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> To: "Rick Taylor" X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 10:42:15 -0000 I agree with Rick, and want to add a few things ... On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > Hi Abdussalam, >=20 > I would recommend that you be very careful about attempting to > adapt/extend RFC5444, particularly with respect to DLEP, because it is > still open to debate whether any future DLEP draft will use RFC5444 = for > its packet format, and I believe the authors are leaning away from it. Yes - plus, it is also not established yet that RFC5444 isn't = appropriate for carrying DLEP signals (should the authors/WG go that = way). > Also, there has been a lot of comment on this mailing list about not > updating RFC5444 yet as there appears little consensus about the = actual > failings of the format w.r.t applicable protocols, i.e. all the > 'complaints' about the format appear to be short-comings in the > consuming protocols, not the packetBB format itself. +1 > Can you perhaps outline what you see as the failings of RFC5444 here > before you produce a lengthy document, in order to gather some quick > peer-review comments, as many on this list struggle to find time to > digest long formal drafts, and I wouldn't want you to suffer from = TL;DR > ('too-long; didn't-read'). Even before that, it would be helpful to see a real routing protocol = (which DLEP is not), with a real usecase & industry behind it (so, not = just a thought experiment), with requirements pushed from real = deployments (so, outside of a lab), which is within the [manet] scope - = and for which its signals cannot properly be expressed in RFC5444. Best, Thomas > Rick Taylor > Cassidian Systems >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf > Of >> Abdussalam Baryun >> Sent: 21 July 2012 14:33 >> To: manet >> Subject: [manet] Start work: update draft for RFC5444-Packets >>=20 >> Hi >>=20 >> I started working on a new draft to make some updates to the RFC5444, >> so manet-packets can be more used by AODVv2, DLEP, and other possible >> protocols. >>=20 >> I will consider your input below of the discussions regarding >> 5444-packets, also in the past there was a request that there is a >> need for how to use 5444, so this draft may include as well, >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>=20 >> If you have any comment or advise to this started work please reply, >>=20 >> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Jul 23 04:19: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 7978A21F866B for ; Mon, 23 Jul 2012 04:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, J_CHICKENPOX_22=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 cVvMce20x8ON for ; Mon, 23 Jul 2012 04:19:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D600321F8650 for ; Mon, 23 Jul 2012 04:19:36 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4961767vcb.31 for ; Mon, 23 Jul 2012 04:19:36 -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=3GR7ZEYA97iFCAaYcgAUVY1knqG0njrm6Sb1CHb0lNo=; b=MGocUs+44bhPq8UA5KDcdI4CbVFgNBdnKOY0+jw/bgL5qNLbYpkKwJPwnTkUGT2vqL HokdsmGWro9QBXYqm+AtBdukxDszaO9a1tWt6vL9/fodK0kYqcR7u9ho03yrR+e0PWzn D64EoXn4Zc/c7DCn0GNF3gqCofCIlwKmJbtIEZndAQzk6weCeP9qBfiLEN9KTrRk9UI/ dyScBdYeP63Bw1kEgU5AnGaR5i3LiBmEX6yCW9+X1CVGl59DiiSrRqRNCnRbsThf488T COLpxo7PMdsZ5VNbPjgVYD3XHxQrkunVwgMTuYJmnl5SoKHX0R0vJL+bCUFnHk+k39a6 kDsw== MIME-Version: 1.0 Received: by 10.220.152.67 with SMTP id f3mr1694596vcw.19.1343042376061; Mon, 23 Jul 2012 04:19:36 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Mon, 23 Jul 2012 04:19:35 -0700 (PDT) In-Reply-To: <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> Date: Mon, 23 Jul 2012 13:19:35 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:19:37 -0000 Hi Thomas, comments in line, On 7/23/12, Thomas Clausen wrote: > I agree with Rick, and want to add a few things ... > > On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > >> Hi Abdussalam, >> >> I would recommend that you be very careful about attempting to >> adapt/extend RFC5444, particularly with respect to DLEP, because it is >> still open to debate whether any future DLEP draft will use RFC5444 for >> its packet format, and I believe the authors are leaning away from it. > > Yes - plus, it is also not established yet that RFC5444 isn't appropriate > for carrying DLEP signals (should the authors/WG go that way). Discussion has been established already on the list and in the last meeting of MANET WG > >> Can you perhaps outline what you see as the failings of RFC5444 here >> before you produce a lengthy document, in order to gather some quick >> peer-review comments, as many on this list struggle to find time to >> digest long formal drafts, and I wouldn't want you to suffer from TL;DR >> ('too-long; didn't-read'). > > Even before that, it would be helpful to see a real routing protocol (which > DLEP is not), with a real usecase & industry behind it (so, not just a > thought experiment), with requirements pushed from real deployments (so, > outside of a lab), which is within the [manet] scope - and for which its > signals cannot properly be expressed in RFC5444. nothing real/production comes to life without a start of ideas and discussions, please note that any discussion is in scope of the MANET WG, and that MANET theory I-Ds may be accepted and become RFCs which is also in scope. Regards AB From boberry@cisco.com Mon Jul 23 04:27: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 1502121F86FF for ; Mon, 23 Jul 2012 04:27:46 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 CEYPEgl45FWD for ; Mon, 23 Jul 2012 04:27:45 -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 5DAA821F84F2 for ; Mon, 23 Jul 2012 04:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=3787; q=dns/txt; s=iport; t=1343042865; x=1344252465; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+paFKCcCrtdDOppdWO3hwhRZhdeH/7T2RKWHn3/FNdI=; b=FKOJwqTts5tYhStw5PNtCW0Ayhq/AC/R3n4nihIijBdgNE53uHsQI8BV qHdSU4WUNHsjX7okzbLhMmsxH4gOPQmKwhu14FHJjXbL07JaFegqbGF1y uduw9li46Ms/N65vffr4GyCII8IqV52OndF4CKn46GZXfhU73x0lMWvWz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEI0DVCtJXG+/2dsb2JhbABFuTWBB4IgAQEBAwEBAQEPASc0CwUHBAsRBAEBAScHJx8JCAYTCRmHZQYLnh2fKItNGoVZYAOVSYVbiEyBZoJ7gUM X-IronPort-AV: E=Sophos;i="4.77,638,1336348800"; d="scan'208";a="104344234" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jul 2012 11:27:45 +0000 Received: from [192.168.1.206] (ggsg-1vpn2-230-66.cisco.com [10.81.230.66]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6NBRiHX029778; Mon, 23 Jul 2012 11:27:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> Date: Mon, 23 Jul 2012 07:27:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.1084) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 11:27:46 -0000 As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) are working on DLEP revisions. -Bo On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: > I agree with Rick, and want to add a few things ... >=20 > On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >=20 >> Hi Abdussalam, >>=20 >> I would recommend that you be very careful about attempting to >> adapt/extend RFC5444, particularly with respect to DLEP, because it = is >> still open to debate whether any future DLEP draft will use RFC5444 = for >> its packet format, and I believe the authors are leaning away from = it. >=20 > Yes - plus, it is also not established yet that RFC5444 isn't = appropriate for carrying DLEP signals (should the authors/WG go that = way). >=20 >> Also, there has been a lot of comment on this mailing list about not >> updating RFC5444 yet as there appears little consensus about the = actual >> failings of the format w.r.t applicable protocols, i.e. all the >> 'complaints' about the format appear to be short-comings in the >> consuming protocols, not the packetBB format itself. >=20 > +1 >=20 >> Can you perhaps outline what you see as the failings of RFC5444 here >> before you produce a lengthy document, in order to gather some quick >> peer-review comments, as many on this list struggle to find time to >> digest long formal drafts, and I wouldn't want you to suffer from = TL;DR >> ('too-long; didn't-read'). >=20 > Even before that, it would be helpful to see a real routing protocol = (which DLEP is not), with a real usecase & industry behind it (so, not = just a thought experiment), with requirements pushed from real = deployments (so, outside of a lab), which is within the [manet] scope - = and for which its signals cannot properly be expressed in RFC5444. >=20 > Best, >=20 > Thomas >=20 >=20 >> Rick Taylor >> Cassidian Systems >>=20 >>> -----Original Message----- >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >> Of >>> Abdussalam Baryun >>> Sent: 21 July 2012 14:33 >>> To: manet >>> Subject: [manet] Start work: update draft for RFC5444-Packets >>>=20 >>> Hi >>>=20 >>> I started working on a new draft to make some updates to the = RFC5444, >>> so manet-packets can be more used by AODVv2, DLEP, and other = possible >>> protocols. >>>=20 >>> I will consider your input below of the discussions regarding >>> 5444-packets, also in the past there was a request that there is a >>> need for how to use 5444, so this draft may include as well, >>>=20 >>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>>=20 >>> If you have any comment or advise to this started work please reply, >>>=20 >>> AB >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 sratliff@cisco.com Mon Jul 23 07:59: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 519CD11E8091 for ; Mon, 23 Jul 2012 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 sbgyD+FFm8zU for ; Mon, 23 Jul 2012 07:59: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 BD6E211E807F for ; Mon, 23 Jul 2012 07:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=26275; q=dns/txt; s=iport; t=1343055573; x=1344265173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/29PPQwNbbgEeACrnRfkiX4Sf4h+sEQcRc7sDpE73I4=; b=OhHT8U7x8EPLjeM6BzM5hlYkvhaW1V9Pol2Tx1mS+psSc07WqX2/txwZ cexezMxTcu/RkmhJvjUr4uGkFSeWrrmCZYpbfgJzWYrKf911utCXoWzem BIxWFSocdBe6CL9awC6N1ORsGIP94/d5/q9O94YOlKXhkBictZHz3aUPa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADhmDVCtJV2a/2dsb2JhbAA7AQm5OIEHgiABAQEDAQEBAQ8BB00EAwIJBQsCAQgYLicLJQIECgQDAhQOh2UGC50tn1IEi00QAQMHhVhgA5VJjieBZoJfPoEYAgcc X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104421628" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jul 2012 14:59:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6NExVbQ004549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 14:59:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 09:59:31 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] MANET Terminology Update Thread-Index: AQHNaKCpTpyJkO77IEKicKgVvY7Vipc3ShYA Date: Mon, 23 Jul 2012 14:59:30 +0000 Message-ID: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--54.900700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Thomas Heide Clausen Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:59:35 -0000 I'm going to "+1" one (and only one) sentence in this email thread:=20 >=20 > On 7/6/12, Thomas Heide Clausen wrote: >> I do not see the need for this terminology document in MANET: >=20 In my opinion as a working group participant, this is an unnecessary distra= ction for the working group, and will not result in a meaningful document. = I will not support it.=20 Regards, Stan On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote: > Hi >=20 > Comment inline below: >=20 > On 7/6/12, Thomas Heide Clausen wrote: >> I do not see the need for this terminology document in MANET: >>=20 >> o The RFCs published by the WG all do a good job of defining their prop= er >> terminology and conventions in the sections, aptly named to this >> effect -- and something which both the WG and the IESG has been very >> vigilant in ensuring. >=20 > Agree >=20 >>=20 >> o Extracting this terminology, to present without the context of the RF= C in >>=20 >> which they are introduced and used, is both futile and a source >> of errors and confusion. >=20 > It is not extracting any thing it is locating information in easy > location to be reached efficiently by researchers, or other WG > participants. In another reason, for example the RFC5444 and RFC6130 > is providing a MANET standard, while any RFC in this WG is specifying > its own terminology and message format, but the reason was to bring > RFCs to have similar formating functions. The terminology RFCs in many > WGs does the same. RFC2501 is doing a good job to bring understanding > of MANET which the terminology informational RFCs are doing in each > concept/group-charter. >=20 >>=20 >> o The domain evolves, new protocols appear and introduce new concepts, >> terms. This is captured by carefully defining such in the RFC specifyi= ng >> that protocol. Any terminology document (aside from all its other issu= es, >> indicated in this list) would likely be obsolete and incomplete before >> the >> ink with which it was written was dry. >=20 > So when new concepts appear any WG needs to prepare updates I-D to > their information/standards/experiments so that knowledge is > consistent and concepts are updated as will (including terminology > document can be updated). Please note that our documents in MANET are > a source of information to any participant in IETF, so we need to > focus to not only produce new concepts/work but we see into > update/obsolete previous work if possible/necessary. other wise why > did the IETF make an option possibility to *update* and *obsolete* if > they are not needed for WGs. >=20 >>=20 >> o All RFCs in MANET uses no more than a small subset of the total MANET >> (and Internet) terminology. A collective terminology document would, >> therefore, necessarily be adding entropy to any single RFC and to the >> WG (and to implementers of the WG protocols). >=20 > Please note that the bigest reason of terminology is that when WG > participants discuss things they don't misunderstand. Please note > there are many times in MANET WG there are misunderstood in technical > terms (I have references on the list to many incidence if you ask), so > if experts have this problem we need to solve it by a RFC document, > also we need to give the protocol user a sense of the general/specific > terminology (as we have MANET general format, MANET general > understanding, MANET general direction). >=20 >>=20 >> o Certainly, a large number of terms in this document are entirely out = of >> scope >> (such as those pertaining to non-MANET developed concepts or protocols= , >> e.g., those developed in other parts of the IETF), are useless for the= WG >> (such as, but not exclusively, "communication channel" and "communicat= ion >>=20 >> medium"), are by nature ambiguous (such as, but not exclusively, "Uppe= r >> Layer" >> and "Node"), carry a legacy that renders them difficult to use (such a= s, >> but >> not exclusively, "Logical (virtual) Link", "Physical Link", and "Link"= ). >>=20 >=20 > I disagree that thoes terms are out of scope of the I-D of the MANETs > context terminology, because those terms you mentioned were used in > one/some MANET RFCs, so they need to be explained to bring all terms > together to make overall knowledge to internet community. Your > argument is right only if we are not specifying network-protocols, so > because we are doing a type of network, then our documents for it > SHOULD be *connected* by some combined meaning/knowledge *words*, so > other (i.e. all internet community) can understand, without any > possibility of misunderstanding (there are many examples I can give if > you want). >=20 > I thank you for your comments, and I will prepare a new version for the I= -D, >=20 > Best Regards >=20 > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>>>=20 >>>>> Dear All >>>>>=20 >>>>> I completed the first version of draft on terminology and submited th= e >>>>> draft yesterday (with getting some techniq problem), but needed to >>>>> post to know the community feedback and advise. There are other terms >>>>> that was not yet included which will need some advise from you. >>>>> Thanking you, >>>>>=20 >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Abbreviations Used in The submitted Document >>>>>=20 >>>>> AH Authentication Header >>>>> DAD Duplicate Address Detection >>>>> DPD Duplicate Packet Detection >>>>> DoS Denial of Service >>>>> ESP Encapsulating Security Payload >>>>> IP IPv4 or IPv6 >>>>> ICMP Internet Control Message Protocol >>>>> IIB Interface Information Base >>>>> ETX Estimated Expected number of Transmission >>>>> FIB Forwarding Information Base >>>>> LQI Link Quality Indicator >>>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>>> LLN Low power and Lossy Network >>>>> MAC Mediam Access Control >>>>> MIB Management Information Base >>>>> MTU Maximum Transmission Unit >>>>> NBMA Non-Broadcast Multi-Access link >>>>> NHDP Neighborhood Discovery Protocol >>>>> ND IP Neighbor Discovery >>>>> OSPF Open Shortest Path First >>>>> RIB Routing Information Base >>>>> SMF Simplified Multicast Forwarding >>>>> TCP Transmission Control Protocol >>>>> UDP User Datagram Protocol >>>>>=20 >>>>> 2.3 Definitions for MANET Terms >>>>>=20 >>>>> 2.3.1 Terms Definition of MANET Communication: >>>>>=20 >>>>> Communications=92 Technology or Facility: >>>>> The means employed by two or more devices/subsystems to transfer >>>>> and/or receive information between them in one way or two way >>>>> communication. MANET communications often uses the wireless >>>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>>> space, air, water, antenna, coaxial cables, etc.) >>>>>=20 >>>>> Communication Medium: >>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>>> satellite system, etc.) that the routing device uses to communicates >>>>> through the transmission medium(s), by providing connectionless and/o= r >>>>> connection services that MAY be established. The system medium >>>>> includes MAC layer and MAY include the physical Layer. >>>>>=20 >>>>> Communication Channel: >>>>> A subdivision of the physical communication medium (i.e. radio carrie= r >>>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>>> independent uses of the medium. Channels may be made available by >>>>> subdividing the medium into; distinct time slots, distinct spectral >>>>> bands, or coding sequence, etc. >>>>>=20 >>>>> MANET Protocol: >>>>> The communication system/subsystem that operates and maintains the >>>>> ad hoc communication technology or facility within MANET. MANET routi= ng >>>>> Protocols often apply distributed algorithms/techniques to disseminat= e >>>>> or forward routing messages within a MANET routing domain. >>>>>=20 >>>>> Topology: >>>>> An abstract representation of a network (physical or logical), as a >>>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>>> that >>>>> communicate through set of links (E), where the G =3D (V, E). >>>>>=20 >>>>> Physical-level Topology: >>>>> A topology of the communication medium networks consists of routing >>>>> devices and physical links. This topology information is updated by >>>>> devices=92 technology in the L2 information Base. >>>>>=20 >>>>> Network-level Topology: >>>>> A topology of the communication system networks consists of routers a= nd >>>>> links. This topology information is updated by routers in its RIB. >>>>>=20 >>>>> Multihop MANET: >>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach th= e >>>>> destination. >>>>>=20 >>>>> Reactive Routing: >>>>> An on-demand based routing protocol that operates route discover and >>>>> maintainance the route(s), to reach the demanded destination(s). >>>>>=20 >>>>> Proactive Routing: >>>>> A topology RIB based routing protocol that operates routes and >>>>> maintains >>>>> the network topology, to reach its known destination(s). Each router >>>>> maintains routes to all reachable destinations at all times, whether = or >>>>> not there is currently any demand to deliver packets to those >>>>> destinations. >>>>>=20 >>>>> Upper Layer: >>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>>>=20 >>>>> MANET Domain: TBD >>>>>=20 >>>>> MANET Signaling: >>>>> Sending and exchanging some MANET messages/information. >>>>>=20 >>>>> 2.3.2 Terms Definition of MANET Elements >>>>>=20 >>>>> Node: >>>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>>> MANET signaling. It either runs a MANET routing protocol or participa= te >>>>> in MANET signaling. >>>>>=20 >>>>> Router: >>>>> A MANET node that MUST implement a MANET routing protocol and forward= s >>>>> IP packets not explicitly addressed to itself. >>>>>=20 >>>>> Host: >>>>> A node that is not a router. All destinations in MANET that receive >>>>> delivered data are hosts. >>>>>=20 >>>>> Link: >>>>> A link between two node interfaces. This link may be Logical >>>>> (i.e. virtual) link or physical link. Logical links are between two >>>>> logical interfaces and physical links are between two physical >>>>> interfaces. Links are either unidirectional or bidirectional >>>>> (links may be on-link and off-link: see RFC4861). >>>>>=20 >>>>>=20 >>>>> Physical Link: >>>>> a communication facility or medium over which the nodes can >>>>> communicate at the link layer, i.e., the layer immediately below >>>>> IP. Physical interfaces are the nodes=92 attachment to physical links= . >>>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>>> and shared-media, etc (see link types in ND [RFC4861]). >>>>>=20 >>>>> Logical (virtual) Link: >>>>> a communication facility (at L3, or upper-layer) over which nodes can >>>>> communicate. This logical link is between two MANET interfaces exists >>>>> if either can be heard by the other. >>>>>=20 >>>>> Link MTU: >>>>> the maximum transmission unit (i.e. maximum unit size in octets), tha= t >>>>> can be conveyed in one transmission unit over the link. >>>>>=20 >>>>>=20 >>>>> Node Interface: >>>>> A node's point of attachment to a link. Each node MUST have at least >>>>> one >>>>> interface that SHOULD be assigned an IP address. If there is/are more >>>>> than one interface(s) per node then the additional interface(s) MAY b= e >>>>> assigned an IP address. If an interface is not assigned to an IP >>>>> address >>>>> it MUST be identified by the MANET routing protocol. An interface MAY >>>>> be >>>>> assigned one or more addresses. >>>>>=20 >>>>> MANET Interface: >>>>> A node interface that participate in; exchange MANET information used >>>>> in >>>>> MANET routing or exchange information in MANET neighbor node discover= y >>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned >>>>> to >>>>> least one address to communicate. A router interface MUST be >>>>> assigned a routable address which is the main address for the >>>>> interface. >>>>>=20 >>>>>=20 >>>>> 2.3.3 Terms Definition of MANET Identifications: >>>>>=20 >>>>> An interface MAY be assigned one or more addresses. If the interface = is >>>>> a logical interface it MAY be assigned to only logical addresses, but >>>>> if >>>>> it is a physical interface MAY be assigned with physical address >>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>>> MANET addresses). >>>>>=20 >>>>>=20 >>>>> MANET Address >>>>> A MANET-subnet, node, or interface address. Node and interface >>>>> addresses >>>>> are either IP addresses or RFC5444 addresses. All subnet addresses ar= e >>>>> unicast IP addresses. >>>>>=20 >>>>> Address Block and TLV: as specified in RFC5444 >>>>>=20 >>>>> Routable address: >>>>> A subnet address which can be a destination address. A router MUST be >>>>> able to distinguish a routable address from a non-routable address. >>>>> Broadcast, and multicast addresses, limited in scope to less than the >>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>>> addresses MAY be considered as routable addresses. >>>>>=20 >>>>> Main address >>>>> A routable address (MANET address) that is assigned to one router's >>>>> MANET interface. >>>>>=20 >>>>> Originator address: >>>>> A node address of the node that originated a MANET message (this >>>>> message >>>>> MUST include the originator address). It MAY be a routable or an >>>>> unroutable address. >>>>>=20 >>>>> subnet prefix >>>>> A bit string that consists of some number of initial bits of an IP >>>>> address. >>>>>=20 >>>>> Interface identifier >>>>> the remaining low-order bits in the node's IP address after the subne= t >>>>> prefix. A number used to identify a node's interface on a link. >>>>>=20 >>>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>>>=20 >>>>> Packet: >>>>> A MANET packet of a header plus payload. These packets are either >>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>>> in IP packet. Packets are generated by nodes to be sent to >>>>> destination(s) through MANET or through the Internet. RFC5444 packets >>>>> information MAY not be used only by MANET routers. >>>>>=20 >>>>> Message: >>>>> A MANET data message or routing control message. Routing control >>>>> messages are either MANET routing protocol messages or/and RFC5444 >>>>> messages. >>>>>=20 >>>>> Type Length Value coding (TLV): >>>>> A generic way to represent MANET information (as in [RFC5444] and >>>>> [RFC5497]). >>>>>=20 >>>>> Frame: >>>>> A L2 protocol TLV with a header and payload. In some technologies the >>>>> L2 >>>>> operates a MANET routing protocol as a local area networking system. >>>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>>> telecommunication network. >>>>>=20 >>>>> Route Request Message (RREQ) >>>>> A message is used to discover a valid route to a particular >>>>> destination address, called the RREQ Target Node. When a router >>>>> processes a RREQ it learns routing information on how to Originator >>>>> Node. >>>>>=20 >>>>> Route Reply Message (RREP) >>>>> A message is used to disseminate routing information about >>>>> the RREP Target Node to the RREQ Originator Node and the intermediate >>>>> routers. >>>>>=20 >>>>> Route Error Message (RERR) >>>>> A message is used to disseminate the information that a route is >>>>> not available for one or more particular addresses. A RERR message is >>>>> used to indicate that a router does not have a forwarding route >>>>> to one or more particular addresses. >>>>>=20 >>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>>>=20 >>>>> Hop-by-hop Routing: (TBD) >>>>> A dynamic routing that routes to destination by routing table. >>>>>=20 >>>>> Source Routing: (TBD) >>>>> A dynamic routing that its route path is provided in the IP packet. >>>>>=20 >>>>> Route Discovery: TBD >>>>>=20 >>>>> Route Maintenance: TBD >>>>>=20 >>>>> Neighbor discovery: (TBD) >>>>> A node discovers neighbors only if the node receives from it's >>>>> neighbors. >>>>>=20 >>>>>=20 >>>>> Multipoint relay (MPR): (TBD) >>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>>> its selection of router X1 as an MPR in a recent HELLO message. >>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>>> participate in the flooding process of messages received from >>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>>> declare link-state information for the link from X1 to Y1. It may >>>>> also be both at the same time. >>>>>=20 >>>>> MPR selector: >>>>> A router, Y, is a flooding/routing MPR selector of router X if >>>>> router Y has selected router X as a flooding/routing MPR. >>>>>=20 >>>>> Router Parameters: >>>>> boolean or numerical values, specified for each router, and not >>>>> specific to an interface. A router MAY change router parameter >>>>> values at any time, subject to some MANET constraints. >>>>>=20 >>>>> MANET Routing Metric: >>>>> A MANET routing cost that is governed by specific rules and propertie= s >>>>> defined by the MANET routing protocol which captures specific link or >>>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>>> LQI, >>>>> etc. >>>>>=20 >>>>> Distance Vector Metric >>>>> A metric class related to rules of the MANET interface and MANET path >>>>> distance. The metric can be calculated by the distance vector routing >>>>> algorithm class used by the MANET routing protocol. A metric of the >>>>> distance a message or piece of information has traversed. The minimum >>>>> value of distance is the number of IP hops traversed. >>>>>=20 >>>>> Link State Metric >>>>> A metric type related to the MANET network-topology status and logica= l >>>>> links' states. This metric is calculated by the link state routing >>>>> algorithm class used by the MANET routing protocol. A metric type may= be >>>>> EXT, LQL, etc. >>>>>=20 >>>>> Link Metric: TBD >>>>>=20 >>>>> Neighbor Metric: TBD >>>>>=20 >>>>> Path accumulated: >>>>> The RREQ message accumulates intermediate routers that are in path to >>>>> destination(s). >>>>>=20 >>>>> Protocol Sequence Number: >>>>> A Sequence Number related to a MANET protocol that maintained by each >>>>> protocol subsystem process. This sequence number is used by other >>>>> subsystems to identify the temporal order of protocol information >>>>> generated. >>>>>=20 >>>>> Router Sequence Number: >>>>> A router sequence number is maintained by each router process. The >>>>> sequence number is used by other routers to identify the temporal >>>>> order of routing information generated and ensure loop-free routes. >>>>>=20 >>>>> MANET Information Base: >>>>> A collection of information (in Table or Cache structure) maintained >>>>> by MANET protocols and which is to be made available to MANET routing >>>>> protocols. An Information Base may be associated with a MANET router >>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB= ). >>>>>=20 >>>>> RIB Entry: >>>>> The RIB entry is a conceptual data structure. Implementations may use >>>>> any internal representation that conforms to the semantics of a route >>>>> as specified in the router specification. >>>>>=20 >>>>> 3. IP Considerations and Terminology >>>>>=20 >>>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>>> run/implement at least one MANET routing protocol. The >>>>> terminologies described in this document can be used for >>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>>>=20 >>>>> IP address: >>>>> IPv4 addresses or IPv6 addresses. >>>>>=20 >>>>> IP Packet: >>>>> The packet header plus payload as specified in [RFC791] and [RFC2460] >>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >>>>> specified by RFC5498. >>>>>=20 >>>>> Mobile IP considerations: >>>>> Mobile IP terms are provided in [RFC6275], and this technology >>>>> assists nodes while connected through the Internet domain(s). MANET >>>>> is an infrastructure-less network that is able to communicate with >>>>> the Internet (i.e. an IP infrastructure network). >>>>>=20 >>>>> 4. Security Consideration and Terminology >>>>>=20 >>>>> It is RECOMMENDED that MANET routing protocols consider security >>>>> issues because the MANET's transmission medium is wireless which make >>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>>> routing information while traversing the MANET MAY be used by an >>>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>>>=20 >>>>> The following are some terminology related to MANET threats and >>>>> security. >>>>>=20 >>>>> Attacker: A node, present in the network and which intentionally seek= s >>>>> to compromise information based in MANET router(s). The Attacker MAY = be >>>>> a compromised MANET router if obtained MANET identity or routing >>>>> information. >>>>>=20 >>>>> Compromised MANET Router: An attacker router, present in MANET and >>>>> which generates syntactically correct routing control messages. Contr= ol >>>>> messages emitted by compromised router(s) may contain additional >>>>> information, or omit information, as compared to a control message >>>>> generated by a non-compromised router located in the same MANET >>>>> topological position. >>>>>=20 >>>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>>> MANET Router. >>>>>=20 >>>>> Jamming Attack: >>>>> The attacker transmits massive amounts of interfering radio traffic, >>>>> which will prevent legitimate traffic (e.g., routing and data traffic= ) >>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>>> influencing Legitimate MANET Router to transmit unnecessary >>>>> information. >>>>>=20 >>>>> Eavesdropping: >>>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>>> information or the transmitted data information from its neighbor's >>>>> transmitted radio packet. Attacker=92s processes MANY be used by atta= cker >>>>> to mislead routing. Eavesdropping does not pose a direct threat to th= e >>>>> MANET or to its routing. >>>>>=20 >>>>> Identity Spoofing: >>>>> Attacker sends routing messages, pretending to have the MANET identit= y >>>>> of another node. >>>>>=20 >>>>> Link Spoofing: >>>>> Compromised MANET router sends routing messages to neighbor node(s) >>>>> providing incorrect set of link information. >>>>>=20 >>>>> Replay Attack: >>>>> A Compromised router in one MANET region records control traffic >>>>> information and replays the recorded information in a different MANET >>>>> region (this type of attack is also called the Wormhole attack). >>>>>=20 >>>>> Broadcast Storm: >>>>> Compromised MANET router may attack the MANET by attempting to change >>>>> the MANET flooding algorithm(s) to increase routing overheads or/and = to >>>>> increase the route discovery delay. Broadcast storm degrades the data >>>>> traffic delivery and MANET performance. >>>>>=20 >>>>> Falsification in MANET: >>>>> The compromised MANET router sends false routing information into >>>>> MANET. >>>>> False routing information received in MANET, MAY create unrealistic >>>>> information bases. >>>>>=20 >>>>> ICMP Attacks: >>>>> The generation of ICMPv6 error messages may be used by compromised >>>>> MANET >>>>> router to attempt DoS attacks by sending an error-causing source >>>>> routing >>>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>>> the >>>>> upper-layer processes, it is possible to perform attacks on the upper >>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>>> RECOMMENDED to perform some form of validation to ICMP messages (usin= g >>>>> the information contained in the payload of the ICMP message) before >>>>> acting upon them. >>>>>=20 >>>>> Source Routing Attacks: TBD >>>>>=20 >>>>> Acknowledgments: >>>>>=20 >>>>> This work has used/modified terms of the following documents: RFC2462= , >>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>>> Gratefully acknowledge to the IETF community and all contributions. >>>>>=20 >>>>> Reference: >>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>>> NHDP", Work in progress, March, 2012. >>>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>>> Networks", John Wiley & Sons, March 2007. >>>>> ISBN: 978-0-471-75688-0. >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>=20 >>>>> I hope to get some advise from the Internet community to make the >>>>> definitions more suitable/accurate, because I MAY misunderstood. >>>>> Thanking you, >>>>>=20 >>>>> Best Regards >>>>>=20 >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Mon Jul 23 08:00: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 761A511E80AD for ; Mon, 23 Jul 2012 08:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.911 X-Spam-Level: X-Spam-Status: No, score=-9.911 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 pOq57QDngt7U for ; Mon, 23 Jul 2012 08:00:29 -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 E305111E8097 for ; Mon, 23 Jul 2012 08:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4085; q=dns/txt; s=iport; t=1343055624; x=1344265224; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iXwIs4svH7hslGc+ylAIMqaNviS0AyTwnRJFfZv5aeY=; b=PmR9J3LvQv5+w/+LNPJuc/28pEvTy6ZsEzVI6SCjIWw6EHmkDwBTtRqn 5CgTJDq5VEWkmnqjMjDr/yaJptU4OYqMqZCOxD+h3Fkz8jxQArfyS+Ov1 HyvxYhSwE5Jt0K+CtfOHyw3IiyT/2kZ25C46aF4KkuKJYKjYk2eU7pE79 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJxmDVCtJXG//2dsb2JhbABFuTiBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQEBHgkHJwsUCQgBAQQOBQkZh2UGC50un1aLTRqFWWADlUmOJ4Fmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104394654" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2012 15:00:14 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6NF0ERj008746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 15:00:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 10:00:14 -0500 From: "Stan Ratliff (sratliff)" To: "Bo Berry (boberry)" Thread-Topic: [manet] Start work: update draft for RFC5444-Packets Thread-Index: Ac1nRVEz4qnqj1lUdUWZmFtP9xSwrQBbSaUgAA3PzIAAAZgkAAAHa3SA Date: Mon, 23 Jul 2012 15:00:13 +0000 Message-ID: <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> In-Reply-To: <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--48.403500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Thomas Clausen , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:00:31 -0000 +1 Regards, Stan On Jul 23, 2012, at 7:27 AM, Bo Berry wrote: > As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) are > working on DLEP revisions. >=20 > -Bo >=20 >=20 > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: >=20 >> I agree with Rick, and want to add a few things ... >>=20 >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >>=20 >>> Hi Abdussalam, >>>=20 >>> I would recommend that you be very careful about attempting to >>> adapt/extend RFC5444, particularly with respect to DLEP, because it is >>> still open to debate whether any future DLEP draft will use RFC5444 for >>> its packet format, and I believe the authors are leaning away from it. >>=20 >> Yes - plus, it is also not established yet that RFC5444 isn't appropriat= e for carrying DLEP signals (should the authors/WG go that way). >>=20 >>> Also, there has been a lot of comment on this mailing list about not >>> updating RFC5444 yet as there appears little consensus about the actual >>> failings of the format w.r.t applicable protocols, i.e. all the >>> 'complaints' about the format appear to be short-comings in the >>> consuming protocols, not the packetBB format itself. >>=20 >> +1 >>=20 >>> Can you perhaps outline what you see as the failings of RFC5444 here >>> before you produce a lengthy document, in order to gather some quick >>> peer-review comments, as many on this list struggle to find time to >>> digest long formal drafts, and I wouldn't want you to suffer from TL;DR >>> ('too-long; didn't-read'). >>=20 >> Even before that, it would be helpful to see a real routing protocol (wh= ich DLEP is not), with a real usecase & industry behind it (so, not just a = thought experiment), with requirements pushed from real deployments (so, ou= tside of a lab), which is within the [manet] scope - and for which its sig= nals cannot properly be expressed in RFC5444. >>=20 >> Best, >>=20 >> Thomas >>=20 >>=20 >>> Rick Taylor >>> Cassidian Systems >>>=20 >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>> Of >>>> Abdussalam Baryun >>>> Sent: 21 July 2012 14:33 >>>> To: manet >>>> Subject: [manet] Start work: update draft for RFC5444-Packets >>>>=20 >>>> Hi >>>>=20 >>>> I started working on a new draft to make some updates to the RFC5444, >>>> so manet-packets can be more used by AODVv2, DLEP, and other possible >>>> protocols. >>>>=20 >>>> I will consider your input below of the discussions regarding >>>> 5444-packets, also in the past there was a request that there is a >>>> need for how to use 5444, so this draft may include as well, >>>>=20 >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>>>=20 >>>> If you have any comment or advise to this started work please reply, >>>>=20 >>>> AB >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 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 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Mon Jul 23 08:33: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 9E93311E809C for ; Mon, 23 Jul 2012 08:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 jVM8l7EJqfH6 for ; Mon, 23 Jul 2012 08:33:32 -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 3E07611E809B for ; Mon, 23 Jul 2012 08:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=68759; q=dns/txt; s=iport; t=1343057612; x=1344267212; h=from:to:subject:date:message-id:references:mime-version; bh=70L3PtHOoC8gTd0Cr+A0EXsdw1WEZ8JEM67ET7OlwNs=; b=FbLjXoaRpKVL6z163APgTpKwP+hAuxqfaiR6Ttn78b3G0cf59yzQ62uk Aib885f+fP09vnttIQRfA/WVjLBq+dO24jXwgXzfOlRLunNITvvMY3GvH bINQjDYO5Jc+mHxpoXIYSOAQRgpZX+Py/VtOQVQ1s80vwnDr3hGyM9Mrq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJZtDVCtJV2c/2dsb2JhbAA7AQYDuTiBB4IgAQEBAwEBAQEPAQcBTAQDAg4LAgEZAwECASABBgchBgsUBwIIAgQKBwIUDodcAwYGC50algINiUoEimZnEAEDB4MXgkFgA5N1gVSLCoMdgWaCXz6BGAIHHA X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208,217";a="104458951" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2012 15:33:30 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6NFXUqN022694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 15:33:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 10:33:29 -0500 From: "Stan Ratliff (sratliff)" To: manet IETF Thread-Topic: [manet] MANET Terminology Update Thread-Index: AQHNaKCpTpyJkO77IEKicKgVvY7Vig== Date: Mon, 23 Jul 2012 15:33:28 +0000 Message-ID: <02619309-38C0-4F60-8814-E680A4894F33@cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--50.099700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_0261930938C04F608814E680A4894F33ciscocom_" MIME-Version: 1.0 Subject: [manet] Fwd: MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:33:36 -0000 --_000_0261930938C04F608814E680A4894F33ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Looks like this was a "respond to me" instead of a "respond to the list". I= 'm forwarding it along. Stan Begin forwarded message: From: Daniel He > Subject: Re: [manet] MANET Terminology Update Date: July 23, 2012 11:01:37 AM EDT To: "Stan Ratliff (sratliff)" > If we go this document, we will go a stupid work. I agree with Stan, don't= support it as well. Regards Dan On 23 July 2012 15:59, Stan Ratliff (sratliff) > wrote: I'm going to "+1" one (and only one) sentence in this email thread: > > On 7/6/12, Thomas Heide Clausen > wrote: >> I do not see the need for this terminology document in MANET: > In my opinion as a working group participant, this is an unnecessary distra= ction for the working group, and will not result in a meaningful document. = I will not support it. Regards, Stan On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote: > Hi > > Comment inline below: > > On 7/6/12, Thomas Heide Clausen > wrote: >> I do not see the need for this terminology document in MANET: >> >> o The RFCs published by the WG all do a good job of defining = their proper >> terminology and conventions in the sections, aptly named to= this >> effect -- and something which both the WG and the IESG has = been very >> vigilant in ensuring. > > Agree > >> >> o Extracting this terminology, to present without the context= of the RFC in >> >> which they are introduced and used, is both futile and a so= urce >> of errors and confusion. > > It is not extracting any thing it is locating information in easy > location to be reached efficiently by researchers, or other WG > participants. In another reason, for example the RFC5444 and RFC6130 > is providing a MANET standard, while any RFC in this WG is specifying > its own terminology and message format, but the reason was to bring > RFCs to have similar formating functions. The terminology RFCs in many > WGs does the same. RFC2501 is doing a good job to bring understanding > of MANET which the terminology informational RFCs are doing in each > concept/group-charter. > >> >> o The domain evolves, new protocols appear and introduce new = concepts, >> terms. This is captured by carefully defining such in the R= FC specifying >> that protocol. Any terminology document (aside from all its= other issues, >> indicated in this list) would likely be obsolete and incomp= lete before >> the >> ink with which it was written was dry. > > So when new concepts appear any WG needs to prepare updates I-D to > their information/standards/experiments so that knowledge is > consistent and concepts are updated as will (including terminology > document can be updated). Please note that our documents in MANET are > a source of information to any participant in IETF, so we need to > focus to not only produce new concepts/work but we see into > update/obsolete previous work if possible/necessary. other wise why > did the IETF make an option possibility to *update* and *obsolete* if > they are not needed for WGs. > >> >> o All RFCs in MANET uses no more than a small subset of the t= otal MANET >> (and Internet) terminology. A collective terminology docume= nt would, >> therefore, necessarily be adding entropy to any single RFC = and to the >> WG (and to implementers of the WG protocols). > > Please note that the bigest reason of terminology is that when WG > participants discuss things they don't misunderstand. Please note > there are many times in MANET WG there are misunderstood in technical > terms (I have references on the list to many incidence if you ask), so > if experts have this problem we need to solve it by a RFC document, > also we need to give the protocol user a sense of the general/specific > terminology (as we have MANET general format, MANET general > understanding, MANET general direction). > >> >> o Certainly, a large number of terms in this document are ent= irely out of >> scope >> (such as those pertaining to non-MANET developed concepts o= r protocols, >> e.g., those developed in other parts of the IETF), are usel= ess for the WG >> (such as, but not exclusively, "communication channel" and = "communication >> >> medium"), are by nature ambiguous (such as, but not exclusi= vely, "Upper >> Layer" >> and "Node"), carry a legacy that renders them difficult to = use (such as, >> but >> not exclusively, "Logical (virtual) Link", "Physical Link",= and "Link"). >> > > I disagree that thoes terms are out of scope of the I-D of the MANETs > context terminology, because those terms you mentioned were used in > one/some MANET RFCs, so they need to be explained to bring all terms > together to make overall knowledge to internet community. Your > argument is right only if we are not specifying network-protocols, so > because we are doing a type of network, then our documents for it > SHOULD be *connected* by some combined meaning/knowledge *words*, so > other (i.e. all internet community) can understand, without any > possibility of misunderstanding (there are many examples I can give if > you want). > > I thank you for your comments, and I will prepare a new version for the I= -D, > > Best Regards > > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>>> >>>>> Dear All >>>>> >>>>> I completed the first version of draft on terminology and submited th= e >>>>> draft yesterday (with getting some techniq problem), but needed to >>>>> post to know the community feedback and advise. There are other terms >>>>> that was not yet included which will need some advise from you. >>>>> Thanking you, >>>>> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Abbreviations Used in The submitted Document >>>>> >>>>> AH Authentication Header >>>>> DAD Duplicate Address Detection >>>>> DPD Duplicate Packet Detection >>>>> DoS Denial of Service >>>>> ESP Encapsulating Security Payload >>>>> IP IPv4 or IPv6 >>>>> ICMP Internet Control Message Protocol >>>>> IIB Interface Information Base >>>>> ETX Estimated Expected number of Transmission >>>>> FIB Forwarding Information Base >>>>> LQI Link Quality Indicator >>>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>>> LLN Low power and Lossy Network >>>>> MAC Mediam Access Control >>>>> MIB Management Information Base >>>>> MTU Maximum Transmission Unit >>>>> NBMA Non-Broadcast Multi-Access link >>>>> NHDP Neighborhood Discovery Protocol >>>>> ND IP Neighbor Discovery >>>>> OSPF Open Shortest Path First >>>>> RIB Routing Information Base >>>>> SMF Simplified Multicast Forwarding >>>>> TCP Transmission Control Protocol >>>>> UDP User Datagram Protocol >>>>> >>>>> 2.3 Definitions for MANET Terms >>>>> >>>>> 2.3.1 Terms Definition of MANET Communication: >>>>> >>>>> Communications=92 Technology or Facility: >>>>> The means employed by two or more devices/subsystems to transfer >>>>> and/or receive information between them in one way or two way >>>>> communication. MANET communications often uses the wireless >>>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>>> space, air, water, antenna, coaxial cables, etc.) >>>>> >>>>> Communication Medium: >>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>>> satellite system, etc.) that the routing device uses to communicates >>>>> through the transmission medium(s), by providing connectionless and/o= r >>>>> connection services that MAY be established. The system medium >>>>> includes MAC layer and MAY include the physical Layer. >>>>> >>>>> Communication Channel: >>>>> A subdivision of the physical communication medium (i.e. radio carrie= r >>>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>>> independent uses of the medium. Channels may be made available by >>>>> subdividing the medium into; distinct time slots, distinct spectral >>>>> bands, or coding sequence, etc. >>>>> >>>>> MANET Protocol: >>>>> The communication system/subsystem that operates and maintains the >>>>> ad hoc communication technology or facility within MANET. MANET routi= ng >>>>> Protocols often apply distributed algorithms/techniques to disseminat= e >>>>> or forward routing messages within a MANET routing domain. >>>>> >>>>> Topology: >>>>> An abstract representation of a network (physical or logical), as a >>>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>>> that >>>>> communicate through set of links (E), where the G =3D (V, E). >>>>> >>>>> Physical-level Topology: >>>>> A topology of the communication medium networks consists of routing >>>>> devices and physical links. This topology information is updated by >>>>> devices=92 technology in the L2 information Base. >>>>> >>>>> Network-level Topology: >>>>> A topology of the communication system networks consists of routers a= nd >>>>> links. This topology information is updated by routers in its RIB. >>>>> >>>>> Multihop MANET: >>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach th= e >>>>> destination. >>>>> >>>>> Reactive Routing: >>>>> An on-demand based routing protocol that operates route discover and >>>>> maintainance the route(s), to reach the demanded destination(s). >>>>> >>>>> Proactive Routing: >>>>> A topology RIB based routing protocol that operates routes and >>>>> maintains >>>>> the network topology, to reach its known destination(s). Each router >>>>> maintains routes to all reachable destinations at all times, whether = or >>>>> not there is currently any demand to deliver packets to those >>>>> destinations. >>>>> >>>>> Upper Layer: >>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>>> >>>>> MANET Domain: TBD >>>>> >>>>> MANET Signaling: >>>>> Sending and exchanging some MANET messages/information. >>>>> >>>>> 2.3.2 Terms Definition of MANET Elements >>>>> >>>>> Node: >>>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>>> MANET signaling. It either runs a MANET routing protocol or participa= te >>>>> in MANET signaling. >>>>> >>>>> Router: >>>>> A MANET node that MUST implement a MANET routing protocol and forward= s >>>>> IP packets not explicitly addressed to itself. >>>>> >>>>> Host: >>>>> A node that is not a router. All destinations in MANET that receive >>>>> delivered data are hosts. >>>>> >>>>> Link: >>>>> A link between two node interfaces. This link may be Logical >>>>> (i.e. virtual) link or physical link. Logical links are between two >>>>> logical interfaces and physical links are between two physical >>>>> interfaces. Links are either unidirectional or bidirectional >>>>> (links may be on-link and off-link: see RFC4861). >>>>> >>>>> >>>>> Physical Link: >>>>> a communication facility or medium over which the nodes can >>>>> communicate at the link layer, i.e., the layer immediately below >>>>> IP. Physical interfaces are the nodes=92 attachment to physical links= . >>>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>>> and shared-media, etc (see link types in ND [RFC4861]). >>>>> >>>>> Logical (virtual) Link: >>>>> a communication facility (at L3, or upper-layer) over which nodes can >>>>> communicate. This logical link is between two MANET interfaces exists >>>>> if either can be heard by the other. >>>>> >>>>> Link MTU: >>>>> the maximum transmission unit (i.e. maximum unit size in octets), tha= t >>>>> can be conveyed in one transmission unit over the link. >>>>> >>>>> >>>>> Node Interface: >>>>> A node's point of attachment to a link. Each node MUST have at least >>>>> one >>>>> interface that SHOULD be assigned an IP address. If there is/are more >>>>> than one interface(s) per node then the additional interface(s) MAY b= e >>>>> assigned an IP address. If an interface is not assigned to an IP >>>>> address >>>>> it MUST be identified by the MANET routing protocol. An interface MAY >>>>> be >>>>> assigned one or more addresses. >>>>> >>>>> MANET Interface: >>>>> A node interface that participate in; exchange MANET information used >>>>> in >>>>> MANET routing or exchange information in MANET neighbor node discover= y >>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned >>>>> to >>>>> least one address to communicate. A router interface MUST be >>>>> assigned a routable address which is the main address for the >>>>> interface. >>>>> >>>>> >>>>> 2.3.3 Terms Definition of MANET Identifications: >>>>> >>>>> An interface MAY be assigned one or more addresses. If the interface = is >>>>> a logical interface it MAY be assigned to only logical addresses, but >>>>> if >>>>> it is a physical interface MAY be assigned with physical address >>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>>> MANET addresses). >>>>> >>>>> >>>>> MANET Address >>>>> A MANET-subnet, node, or interface address. Node and interface >>>>> addresses >>>>> are either IP addresses or RFC5444 addresses. All subnet addresses ar= e >>>>> unicast IP addresses. >>>>> >>>>> Address Block and TLV: as specified in RFC5444 >>>>> >>>>> Routable address: >>>>> A subnet address which can be a destination address. A router MUST be >>>>> able to distinguish a routable address from a non-routable address. >>>>> Broadcast, and multicast addresses, limited in scope to less than the >>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>>> addresses MAY be considered as routable addresses. >>>>> >>>>> Main address >>>>> A routable address (MANET address) that is assigned to one router's >>>>> MANET interface. >>>>> >>>>> Originator address: >>>>> A node address of the node that originated a MANET message (this >>>>> message >>>>> MUST include the originator address). It MAY be a routable or an >>>>> unroutable address. >>>>> >>>>> subnet prefix >>>>> A bit string that consists of some number of initial bits of an IP >>>>> address. >>>>> >>>>> Interface identifier >>>>> the remaining low-order bits in the node's IP address after the subne= t >>>>> prefix. A number used to identify a node's interface on a link. >>>>> >>>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>>> >>>>> Packet: >>>>> A MANET packet of a header plus payload. These packets are either >>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>>> in IP packet. Packets are generated by nodes to be sent to >>>>> destination(s) through MANET or through the Internet. RFC5444 packets >>>>> information MAY not be used only by MANET routers. >>>>> >>>>> Message: >>>>> A MANET data message or routing control message. Routing control >>>>> messages are either MANET routing protocol messages or/and RFC5444 >>>>> messages. >>>>> >>>>> Type Length Value coding (TLV): >>>>> A generic way to represent MANET information (as in [RFC5444] and >>>>> [RFC5497]). >>>>> >>>>> Frame: >>>>> A L2 protocol TLV with a header and payload. In some technologies the >>>>> L2 >>>>> operates a MANET routing protocol as a local area networking system. >>>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>>> telecommunication network. >>>>> >>>>> Route Request Message (RREQ) >>>>> A message is used to discover a valid route to a particular >>>>> destination address, called the RREQ Target Node. When a router >>>>> processes a RREQ it learns routing information on how to Originator >>>>> Node. >>>>> >>>>> Route Reply Message (RREP) >>>>> A message is used to disseminate routing information about >>>>> the RREP Target Node to the RREQ Originator Node and the intermediate >>>>> routers. >>>>> >>>>> Route Error Message (RERR) >>>>> A message is used to disseminate the information that a route is >>>>> not available for one or more particular addresses. A RERR message is >>>>> used to indicate that a router does not have a forwarding route >>>>> to one or more particular addresses. >>>>> >>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>>> >>>>> Hop-by-hop Routing: (TBD) >>>>> A dynamic routing that routes to destination by routing table. >>>>> >>>>> Source Routing: (TBD) >>>>> A dynamic routing that its route path is provided in the IP packet. >>>>> >>>>> Route Discovery: TBD >>>>> >>>>> Route Maintenance: TBD >>>>> >>>>> Neighbor discovery: (TBD) >>>>> A node discovers neighbors only if the node receives from it's >>>>> neighbors. >>>>> >>>>> >>>>> Multipoint relay (MPR): (TBD) >>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>>> its selection of router X1 as an MPR in a recent HELLO message. >>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>>> participate in the flooding process of messages received from >>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>>> declare link-state information for the link from X1 to Y1. It may >>>>> also be both at the same time. >>>>> >>>>> MPR selector: >>>>> A router, Y, is a flooding/routing MPR selector of router X if >>>>> router Y has selected router X as a flooding/routing MPR. >>>>> >>>>> Router Parameters: >>>>> boolean or numerical values, specified for each router, and not >>>>> specific to an interface. A router MAY change router parameter >>>>> values at any time, subject to some MANET constraints. >>>>> >>>>> MANET Routing Metric: >>>>> A MANET routing cost that is governed by specific rules and propertie= s >>>>> defined by the MANET routing protocol which captures specific link or >>>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>>> LQI, >>>>> etc. >>>>> >>>>> Distance Vector Metric >>>>> A metric class related to rules of the MANET interface and MANET path >>>>> distance. The metric can be calculated by the distance vector routing >>>>> algorithm class used by the MANET routing protocol. A metric of the >>>>> distance a message or piece of information has traversed. The minimum >>>>> value of distance is the number of IP hops traversed. >>>>> >>>>> Link State Metric >>>>> A metric type related to the MANET network-topology status and logica= l >>>>> links' states. This metric is calculated by the link state routing >>>>> algorithm class used by the MANET routing protocol. A metric type may= be >>>>> EXT, LQL, etc. >>>>> >>>>> Link Metric: TBD >>>>> >>>>> Neighbor Metric: TBD >>>>> >>>>> Path accumulated: >>>>> The RREQ message accumulates intermediate routers that are in path to >>>>> destination(s). >>>>> >>>>> Protocol Sequence Number: >>>>> A Sequence Number related to a MANET protocol that maintained by each >>>>> protocol subsystem process. This sequence number is used by other >>>>> subsystems to identify the temporal order of protocol information >>>>> generated. >>>>> >>>>> Router Sequence Number: >>>>> A router sequence number is maintained by each router process. The >>>>> sequence number is used by other routers to identify the temporal >>>>> order of routing information generated and ensure loop-free routes. >>>>> >>>>> MANET Information Base: >>>>> A collection of information (in Table or Cache structure) maintained >>>>> by MANET protocols and which is to be made available to MANET routing >>>>> protocols. An Information Base may be associated with a MANET router >>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB= ). >>>>> >>>>> RIB Entry: >>>>> The RIB entry is a conceptual data structure. Implementations may use >>>>> any internal representation that conforms to the semantics of a route >>>>> as specified in the router specification. >>>>> >>>>> 3. IP Considerations and Terminology >>>>> >>>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>>> run/implement at least one MANET routing protocol. The >>>>> terminologies described in this document can be used for >>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>>> >>>>> IP address: >>>>> IPv4 addresses or IPv6 addresses. >>>>> >>>>> IP Packet: >>>>> The packet header plus payload as specified in [RFC791] and [RFC2460] >>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as >>>>> specified by RFC5498. >>>>> >>>>> Mobile IP considerations: >>>>> Mobile IP terms are provided in [RFC6275], and this technology >>>>> assists nodes while connected through the Internet domain(s). MANET >>>>> is an infrastructure-less network that is able to communicate with >>>>> the Internet (i.e. an IP infrastructure network). >>>>> >>>>> 4. Security Consideration and Terminology >>>>> >>>>> It is RECOMMENDED that MANET routing protocols consider security >>>>> issues because the MANET's transmission medium is wireless which make >>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>>> routing information while traversing the MANET MAY be used by an >>>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>>> >>>>> The following are some terminology related to MANET threats and >>>>> security. >>>>> >>>>> Attacker: A node, present in the network and which intentionally seek= s >>>>> to compromise information based in MANET router(s). The Attacker MAY = be >>>>> a compromised MANET router if obtained MANET identity or routing >>>>> information. >>>>> >>>>> Compromised MANET Router: An attacker router, present in MANET and >>>>> which generates syntactically correct routing control messages. Contr= ol >>>>> messages emitted by compromised router(s) may contain additional >>>>> information, or omit information, as compared to a control message >>>>> generated by a non-compromised router located in the same MANET >>>>> topological position. >>>>> >>>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>>> MANET Router. >>>>> >>>>> Jamming Attack: >>>>> The attacker transmits massive amounts of interfering radio traffic, >>>>> which will prevent legitimate traffic (e.g., routing and data traffic= ) >>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>>> influencing Legitimate MANET Router to transmit unnecessary >>>>> information. >>>>> >>>>> Eavesdropping: >>>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>>> information or the transmitted data information from its neighbor's >>>>> transmitted radio packet. Attacker=92s processes MANY be used by atta= cker >>>>> to mislead routing. Eavesdropping does not pose a direct threat to th= e >>>>> MANET or to its routing. >>>>> >>>>> Identity Spoofing: >>>>> Attacker sends routing messages, pretending to have the MANET identit= y >>>>> of another node. >>>>> >>>>> Link Spoofing: >>>>> Compromised MANET router sends routing messages to neighbor node(s) >>>>> providing incorrect set of link information. >>>>> >>>>> Replay Attack: >>>>> A Compromised router in one MANET region records control traffic >>>>> information and replays the recorded information in a different MANET >>>>> region (this type of attack is also called the Wormhole attack). >>>>> >>>>> Broadcast Storm: >>>>> Compromised MANET router may attack the MANET by attempting to change >>>>> the MANET flooding algorithm(s) to increase routing overheads or/and = to >>>>> increase the route discovery delay. Broadcast storm degrades the data >>>>> traffic delivery and MANET performance. >>>>> >>>>> Falsification in MANET: >>>>> The compromised MANET router sends false routing information into >>>>> MANET. >>>>> False routing information received in MANET, MAY create unrealistic >>>>> information bases. >>>>> >>>>> ICMP Attacks: >>>>> The generation of ICMPv6 error messages may be used by compromised >>>>> MANET >>>>> router to attempt DoS attacks by sending an error-causing source >>>>> routing >>>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>>> the >>>>> upper-layer processes, it is possible to perform attacks on the upper >>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>>> RECOMMENDED to perform some form of validation to ICMP messages (usin= g >>>>> the information contained in the payload of the ICMP message) before >>>>> acting upon them. >>>>> >>>>> Source Routing Attacks: TBD >>>>> >>>>> Acknowledgments: >>>>> >>>>> This work has used/modified terms of the following documents: RFC2462= , >>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>>> Gratefully acknowledge to the IETF community and all contributions. >>>>> >>>>> Reference: >>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>>> NHDP", Work in progress, March, 2012. >>>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>>> Networks", John Wiley & Sons, March 2007. >>>>> ISBN: 978-0-471-75688-0. >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> I hope to get some advise from the Internet community to make the >>>>> definitions more suitable/accurate, because I MAY misunderstood. >>>>> Thanking you, >>>>> >>>>> Best Regards >>>>> >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > 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 -- Dan He --------------------- Tel: +44-788-686-3428 --_000_0261930938C04F608814E680A4894F33ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <58ADB34B284E594DBFBC5E1B99302515@cisco.com> Content-Transfer-Encoding: quoted-printable Looks like this was a "respond to me" instead of a "respond = to the list". I'm forwarding it along.
Stan


Begin forwarded message:

From: Danie= l He <drdanhe@gmail.com>
Subject: Re= : [manet] MANET Terminology Update
Date: July = 23, 2012 11:01:37 AM EDT
To: "= ;Stan Ratliff (sratliff)" <sr= atliff@cisco.com>

If we go this document, we will go a stupid work. I agree with Stan,&n= bsp; don't support it as well.
Regards
Dan

On 23 July 2012 15:59, Stan Ratliff (sratliff) <= span dir=3D"ltr"> <sratliff@cisco.= com> wrote:
I'm going to "+1" one (and only one) sentence in this email t= hread:

>
> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
>> I do not see the need for this terminology document in MANET:
>

In my opinion as a working group participant, this is an unnecessary distra= ction for the working group, and will not result in a meaningful document. = I will not support it.

Regards,
Stan




On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote:

> Hi
>
> Comment inline below:
>
> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
>> I do not see the need for this terminology document in MANET:
>>
>>      o       The RFCs published by t= he WG all do a good job of defining their proper
>>              terminology and co= nventions in the sections, aptly named to this
>>              effect -- and some= thing which both the WG and the IESG has been very
>>              vigilant in ensuri= ng.
>
> Agree
>
>>
>>      o       Extracting this termino= logy, to present without the context of the RFC in
>>
>>              which they are int= roduced and used, is both futile and a source
>>              of errors and conf= usion.
>
> It is not extracting any thing it is locating information in easy
> location to be reached efficiently by researchers, or other WG
> participants. In another reason, for example the RFC5444 and RFC6130 > is providing a MANET standard, while any RFC in this WG is specifying<= br> > its own terminology and message format, but the reason was to bring > RFCs to have similar formating functions. The terminology RFCs in many=
> WGs does the same. RFC2501 is doing a good job to bring understanding<= br> > of MANET which the terminology informational RFCs are doing in each > concept/group-charter.
>
>>
>>      o       The domain evolves, new= protocols appear and introduce new concepts,
>>              terms. This is cap= tured by carefully defining such in the RFC specifying
>>              that protocol. Any= terminology document (aside from all its other issues,
>>              indicated in this = list) would likely be obsolete and incomplete before
>> the
>>              ink with which it = was written was dry.
>
> So when new concepts appear any WG needs to prepare updates I-D to
> their information/standards/experiments so that knowledge is
> consistent and concepts are updated as will (including terminology
> document can be updated). Please note that our documents in MANET are<= br> > a source of information to any participant in IETF, so we need to
> focus to not only produce new concepts/work but we see into
> update/obsolete previous work if possible/necessary. other wise why > did the IETF make an option possibility to *update* and *obsolete* if<= br> > they are not needed for WGs.
>
>>
>>      o       All RFCs in MANET uses = no more than a small subset of the total MANET
>>              (and Internet) ter= minology. A collective terminology document would,
>>              therefore, necessa= rily be adding entropy to any single RFC and to the
>>              WG (and to impleme= nters of the WG protocols).
>
> Please note that the bigest reason of terminology is that when WG
> participants discuss things they don't misunderstand. Please note
> there are many times in MANET WG there are misunderstood in technical<= br> > terms (I have references on the list to many incidence if you ask), so=
> if experts have this problem we need to solve it by a RFC document, > also we need to give the protocol user a sense of the general/specific=
> terminology (as we have MANET general format, MANET general
> understanding, MANET general direction).
>
>>
>>      o       Certainly, a large numb= er of terms in this document are entirely out of
>> scope
>>              (such as those per= taining to non-MANET developed concepts or protocols,
>>              e.g., those develo= ped in other parts of the IETF), are useless for the WG
>>              (such as, but not = exclusively, "communication channel" and "communication
>>
>>              medium"), are= by nature ambiguous (such as, but not exclusively, "Upper
>> Layer"
>>              and "Node&quo= t;), carry a legacy that renders them difficult to use (such as,
>> but
>>              not exclusively, &= quot;Logical (virtual) Link", "Physical Link", and "Lin= k").
>>
>
> I disagree that thoes terms are out of scope of the I-D of the MANETs<= br> > context terminology, because those terms you mentioned were used in > one/some MANET RFCs, so they need to be explained to bring all terms > together to make overall knowledge to internet community. Your
> argument is right only if we are not specifying network-protocols, so<= br> > because we are doing a type of network, then our documents for it
> SHOULD be *connected* by some combined meaning/knowledge *words*, so > other (i.e. all internet community) can understand, without any
> possibility of misunderstanding (there are many examples I can give if=
> you want).
>
> I thank you for your comments, and I will prepare a new version for th= e I-D,
>
> Best Regards
>
> Abdussalam Baryun
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote:
>>>>
>>>>> Dear All
>>>>>
>>>>> I completed the first version of draft on terminology = and submited the
>>>>> draft yesterday (with getting some techniq problem), b= ut needed to
>>>>> post to know the community feedback and advise. There = are other terms
>>>>> that was not yet included which will need some advise = from you.
>>>>> Thanking you,
>>>>>
>>>>> +++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;++
>>>>> Abbreviations Used in The submitted Document
>>>>>
>>>>> AH   Authentication Header
>>>>> DAD  Duplicate Address Detection
>>>>> DPD  Duplicate Packet Detection
>>>>> DoS  Denial of Service
>>>>> ESP  Encapsulating Security Payload
>>>>> IP   IPv4 or IPv6
>>>>> ICMP Internet Control Message Protocol
>>>>> IIB  Interface Information Base
>>>>> ETX  Estimated Expected number of Transmission >>>>> FIB  Forwarding Information Base
>>>>> LQI  Link Quality Indicator
>>>>> L2   Data Link Layer (i.e. 2nd layer in ISO model= )
>>>>> L3   Internet Layer (i.e. 3rd layer in ISO model)=
>>>>> LLN  Low power and Lossy Network
>>>>> MAC  Mediam Access Control
>>>>> MIB  Management Information Base
>>>>> MTU  Maximum Transmission Unit
>>>>> NBMA Non-Broadcast Multi-Access link
>>>>> NHDP Neighborhood Discovery Protocol
>>>>> ND   IP Neighbor Discovery
>>>>> OSPF Open Shortest Path First
>>>>> RIB  Routing Information Base
>>>>> SMF  Simplified Multicast Forwarding
>>>>> TCP  Transmission Control Protocol
>>>>> UDP  User Datagram Protocol
>>>>>
>>>>> 2.3 Definitions for MANET Terms
>>>>>
>>>>> 2.3.1 Terms Definition of MANET Communication:
>>>>>
>>>>> Communications=92 Technology or Facility:
>>>>> The means employed by two or more devices/subsystems t= o transfer
>>>>> and/or receive information between them in one way or = two way
>>>>> communication.  MANET communications often uses t= he wireless
>>>>> transmission medium(s) and MAY use some wired mediums = (e.g. free
>>>>> space, air, water, antenna, coaxial cables, etc.)
>>>>>
>>>>> Communication Medium:
>>>>> The transceiver system (e.g. such as L2 systems, IEEE8= 02.11 systems,
>>>>> satellite system, etc.) that the routing device uses t= o communicates
>>>>> through the transmission medium(s), by providing conne= ctionless and/or
>>>>> connection services that MAY be established. The syste= m medium
>>>>> includes MAC layer and MAY include the physical Layer.=
>>>>>
>>>>> Communication Channel:
>>>>> A subdivision of the physical communication medium (i.= e. radio carrier
>>>>> signal bandwidth, or the system bandwidth) allowing po= ssibly shared
>>>>> independent uses of the medium. Channels may be made a= vailable by
>>>>> subdividing the medium into; distinct time slots, dist= inct spectral
>>>>> bands, or coding sequence, etc.
>>>>>
>>>>> MANET Protocol:
>>>>> The communication system/subsystem that operates and m= aintains the
>>>>> ad hoc communication technology or facility within MAN= ET. MANET routing
>>>>> Protocols often apply distributed algorithms/technique= s to disseminate
>>>>> or forward routing messages within a MANET routing dom= ain.
>>>>>
>>>>> Topology:
>>>>> An abstract representation of a network (physical or l= ogical), as a
>>>>> graph (G) whose topology is defined by a set of router= s/bridges (V)
>>>>> that
>>>>> communicate through set of links (E), where the G =3D = (V, E).
>>>>>
>>>>> Physical-level Topology:
>>>>> A topology of the communication medium networks consis= ts of routing
>>>>> devices and physical links. This topology information = is updated by
>>>>> devices=92 technology in the L2 information Base.
>>>>>
>>>>> Network-level Topology:
>>>>> A topology of the communication system networks consis= ts of routers and
>>>>> links. This topology information is updated by routers= in its RIB.
>>>>>
>>>>> Multihop MANET:
>>>>> A MANET that its node(s) MAY need(s) more than one IP = hop to reach the
>>>>> destination.
>>>>>
>>>>> Reactive Routing:
>>>>> An on-demand based routing protocol that operates rout= e discover and
>>>>> maintainance the route(s), to reach the demanded desti= nation(s).
>>>>>
>>>>> Proactive Routing:
>>>>> A topology RIB based routing protocol that operates ro= utes and
>>>>> maintains
>>>>> the network topology, to reach its known destination(s= ). Each router
>>>>> maintains routes to all reachable destinations at all = times, whether or
>>>>> not there is currently any demand to deliver packets t= o those
>>>>> destinations.
>>>>>
>>>>> Upper Layer:
>>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSP= F).
>>>>>
>>>>> MANET Domain: TBD
>>>>>
>>>>> MANET Signaling:
>>>>> Sending and exchanging some MANET messages/information= .
>>>>>
>>>>> 2.3.2 Terms Definition of MANET Elements
>>>>>
>>>>> Node:
>>>>> A device/subsystem that MUST implement IP and SHOULD p= articipate in
>>>>> MANET signaling. It either runs a MANET routing protoc= ol or participate
>>>>> in MANET signaling.
>>>>>
>>>>> Router:
>>>>> A MANET node that MUST implement a MANET routing proto= col and forwards
>>>>> IP packets not explicitly addressed to itself.
>>>>>
>>>>> Host:
>>>>> A node that is not a router. All destinations in MANET= that receive
>>>>> delivered data are hosts.
>>>>>
>>>>> Link:
>>>>> A link between two node interfaces. This link may be L= ogical
>>>>> (i.e. virtual) link or physical link. Logical links ar= e between two
>>>>> logical interfaces and physical links are between two = physical
>>>>> interfaces. Links are either unidirectional or bidirec= tional
>>>>> (links may be on-link and off-link: see RFC4861).
>>>>>
>>>>>
>>>>> Physical Link:
>>>>> a communication facility or medium over which the node= s can
>>>>> communicate at the link layer, i.e., the layer immedia= tely below
>>>>> IP. Physical interfaces are the nodes=92 attachment to= physical links.
>>>>> Physical Link types are point-to-point, NBMA, multicas= t capable,
>>>>> and shared-media, etc (see link types in ND [RFC4861])= .
>>>>>
>>>>> Logical (virtual) Link:
>>>>> a communication facility (at L3, or upper-layer) over = which nodes can
>>>>> communicate. This logical link is between two MANET in= terfaces exists
>>>>> if either can be heard by the other.
>>>>>
>>>>> Link MTU:
>>>>> the maximum transmission unit (i.e. maximum unit size = in octets), that
>>>>> can be conveyed in one transmission unit over the link= .
>>>>>
>>>>>
>>>>> Node Interface:
>>>>> A node's point of attachment to a link. Each node MUST= have at least
>>>>> one
>>>>> interface that SHOULD be assigned an IP address. If th= ere is/are more
>>>>> than one interface(s) per node then the additional int= erface(s) MAY be
>>>>> assigned an IP address. If an interface is not assigne= d to an IP
>>>>> address
>>>>> it MUST be identified by the MANET routing protocol. A= n interface MAY
>>>>> be
>>>>> assigned one or more addresses.
>>>>>
>>>>> MANET Interface:
>>>>> A node interface that participate in; exchange MANET i= nformation used
>>>>> in
>>>>> MANET routing or exchange information in MANET neighbo= r node discovery
>>>>> (e.g as the term used in RFC6130). A MANET interface M= UST be assigned
>>>>> to
>>>>> least one  address to communicate. A router inter= face MUST be
>>>>> assigned a routable address which is the main address = for the
>>>>> interface.
>>>>>
>>>>>
>>>>> 2.3.3 Terms Definition of MANET Identifications:
>>>>>
>>>>> An interface MAY be assigned one or more addresses. If= the interface is
>>>>> a logical interface it MAY be assigned to only logical= addresses, but
>>>>> if
>>>>> it is a physical interface MAY be assigned with physic= al address
>>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP= addresses,
>>>>> MANET addresses).
>>>>>
>>>>>
>>>>> MANET Address
>>>>> A MANET-subnet, node, or interface address. Node and i= nterface
>>>>> addresses
>>>>> are either IP addresses or RFC5444 addresses. All subn= et addresses are
>>>>> unicast IP addresses.
>>>>>
>>>>> Address Block and TLV: as specified in RFC5444
>>>>>
>>>>> Routable address:
>>>>> A subnet address which can be a destination address. A= router MUST be
>>>>> able to distinguish a routable address from a non-rout= able address.
>>>>> Broadcast, and multicast addresses, limited in scope t= o less than the
>>>>> entire MANET, MUST NOT be considered as routable addre= sses. Anycast
>>>>> addresses MAY be considered as routable addresses.
>>>>>
>>>>> Main address
>>>>> A routable address (MANET address) that is assigned to= one router's
>>>>> MANET interface.
>>>>>
>>>>> Originator address:
>>>>> A node address of the node that originated a MANET mes= sage (this
>>>>> message
>>>>> MUST include the originator address). It MAY be a rout= able or an
>>>>> unroutable address.
>>>>>
>>>>> subnet prefix
>>>>> A bit string that consists of some number of initial b= its of an IP
>>>>> address.
>>>>>
>>>>> Interface identifier
>>>>> the remaining low-order bits in the node's IP address = after the subnet
>>>>> prefix. A number used to identify a node's interface o= n a link.
>>>>>
>>>>> 2.3.4 Terms Definition of MANET exchange information f= ormats:
>>>>>
>>>>> Packet:
>>>>> A MANET packet of a header plus payload. These packets= are either
>>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be = encapsulated
>>>>> in IP packet. Packets are generated by nodes to be sen= t to
>>>>> destination(s) through MANET or through the Internet. = RFC5444 packets
>>>>> information MAY not be used only by MANET routers.
>>>>>
>>>>> Message:
>>>>> A MANET data message or routing control message. Routi= ng control
>>>>> messages are either MANET routing protocol messages or= /and RFC5444
>>>>> messages.
>>>>>
>>>>> Type Length Value coding (TLV):
>>>>> A generic way to represent MANET information (as in [R= FC5444] and
>>>>> [RFC5497]).
>>>>>
>>>>> Frame:
>>>>> A L2 protocol TLV with a header and payload. In some t= echnologies the
>>>>> L2
>>>>> operates a MANET routing protocol as a local area netw= orking system.
>>>>> Frames MAY encapsulate MANET packets to be tunneled th= rough a
>>>>> telecommunication network.
>>>>>
>>>>> Route Request Message (RREQ)
>>>>> A message is used to discover a valid route to a parti= cular
>>>>> destination address, called the RREQ Target Node. When= a router
>>>>> processes a RREQ it learns routing information on how = to Originator
>>>>> Node.
>>>>>
>>>>> Route Reply Message (RREP)
>>>>> A message is used to disseminate routing information a= bout
>>>>> the RREP Target Node to the RREQ Originator Node and t= he intermediate
>>>>> routers.
>>>>>
>>>>> Route Error Message (RERR)
>>>>> A message is used to disseminate the information that = a route is
>>>>> not available for one or more particular addresses. A = RERR message is
>>>>> used to indicate that a router does not have a forward= ing route
>>>>> to one or more particular addresses.
>>>>>
>>>>> 2.3.5 Terms Definition Related to MANET Protocol Opera= tion:
>>>>>
>>>>> Hop-by-hop Routing: (TBD)
>>>>> A dynamic routing that routes to destination by routin= g table.
>>>>>
>>>>> Source Routing: (TBD)
>>>>> A dynamic routing that its route path is provided in t= he IP packet.
>>>>>
>>>>> Route Discovery: TBD
>>>>>
>>>>> Route Maintenance: TBD
>>>>>
>>>>> Neighbor discovery: (TBD)
>>>>> A node discovers neighbors only if the node receives f= rom it's
>>>>> neighbors.
>>>>>
>>>>>
>>>>> Multipoint relay (MPR): (TBD)
>>>>> A router X1 is an MPR for a router Y1, if router Y1 ha= s indicated
>>>>> its selection of router X1 as an MPR in a recent HELLO= message.
>>>>> Router X1 may be a flooding MPR for Y1 if it is indica= ted to
>>>>> participate in the flooding process of messages receiv= ed from
>>>>> router Y1, or it may be a routing MPR for Y1, if it is= indicated to
>>>>> declare link-state information for the link from X1 to= Y1. It may
>>>>> also be both at the same time.
>>>>>
>>>>> MPR selector:
>>>>> A router, Y, is a flooding/routing MPR selector of rou= ter X if
>>>>> router Y has selected router X as a flooding/routing M= PR.
>>>>>
>>>>> Router Parameters:
>>>>> boolean or numerical values, specified for each router= , and not
>>>>> specific to an interface. A router MAY change router p= arameter
>>>>> values at any time, subject to some MANET constraints.=
>>>>>
>>>>> MANET Routing Metric:
>>>>> A MANET routing cost that is governed by specific rule= s and properties
>>>>> defined by the MANET routing protocol which captures s= pecific link or
>>>>> node characteristics. Examples of basic metrics are ho= p-count, ETX,
>>>>> LQI,
>>>>> etc.
>>>>>
>>>>> Distance Vector Metric
>>>>> A metric class related to rules of the MANET interface= and MANET path
>>>>> distance. The metric can be calculated by the distance= vector routing
>>>>> algorithm class used by the MANET routing protocol. A = metric of the
>>>>> distance a message or piece of information has travers= ed. The minimum
>>>>> value of distance is the number of IP hops traversed.<= br> >>>>>
>>>>> Link State Metric
>>>>> A metric type related to the MANET network-topology st= atus and logical
>>>>> links' states. This metric is calculated by the link s= tate routing
>>>>> algorithm class used by the MANET routing protocol. A = metric type maybe
>>>>> EXT, LQL, etc.
>>>>>
>>>>> Link Metric: TBD
>>>>>
>>>>> Neighbor Metric: TBD
>>>>>
>>>>> Path accumulated:
>>>>> The RREQ message accumulates intermediate routers that= are in path to
>>>>> destination(s).
>>>>>
>>>>> Protocol Sequence Number:
>>>>> A Sequence Number related to a MANET protocol that mai= ntained by each
>>>>> protocol subsystem process. This sequence number is us= ed by other
>>>>> subsystems to identify the temporal order of protocol = information
>>>>> generated.
>>>>>
>>>>> Router Sequence Number:
>>>>> A router sequence number is maintained by each router = process. The
>>>>> sequence number is used by other routers to identify t= he temporal
>>>>> order of routing information generated and ensure loop= -free routes.
>>>>>
>>>>> MANET Information Base:
>>>>> A collection of information (in Table or Cache structu= re) maintained
>>>>> by MANET protocols and which is to be made available t= o MANET routing
>>>>> protocols. An Information Base may be associated with = a MANET router
>>>>> or with MANET interface (e.g. route request table, IIB= , RIB, FIB, MIB).
>>>>>
>>>>> RIB Entry:
>>>>> The RIB entry is a conceptual data structure. Implemen= tations may use
>>>>> any internal representation that conforms to the seman= tics of a route
>>>>> as specified in the router specification.
>>>>>
>>>>> 3. IP Considerations and Terminology
>>>>>
>>>>> All MANET nodes MUST implement IP and all MANET router= s MUST
>>>>> run/implement  at least one MANET routing protoco= l. The
>>>>> terminologies described in this document can be used f= or
>>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be u= sed in IPv6
>>>>> packets but IPv6 addresses MUST not be in IPv4 packets= .
>>>>>
>>>>> IP address:
>>>>> IPv4 addresses or IPv6 addresses.
>>>>>
>>>>> IP Packet:
>>>>> The packet header plus payload as specified in [RFC791= ] and [RFC2460]
>>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC= 5444 packets as
>>>>> specified by RFC5498.
>>>>>
>>>>> Mobile IP considerations:
>>>>> Mobile IP terms are provided in [RFC6275], and this te= chnology
>>>>> assists nodes while connected through the Internet dom= ain(s). MANET
>>>>> is an infrastructure-less network that is able to comm= unicate with
>>>>> the Internet (i.e. an IP infrastructure network).
>>>>>
>>>>> 4. Security Consideration and Terminology
>>>>>
>>>>> It is RECOMMENDED that MANET routing protocols conside= r security
>>>>> issues because the MANET's transmission medium is wire= less which make
>>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some sit= uations the
>>>>> routing information while traversing the MANET MAY be = used by an
>>>>> intruder node, to obtain MANET data traffic or/and att= ack the MANET
>>>>> [HERBERG]. Forwarding protocols that use DPD technique= s MAY be
>>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MA= Y be secured
>>>>> by using IPsec, AH, DAD, and ESP techniques, and other= . However,
>>>>> it is RECOMMENDED that MANET detects attackers and pos= sible threats.
>>>>>
>>>>> The following are some terminology related to MANET th= reats and
>>>>> security.
>>>>>
>>>>> Attacker: A node, present in the network and which int= entionally seeks
>>>>> to compromise information based in MANET router(s). Th= e Attacker MAY be
>>>>> a compromised MANET router if obtained MANET identity = or routing
>>>>> information.
>>>>>
>>>>> Compromised MANET Router: An attacker router, present = in MANET and
>>>>> which generates syntactically correct routing control = messages. Control
>>>>> messages emitted by compromised router(s) may contain = additional
>>>>> information, or omit information, as compared to a con= trol message
>>>>> generated by a non-compromised router located in the s= ame MANET
>>>>> topological position.
>>>>>
>>>>> Legitimate MANET Router: A MANET router, which is not = a Compromised
>>>>> MANET Router.
>>>>>
>>>>> Jamming Attack:
>>>>> The attacker transmits massive amounts of interfering = radio traffic,
>>>>> which will prevent legitimate traffic (e.g., routing a= nd data traffic)
>>>>> on all or part of the MANET. Indirect jamming attacks = MAY occur by
>>>>> influencing Legitimate MANET Router to transmit unnece= ssary
>>>>> information.
>>>>>
>>>>> Eavesdropping:
>>>>> Obtaining a copy by the attacker of the transmitted MA= NET routing
>>>>> information or the transmitted data information from i= ts neighbor's
>>>>> transmitted radio packet. Attacker=92s processes MANY = be used by attacker
>>>>> to mislead routing. Eavesdropping does not pose a dire= ct threat to the
>>>>> MANET or to its routing.
>>>>>
>>>>> Identity Spoofing:
>>>>> Attacker sends routing messages, pretending to have th= e MANET identity
>>>>> of another node.
>>>>>
>>>>> Link Spoofing:
>>>>> Compromised MANET router sends routing messages to nei= ghbor node(s)
>>>>> providing incorrect set of link information.
>>>>>
>>>>> Replay Attack:
>>>>> A Compromised router in one MANET region records contr= ol traffic
>>>>> information and replays the recorded information in a = different MANET
>>>>> region (this type of attack is also called the Wormhol= e attack).
>>>>>
>>>>> Broadcast Storm:
>>>>> Compromised MANET router may attack the MANET by attem= pting to change
>>>>> the MANET flooding algorithm(s) to increase routing ov= erheads or/and to
>>>>> increase the route discovery delay. Broadcast storm de= grades the data
>>>>> traffic delivery and MANET performance.
>>>>>
>>>>> Falsification in MANET:
>>>>> The compromised MANET router sends false routing infor= mation into
>>>>> MANET.
>>>>> False routing information received in MANET, MAY creat= e unrealistic
>>>>> information bases.
>>>>>
>>>>> ICMP Attacks:
>>>>> The generation of ICMPv6 error messages may be used by= compromised
>>>>> MANET
>>>>> router to attempt DoS attacks by sending an error-caus= ing source
>>>>> routing
>>>>> header in back-to-back datagrams. As the ICMP messages= are passed to
>>>>> the
>>>>> upper-layer processes, it is possible to perform attac= ks on the upper
>>>>> layer protocols (e.g., UDP, TCP). Protocols at the upp= er layers are
>>>>> RECOMMENDED to perform some form of validation to ICMP= messages (using
>>>>> the information contained in the payload of the ICMP m= essage) before
>>>>> acting upon them.
>>>>>
>>>>> Source Routing Attacks: TBD
>>>>>
>>>>> Acknowledgments:
>>>>>
>>>>> This work has used/modified terms of the following doc= uments: RFC2462,
>>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, = RFC5444,
>>>>> RFC6130,  RFC6621, [AODVv2], [OLSRv2], and [HERBE= RG],
>>>>> Gratefully acknowledge to the IETF community and all c= ontributions.
>>>>>
>>>>> Reference:
>>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Secur= ity Threats for
>>>>>           NHDP", Work in= progress, March, 2012.
>>>>> [ANJUM]   Anjum, F. and Mouchtaris, P. "Secu= rity for Wireless Ad Hoc
>>>>>           Networks", Joh= n Wiley & Sons, March 2007.
>>>>>           ISBN: 978-0-471-756= 88-0.
>>>>> +++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;+++++++++++++++= ;
>>>>>
>>>>> I hope to get some advise from the Internet community = to make the
>>>>> definitions more suitable/accurate, because I MAY misu= nderstood.
>>>>> Thanking you,
>>>>>
>>>>> Best Regards
>>>>>
>>>>> Abdussalam Baryun
>>>>> University of Glamorgan, UK
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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



--
Dan He
---------------------
Tel: +44-788-686-3428


--_000_0261930938C04F608814E680A4894F33ciscocom_-- From jpmacker@gmail.com Mon Jul 23 08:37: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 2256C11E807F for ; Mon, 23 Jul 2012 08:37:06 -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 wILKQ3A6Vwux for ; Mon, 23 Jul 2012 08:37:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E872811E8096 for ; Mon, 23 Jul 2012 08:37:03 -0700 (PDT) Received: by yhq56 with SMTP id 56so6127415yhq.31 for ; Mon, 23 Jul 2012 08:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=cs9jwicnShkMCQ8s1LJOdg6AKN29DGiGleShjgohJ20=; b=dfZskag9Ib5rJ5IZglYfXnW58pdYLiCevedA/gyR3r5lfcrkyzjvljnUepRvGFzxIo x++2aeIJ9GbaEX8KDNH7SDXQT64QAHbk8NV7ztmiQ3kOw5s2N4/bLkV4NJ5s0aCJCoY/ OxJDobmEbv40UStmvnq6IUdLbM+Om+iauzvE0vXPnpW6abNZP86tKJ4fMpX2pkhWXeG8 oQk0rZ/uouuGESjKrtrfQFOUJauMGEhY9cTIy3izsh91kytQSWu0MB19AhS5qMn2Op57 M4ahbRh5AwKdsAv8lQXyQ6uHXCl5UiCnlRr4CdGSPzTx9saA5roRlgq3/fAuh+shtVEL +sXw== Received: by 10.236.161.72 with SMTP id v48mr14895514yhk.84.1343057823449; Mon, 23 Jul 2012 08:37:03 -0700 (PDT) Received: from ?IPv6:2002:458c:9704:1234:3cc8:3c42:cdb1:edb9? ([2002:458c:9704:1234:3cc8:3c42:cdb1:edb9]) by mx.google.com with ESMTPS id q3sm12680492ani.15.2012.07.23.08.37.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 08:37:03 -0700 (PDT) References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <30FD7097-ED54-4D5C-A1A2-7D45F62AFDB0@gmail.com> X-Mailer: iPhone Mail (9B206) From: Joe Macker Date: Mon, 23 Jul 2012 11:40:06 -0400 To: "Stan Ratliff (sratliff)" Cc: manet , Thomas Heide Clausen , Abdussalam Baryun Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:37:06 -0000 Additional +1=20 I believe there is no need for this Sent from my iPhone On Jul 23, 2012, at 10:59 AM, "Stan Ratliff (sratliff)" = wrote: > I'm going to "+1" one (and only one) sentence in this email thread:=20 >=20 >>=20 >> On 7/6/12, Thomas Heide Clausen wrote: >>> I do not see the need for this terminology document in MANET: >>=20 >=20 > In my opinion as a working group participant, this is an unnecessary distr= action for the working group, and will not result in a meaningful document. I= will not support it.=20 >=20 > Regards, > Stan >=20 >=20 >=20 >=20 > On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote: >=20 >> Hi >>=20 >> Comment inline below: >>=20 >> On 7/6/12, Thomas Heide Clausen wrote: >>> I do not see the need for this terminology document in MANET: >>>=20 >>> o The RFCs published by the WG all do a good job of defining their= proper >>> terminology and conventions in the sections, aptly named to this >>> effect -- and something which both the WG and the IESG has been v= ery >>> vigilant in ensuring. >>=20 >> Agree >>=20 >>>=20 >>> o Extracting this terminology, to present without the context of t= he RFC in >>>=20 >>> which they are introduced and used, is both futile and a source >>> of errors and confusion. >>=20 >> It is not extracting any thing it is locating information in easy >> location to be reached efficiently by researchers, or other WG >> participants. In another reason, for example the RFC5444 and RFC6130 >> is providing a MANET standard, while any RFC in this WG is specifying >> its own terminology and message format, but the reason was to bring >> RFCs to have similar formating functions. The terminology RFCs in many >> WGs does the same. RFC2501 is doing a good job to bring understanding >> of MANET which the terminology informational RFCs are doing in each >> concept/group-charter. >>=20 >>>=20 >>> o The domain evolves, new protocols appear and introduce new conce= pts, >>> terms. This is captured by carefully defining such in the RFC spe= cifying >>> that protocol. Any terminology document (aside from all its other= issues, >>> indicated in this list) would likely be obsolete and incomplete b= efore >>> the >>> ink with which it was written was dry. >>=20 >> So when new concepts appear any WG needs to prepare updates I-D to >> their information/standards/experiments so that knowledge is >> consistent and concepts are updated as will (including terminology >> document can be updated). Please note that our documents in MANET are >> a source of information to any participant in IETF, so we need to >> focus to not only produce new concepts/work but we see into >> update/obsolete previous work if possible/necessary. other wise why >> did the IETF make an option possibility to *update* and *obsolete* if >> they are not needed for WGs. >>=20 >>>=20 >>> o All RFCs in MANET uses no more than a small subset of the total M= ANET >>> (and Internet) terminology. A collective terminology document wou= ld, >>> therefore, necessarily be adding entropy to any single RFC and to= the >>> WG (and to implementers of the WG protocols). >>=20 >> Please note that the bigest reason of terminology is that when WG >> participants discuss things they don't misunderstand. Please note >> there are many times in MANET WG there are misunderstood in technical >> terms (I have references on the list to many incidence if you ask), so >> if experts have this problem we need to solve it by a RFC document, >> also we need to give the protocol user a sense of the general/specific >> terminology (as we have MANET general format, MANET general >> understanding, MANET general direction). >>=20 >>>=20 >>> o Certainly, a large number of terms in this document are entirely= out of >>> scope >>> (such as those pertaining to non-MANET developed concepts or prot= ocols, >>> e.g., those developed in other parts of the IETF), are useless fo= r the WG >>> (such as, but not exclusively, "communication channel" and "commu= nication >>>=20 >>> medium"), are by nature ambiguous (such as, but not exclusively, "= Upper >>> Layer" >>> and "Node"), carry a legacy that renders them difficult to use (s= uch as, >>> but >>> not exclusively, "Logical (virtual) Link", "Physical Link", and "= Link"). >>>=20 >>=20 >> I disagree that thoes terms are out of scope of the I-D of the MANETs >> context terminology, because those terms you mentioned were used in >> one/some MANET RFCs, so they need to be explained to bring all terms >> together to make overall knowledge to internet community. Your >> argument is right only if we are not specifying network-protocols, so >> because we are doing a type of network, then our documents for it >> SHOULD be *connected* by some combined meaning/knowledge *words*, so >> other (i.e. all internet community) can understand, without any >> possibility of misunderstanding (there are many examples I can give if >> you want). >>=20 >> I thank you for your comments, and I will prepare a new version for the I= -D, >>=20 >> Best Regards >>=20 >> Abdussalam Baryun >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Dear All >>>>>>=20 >>>>>> I completed the first version of draft on terminology and submited th= e >>>>>> draft yesterday (with getting some techniq problem), but needed to >>>>>> post to know the community feedback and advise. There are other terms= >>>>>> that was not yet included which will need some advise from you. >>>>>> Thanking you, >>>>>>=20 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> Abbreviations Used in The submitted Document >>>>>>=20 >>>>>> AH Authentication Header >>>>>> DAD Duplicate Address Detection >>>>>> DPD Duplicate Packet Detection >>>>>> DoS Denial of Service >>>>>> ESP Encapsulating Security Payload >>>>>> IP IPv4 or IPv6 >>>>>> ICMP Internet Control Message Protocol >>>>>> IIB Interface Information Base >>>>>> ETX Estimated Expected number of Transmission >>>>>> FIB Forwarding Information Base >>>>>> LQI Link Quality Indicator >>>>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>>>> LLN Low power and Lossy Network >>>>>> MAC Mediam Access Control >>>>>> MIB Management Information Base >>>>>> MTU Maximum Transmission Unit >>>>>> NBMA Non-Broadcast Multi-Access link >>>>>> NHDP Neighborhood Discovery Protocol >>>>>> ND IP Neighbor Discovery >>>>>> OSPF Open Shortest Path First >>>>>> RIB Routing Information Base >>>>>> SMF Simplified Multicast Forwarding >>>>>> TCP Transmission Control Protocol >>>>>> UDP User Datagram Protocol >>>>>>=20 >>>>>> 2.3 Definitions for MANET Terms >>>>>>=20 >>>>>> 2.3.1 Terms Definition of MANET Communication: >>>>>>=20 >>>>>> Communications=E2=80=99 Technology or Facility: >>>>>> The means employed by two or more devices/subsystems to transfer >>>>>> and/or receive information between them in one way or two way >>>>>> communication. MANET communications often uses the wireless >>>>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>>>> space, air, water, antenna, coaxial cables, etc.) >>>>>>=20 >>>>>> Communication Medium: >>>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>>>> satellite system, etc.) that the routing device uses to communicates >>>>>> through the transmission medium(s), by providing connectionless and/o= r >>>>>> connection services that MAY be established. The system medium >>>>>> includes MAC layer and MAY include the physical Layer. >>>>>>=20 >>>>>> Communication Channel: >>>>>> A subdivision of the physical communication medium (i.e. radio carrie= r >>>>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>>>> independent uses of the medium. Channels may be made available by >>>>>> subdividing the medium into; distinct time slots, distinct spectral >>>>>> bands, or coding sequence, etc. >>>>>>=20 >>>>>> MANET Protocol: >>>>>> The communication system/subsystem that operates and maintains the >>>>>> ad hoc communication technology or facility within MANET. MANET routi= ng >>>>>> Protocols often apply distributed algorithms/techniques to disseminat= e >>>>>> or forward routing messages within a MANET routing domain. >>>>>>=20 >>>>>> Topology: >>>>>> An abstract representation of a network (physical or logical), as a >>>>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>>>> that >>>>>> communicate through set of links (E), where the G =3D (V, E). >>>>>>=20 >>>>>> Physical-level Topology: >>>>>> A topology of the communication medium networks consists of routing >>>>>> devices and physical links. This topology information is updated by >>>>>> devices=E2=80=99 technology in the L2 information Base. >>>>>>=20 >>>>>> Network-level Topology: >>>>>> A topology of the communication system networks consists of routers a= nd >>>>>> links. This topology information is updated by routers in its RIB. >>>>>>=20 >>>>>> Multihop MANET: >>>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach th= e >>>>>> destination. >>>>>>=20 >>>>>> Reactive Routing: >>>>>> An on-demand based routing protocol that operates route discover and >>>>>> maintainance the route(s), to reach the demanded destination(s). >>>>>>=20 >>>>>> Proactive Routing: >>>>>> A topology RIB based routing protocol that operates routes and >>>>>> maintains >>>>>> the network topology, to reach its known destination(s). Each router >>>>>> maintains routes to all reachable destinations at all times, whether o= r >>>>>> not there is currently any demand to deliver packets to those >>>>>> destinations. >>>>>>=20 >>>>>> Upper Layer: >>>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>>>>=20 >>>>>> MANET Domain: TBD >>>>>>=20 >>>>>> MANET Signaling: >>>>>> Sending and exchanging some MANET messages/information. >>>>>>=20 >>>>>> 2.3.2 Terms Definition of MANET Elements >>>>>>=20 >>>>>> Node: >>>>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>>>> MANET signaling. It either runs a MANET routing protocol or participa= te >>>>>> in MANET signaling. >>>>>>=20 >>>>>> Router: >>>>>> A MANET node that MUST implement a MANET routing protocol and forward= s >>>>>> IP packets not explicitly addressed to itself. >>>>>>=20 >>>>>> Host: >>>>>> A node that is not a router. All destinations in MANET that receive >>>>>> delivered data are hosts. >>>>>>=20 >>>>>> Link: >>>>>> A link between two node interfaces. This link may be Logical >>>>>> (i.e. virtual) link or physical link. Logical links are between two >>>>>> logical interfaces and physical links are between two physical >>>>>> interfaces. Links are either unidirectional or bidirectional >>>>>> (links may be on-link and off-link: see RFC4861). >>>>>>=20 >>>>>>=20 >>>>>> Physical Link: >>>>>> a communication facility or medium over which the nodes can >>>>>> communicate at the link layer, i.e., the layer immediately below >>>>>> IP. Physical interfaces are the nodes=E2=80=99 attachment to physical= links. >>>>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>>>> and shared-media, etc (see link types in ND [RFC4861]). >>>>>>=20 >>>>>> Logical (virtual) Link: >>>>>> a communication facility (at L3, or upper-layer) over which nodes can= >>>>>> communicate. This logical link is between two MANET interfaces exists= >>>>>> if either can be heard by the other. >>>>>>=20 >>>>>> Link MTU: >>>>>> the maximum transmission unit (i.e. maximum unit size in octets), tha= t >>>>>> can be conveyed in one transmission unit over the link. >>>>>>=20 >>>>>>=20 >>>>>> Node Interface: >>>>>> A node's point of attachment to a link. Each node MUST have at least >>>>>> one >>>>>> interface that SHOULD be assigned an IP address. If there is/are more= >>>>>> than one interface(s) per node then the additional interface(s) MAY b= e >>>>>> assigned an IP address. If an interface is not assigned to an IP >>>>>> address >>>>>> it MUST be identified by the MANET routing protocol. An interface MAY= >>>>>> be >>>>>> assigned one or more addresses. >>>>>>=20 >>>>>> MANET Interface: >>>>>> A node interface that participate in; exchange MANET information used= >>>>>> in >>>>>> MANET routing or exchange information in MANET neighbor node discover= y >>>>>> (e.g as the term used in RFC6130). A MANET interface MUST be assigned= >>>>>> to >>>>>> least one address to communicate. A router interface MUST be >>>>>> assigned a routable address which is the main address for the >>>>>> interface. >>>>>>=20 >>>>>>=20 >>>>>> 2.3.3 Terms Definition of MANET Identifications: >>>>>>=20 >>>>>> An interface MAY be assigned one or more addresses. If the interface i= s >>>>>> a logical interface it MAY be assigned to only logical addresses, but= >>>>>> if >>>>>> it is a physical interface MAY be assigned with physical address >>>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>>>> MANET addresses). >>>>>>=20 >>>>>>=20 >>>>>> MANET Address >>>>>> A MANET-subnet, node, or interface address. Node and interface >>>>>> addresses >>>>>> are either IP addresses or RFC5444 addresses. All subnet addresses ar= e >>>>>> unicast IP addresses. >>>>>>=20 >>>>>> Address Block and TLV: as specified in RFC5444 >>>>>>=20 >>>>>> Routable address: >>>>>> A subnet address which can be a destination address. A router MUST be= >>>>>> able to distinguish a routable address from a non-routable address. >>>>>> Broadcast, and multicast addresses, limited in scope to less than the= >>>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>>>> addresses MAY be considered as routable addresses. >>>>>>=20 >>>>>> Main address >>>>>> A routable address (MANET address) that is assigned to one router's >>>>>> MANET interface. >>>>>>=20 >>>>>> Originator address: >>>>>> A node address of the node that originated a MANET message (this >>>>>> message >>>>>> MUST include the originator address). It MAY be a routable or an >>>>>> unroutable address. >>>>>>=20 >>>>>> subnet prefix >>>>>> A bit string that consists of some number of initial bits of an IP >>>>>> address. >>>>>>=20 >>>>>> Interface identifier >>>>>> the remaining low-order bits in the node's IP address after the subne= t >>>>>> prefix. A number used to identify a node's interface on a link. >>>>>>=20 >>>>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>>>>=20 >>>>>> Packet: >>>>>> A MANET packet of a header plus payload. These packets are either >>>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>>>> in IP packet. Packets are generated by nodes to be sent to >>>>>> destination(s) through MANET or through the Internet. RFC5444 packets= >>>>>> information MAY not be used only by MANET routers. >>>>>>=20 >>>>>> Message: >>>>>> A MANET data message or routing control message. Routing control >>>>>> messages are either MANET routing protocol messages or/and RFC5444 >>>>>> messages. >>>>>>=20 >>>>>> Type Length Value coding (TLV): >>>>>> A generic way to represent MANET information (as in [RFC5444] and >>>>>> [RFC5497]). >>>>>>=20 >>>>>> Frame: >>>>>> A L2 protocol TLV with a header and payload. In some technologies the= >>>>>> L2 >>>>>> operates a MANET routing protocol as a local area networking system. >>>>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>>>> telecommunication network. >>>>>>=20 >>>>>> Route Request Message (RREQ) >>>>>> A message is used to discover a valid route to a particular >>>>>> destination address, called the RREQ Target Node. When a router >>>>>> processes a RREQ it learns routing information on how to Originator >>>>>> Node. >>>>>>=20 >>>>>> Route Reply Message (RREP) >>>>>> A message is used to disseminate routing information about >>>>>> the RREP Target Node to the RREQ Originator Node and the intermediate= >>>>>> routers. >>>>>>=20 >>>>>> Route Error Message (RERR) >>>>>> A message is used to disseminate the information that a route is >>>>>> not available for one or more particular addresses. A RERR message is= >>>>>> used to indicate that a router does not have a forwarding route >>>>>> to one or more particular addresses. >>>>>>=20 >>>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>>>>=20 >>>>>> Hop-by-hop Routing: (TBD) >>>>>> A dynamic routing that routes to destination by routing table. >>>>>>=20 >>>>>> Source Routing: (TBD) >>>>>> A dynamic routing that its route path is provided in the IP packet. >>>>>>=20 >>>>>> Route Discovery: TBD >>>>>>=20 >>>>>> Route Maintenance: TBD >>>>>>=20 >>>>>> Neighbor discovery: (TBD) >>>>>> A node discovers neighbors only if the node receives from it's >>>>>> neighbors. >>>>>>=20 >>>>>>=20 >>>>>> Multipoint relay (MPR): (TBD) >>>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>>>> its selection of router X1 as an MPR in a recent HELLO message. >>>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>>>> participate in the flooding process of messages received from >>>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>>>> declare link-state information for the link from X1 to Y1. It may >>>>>> also be both at the same time. >>>>>>=20 >>>>>> MPR selector: >>>>>> A router, Y, is a flooding/routing MPR selector of router X if >>>>>> router Y has selected router X as a flooding/routing MPR. >>>>>>=20 >>>>>> Router Parameters: >>>>>> boolean or numerical values, specified for each router, and not >>>>>> specific to an interface. A router MAY change router parameter >>>>>> values at any time, subject to some MANET constraints. >>>>>>=20 >>>>>> MANET Routing Metric: >>>>>> A MANET routing cost that is governed by specific rules and propertie= s >>>>>> defined by the MANET routing protocol which captures specific link or= >>>>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>>>> LQI, >>>>>> etc. >>>>>>=20 >>>>>> Distance Vector Metric >>>>>> A metric class related to rules of the MANET interface and MANET path= >>>>>> distance. The metric can be calculated by the distance vector routing= >>>>>> algorithm class used by the MANET routing protocol. A metric of the >>>>>> distance a message or piece of information has traversed. The minimum= >>>>>> value of distance is the number of IP hops traversed. >>>>>>=20 >>>>>> Link State Metric >>>>>> A metric type related to the MANET network-topology status and logica= l >>>>>> links' states. This metric is calculated by the link state routing >>>>>> algorithm class used by the MANET routing protocol. A metric type may= be >>>>>> EXT, LQL, etc. >>>>>>=20 >>>>>> Link Metric: TBD >>>>>>=20 >>>>>> Neighbor Metric: TBD >>>>>>=20 >>>>>> Path accumulated: >>>>>> The RREQ message accumulates intermediate routers that are in path to= >>>>>> destination(s). >>>>>>=20 >>>>>> Protocol Sequence Number: >>>>>> A Sequence Number related to a MANET protocol that maintained by each= >>>>>> protocol subsystem process. This sequence number is used by other >>>>>> subsystems to identify the temporal order of protocol information >>>>>> generated. >>>>>>=20 >>>>>> Router Sequence Number: >>>>>> A router sequence number is maintained by each router process. The >>>>>> sequence number is used by other routers to identify the temporal >>>>>> order of routing information generated and ensure loop-free routes. >>>>>>=20 >>>>>> MANET Information Base: >>>>>> A collection of information (in Table or Cache structure) maintained >>>>>> by MANET protocols and which is to be made available to MANET routing= >>>>>> protocols. An Information Base may be associated with a MANET router >>>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB= ). >>>>>>=20 >>>>>> RIB Entry: >>>>>> The RIB entry is a conceptual data structure. Implementations may use= >>>>>> any internal representation that conforms to the semantics of a route= >>>>>> as specified in the router specification. >>>>>>=20 >>>>>> 3. IP Considerations and Terminology >>>>>>=20 >>>>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>>>> run/implement at least one MANET routing protocol. The >>>>>> terminologies described in this document can be used for >>>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>>>>=20 >>>>>> IP address: >>>>>> IPv4 addresses or IPv6 addresses. >>>>>>=20 >>>>>> IP Packet: >>>>>> The packet header plus payload as specified in [RFC791] and [RFC2460]= >>>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as= >>>>>> specified by RFC5498. >>>>>>=20 >>>>>> Mobile IP considerations: >>>>>> Mobile IP terms are provided in [RFC6275], and this technology >>>>>> assists nodes while connected through the Internet domain(s). MANET >>>>>> is an infrastructure-less network that is able to communicate with >>>>>> the Internet (i.e. an IP infrastructure network). >>>>>>=20 >>>>>> 4. Security Consideration and Terminology >>>>>>=20 >>>>>> It is RECOMMENDED that MANET routing protocols consider security >>>>>> issues because the MANET's transmission medium is wireless which make= >>>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>>>> routing information while traversing the MANET MAY be used by an >>>>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>>>>=20 >>>>>> The following are some terminology related to MANET threats and >>>>>> security. >>>>>>=20 >>>>>> Attacker: A node, present in the network and which intentionally seek= s >>>>>> to compromise information based in MANET router(s). The Attacker MAY b= e >>>>>> a compromised MANET router if obtained MANET identity or routing >>>>>> information. >>>>>>=20 >>>>>> Compromised MANET Router: An attacker router, present in MANET and >>>>>> which generates syntactically correct routing control messages. Contr= ol >>>>>> messages emitted by compromised router(s) may contain additional >>>>>> information, or omit information, as compared to a control message >>>>>> generated by a non-compromised router located in the same MANET >>>>>> topological position. >>>>>>=20 >>>>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>>>> MANET Router. >>>>>>=20 >>>>>> Jamming Attack: >>>>>> The attacker transmits massive amounts of interfering radio traffic, >>>>>> which will prevent legitimate traffic (e.g., routing and data traffic= ) >>>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>>>> influencing Legitimate MANET Router to transmit unnecessary >>>>>> information. >>>>>>=20 >>>>>> Eavesdropping: >>>>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>>>> information or the transmitted data information from its neighbor's >>>>>> transmitted radio packet. Attacker=E2=80=99s processes MANY be used b= y attacker >>>>>> to mislead routing. Eavesdropping does not pose a direct threat to th= e >>>>>> MANET or to its routing. >>>>>>=20 >>>>>> Identity Spoofing: >>>>>> Attacker sends routing messages, pretending to have the MANET identit= y >>>>>> of another node. >>>>>>=20 >>>>>> Link Spoofing: >>>>>> Compromised MANET router sends routing messages to neighbor node(s) >>>>>> providing incorrect set of link information. >>>>>>=20 >>>>>> Replay Attack: >>>>>> A Compromised router in one MANET region records control traffic >>>>>> information and replays the recorded information in a different MANET= >>>>>> region (this type of attack is also called the Wormhole attack). >>>>>>=20 >>>>>> Broadcast Storm: >>>>>> Compromised MANET router may attack the MANET by attempting to change= >>>>>> the MANET flooding algorithm(s) to increase routing overheads or/and t= o >>>>>> increase the route discovery delay. Broadcast storm degrades the data= >>>>>> traffic delivery and MANET performance. >>>>>>=20 >>>>>> Falsification in MANET: >>>>>> The compromised MANET router sends false routing information into >>>>>> MANET. >>>>>> False routing information received in MANET, MAY create unrealistic >>>>>> information bases. >>>>>>=20 >>>>>> ICMP Attacks: >>>>>> The generation of ICMPv6 error messages may be used by compromised >>>>>> MANET >>>>>> router to attempt DoS attacks by sending an error-causing source >>>>>> routing >>>>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>>>> the >>>>>> upper-layer processes, it is possible to perform attacks on the upper= >>>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>>>> RECOMMENDED to perform some form of validation to ICMP messages (usin= g >>>>>> the information contained in the payload of the ICMP message) before >>>>>> acting upon them. >>>>>>=20 >>>>>> Source Routing Attacks: TBD >>>>>>=20 >>>>>> Acknowledgments: >>>>>>=20 >>>>>> This work has used/modified terms of the following documents: RFC2462= , >>>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>>>> Gratefully acknowledge to the IETF community and all contributions. >>>>>>=20 >>>>>> Reference: >>>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>>>> NHDP", Work in progress, March, 2012. >>>>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>>>> Networks", John Wiley & Sons, March 2007. >>>>>> ISBN: 978-0-471-75688-0. >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>=20 >>>>>> I hope to get some advise from the Internet community to make the >>>>>> definitions more suitable/accurate, because I MAY misunderstood. >>>>>> Thanking you, >>>>>>=20 >>>>>> Best Regards >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> 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 d.sturek@att.net Mon Jul 23 08:51: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 4F2F821F85F0 for ; Mon, 23 Jul 2012 08:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, 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 pZsND1gDisnR for ; Mon, 23 Jul 2012 08:51:44 -0700 (PDT) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by ietfa.amsl.com (Postfix) with SMTP id 2691721F85D3 for ; Mon, 23 Jul 2012 08:51:44 -0700 (PDT) Received: from [98.139.52.197] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 23 Jul 2012 15:51:41 -0000 Received: from [68.142.200.225] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000 Received: from [66.94.237.101] by t6.bullet.mud.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 23 Jul 2012 15:51:40 -0000 X-Yahoo-Newman-Id: 630312.19430.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 5907 invoked from network); 23 Jul 2012 15:51:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1343058700; bh=ieYR6tIY8A2/t4iwnhhvECBeZT1P9cGQCAF+sIvHQxo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=J+Ne+WQSDgwx/nTFQsGdCmn6VhXQinbHGiaS/Pe8vHTCnrtS3ruJ6xggnl6Ofbh/IXd/P7cTBBxaYNCL0W9dPmS9KCV1xVYuXks73Zk2IgjAMpW3Au7G3Kwu4xrwaZxlDrwFn3PKLnFRfBVQQlhD+8lDoEQDhGvW332ov7KaEvg= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PAT9oJkVM1l3YnYkRKz4wZ4H1srU88JvuqncautSR0FEJAT n8Dl1.QZGWz0ns1VLdf9nH13R0mMFiflxqkbVZKNFZpB1SjV3Eh8YsvycJeu IMniWykpYzVGYNISOgIv2qjW1sLGPPISyyiGo4T3WYi_y0d5VaEACfSibH9B 7OnCFCLZl40B83tCZL0ryR7WH.M2Mt.KaI8ouQaap86xtN2utSP9_36o9L90 R.4LW064i.owC3axxhSyzbcbw6EHH2vylCs3qOv5sliQ8YpEEVOac8nGe_nX nIP6tr3ghkKcaQ7hcHQPsLxASbnEZI0DLWgdd5Hm1ofl2gqAiA1cw7AzCIia vaVzICSymD5NLe5ppQvucOT4LB8rWC9pJ2zjeH3t_SUol5e2nYK6WTuUJUkX .E5S7EbTwWPPzkVNi2P.vGUZRfA7yH_uh X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp111.sbc.mail.ne1.yahoo.com with SMTP; 23 Jul 2012 08:51:39 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 23 Jul 2012 08:51:34 -0700 From: Don Sturek To: "Stan Ratliff \(sratliff\)" , Abdussalam Baryun Message-ID: Thread-Topic: [manet] MANET Terminology Update In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: manet , Thomas Heide Clausen Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:51:46 -0000 +1 Agreed. I don't see any value in MANET to the proposed I-D. Don On 7/23/12 7:59 AM, "Stan Ratliff (sratliff)" wrote: >I'm going to "+1" one (and only one) sentence in this email thread: > >>=20 >> On 7/6/12, Thomas Heide Clausen wrote: >>> I do not see the need for this terminology document in MANET: >>=20 > >In my opinion as a working group participant, this is an unnecessary >distraction for the working group, and will not result in a meaningful >document. I will not support it. > >Regards, >Stan > > > > >On Jul 23, 2012, at 2:58 AM, Abdussalam Baryun wrote: > >> Hi >>=20 >> Comment inline below: >>=20 >> On 7/6/12, Thomas Heide Clausen wrote: >>> I do not see the need for this terminology document in MANET: >>>=20 >>> o The RFCs published by the WG all do a good job of defining their >>>proper >>> terminology and conventions in the sections, aptly named to this >>> effect -- and something which both the WG and the IESG has been very >>> vigilant in ensuring. >>=20 >> Agree >>=20 >>>=20 >>> o Extracting this terminology, to present without the context of the >>>RFC in >>>=20 >>> which they are introduced and used, is both futile and a source >>> of errors and confusion. >>=20 >> It is not extracting any thing it is locating information in easy >> location to be reached efficiently by researchers, or other WG >> participants. In another reason, for example the RFC5444 and RFC6130 >> is providing a MANET standard, while any RFC in this WG is specifying >> its own terminology and message format, but the reason was to bring >> RFCs to have similar formating functions. The terminology RFCs in many >> WGs does the same. RFC2501 is doing a good job to bring understanding >> of MANET which the terminology informational RFCs are doing in each >> concept/group-charter. >>=20 >>>=20 >>> o The domain evolves, new protocols appear and introduce new concepts, >>> terms. This is captured by carefully defining such in the RFC >>>specifying >>> that protocol. Any terminology document (aside from all its other >>>issues, >>> indicated in this list) would likely be obsolete and incomplete >>>before >>> the >>> ink with which it was written was dry. >>=20 >> So when new concepts appear any WG needs to prepare updates I-D to >> their information/standards/experiments so that knowledge is >> consistent and concepts are updated as will (including terminology >> document can be updated). Please note that our documents in MANET are >> a source of information to any participant in IETF, so we need to >> focus to not only produce new concepts/work but we see into >> update/obsolete previous work if possible/necessary. other wise why >> did the IETF make an option possibility to *update* and *obsolete* if >> they are not needed for WGs. >>=20 >>>=20 >>> o All RFCs in MANET uses no more than a small subset of the total >>>MANET >>> (and Internet) terminology. A collective terminology document would, >>> therefore, necessarily be adding entropy to any single RFC and to the >>> WG (and to implementers of the WG protocols). >>=20 >> Please note that the bigest reason of terminology is that when WG >> participants discuss things they don't misunderstand. Please note >> there are many times in MANET WG there are misunderstood in technical >> terms (I have references on the list to many incidence if you ask), so >> if experts have this problem we need to solve it by a RFC document, >> also we need to give the protocol user a sense of the general/specific >> terminology (as we have MANET general format, MANET general >> understanding, MANET general direction). >>=20 >>>=20 >>> o Certainly, a large number of terms in this document are entirely >>>out of >>> scope >>> (such as those pertaining to non-MANET developed concepts or >>>protocols, >>> e.g., those developed in other parts of the IETF), are useless for >>>the WG >>> (such as, but not exclusively, "communication channel" and >>>"communication >>>=20 >>> medium"), are by nature ambiguous (such as, but not exclusively, >>>"Upper >>> Layer" >>> and "Node"), carry a legacy that renders them difficult to use (such >>>as, >>> but >>> not exclusively, "Logical (virtual) Link", "Physical Link", and >>>"Link"). >>>=20 >>=20 >> I disagree that thoes terms are out of scope of the I-D of the MANETs >> context terminology, because those terms you mentioned were used in >> one/some MANET RFCs, so they need to be explained to bring all terms >> together to make overall knowledge to internet community. Your >> argument is right only if we are not specifying network-protocols, so >> because we are doing a type of network, then our documents for it >> SHOULD be *connected* by some combined meaning/knowledge *words*, so >> other (i.e. all internet community) can understand, without any >> possibility of misunderstanding (there are many examples I can give if >> you want). >>=20 >> I thank you for your comments, and I will prepare a new version for the >>I-D, >>=20 >> Best Regards >>=20 >> Abdussalam Baryun >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> On Jul 3, 2012, at 1:24 PM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Dear All >>>>>>=20 >>>>>> I completed the first version of draft on terminology and submited >>>>>>the >>>>>> draft yesterday (with getting some techniq problem), but needed to >>>>>> post to know the community feedback and advise. There are other >>>>>>terms >>>>>> that was not yet included which will need some advise from you. >>>>>> Thanking you, >>>>>>=20 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> Abbreviations Used in The submitted Document >>>>>>=20 >>>>>> AH Authentication Header >>>>>> DAD Duplicate Address Detection >>>>>> DPD Duplicate Packet Detection >>>>>> DoS Denial of Service >>>>>> ESP Encapsulating Security Payload >>>>>> IP IPv4 or IPv6 >>>>>> ICMP Internet Control Message Protocol >>>>>> IIB Interface Information Base >>>>>> ETX Estimated Expected number of Transmission >>>>>> FIB Forwarding Information Base >>>>>> LQI Link Quality Indicator >>>>>> L2 Data Link Layer (i.e. 2nd layer in ISO model) >>>>>> L3 Internet Layer (i.e. 3rd layer in ISO model) >>>>>> LLN Low power and Lossy Network >>>>>> MAC Mediam Access Control >>>>>> MIB Management Information Base >>>>>> MTU Maximum Transmission Unit >>>>>> NBMA Non-Broadcast Multi-Access link >>>>>> NHDP Neighborhood Discovery Protocol >>>>>> ND IP Neighbor Discovery >>>>>> OSPF Open Shortest Path First >>>>>> RIB Routing Information Base >>>>>> SMF Simplified Multicast Forwarding >>>>>> TCP Transmission Control Protocol >>>>>> UDP User Datagram Protocol >>>>>>=20 >>>>>> 2.3 Definitions for MANET Terms >>>>>>=20 >>>>>> 2.3.1 Terms Definition of MANET Communication: >>>>>>=20 >>>>>> Communications=B9 Technology or Facility: >>>>>> The means employed by two or more devices/subsystems to transfer >>>>>> and/or receive information between them in one way or two way >>>>>> communication. MANET communications often uses the wireless >>>>>> transmission medium(s) and MAY use some wired mediums (e.g. free >>>>>> space, air, water, antenna, coaxial cables, etc.) >>>>>>=20 >>>>>> Communication Medium: >>>>>> The transceiver system (e.g. such as L2 systems, IEEE802.11 systems, >>>>>> satellite system, etc.) that the routing device uses to communicates >>>>>> through the transmission medium(s), by providing connectionless >>>>>>and/or >>>>>> connection services that MAY be established. The system medium >>>>>> includes MAC layer and MAY include the physical Layer. >>>>>>=20 >>>>>> Communication Channel: >>>>>> A subdivision of the physical communication medium (i.e. radio >>>>>>carrier >>>>>> signal bandwidth, or the system bandwidth) allowing possibly shared >>>>>> independent uses of the medium. Channels may be made available by >>>>>> subdividing the medium into; distinct time slots, distinct spectral >>>>>> bands, or coding sequence, etc. >>>>>>=20 >>>>>> MANET Protocol: >>>>>> The communication system/subsystem that operates and maintains the >>>>>> ad hoc communication technology or facility within MANET. MANET >>>>>>routing >>>>>> Protocols often apply distributed algorithms/techniques to >>>>>>disseminate >>>>>> or forward routing messages within a MANET routing domain. >>>>>>=20 >>>>>> Topology: >>>>>> An abstract representation of a network (physical or logical), as a >>>>>> graph (G) whose topology is defined by a set of routers/bridges (V) >>>>>> that >>>>>> communicate through set of links (E), where the G =3D (V, E). >>>>>>=20 >>>>>> Physical-level Topology: >>>>>> A topology of the communication medium networks consists of routing >>>>>> devices and physical links. This topology information is updated by >>>>>> devices=B9 technology in the L2 information Base. >>>>>>=20 >>>>>> Network-level Topology: >>>>>> A topology of the communication system networks consists of routers >>>>>>and >>>>>> links. This topology information is updated by routers in its RIB. >>>>>>=20 >>>>>> Multihop MANET: >>>>>> A MANET that its node(s) MAY need(s) more than one IP hop to reach >>>>>>the >>>>>> destination. >>>>>>=20 >>>>>> Reactive Routing: >>>>>> An on-demand based routing protocol that operates route discover and >>>>>> maintainance the route(s), to reach the demanded destination(s). >>>>>>=20 >>>>>> Proactive Routing: >>>>>> A topology RIB based routing protocol that operates routes and >>>>>> maintains >>>>>> the network topology, to reach its known destination(s). Each router >>>>>> maintains routes to all reachable destinations at all times, >>>>>>whether or >>>>>> not there is currently any demand to deliver packets to those >>>>>> destinations. >>>>>>=20 >>>>>> Upper Layer: >>>>>> a protocol layer above IP layer (e.g. as TCP, UDP, OSPF). >>>>>>=20 >>>>>> MANET Domain: TBD >>>>>>=20 >>>>>> MANET Signaling: >>>>>> Sending and exchanging some MANET messages/information. >>>>>>=20 >>>>>> 2.3.2 Terms Definition of MANET Elements >>>>>>=20 >>>>>> Node: >>>>>> A device/subsystem that MUST implement IP and SHOULD participate in >>>>>> MANET signaling. It either runs a MANET routing protocol or >>>>>>participate >>>>>> in MANET signaling. >>>>>>=20 >>>>>> Router: >>>>>> A MANET node that MUST implement a MANET routing protocol and >>>>>>forwards >>>>>> IP packets not explicitly addressed to itself. >>>>>>=20 >>>>>> Host: >>>>>> A node that is not a router. All destinations in MANET that receive >>>>>> delivered data are hosts. >>>>>>=20 >>>>>> Link: >>>>>> A link between two node interfaces. This link may be Logical >>>>>> (i.e. virtual) link or physical link. Logical links are between two >>>>>> logical interfaces and physical links are between two physical >>>>>> interfaces. Links are either unidirectional or bidirectional >>>>>> (links may be on-link and off-link: see RFC4861). >>>>>>=20 >>>>>>=20 >>>>>> Physical Link: >>>>>> a communication facility or medium over which the nodes can >>>>>> communicate at the link layer, i.e., the layer immediately below >>>>>> IP. Physical interfaces are the nodes=B9 attachment to physical links. >>>>>> Physical Link types are point-to-point, NBMA, multicast capable, >>>>>> and shared-media, etc (see link types in ND [RFC4861]). >>>>>>=20 >>>>>> Logical (virtual) Link: >>>>>> a communication facility (at L3, or upper-layer) over which nodes >>>>>>can >>>>>> communicate. This logical link is between two MANET interfaces >>>>>>exists >>>>>> if either can be heard by the other. >>>>>>=20 >>>>>> Link MTU: >>>>>> the maximum transmission unit (i.e. maximum unit size in octets), >>>>>>that >>>>>> can be conveyed in one transmission unit over the link. >>>>>>=20 >>>>>>=20 >>>>>> Node Interface: >>>>>> A node's point of attachment to a link. Each node MUST have at least >>>>>> one >>>>>> interface that SHOULD be assigned an IP address. If there is/are >>>>>>more >>>>>> than one interface(s) per node then the additional interface(s) MAY >>>>>>be >>>>>> assigned an IP address. If an interface is not assigned to an IP >>>>>> address >>>>>> it MUST be identified by the MANET routing protocol. An interface >>>>>>MAY >>>>>> be >>>>>> assigned one or more addresses. >>>>>>=20 >>>>>> MANET Interface: >>>>>> A node interface that participate in; exchange MANET information >>>>>>used >>>>>> in >>>>>> MANET routing or exchange information in MANET neighbor node >>>>>>discovery >>>>>> (e.g as the term used in RFC6130). A MANET interface MUST be >>>>>>assigned >>>>>> to >>>>>> least one address to communicate. A router interface MUST be >>>>>> assigned a routable address which is the main address for the >>>>>> interface. >>>>>>=20 >>>>>>=20 >>>>>> 2.3.3 Terms Definition of MANET Identifications: >>>>>>=20 >>>>>> An interface MAY be assigned one or more addresses. If the >>>>>>interface is >>>>>> a logical interface it MAY be assigned to only logical addresses, >>>>>>but >>>>>> if >>>>>> it is a physical interface MAY be assigned with physical address >>>>>> (e.g. MAC address) and/or logical address(es) (e.g. IP addresses, >>>>>> MANET addresses). >>>>>>=20 >>>>>>=20 >>>>>> MANET Address >>>>>> A MANET-subnet, node, or interface address. Node and interface >>>>>> addresses >>>>>> are either IP addresses or RFC5444 addresses. All subnet addresses >>>>>>are >>>>>> unicast IP addresses. >>>>>>=20 >>>>>> Address Block and TLV: as specified in RFC5444 >>>>>>=20 >>>>>> Routable address: >>>>>> A subnet address which can be a destination address. A router MUST >>>>>>be >>>>>> able to distinguish a routable address from a non-routable address. >>>>>> Broadcast, and multicast addresses, limited in scope to less than >>>>>>the >>>>>> entire MANET, MUST NOT be considered as routable addresses. Anycast >>>>>> addresses MAY be considered as routable addresses. >>>>>>=20 >>>>>> Main address >>>>>> A routable address (MANET address) that is assigned to one router's >>>>>> MANET interface. >>>>>>=20 >>>>>> Originator address: >>>>>> A node address of the node that originated a MANET message (this >>>>>> message >>>>>> MUST include the originator address). It MAY be a routable or an >>>>>> unroutable address. >>>>>>=20 >>>>>> subnet prefix >>>>>> A bit string that consists of some number of initial bits of an IP >>>>>> address. >>>>>>=20 >>>>>> Interface identifier >>>>>> the remaining low-order bits in the node's IP address after the >>>>>>subnet >>>>>> prefix. A number used to identify a node's interface on a link. >>>>>>=20 >>>>>> 2.3.4 Terms Definition of MANET exchange information formats: >>>>>>=20 >>>>>> Packet: >>>>>> A MANET packet of a header plus payload. These packets are either >>>>>> IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated >>>>>> in IP packet. Packets are generated by nodes to be sent to >>>>>> destination(s) through MANET or through the Internet. RFC5444 >>>>>>packets >>>>>> information MAY not be used only by MANET routers. >>>>>>=20 >>>>>> Message: >>>>>> A MANET data message or routing control message. Routing control >>>>>> messages are either MANET routing protocol messages or/and RFC5444 >>>>>> messages. >>>>>>=20 >>>>>> Type Length Value coding (TLV): >>>>>> A generic way to represent MANET information (as in [RFC5444] and >>>>>> [RFC5497]). >>>>>>=20 >>>>>> Frame: >>>>>> A L2 protocol TLV with a header and payload. In some technologies >>>>>>the >>>>>> L2 >>>>>> operates a MANET routing protocol as a local area networking system. >>>>>> Frames MAY encapsulate MANET packets to be tunneled through a >>>>>> telecommunication network. >>>>>>=20 >>>>>> Route Request Message (RREQ) >>>>>> A message is used to discover a valid route to a particular >>>>>> destination address, called the RREQ Target Node. When a router >>>>>> processes a RREQ it learns routing information on how to Originator >>>>>> Node. >>>>>>=20 >>>>>> Route Reply Message (RREP) >>>>>> A message is used to disseminate routing information about >>>>>> the RREP Target Node to the RREQ Originator Node and the >>>>>>intermediate >>>>>> routers. >>>>>>=20 >>>>>> Route Error Message (RERR) >>>>>> A message is used to disseminate the information that a route is >>>>>> not available for one or more particular addresses. A RERR message >>>>>>is >>>>>> used to indicate that a router does not have a forwarding route >>>>>> to one or more particular addresses. >>>>>>=20 >>>>>> 2.3.5 Terms Definition Related to MANET Protocol Operation: >>>>>>=20 >>>>>> Hop-by-hop Routing: (TBD) >>>>>> A dynamic routing that routes to destination by routing table. >>>>>>=20 >>>>>> Source Routing: (TBD) >>>>>> A dynamic routing that its route path is provided in the IP packet. >>>>>>=20 >>>>>> Route Discovery: TBD >>>>>>=20 >>>>>> Route Maintenance: TBD >>>>>>=20 >>>>>> Neighbor discovery: (TBD) >>>>>> A node discovers neighbors only if the node receives from it's >>>>>> neighbors. >>>>>>=20 >>>>>>=20 >>>>>> Multipoint relay (MPR): (TBD) >>>>>> A router X1 is an MPR for a router Y1, if router Y1 has indicated >>>>>> its selection of router X1 as an MPR in a recent HELLO message. >>>>>> Router X1 may be a flooding MPR for Y1 if it is indicated to >>>>>> participate in the flooding process of messages received from >>>>>> router Y1, or it may be a routing MPR for Y1, if it is indicated to >>>>>> declare link-state information for the link from X1 to Y1. It may >>>>>> also be both at the same time. >>>>>>=20 >>>>>> MPR selector: >>>>>> A router, Y, is a flooding/routing MPR selector of router X if >>>>>> router Y has selected router X as a flooding/routing MPR. >>>>>>=20 >>>>>> Router Parameters: >>>>>> boolean or numerical values, specified for each router, and not >>>>>> specific to an interface. A router MAY change router parameter >>>>>> values at any time, subject to some MANET constraints. >>>>>>=20 >>>>>> MANET Routing Metric: >>>>>> A MANET routing cost that is governed by specific rules and >>>>>>properties >>>>>> defined by the MANET routing protocol which captures specific link >>>>>>or >>>>>> node characteristics. Examples of basic metrics are hop-count, ETX, >>>>>> LQI, >>>>>> etc. >>>>>>=20 >>>>>> Distance Vector Metric >>>>>> A metric class related to rules of the MANET interface and MANET >>>>>>path >>>>>> distance. The metric can be calculated by the distance vector >>>>>>routing >>>>>> algorithm class used by the MANET routing protocol. A metric of the >>>>>> distance a message or piece of information has traversed. The >>>>>>minimum >>>>>> value of distance is the number of IP hops traversed. >>>>>>=20 >>>>>> Link State Metric >>>>>> A metric type related to the MANET network-topology status and >>>>>>logical >>>>>> links' states. This metric is calculated by the link state routing >>>>>> algorithm class used by the MANET routing protocol. A metric type >>>>>>maybe >>>>>> EXT, LQL, etc. >>>>>>=20 >>>>>> Link Metric: TBD >>>>>>=20 >>>>>> Neighbor Metric: TBD >>>>>>=20 >>>>>> Path accumulated: >>>>>> The RREQ message accumulates intermediate routers that are in path >>>>>>to >>>>>> destination(s). >>>>>>=20 >>>>>> Protocol Sequence Number: >>>>>> A Sequence Number related to a MANET protocol that maintained by >>>>>>each >>>>>> protocol subsystem process. This sequence number is used by other >>>>>> subsystems to identify the temporal order of protocol information >>>>>> generated. >>>>>>=20 >>>>>> Router Sequence Number: >>>>>> A router sequence number is maintained by each router process. The >>>>>> sequence number is used by other routers to identify the temporal >>>>>> order of routing information generated and ensure loop-free routes. >>>>>>=20 >>>>>> MANET Information Base: >>>>>> A collection of information (in Table or Cache structure) maintained >>>>>> by MANET protocols and which is to be made available to MANET >>>>>>routing >>>>>> protocols. An Information Base may be associated with a MANET router >>>>>> or with MANET interface (e.g. route request table, IIB, RIB, FIB, >>>>>>MIB). >>>>>>=20 >>>>>> RIB Entry: >>>>>> The RIB entry is a conceptual data structure. Implementations may >>>>>>use >>>>>> any internal representation that conforms to the semantics of a >>>>>>route >>>>>> as specified in the router specification. >>>>>>=20 >>>>>> 3. IP Considerations and Terminology >>>>>>=20 >>>>>> All MANET nodes MUST implement IP and all MANET routers MUST >>>>>> run/implement at least one MANET routing protocol. The >>>>>> terminologies described in this document can be used for >>>>>> IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6 >>>>>> packets but IPv6 addresses MUST not be in IPv4 packets. >>>>>>=20 >>>>>> IP address: >>>>>> IPv4 addresses or IPv6 addresses. >>>>>>=20 >>>>>> IP Packet: >>>>>> The packet header plus payload as specified in [RFC791] and >>>>>>[RFC2460] >>>>>> for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets >>>>>>as >>>>>> specified by RFC5498. >>>>>>=20 >>>>>> Mobile IP considerations: >>>>>> Mobile IP terms are provided in [RFC6275], and this technology >>>>>> assists nodes while connected through the Internet domain(s). MANET >>>>>> is an infrastructure-less network that is able to communicate with >>>>>> the Internet (i.e. an IP infrastructure network). >>>>>>=20 >>>>>> 4. Security Consideration and Terminology >>>>>>=20 >>>>>> It is RECOMMENDED that MANET routing protocols consider security >>>>>> issues because the MANET's transmission medium is wireless which >>>>>>make >>>>>> it vulnerable to attacks [ANJUM][RFC4593]. In some situations the >>>>>> routing information while traversing the MANET MAY be used by an >>>>>> intruder node, to obtain MANET data traffic or/and attack the MANET >>>>>> [HERBERG]. Forwarding protocols that use DPD techniques MAY be >>>>>> vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured >>>>>> by using IPsec, AH, DAD, and ESP techniques, and other. However, >>>>>> it is RECOMMENDED that MANET detects attackers and possible threats. >>>>>>=20 >>>>>> The following are some terminology related to MANET threats and >>>>>> security. >>>>>>=20 >>>>>> Attacker: A node, present in the network and which intentionally >>>>>>seeks >>>>>> to compromise information based in MANET router(s). The Attacker >>>>>>MAY be >>>>>> a compromised MANET router if obtained MANET identity or routing >>>>>> information. >>>>>>=20 >>>>>> Compromised MANET Router: An attacker router, present in MANET and >>>>>> which generates syntactically correct routing control messages. >>>>>>Control >>>>>> messages emitted by compromised router(s) may contain additional >>>>>> information, or omit information, as compared to a control message >>>>>> generated by a non-compromised router located in the same MANET >>>>>> topological position. >>>>>>=20 >>>>>> Legitimate MANET Router: A MANET router, which is not a Compromised >>>>>> MANET Router. >>>>>>=20 >>>>>> Jamming Attack: >>>>>> The attacker transmits massive amounts of interfering radio traffic, >>>>>> which will prevent legitimate traffic (e.g., routing and data >>>>>>traffic) >>>>>> on all or part of the MANET. Indirect jamming attacks MAY occur by >>>>>> influencing Legitimate MANET Router to transmit unnecessary >>>>>> information. >>>>>>=20 >>>>>> Eavesdropping: >>>>>> Obtaining a copy by the attacker of the transmitted MANET routing >>>>>> information or the transmitted data information from its neighbor's >>>>>> transmitted radio packet. Attacker=B9s processes MANY be used by >>>>>>attacker >>>>>> to mislead routing. Eavesdropping does not pose a direct threat to >>>>>>the >>>>>> MANET or to its routing. >>>>>>=20 >>>>>> Identity Spoofing: >>>>>> Attacker sends routing messages, pretending to have the MANET >>>>>>identity >>>>>> of another node. >>>>>>=20 >>>>>> Link Spoofing: >>>>>> Compromised MANET router sends routing messages to neighbor node(s) >>>>>> providing incorrect set of link information. >>>>>>=20 >>>>>> Replay Attack: >>>>>> A Compromised router in one MANET region records control traffic >>>>>> information and replays the recorded information in a different >>>>>>MANET >>>>>> region (this type of attack is also called the Wormhole attack). >>>>>>=20 >>>>>> Broadcast Storm: >>>>>> Compromised MANET router may attack the MANET by attempting to >>>>>>change >>>>>> the MANET flooding algorithm(s) to increase routing overheads >>>>>>or/and to >>>>>> increase the route discovery delay. Broadcast storm degrades the >>>>>>data >>>>>> traffic delivery and MANET performance. >>>>>>=20 >>>>>> Falsification in MANET: >>>>>> The compromised MANET router sends false routing information into >>>>>> MANET. >>>>>> False routing information received in MANET, MAY create unrealistic >>>>>> information bases. >>>>>>=20 >>>>>> ICMP Attacks: >>>>>> The generation of ICMPv6 error messages may be used by compromised >>>>>> MANET >>>>>> router to attempt DoS attacks by sending an error-causing source >>>>>> routing >>>>>> header in back-to-back datagrams. As the ICMP messages are passed to >>>>>> the >>>>>> upper-layer processes, it is possible to perform attacks on the >>>>>>upper >>>>>> layer protocols (e.g., UDP, TCP). Protocols at the upper layers are >>>>>> RECOMMENDED to perform some form of validation to ICMP messages >>>>>>(using >>>>>> the information contained in the payload of the ICMP message) before >>>>>> acting upon them. >>>>>>=20 >>>>>> Source Routing Attacks: TBD >>>>>>=20 >>>>>> Acknowledgments: >>>>>>=20 >>>>>> This work has used/modified terms of the following documents: >>>>>>RFC2462, >>>>>> RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444, >>>>>> RFC6130, RFC6621, [AODVv2], [OLSRv2], and [HERBERG], >>>>>> Gratefully acknowledge to the IETF community and all contributions. >>>>>>=20 >>>>>> Reference: >>>>>> [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for >>>>>> NHDP", Work in progress, March, 2012. >>>>>> [ANJUM] Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc >>>>>> Networks", John Wiley & Sons, March 2007. >>>>>> ISBN: 978-0-471-75688-0. >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>=20 >>>>>> I hope to get some advise from the Internet community to make the >>>>>> definitions more suitable/accurate, because I MAY misunderstood. >>>>>> Thanking you, >>>>>>=20 >>>>>> Best Regards >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>> University of Glamorgan, UK >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> _______________________________________________ >> 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 ulrich@herberg.name Mon Jul 23 09:21: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 71F9A11E809B for ; Mon, 23 Jul 2012 09:21:13 -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.432, 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 ziojopEZ0aZv for ; Mon, 23 Jul 2012 09:21:12 -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 0FF5C11E8093 for ; Mon, 23 Jul 2012 09:21:11 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11462030pbc.31 for ; Mon, 23 Jul 2012 09:21: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=jjNt8odcHLCwsgqHtkRFjBWoqatOWxwBOg2lwDFtjw8=; b=2l7aTL3qOEBZde6r8c/kkKiwyc5ROU9r7Eo5VFe+BbYQh7HTafBAr45bGrqUPW5GkG 2/HsHbHuH72CJI8CuTzGQTJgJomDyif0/vGCnp+1qKq53KQq1DQ4yVP8HgGN8dJaYIID xczqnEM2k9LNtIA61wqX4j7Cc6RpQq+18pt2A= 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=jjNt8odcHLCwsgqHtkRFjBWoqatOWxwBOg2lwDFtjw8=; b=IPktXayV6xL8TVxC/qbSslDOfbtW45q5xa8baIPuwjYH9qd7D982RUTXBipWenXf/a /tNgz+3Ds0vN5cZFo4hepJ2/AGai6YGh64kZHMKE+e/IhusAbXiMjxT6Wd0PopgCeikS wZ3HXQAenrXQTWwH1xbVoQN6vI3Obw86qFi9UpM8Y03QvtG2AbrB2T0QHKY5kTYVHvvL PU0TFhMFr71eQYC9klrB7ZSigmJ1qR7+T6KGbCiy5BlrDjAxP6X39/RgZmBb5JBa+1qm B0oamwIsFhp4nAd7hYPvlNBf7jyAb7wNJeQj2PJY47DqCnskZ38t23vpGd5QXlzTCrOr MjRA== MIME-Version: 1.0 Received: by 10.68.217.100 with SMTP id ox4mr36301594pbc.87.1343060471584; Mon, 23 Jul 2012 09:21:11 -0700 (PDT) Received: by 10.66.26.207 with HTTP; Mon, 23 Jul 2012 09:21:11 -0700 (PDT) In-Reply-To: <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> Date: Mon, 23 Jul 2012 09:21:11 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=e89a8ff245df52196704c581a224 X-Gm-Message-State: ALoCoQkd0VTjna7rlUsrTBRfEtxqNtfhlmJimsL4OnGamzWuqaW3yypQTtOLWHXNDJ/GZYWoSbmk Cc: manet , Thomas Heide Clausen , Abdussalam Baryun Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:21:13 -0000 --e89a8ff245df52196704c581a224 Content-Type: text/plain; charset=ISO-8859-1 +1 On Mon, Jul 23, 2012 at 7:59 AM, Stan Ratliff (sratliff) wrote: > I'm going to "+1" one (and only one) sentence in this email thread: > > > > > On 7/6/12, Thomas Heide Clausen wrote: > >> I do not see the need for this terminology document in MANET: > > > > In my opinion as a working group participant, this is an unnecessary > distraction for the working group, and will not result in a meaningful > document. I will not support it. > > Regards, > Stan > > > --e89a8ff245df52196704c581a224 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Mon, Jul 23, 2012 at 7:59 AM, Stan = Ratliff (sratliff) <sratliff@cisco.com> wrote:
I'm going to "+1" one (and only one) sentence in this email t= hread:

>
> On 7/6/12, Thomas Heide Clausen <thomas@thomasclausen.org> wrote:
>> I do not see the need for this terminology document in MANET:
>

In my opinion as a working group participant, this is an unnecessary = distraction for the working group, and will not result in a meaningful docu= ment. I will not support it.

Regards,
Stan


--e89a8ff245df52196704c581a224-- From boberry@cisco.com Mon Jul 23 10:08: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 110EA11E80E6 for ; Mon, 23 Jul 2012 10:08:01 -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 Oc4IU82Q2UgJ for ; Mon, 23 Jul 2012 10:08:00 -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 4B2FA11E80E7 for ; Mon, 23 Jul 2012 10:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=1219; q=dns/txt; s=iport; t=1343063280; x=1344272880; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=33Rc3jiMNIZcZJBWX6CmcKeIa1IKjyNCHEZhJkcsTsc=; b=FM+ItighD2ybx+Okg511pk7YKbBrSBVHYRnNoA5ZYW/3Rr+icYa+4UPX LKryyPN9Jvp1xD74KKW1PlVr0YZXS/CSQb6UPWni1R6up45aY5EbKwHi+ 1NS4eaI7p3WXS85M58EJewbZejA0pG7duoniPV9eSGN1qmo6Nr97gDWb3 Q=; X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104492825" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2012 17:08:00 +0000 Received: from dhcp-64-102-54-137.cisco.com (dhcp-64-102-54-137.cisco.com [64.102.54.137]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6NH7xx0016940; Mon, 23 Jul 2012 17:07:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 23 Jul 2012 13:08:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C1F8976-FE53-4C49-9BA3-930BFB63A8F5@thomasclausen.org> <8A25B620-D502-4C37-B292-B185331B1669@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: manet , Abdussalam Baryun , Thomas Heide Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:08:01 -0000 +1 On Jul 23, 2012, at 12:21 PM, Ulrich Herberg wrote: > +1 >=20 > On Mon, Jul 23, 2012 at 7:59 AM, Stan Ratliff (sratliff) = wrote: > I'm going to "+1" one (and only one) sentence in this email thread: >=20 > > > > On 7/6/12, Thomas Heide Clausen wrote: > >> I do not see the need for this terminology document in MANET: > > >=20 > In my opinion as a working group participant, this is an unnecessary = distraction for the working group, and will not result in a meaningful = document. I will not support it. >=20 > Regards, > Stan >=20 >=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 ulrich@herberg.name Mon Jul 23 10:10: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 2A95E21F858F for ; Mon, 23 Jul 2012 10:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 vjVgwr63ijnw for ; Mon, 23 Jul 2012 10:10:21 -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 A639921F858E for ; Mon, 23 Jul 2012 10:10:21 -0700 (PDT) Received: by yenq13 with SMTP id q13so6246131yen.31 for ; Mon, 23 Jul 2012 10:10:21 -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=pOBIocFxNSTe6ip5si1CuuWBFiH8ZtsJcXWfL4O+opw=; b=oJxLW1Ig8M5N2XdH9xmGFABQjfniAY6DQC7wl9PrE264umSCtPT7DodGCTaf6qgxHX uDN9lJkCwbf5b9lunog/mZfXoS6X9go/L7AcWvhmtvzn1+lchRZ+UoMdvq7O0Xe9yEuo ih3VkJSw/h/lrErNfhF2jQZ928hhgC4qD2voU= 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=pOBIocFxNSTe6ip5si1CuuWBFiH8ZtsJcXWfL4O+opw=; b=HqlG9UJG7Lsk3EEXtJaE0TV9TzpNj4/GaXUE1msY3fec6rzRmP65KTDngSZ3gaedcB Dei+WM4EfbBcLbXNIdze0yJ4wEhwJtCRXnR5Fr85BpfMnHMrjHJ7FjxDKhLGnoXyOc9e hppqp3WSwEUULIFTqlMPbAhbDFxR+5R13l0n3Y9/v2JB+2KPhzvaTN0AMEQFKrnlS2+g XHJfcwCBL0R2CQ4nfYSvrJP8fJbNgbTy8+Yhnacg+UjUCUmdO4e/RqxZwIeD+xcfSKUG l1x9ubVl6Hbk8tyLV2wUEKXnC9qtYIACCZPYVzjhrfLi1nACK1TmrTNnxX+B+Gcb9ew2 Dldg== MIME-Version: 1.0 Received: by 10.60.171.5 with SMTP id aq5mr13583462oec.34.1343063421060; Mon, 23 Jul 2012 10:10:21 -0700 (PDT) Received: by 10.76.90.101 with HTTP; Mon, 23 Jul 2012 10:10:20 -0700 (PDT) In-Reply-To: <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> Date: Mon, 23 Jul 2012 10:10:20 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=bcaec5523dcc1f853c04c58252f8 X-Gm-Message-State: ALoCoQmPbX+7g8PI9BZwLvfdEWRNtmjJuVFNfvl06afAy7wCTT6/IusjZMGoeFVU9OwURU5CBOwl Cc: manet , Abdussalam Baryun , "Bo Berry \(boberry\)" , Thomas Clausen Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:10:23 -0000 --bcaec5523dcc1f853c04c58252f8 Content-Type: text/plain; charset=ISO-8859-1 I don't see the need for updating RFC5444 at the moment. Best Ulrich On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) wrote: > +1 > > Regards, > Stan > > On Jul 23, 2012, at 7:27 AM, Bo Berry wrote: > > > As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) are > > working on DLEP revisions. > > > > -Bo > > > > > > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: > > > >> I agree with Rick, and want to add a few things ... > >> > >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > >> > >>> Hi Abdussalam, > >>> > >>> I would recommend that you be very careful about attempting to > >>> adapt/extend RFC5444, particularly with respect to DLEP, because it is > >>> still open to debate whether any future DLEP draft will use RFC5444 for > >>> its packet format, and I believe the authors are leaning away from it. > >> > >> Yes - plus, it is also not established yet that RFC5444 isn't > appropriate for carrying DLEP signals (should the authors/WG go that way). > >> > >>> Also, there has been a lot of comment on this mailing list about not > >>> updating RFC5444 yet as there appears little consensus about the actual > >>> failings of the format w.r.t applicable protocols, i.e. all the > >>> 'complaints' about the format appear to be short-comings in the > >>> consuming protocols, not the packetBB format itself. > >> > >> +1 > >> > >>> Can you perhaps outline what you see as the failings of RFC5444 here > >>> before you produce a lengthy document, in order to gather some quick > >>> peer-review comments, as many on this list struggle to find time to > >>> digest long formal drafts, and I wouldn't want you to suffer from TL;DR > >>> ('too-long; didn't-read'). > >> > >> Even before that, it would be helpful to see a real routing protocol > (which DLEP is not), with a real usecase & industry behind it (so, not just > a thought experiment), with requirements pushed from real deployments (so, > outside of a lab), which is within the [manet] scope - and for which its > signals cannot properly be expressed in RFC5444. > >> > >> Best, > >> > >> Thomas > >> > >> > >>> Rick Taylor > >>> Cassidian Systems > >>> > >>>> -----Original Message----- > >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf > >>> Of > >>>> Abdussalam Baryun > >>>> Sent: 21 July 2012 14:33 > >>>> To: manet > >>>> Subject: [manet] Start work: update draft for RFC5444-Packets > >>>> > >>>> Hi > >>>> > >>>> I started working on a new draft to make some updates to the RFC5444, > >>>> so manet-packets can be more used by AODVv2, DLEP, and other possible > >>>> protocols. > >>>> > >>>> I will consider your input below of the discussions regarding > >>>> 5444-packets, also in the past there was a request that there is a > >>>> need for how to use 5444, so this draft may include as well, > >>>> > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html > >>>> > >>>> If you have any comment or advise to this started work please reply, > >>>> > >>>> AB > >>>> _______________________________________________ > >>>> 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 > > > > ---- > > 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 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec5523dcc1f853c04c58252f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't see the need for updating RFC5444 at the moment.

BestUlrich

On Mon, Jul 23, 2012 at 8:00 AM, = Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
+1

Regards,
Stan

On Jul 23, 2012, at 7:27 AM, Bo Berry wrote:

> As a co-author of DLEP, I agree w/ Rick&Thomas. =A0We (DLEP author= s) are
> working on DLEP revisions.
>
> -Bo
>
>
> On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote:
>
>> I agree with Rick, and want to add a few things ...
>>
>> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote:
>>
>>> Hi Abdussalam,
>>>
>>> I would recommend that you be very careful about attempting to=
>>> adapt/extend RFC5444, particularly with respect to DLEP, becau= se it is
>>> still open to debate whether any future DLEP draft will use RF= C5444 for
>>> its packet format, and I believe the authors are leaning away = from it.
>>
>> Yes - plus, it is also not established yet that RFC5444 isn't = appropriate for carrying DLEP signals (should the authors/WG go that way).<= br> >>
>>> Also, there has been a lot of comment on this mailing list abo= ut not
>>> updating RFC5444 yet as there appears little consensus about t= he actual
>>> failings of the format w.r.t applicable protocols, i.e. all th= e
>>> 'complaints' about the format appear to be short-comin= gs in the
>>> consuming protocols, not the packetBB format itself.
>>
>> +1
>>
>>> Can you perhaps outline what you see as the failings of RFC544= 4 here
>>> before you produce a lengthy document, in order to gather some= quick
>>> peer-review comments, as many on this list struggle to find ti= me to
>>> digest long formal drafts, and I wouldn't want you to suff= er from TL;DR
>>> ('too-long; didn't-read').
>>
>> Even before that, it would be helpful to see a real routing protoc= ol (which DLEP is not), with a real usecase & industry behind it (so, n= ot just a thought experiment), with requirements pushed from real deploymen= ts (so, outside of a lab), which =A0is within the [manet] scope - and for w= hich its signals cannot properly be expressed in RFC5444.
>>
>> Best,
>>
>> Thomas
>>
>>
>>> Rick Taylor
>>> Cassidian Systems
>>>
>>>> -----Original Message-----
>>>> From: manet-boun= ces@ietf.org [mailto:manet-bo= unces@ietf.org] On Behalf
>>> Of
>>>> Abdussalam Baryun
>>>> Sent: 21 July 2012 14:33
>>>> To: manet
>>>> Subject: [manet] Start work: update draft for RFC5444-Pack= ets
>>>>
>>>> Hi
>>>>
>>>> I started working on a new draft to make some updates to t= he RFC5444,
>>>> so manet-packets can be more used by AODVv2, DLEP, and oth= er possible
>>>> protocols.
>>>>
>>>> I will consider your input below of =A0the discussions reg= arding
>>>> 5444-packets, also in the past there was a request that th= ere is a
>>>> need for how to use 5444, so this draft may include as wel= l,
>>>>
>>>> http://www.ietf.org/mail-archive/web/m= anet/current/msg13212.html
>>>> http://www.ietf.org/mail-archive/web/m= anet/current/msg13105.html
>>>> http://www.ietf.org/mail-archive/web/m= anet/current/msg12430.html
>>>>
>>>> If you have any comment or advise to this started work ple= ase reply,
>>>>
>>>> AB
>>>> _______________________________________________
>>>> 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
>
> ----
> boberry@cisco.com
> This email may contain confidential and privileged material for the so= le use of the intended recipient. This email may contain information that i= s protected by NDA. Any unauthorized review, use, distribution or disclosur= e by others is strictly prohibited. If you are not the intended recipient (= or authorized to receive for the recipient), please contact the sender by r= eply email and delete all copies of this message.
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

--bcaec5523dcc1f853c04c58252f8-- From boberry@cisco.com Mon Jul 23 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 919F921F85A8 for ; Mon, 23 Jul 2012 10:16:42 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 HmnLUtSLRe32 for ; Mon, 23 Jul 2012 10:16:40 -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 4F20C21F8518 for ; Mon, 23 Jul 2012 10:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=5137; q=dns/txt; s=iport; t=1343063799; x=1344273399; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=c3VsmljO7huSrI9a/ohg2iYTqPCwL3qiFolWV5MjzqE=; b=EJ+1L8VAJZw4nPQksFXFde4JdjztrHc4Ll4dBZWM4CMp05zq6LlBv50e aRURja6E2MUMv8nKbf8fmMItt0XI4DEYRUmU7aOfRigUFfYXiWMIX6L5H /vknM8kLSQacHoVd88JLGp8SJw6WH9RqiXNs3WSrj7D9y0sL0xoRXxfWR g=; X-IronPort-AV: E=Sophos;i="4.77,639,1336348800"; d="scan'208";a="104447293" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2012 17:16:39 +0000 Received: from dhcp-64-102-54-137.cisco.com (dhcp-64-102-54-137.cisco.com [64.102.54.137]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6NHGccN030266; Mon, 23 Jul 2012 17:16:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bo Berry In-Reply-To: Date: Mon, 23 Jul 2012 13:16:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15E2F358-45A5-4E54-A5E3-E9D604446E39@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1084) Cc: manet , Abdussalam Baryun , Thomas Clausen , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:16:42 -0000 +1, big agreement here! =20 On Jul 23, 2012, at 1:10 PM, Ulrich Herberg wrote: > I don't see the need for updating RFC5444 at the moment. >=20 > Best > Ulrich >=20 > On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) = wrote: > +1 >=20 > Regards, > Stan >=20 > On Jul 23, 2012, at 7:27 AM, Bo Berry wrote: >=20 > > As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) = are > > working on DLEP revisions. > > > > -Bo > > > > > > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: > > > >> I agree with Rick, and want to add a few things ... > >> > >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > >> > >>> Hi Abdussalam, > >>> > >>> I would recommend that you be very careful about attempting to > >>> adapt/extend RFC5444, particularly with respect to DLEP, because = it is > >>> still open to debate whether any future DLEP draft will use = RFC5444 for > >>> its packet format, and I believe the authors are leaning away from = it. > >> > >> Yes - plus, it is also not established yet that RFC5444 isn't = appropriate for carrying DLEP signals (should the authors/WG go that = way). > >> > >>> Also, there has been a lot of comment on this mailing list about = not > >>> updating RFC5444 yet as there appears little consensus about the = actual > >>> failings of the format w.r.t applicable protocols, i.e. all the > >>> 'complaints' about the format appear to be short-comings in the > >>> consuming protocols, not the packetBB format itself. > >> > >> +1 > >> > >>> Can you perhaps outline what you see as the failings of RFC5444 = here > >>> before you produce a lengthy document, in order to gather some = quick > >>> peer-review comments, as many on this list struggle to find time = to > >>> digest long formal drafts, and I wouldn't want you to suffer from = TL;DR > >>> ('too-long; didn't-read'). > >> > >> Even before that, it would be helpful to see a real routing = protocol (which DLEP is not), with a real usecase & industry behind it = (so, not just a thought experiment), with requirements pushed from real = deployments (so, outside of a lab), which is within the [manet] scope - = and for which its signals cannot properly be expressed in RFC5444. > >> > >> Best, > >> > >> Thomas > >> > >> > >>> Rick Taylor > >>> Cassidian Systems > >>> > >>>> -----Original Message----- > >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf > >>> Of > >>>> Abdussalam Baryun > >>>> Sent: 21 July 2012 14:33 > >>>> To: manet > >>>> Subject: [manet] Start work: update draft for RFC5444-Packets > >>>> > >>>> Hi > >>>> > >>>> I started working on a new draft to make some updates to the = RFC5444, > >>>> so manet-packets can be more used by AODVv2, DLEP, and other = possible > >>>> protocols. > >>>> > >>>> I will consider your input below of the discussions regarding > >>>> 5444-packets, also in the past there was a request that there is = a > >>>> need for how to use 5444, so this draft may include as well, > >>>> > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html > >>>> > >>>> If you have any comment or advise to this started work please = reply, > >>>> > >>>> AB > >>>> _______________________________________________ > >>>> 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 > > > > ---- > > 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 >=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 = 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 Mon Jul 23 10:25: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 B976521F8636 for ; Mon, 23 Jul 2012 10:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.418, 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 SdjK4nK7ANu1 for ; Mon, 23 Jul 2012 10:25: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 B7A3C21F8627 for ; Mon, 23 Jul 2012 10:25:18 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11283313obb.31 for ; Mon, 23 Jul 2012 10:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=EFuOZDD+I0TD6HWwnn+u8T4CCb80GA3v7zTPlc5U0Xk=; b=ggSX87pc7fynxpDslqkUUCnV7HhOklGBoYQAG13/UBsRyrTL6t24zu+1CCF6yUaA5S ROTGi1VFZaJdKNFcuX6k8hh0sjr8SNR97i3Qqu489VMug8cV/oX2rp2bHn8gRVVhSsN5 lCsx60CmC3p4ETlUpUjgFaD6YquRrRbT6qvjE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=EFuOZDD+I0TD6HWwnn+u8T4CCb80GA3v7zTPlc5U0Xk=; b=WAS+tRY5g/W6nT1UFCjX6cwSQbMURWMSNKxjIC0VmgqMjnXmDo1reHqqPcRJ68OPJR KRdN6N/dNNCUVFNIKmsB5Q7VFSoBxByGnBCNG6bkzqQiY2JX4aed8eBrOmbHpvo+Bovj S0aNbkbXxvxY8dbuT4klobmTpdIrUdC8Fj11EsvugUY76ku5B4ktpvwT3vtJ5JbNA616 UbEYv2zLem5sXT8nS652WRev92O2byo7/DAGocqF/lB6aTjB9X3NXd2WqhY5xeHXuIxk gO7CI1XjI25euqqVykqoRzmXknDsVzhBtr1VIT8pUWUjC0ISsJmQ3rB3nHrAoVRsOKpi xshA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr22340432obc.1.1343064318178; Mon, 23 Jul 2012 10:25:18 -0700 (PDT) Received: by 10.76.90.101 with HTTP; Mon, 23 Jul 2012 10:25:18 -0700 (PDT) Date: Mon, 23 Jul 2012 10:25:18 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=14dae9399bad9873e904c5828707 X-Gm-Message-State: ALoCoQnMCz08CjiWV9y3Nx/omUK6Xyp4lvvmgLZVq7y4EfUXIEW87sBy5eqqnp4Wr8S9bYkMMlyW Subject: [manet] Slides, please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:25:19 -0000 --14dae9399bad9873e904c5828707 Content-Type: text/plain; charset=ISO-8859-1 Hi, the MANET meeting takes place on Monday, July 30, 1pm in the Regency B room. The preliminary agenda can be found at: https://datatracker.ietf.org/meeting/84/agenda/manet To those who will present: please send the slides (preferably as PDF file) until Sunday, Jul 29, so that we have enough time to upload them. Thank you Ulrich --14dae9399bad9873e904c5828707 Content-Type: text/html; charset=ISO-8859-1 Hi,

the MANET meeting takes place on Monday, July 30, 1pm in the Regency B room. The preliminary agenda can be found at:
https://datatracker.ietf.org/meeting/84/agenda/manet

To those who will present: please send the slides (preferably as PDF file) until Sunday, Jul 29, so that we have enough time to upload them.

Thank you
Ulrich
--14dae9399bad9873e904c5828707-- From jpmacker@gmail.com Mon Jul 23 10:27: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 1CDE121F8642 for ; Mon, 23 Jul 2012 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 o20VPLJPX7Lx for ; Mon, 23 Jul 2012 10:27:55 -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 9ECA421F865F for ; Mon, 23 Jul 2012 10:27:55 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5390474vbb.31 for ; Mon, 23 Jul 2012 10:27:55 -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=r7slIYcYyTXQ0HRh38iRZbO8m2/lnmlYUZEX//sptl8=; b=rrVhMtDR6Epf2OkGAUHoM+EykESGCRO6BJqwD+6cUbx8vU2VWwZNpM0ZPZlIBtD0x3 lLz/nmova9EjU/eyLsFcD+ai5r2hwYg8ucKXJ7rFBqF2B4r2PR+p2dXNwSWYr6PkGvZX 8sUw409FluQBIES9jAK1zWMtFebGyha51ZucT7WOKNLD93vv2JerzLOnl8dMwwmx+o9I QFzcGJ8oBqUxTc86mi/MKAs97H/lR8g/3X1+ESge5d92OHvYpFsS103+sXoOWaJLLqvC WPlSOgOXi7pn99UnvSdFuReACUR65ugP7QW+Up6527slXxErMrU6Iue1VNWcXBY6gBHL zucA== MIME-Version: 1.0 Received: by 10.221.12.195 with SMTP id pj3mr13156370vcb.68.1343064474678; Mon, 23 Jul 2012 10:27:54 -0700 (PDT) Received: by 10.58.200.97 with HTTP; Mon, 23 Jul 2012 10:27:54 -0700 (PDT) In-Reply-To: <15E2F358-45A5-4E54-A5E3-E9D604446E39@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> <15E2F358-45A5-4E54-A5E3-E9D604446E39@cisco.com> Date: Mon, 23 Jul 2012 13:27:54 -0400 Message-ID: From: Joseph Macker To: manet Content-Type: multipart/alternative; boundary=bcaec54eeffcec746004c58290ee Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:27:57 -0000 --bcaec54eeffcec746004c58290ee Content-Type: text/plain; charset=ISO-8859-1 +1 also against this right now. On Mon, Jul 23, 2012 at 1:16 PM, Bo Berry wrote: > +1, big agreement here! > > On Jul 23, 2012, at 1:10 PM, Ulrich Herberg wrote: > > > I don't see the need for updating RFC5444 at the moment. > > > > Best > > Ulrich > > > > On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) < > sratliff@cisco.com> wrote: > > +1 > > > > Regards, > > Stan > > > > On Jul 23, 2012, at 7:27 AM, Bo Berry wrote: > > > > > As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) are > > > working on DLEP revisions. > > > > > > -Bo > > > > > > > > > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: > > > > > >> I agree with Rick, and want to add a few things ... > > >> > > >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > > >> > > >>> Hi Abdussalam, > > >>> > > >>> I would recommend that you be very careful about attempting to > > >>> adapt/extend RFC5444, particularly with respect to DLEP, because it > is > > >>> still open to debate whether any future DLEP draft will use RFC5444 > for > > >>> its packet format, and I believe the authors are leaning away from > it. > > >> > > >> Yes - plus, it is also not established yet that RFC5444 isn't > appropriate for carrying DLEP signals (should the authors/WG go that way). > > >> > > >>> Also, there has been a lot of comment on this mailing list about not > > >>> updating RFC5444 yet as there appears little consensus about the > actual > > >>> failings of the format w.r.t applicable protocols, i.e. all the > > >>> 'complaints' about the format appear to be short-comings in the > > >>> consuming protocols, not the packetBB format itself. > > >> > > >> +1 > > >> > > >>> Can you perhaps outline what you see as the failings of RFC5444 here > > >>> before you produce a lengthy document, in order to gather some quick > > >>> peer-review comments, as many on this list struggle to find time to > > >>> digest long formal drafts, and I wouldn't want you to suffer from > TL;DR > > >>> ('too-long; didn't-read'). > > >> > > >> Even before that, it would be helpful to see a real routing protocol > (which DLEP is not), with a real usecase & industry behind it (so, not just > a thought experiment), with requirements pushed from real deployments (so, > outside of a lab), which is within the [manet] scope - and for which its > signals cannot properly be expressed in RFC5444. > > >> > > >> Best, > > >> > > >> Thomas > > >> > > >> > > >>> Rick Taylor > > >>> Cassidian Systems > > >>> > > >>>> -----Original Message----- > > >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf > > >>> Of > > >>>> Abdussalam Baryun > > >>>> Sent: 21 July 2012 14:33 > > >>>> To: manet > > >>>> Subject: [manet] Start work: update draft for RFC5444-Packets > > >>>> > > >>>> Hi > > >>>> > > >>>> I started working on a new draft to make some updates to the > RFC5444, > > >>>> so manet-packets can be more used by AODVv2, DLEP, and other > possible > > >>>> protocols. > > >>>> > > >>>> I will consider your input below of the discussions regarding > > >>>> 5444-packets, also in the past there was a request that there is a > > >>>> need for how to use 5444, so this draft may include as well, > > >>>> > > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html > > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html > > >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html > > >>>> > > >>>> If you have any comment or advise to this started work please reply, > > >>>> > > >>>> AB > > >>>> _______________________________________________ > > >>>> 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 > > > > > > ---- > > > 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 > > > > _______________________________________________ > > 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 > --bcaec54eeffcec746004c58290ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 also against this right now.

On Mon, J= ul 23, 2012 at 1:16 PM, Bo Berry <boberry@cisco.com> wrote:<= br>
+1, big agreement here!

On Jul 23, 2012, at 1:10 PM, Ulrich Herberg wrote:

> I don't see the need for updating RFC5444 at the moment.
>
> Best
> Ulrich
>
> On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:
> +1
>
> Regards,
> Stan
>
> On Jul 23, 2012, at 7:27 AM, Bo Berry wrote:
>
> > As a co-author of DLEP, I agree w/ Rick&Thomas. =A0We (DLEP a= uthors) are
> > working on DLEP revisions.
> >
> > -Bo
> >
> >
> > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote:
> >
> >> I agree with Rick, and want to add a few things ...
> >>
> >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote:
> >>
> >>> Hi Abdussalam,
> >>>
> >>> I would recommend that you be very careful about attempti= ng to
> >>> adapt/extend RFC5444, particularly with respect to DLEP, = because it is
> >>> still open to debate whether any future DLEP draft will u= se RFC5444 for
> >>> its packet format, and I believe the authors are leaning = away from it.
> >>
> >> Yes - plus, it is also not established yet that RFC5444 isn&#= 39;t appropriate for carrying DLEP signals (should the authors/WG go that w= ay).
> >>
> >>> Also, there has been a lot of comment on this mailing lis= t about not
> >>> updating RFC5444 yet as there appears little consensus ab= out the actual
> >>> failings of the format w.r.t applicable protocols, i.e. a= ll the
> >>> 'complaints' about the format appear to be short-= comings in the
> >>> consuming protocols, not the packetBB format itself.
> >>
> >> +1
> >>
> >>> Can you perhaps outline what you see as the failings of R= FC5444 here
> >>> before you produce a lengthy document, in order to gather= some quick
> >>> peer-review comments, as many on this list struggle to fi= nd time to
> >>> digest long formal drafts, and I wouldn't want you to= suffer from TL;DR
> >>> ('too-long; didn't-read').
> >>
> >> Even before that, it would be helpful to see a real routing p= rotocol (which DLEP is not), with a real usecase & industry behind it (= so, not just a thought experiment), with requirements pushed from real depl= oyments (so, outside of a lab), which =A0is within the [manet] scope - and = for which its signals cannot properly be expressed in RFC5444.
> >>
> >> Best,
> >>
> >> Thomas
> >>
> >>
> >>> Rick Taylor
> >>> Cassidian Systems
> >>>
> >>>> -----Original Message-----
> >>>> From: manet= -bounces@ietf.org [mailto:man= et-bounces@ietf.org] On Behalf
> >>> Of
> >>>> Abdussalam Baryun
> >>>> Sent: 21 July 2012 14:33
> >>>> To: manet
> >>>> Subject: [manet] Start work: update draft for RFC5444= -Packets
> >>>>
> >>>> Hi
> >>>>
> >>>> I started working on a new draft to make some updates= to the RFC5444,
> >>>> so manet-packets can be more used by AODVv2, DLEP, an= d other possible
> >>>> protocols.
> >>>>
> >>>> I will consider your input below of =A0the discussion= s regarding
> >>>> 5444-packets, also in the past there was a request th= at there is a
> >>>> need for how to use 5444, so this draft may include a= s well,
> >>>>
> >>>> http://www.ietf.org/mail-archive/= web/manet/current/msg13212.html
> >>>> http://www.ietf.org/mail-archive/= web/manet/current/msg13105.html
> >>>> http://www.ietf.org/mail-archive/= web/manet/current/msg12430.html
> >>>>
> >>>> If you have any comment or advise to this started wor= k please reply,
> >>>>
> >>>> AB
> >>>> _______________________________________________
> >>>> manet mailing list
> >>>> manet@ietf.org<= br> > >>>> 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
> >
> > ----
> > boberry@cisco.com
> > This email may contain confidential and privileged material for t= he sole use of the intended recipient. This email may contain information t= hat is protected by NDA. Any unauthorized review, use, distribution or disc= losure by others is strictly prohibited. If you are not the intended recipi= ent (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
>
> _______________________________________________
> 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
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec54eeffcec746004c58290ee-- From drdanhe@gmail.com Mon Jul 23 10:30: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 042E311E8091 for ; Mon, 23 Jul 2012 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=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 3YTrahZfH-in for ; Mon, 23 Jul 2012 10:30:36 -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 6F56A11E808D for ; Mon, 23 Jul 2012 10:30:36 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4256769wgb.13 for ; Mon, 23 Jul 2012 10:30: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=dRvz33MqNXNvajTkdD59xUlpFRUDbA/ufM9BBjWZcdE=; b=ECDY+QycVZDAWEpC3LjZamzhGmhAJkGtb7fff3CYVheK4qvrESIrx65Z1NZY7Cq7cX r3s4IAtxAa3t5O/QBI+Bbyr+KFqBgPCD02CIcJSm1Hn0GL0z06XPJft5r282dz3wRRSP 2dWad9vjHFcVRk432hogEvjORL5M+NyKB1eqGFGg9cNbOVvxjQdVDdrnqap1V37ct5a3 a+ZzCtiD+fkqjvHUjdoRaG3tD9uWVWiZXAaZGXzRqsDW5GP44MxqbMc0BshB/FGoTMiu iVNs0220Fa6z4Tf2RCuxJsV4XZ76cps/ytwu9N24li+MwSZDL1b2Mc7/YQScSx6KPnmu jhRA== MIME-Version: 1.0 Received: by 10.216.242.196 with SMTP id i46mr1148705wer.140.1343064635355; Mon, 23 Jul 2012 10:30:35 -0700 (PDT) Received: by 10.194.47.10 with HTTP; Mon, 23 Jul 2012 10:30:35 -0700 (PDT) In-Reply-To: References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <6619DBF5-E3CD-4158-AECE-CFA6689C6CBD@cisco.com> <5D549284-A035-4393-8642-C8189E8171F7@cisco.com> Date: Mon, 23 Jul 2012 18:30:35 +0100 Message-ID: From: Daniel He To: Ulrich Herberg Content-Type: multipart/alternative; boundary=e0cb4e43ab8180337d04c5829a1f Cc: Thomas Clausen , manet , Abdussalam Baryun , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:30:38 -0000 --e0cb4e43ab8180337d04c5829a1f Content-Type: text/plain; charset=ISO-8859-1 Me 2 against this update. Regards, Dan On 23 July 2012 18:10, Ulrich Herberg wrote: > I don't see the need for updating RFC5444 at the moment. > > Best > Ulrich > > On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) < > sratliff@cisco.com> wrote: > >> +1 >> >> Regards, >> Stan >> >> On Jul 23, 2012, at 7:27 AM, Bo Berry wrote: >> >> > As a co-author of DLEP, I agree w/ Rick&Thomas. We (DLEP authors) are >> > working on DLEP revisions. >> > >> > -Bo >> > >> > >> > On Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote: >> > >> >> I agree with Rick, and want to add a few things ... >> >> >> >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >> >> >> >>> Hi Abdussalam, >> >>> >> >>> I would recommend that you be very careful about attempting to >> >>> adapt/extend RFC5444, particularly with respect to DLEP, because it is >> >>> still open to debate whether any future DLEP draft will use RFC5444 >> for >> >>> its packet format, and I believe the authors are leaning away from it. >> >> >> >> Yes - plus, it is also not established yet that RFC5444 isn't >> appropriate for carrying DLEP signals (should the authors/WG go that way). >> >> >> >>> Also, there has been a lot of comment on this mailing list about not >> >>> updating RFC5444 yet as there appears little consensus about the >> actual >> >>> failings of the format w.r.t applicable protocols, i.e. all the >> >>> 'complaints' about the format appear to be short-comings in the >> >>> consuming protocols, not the packetBB format itself. >> >> >> >> +1 >> >> >> >>> Can you perhaps outline what you see as the failings of RFC5444 here >> >>> before you produce a lengthy document, in order to gather some quick >> >>> peer-review comments, as many on this list struggle to find time to >> >>> digest long formal drafts, and I wouldn't want you to suffer from >> TL;DR >> >>> ('too-long; didn't-read'). >> >> >> >> Even before that, it would be helpful to see a real routing protocol >> (which DLEP is not), with a real usecase & industry behind it (so, not just >> a thought experiment), with requirements pushed from real deployments (so, >> outside of a lab), which is within the [manet] scope - and for which its >> signals cannot properly be expressed in RFC5444. >> >> >> >> Best, >> >> >> >> Thomas >> >> >> >> >> >>> Rick Taylor >> >>> Cassidian Systems >> >>> >> >>>> -----Original Message----- >> >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On >> Behalf >> >>> Of >> >>>> Abdussalam Baryun >> >>>> Sent: 21 July 2012 14:33 >> >>>> To: manet >> >>>> Subject: [manet] Start work: update draft for RFC5444-Packets >> >>>> >> >>>> Hi >> >>>> >> >>>> I started working on a new draft to make some updates to the RFC5444, >> >>>> so manet-packets can be more used by AODVv2, DLEP, and other possible >> >>>> protocols. >> >>>> >> >>>> I will consider your input below of the discussions regarding >> >>>> 5444-packets, also in the past there was a request that there is a >> >>>> need for how to use 5444, so this draft may include as well, >> >>>> >> >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >> >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >> >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >> >>>> >> >>>> If you have any comment or advise to this started work please reply, >> >>>> >> >>>> AB >> >>>> _______________________________________________ >> >>>> 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 >> > >> > ---- >> > 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 >> >> _______________________________________________ >> 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 > > -- Dan He --------------------- Tel: +44-788-686-3428 --e0cb4e43ab8180337d04c5829a1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Me 2 against this update.
Regards,
Dan

On 23 July 2012 18:10, Ulrich Herberg <ulric= h@herberg.name> wrote:
I don't see the need for updating= RFC5444 at the moment.

Best
Ulrich

On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (s= ratliff) <sratliff@cisco.com> wrote:
+1

Regards,
Stan

On Jul 23, 2012, at 7:27 AM, Bo Berry wrote:

> As a co-a= uthor of DLEP, I agree w/ Rick&Thomas. =A0We (DLEP authors) are
>= working on DLEP revisions.
>
> -Bo
>
>
> On = Jul 23, 2012, at 6:42 AM, Thomas Clausen wrote:
>
>> I agree with Rick, and want to add a few things ...
>= ;>
>> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote:
>&= gt;
>>> Hi Abdussalam,
>>>
>>> I would = recommend that you be very careful about attempting to
>>> adapt/extend RFC5444, particularly with respect to DLEP, becau= se it is
>>> still open to debate whether any future DLEP draft= will use RFC5444 for
>>> its packet format, and I believe the = authors are leaning away from it.
>>
>> Yes - plus, it is also not established yet that RFC544= 4 isn't appropriate for carrying DLEP signals (should the authors/WG go= that way).
>>
>>> Also, there has been a lot of comme= nt on this mailing list about not
>>> updating RFC5444 yet as there appears little consensus about t= he actual
>>> failings of the format w.r.t applicable protocols= , i.e. all the
>>> 'complaints' about the format appear= to be short-comings in the
>>> consuming protocols, not the packetBB format itself.
>&g= t;
>> +1
>>
>>> Can you perhaps outline what = you see as the failings of RFC5444 here
>>> before you produce = a lengthy document, in order to gather some quick
>>> peer-review comments, as many on this list struggle to find ti= me to
>>> digest long formal drafts, and I wouldn't want yo= u to suffer from TL;DR
>>> ('too-long; didn't-read'= ).
>>
>> Even before that, it would be helpful to see a real ro= uting protocol (which DLEP is not), with a real usecase & industry behi= nd it (so, not just a thought experiment), with requirements pushed from re= al deployments (so, outside of a lab), which =A0is within the [manet] scope= - and for which its signals cannot properly be expressed in RFC5444.
>>
>> Best,
>>
>> Thomas
>>
&g= t;>
>>> Rick Taylor
>>> Cassidian Systems
>= ;>>
>>>> -----Original Message-----
>>>>= ; From: manet-b= ounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
>>> Of
>>>> Abdussalam Baryun
>>>> S= ent: 21 July 2012 14:33
>>>> To: manet
>>>> S= ubject: [manet] Start work: update draft for RFC5444-Packets
>>>= ;>
>>>> Hi
>>>>
>>>> I started worki= ng on a new draft to make some updates to the RFC5444,
>>>> = so manet-packets can be more used by AODVv2, DLEP, and other possible
>>>> protocols.
>>>>
>>>> I will = consider your input below of =A0the discussions regarding
>>>&g= t; 5444-packets, also in the past there was a request that there is a
>>>> need for how to use 5444, so this draft may include as wel= l,
>>>>
>>>> http://www.i= etf.org/mail-archive/web/manet/current/msg13212.html
>>>> http://www.ietf.org/mail-archive/web/m= anet/current/msg13105.html
>>>> http= ://www.ietf.org/mail-archive/web/manet/current/msg12430.html
>>>>
>>>> If you have any comment or advise to t= his started work please reply,
>>>>
>>>> AB>>>> _______________________________________________
>&= gt;>> manet mailing list
>>>> manet@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/manet=
>>> _______________________________________________
>>>= ; manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailma= n/listinfo/manet
>>
>> _______________________________________________
>= ;> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/li= stinfo/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 a= re not the intended recipient (or authorized to receive for the recipient),= please contact the sender by reply email and delete all copies of this mes= sage.
>
> _______________________________________________
> manet = mailing list
> ma= net@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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


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




--
Dan He
---------= ------------
Tel: +44-788-686-3428

--e0cb4e43ab8180337d04c5829a1f-- From jpmacker@gmail.com Mon Jul 23 10:31: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 710CB11E80DE for ; Mon, 23 Jul 2012 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 lkR8jwOvG94N for ; Mon, 23 Jul 2012 10:31:36 -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 ABE3211E80CE for ; Mon, 23 Jul 2012 10:31:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5394332vbb.31 for ; Mon, 23 Jul 2012 10:31:36 -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=tTNO04CU4Vju0R23zMr8W7z9a/d2FjDk1z7m1JXxHOI=; b=Aw5zY8cp9NfXQQ0Q2L4XsCkc6K5S1hjXdkbfc0j2ldnsHAy1btrdOgJw+XkqFhC/Ea gZjUK+2k33JbrUNAegNCx/k8mxGYioPytngKcqpeGHPY4VwWXUKEIGjzVmTuoZRJ8v3e iipG4ZWGt40LwjF3gx9LZXCxT+vqtUSWYfbN/dG2sAZ6b7cqgzg5Vuo2mRjaxTPMgXLy R1O2mVwpGKbML6Vx6pipnbij2DTWF20WTJAJAH1OD00okmCMfiztLoCwL50Z2pAGrEgJ 5c7fUsIN1kf2qz/KIDHwDtGkBOtpVtbvEARSZGVPmoJZAaUe+vLloZvLF+L4YSUI+DvB Ri0g== MIME-Version: 1.0 Received: by 10.52.73.225 with SMTP id o1mr11572263vdv.77.1343064696101; Mon, 23 Jul 2012 10:31:36 -0700 (PDT) Received: by 10.58.200.97 with HTTP; Mon, 23 Jul 2012 10:31:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jul 2012 13:31:36 -0400 Message-ID: From: Joseph Macker To: Ulrich Herberg , Joseph Macker , Stan Ratliff Content-Type: multipart/alternative; boundary=20cf307f34941f1b3e04c5829e57 Cc: manet@ietf.org Subject: Re: [manet] Slides, please X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:31:37 -0000 --20cf307f34941f1b3e04c5829e57 Content-Type: text/plain; charset=ISO-8859-1 Please cc the WG chairs and the secretary on your slide submissions this well avoid problems due to early week presentations and travet,etc On Mon, Jul 23, 2012 at 1:25 PM, Ulrich Herberg wrote: > Hi, > > the MANET meeting takes place on Monday, July 30, 1pm in the Regency B > room. The preliminary agenda can be found at: > https://datatracker.ietf.org/meeting/84/agenda/manet > > To those who will present: please send the slides (preferably as PDF file) > until Sunday, Jul 29, so that we have enough time to upload them. > > Thank you > Ulrich > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --20cf307f34941f1b3e04c5829e57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please cc the WG chairs and the secretary on your slide submissions this we= ll avoid problems due to early week presentations and travet,etc

On Mon, Jul 23, 2012 at 1:25 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Hi,

the MANET meeting takes place on = Monday, July 30, 1pm in the Regency B room. The preliminary agenda can be f= ound at:
https://datatracker.ietf.org/meeting/84/agenda/manet

To those who will present: please send the slides (preferably as PDF fi= le) until Sunday, Jul 29, so that we have enough time to upload them.
Thank you
Ulrich

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


--20cf307f34941f1b3e04c5829e57-- From Chris.Dearlove@baesystems.com Tue Jul 24 03:09: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 7B63121F85E6 for ; Tue, 24 Jul 2012 03:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.911 X-Spam-Level: X-Spam-Status: No, score=-9.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_22=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 LBRusurYYtAf for ; Tue, 24 Jul 2012 03:09:55 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 377F021F85C5 for ; Tue, 24 Jul 2012 03:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,644,1336345200"; d="scan'208";a="258503976" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Jul 2012 11:09: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 q6OA9q74029385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 11:09:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.170]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Tue, 24 Jul 2012 11:09:51 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Clausen , Rick Taylor Thread-Topic: [manet] Start work: update draft for RFC5444-Packets Thread-Index: Ac1nRVEzzhn4U2H5KU6ASYD45y798ABbSaUgAAE9JYAAMsdtoA== Date: Tue, 24 Jul 2012 10:09:51 +0000 Message-ID: References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> In-Reply-To: <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 10:09:56 -0000 I want to be a bit stronger than the various +1s that have been added. Work in the IETF should be about things that people want. And in particular= 5444, and other supporting documents, is always going to be the last place= to start. There are at least two steps before that, and more if you break = things down. First it's what do users want? And second it's what do protoco= ls need to do? You'd start with first that people need this (for some value= of this that matters to a user) to happen. Then second that needs a protoc= ol that, once designed (one of the sub-steps noted) needs this information = transferred. And only then, right at the end of the journey, it's saying "I= can't see how to do this in 5444" and waiting to see if someone else says = "but I can". Only at the end of that process (and putting aside also possib= ilities of not using 5444, so it's only MANET routing protocols that the us= e of 5444 is strongly preferable) do you get to "should we update 5444" and= even then you need to recognise the significant costs of so doing in the i= ssues of versions and normative dependences. (And if you don't understand t= hose issuers, you shouldn't be going anywhere near it.) And that's putting = aside issues of who owns what aspects of 5444 (which are also important). I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, but it= 's all starting from drafts and revisions (link layer, terminology, 2501, D= SR, 5444 and others I may have missed and/or outside this WG). Those are no= t the starting points. All have preceding steps, and all include the questi= on "is this what we want?" and so far (in the five quoted examples at least= ) it's always been "no", or at least "no case has been made for that yet, a= nd a strong one would be needed". --=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: Thomas Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 23 July 2012 11:42 To: Rick Taylor Cc: Abdussalam Baryun; manet Subject: Re: [manet] Start work: update draft for RFC5444-Packets ----------------------! 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 agree with Rick, and want to add a few things ... On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: > Hi Abdussalam, >=20 > I would recommend that you be very careful about attempting to > adapt/extend RFC5444, particularly with respect to DLEP, because it is > still open to debate whether any future DLEP draft will use RFC5444 for > its packet format, and I believe the authors are leaning away from it. Yes - plus, it is also not established yet that RFC5444 isn't appropriate f= or carrying DLEP signals (should the authors/WG go that way). > Also, there has been a lot of comment on this mailing list about not > updating RFC5444 yet as there appears little consensus about the actual > failings of the format w.r.t applicable protocols, i.e. all the > 'complaints' about the format appear to be short-comings in the > consuming protocols, not the packetBB format itself. +1 > Can you perhaps outline what you see as the failings of RFC5444 here > before you produce a lengthy document, in order to gather some quick > peer-review comments, as many on this list struggle to find time to > digest long formal drafts, and I wouldn't want you to suffer from TL;DR > ('too-long; didn't-read'). Even before that, it would be helpful to see a real routing protocol (which= DLEP is not), with a real usecase & industry behind it (so, not just a tho= ught experiment), with requirements pushed from real deployments (so, outsi= de of a lab), which is within the [manet] scope - and for which its signal= s cannot properly be expressed in RFC5444. Best, Thomas > Rick Taylor > Cassidian Systems >=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of >> Abdussalam Baryun >> Sent: 21 July 2012 14:33 >> To: manet >> Subject: [manet] Start work: update draft for RFC5444-Packets >>=20 >> Hi >>=20 >> I started working on a new draft to make some updates to the RFC5444, >> so manet-packets can be more used by AODVv2, DLEP, and other possible >> protocols. >>=20 >> I will consider your input below of the discussions regarding >> 5444-packets, also in the past there was a request that there is a >> need for how to use 5444, so this draft may include as well, >>=20 >> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>=20 >> If you have any comment or advise to this started work please reply, >>=20 >> AB >> _______________________________________________ >> 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 Jul 24 03:25: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 E00A121F85AC for ; Tue, 24 Jul 2012 03:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 aCxs3LfSnPz6 for ; Tue, 24 Jul 2012 03:25:17 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 60A6A21F84CD for ; Tue, 24 Jul 2012 03:25:14 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 24 Jul 2012 12:25:12 +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, 24 Jul 2012 12:25:11 +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, 24 Jul 2012 12:25:11 +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, 24 Jul 2012 12:25:11 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 11:24:37 +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, 24 Jul 2012 11:25:10 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1046E9C9F@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Start work: update draft for RFC5444-Packets Thread-Index: Ac1phHspPweXXqcERCqgKjAXy3lziQAAg7aw References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> From: "Rick Taylor" To: "Dearlove, Christopher (UK)" , "Thomas Clausen" X-OriginalArrivalTime: 24 Jul 2012 10:24:37.0549 (UTC) FILETIME=[870665D0:01CD6986] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19060.006 X-TM-AS-Result: No--48.693100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 10:25:18 -0000 +1 (or more if allowed) Rick Taylor > -----Original Message----- > From: Dearlove, Christopher (UK) = [mailto:Chris.Dearlove@baesystems.com] > Sent: 24 July 2012 11:10 > To: Thomas Clausen; Rick Taylor > Cc: Abdussalam Baryun; manet > Subject: RE: [manet] Start work: update draft for RFC5444-Packets >=20 > I want to be a bit stronger than the various +1s that have been added. >=20 > Work in the IETF should be about things that people want. And in > particular 5444, and other supporting documents, is always going to be = the > last place to start. There are at least two steps before that, and = more if > you break things down. First it's what do users want? And second it's = what > do protocols need to do? You'd start with first that people need this = (for > some value of this that matters to a user) to happen. Then second that > needs a protocol that, once designed (one of the sub-steps noted) = needs > this information transferred. And only then, right at the end of the > journey, it's saying "I can't see how to do this in 5444" and waiting = to > see if someone else says "but I can". Only at the end of that process = (and > putting aside also possibilities of not using 5444, so it's only MANET > routing protocols that the use of 5444 is strongly preferable) do you = get > to "should we update 5444" and even then you need to recognise the > significant costs of so doing in the issues of versions and normative > dependences. (And if you don't understand those issuers, you shouldn't = be > going anywhere near it.) And that's putting aside issues of who owns = what > aspects of 5444 (which are also important). >=20 > I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, = but > it's all starting from drafts and revisions (link layer, terminology, > 2501, DSR, 5444 and others I may have missed and/or outside this WG). > Those are not the starting points. All have preceding steps, and all > include the question "is this what we want?" and so far (in the five > quoted examples at least) it's always been "no", or at least "no case = has > been made for that yet, and a strong one would be needed". >=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: Thomas Clausen [mailto:thomas@thomasclausen.org] > Sent: 23 July 2012 11:42 > To: Rick Taylor > Cc: Abdussalam Baryun; manet > Subject: Re: [manet] Start work: update draft for RFC5444-Packets >=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 agree with Rick, and want to add a few things ... >=20 > On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >=20 > > Hi Abdussalam, > > > > I would recommend that you be very careful about attempting to > > adapt/extend RFC5444, particularly with respect to DLEP, because it = is > > still open to debate whether any future DLEP draft will use RFC5444 = for > > its packet format, and I believe the authors are leaning away from = it. >=20 > Yes - plus, it is also not established yet that RFC5444 isn't = appropriate > for carrying DLEP signals (should the authors/WG go that way). >=20 > > Also, there has been a lot of comment on this mailing list about not > > updating RFC5444 yet as there appears little consensus about the = actual > > failings of the format w.r.t applicable protocols, i.e. all the > > 'complaints' about the format appear to be short-comings in the > > consuming protocols, not the packetBB format itself. >=20 > +1 >=20 > > Can you perhaps outline what you see as the failings of RFC5444 here > > before you produce a lengthy document, in order to gather some quick > > peer-review comments, as many on this list struggle to find time to > > digest long formal drafts, and I wouldn't want you to suffer from = TL;DR > > ('too-long; didn't-read'). >=20 > Even before that, it would be helpful to see a real routing protocol > (which DLEP is not), with a real usecase & industry behind it (so, not > just a thought experiment), with requirements pushed from real = deployments > (so, outside of a lab), which is within the [manet] scope - and for = which > its signals cannot properly be expressed in RFC5444. >=20 > Best, >=20 > Thomas >=20 >=20 > > Rick Taylor > > Cassidian Systems > > > >> -----Original Message----- > >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf > > Of > >> Abdussalam Baryun > >> Sent: 21 July 2012 14:33 > >> To: manet > >> Subject: [manet] Start work: update draft for RFC5444-Packets > >> > >> Hi > >> > >> I started working on a new draft to make some updates to the = RFC5444, > >> so manet-packets can be more used by AODVv2, DLEP, and other = possible > >> protocols. > >> > >> I will consider your input below of the discussions regarding > >> 5444-packets, also in the past there was a request that there is a > >> need for how to use 5444, so this draft may include as well, > >> > >> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html > >> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html > >> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html > >> > >> If you have any comment or advise to this started work please = reply, > >> > >> AB > >> _______________________________________________ > >> 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 >=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 ietf@thomasclausen.org Tue Jul 24 04:04: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 5901421F860F for ; Tue, 24 Jul 2012 04:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 h4Hqu0bX1iHC for ; Tue, 24 Jul 2012 04:04:34 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC7A21F85F9 for ; Tue, 24 Jul 2012 04:04:34 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E3351557F70 for ; Tue, 24 Jul 2012 04:04:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 28E031BC5A7F; Tue, 24 Jul 2012 04:04:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6487B1BC5A7E; Tue, 24 Jul 2012 04:04:32 -0700 (PDT) References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <7B31B0093014224A843C10C0CCE92AC1046E9C9F@SUKNPT8106.cogent-dsn.local> In-Reply-To: <7B31B0093014224A843C10C0CCE92AC1046E9C9F@SUKNPT8106.cogent-dsn.local> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <67278D29-A0C0-423B-B4B3-30F692900B73@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Tue, 24 Jul 2012 13:05:27 +0200 To: Rick Taylor Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 11:04:35 -0000 I couldn't have phrased it better than Chris. +1000 -- 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 24 Jul 2012, at 12:25, "Rick Taylor" wrote: > +1 (or more if allowed) > > Rick Taylor > >> -----Original Message----- >> From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >> Sent: 24 July 2012 11:10 >> To: Thomas Clausen; Rick Taylor >> Cc: Abdussalam Baryun; manet >> Subject: RE: [manet] Start work: update draft for RFC5444-Packets >> >> I want to be a bit stronger than the various +1s that have been added. >> >> Work in the IETF should be about things that people want. And in >> particular 5444, and other supporting documents, is always going to be the >> last place to start. There are at least two steps before that, and more if >> you break things down. First it's what do users want? And second it's what >> do protocols need to do? You'd start with first that people need this (for >> some value of this that matters to a user) to happen. Then second that >> needs a protocol that, once designed (one of the sub-steps noted) needs >> this information transferred. And only then, right at the end of the >> journey, it's saying "I can't see how to do this in 5444" and waiting to >> see if someone else says "but I can". Only at the end of that process (and >> putting aside also possibilities of not using 5444, so it's only MANET >> routing protocols that the use of 5444 is strongly preferable) do you get >> to "should we update 5444" and even then you need to recognise the >> significant costs of so doing in the issues of versions and normative >> dependences. (And if you don't understand those issuers, you shouldn't be >> going anywhere near it.) And that's putting aside issues of who owns what >> aspects of 5444 (which are also important). >> >> I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, but >> it's all starting from drafts and revisions (link layer, terminology, >> 2501, DSR, 5444 and others I may have missed and/or outside this WG). >> Those are not the starting points. All have preceding steps, and all >> include the question "is this what we want?" and so far (in the five >> quoted examples at least) it's always been "no", or at least "no case has >> been made for that yet, and a strong one would be needed". >> >> -- >> 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: Thomas Clausen [mailto:thomas@thomasclausen.org] >> Sent: 23 July 2012 11:42 >> To: Rick Taylor >> Cc: Abdussalam Baryun; manet >> Subject: Re: [manet] Start work: update draft for RFC5444-Packets >> >> ----------------------! 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 agree with Rick, and want to add a few things ... >> >> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >> >>> Hi Abdussalam, >>> >>> I would recommend that you be very careful about attempting to >>> adapt/extend RFC5444, particularly with respect to DLEP, because it is >>> still open to debate whether any future DLEP draft will use RFC5444 for >>> its packet format, and I believe the authors are leaning away from it. >> >> Yes - plus, it is also not established yet that RFC5444 isn't appropriate >> for carrying DLEP signals (should the authors/WG go that way). >> >>> Also, there has been a lot of comment on this mailing list about not >>> updating RFC5444 yet as there appears little consensus about the actual >>> failings of the format w.r.t applicable protocols, i.e. all the >>> 'complaints' about the format appear to be short-comings in the >>> consuming protocols, not the packetBB format itself. >> >> +1 >> >>> Can you perhaps outline what you see as the failings of RFC5444 here >>> before you produce a lengthy document, in order to gather some quick >>> peer-review comments, as many on this list struggle to find time to >>> digest long formal drafts, and I wouldn't want you to suffer from TL;DR >>> ('too-long; didn't-read'). >> >> Even before that, it would be helpful to see a real routing protocol >> (which DLEP is not), with a real usecase & industry behind it (so, not >> just a thought experiment), with requirements pushed from real deployments >> (so, outside of a lab), which is within the [manet] scope - and for which >> its signals cannot properly be expressed in RFC5444. >> >> Best, >> >> Thomas >> >> >>> Rick Taylor >>> Cassidian Systems >>> >>>> -----Original Message----- >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>> Of >>>> Abdussalam Baryun >>>> Sent: 21 July 2012 14:33 >>>> To: manet >>>> Subject: [manet] Start work: update draft for RFC5444-Packets >>>> >>>> Hi >>>> >>>> I started working on a new draft to make some updates to the RFC5444, >>>> so manet-packets can be more used by AODVv2, DLEP, and other possible >>>> protocols. >>>> >>>> I will consider your input below of the discussions regarding >>>> 5444-packets, also in the past there was a request that there is a >>>> need for how to use 5444, so this draft may include as well, >>>> >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>>> >>>> If you have any comment or advise to this started work please reply, >>>> >>>> AB >>>> _______________________________________________ >>>> 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 Tue Jul 24 07:22: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 48EE221F8678 for ; Tue, 24 Jul 2012 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_22=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 9tBIs6BkfGQA for ; Tue, 24 Jul 2012 07:22: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 E930E21F865C for ; Tue, 24 Jul 2012 07:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=7859; q=dns/txt; s=iport; t=1343139751; x=1344349351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cea31nQp1VZ+GYBFVK17iFvaGhNFFqLOmryLZv0/lYI=; b=ghlQu7ALP79JKZbub3CeXnrCNKuCga0ft6iVkH/xeFxMuLzlfq2RGZ55 DlI11Qy3wMOxC6CqxpJWny/JNL78OwrZkqAuz5GwX49NX+odFn9ylKr7U i54CdjeJr5ZXcvhUgJFtOuLXUf8aahZ2x4uIOHgbgFCydDlfCAEYjQWsl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALiuDlCtJV2b/2dsb2JhbABFuXKBB4IgAQEBAwEBAQEPAScbGQMIBQcEAgEIEQQBAQEeCQcnCxQJCAIECgQFCRmHZQYLmw+gQ4tLFAYIhXJgA5VJjieBZoJfgVYJ X-IronPort-AV: E=Sophos;i="4.77,646,1336348800"; d="scan'208";a="104792250" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jul 2012 14:22:30 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6OEMU8S024689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 14:22:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 09:22:29 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Start work: update draft for RFC5444-Packets Thread-Index: Ac1nRVEz4qnqj1lUdUWZmFtP9xSwrQBbSaUgAA3PzIAAMSoegAAAiPEAAAFoKYAABuF3AA== Date: Tue, 24 Jul 2012 14:22:29 +0000 Message-ID: <9BD12E7B-F852-473D-9EC6-A5397EBE89FD@cisco.com> References: <7B31B0093014224A843C10C0CCE92AC10467359C@SUKNPT8106.cogent-dsn.local> <302BB11B-A830-4AD7-AF05-728134C90A4F@thomasclausen.org> <7B31B0093014224A843C10C0CCE92AC1046E9C9F@SUKNPT8106.cogent-dsn.local> <67278D29-A0C0-423B-B4B3-30F692900B73@thomasclausen.org> In-Reply-To: <67278D29-A0C0-423B-B4B3-30F692900B73@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.006 x-tm-as-result: No--54.301000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] Start work: update draft for RFC5444-Packets X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 14:22:32 -0000 Well said, Chris. I completely agree.=20 Regards, Stan On Jul 24, 2012, at 7:05 AM, Thomas Heide Clausen wrote: > I couldn't have phrased it better than Chris. >=20 > +1000 >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees >=20 >=20 > On 24 Jul 2012, at 12:25, "Rick Taylor" wrote= : >=20 >> +1 (or more if allowed) >>=20 >> Rick Taylor >>=20 >>> -----Original Message----- >>> From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] >>> Sent: 24 July 2012 11:10 >>> To: Thomas Clausen; Rick Taylor >>> Cc: Abdussalam Baryun; manet >>> Subject: RE: [manet] Start work: update draft for RFC5444-Packets >>>=20 >>> I want to be a bit stronger than the various +1s that have been added. >>>=20 >>> Work in the IETF should be about things that people want. And in >>> particular 5444, and other supporting documents, is always going to be = the >>> last place to start. There are at least two steps before that, and more= if >>> you break things down. First it's what do users want? And second it's w= hat >>> do protocols need to do? You'd start with first that people need this (= for >>> some value of this that matters to a user) to happen. Then second that >>> needs a protocol that, once designed (one of the sub-steps noted) needs >>> this information transferred. And only then, right at the end of the >>> journey, it's saying "I can't see how to do this in 5444" and waiting t= o >>> see if someone else says "but I can". Only at the end of that process (= and >>> putting aside also possibilities of not using 5444, so it's only MANET >>> routing protocols that the use of 5444 is strongly preferable) do you g= et >>> to "should we update 5444" and even then you need to recognise the >>> significant costs of so doing in the issues of versions and normative >>> dependences. (And if you don't understand those issuers, you shouldn't = be >>> going anywhere near it.) And that's putting aside issues of who owns wh= at >>> aspects of 5444 (which are also important). >>>=20 >>> I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, bu= t >>> it's all starting from drafts and revisions (link layer, terminology, >>> 2501, DSR, 5444 and others I may have missed and/or outside this WG). >>> Those are not the starting points. All have preceding steps, and all >>> include the question "is this what we want?" and so far (in the five >>> quoted examples at least) it's always been "no", or at least "no case h= as >>> been made for that yet, and a strong one would be needed". >>>=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 Cent= re, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Thomas Clausen [mailto:thomas@thomasclausen.org] >>> Sent: 23 July 2012 11:42 >>> To: Rick Taylor >>> Cc: Abdussalam Baryun; manet >>> Subject: Re: [manet] Start work: update draft for RFC5444-Packets >>>=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 agree with Rick, and want to add a few things ... >>>=20 >>> On Jul 23, 2012, at 11:16 AM, Rick Taylor wrote: >>>=20 >>>> Hi Abdussalam, >>>>=20 >>>> I would recommend that you be very careful about attempting to >>>> adapt/extend RFC5444, particularly with respect to DLEP, because it is >>>> still open to debate whether any future DLEP draft will use RFC5444 fo= r >>>> its packet format, and I believe the authors are leaning away from it. >>>=20 >>> Yes - plus, it is also not established yet that RFC5444 isn't appropria= te >>> for carrying DLEP signals (should the authors/WG go that way). >>>=20 >>>> Also, there has been a lot of comment on this mailing list about not >>>> updating RFC5444 yet as there appears little consensus about the actua= l >>>> failings of the format w.r.t applicable protocols, i.e. all the >>>> 'complaints' about the format appear to be short-comings in the >>>> consuming protocols, not the packetBB format itself. >>>=20 >>> +1 >>>=20 >>>> Can you perhaps outline what you see as the failings of RFC5444 here >>>> before you produce a lengthy document, in order to gather some quick >>>> peer-review comments, as many on this list struggle to find time to >>>> digest long formal drafts, and I wouldn't want you to suffer from TL;D= R >>>> ('too-long; didn't-read'). >>>=20 >>> Even before that, it would be helpful to see a real routing protocol >>> (which DLEP is not), with a real usecase & industry behind it (so, not >>> just a thought experiment), with requirements pushed from real deployme= nts >>> (so, outside of a lab), which is within the [manet] scope - and for wh= ich >>> its signals cannot properly be expressed in RFC5444. >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>=20 >>>> Rick Taylor >>>> Cassidian Systems >>>>=20 >>>>> -----Original Message----- >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behal= f >>>> Of >>>>> Abdussalam Baryun >>>>> Sent: 21 July 2012 14:33 >>>>> To: manet >>>>> Subject: [manet] Start work: update draft for RFC5444-Packets >>>>>=20 >>>>> Hi >>>>>=20 >>>>> I started working on a new draft to make some updates to the RFC5444, >>>>> so manet-packets can be more used by AODVv2, DLEP, and other possible >>>>> protocols. >>>>>=20 >>>>> I will consider your input below of the discussions regarding >>>>> 5444-packets, also in the past there was a request that there is a >>>>> need for how to use 5444, so this draft may include as well, >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html >>>>> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html >>>>>=20 >>>>> If you have any comment or advise to this started work please reply, >>>>>=20 >>>>> AB >>>>> _______________________________________________ >>>>> 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 >>>=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. >>> ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From maxpassion@gmail.com Tue Jul 24 20: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 58EFA21F84CD; Tue, 24 Jul 2012 20:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 AHiAXbx42i4L; Tue, 24 Jul 2012 20:26:43 -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 36A9721F84C9; Tue, 24 Jul 2012 20:26:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so455460obb.31 for ; Tue, 24 Jul 2012 20:26: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:content-transfer-encoding; bh=rdjQoylG7IWI5bceVq1pEN7ULm5wCG5Su23oVLuD28E=; b=UjH1XeFf8/ghNTnDNo5jZC9tAfsqZCwL3YGSsx2KxhxvSQJQY4JCsb2rijG/kh1jX3 8QQPPhl0tZH/unbhQOppX8fB3FFNgHDQNWqa591stfWWLWif6CoSMmYY3bxaqPiR3QOM bE+WTTscibcHHahykO6jzQD60nCvoVMyHMhkYEzU98qX6BHbWD4FivhdXKxwQjTVrmMD eiON9xmi3NhW3kWewH2dL0LEn/CzT7bm2+VQL6wKunGevUF/DidukSIYfBwH7+hRqgZn aYL6Pfi3LQj3HLVYyQUAe19ixV2z3x77oo+OYgrfMmwFL1JeyI5fMUye/ip+6enSFr4A Q0Wg== MIME-Version: 1.0 Received: by 10.182.95.142 with SMTP id dk14mr31667421obb.2.1343186799693; Tue, 24 Jul 2012 20:26:39 -0700 (PDT) Received: by 10.76.139.136 with HTTP; Tue, 24 Jul 2012 20:26:39 -0700 (PDT) In-Reply-To: <4FF2A65E.2080000@gmail.com> References: <4FF2A65E.2080000@gmail.com> Date: Wed, 25 Jul 2012 11:26:39 +0800 Message-ID: From: liu dapeng To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 03:26:44 -0000 Hi Alex, Regarding v2v communication: 1. If the mobile routers have LTE link and use IPv6, then v2v communication can also rely on LTE? The precondition is that one vehicle knows the other vehicle's identity (for example, every mobile router have a domain name and can be updated dynamically). 2. Even in the above v2v case, Mobile IP could also be useful? Since mobile IP can provide a stable IP address, the mobile routers do not need to update the domain name dynamically, it can use the home address when registering in the domain system. Any comments? Thanks, Best regards, Dapeng 2012/7/3, Alexandru Petrescu : > Hi Abdussalam and thanks for the reply. > > Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >> Hi Alex and All, >> >>> Scenario : A router deployed in a moving vehicle, uses its egress >>> interface to connect to larger-area access network(s) or to other >>> vehicles. >> >> Should it use IPv6-over-LTE? > > In our context we consider indeed IPv6 over LTE, for several reasons. > The 3GPP specs about LTE seem to be very specific and detailed about the > use of IPv6. (In the past, before LTE, the earlier 3GPP specs were > mentioning IPv6 but more like an option feature.) > > However, the 3GPP specs about the use of IPv6 have some lack of > specification in the case that the UE (User Terminal) is actually a > Mobile Router. The Prefix Delegation part may be underspecified. > >> Should it use Mobile IP? > > Hmm... that is a good question and much can be said about it. I am > interested to liste others' oppinions as well. > > I think Mobile IP may be necessary but not sufficient. In the case of > direct vehicle-to-vehicle IP communications (non covered areas) Mobile > IP may not be necessary. It may be that extensions to Neighbor > Discovery and DHCP could help establish paths within local topologies. > > And, when that is done (e.g. exchange routes between two vehicles using > RA) it may become apparent that interactions between Mobile IP and this > mechanism may be necessary. > >>> Open to discussion: what are the scenarios? > > We are interested in describing the scenarios. There may exist several > possibilities. I think of the following lego-like approach: > > - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. > - scenario MR-to-MR - conceive prefixes in Router Advertisements, > compare to other dynamic routing approaches. > - scenario MR-to-MR-to-Infrastructure - combine the above two. > > Another direction is classify the kinds of vehicles. I think of > something like this: > > - Internet Vehicle (has a plethora of interfaces, long- and short- > range). > - Range Extending Vehicle - extends the range of reachability. > - Leaf Vehicle - like and end-node. > > Then there are other scenario statements that could open the path to the > following: > - addressability within vehicle, ULA, VIN. > - problem of bandwidth difference between inside and outside the > vehicle. > >> What are the potential work items? What might be needed, >> if anything at all? >> >> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS >> issues and in your questions directions. I will join the ITS-WG which >> I think can have relation to MANET [RFC2501]. > > Well, hmm. I am happy to hear that but let us go easy about this. > > "ITS" at IETF is currently just an informal effort. Its future may be > ambitious but right now it's not a WG. To do that, we'd need to make a > BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward= . > > Secod, RFC2501 and ad-hoc routing are just one possibility to continue > working on this. Some people may express positive technical feedback > about MANET and others less so. > >> IMO that vehicle routers communications depend on both their >> communication protocols and the used-network for such communication >> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO >> there is no doubt that Mobile IP [RFC6275] is needed for the router's >> if the communication is through the Internet's domain(s), but if it >> is through Ad-hoc networks' domain(s) it MAY not be used. > > I tend to agree that Mobile IP may not be needed between vehicles which > communicate directly without infrastructure. Then one wonders _what_ is > needed? > >> The Internet is an infrastructure network and Ad-hoc networks are >> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with >> the WG answers, and will read more into the WG inputs regarding these >> issues. > > (see above note about this "WG" acronym which ITS is not currently) > >> I will schedule to participate/prepare I-D in the future for ITS >> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET >> routing protocol that fits the use-case of ITS and VANET as well. > > I am interested to work on scenario/reqs drafts for ITS. > > About "DSRv2" - is it still about Routing Headers? > > I am interested to hear others' oppinions as well. > > Yours, > > Alex > >> >> Regards >> >> Abdussalam Baryun University of Glamorgan, UK >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> From: Alexandru Petrescu To: its >> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >> Scenarios, potential topics... >> ------------------------------------------------------------------------= -------- >> >> >> >> >> > Welcome to the ITS list at IETF, an informal discussion. >> >> Earlier at IETF discussions related to vehicular communications >> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >> few), drafts were published [*]. At times people expressed interest >> to meet f2f. Now there is this email list. >> >> Participants are solicited to work on the topic of using IP in >> Intelligent Transportation Systems. The term ITS is a placeholder >> that, in my oppinion, is generic enough to cover many aspects of >> vehicular communications; vehicles may be wheeled, watered, flown. >> Ambulance, fire engine, coastal ship are particular examples. >> >> Scenario : A router deployed in a moving vehicle, uses its egress >> interface to connect to larger-area access network(s) or to other >> vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >> >> Example potential work items: - Reqs for IPv6 in vehicular networks >> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and >> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p >> (IPv6-over-foo). - open. >> >> I am told about other vehicular drafts and discussions, that I have >> not cited, existed and still exist (about e.g. ecall). I am >> interested to learn about all the vehicular activities at IETF. >> >> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >> >> Open to discussion: what are the scenarios? What are the potential >> work items? What might be needed, if anything at all? >> >> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >> draft-jhlee-mext-mnpp-00.txt, October 2009. >> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. >> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 >> draft-rosen-ecrit-ecall-04.txt, March 2010. >> draft-singh-simple-vehicle-info, July 2007. >> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >> draft-bauer-mext-aero-solspace, Sep. 2009. >> draft-bauer-mext-aero-topology, Sep. 2009. >> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >> draft-rosen-ecrit-ecall-05.txt, March 2012. >> >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 ------ Best Regards, Dapeng Liu From alexandru.petrescu@gmail.com Wed Jul 25 07:18: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 49DE221F85EF; Wed, 25 Jul 2012 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.264 X-Spam-Level: X-Spam-Status: No, score=-9.264 tagged_above=-999 required=5 tests=[AWL=0.985, 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 Ef24+iTC0CZU; Wed, 25 Jul 2012 07:18:15 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9634421F85D1; Wed, 25 Jul 2012 07:18:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6PEICwV032047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2012 16:18:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6PEIB0O032017; Wed, 25 Jul 2012 16:18:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6PEI7X7004872; Wed, 25 Jul 2012 16:18:11 +0200 Message-ID: <50100020.4040708@gmail.com> Date: Wed, 25 Jul 2012 16:18:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: liu dapeng References: <4FF2A65E.2080000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 14:18:16 -0000 Dear Dapeng, Thank you for the interest in the v2v scenario. Please see below for answers to the questions. Le 25/07/2012 05:26, liu dapeng a écrit : > Hi Alex, > > Regarding v2v communication: > > 1. If the mobile routers have LTE link and use IPv6, then v2v > communication can also rely on LTE? LTE use on a vehicle for V2V communication may be an option. We locally think currently more about the use of shorter-range links (WiFi, other) for direct communications between vehicles, without the use of LTE infrastructure. On another hand, the use of a fixed LTE base station or eNodeB to achieve communication between Mobile Routers may be feasible. Just one LTE base station, or femto cell, may be sufficient to largely improve the V2V communications based on short-range links. Even more, it may be possible to use a LTE base-station on board of vehicle, and maybe LTE Relay, on X2 interface. In this way, direct V2V communication without fixed infrastructure, and still LTE - long range, high bandwidth, may be possible. What do you think? > The precondition is that one vehicle knows the other vehicle's > identity (for example, every mobile router have a domain name and can > be updated dynamically). Right, if a MR owns a fully qualified domain name, then it may try to obtain an IP address dynamically from the LTE infrastructure, and then update its ressource record in the DNS. In this way, another MR may contact the first by identifying it with the FQDN. But here, there may be some problems about the LFNs (Local Fixed Nodes). It's the LFNs which woult typically communicate application data, not the MRs. Then I wonder how would it be possible to have a FQDN for all the LFNs, and an entry in DNS about such FQDN and the IP prefix. And how would the prefix be allocated too. What do you think? > 2. Even in the above v2v case, Mobile IP could also be useful? Since > mobile IP can provide a stable IP address, the mobile routers do not > need to update the domain name dynamically, it can use the home > address when registering in the domain system. Mobile IP could be useful, yes. And if it is used then reachability at a permanent address and session continuity are ensured, without needing to update the DNS. But in order for Mobile IP to work there would be a need for a Home Agent in the fixed infrastructure. For direct V2V communications one MR may "nest" under another MR. For their communication to work, there would be a need that one of those two MRs to be connected to the infrastructure to the HA. Also, it may be possible that even though the HA is not reachable, one MR sends a BU to another MR informing it about its prefix. This is doable. Until now we have much considered the use of RA (Router Advertisement) messages to achieve this, instead of BU. But each has its advantages. What do you think? Alex > > Any comments? > > Thanks, Best regards, Dapeng > > 2012/7/3, Alexandru Petrescu : >> Hi Abdussalam and thanks for the reply. >> >> Le 01/07/2012 19:31, Abdussalam Baryun a écrit : >>> Hi Alex and All, >>> >>>> Scenario : A router deployed in a moving vehicle, uses its >>>> egress interface to connect to larger-area access network(s) or >>>> to other vehicles. >>> >>> Should it use IPv6-over-LTE? >> >> In our context we consider indeed IPv6 over LTE, for several >> reasons. The 3GPP specs about LTE seem to be very specific and >> detailed about the use of IPv6. (In the past, before LTE, the >> earlier 3GPP specs were mentioning IPv6 but more like an option >> feature.) >> >> However, the 3GPP specs about the use of IPv6 have some lack of >> specification in the case that the UE (User Terminal) is actually >> a Mobile Router. The Prefix Delegation part may be >> underspecified. >> >>> Should it use Mobile IP? >> >> Hmm... that is a good question and much can be said about it. I >> am interested to liste others' oppinions as well. >> >> I think Mobile IP may be necessary but not sufficient. In the case >> of direct vehicle-to-vehicle IP communications (non covered areas) >> Mobile IP may not be necessary. It may be that extensions to >> Neighbor Discovery and DHCP could help establish paths within local >> topologies. >> >> And, when that is done (e.g. exchange routes between two vehicles >> using RA) it may become apparent that interactions between Mobile >> IP and this mechanism may be necessary. >> >>>> Open to discussion: what are the scenarios? >> >> We are interested in describing the scenarios. There may exist >> several possibilities. I think of the following lego-like >> approach: >> >> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >> Delegation. - scenario MR-to-MR - conceive prefixes in Router >> Advertisements, compare to other dynamic routing approaches. - >> scenario MR-to-MR-to-Infrastructure - combine the above two. >> >> Another direction is classify the kinds of vehicles. I think of >> something like this: >> >> - Internet Vehicle (has a plethora of interfaces, long- and short- >> range). - Range Extending Vehicle - extends the range of >> reachability. - Leaf Vehicle - like and end-node. >> >> Then there are other scenario statements that could open the path >> to the following: - addressability within vehicle, ULA, VIN. - >> problem of bandwidth difference between inside and outside the >> vehicle. >> >>> What are the potential work items? What might be >>> needed, if anything at all? >>> >>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and >>> ITS issues and in your questions directions. I will join the >>> ITS-WG which I think can have relation to MANET [RFC2501]. >> >> Well, hmm. I am happy to hear that but let us go easy about this. >> >> "ITS" at IETF is currently just an informal effort. Its future may >> be ambitious but right now it's not a WG. To do that, we'd need to >> make a BoF first (Birds-of-a-Feather) and ask others' oppinion >> about way forward. >> >> Secod, RFC2501 and ad-hoc routing are just one possibility to >> continue working on this. Some people may express positive >> technical feedback about MANET and others less so. >> >>> IMO that vehicle routers communications depend on both their >>> communication protocols and the used-network for such >>> communication (my answer of both Q1 and Q2). In particular, to >>> answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is >>> needed for the router's if the communication is through the >>> Internet's domain(s), but if it is through Ad-hoc networks' >>> domain(s) it MAY not be used. >> >> I tend to agree that Mobile IP may not be needed between vehicles >> which communicate directly without infrastructure. Then one >> wonders _what_ is needed? >> >>> The Internet is an infrastructure network and Ad-hoc networks >>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree >>> with the WG answers, and will read more into the WG inputs >>> regarding these issues. >> >> (see above note about this "WG" acronym which ITS is not >> currently) >> >>> I will schedule to participate/prepare I-D in the future for ITS >>> scenarios. I am preparing an I-D on DSRv2 routing which is a >>> MANET routing protocol that fits the use-case of ITS and VANET as >>> well. >> >> I am interested to work on scenario/reqs drafts for ITS. >> >> About "DSRv2" - is it still about Routing Headers? >> >> I am interested to hear others' oppinions as well. >> >> Yours, >> >> Alex >> >>> >>> Regards >>> >>> Abdussalam Baryun University of Glamorgan, UK >>> ======================================================= >>> >>> From: Alexandru Petrescu To: >>> its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>> Scenarios, potential topics... >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> >> >>> >>> >>> Welcome to the ITS list at IETF, an informal discussion. >>> >>> Earlier at IETF discussions related to vehicular communications >>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>> few), drafts were published [*]. At times people expressed >>> interest to meet f2f. Now there is this email list. >>> >>> Participants are solicited to work on the topic of using IP in >>> Intelligent Transportation Systems. The term ITS is a >>> placeholder that, in my oppinion, is generic enough to cover many >>> aspects of vehicular communications; vehicles may be wheeled, >>> watered, flown. Ambulance, fire engine, coastal ship are >>> particular examples. >>> >>> Scenario : A router deployed in a moving vehicle, uses its >>> egress interface to connect to larger-area access network(s) or >>> to other vehicles. Should it use IPv6-over-LTE? Should it use >>> Mobile IP? >>> >>> Example potential work items: - Reqs for IPv6 in vehicular >>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - >>> ULA and IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 >>> over 802.11p (IPv6-over-foo). - open. >>> >>> I am told about other vehicular drafts and discussions, that I >>> have not cited, existed and still exist (about e.g. ecall). I >>> am interested to learn about all the vehicular activities at >>> IETF. >>> >>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>> >>> Open to discussion: what are the scenarios? What are the >>> potential work items? What might be needed, if anything at all? >>> >>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. >>> 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>> draft-singh-simple-vehicle-info, July 2007. >>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>> draft-bauer-mext-aero-solspace, Sep. 2009. >>> draft-bauer-mext-aero-topology, Sep. 2009. >>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>> >>> >> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >> > > From adrian@olddog.co.uk Wed Jul 25 11:46: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 AB0A421F8746 for ; Wed, 25 Jul 2012 11:46:00 -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 OZs66Gcgh-Lh for ; Wed, 25 Jul 2012 11:46:00 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id DA09821F8735 for ; Wed, 25 Jul 2012 11:45:59 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6PIjwbA012580; Wed, 25 Jul 2012 19:45:58 +0100 Received: from 950129200 ([128.107.30.81]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6PIjtEX012560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2012 19:45:57 +0100 From: "Adrian Farrel" To: Date: Wed, 25 Jul 2012 19:45:55 +0100 Message-ID: <078d01cd6a95$badeb000$309c1000$@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: Ac1qlaMCqvMY+Ch2RuSx8NamzwBR2Q== Content-Language: en-gb Cc: draft-ietf-manet-olsrv2@tools.ietf.org Subject: [manet] AD review of draft-ietf-manet-olsrv2 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: Wed, 25 Jul 2012 18:46:00 -0000 Hi, Don't be alarmed! I have done an AD review of this document. The principal purpose of my review is to catch issues that I find in the document and to ensure that the work will get a smoother and more rapid progression through IETF last call and IESG review. My congratulations to the working group, and especially the editors, for an extremely clear and readable document. I have only minor comments that I suggest you handle along with any comments you receive during IETF last call (which I will start shortly). Thanks, Adrian === Section 1 After the discussion on the list about the impact on the status of RFC 3626, I suggest adding the following sentence to the end of the first paragraph in Section 1 This document does not obsolete [RFC3626] which is left in place for further experimentation. --- Section 2 Anycast addresses MAY be considered as routable addresses. This is fine, but it would be helpful to explain why this is "MAY" not may. The upper case gives a feeling that anycast addresses can be present and normally not considered as routable, but sometimes (for some unspecified reason) and implementation/deployment will consider them as routable. --- I like the appendixes and the fact that you have taken the time to create examples. But appendix D contains 2119 language and this jars a bit. Is appendix D part of the normative text but moved to an appendix because it is a meaty piece of text that would get in the way of the flow of the main text (i.e. section 22 bullet 1)? If so, the appendix should start with a statement that this appendix forms a normative part of the specification, and a back pointer to section 22. To a lesser extent, appendix E bothered me and I wondered whether you would consider moving it to be a main section of the document. From iesg-secretary@ietf.org Wed Jul 25 12:23: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 9095321F86FA; Wed, 25 Jul 2012 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 qJlvY27RGxjg; Wed, 25 Jul 2012 12:23:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F51221F86E3; Wed, 25 Jul 2012 12:23:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120725192307.868.16290.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2012 12:23:07 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (The Optimized Link State Routing Protocol version 2) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:23:07 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'The Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This last call periodhas been extended to handle the fact that it spans the IETF-84 meeting. Abstract This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/ No IPR declarations have been submitted directly on this I-D. From maxpassion@gmail.com Thu Jul 26 00:25: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 9F30221F84CE; Thu, 26 Jul 2012 00:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 wVE6NJ3+dqfq; Thu, 26 Jul 2012 00:25:14 -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 4182621F84C5; Thu, 26 Jul 2012 00:25:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2594680obb.31 for ; Thu, 26 Jul 2012 00:25:13 -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=4d75gvEQyiFGBwyHoGLl9Ufc04cLERaigC9GLdcLAK0=; b=skufv8KREOfrrQZ5wcnBOXOvGQGdMvXXfn8zQ7cNtLeZWEB7YZizle164kU4WZH9oA TDL7L17LX4URnTwWX5oBuMhCN5U+mBkzgfrXXJ5JLfn4yN8Pj0Sk9mVN12zy8R7atuU+ Bal5c0mw9vLO0vHnJ0+kQLzNCuec/KciL+4HmIVGRinXlymWeUzF4y2aKMRUBxv70BLI IQAJWUFqOSrd33u08zUBIu2gE4cmVKRt1ZCoV4dFIpWIQXTvvsR8AjxBkiqZvShGFr+C Lzql5L8K48CIbzw03BRwlW2fr8SbOI83+G+Mjykmflmkry1geu7qP8/1k52frhXxZnaw d/MA== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr39529336oeg.37.1343287513597; Thu, 26 Jul 2012 00:25:13 -0700 (PDT) Received: by 10.76.139.136 with HTTP; Thu, 26 Jul 2012 00:25:13 -0700 (PDT) In-Reply-To: <50100020.4040708@gmail.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> Date: Thu, 26 Jul 2012 15:25:13 +0800 Message-ID: From: liu dapeng To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 07:25:15 -0000 Hi Alex, Please see my reply inline. 2012/7/25, Alexandru Petrescu : > Dear Dapeng, > > Thank you for the interest in the v2v scenario. Please see below for > answers to the questions. > > Le 25/07/2012 05:26, liu dapeng a =E9crit : >> Hi Alex, >> >> Regarding v2v communication: >> >> 1. If the mobile routers have LTE link and use IPv6, then v2v >> communication can also rely on LTE? > > LTE use on a vehicle for V2V communication may be an option. We locally > think currently more about the use of shorter-range links (WiFi, other) > for direct communications between vehicles, without the use of LTE > infrastructure. [Dapeng] May I ask what is the use case scenario of this V2V communication? Whether the transmission range of Wi-Fi is enough for this use case? > On another hand, the use of a fixed LTE base station or eNodeB to > achieve communication between Mobile Routers may be feasible. Just one > LTE base station, or femto cell, may be sufficient to largely improve > the V2V communications based on short-range links. > > Even more, it may be possible to use a LTE base-station on board of > vehicle, and maybe LTE Relay, on X2 interface. In this way, direct V2V > communication without fixed infrastructure, and still LTE - long range, > high bandwidth, may be possible. > > What do you think? [Dapeng] LTE D2D maybe relevant to this topic? >> The precondition is that one vehicle knows the other vehicle's >> identity (for example, every mobile router have a domain name and can >> be updated dynamically). > > Right, if a MR owns a fully qualified domain name, then it may try to > obtain an IP address dynamically from the LTE infrastructure, and then > update its ressource record in the DNS. In this way, another MR may > contact the first by identifying it with the FQDN. > > But here, there may be some problems about the LFNs (Local Fixed Nodes). > It's the LFNs which woult typically communicate application data, not > the MRs. Then I wonder how would it be possible to have a FQDN for all > the LFNs, and an entry in DNS about such FQDN and the IP prefix. And > how would the prefix be allocated too. [Dapeng] How about using NEMO in the MR? If that is the case, the LFNs will be the mobile node and only the LFN that need to communicate with another vehicle need to have a FQDN. The user can get the FQDN by registering the service to the the ITS operator. > What do you think? > >> 2. Even in the above v2v case, Mobile IP could also be useful? Since >> mobile IP can provide a stable IP address, the mobile routers do not >> need to update the domain name dynamically, it can use the home >> address when registering in the domain system. > > Mobile IP could be useful, yes. And if it is used then reachability at > a permanent address and session continuity are ensured, without needing > to update the DNS. But in order for Mobile IP to work there would be a > need for a Home Agent in the fixed infrastructure. > > For direct V2V communications one MR may "nest" under another MR. For > their communication to work, there would be a need that one of those two > MRs to be connected to the infrastructure to the HA. > > Also, it may be possible that even though the HA is not reachable, one > MR sends a BU to another MR informing it about its prefix. This is > doable. Until now we have much considered the use of RA (Router > Advertisement) messages to achieve this, instead of BU. But each has > its advantages. [Dapeng] If use RA, that will limit the V2V communication to only adjacent vehicle? Thanks, Best Regards, Dapeng > What do you think? > > Alex > >> >> Any comments? >> >> Thanks, Best regards, Dapeng >> >> 2012/7/3, Alexandru Petrescu : >>> Hi Abdussalam and thanks for the reply. >>> >>> Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >>>> Hi Alex and All, >>>> >>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>> egress interface to connect to larger-area access network(s) or >>>>> to other vehicles. >>>> >>>> Should it use IPv6-over-LTE? >>> >>> In our context we consider indeed IPv6 over LTE, for several >>> reasons. The 3GPP specs about LTE seem to be very specific and >>> detailed about the use of IPv6. (In the past, before LTE, the >>> earlier 3GPP specs were mentioning IPv6 but more like an option >>> feature.) >>> >>> However, the 3GPP specs about the use of IPv6 have some lack of >>> specification in the case that the UE (User Terminal) is actually >>> a Mobile Router. The Prefix Delegation part may be >>> underspecified. >>> >>>> Should it use Mobile IP? >>> >>> Hmm... that is a good question and much can be said about it. I >>> am interested to liste others' oppinions as well. >>> >>> I think Mobile IP may be necessary but not sufficient. In the case >>> of direct vehicle-to-vehicle IP communications (non covered areas) >>> Mobile IP may not be necessary. It may be that extensions to >>> Neighbor Discovery and DHCP could help establish paths within local >>> topologies. >>> >>> And, when that is done (e.g. exchange routes between two vehicles >>> using RA) it may become apparent that interactions between Mobile >>> IP and this mechanism may be necessary. >>> >>>>> Open to discussion: what are the scenarios? >>> >>> We are interested in describing the scenarios. There may exist >>> several possibilities. I think of the following lego-like >>> approach: >>> >>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >>> Delegation. - scenario MR-to-MR - conceive prefixes in Router >>> Advertisements, compare to other dynamic routing approaches. - >>> scenario MR-to-MR-to-Infrastructure - combine the above two. >>> >>> Another direction is classify the kinds of vehicles. I think of >>> something like this: >>> >>> - Internet Vehicle (has a plethora of interfaces, long- and short- >>> range). - Range Extending Vehicle - extends the range of >>> reachability. - Leaf Vehicle - like and end-node. >>> >>> Then there are other scenario statements that could open the path >>> to the following: - addressability within vehicle, ULA, VIN. - >>> problem of bandwidth difference between inside and outside the >>> vehicle. >>> >>>> What are the potential work items? What might be >>>> needed, if anything at all? >>>> >>>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and >>>> ITS issues and in your questions directions. I will join the >>>> ITS-WG which I think can have relation to MANET [RFC2501]. >>> >>> Well, hmm. I am happy to hear that but let us go easy about this. >>> >>> "ITS" at IETF is currently just an informal effort. Its future may >>> be ambitious but right now it's not a WG. To do that, we'd need to >>> make a BoF first (Birds-of-a-Feather) and ask others' oppinion >>> about way forward. >>> >>> Secod, RFC2501 and ad-hoc routing are just one possibility to >>> continue working on this. Some people may express positive >>> technical feedback about MANET and others less so. >>> >>>> IMO that vehicle routers communications depend on both their >>>> communication protocols and the used-network for such >>>> communication (my answer of both Q1 and Q2). In particular, to >>>> answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is >>>> needed for the router's if the communication is through the >>>> Internet's domain(s), but if it is through Ad-hoc networks' >>>> domain(s) it MAY not be used. >>> >>> I tend to agree that Mobile IP may not be needed between vehicles >>> which communicate directly without infrastructure. Then one >>> wonders _what_ is needed? >>> >>>> The Internet is an infrastructure network and Ad-hoc networks >>>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree >>>> with the WG answers, and will read more into the WG inputs >>>> regarding these issues. >>> >>> (see above note about this "WG" acronym which ITS is not >>> currently) >>> >>>> I will schedule to participate/prepare I-D in the future for ITS >>>> scenarios. I am preparing an I-D on DSRv2 routing which is a >>>> MANET routing protocol that fits the use-case of ITS and VANET as >>>> well. >>> >>> I am interested to work on scenario/reqs drafts for ITS. >>> >>> About "DSRv2" - is it still about Routing Headers? >>> >>> I am interested to hear others' oppinions as well. >>> >>> Yours, >>> >>> Alex >>> >>>> >>>> Regards >>>> >>>> Abdussalam Baryun University of Glamorgan, UK >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>> >>>> From: Alexandru Petrescu To: >>>> its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>>> Scenarios, potential topics... >>>> ----------------------------------------------------------------------= ---------- >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> > Welcome to the ITS list at IETF, an informal discussion. >>>> >>>> Earlier at IETF discussions related to vehicular communications >>>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>>> few), drafts were published [*]. At times people expressed >>>> interest to meet f2f. Now there is this email list. >>>> >>>> Participants are solicited to work on the topic of using IP in >>>> Intelligent Transportation Systems. The term ITS is a >>>> placeholder that, in my oppinion, is generic enough to cover many >>>> aspects of vehicular communications; vehicles may be wheeled, >>>> watered, flown. Ambulance, fire engine, coastal ship are >>>> particular examples. >>>> >>>> Scenario : A router deployed in a moving vehicle, uses its >>>> egress interface to connect to larger-area access network(s) or >>>> to other vehicles. Should it use IPv6-over-LTE? Should it use >>>> Mobile IP? >>>> >>>> Example potential work items: - Reqs for IPv6 in vehicular >>>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - >>>> ULA and IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 >>>> over 802.11p (IPv6-over-foo). - open. >>>> >>>> I am told about other vehicular drafts and discussions, that I >>>> have not cited, existed and still exist (about e.g. ecall). I >>>> am interested to learn about all the vehicular activities at >>>> IETF. >>>> >>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>> >>>> Open to discussion: what are the scenarios? What are the >>>> potential work items? What might be needed, if anything at all? >>>> >>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. >>>> 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>>> draft-singh-simple-vehicle-info, July 2007. >>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>>> draft-bauer-mext-aero-solspace, Sep. 2009. >>>> draft-bauer-mext-aero-topology, Sep. 2009. >>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>> >>>> >>> >>> >>> >>> _______________________________________________ manet mailing list >>> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >>> >> >> > > > --=20 ------ Best Regards, Dapeng Liu From alexandru.petrescu@gmail.com Thu Jul 26 09:37: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 A875021F85DF; Thu, 26 Jul 2012 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.323 X-Spam-Level: X-Spam-Status: No, score=-9.323 tagged_above=-999 required=5 tests=[AWL=0.926, 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 Rsi8T0hK+6YS; Thu, 26 Jul 2012 09:37:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1621F85D8; Thu, 26 Jul 2012 09:37:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6QGbOla016040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 18:37:24 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QGbOlT020060; Thu, 26 Jul 2012 18:37:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QGbK8G000336; Thu, 26 Jul 2012 18:37:24 +0200 Message-ID: <50117240.10902@gmail.com> Date: Thu, 26 Jul 2012 18:37:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: liu dapeng References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 16:37:31 -0000 Hi Dapeng, Le 26/07/2012 09:25, liu dapeng a écrit : > Hi Alex, Please see my reply inline. > > 2012/7/25, Alexandru Petrescu : >> Dear Dapeng, >> >> Thank you for the interest in the v2v scenario. Please see below >> for answers to the questions. >> >> Le 25/07/2012 05:26, liu dapeng a écrit : >>> Hi Alex, >>> >>> Regarding v2v communication: >>> >>> 1. If the mobile routers have LTE link and use IPv6, then v2v >>> communication can also rely on LTE? >> >> LTE use on a vehicle for V2V communication may be an option. We >> locally think currently more about the use of shorter-range links >> (WiFi, other) for direct communications between vehicles, without >> the use of LTE infrastructure. > > [Dapeng] May I ask what is the use case scenario of this V2V > communication? Well you may and there are many scenarios that we considered in the past, as part of work with various partners specialized in particular scenarios. V2V concepts for public transportation scenarios are described in section 3.3 of draft-petrescu-its-scenarios-reqs-01. A fixed incident scene scenario for V2V is described in section 3 of draft-petrescu-autoconf-ra-based-routing-02. Peer-to-peer applications described in section 4.2 of draft-ietf-mext-nemo-ro-automotive-req-02. An advertising vehicle scenario is one where a 'billboard' vehicle runs along the highway and distributes not only visual ads but also wireless Internet. This is to be used in many kinds of convoys like... Generic use of V2V is described in section 3.3 of draft-petrescu-its-scenarios-reqs-01.txt. CALM describes some V2V scenarios as well. Is there some particular scenario that deserves more interest from your side? > Whether the transmission range of Wi-Fi is enough for this use case? Indeed in some use cases the WiFi transmission range (unlicensed spectrum, around 50meter range at a certain power level) may be enough. For example, at an incident scene this is largely enough. On another hand, vehicles in a convoy, or wifi billboard vehicle, may need more than 50m, otherwise one is tempted to approach more for better reception. In these cases maybe LTE may be necessary, or other forms of longer-range wireless links, maybe with forms of 802.11p. >> On another hand, the use of a fixed LTE base station or eNodeB to >> achieve communication between Mobile Routers may be feasible. >> Just one LTE base station, or femto cell, may be sufficient to >> largely improve the V2V communications based on short-range links. >> >> Even more, it may be possible to use a LTE base-station on board of >> vehicle, and maybe LTE Relay, on X2 interface. In this way, direct >> V2V communication without fixed infrastructure, and still LTE - >> long range, high bandwidth, may be possible. >> >> What do you think? > > [Dapeng] LTE D2D maybe relevant to this topic? LTE D2D would stand for "Device-to-Device"? I am not aware of this term, please explain. (I am aware of an effort at ETSI called "GW-to-GW" communications which may approach much to these V2V terms). >>> The precondition is that one vehicle knows the other vehicle's >>> identity (for example, every mobile router have a domain name >>> and can be updated dynamically). >> >> Right, if a MR owns a fully qualified domain name, then it may try >> to obtain an IP address dynamically from the LTE infrastructure, >> and then update its ressource record in the DNS. In this way, >> another MR may contact the first by identifying it with the FQDN. >> >> But here, there may be some problems about the LFNs (Local Fixed >> Nodes). It's the LFNs which woult typically communicate >> application data, not the MRs. Then I wonder how would it be >> possible to have a FQDN for all the LFNs, and an entry in DNS about >> such FQDN and the IP prefix. And how would the prefix be allocated >> too. > > [Dapeng] How about using NEMO in the MR? If that is the case, the > LFNs will be the mobile node and only the LFN that need to > communicate with another vehicle need to have a FQDN. The user can > get the FQDN by registering the service to the the ITS operator. Sounds reasonable. However, running NEMO Mobile IP on MR would mean that LFN is not running anything mobility-related and that MR does all mobility management on its behalf. In this sense, such a scenario would mean that MR updates the DNS with an entire set of addresses (a prefix). For example, instead of updating it with mr.example.com - 1::1, it would update it with example.com - 1::/64, if that is at all possible. In this way, whenever some LFN asks to talk to LFN.example.com then the IP address would be within that prefix. I am not sure I am not saying stupid DNS things, I stand correced. I need to better understand a DNS part of the picture in this ITS effort, please, and others help clarify it. Yours, Alex > >> What do you think? >> >>> 2. Even in the above v2v case, Mobile IP could also be useful? >>> Since mobile IP can provide a stable IP address, the mobile >>> routers do not need to update the domain name dynamically, it >>> can use the home address when registering in the domain system. >> >> Mobile IP could be useful, yes. And if it is used then >> reachability at a permanent address and session continuity are >> ensured, without needing to update the DNS. But in order for >> Mobile IP to work there would be a need for a Home Agent in the >> fixed infrastructure. >> >> For direct V2V communications one MR may "nest" under another MR. >> For their communication to work, there would be a need that one of >> those two MRs to be connected to the infrastructure to the HA. >> >> Also, it may be possible that even though the HA is not reachable, >> one MR sends a BU to another MR informing it about its prefix. This >> is doable. Until now we have much considered the use of RA (Router >> Advertisement) messages to achieve this, instead of BU. But each >> has its advantages. > > [Dapeng] If use RA, that will limit the V2V communication to only > adjacent vehicle? > > Thanks, Best Regards, Dapeng > >> What do you think? >> >> Alex >> >>> >>> Any comments? >>> >>> Thanks, Best regards, Dapeng >>> >>> 2012/7/3, Alexandru Petrescu : >>>> Hi Abdussalam and thanks for the reply. >>>> >>>> Le 01/07/2012 19:31, Abdussalam Baryun a écrit : >>>>> Hi Alex and All, >>>>> >>>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>>> egress interface to connect to larger-area access >>>>>> network(s) or to other vehicles. >>>>> >>>>> Should it use IPv6-over-LTE? >>>> >>>> In our context we consider indeed IPv6 over LTE, for several >>>> reasons. The 3GPP specs about LTE seem to be very specific and >>>> detailed about the use of IPv6. (In the past, before LTE, the >>>> earlier 3GPP specs were mentioning IPv6 but more like an >>>> option feature.) >>>> >>>> However, the 3GPP specs about the use of IPv6 have some lack of >>>> specification in the case that the UE (User Terminal) is >>>> actually a Mobile Router. The Prefix Delegation part may be >>>> underspecified. >>>> >>>>> Should it use Mobile IP? >>>> >>>> Hmm... that is a good question and much can be said about it. I >>>> am interested to liste others' oppinions as well. >>>> >>>> I think Mobile IP may be necessary but not sufficient. In the >>>> case of direct vehicle-to-vehicle IP communications (non >>>> covered areas) Mobile IP may not be necessary. It may be that >>>> extensions to Neighbor Discovery and DHCP could help establish >>>> paths within local topologies. >>>> >>>> And, when that is done (e.g. exchange routes between two >>>> vehicles using RA) it may become apparent that interactions >>>> between Mobile IP and this mechanism may be necessary. >>>> >>>>>> Open to discussion: what are the scenarios? >>>> >>>> We are interested in describing the scenarios. There may exist >>>> several possibilities. I think of the following lego-like >>>> approach: >>>> >>>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >>>> Delegation. - scenario MR-to-MR - conceive prefixes in Router >>>> Advertisements, compare to other dynamic routing approaches. - >>>> scenario MR-to-MR-to-Infrastructure - combine the above two. >>>> >>>> Another direction is classify the kinds of vehicles. I think >>>> of something like this: >>>> >>>> - Internet Vehicle (has a plethora of interfaces, long- and >>>> short- range). - Range Extending Vehicle - extends the range of >>>> reachability. - Leaf Vehicle - like and end-node. >>>> >>>> Then there are other scenario statements that could open the >>>> path to the following: - addressability within vehicle, ULA, >>>> VIN. - problem of bandwidth difference between inside and >>>> outside the vehicle. >>>> >>>>> What are the potential work items? What might be >>>>> needed, if anything at all? >>>>> >>>>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) >>>>> and ITS issues and in your questions directions. I will join >>>>> the ITS-WG which I think can have relation to MANET >>>>> [RFC2501]. >>>> >>>> Well, hmm. I am happy to hear that but let us go easy about >>>> this. >>>> >>>> "ITS" at IETF is currently just an informal effort. Its >>>> future may be ambitious but right now it's not a WG. To do >>>> that, we'd need to make a BoF first (Birds-of-a-Feather) and >>>> ask others' oppinion about way forward. >>>> >>>> Secod, RFC2501 and ad-hoc routing are just one possibility to >>>> continue working on this. Some people may express positive >>>> technical feedback about MANET and others less so. >>>> >>>>> IMO that vehicle routers communications depend on both their >>>>> communication protocols and the used-network for such >>>>> communication (my answer of both Q1 and Q2). In particular, >>>>> to answer Q2, IMHO there is no doubt that Mobile IP >>>>> [RFC6275] is needed for the router's if the communication is >>>>> through the Internet's domain(s), but if it is through >>>>> Ad-hoc networks' domain(s) it MAY not be used. >>>> >>>> I tend to agree that Mobile IP may not be needed between >>>> vehicles which communicate directly without infrastructure. >>>> Then one wonders _what_ is needed? >>>> >>>>> The Internet is an infrastructure network and Ad-hoc networks >>>>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I >>>>> agree with the WG answers, and will read more into the WG >>>>> inputs regarding these issues. >>>> >>>> (see above note about this "WG" acronym which ITS is not >>>> currently) >>>> >>>>> I will schedule to participate/prepare I-D in the future for >>>>> ITS scenarios. I am preparing an I-D on DSRv2 routing which >>>>> is a MANET routing protocol that fits the use-case of ITS >>>>> and VANET as well. >>>> >>>> I am interested to work on scenario/reqs drafts for ITS. >>>> >>>> About "DSRv2" - is it still about Routing Headers? >>>> >>>> I am interested to hear others' oppinions as well. >>>> >>>> Yours, >>>> >>>> Alex >>>> >>>>> >>>>> Regards >>>>> >>>>> Abdussalam Baryun University of Glamorgan, UK >>>>> ======================================================= >>>>> >>>>> From: Alexandru Petrescu >>>>> To: its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 >>>>> Sub: [its] Scenarios, potential topics... >>>>> -------------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> Welcome to the ITS list at IETF, an informal discussion. >>>>> >>>>> Earlier at IETF discussions related to vehicular >>>>> communications happened in several groups (MEXT, AUTOCONF, >>>>> 6MAN, to name but a few), drafts were published [*]. At >>>>> times people expressed interest to meet f2f. Now there is >>>>> this email list. >>>>> >>>>> Participants are solicited to work on the topic of using IP >>>>> in Intelligent Transportation Systems. The term ITS is a >>>>> placeholder that, in my oppinion, is generic enough to cover >>>>> many aspects of vehicular communications; vehicles may be >>>>> wheeled, watered, flown. Ambulance, fire engine, coastal >>>>> ship are particular examples. >>>>> >>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>> egress interface to connect to larger-area access network(s) >>>>> or to other vehicles. Should it use IPv6-over-LTE? Should >>>>> it use Mobile IP? >>>>> >>>>> Example potential work items: - Reqs for IPv6 in vehicular >>>>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 >>>>> addressing - ULA and IPv6 for vehicles - IPv6 multicast - >>>>> ISO TC204 - IPv6 over 802.11p (IPv6-over-foo). - open. >>>>> >>>>> I am told about other vehicular drafts and discussions, that >>>>> I have not cited, existed and still exist (about e.g. >>>>> ecall). I am interested to learn about all the vehicular >>>>> activities at IETF. >>>>> >>>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>>> >>>>> Open to discussion: what are the scenarios? What are the >>>>> potential work items? What might be needed, if anything at >>>>> all? >>>>> >>>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>>>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. >>>>> 2010. draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, >>>>> Nov. 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>>>> draft-singh-simple-vehicle-info, July 2007. >>>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>>>> draft-bauer-mext-aero-solspace, Sep. 2009. >>>>> draft-bauer-mext-aero-topology, Sep. 2009. >>>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>>>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ manet mailing >>>> list manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >> >> >> > > From budden@nps.edu Thu Jul 26 10:12: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 7F0C221F866D for ; Thu, 26 Jul 2012 10:12:59 -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.000, 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 g-qjxQny5Vta for ; Thu, 26 Jul 2012 10:12:58 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D221F8669 for ; Thu, 26 Jul 2012 10:12:58 -0700 (PDT) X-ASG-Debug-ID: 1343322774-036c92049440a400001-Rp4q3q Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id 6amhIaGhgdyKCTfA; Thu, 26 Jul 2012 10:12:54 -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.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jul 2012 10:12:53 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] [its] Scenarios, potential topics... To: Alexandru Petrescu In-Reply-To: <50117240.10902@gmail.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Jul 2012 10:12:00 -0700 Message-ID: <1343322720.981.666.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: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1343322774 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.103822 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:12:59 -0000 On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: > > Is there some particular scenario that deserves more interest from > your > side? > > > Whether the transmission range of Wi-Fi is enough for this use case? > > Indeed in some use cases the WiFi transmission range (unlicensed > spectrum, around 50meter range at a certain power level) may be > enough. > For example, at an incident scene this is largely enough. Liu Dapeng, The classical use case, in my mind, is the instrumented ambulance*. The casualty inside may have several end systems (sensors) attached. Further, the ambulance will have end system nav receiver (to report position) and the EMT may need several services, VOIP being an obvious one. The topology for such is a LAN within the ambulance and a router with one or more outside interfaces. Reaching to a neighboring vehicle (e.g. with WiFi) is clearly not enough. The router needs to get to the rest of the internet in order to get the data to the hospital emergency room. So the first thought is an LTE or IEEE 802.16 network segment for the radio-WAN. There's nothing wrong with more than one hop, so including a WiFi interface on the router is OK too. (Indeed with the balkanization of the cellphone system, at least in US, multiple 4G cellphone interfaces is likely to be needed). From sratliff@cisco.com Thu Jul 26 11:22: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 DAEE721F861F; Thu, 26 Jul 2012 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 jtH-ZN6sQbwS; Thu, 26 Jul 2012 11:22:30 -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 2C25421F8623; Thu, 26 Jul 2012 11:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2135; q=dns/txt; s=iport; t=1343326950; x=1344536550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7dkrGO47WYkVkOBES2sCYFPba7QSO69U1FoyzmakyR0=; b=CE31W632IWE2tKRBAcLvRXIURHt315U9xsxDttTxoIGPu9EOg/ZjcV/+ PVOLNAvYzG7iXKqBMlFF0VecovtNiy3z6OAKIgva94KC5UcaPyhslDNvP n0pllzq0Ft15kiAYD4IyXW9zZ/WZZT27SrcYMFRb1Hy9oXY7PMuyjerDZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJKJEVCtJV2d/2dsb2JhbABFuTmBB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECcLJQIEDgUih2UGC5tzoEYEi08bhXlgA5VIjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,660,1336348800"; d="scan'208";a="102690250" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2012 18:22:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6QIMTo8024757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jul 2012 18:22:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 13:22:29 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsAA= Date: Thu, 26 Jul 2012 18:22:28 +0000 Message-ID: References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> In-Reply-To: <1343322720.981.666.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.005 x-tm-as-result: No--33.827800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <17B5F65E7430E74AA434261AC6C8121F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandru Petrescu , manet , "" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 18:22:31 -0000 Rex, On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: > On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>=20 >> Is there some particular scenario that deserves more interest from >> your >> side? >>=20 >>> Whether the transmission range of Wi-Fi is enough for this use case? >>=20 >> Indeed in some use cases the WiFi transmission range (unlicensed >> spectrum, around 50meter range at a certain power level) may be >> enough. >> For example, at an incident scene this is largely enough.=20 >=20 > Liu Dapeng, >=20 > The classical use case, in my mind, is the instrumented ambulance*. The > casualty inside may have several end systems (sensors) attached. > Further, the ambulance will have end system nav receiver (to report > position) and the EMT may need several services, VOIP being an obvious > one. >=20 > The topology for such is a LAN within the ambulance and a router with > one or more outside interfaces. Reaching to a neighboring vehicle (e.g. > with WiFi) is clearly not enough. The router needs to get to the rest > of the internet in order to get the data to the hospital emergency room. > So the first thought is an LTE or IEEE 802.16 network segment for the > radio-WAN. There's nothing wrong with more than one hop, so including a > WiFi interface on the router is OK too. (Indeed with the balkanization > of the cellphone system, at least in US, multiple 4G cellphone > interfaces is likely to be needed). >=20 FWIW, I think you've hit the nail on the head here. The WiFi connection to = a neighboring vehicle might help, in cases where (1) the ambulance attendan= ts want to do something like a VoIP call to the people in the neighboring v= ehicle, or (2) if said neighboring vehicle has Internet connectivity and ca= n "share" (e.g. 802.16, or LTE, or maybe even a satellite modem). But havin= g WiFi to a neighboring vehicle is, in and of itself, not necessarily a goo= d thing.=20 Regards, Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From alexandru.petrescu@gmail.com Fri Jul 27 05:38: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 B4C3921F84FE; Fri, 27 Jul 2012 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.458 X-Spam-Level: X-Spam-Status: No, score=-9.458 tagged_above=-999 required=5 tests=[AWL=0.791, 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 YHYa-WxKt2LC; Fri, 27 Jul 2012 05:38:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id CB5CD21F84E1; Fri, 27 Jul 2012 05:38:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6RCce5H015590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2012 14:38:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6RCcdcw025631; Fri, 27 Jul 2012 14:38:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6RCcaaU021812; Fri, 27 Jul 2012 14:38:39 +0200 Message-ID: <50128BCC.7070002@gmail.com> Date: Fri, 27 Jul 2012 14:38:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 12:38:45 -0000 Le 26/07/2012 20:22, Stan Ratliff (sratliff) a écrit : > Rex, > > On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: > >> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>> >>> Is there some particular scenario that deserves more interest >>> from your side? >>> >>>> Whether the transmission range of Wi-Fi is enough for this use >>>> case? >>> >>> Indeed in some use cases the WiFi transmission range (unlicensed >>> spectrum, around 50meter range at a certain power level) may be >>> enough. For example, at an incident scene this is largely >>> enough. >> >> Liu Dapeng, >> >> The classical use case, in my mind, is the instrumented >> ambulance*. The casualty inside may have several end systems >> (sensors) attached. Further, the ambulance will have end system nav >> receiver (to report position) and the EMT may need several >> services, VOIP being an obvious one. >> >> The topology for such is a LAN within the ambulance and a router >> with one or more outside interfaces. Reaching to a neighboring >> vehicle (e.g. with WiFi) is clearly not enough. The router needs >> to get to the rest of the internet in order to get the data to the >> hospital emergency room. So the first thought is an LTE or IEEE >> 802.16 network segment for the radio-WAN. There's nothing wrong >> with more than one hop, so including a WiFi interface on the >> router is OK too. (Indeed with the balkanization of the cellphone >> system, at least in US, multiple 4G cellphone interfaces is likely >> to be needed). >> > > FWIW, I think you've hit the nail on the head here. The WiFi > connection to a neighboring vehicle might help, in cases where (1) > the ambulance attendants want to do something like a VoIP call to > the people in the neighboring vehicle, or (2) if said neighboring > vehicle has Internet connectivity and can "share" (e.g. 802.16, or > LTE, or maybe even a satellite modem). But having WiFi to a > neighboring vehicle is, in and of itself, not necessarily a good > thing. WEll, I agree with the first points about potential necessity of WiFi between ambulance and a neighboring vehicle. One scenario that may be relevant is sharing information about the casualty between the two different agencies running each vehicle (say law enforcement and first aid); from an eHealth perspective this would mean to share data like chemical substance history to medicals trying to identify what happened, or between insurance company and the medical to have first hand proof about accident conditions and reimbursement. And more. I also agree about one vehicle offering Internet connection to nearby vehicle (a case named sometimes V2V2I). But I do not understand well why you're saying that having WiFi to a neighboring WiFi (not for Internet access, not for data sharing like ambulance-police) is not necessarily a good thing. What do you have in mind about it not being a good thing? Alex > > Regards, Stan > > > >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > > From sratliff@cisco.com Fri Jul 27 08:10: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 A575921F84F3; Fri, 27 Jul 2012 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Lm2071bUuKLv; Fri, 27 Jul 2012 08:10:20 -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 AA2CE21F84DC; Fri, 27 Jul 2012 08:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3984; q=dns/txt; s=iport; t=1343401820; x=1344611420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HX5RRTzuvaA5WxWV8A6mrBdvQ4NVgACaGBoYkbcqtmY=; b=AZCD0kPwhDc4RzxA13c2ZfHoXHSpdYm6Kpd5r5zt3oGArLCmLtSW5c3W PVzNBRyItnLpS7EXP850DOUpXSKJNbgVP/tzByIRK0WEpcpXe0IZvXYQF ObZlC05EFXyQn1sWu0mDwcaSr9eAbKYVlL5D5+6nEBqWVyfRB1su3nVsh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKuElCtJXG9/2dsb2JhbAA7Crk8gQeCIAEBAQMBAQEBDwFbCwULAgEIGC4nCyUCBA4FIodlBguaA6BYBItQEAuFeWADiBiNMI4ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106031203" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2012 15:10:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6RFAKs8005985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 15:10:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 10:10:19 -0500 From: "Stan Ratliff (sratliff)" To: Alexandru Petrescu Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsACAATJBAIAAKmAA Date: Fri, 27 Jul 2012 15:10:18 +0000 Message-ID: <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> In-Reply-To: <50128BCC.7070002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--35.642200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <903AD7FCED12BA44A9004EE3A2A13E51@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:10:21 -0000 On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: > Le 26/07/2012 20:22, Stan Ratliff (sratliff) a =E9crit : >> Rex, >>=20 >> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>=20 >>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>=20 >>>> Is there some particular scenario that deserves more interest >>>> from your side? >>>>=20 >>>>> Whether the transmission range of Wi-Fi is enough for this use >>>>> case? >>>>=20 >>>> Indeed in some use cases the WiFi transmission range (unlicensed >>>> spectrum, around 50meter range at a certain power level) may be >>>> enough. For example, at an incident scene this is largely >>>> enough. >>>=20 >>> Liu Dapeng, >>>=20 >>> The classical use case, in my mind, is the instrumented >>> ambulance*. The casualty inside may have several end systems >>> (sensors) attached. Further, the ambulance will have end system nav >>> receiver (to report position) and the EMT may need several >>> services, VOIP being an obvious one. >>>=20 >>> The topology for such is a LAN within the ambulance and a router >>> with one or more outside interfaces. Reaching to a neighboring >>> vehicle (e.g. with WiFi) is clearly not enough. The router needs >>> to get to the rest of the internet in order to get the data to the >>> hospital emergency room. So the first thought is an LTE or IEEE >>> 802.16 network segment for the radio-WAN. There's nothing wrong >>> with more than one hop, so including a WiFi interface on the >>> router is OK too. (Indeed with the balkanization of the cellphone >>> system, at least in US, multiple 4G cellphone interfaces is likely >>> to be needed). >>>=20 >>=20 >> FWIW, I think you've hit the nail on the head here. The WiFi >> connection to a neighboring vehicle might help, in cases where (1) >> the ambulance attendants want to do something like a VoIP call to >> the people in the neighboring vehicle, or (2) if said neighboring >> vehicle has Internet connectivity and can "share" (e.g. 802.16, or >> LTE, or maybe even a satellite modem). But having WiFi to a >> neighboring vehicle is, in and of itself, not necessarily a good >> thing. >=20 > WEll, I agree with the first points about potential necessity of WiFi > between ambulance and a neighboring vehicle. >=20 > One scenario that may be relevant is sharing information about the > casualty between the two different agencies running each vehicle (say > law enforcement and first aid); from an eHealth perspective this would > mean to share data like chemical substance history to medicals trying to > identify what happened, or between insurance company and the medical to > have first hand proof about accident conditions and reimbursement. And > more. >=20 > I also agree about one vehicle offering Internet connection to nearby > vehicle (a case named sometimes V2V2I). >=20 > But I do not understand well why you're saying that having WiFi to a > neighboring WiFi (not for Internet access, not for data sharing like > ambulance-police) is not necessarily a good thing. What do you have in > mind about it not being a good thing? Again, let's consider the ambulance case. I've got a small subnet of device= s in that ambulance, behind an on-board router. Let's also assume a scenari= o where *all* of my traffic needs are back to the hospital (via the Interne= t). From the ambulance, I have WiFi connectivity to, say, a neighboring pol= ice vehicle. But that police vehicle either doesn't have a router installed= , or it doesn't have Internet connectivity. All I'm saying is that in that = case, a WiFi connection from the ambulance to the police vehicle doesn't he= lp a whole lot. Regards, Stan >=20 > Alex >=20 >>=20 >> Regards, Stan >>=20 >>=20 >>=20 >>> _______________________________________________ manet mailing list >>> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >=20 >=20 From alexandru.petrescu@gmail.com Fri Jul 27 08:18: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 86FDD21F8770; Fri, 27 Jul 2012 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.478 X-Spam-Level: X-Spam-Status: No, score=-9.478 tagged_above=-999 required=5 tests=[AWL=0.771, 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 aZxSVmsPt15W; Fri, 27 Jul 2012 08:18:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 36C1321F8766; Fri, 27 Jul 2012 08:18:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6RFHwvU022270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2012 17:17:58 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6RFHw4A018836; Fri, 27 Jul 2012 17:17:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6RFHs0c030140; Fri, 27 Jul 2012 17:17:58 +0200 Message-ID: <5012B123.2040605@gmail.com> Date: Fri, 27 Jul 2012 17:17:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> In-Reply-To: <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:18:03 -0000 Le 27/07/2012 17:10, Stan Ratliff (sratliff) a écrit : > > On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: > >> Le 26/07/2012 20:22, Stan Ratliff (sratliff) a écrit : >>> Rex, >>> >>> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>> >>>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>> >>>>> Is there some particular scenario that deserves more interest >>>>> from your side? >>>>> >>>>>> Whether the transmission range of Wi-Fi is enough for this >>>>>> use case? >>>>> >>>>> Indeed in some use cases the WiFi transmission range >>>>> (unlicensed spectrum, around 50meter range at a certain >>>>> power level) may be enough. For example, at an incident scene >>>>> this is largely enough. >>>> >>>> Liu Dapeng, >>>> >>>> The classical use case, in my mind, is the instrumented >>>> ambulance*. The casualty inside may have several end systems >>>> (sensors) attached. Further, the ambulance will have end >>>> system nav receiver (to report position) and the EMT may need >>>> several services, VOIP being an obvious one. >>>> >>>> The topology for such is a LAN within the ambulance and a >>>> router with one or more outside interfaces. Reaching to a >>>> neighboring vehicle (e.g. with WiFi) is clearly not enough. The >>>> router needs to get to the rest of the internet in order to get >>>> the data to the hospital emergency room. So the first thought >>>> is an LTE or IEEE 802.16 network segment for the radio-WAN. >>>> There's nothing wrong with more than one hop, so including a >>>> WiFi interface on the router is OK too. (Indeed with the >>>> balkanization of the cellphone system, at least in US, multiple >>>> 4G cellphone interfaces is likely to be needed). >>>> >>> >>> FWIW, I think you've hit the nail on the head here. The WiFi >>> connection to a neighboring vehicle might help, in cases where >>> (1) the ambulance attendants want to do something like a VoIP >>> call to the people in the neighboring vehicle, or (2) if said >>> neighboring vehicle has Internet connectivity and can "share" >>> (e.g. 802.16, or LTE, or maybe even a satellite modem). But >>> having WiFi to a neighboring vehicle is, in and of itself, not >>> necessarily a good thing. >> >> WEll, I agree with the first points about potential necessity of >> WiFi between ambulance and a neighboring vehicle. >> >> One scenario that may be relevant is sharing information about the >> casualty between the two different agencies running each vehicle >> (say law enforcement and first aid); from an eHealth perspective >> this would mean to share data like chemical substance history to >> medicals trying to identify what happened, or between insurance >> company and the medical to have first hand proof about accident >> conditions and reimbursement. And more. >> >> I also agree about one vehicle offering Internet connection to >> nearby vehicle (a case named sometimes V2V2I). >> >> But I do not understand well why you're saying that having WiFi to >> a neighboring WiFi (not for Internet access, not for data sharing >> like ambulance-police) is not necessarily a good thing. What do >> you have in mind about it not being a good thing? > > Again, let's consider the ambulance case. I've got a small subnet of > devices in that ambulance, behind an on-board router. Let's also > assume a scenario where *all* of my traffic needs are back to the > hospital (via the Internet). From the ambulance, I have WiFi > connectivity to, say, a neighboring police vehicle. But that police > vehicle either doesn't have a router installed, or it doesn't have > Internet connectivity. All I'm saying is that in that case, a WiFi > connection from the ambulance to the police vehicle doesn't help a > whole lot. Well, now I understand what you mean by a non-Internet WiFi access being a bad thing. It is a temptation to connect to and then a disillusion that there is no Internet on it. This is a good problem that deserves being explored. I think the V2V without Internet may still be needed. There may exist a mechanism where one vehicle's MR detects the presence of the other vehicle's MR and understands whether this latter may offer Internet access or not. This distinctor may be the presence of a default route capability in the RA (or DHCP). The presence/absence of default router capability in the heard WiFi is what may help decide to follow/not follow the path of connecting to that WiFi and avoid being deceived. But I agree this risk of deceit by the presence of a non-Internet WiFi is something not good, and we could look at it. Or maybe you see some other solution to this? Alex > > Regards, Stan > > > >> >> Alex >> >>> >>> Regards, Stan >>> >>> >>> >>>> _______________________________________________ manet mailing >>>> list manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >> >> > > > From sratliff@cisco.com Fri Jul 27 08:26: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 D967621F87CC; Fri, 27 Jul 2012 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 FSfxurOb8Doq; Fri, 27 Jul 2012 08:26:14 -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 E921C21F87C8; Fri, 27 Jul 2012 08:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6188; q=dns/txt; s=iport; t=1343402774; x=1344612374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=22LwjAWfdxflN/uyPZKqw5pJDqv5X24mgvwp5LLR6y8=; b=ID1JlAFVm62lnI/DHlyBfV0p5CxLu1qqjwCnPKXGTSWpUQkv4BYhfwUM 1ET3aAyL0fZn4Y0bLiKMpNLhiqNOPBaInCBLw/o1ere3owyLebie4szEA 4cUbz/1J8FLcKvEv22Bw4ZfC8+zxKGOEuNN4by4gD8oWmT0OsFVIalqKi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMuxElCtJV2a/2dsb2JhbAA7Crk8gQeCIAEBAQMBAQEBDwFbCwULAgEIGC4nCyUCBA4FGweHZQYLmg2gVASLUBALhXlgA4gYjTCOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106005324" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jul 2012 15:26:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6RFQDZO030397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 15:26:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 10:26:13 -0500 From: "Stan Ratliff (sratliff)" To: Alexandru Petrescu Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsACAATJBAIAAKmAAgAACJICAAAJPgA== Date: Fri, 27 Jul 2012 15:26:12 +0000 Message-ID: <320F7BE1-B4E7-4F2E-A271-162D8627144B@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> <5012B123.2040605@gmail.com> In-Reply-To: <5012B123.2040605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--35.186100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6A0C1D6607CDD34CBA56FD1EBA9E3BD0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 15:26:15 -0000 On Jul 27, 2012, at 11:17 AM, Alexandru Petrescu wrote: > Le 27/07/2012 17:10, Stan Ratliff (sratliff) a =E9crit : >>=20 >> On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: >>=20 >>> Le 26/07/2012 20:22, Stan Ratliff (sratliff) a =E9crit : >>>> Rex, >>>>=20 >>>> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>>>=20 >>>>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>>>=20 >>>>>> Is there some particular scenario that deserves more interest >>>>>> from your side? >>>>>>=20 >>>>>>> Whether the transmission range of Wi-Fi is enough for this >>>>>>> use case? >>>>>>=20 >>>>>> Indeed in some use cases the WiFi transmission range >>>>>> (unlicensed spectrum, around 50meter range at a certain >>>>>> power level) may be enough. For example, at an incident scene >>>>>> this is largely enough. >>>>>=20 >>>>> Liu Dapeng, >>>>>=20 >>>>> The classical use case, in my mind, is the instrumented >>>>> ambulance*. The casualty inside may have several end systems >>>>> (sensors) attached. Further, the ambulance will have end >>>>> system nav receiver (to report position) and the EMT may need >>>>> several services, VOIP being an obvious one. >>>>>=20 >>>>> The topology for such is a LAN within the ambulance and a >>>>> router with one or more outside interfaces. Reaching to a >>>>> neighboring vehicle (e.g. with WiFi) is clearly not enough. The >>>>> router needs to get to the rest of the internet in order to get >>>>> the data to the hospital emergency room. So the first thought >>>>> is an LTE or IEEE 802.16 network segment for the radio-WAN. >>>>> There's nothing wrong with more than one hop, so including a >>>>> WiFi interface on the router is OK too. (Indeed with the >>>>> balkanization of the cellphone system, at least in US, multiple >>>>> 4G cellphone interfaces is likely to be needed). >>>>>=20 >>>>=20 >>>> FWIW, I think you've hit the nail on the head here. The WiFi >>>> connection to a neighboring vehicle might help, in cases where >>>> (1) the ambulance attendants want to do something like a VoIP >>>> call to the people in the neighboring vehicle, or (2) if said >>>> neighboring vehicle has Internet connectivity and can "share" >>>> (e.g. 802.16, or LTE, or maybe even a satellite modem). But >>>> having WiFi to a neighboring vehicle is, in and of itself, not >>>> necessarily a good thing. >>>=20 >>> WEll, I agree with the first points about potential necessity of >>> WiFi between ambulance and a neighboring vehicle. >>>=20 >>> One scenario that may be relevant is sharing information about the >>> casualty between the two different agencies running each vehicle >>> (say law enforcement and first aid); from an eHealth perspective >>> this would mean to share data like chemical substance history to >>> medicals trying to identify what happened, or between insurance >>> company and the medical to have first hand proof about accident >>> conditions and reimbursement. And more. >>>=20 >>> I also agree about one vehicle offering Internet connection to >>> nearby vehicle (a case named sometimes V2V2I). >>>=20 >>> But I do not understand well why you're saying that having WiFi to >>> a neighboring WiFi (not for Internet access, not for data sharing >>> like ambulance-police) is not necessarily a good thing. What do >>> you have in mind about it not being a good thing? >>=20 >> Again, let's consider the ambulance case. I've got a small subnet of >> devices in that ambulance, behind an on-board router. Let's also >> assume a scenario where *all* of my traffic needs are back to the >> hospital (via the Internet). From the ambulance, I have WiFi >> connectivity to, say, a neighboring police vehicle. But that police >> vehicle either doesn't have a router installed, or it doesn't have >> Internet connectivity. All I'm saying is that in that case, a WiFi >> connection from the ambulance to the police vehicle doesn't help a >> whole lot. >=20 > Well, now I understand what you mean by a non-Internet WiFi access being > a bad thing. It is a temptation to connect to and then a disillusion > that there is no Internet on it. >=20 > This is a good problem that deserves being explored. >=20 > I think the V2V without Internet may still be needed. There may exist a > mechanism where one vehicle's MR detects the presence of the other > vehicle's MR and understands whether this latter may offer Internet > access or not. This distinctor may be the presence of a default route > capability in the RA (or DHCP). The presence/absence of default router > capability in the heard WiFi is what may help decide to follow/not > follow the path of connecting to that WiFi and avoid being deceived. Oh yes, I absolutely agree that the WiFi connection *could* be a useful thi= ng - it just depends on what you are trying to do. >=20 > But I agree this risk of deceit by the presence of a non-Internet WiFi > is something not good, and we could look at it. >=20 > Or maybe you see some other solution to this? I don't know that it deceitful, it's just a scenario that could happen. As = far as a solution goes, I think it's something that should be discussed, bu= t from what I've seen, one way to address it is with multiple links in the = ambulance. As was mentioned earlier in this thread - if the ambulance has a= n LTE connection to the Internet, then things work. In the case where the a= mbulance's WiFi happens to find an Internet-accessible hotspot to connect t= o, then there are a couple of paths back to the hospital - the question fro= m the ambulance router perspective is "what's the best link?". But yes, I s= ee this as an area for discussion/exploration and potential work.=20 Regards, Stan >=20 > Alex >=20 >=20 >>=20 >> Regards, Stan >>=20 >>=20 >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Regards, Stan >>>>=20 >>>>=20 >>>>=20 >>>>> _______________________________________________ manet mailing >>>>> list manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 From thomas@thomasclausen.org Sat Jul 28 12:30: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 9E29421F8496 for ; Sat, 28 Jul 2012 12:30:10 -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 RFlMa-hV41W8 for ; Sat, 28 Jul 2012 12:30:09 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id B294721F8495 for ; Sat, 28 Jul 2012 12:30:09 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 5F207A6833 for ; Sat, 28 Jul 2012 12:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 523A51BD5C9E; Sat, 28 Jul 2012 12:30:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.9.193] (unknown [64.114.255.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BF1A11BD5CBC; Sat, 28 Jul 2012 12:30:07 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8B297D77-4FFE-40ED-A7B1-EFDAB62A4A0E" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Heide Clausen In-Reply-To: <078d01cd6a95$badeb000$309c1000$@olddog.co.uk> Date: Sat, 28 Jul 2012 12:30:04 -0700 Message-Id: References: <078d01cd6a95$badeb000$309c1000$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1485) Cc: manet@ietf.org, draft-ietf-manet-olsrv2@tools.ietf.org Subject: Re: [manet] AD review of 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: Sat, 28 Jul 2012 19:30:10 -0000 --Apple-Mail=_8B297D77-4FFE-40ED-A7B1-EFDAB62A4A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Adrian, Detailed comments below. Begin forwarded message: > From: "Adrian Farrel" > Subject: [manet] AD review of draft-ietf-manet-olsrv2 > Date: July 25, 2012 11:45:55 PDT > To: > Cc: draft-ietf-manet-olsrv2@tools.ietf.org > Reply-To: adrian@olddog.co.uk >=20 > Hi, >=20 > Don't be alarmed! >=20 > I have done an AD review of this document. The principal purpose of my > review is to catch issues that I find in the document and to ensure = that > the work will get a smoother and more rapid progression through IETF > last call and IESG review. >=20 > My congratulations to the working group, and especially the editors, = for > an extremely clear and readable document. I have only minor comments > that I suggest you handle along with any comments you receive during = IETF > last call (which I will start shortly). Thank you for your review, and for those kind words; we aim to please. > Thanks, > Adrian >=20 > =3D=3D=3D >=20 > Section 1 >=20 > After the discussion on the list about the impact on the status of > RFC 3626, I suggest adding the following sentence to the end of the > first paragraph in Section 1 >=20 > This document does not obsolete [RFC3626] which is left in place for > further experimentation. Sensible and reasonable suggestion, which we shall include. > --- >=20 > Section 2 >=20 > Anycast > addresses MAY be considered as routable addresses. >=20 > This is fine, but it would be helpful to explain why this is "MAY" not > may. The upper case gives a feeling that anycast addresses can be > present and normally not considered as routable, but sometimes (for = some > unspecified reason) and implementation/deployment will consider them = as > routable. Right; I do not really think that there's any good reason why it is = "MAY" and not "may" - would it help to simply make this lower-case? > --- >=20 > I like the appendixes and the fact that you have taken the time to > create examples. But appendix D contains 2119 language and this jars a > bit. As a first comment, this is done in OLSRv2 exactly as it was in RFC6130 = (where the corresponding appendix is B, and we would much prefer to keep = those two documents as similar in structure as possible. That said, for appendix D, note that: o The processing specified in the normative sections (1-27 = -- i.e. non-appendices) ensures that these constraints are met. Thus, if one goes ahead and = implements the protocol as specified, these constraints are satisfied. o If any external process is modifying the recorded = information, then that external process should be such that these constraints are not violated. = Note that this specification does not specify such a process, just gives constraints that must = be satisfied so as to not break OLSRv2 o An implementation, wanting to run sanity-checks on the = recorded information, can do so according to this appendix; if a constraint is not met, then = something in the processing code has borked up,=20 be that either the implementation of the processing in = sections 1-27, or some external process updating the same information sets. Another way of putting the above is, that appendix D doesn't prescribe = behaviour of the protocol specified in this document, but rather = provides constraints which must be respected for the case where another = process/protocol wishes to update the information sets used by this = protocol. Thus, to answer your question: > Is appendix D part of the normative text but moved to an appendix > because it is a meaty piece of text that would get in the way of the > flow of the main text (i.e. section 22 bullet 1)? If so, the appendix > should start with a statement that this appendix forms a normative = part > of the specification, and a back pointer to section 22. The answer is No. =20 This wasn't a piece of text moved to an appendix so that it wouldn't get = in the way, but rather because it's providing a framework of constraints = for guiding "extensions"/external processes wanting to interact with = OLSRv2. The processing in the numbered sections respect these = constraints already. Thus, appendix D does IMO not belong in the main part of the text (the = numbered sections), but definitely in an appendix. Also, I do think that = this precisely is one of the (very few) cases where 2119-language is = appropriate in an appendix. > To a lesser extent, appendix E bothered me and I wondered whether you > would consider moving it to be a main section of the document. As a first comment, this is done in OLSRv2 exactly as it was in RFC6130 = (where the corresponding appendix is D, and we would much prefer to keep = those two documents as similar in structure as possible. As a second comment, this appendix definitely isn't prescriptive in = nature, but rather reflects on the signalling nature of the protocol = (and exists since, eons ago, there was a requirement that all protocol = specifications have a "Flow and Congestion Control" appendix). Best, Thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_8B297D77-4FFE-40ED-A7B1-EFDAB62A4A0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = Adrian,

Detailed comments = below.

Begin forwarded message:

From: "Adrian Farrel" <adrian@olddog.co.uk>
<= div style=3D"margin: 0px; ">Subject: [manet] AD review of = draft-ietf-manet-olsrv2
adrian@olddog.co.uk

<= div>Hi,

Don't be alarmed!

I have done an AD review of this = document. The principal purpose of my
review is to catch issues that = I find in the document and to ensure that
the work will get a = smoother and more rapid progression through IETF
last call and IESG = review.

My congratulations to the working group, and especially = the editors, for
an extremely clear and readable document. I have = only minor comments
that I suggest you handle along with any comments = you receive during IETF
last call (which I will start = shortly).

Thank you for your = review, and for those kind words; we aim to = please.

Thanks,
Adrian

=3D=3D=3D

Section = 1

After the discussion on the list about the impact on the status = of
RFC 3626, I suggest adding the following sentence to the end of = the
first paragraph in Section 1

  This document = does not obsolete [RFC3626] which is left in place = for
  further = experimentation.

Sensible and reasonable = suggestion, which we shall = include.

---

Section = 2

     Anycast
    =  addresses MAY be considered as routable addresses.

This is = fine, but it would be helpful to explain why this is "MAY" not
may. = The upper case gives a feeling that anycast addresses can be
present = and normally not considered as routable, but sometimes (for = some
unspecified reason) and implementation/deployment will consider = them as
routable.

Right; I do not = really think that there's any good reason why it is "MAY" and not "may" = - would it help to simply make this = lower-case?

---

I like the appendixes and the fact that you = have taken the time to
create examples. But appendix D contains 2119 = language and this jars a
bit.

As a first = comment, this is done in OLSRv2 exactly as it was in RFC6130 (where the = corresponding appendix is B, and we would much prefer to keep those two = documents as similar in structure as = possible.

That said, for appendix D, note = that:

o The processing specified in the = normative sections (1-27 -- i.e. non-appendices) ensures = that
= these constraints are satisfied.

o If any = external process is modifying the recorded information, then that = external process
should be such that these = constraints are not violated. Note that this specification does = not
o An implementation, wanting to run = sanity-checks on the recorded information, can do so = according
to this appendix; if a constraint is not met, = then something in the processing code has borked = up, 
be that either the implementation of the = processing in sections 1-27, or some external process
= updating the same information = sets.

Another way of putting the above is, that = appendix D doesn't prescribe behaviour of the protocol specified in this = document, but rather provides constraints which must be respected for = the case where another process/protocol wishes to update the information = sets used by this protocol.

Thus, to answer = your question:

Is = appendix D part of the normative text but moved to an = appendix
because it is a meaty piece of text that would get in the = way of the
flow of the main text (i.e. section 22 bullet 1)? If so, = the appendix
should start with a statement that this appendix forms a = normative part
of the specification, and a back pointer to section = 22.

The answer is No. =  

This wasn't a piece of text moved to an = appendix so that it wouldn't get in the way, but rather because it's = providing a framework of constraints for guiding "extensions"/external = processes wanting to interact with OLSRv2. The processing in the = numbered sections respect these constraints = already.

Thus, appendix D does IMO not belong = in the main part of the text (the numbered sections), but definitely in = an appendix. Also, I do think that this precisely is one of the (very = few) cases where 2119-language is appropriate in an = appendix.


To a lesser extent, appendix E bothered me and I wondered = whether you
would consider moving it to be a main section of the = document.

As a first comment, = this is done in OLSRv2 exactly as it was in RFC6130 (where the = corresponding appendix is D, and we would much prefer to keep those two = documents as similar in structure as = possible.

As a second comment, this appendix = definitely isn't prescriptive in nature, but rather reflects on the = signalling nature of the protocol (and exists since, eons ago, there was = a requirement that all protocol specifications have a "Flow and = Congestion Control" = appendix).

Best,

Thomas<= /div>

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

= --Apple-Mail=_8B297D77-4FFE-40ED-A7B1-EFDAB62A4A0E-- From iesg-secretary@ietf.org Sat Jul 28 16:27: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 7AB6B21F84A0; Sat, 28 Jul 2012 16:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 fK1IVqXwBW+2; Sat, 28 Jul 2012 16:27:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181FA21F8494; Sat, 28 Jul 2012 16:27:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120728232737.23974.14830.idtracker@ietfa.amsl.com> Date: Sat, 28 Jul 2012 16:27:37 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (The Optimized Link State Routing Protocol version 2) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 23:27:37 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'The Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This last call period has been extended to handle the fact that it spans the IETF-84 meeting. This last call is being re-initiated to include a notice that this document includes a normative down reference to an Informational RFC: RFC5148, "Jitter considerations in MANETs". Abstract This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/ No IPR declarations have been submitted directly on this I-D. From adrian@olddog.co.uk Sat Jul 28 21:43: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 CF62721F86A8; Sat, 28 Jul 2012 21:43:44 -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 ynR8JUwWVy29; Sat, 28 Jul 2012 21:43:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97721F8666; Sat, 28 Jul 2012 21:43:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6T4hd7a030362; Sun, 29 Jul 2012 05:43:39 +0100 Received: from 950129200 ([130.129.68.110]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6T4hYIu030151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Jul 2012 05:43:37 +0100 From: "Adrian Farrel" To: Date: Sun, 29 Jul 2012 05:42:45 +0100 Message-ID: <024701cd6d44$b8d80160$2a880420$@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: Ac1tRJV354xo90DRS1egTZvG+nyJhQ== Content-Language: en-gb Cc: manet@ietf.org Subject: Re: [manet] Last Call: (The Optimized Link State Routing Protocol version 2) to Proposed Standard 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: Sun, 29 Jul 2012 04:43:45 -0000 All, Please note this last call was re-started to handle a downref I missed first time around. Adrian > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > The IESG > Sent: 29 July 2012 00:28 > To: IETF-Announce > Cc: manet@ietf.org > Subject: [manet] Last Call: (The Optimized Link > State Routing Protocol version 2) to Proposed Standard > > > The IESG has received a request from the Mobile Ad-hoc Networks WG > (manet) to consider the following document: > - 'The Optimized Link State Routing Protocol version 2' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. This last call > period has been extended to handle the fact that it spans the IETF-84 > meeting. > > This last call is being re-initiated to include a notice that this document > includes a normative down reference to an Informational RFC: > RFC5148, "Jitter considerations in MANETs". > > Abstract > > This specification describes version 2 of the Optimized Link State > Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From reller@cococorp.com Mon Jul 30 10:19: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 7846411E8133; Mon, 30 Jul 2012 10:19:43 -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 1F2bUTfmiwHh; Mon, 30 Jul 2012 10:19:43 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id D2AD111E8130; Mon, 30 Jul 2012 10:19:42 -0700 (PDT) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub06.exchhosting.com (192.168.11.102) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 10:19:41 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Mon, 30 Jul 2012 10:19:40 -0700 From: "A. Riley Eller" To: Alexandru Petrescu , liu dapeng Date: Mon, 30 Jul 2012 10:19:37 -0700 Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: Ac1qcFoz+xyXwOxsSdyoLN0cNH/MfQEBr1Xw Message-ID: <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> In-Reply-To: <50100020.4040708@gmail.com> 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 Cc: manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:19:43 -0000 Le 25/07/2012 05:26, liu dapeng a =E9crit : > > 1. If the mobile routers have LTE link and use IPv6, then v2v=20 > communication can also rely on LTE? While the working item is still a fair distance from realizing standardizat= ion, I think it is worth mentioning that LTE Direct (a peer-to-peer channel= and symmetric transmission/reception mode) is being proposed by Qualcomm. = >From my interviews with their technical team, I am very excited about the p= ossibility of mobile node to mobile node direct LTE link. If any of you are= also interested, it might be good to check in on their progress and offer = your comments. Riley From alexandru.petrescu@gmail.com Mon Jul 30 10:31: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 CF7DA11E8166; Mon, 30 Jul 2012 10:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.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 zVN7G4XZnUTV; Mon, 30 Jul 2012 10:31:15 -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 E7B5F11E8163; Mon, 30 Jul 2012 10:31:14 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10118186pbc.31 for ; Mon, 30 Jul 2012 10:31:14 -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:content-type:content-transfer-encoding; bh=dHzoHryU3kQZL1cEfdFlpgAcNkw+JxAwmsw6A0qci6M=; b=u2QgGG6XApj2sZZNsMH0PVMBUvunoP7V3y5rGZDNfAF5fMws3CpsJuy0PeAkRyoNLG U3tp02tauIWZ93BKZwmZOhxfIRQjmNpZtwU/NOy2D+odRL/iCQ2U+09X/R2B7O3o12ZP eYB8/sAvo+s3cYYxIurn5OpNyt1piEkHQNFSi7A7McmCRwCi9qQB6+OGGbeyiK2QHMQJ g3JaTk4jsm4h2/60ABZQ+WQKR8nGicvJbi5BCHlB0vjbiqehhKMF2SNVo+7bfE3qY+B2 Vc4Mx1xo4pEglRd6M7dR3wP+8usev0yiWsvjQ12xKuamI91DZs5Oer7DlYJGF7TdiGlE Bdrg== Received: by 10.68.239.103 with SMTP id vr7mr37930029pbc.0.1343669474743; Mon, 30 Jul 2012 10:31:14 -0700 (PDT) Received: from [130.129.19.174] (dhcp-13ae.meeting.ietf.org. [130.129.19.174]) by mx.google.com with ESMTPS id nh8sm8286986pbc.60.2012.07.30.10.31.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 10:31:14 -0700 (PDT) Message-ID: <5016C4DD.3090603@gmail.com> Date: Mon, 30 Jul 2012 10:31:09 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "A. Riley Eller" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 17:31:16 -0000 Le 30/07/2012 10:19, A. Riley Eller a écrit : > Le 25/07/2012 05:26, liu dapeng a écrit : >> >> 1. If the mobile routers have LTE link and use IPv6, then v2v >> communication can also rely on LTE? > > While the working item is still a fair distance from realizing > standardization, I think it is worth mentioning that LTE Direct (a > peer-to-peer channel and symmetric transmission/reception mode) is > being proposed by Qualcomm. From my interviews with their technical > team, I am very excited about the possibility of mobile node to > mobile node direct LTE link. If any of you are also interested, it > might be good to check in on their progress and offer your comments. Certainly I (and a group of people locally) are interested in the use of LTE for direct communications. How would it be possible to check in on their progress and how could we offer our comments? Alex > > Riley > From alexandru.petrescu@gmail.com Mon Jul 30 13:15: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 3DA8111E80F6 for ; Mon, 30 Jul 2012 13:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.062 X-Spam-Level: X-Spam-Status: No, score=-4.062 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 CZ1t4qOpeLRx for ; Mon, 30 Jul 2012 13:15:00 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 634E811E80F1 for ; Mon, 30 Jul 2012 13:15:00 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5702772ggn.31 for ; Mon, 30 Jul 2012 13:15:00 -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:subject :content-type:content-transfer-encoding; bh=saKC4KI3zt/SaowQXhxpYYzM4DGne0Z1/HNEFtJmiPc=; b=qpV6oLa8lPDXxTf16YD7OJ1D2NlKiS9w3HOQ1ilpHRPHeVcExKrYPrJQQUrZagPZC4 x9U9KMgCq9oxX15AaI4dcmc6RdM1YGlcNa/N0wf4M5isYEWOC4mkZGC0V+P5SyaiDY2J zTxoXM8ObJpFganhKfikIfeZTTKdn0TmvdzS+pm2OgTtAJOX59YFE1dDEl7KinmvoYvo uUhzQqwhKB2Jdpb1oRjqs8RjwvrHV6BCVk6RiXrfgYWTb8odsZfl8eU0ZUhexV/8i9SK 5TKRx2jGhXXPIJxLlnPZCOmvfgZozcEASpkkt5psR45exLWZnqLRJ0288S+UDFL5Qu3r v1pg== Received: by 10.66.82.228 with SMTP id l4mr27053649pay.41.1343679299655; Mon, 30 Jul 2012 13:14:59 -0700 (PDT) Received: from [130.129.19.174] (dhcp-13ae.meeting.ietf.org. [130.129.19.174]) by mx.google.com with ESMTPS id ql6sm8514704pbc.61.2012.07.30.13.14.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 13:14:59 -0700 (PDT) Message-ID: <5016EB3E.5050901@gmail.com> Date: Mon, 30 Jul 2012 13:14:54 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: manet Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [manet] bar BoF ITS Intelligent Transportation Systems, today 19h30-20h30, room Plaza C X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 20:15:01 -0000 Dear participants to MANET Working Group, I invite to join us at the bar BoF ITS - IP for Intelligent Transportation Systems today 30 july 2012 19h30-20h30 Vancouver at Pacific time room Plaza C, 2nd floor email list its@ietf.org, https://www.ietf.org/mailman/listinfo/its webex https://cea-list.webex.com/cea-list/j.php?ED=219289702&UID=0&PW=NOGFmZmI1MzA2&RT=NyM0 password itsietf During the previous IETF meeting in Paris, the first ITS informal meeting took place; then several potential work items were identified and presented (http://imara.inria.fr/ietf-its). Since then we discussed scenarios, requirements and work items. The goal of the meeting this evening is to better identify the scope of potential work, problem and work items. What would a Charter look like. Yours, Alex From reller@cococorp.com Mon Jul 30 16:20: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 C902F21F850C; Mon, 30 Jul 2012 16:20:15 -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 gAWpY-EzTPBq; Mon, 30 Jul 2012 16:20:14 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id D897E21F850B; Mon, 30 Jul 2012 16:20:05 -0700 (PDT) Received: from exhub13.exchhosting.com (192.168.11.122) by exhub09.exchhosting.com (192.168.11.107) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 16:20:04 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by exhub13.exchhosting.com ([::1]) with mapi; Mon, 30 Jul 2012 16:20:03 -0700 From: "A. Riley Eller" To: Alexandru Petrescu Date: Mon, 30 Jul 2012 16:20:01 -0700 Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: Ac1ueR93exAGBa3gTkWHUVIyQKj+hQAMFh2g Message-ID: <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> In-Reply-To: <5016C4DD.3090603@gmail.com> 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 Cc: manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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 Jul 2012 23:20:16 -0000 > > While the working item is still a fair distance from realizing > > standardization, I think it is worth mentioning that LTE Direct (a > > peer-to-peer channel and symmetric transmission/reception mode) is > > being proposed by Qualcomm. From my interviews with their technical > > team, I am very excited about the possibility of mobile node to > > mobile node direct LTE link. If any of you are also interested, it=20 > > might be good to check in on their progress and offer your comments. >=20 > Certainly I (and a group of people locally) are interested in the use > of LTE for direct communications. >=20 > How would it be possible to check in on their progress and how could we > offer our comments? >=20 > Alex I am not an expert on the 3GPP process, so rather than muddle about and con= fuse things, I will include the following article which I hope will offer c= lues. I believe that the standards body has agreed to investigate whether a= direct mode is worth standardizing (??). http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20110= 928/ My connection to this program came from direct industry contact, so I apolo= gize for my obtuse response. Riley From jpmacker@gmail.com Mon Jul 30 17:09: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 69A9F11E80E4 for ; Mon, 30 Jul 2012 17:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.532, 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 EYVcE9qqKErg for ; Mon, 30 Jul 2012 17:09:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B171811E8099 for ; Mon, 30 Jul 2012 17:09:15 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5526325vcb.31 for ; Mon, 30 Jul 2012 17:09:15 -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=OXHbQzkJljrWklsD10NNz4Kav+H/Ldav66TlOjgi7Uo=; b=GP7PuugqIF9gzNK4BumH9GXStIvZUoWmxbBxQKEoa4p3V4hO6Ryke+i6mMnEmwlTwX DiaBgd0PrxyawNC8vEO7z4Yo3iGUkjzUWykNuvG+qd8z4qblPSGgpXDCot7+qFN1knMg c+8JU+mo2MnXV+CUUIxwNw037OiG+fPaHckNRFnUFSHfk89nPrfzu7YqTBjMTRfvcmDg SJrKNTUOT5fKvGT2tPY6tl5nGAJJ8oxcG3xznv40ylNVcWH2oUgu3Rl9UunWaNZoJcel tE2E1Zt/Kpsefb89axjO9urtWrBXuzn9ILEN9En4uwXa7Cyboh58OQ0WFU0vyQFi/Tjp T7yg== MIME-Version: 1.0 Received: by 10.59.7.138 with SMTP id dc10mr893372ved.8.1343693355207; Mon, 30 Jul 2012 17:09:15 -0700 (PDT) Received: by 10.58.200.97 with HTTP; Mon, 30 Jul 2012 17:09:15 -0700 (PDT) Date: Mon, 30 Jul 2012 17:09:15 -0700 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0f3261fcdcf04c614fddd Subject: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 00:09:16 -0000 --047d7bf0f3261fcdcf04c614fddd Content-Type: text/plain; charset=ISO-8859-1 I apologize to Jiazi and co-authors as we accidentally skipped one of the slide sets at this afternoon's meeting. Please review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda and see draft-ietf-manet-nhdp-sec-threats-00 The authors are asking for consideration of WG LAST CALL on this document so please comment. -Joe --047d7bf0f3261fcdcf04c614fddd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I apologize to Jiazi and co-authors as we accidentally skipped one of the s= lide sets at this afternoon's meeting.

Please review the slides = for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda
and see draft-ietf-manet-nhdp-sec-threats-00

The authors are asking for consideration of WG LAST CALL on this docume= nt so please comment.

-Joe
--047d7bf0f3261fcdcf04c614fddd-- From yi.jiazi@gmail.com Mon Jul 30 18:18: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 2BE5D21F85A5 for ; Mon, 30 Jul 2012 18:18:00 -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 rFKee06oTssE for ; Mon, 30 Jul 2012 18:17:59 -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 6640421F853E for ; Mon, 30 Jul 2012 18:17:58 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so10674598pbc.31 for ; Mon, 30 Jul 2012 18:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=m0U6BHIsT5KOJATXY9OyOEyawvZKRYcMGpdYaDc4VP8=; b=kdW+K7iLZKY6T6MxDDbOc+7JDiRYy1V5Bs5CdbfE+tMvyNnmJH9ZCmL0NUAG7ixo2S iNhi8iJr7Q6e/FlMU4aLv3H1Y643B4O3FLes+mrEGtdc3McQ/G+Yda7Rq2IXGeew7j+a WiAeUvnju8vIPLh1qJ9x2bFGHdjG0uRRJFvgXSuStBL1FF5ffH48lTFz0f0tOtvCvQqb likfvGtWju9jss0+hdwRdAyUuwO4L0H6hlVxGRF7QjEUjtsfcwTYwrIaF9fgAXMW3mVY oKGwe7oLHMt93j41kHG8OV4BtG3RCZMOvYx59MdpU86RSMJci55sqo76S33JPRa6Szac gKyQ== Received: by 10.68.224.170 with SMTP id rd10mr36849307pbc.106.1343697477984; Mon, 30 Jul 2012 18:17:57 -0700 (PDT) Received: from [208.181.207.220] ([64.114.255.126]) by mx.google.com with ESMTPS id qd10sm8952335pbb.38.2012.07.30.18.17.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 18:17:56 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_6315DE07-12C5-4BB6-A2B8-0352CDB3D210" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jiazi YI In-Reply-To: Date: Mon, 30 Jul 2012 18:17:56 -0700 Message-Id: <6E0E9E31-A9D4-403E-8F12-85F6EF1E898C@jiaziyi.com> References: To: Joseph Macker X-Mailer: Apple Mail (2.1485) Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 01:18:00 -0000 --Apple-Mail=_6315DE07-12C5-4BB6-A2B8-0352CDB3D210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 No problem, Joe.=20 Actually, there is no update since the last IETF in Paris, so just a few = words to be added: The main comment from the last IETF meeting is regarding the scope of = this document. We have explained our approach/consideration in a = previous mail = (http://www.ietf.org/mail-archive/web/manet/current/msg12897.html ), and = there is no objection of that.=20 Therefore, we would like ask for WGLC, and comments from the working = group.=20 best Jiazi Yi http://www.jiaziyi.com LIX, Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex France On Jul 30, 2012, at 5:09 PM, Joseph Macker wrote: > I apologize to Jiazi and co-authors as we accidentally skipped one of = the slide sets at this afternoon's meeting. >=20 > Please review the slides for NHDP-sec-threats located at = http://tools.ietf.org/wg/manet/agenda > and see draft-ietf-manet-nhdp-sec-threats-00 >=20 > The authors are asking for consideration of WG LAST CALL on this = document so please comment. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_6315DE07-12C5-4BB6-A2B8-0352CDB3D210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 = http://www.ietf.org/mail-archive/web/manet/current/msg12897.html = ), and there is no objection of = that. 

Therefore, we would like ask for = WGLC, and comments from the working = group. 

best

Jiazi = Yi

LIX, = Ecole Polytechnique
Route de Saclay 91128 Palaiseau Cedex = France

On Jul 30, 2012, at 5:09 PM, Joseph Macker <jpmacker@gmail.com> = wrote:

I apologize to Jiazi and co-authors as we accidentally = skipped one of the slide sets at this afternoon's meeting.

Please = review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda
and see draft-ietf-manet-nhdp-sec-threats-00

The authors are asking for consideration of WG LAST CALL on this = document so please comment.

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

= --Apple-Mail=_6315DE07-12C5-4BB6-A2B8-0352CDB3D210-- From abdussalambaryun@gmail.com Mon Jul 30 21:40: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 A5F7A11E80D5 for ; Mon, 30 Jul 2012 21:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 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 70jHjkhGli5R for ; Mon, 30 Jul 2012 21:40:49 -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 1A23D21F853B for ; Mon, 30 Jul 2012 21:40:49 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5751377vbb.31 for ; Mon, 30 Jul 2012 21:40:48 -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=HpuRLn6LwFYyYGDnMUwY1mEDeaZMwksIfVQR87Tufmk=; b=CRwNWBhTKk1OKFuy+RgHNKsWdniksNy/R5buQGAfBAid993gq7dHHHJZPO6dj0ctOt lPgMgLjIo+MQ86Vdg2yvXxx5k9OU03cqtzthGO0SgfVbp7yKYz1COiJLRFBwkQ6QWJuW Gu0s3/BpsLhZcsK/pRxS5OmT90aoNhA1QMHUx68HEyQ5nVfnLz49H2Yvo074rSM0BMLC 0s4I6ReEHbK4eUGIrYv1aPCq6GMLsTG/E09B/YlRGLMGOIq1FueKFl51xVYMgkZz12Cy Sm7L7YQs+KNY9f38/iy5GuCKMXSg69tixm97fDoolIxkKR/odgTpm8dWI9itOTgiGK3x N2Ow== MIME-Version: 1.0 Received: by 10.52.90.144 with SMTP id bw16mr11436911vdb.129.1343709648585; Mon, 30 Jul 2012 21:40:48 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Mon, 30 Jul 2012 21:40:48 -0700 (PDT) Date: Tue, 31 Jul 2012 06:40:48 +0200 Message-ID: From: Abdussalam Baryun To: ietf@jiaziyi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 04:40:50 -0000 Hi Jiazi I already send my feedback before [1 -2] which had no respond/comment from authors. I think any comment should be responded to by authors of I-Ds or RFCs. I think that we need more discussions responds/comments from the group before last call regarding this I-D. Regards AB [1] http://www.ietf.org/mail-archive/web/manet/current/msg12899.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg13234.html =================================================== > I apologize to Jiazi and co-authors as we accidentally skipped one of > the slide sets at this afternoon's meeting. > > Please review the slides for NHDP-sec-threats located at > http://tools.ietf.org/wg/manet/agenda > and see draft-ietf-manet-nhdp-sec-threats-00 > > The authors are asking for consideration of WG LAST CALL on this > document so please comment. > > -Joe > From teco@inf-net.nl Mon Jul 30 23:00: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 E664E21F850D for ; Mon, 30 Jul 2012 23:00:37 -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 a-rIUwJNXtPs for ; Mon, 30 Jul 2012 23:00:35 -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 1196511E80EE for ; Mon, 30 Jul 2012 23:00:34 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so11032817pbc.31 for ; Mon, 30 Jul 2012 23:00: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 :message-id:references:to:x-mailer:x-gm-message-state; bh=Q9I2haCT4gUorcSybz7Gj4Oqvy5/ljkatVo+3xmvkUU=; b=X+iSvz5gNqahfJmojm9z7GnHq7Z4Hytv73lVdRqXAknNivO0U2Ej/3bZdlSkgAa9VD ZxoH7OjQVYd/TzX2nfcD3QJ3kXSEdY97u7KddW2BwvmYgf64VoTuAHgkSZgKBBmZxRzz hLAMeLcmdVZT1DYyAr8DeSSxlyC8JiaF6JXkXZ1VWhXWc185BNP+cvYgt48mEWaasRm6 tVaE50TQ1WD5I8EutE79yYmRhqZJlSHpsRiW5Cu4voaQzDVcY2QvqJgMkGrebhYIM/QU TTCpInMpfKUiVa4LxVuSXm0jVauP6Ny6lBg52pi91izpUDWYBw+/leFaFfVGg7Y38hsw ml7g== Received: by 10.68.227.195 with SMTP id sc3mr40759262pbc.104.1343714433341; Mon, 30 Jul 2012 23:00:33 -0700 (PDT) Received: from dhcp-44e8.meeting.ietf.org (dhcp-44e8.meeting.ietf.org. [130.129.68.232]) by mx.google.com with ESMTPS id ms9sm9420727pbb.43.2012.07.30.23.00.31 (version=SSLv3 cipher=OTHER); Mon, 30 Jul 2012 23:00:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1919A322-AD99-4958-9724-BEA24C2664F1" From: Teco Boot In-Reply-To: Date: Tue, 31 Jul 2012 08:00:29 +0200 Message-Id: <552D5A63-994B-4E12-B615-213B0FFC46F3@inf-net.nl> References: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkYLZq3O8R5o/LjQcwcPXM5CKXqa5nQeHxf5LNdyCsKxKRGu8upDupiTKp0Gr7xP663Md5m Cc: "Dearlove, Christopher \(UK\)" , manet , Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:00:38 -0000 --Apple-Mail=_1919A322-AD99-4958-9724-BEA24C2664F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I provided feedback to authors before: I strongly prefer having a = document on MANET packet security before we go into further details, = such as manet-nhdp-sec. Another concern is that NHDP messages are = extended by other protocols. Teco Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven: > Chris, >=20 > On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) = wrote: > This partly depends on what your planned document structure is, Ulrich = just mentioned the possibility of a generic 5444 document. I'm actually = not sure that wouldn't be more relevant, as it is hard to actually = separate these things. >=20 >=20 > My concern is, if you want to specify packet signing in the NHDP-sec = document, that NHDP itself would never see the packet. The RFC5444 = multiplexing would see a HELLO message in the packet and send it to NHDP = (which can use the mechanisms specified in NHDP-sec to reject or accept = the message). I think that a packet signer/verifier is tied to the = RFC5444 parser itself, which would accept or reject the whole packet. So = in my view, it would actually be much easier to separate it into an = additional draft, rather than combining it with NHDP.=20 > Moreover, protocols that do not use NHDP but use RFC5444 would = probably like to use packet ICV verification as well, but they don't = need all the NHDP part. >=20 > =20 >=20 > =20 >=20 > But I think this is jumping in with solutions before considering a = threat model. Let's suppose that we have hardware that (a) stores key = materials in secure tamperproof storage, (b) doesn't make mistakes, and = (c) we use a signature method that's cryptographically infeasible to = break. Then in this case (not uniquely) packet signatures actually = provide as much security as message signatures. >=20 >=20 > If you assume a transitive trust model. If a router receives a TC = message (unsigned) in a correctly signed packet, the receiving router = can be sure that the TC has not been modified after transmission by the = previous hop. It has no information what happened before that. But I = agree that for certain deployments that may be enough. > =20 > Of course I can also think of threat models that do favour message = signatures. But this is exactly like the choice of signature methods, = which is not mandated because different threats require different = solutions. >=20 >=20 > Right. I am absolutely in favor of specifying packet ICV handling. The = only question for me is where to do that. > =20 > The same is true of packet and message signatures. Each (and indeed = the third option of both) should be allowed, we should not have a = document that prefers one above the other >=20 >=20 > Correct. > =20 > except following a security analysis - which is not on offer. >=20 >=20 > Yes. There was some emails about the nhdp-sec-threats document by = Jiazi several months ago, but there was not much activity on the mailing = list.. Do you think that that document should contain such an analysis? >=20 > Best regards > Ulrich > =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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 13 July 2012 13:36 > To: Dearlove, Christopher (UK) > Cc: Ulrich Herberg; manet >=20 >=20 > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt >=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 > Chris, >=20 > =20 >=20 > I figured that you wouldn't agree. >=20 > =20 >=20 > I agree, of course, with your observation that none of the signature = models yields end-to-end security, but I don't think that that's the = issue here.=20 >=20 > =20 >=20 > Personally, I do not see packet ICVs as being appropriate for neither = NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am = not saying that they do not exist. I could make an argument that a = packet ICV would have to be validated before knowing that a HELLO = message was delivered to an NHDP instance, and that the validation might = be based on different principles (or, even layers) for packet/messages.=20= >=20 > =20 >=20 > I see what you say about protecting packet sequence numbers by way of = a packet-level ICV, but I would argue that: >=20 > =20 >=20 > o As packet sequence numbers are generated = "outside" NHDP, and are incremented for all=20 >=20 > packets (not just those with HELLOs), = specifying the validation of a packet-level ICV in NHDP would >=20 > be inappropriate (as in: potentially = conflicting with another mechanism) >=20 > =20 >=20 > o Whatever mechanism would provide "packet = sequence number statistics" to NHDP (such as the >=20 > demultiplexer) would want to be the entity = doing that packet-level ICV validation, in part as >=20 > I would _suspect_ that inability to validate a = packet-level ICV should cause the whole packet >=20 > with all contained messages to be dropped. >=20 > =20 >=20 > That said, with reference to the I-D, I think I speak for the authors = when saying that we're welcoming a suggestion that would address the = issue that you raise? >=20 > =20 >=20 > Best, >=20 > =20 >=20 > Thomas >=20 > =20 >=20 > On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote: >=20 >=20 >=20 >=20 > I don't agree. Note that if all you are running is NHDP, then signing = packets is more secure than signing messages, as you get to cover the = packet sequence number as well. >=20 > What I think is wrong is to suggest that the only correct way to = protect NHDP is to sign HELLO messages. Whether by inclusion or external = reference, signing packets should be also an option. >=20 > =20 >=20 > I'll take that further to OLSrv2 as well. Now there signing messages = vs signing packets has advantages to the former. But signing packets = also has advantages of simplicity and covering packet header. It is = incidentally not correct to say that signing TC messages provides end to = end security. It's actually last-bit-one-from-end to end, and still = relies on a form of transitive trust. Packet based signatures rely on a = greater degree of transitive trust. There is a difference in threat = models and vulnerabilities, and that may matter, but it's not = (unfortunately) as simple as one being end to end and thus avoiding = transitivity issues. >=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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 > Sent: 12 July 2012 23:09 > To: Ulrich Herberg > Cc: Dearlove, Christopher (UK); manet > Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt >=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 > I agree with Ulrich.=20 >=20 > =20 >=20 > Note that this is all about "messages" in as much as NHDP is = concerned. >=20 > =20 >=20 > 1) NHDP specifies something akin to "an implementation may recognize = additional reasons for considering a HELLO message invalid for = processing"; this I-D specifies such an additional reason, by way of a = TLV in HELLO messages. >=20 > =20 >=20 > 2) NHDP "owns" HELLO messages, and therefore gets first dip on an = incoming HELLO message post-demultiplication. Including the ICV Message = TLV in HELLO messages therefore makes sense. >=20 > =20 >=20 > Ad 1), I note that this I-D is intended to exactly plug in at that = place in 6130. >=20 > =20 >=20 > Thomas >=20 > =20 >=20 > --=20 >=20 > Thomas Heide Clausen >=20 > http://www.thomasclausen.org/ >=20 >=20 >=20 >=20 >=20 > "Any simple problem can be made insoluble if enough meetings are held = to >=20 > discuss it." >=20 > -- Mitchell's Law of Committees >=20 > =20 >=20 >=20 > On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: >=20 > The document specifies signing/verifying NHDP messages. RFC5444 = packets are not specific to NHDP, and therefore should IMO not be = discussed in a document entitled "Using Integrity Check Values and = Timestamps For Router Admittance in NHDP". That's why I suggested to = handle this in an additional document for RFC5444 packets. >=20 > Regards > Ulrich >=20 > On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun = wrote: >=20 > Hi Ulrich, >=20 > I am not expert in security issues, but IMHO, I agree with Chris to > recommend to include in draft-02 both securing messages and packets > (in general for packets), so the document should specify NHDP messages > and MANET packets [AB]. The reasons are first, because NHDP is a MANET > Interface protocol between neighbor routers. secondly it uses RFC5444 > format that the future MANET routers will use. Third, NHDP uses > RFC5444 which was specified for information exchange between MANET > routers. >=20 > [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt >=20 > Regards > Abdussalam > =3D=3D=3D=3D=3D=3D=3D >=20 >=20 > On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg wrote: > > Dear Chris, > > > > I agree that we need to provide similar mechanisms as in NHDP-sec = for TC > > messages as well. I don't think that signing the packet is enough, = since > > that does not provide end-to-end security. Instead, I suggest to = submit a > > draft OLSRv2-sec that specifies how to calculate ICVs for TC = messages, and > > how to handle these messages in OLSRv2. > > > > However, I believe that it would be beneficial for certain = applications to > > also be able to sign/verify packets. But I don't think that the = NHDP-sec > > document is the right place for this, since other applications (e.g. = DYMO) > > may not use HELLO messages at all, but would still like to = sign/verify > > packets. > > Maybe it would be better to have an extra document "packet-sec" = which > > specifies how to sign/verify packets? > > > > Best > > Ulrich > > > > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) >=20 > > wrote: > >> > >> (Sending again, to sort out the formatting problem with the last = attempt.) > >> > >> As I read it, this draft is proposing using the RFC 6622 mechanism = to sign > >> HELLO messages. RFC 6622 actually allows for signing packets as = well as > >> signing messages (both, either, or neither to be used as required). = There > >> isn't a major difference when considering HELLO messages, as few if = any > >> packets will contain more than one HELLO message, and the packet = and the > >> message will be signed by the same party. > >> > >> However NHDP doesn't exist in a vacuum, in particular it is used by > >> OLSRv2. Any security mechanism that is described in what will be an = RFC for > >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 = also has > >> TC messages to consider, and they don't satisfy the points noted = above (on > >> number or on who signs them). And one option for OLSRv2 is to sign = all > >> packets, not messages. This can be a sensible decision there, for = several > >> reasons, in some real circumstances. > >> > >> Consequently, I don't believe that this draft should describe only = signing > >> HELLO messages as the correct thing to do, that it should also = allow signing > >> packets as an equal status option. If someone wants to raise the = possibility > >> of signing (possibly by methods with different properties) both at = the > >> message and packet level, that may have its use cases too. > >> > >> Incidentally, even within the limited framework of just NHDP, it is > >> possible that packets need protection. If an NHDP implementation = chooses to > >> use packet sequence number as part of its link quality mechanism, = as it may, > >> then an unprotected packet header is a vulnerability. > >> > >> (For the sake of completeness, RFC 6622 also allows address block > >> signatures. I don't have a reason to suggest using this within NHDP = or > >> OLSRv2.) > >> > >> -- > >> 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 >=20 > >> chris.dearlove at 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 > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Mobile Ad-hoc = Networks Working > >> Group of the IETF. > >> > >> Title : Using Integrity Check Values and = Timestamps For > >> Router Admittance in NHDP > >> Author(s) : Ulrich Herberg > >> Thomas Heide Clausen > >> Filename : draft-ietf-manet-nhdp-sec-02.txt > >> Pages : 12 > >> Date : 2012-05-29 > >> > >> This document specifies a security extension to the MANET > >> Neighborhood Discovery Protocol (NHDP). The extension = introduces the > >> use of Integrity Check Values (ICVs) and Timestamps in HELLO = messages > >> in order to provide a router admittance mechanism, and therefore = to > >> counter 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-02.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-02.txt > >> > >> The IETF datatracker page for this Internet-Draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ > >> > >> _______________________________________________ > >> manet mailing list >=20 > >> manet at ietf.org >=20 > >> 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 > _______________________________________________ > 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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_1919A322-AD99-4958-9724-BEA24C2664F1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I provided feedback to authors before: I strongly prefer having a document on MANET packet security before we go into further details, such as manet-nhdp-sec. Another concern is that NHDP messages are extended by other protocols.

Teco


Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven:

Chris,

On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) <Chris.Dearlove@baesystems.com> wrote:

This partly depends on what your planned document structure is, Ulrich just mentioned the possibility of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these things.


My concern is, if you want to specify packet signing in the NHDP-sec document, that NHDP itself would never see the packet. The RFC5444 multiplexing would see a HELLO message in the packet and send it to NHDP (which can use the mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is tied to the RFC5444 parser itself, which would accept or reject the whole packet. So in my view, it would actually be much easier to separate it into an additional draft, rather than combining it with NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably like to use packet ICV verification as well, but they don't need all the NHDP part.

 

 

But I think this is jumping in with solutions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a signature method that's cryptographically infeasible to break. Then in this case (not uniquely) packet signatures actually provide as much security as message signatures.


If you assume a transitive trust model. If a router receives a TC message (unsigned) in a correctly signed packet, the receiving router can be sure that the TC has not been modified after transmission by the previous hop. It has no information what happened before that. But I agree that for certain deployments that may be enough.
 

Of course I can also think of threat models that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because different threats require different solutions.


Right. I am absolutely in favor of specifying packet ICV handling. The only question for me is where to do that.
 

The same is true of packet and message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other


Correct.
 

except following a security analysis - which is not on offer.


Yes. There was some emails about the nhdp-sec-threats document by Jiazi several months ago, but there was not much activity on the mailing list.. Do you think that that document should contain such an analysis?

Best regards
Ulrich
 

 

--

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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet


Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

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

Chris,

 

I figured that you wouldn't agree.

 

I agree, of course, with your observation that none of the signature models yields end-to-end security, but I don't think that that's the issue here. 

 

Personally, I do not see packet ICVs as being appropriate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am not saying that they do not exist. I could make an argument that a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP instance, and that the validation might be based on different principles (or, even layers) for packet/messages. 

 

I see what you say about protecting packet sequence numbers by way of a packet-level ICV, but I would argue that:

 

            o          As packet sequence numbers are generated "outside" NHDP, and are incremented for all 

                        packets (not just those with HELLOs), specifying the validation of a packet-level ICV in NHDP would

                        be inappropriate (as in: potentially conflicting with another mechanism)

 

            o          Whatever mechanism would provide "packet sequence number statistics" to NHDP (such as the

                        demultiplexer) would want to be the entity doing that packet-level ICV validation, in part as

                        I would _suspect_ that inability to validate a packet-level ICV should cause the whole packet

                        with all contained messages to be dropped.

 

That said, with reference to the I-D, I think I speak for the authors when saying that we're welcoming a suggestion that would address the issue that you raise?

 

Best,

 

Thomas

 

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:



I don't agree. Note that if all you are running is NHDP, then signing packets is more secure than signing messages, as you get to cover the packet sequence number as well.

What I think is wrong is to suggest that the only correct way to protect NHDP is to sign HELLO messages. Whether by inclusion or external reference, signing packets should be also an option.

 

I'll take that further to OLSrv2 as well. Now there signing messages vs signing packets has advantages to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct to say that signing TC messages provides end to end security. It's actually last-bit-one-from-end to end, and still relies on a form of transitive trust. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat models and vulnerabilities, and that may matter, but it's not (unfortunately) as simple as one being end to end and thus avoiding transitivity issues.

 

--

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: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 12 July 2012 23:09
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

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

I agree with Ulrich. 

 

Note that this is all about "messages" in as much as NHDP is concerned.

 

1) NHDP specifies something akin to "an implementation may recognize additional reasons for considering a HELLO message invalid for processing"; this I-D specifies such an additional reason, by way of a TLV in HELLO messages.

 

2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming HELLO message post-demultiplication. Including the ICV Message TLV in HELLO messages therefore makes sense.

 

Ad 1), I note that this I-D is intended to exactly plug in at that place in 6130.

 

Thomas

 

-- 

Thomas Heide Clausen




"Any simple problem can be made insoluble if enough meetings are held to

 discuss it."

   -- Mitchell's Law of Committees

 


On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:

The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets.

Regards
Ulrich

On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

Regards
Abdussalam
=======


On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for TC
> messages as well. I don't think that signing the packet is enough, since
> that does not provide end-to-end security. Instead, I suggest to submit a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain applications to
> also be able to sign/verify packets. But I don't think that the NHDP-sec
> document is the right place for this, since other applications (e.g. DYMO)
> may not use HELLO messages at all, but would still like to sign/verify
> packets.
> Maybe it would be better to have an extra document "packet-sec" which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)

> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last attempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as well as
>> signing messages (both, either, or neither to be used as required). There
>> isn't a major difference when considering HELLO messages, as few if any
>> packets will contain more than one HELLO message, and the packet and the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used by
>> OLSRv2. Any security mechanism that is described in what will be an RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has
>> TC messages to consider, and they don't satisfy the points noted above (on
>> number or on who signs them). And one option for OLSRv2 is to sign all
>> packets, not messages. This can be a sensible decision there, for several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only signing
>> HELLO messages as the correct thing to do, that it should also allow signing
>> packets as an equal status option. If someone wants to raise the possibility
>> of signing (possibly by methods with different properties) both at the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it is
>> possible that packets need protection. If an NHDP implementation chooses to
>> use packet sequence number as part of its link quality mechanism, as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block
>> signatures. I don't have a reason to suggest using this within NHDP or
>> OLSRv2.)
>>
>> --
>> 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

>>
>> 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
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Mobile Ad-hoc Networks Working
>> Group of the IETF.
>>
>>         Title           : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulrich Herberg
>>                           Thomas Heide Clausen
>>         Filename        : draft-ietf-manet-nhdp-sec-02.txt
>>         Pages           : 12
>>         Date            : 2012-05-29
>>
>>    This document specifies a security extension to the MANET
>>    Neighborhood Discovery Protocol (NHDP).  The extension introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps in HELLO messages
>>    in order to provide a router admittance mechanism, and therefore to
>>    counter 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-02.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-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list

>> manet at ietf.org

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

 

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

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

 


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

--Apple-Mail=_1919A322-AD99-4958-9724-BEA24C2664F1-- From rick.taylor@cassidian.com Tue Jul 31 02:49: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 29ABB21F869E for ; Tue, 31 Jul 2012 02:49:32 -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.299, 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 BEx1Pkzei8BJ for ; Tue, 31 Jul 2012 02:49:29 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id E36FB21F867F for ; Tue, 31 Jul 2012 02:49:27 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 31 Jul 2012 11:49:26 +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, 31 Jul 2012 11:49:25 +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, 31 Jul 2012 11:49:25 +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, 31 Jul 2012 11:49:25 +0200 Received: from SUKNPT8106.cogent-dsn.local ([10.80.1.216]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 10:49:00 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6F01.B670202D" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 31 Jul 2012 10:49:25 +0100 Message-ID: <7B31B0093014224A843C10C0CCE92AC1047A1177@SUKNPT8106.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: Ac1u4dXptnHtv0uSSCetfmX2DhKi2AAH5zWQ References: <84F14E53-CA1A-4ED7-B2BF-810516A78069@thomasclausen.org> From: "Rick Taylor" To: "Teco Boot" , "Ulrich Herberg" X-OriginalArrivalTime: 31 Jul 2012 09:49:00.0906 (UTC) FILETIME=[B660CCA0:01CD6F01] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19074.005 X-TM-AS-Result: No--42.295800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Dearlove, Christopher \(UK\)" , manet , Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 09:49:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6F01.B670202D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of us who missed the relevant parts of the mailing discussion, what was the consensus on general ICV verification for RFC5444 packets? =20 I am with Teco, a separate manet-rfc5444-sec document would be very useful. =20 Rick Taylor ________________________________ From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot Sent: 31 July 2012 07:00 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt =20 I provided feedback to authors before: I strongly prefer having a document on MANET packet security before we go into further details, such as manet-nhdp-sec. Another concern is that NHDP messages are extended by other protocols. =20 Teco =20 =20 Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven: Chris, On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) wrote: This partly depends on what your planned document structure is, Ulrich just mentioned the possibility of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these things. My concern is, if you want to specify packet signing in the NHDP-sec document, that NHDP itself would never see the packet. The RFC5444 multiplexing would see a HELLO message in the packet and send it to NHDP (which can use the mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is tied to the RFC5444 parser itself, which would accept or reject the whole packet. So in my view, it would actually be much easier to separate it into an additional draft, rather than combining it with NHDP.=20 Moreover, protocols that do not use NHDP but use RFC5444 would probably like to use packet ICV verification as well, but they don't need all the NHDP part. =20 =20 But I think this is jumping in with solutions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof storage, (b) doesn't make mistakes, and (c) we use a signature method that's cryptographically infeasible to break. Then in this case (not uniquely) packet signatures actually provide as much security as message signatures.=20 If you assume a transitive trust model. If a router receives a TC message (unsigned) in a correctly signed packet, the receiving router can be sure that the TC has not been modified after transmission by the previous hop. It has no information what happened before that. But I agree that for certain deployments that may be enough. =20 Of course I can also think of threat models that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because different threats require different solutions.=20 Right. I am absolutely in favor of specifying packet ICV handling. The only question for me is where to do that. =20 The same is true of packet and message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other Correct. =20 except following a security analysis - which is not on offer. Yes. There was some emails about the nhdp-sec-threats document by Jiazi several months ago, but there was not much activity on the mailing list.. Do you think that that document should contain such an analysis? Best regards Ulrich =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 =20 chris.dearlove@baesystems.com | http://www.baesystems.com =20 =09 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 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 13 July 2012 13:36 To: Dearlove, Christopher (UK) Cc: Ulrich Herberg; manet =09 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt =20 =20 =20 *** 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. Chris, =20 I figured that you wouldn't agree. =20 I agree, of course, with your observation that none of the signature models yields end-to-end security, but I don't think that that's the issue here.=20 =20 Personally, I do not see packet ICVs as being appropriate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am not saying that they do not exist. I could make an argument that a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP instance, and that the validation might be based on different principles (or, even layers) for packet/messages.=20 =20 I see what you say about protecting packet sequence numbers by way of a packet-level ICV, but I would argue that: =20 o As packet sequence numbers are generated "outside" NHDP, and are incremented for all=20 packets (not just those with HELLOs), specifying the validation of a packet-level ICV in NHDP would be inappropriate (as in: potentially conflicting with another mechanism) =20 o Whatever mechanism would provide "packet sequence number statistics" to NHDP (such as the demultiplexer) would want to be the entity doing that packet-level ICV validation, in part as I would _suspect_ that inability to validate a packet-level ICV should cause the whole packet with all contained messages to be dropped. =20 That said, with reference to the I-D, I think I speak for the authors when saying that we're welcoming a suggestion that would address the issue that you raise? =20 Best, =20 Thomas =20 On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote: =20 I don't agree. Note that if all you are running is NHDP, then signing packets is more secure than signing messages, as you get to cover the packet sequence number as well. What I think is wrong is to suggest that the only correct way to protect NHDP is to sign HELLO messages. Whether by inclusion or external reference, signing packets should be also an option. =20 I'll take that further to OLSrv2 as well. Now there signing messages vs signing packets has advantages to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct to say that signing TC messages provides end to end security. It's actually last-bit-one-from-end to end, and still relies on a form of transitive trust. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat models and vulnerabilities, and that may matter, but it's not (unfortunately) as simple as one being end to end and thus avoiding transitivity issues. =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 =20 chris.dearlove@baesystems.com | http://www.baesystems.com =20 =09 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 From: Thomas Heide Clausen [mailto:thomas@thomasclausen.org]=20 Sent: 12 July 2012 23:09 To: Ulrich Herberg Cc: Dearlove, Christopher (UK); manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt =20 =20 *** 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. I agree with Ulrich.=20 =20 Note that this is all about "messages" in as much as NHDP is concerned. =20 1) NHDP specifies something akin to "an implementation may recognize additional reasons for considering a HELLO message invalid for processing"; this I-D specifies such an additional reason, by way of a TLV in HELLO messages. =20 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming HELLO message post-demultiplication. Including the ICV Message TLV in HELLO messages therefore makes sense. =20 Ad 1), I note that this I-D is intended to exactly plug in at that place in 6130. =20 Thomas =20 --=20 Thomas Heide Clausen http://www.thomasclausen.org/ =09 =09 =09 "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees =20 =09 On 12 Jul 2012, at 22:54, Ulrich Herberg wrote: The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets. =09 Regards Ulrich On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun wrote: Hi Ulrich, =09 I am not expert in security issues, but IMHO, I agree with Chris to recommend to include in draft-02 both securing messages and packets (in general for packets), so the document should specify NHDP messages and MANET packets [AB]. The reasons are first, because NHDP is a MANET Interface protocol between neighbor routers. secondly it uses RFC5444 format that the future MANET routers will use. Third, NHDP uses RFC5444 which was specified for information exchange between MANET routers. =09 [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt =09 Regards Abdussalam =3D=3D=3D=3D=3D=3D=3D =09 On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg > wrote: > Dear Chris, > > I agree that we need to provide similar mechanisms as in NHDP-sec for TC > messages as well. I don't think that signing the packet is enough, since > that does not provide end-to-end security. Instead, I suggest to submit a > draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and > how to handle these messages in OLSRv2. > > However, I believe that it would be beneficial for certain applications to > also be able to sign/verify packets. But I don't think that the NHDP-sec > document is the right place for this, since other applications (e.g. DYMO) > may not use HELLO messages at all, but would still like to sign/verify > packets. > Maybe it would be better to have an extra document "packet-sec" which > specifies how to sign/verify packets? > > Best > Ulrich > > > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK) > > wrote: >> >> (Sending again, to sort out the formatting problem with the last attempt.) >> >> As I read it, this draft is proposing using the RFC 6622 mechanism to sign >> HELLO messages. RFC 6622 actually allows for signing packets as well as >> signing messages (both, either, or neither to be used as required). There >> isn't a major difference when considering HELLO messages, as few if any >> packets will contain more than one HELLO message, and the packet and the >> message will be signed by the same party. >> >> However NHDP doesn't exist in a vacuum, in particular it is used by >> OLSRv2. Any security mechanism that is described in what will be an RFC for >> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has >> TC messages to consider, and they don't satisfy the points noted above (on >> number or on who signs them). And one option for OLSRv2 is to sign all >> packets, not messages. This can be a sensible decision there, for several >> reasons, in some real circumstances. >> >> Consequently, I don't believe that this draft should describe only signing >> HELLO messages as the correct thing to do, that it should also allow signing >> packets as an equal status option. If someone wants to raise the possibility >> of signing (possibly by methods with different properties) both at the >> message and packet level, that may have its use cases too. >> >> Incidentally, even within the limited framework of just NHDP, it is >> possible that packets need protection. If an NHDP implementation chooses to >> use packet sequence number as part of its link quality mechanism, as it may, >> then an unprotected packet header is a vulnerability. >> >> (For the sake of completeness, RFC 6622 also allows address block >> signatures. I don't have a reason to suggest using this within NHDP or >> OLSRv2.) >> >> -- >> 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 =20 >> chris.dearlove at 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 >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobile Ad-hoc Networks Working >> Group of the IETF. >> >> Title : Using Integrity Check Values and Timestamps For >> Router Admittance in NHDP >> Author(s) : Ulrich Herberg >> Thomas Heide Clausen >> Filename : draft-ietf-manet-nhdp-sec-02.txt >> Pages : 12 >> Date : 2012-05-29 >> >> This document specifies a security extension to the MANET >> Neighborhood Discovery Protocol (NHDP). The extension introduces the >> use of Integrity Check Values (ICVs) and Timestamps in HELLO messages >> in order to provide a router admittance mechanism, and therefore to >> counter 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-02.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-02.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ >> >> _______________________________________________ >> manet mailing list >> manet at ietf.org =20 >> 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 _______________________________________________ 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 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet =20 ------_=_NextPart_001_01CD6F01.B670202D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those of us who missed the = relevant parts of the mailing discussion, what was the consensus on general ICV = verification for RFC5444 packets?

 

I am with Teco, a separate = manet-rfc5444-sec document would be very useful.

 

Rick Taylor

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot
Sent: 31 July 2012 = 07:00
To: Ulrich Herberg
Cc: Dearlove, Christopher = (UK); manet; Thomas Heide Clausen
Subject: Re: [manet] I-D = Action: draft-ietf-manet-nhdp-sec-02.txt

 

I provided feedback to authors before: I strongly prefer having = a document on MANET packet security before we go into further details, = such as manet-nhdp-sec. Another concern is that NHDP messages are = extended by other protocols.

 

Teco

 

 

Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende = geschreven:



Chris,

On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) = <Chris.Dearlove@baesystems.com> wrote:

This partly depends on what your planned document structure is, Ulrich just mentioned the possibility of a generic 5444 = document. I'm actually not sure that wouldn't be more relevant, as it is hard to = actually separate these things.


My concern is, if you want to specify packet signing in the NHDP-sec = document, that NHDP itself would never see the packet. The RFC5444 multiplexing = would see a HELLO message in the packet and send it to NHDP (which can use the = mechanisms specified in NHDP-sec to reject or accept the message). I think that a = packet signer/verifier is tied to the RFC5444 parser itself, which would accept = or reject the whole packet. So in my view, it would actually be much easier = to separate it into an additional draft, rather than combining it with = NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably = like to use packet ICV verification as well, but they don't need all the NHDP = part.

 

 

But I think this is jumping in with solutions = before considering a threat model. Let's suppose that we have hardware that (a) = stores key materials in secure tamperproof storage,  (b) doesn't make = mistakes, and (c) we use a signature method that's cryptographically infeasible to = break. Then in this case (not uniquely) packet signatures actually provide as = much security as message signatures.


If you assume a transitive trust model. If a router receives a TC = message (unsigned) in a correctly signed packet, the receiving router can be = sure that the TC has not been modified after transmission by the previous hop. It = has no information what happened before that. But I agree that for certain = deployments that may be enough.
 

Of course I can also think of threat models that = do favour message signatures. But this is exactly like the choice of = signature methods, which is not mandated because different threats require = different solutions.


Right. I am absolutely in favor of specifying packet ICV handling. The = only question for me is where to do that.
 

The same is true of packet and message = signatures. Each (and indeed the third option of both) should be allowed, we should not = have a document that prefers one above the other


Correct.
 

except following a security analysis - which is = not on offer.


Yes. There was some emails about the nhdp-sec-threats document by Jiazi = several months ago, but there was not much activity on the mailing list.. Do you = think that that document should contain such an analysis?

Best regards
Ulrich
 

 

--

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: Thomas Heide = Clausen [mailto:thomas@thomasclausen.org]
Sent: 13 July 2012 = 13:36
To: Dearlove, Christopher = (UK)
Cc: Ulrich Herberg; = manet


Subject: Re: [manet] I-D = Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

 

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

Chris,

 

I = figured that you wouldn't agree.

 

I = agree, of course, with your observation that none of the signature models yields end-to-end security, but I don't think that that's the issue = here. 

 

Personally, I do not see packet ICVs as being appropriate for neither NHDP nor OLSRv2 - = at least, not for the uses that I see/have, but I am not saying that they = do not exist. I could make an argument that a packet ICV would have to be = validated before knowing that a HELLO message was delivered to an NHDP instance, = and that the validation might be based on different principles (or, even layers) = for packet/messages. 

 

I see = what you say about protecting packet sequence numbers by way of a packet-level ICV, = but I would argue that:

 

       &nbs= p;    o          As packet = sequence numbers are generated "outside" NHDP, and are incremented for all 

       &nbs= p;            = ;    packets (not just those with HELLOs), specifying the validation of a packet-level ICV in NHDP would

       &nbs= p;            = ;    be inappropriate (as in: potentially conflicting with another = mechanism)

 

       &nbs= p;    o          Whatever = mechanism would provide "packet sequence number statistics" to NHDP = (such as the

       &nbs= p;            = ;    demultiplexer) would want to be the entity doing that packet-level ICV validation, in part as

       &nbs= p;            = ;    I would _suspect_ that inability to validate a packet-level ICV should = cause the whole packet

       &nbs= p;            = ;    with all contained messages to be dropped.

 

That = said, with reference to the I-D, I think I speak for the authors when saying that = we're welcoming a suggestion that would address the issue that you = raise?

 

Best,

 

Thomas

 

On = Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) = wrote:

 

I don't agree. Note that if all you are running = is NHDP, then signing packets is more secure than signing messages, as you get to = cover the packet sequence number as well.

What I think is wrong is to suggest that the only correct way to protect NHDP is to sign HELLO messages. Whether by = inclusion or external reference, signing packets should be also an = option.

 

I'll take that further to OLSrv2 as well. Now = there signing messages vs signing packets has advantages to the former. But = signing packets also has advantages of simplicity and covering packet header. It = is incidentally not correct to say that signing TC messages provides end to = end security. It's actually last-bit-one-from-end to end, and still relies = on a form of transitive trust. Packet based signatures rely on a greater = degree of transitive trust. There is a difference in threat models and = vulnerabilities, and that may matter, but it's not (unfortunately) as simple as one being = end to end and thus avoiding transitivity issues.

 

--

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: Thomas = Heide Clausen [mailto:thomas@thomasclausen.org] 
Sent: 12 July 2012 = 23:09
To: Ulrich = Herberg
Cc: Dearlove, = Christopher (UK); manet
Subject: Re: [manet] = I-D Action: draft-ietf-manet-nhdp-sec-02.txt

 

 

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

I = agree with Ulrich. 

 

Note = that this is all about "messages" in as much as NHDP is = concerned.

 

1) = NHDP specifies something akin to "an implementation may recognize additional = reasons for considering a HELLO message invalid for processing"; this I-D = specifies such an additional reason, by way of a TLV in HELLO = messages.

 

2) = NHDP "owns" HELLO messages, and therefore gets first dip on an = incoming HELLO message post-demultiplication. Including the ICV Message TLV in = HELLO messages therefore makes sense.

 

Ad = 1), I note that this I-D is intended to exactly plug in at that place in = 6130.

 

Thomas

 

-- 

Thomas Heide Clausen



"Any simple problem can be made insoluble if enough meetings are held = to

 discuss it."

   -- Mitchell's Law of Committees

 


On 12 Jul 2012, at 22:54, Ulrich Herberg <ulrich@herberg.name> wrote:

The = document specifies signing/verifying NHDP messages. RFC5444 packets are not = specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance = in NHDP". That's why I suggested to handle this in an additional = document for RFC5444 packets.

Regards
Ulrich

On = Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi = Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP = messages
and MANET packets [AB]. The reasons are first, because NHDP is a = MANET
Interface protocol between neighbor routers. secondly it uses = RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminology= -00.txt

Regards
Abdussalam
=3D=3D=3D=3D=3D=3D=3D


On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> = wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec = for TC
> messages as well. I don't think that signing the packet is enough, = since
> that does not provide end-to-end security. Instead, I suggest to = submit a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC = messages, and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain = applications to
> also be able to sign/verify packets. But I don't think that the = NHDP-sec
> document is the right place for this, since other applications = (e.g. DYMO)
> may not use HELLO messages at all, but would still like to = sign/verify
> packets.
> Maybe it would be better to have an extra document = "packet-sec" which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher = (UK)=

> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the = last attempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 = mechanism to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as = well as
>> signing messages (both, either, or neither to be used as = required). There
>> isn't a major difference when considering HELLO messages, as = few if any
>> packets will contain more than one HELLO message, and the = packet and the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is = used by
>> OLSRv2. Any security mechanism that is described in what will = be an RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. = OLSRv2 also has
>> TC messages to consider, and they don't satisfy the points = noted above (on
>> number or on who signs them). And one option for OLSRv2 is to = sign all
>> packets, not messages. This can be a sensible decision there, = for several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe = only signing
>> HELLO messages as the correct thing to do, that it should also = allow signing
>> packets as an equal status option. If someone wants to raise = the possibility
>> of signing (possibly by methods with different properties) both = at the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, = it is
>> possible that packets need protection. If an NHDP = implementation chooses to
>> use packet sequence number as part of its link quality = mechanism, as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address = block
>> signatures. I don't have a reason to suggest using this within = NHDP or
>> OLSRv2.)
>>
>> --
>> 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<= /p>

>>
>> 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
>>
>>
>> A New Internet-Draft is available from the on-line = Internet-Drafts
>> directories. This draft is a work item of the Mobile Ad-hoc Networks Working
>> Group of the IETF.
>>
>>         Title         =   : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : = Ulrich Herberg
>>                   =         Thomas Heide Clausen
>>         Filename       =  : draft-ietf-manet-nhdp-sec-02.txt
>>         Pages         =   : 12
>>         Date         =    : 2012-05-29
>>
>>    This document specifies a security extension to = the MANET
>>    Neighborhood Discovery Protocol (NHDP).  The extension introduces the
>>    use of Integrity Check Values (ICVs) and = Timestamps in HELLO messages
>>    in order to provide a router admittance mechanism, = and therefore to
>>    counter a selection of security threats to = NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nh= dp-sec-02.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-nhd= p-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-= sec/
>>
>> _______________________________________________
>> manet mailing list

>> manet at ietf.org

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

 

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

________________________= _______________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet<= /font>

 


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

 

------_=_NextPart_001_01CD6F01.B670202D-- From abdussalambaryun@gmail.com Tue Jul 31 06:46: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 218B121F86DE for ; Tue, 31 Jul 2012 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 FNG+sFw1TrLg for ; Tue, 31 Jul 2012 06:45:59 -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 5C83021F86DC for ; Tue, 31 Jul 2012 06:45:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6242914vbb.31 for ; Tue, 31 Jul 2012 06:45: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=DkoCIKw/iwwndoFeBkO84ccCnHffxBTMQ+Ja3aSEdak=; b=ALtJnvj2M9ecjfvOW1zcXJ9ulvdbOL+8ZQNmihZCBUy3HRsbMhIv75504UebyE65oR YXd1qgqe4zBcZrT1HT5lBHqGhUjqb5tcCF6EUukRxohiBfQUjF+XYu8/9Z173YSsuU4o FlokC1pHyGrxgBUrygKzdcuVu9Xi3MrvJghpvpT+HrGk3rHVTo5kQ5k81XRhFrL+RAxS godcFRarco3CTiz+slad+q6XQ77Uk+OeAGA6taKiGTBzSHF5VLOfWhN6lUpaZg60xNvv LmYeaY/lW+1o0nE2QSCZG/++FuUrLUUMhJva8cXlmRn2TyzTIe039flUwXVu4I4qvdAC Qkqg== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr12608444vdb.10.1343742358766; Tue, 31 Jul 2012 06:45:58 -0700 (PDT) Received: by 10.220.141.200 with HTTP; Tue, 31 Jul 2012 06:45:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 15:45:58 +0200 Message-ID: From: Abdussalam Baryun To: ietf@thomasclausen.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 13:46:00 -0000 Hi Thomas and All I am interested in LOADng and did discuss about it from May 2012 until now. I gave comments [1] on LOADng but no respond so far, I asked from before for more discussion but there was no, and hope that we don't forget the past comments on any document in ietf. The LOADng SHOULD specify use case that are related to MANET not LLN. I suggest that the word LLN taken out of the name as well and specify mobility [1-2]. IMHO this protocol was intended as for ROLL WG not for MANET WG, but then changed its direction to MANET [3]. However, please note that *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That said, LOADng SHOULD specfy where is its limits. Then we can discuss adoption. [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html thanking you, AB =========== On 7/4/12, Abdussalam Baryun wrote: > Hi Thomas, > >>Just for information, the coming version of LOADng will use 5444 >> (cleanly). > > but last draft: does not use RFC5444 > > I am interested to know about the LOADng, while you requested its > consideration in MANET, but we still not much discussed the status of > the work, as now some participant and I thought that LOADng didn't use > RFC5444. Please give us some input of updated issues. As was waiting > for the new version which was expected within June as per one > co-author discussion. Thanking you, > > Best Regards > Abdussalam Baryun > =============== > > To: "Dearlove, Christopher (UK)" > Subject: Re: [manet] Status of DLEP-draft at Cisco? > From: Thomas Heide Clausen > > Just for information, the coming version of LOADng will use 5444 (cleanly). > > > -- > Thomas Heide Clausen > http://www.thomasclausen.org > ================================================ >>Abdussalam, > >>we are aware that the LOADng draft needs some updates, before it could > be considered by the MANET WG, notably support for RFC5444 and some > editorial updates. We plan to work on these in the next days, and will > submit a new revision likely next week. So, just stay tuned! > >>Best >>Ulrich > > On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > wrote: >> On 5/29/12, JP Vasseur wrote: >>> >>> We already have two different WG: MANET and ROLL. >>> >> >> Yes we know. That is why LOADng authors should choose either to serve >> LLN that is considered by ROLL WG or they choose serving MANET, and it >> is considered by MANET WG. But the question is which suggestion option >> do you think is better for LOADng-draft? >> >>>MANET is tasked, amongst other, to publish a reactive >>>routing protocol. >> >> MANET is tasked to publish routing protocols that serve the MANET >> network. IMO, MANET-WG is not tasked to publish protocols serving only >> LLN just because the protocol is reactive. Please note that LOADng >> protocol does not even mention MANET nor mobile routers in its draft, >> which confuses its purpose, the authors should look into that. >> >> Abdussalam Baryun > From john.dowdell@cassidian.com Tue Jul 31 06:48: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 9C0CC21F86E2 for ; Tue, 31 Jul 2012 06:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 oEaLdzvN5N8s for ; Tue, 31 Jul 2012 06:48:41 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC2621F86DE for ; Tue, 31 Jul 2012 06:48:02 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 31 Jul 2012 15:39: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); Tue, 31 Jul 2012 15:39:02 +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, 31 Jul 2012 15:39: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, 31 Jul 2012 15:39:02 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6F21.CA72923B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 31 Jul 2012 14:39:03 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01962FAE@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP-sec-threats feedback Thread-Index: Ac1usNLkus7wchG2Tjy4EzRjjSpCuQAbh17Q References: From: "John Dowdell" To: X-OriginalArrivalTime: 31 Jul 2012 13:39:02.0340 (UTC) FILETIME=[D8AC8040:01CD6F21] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19074.007 X-TM-AS-Result: No--21.537200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 13:48:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6F21.CA72923B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on NHDP-sec-threats. =20 The quality of the implementation is outside of the scope of this document, but here will be some variables in how robustly the protocol has been implemented. A simple implementation will be considerably less robust than one with comprehensive error and failed state detection. Links with high bit error rates are particularly difficult to cater for, since implementations may simply crash when there are too many simultaneous error conditions. =20 However, some specifics relating to sequence numbers. =20 If the attacking node sent control packets with random sequence numbers, and the receiving node was expecting linearly increasing sequence numbers, would an implementation ignore packets sent with lower sequence numbers than the highest sequence number sent? An example: say a node was expecting to receive packets 1, 2, 3, 4, 5 and actually received packets 10, 15, 12, 7, 20, 11, then the receiver would process packets 10, 15 and 20 and discard 12, 7 and 11, but will waste processing time doing so. The implementation may decide on supplementary action if the sequence numbers are spread so far apart, as that may give the illusion that this link has a higher packet loss than is actually the case. =20 John ________________________________ From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Joseph Macker Sent: 31 July 2012 01:09 To: manet@ietf.org Subject: [manet] NHDP-sec-threats feedback =20 I apologize to Jiazi and co-authors as we accidentally skipped one of the slide sets at this afternoon's meeting. Please review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda and see draft-ietf-manet-nhdp-sec-threats-00 The authors are asking for consideration of WG LAST CALL on this document so please comment. -Joe ------_=_NextPart_001_01CD6F21.CA72923B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some comments on = NHDP-sec-threats.

 

The quality of the implementation = is outside of the scope of this document, but here will be some variables in how = robustly the protocol has been implemented. A simple implementation will be = considerably less robust than one with comprehensive error and failed state = detection. Links with high bit error rates are particularly difficult to cater for, since implementations may simply crash when there are too many simultaneous = error conditions.

 

However, some specifics relating to sequence numbers.

 

If the attacking node sent control = packets with random sequence numbers, and the receiving node was expecting = linearly increasing sequence numbers, would an implementation ignore packets sent = with lower sequence numbers than the highest sequence number sent? An = example: say a node was expecting to receive packets 1, 2, 3, 4, 5 and actually = received packets 10, 15, 12, 7, 20, 11, then the receiver would process packets 10, 15 = and 20 and discard 12, 7 and 11, but will waste processing time doing so. The = implementation may decide on supplementary action if the sequence numbers are spread so = far apart, as that may give the illusion that this link has a higher packet = loss than is actually the case.

 

John

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Joseph Macker
Sent: 31 July 2012 = 01:09
To: manet@ietf.org
Subject: [manet] = NHDP-sec-threats feedback

 

I apologize to Jiazi and co-authors as we accidentally skipped = one of the slide sets at this afternoon's meeting.

Please review the slides for NHDP-sec-threats located at http://tools.ietf.org/wg/manet/agenda
and see draft-ietf-manet-nhdp-sec-threats-00

The authors are asking for consideration of WG LAST CALL on this = document so please comment.

-Joe

------_=_NextPart_001_01CD6F21.CA72923B-- From hrogge@googlemail.com Tue Jul 31 06:49: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 4647E21F86EE for ; Tue, 31 Jul 2012 06:49:30 -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 K5rUijhs0VGg for ; Tue, 31 Jul 2012 06:49:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B105F21F86EB for ; Tue, 31 Jul 2012 06:49:29 -0700 (PDT) Received: by yhq56 with SMTP id 56so6544689yhq.31 for ; Tue, 31 Jul 2012 06:49:29 -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=IRB3ZF7i7+3fOpHVYaUb5W/RetEt4lHbZX8SGKKZics=; b=IelJyyEF56/WRHPhZCyOUfDZseuk5BDf51VjlMrrZQEqyNMrFx3mHsKIPpi1FiJJcn j0Jfce8Jq8DNi1afk/Vfps1mUlBBvm++iFDYUX/fqbPXrg6jaskry7QS3XC6MROdFVjE Rm8O8T9fQsP0grwrgg8q9RSN+9dJ3ktkTj27LX8ZxJp8xm/zDlBJzIa8Nwd+fKsLZO4i ugLfAcMEeJvtEUCVc9+xjJr/1pUlZMQkrSCfzpOw09AdgGvev8dVR/V6QcApPRh56oLt 7XpzdlaSljuXYheJ8YwOOfB5znQ5epE9N8KihJMTKQDp+pWwmjyyNMp/o/V4DcExlcaw Q1QQ== Received: by 10.66.78.42 with SMTP id y10mr32508249paw.31.1343742569077; Tue, 31 Jul 2012 06:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.241.131 with HTTP; Tue, 31 Jul 2012 06:49:08 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 31 Jul 2012 06:49:08 -0700 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 13:49:30 -0000 On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun wrote: > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. Could you state an example what would be considered a LLN but not a MANET. I normally consider LLNs a subset of what we call MANETs. 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 budden@nps.edu Tue Jul 31 09:30: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 C389B21F8616 for ; Tue, 31 Jul 2012 09:30:41 -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_35=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 Xv3OfycFFePt for ; Tue, 31 Jul 2012 09:30:41 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 05ECE21F8610 for ; Tue, 31 Jul 2012 09:30:40 -0700 (PDT) X-ASG-Debug-ID: 1343752240-036c920495427c80001-Rp4q3q Received: from skytrain.ern.nps.edu (skytrain.ern.nps.edu [172.20.24.112]) by mule.nps.edu with ESMTP id RjHoNxXVcvxFlgdE; Tue, 31 Jul 2012 09:30:40 -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, 31 Jul 2012 09:30:39 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] [its] Scenarios, potential topics... To: "A. Riley Eller" In-Reply-To: <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 31 Jul 2012 09:29:45 -0700 Message-ID: <1343752185.981.856.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: 1343752240 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=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104290 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 16:30:42 -0000 Riley, This has been kicking around in the emergency services broadband discussion. Most of the discussants are not long in understanding of protocol stacks... But they ARE long in experiencing 'the tower' going away and need to talk with 'that guy over there that I can see'. Qualcom only announced the study group news. This is not a product announcement or even a proposed standard. It appears that the alterations proposed would only affect layer 2 of the LTE protocol. Totally agnostic about anything above layer 2. This leaves two questions open: can it be done usefully and scaleably? and 2) what value is it? Speculating a bit on where the study group is going.... LTE and IEEE 802.16 use a hub&spoke structure (for that matter, so does WiFi). The LTE base station manages about four dozen MAC messages, the chief one is the UL-MAP (upload map in English) which tells each of the subscriber stations when it's that station's turn to transmit. The base station also negotiates entry for new subscribers -- ranging messages, X.509 cert exchange, etc. The processing load and the transmitting load on a base station is significantly higher than a subscriber station. Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the hardware for both BS and SS is identical, only the software load changes. My students have hauled .16 gear, both BS and SS, out into the field, plugged them in and gotten them to work (we know if you drop the antenna off the back of the truck that it will break). At the layer 3 interface, all the gear we've ever seen is doing ethernet forwarding so both SS and BS are passing ethernet frames out of the box, just like your cable modem at home. Cellphone implementations will tend to load additional functions (like beam steering) onto base stations to avoid having to do so with subscriber stations (which may be embedded in cellphone handsets). The key diff between BS and SS here is electrical power usage -- a BS will drain the battery a lot faster. So the first question to ask is what would be the study group's criteria? You can already make a subscriber station, with a new software load, act like a base station. If you have an adequate power supply (e.g. vehicle mount rather than handset), then we have this capability now and have had it for some years. What's new? The second question is what value this would be to emergency services (or ITS)? Simply putting up a layer 2 network segment only gets you layer 2 functionality -- all the rest of the applications are outside scope. DNS support? PKI white pages? SIP server? There's a lot left to do in a real-world usability exercise. On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: > > > While the working item is still a fair distance from realizing > > > standardization, I think it is worth mentioning that LTE Direct (a > > > peer-to-peer channel and symmetric transmission/reception mode) is > > > being proposed by Qualcomm. From my interviews with their technical > > > team, I am very excited about the possibility of mobile node to > > > mobile node direct LTE link. If any of you are also interested, it > > > might be good to check in on their progress and offer your comments. > > > > Certainly I (and a group of people locally) are interested in the use > > of LTE for direct communications. > > > > How would it be possible to check in on their progress and how could we > > offer our comments? > > > > Alex > > I am not an expert on the 3GPP process, so rather than muddle about and confuse things, I will include the following article which I hope will offer clues. I believe that the standards body has agreed to investigate whether a direct mode is worth standardizing (??). > > http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20110928/ > > My connection to this program came from direct industry contact, so I apologize for my obtuse response. > > Riley > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From okaytion@gmail.com Tue Jul 31 09:44: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 03CA921F86AA; Tue, 31 Jul 2012 09:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 pqcCARovsTJq; Tue, 31 Jul 2012 09:44:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF23021F869E; Tue, 31 Jul 2012 09:44:50 -0700 (PDT) Received: by qcac10 with SMTP id c10so4212687qca.31 for ; Tue, 31 Jul 2012 09:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=mlx/m0ghjIiVc7tN+zwcjYTlM4w6q4LFFbU0DqkYIrk=; b=aEIglCR9tCWOeXG4iA6pcaTtbRA8AL3EFZKhoggLlMCq9dN2Vh4P/gTyd8jM4dIbxX etXmVNqbse1bveuN+Z6dfGYdGeiADoYJsnCCMwRhlcuyYcfl8Txnv6z6Hbx2x0FhVQFT Go+yG0MI6TZh/T+oFLZbeowUVEzXJ1Cg2ihE/HInumm5aLkkQpNUB+vcLOGkbSuU2iFr 7+CuQkBhDs7GxZuk0Im+rZOkJmuvuCo7bwKkzPeTBPMAFDWM2f2Ygd4N5ky5VN6sMa3M u/kD7rsr5CsUiIaxX3LdqrR0lknB0Kwzc8zuymBjAtKBV4kiYGqTy/xaD1Ev3PO+C+1J wPXw== Received: by 10.224.176.69 with SMTP id bd5mr30567563qab.66.1343753090238; Tue, 31 Jul 2012 09:44:50 -0700 (PDT) Received: from [192.168.2.18] (fctnnbsc30w-156034228166.dhcp-dynamic.FibreOp.nb.bellaliant.net. [156.34.228.166]) by mx.google.com with ESMTPS id hi3sm655718qab.22.2012.07.31.09.44.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 09:44:49 -0700 (PDT) References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> In-Reply-To: <1343752185.981.856.camel@localhost.localdomain> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-AC77E4C9-E5AE-4BA5-B5EF-9540481D731A Message-Id: <5665224C-24CE-47CE-8555-870BDB8B20E1@gmail.com> X-Mailer: iPhone Mail (9A405) From: Okaytion Date: Tue, 31 Jul 2012 13:44:47 -0300 To: Rex Buddenberg Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 16:44:52 -0000 --Apple-Mail-AC77E4C9-E5AE-4BA5-B5EF-9540481D731A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Is any one here an expert in NS2 or knows someone who can help ?? Thanks Sent from Al's iPhone On 2012-07-31, at 1:29 PM, Rex Buddenberg wrote: >=20 > Riley, >=20 > This has been kicking around in the emergency services broadband > discussion. Most of the discussants are not long in understanding of > protocol stacks... But they ARE long in experiencing 'the tower' going > away and need to talk with 'that guy over there that I can see'. =20 >=20 > Qualcom only announced the study group news. This is not a product > announcement or even a proposed standard. >=20 > It appears that the alterations proposed would only affect layer 2 of > the LTE protocol. Totally agnostic about anything above layer 2. =20 >=20 > This leaves two questions open: can it be done usefully and scaleably? > and 2) what value is it? =20 >=20 >=20 > Speculating a bit on where the study group is going.... LTE and IEEE > 802.16 use a hub&spoke structure (for that matter, so does WiFi). The > LTE base station manages about four dozen MAC messages, the chief one is > the UL-MAP (upload map in English) which tells each of the subscriber > stations when it's that station's turn to transmit. The base station > also negotiates entry for new subscribers -- ranging messages, X.509 > cert exchange, etc. The processing load and the transmitting load on a > base station is significantly higher than a subscriber station. =20 >=20 > Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the > hardware for both BS and SS is identical, only the software load > changes. =20 >=20 > My students have hauled .16 gear, both BS and SS, out into the field, > plugged them in and gotten them to work (we know if you drop the antenna > off the back of the truck that it will break). At the layer 3 > interface, all the gear we've ever seen is doing ethernet forwarding so > both SS and BS are passing ethernet frames out of the box, just like > your cable modem at home. =20 >=20 > Cellphone implementations will tend to load additional functions (like > beam steering) onto base stations to avoid having to do so with > subscriber stations (which may be embedded in cellphone handsets). The > key diff between BS and SS here is electrical power usage -- a BS will > drain the battery a lot faster. =20 >=20 > So the first question to ask is what would be the study group's > criteria? You can already make a subscriber station, with a new > software load, act like a base station. If you have an adequate power > supply (e.g. vehicle mount rather than handset), then we have this > capability now and have had it for some years. What's new? =20 >=20 > The second question is what value this would be to emergency services > (or ITS)? Simply putting up a layer 2 network segment only gets you > layer 2 functionality -- all the rest of the applications are outside > scope. DNS support? PKI white pages? SIP server? There's a lot left > to do in a real-world usability exercise. =20 >=20 >=20 >=20 > On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>> While the working item is still a fair distance from realizing >>>> standardization, I think it is worth mentioning that LTE Direct (a >>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>> being proposed by Qualcomm. =46rom my interviews with their technical >>>> team, I am very excited about the possibility of mobile node to >>>> mobile node direct LTE link. If any of you are also interested, it=20 >>>> might be good to check in on their progress and offer your comments. >>>=20 >>> Certainly I (and a group of people locally) are interested in the use >>> of LTE for direct communications. >>>=20 >>> How would it be possible to check in on their progress and how could we >>> offer our comments? >>>=20 >>> Alex >>=20 >> I am not an expert on the 3GPP process, so rather than muddle about and c= onfuse things, I will include the following article which I hope will offer c= lues. I believe that the standards body has agreed to investigate whether a d= irect mode is worth standardizing (??). >>=20 >> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-201= 10928/ >>=20 >> My connection to this program came from direct industry contact, so I apo= logize for my obtuse response. >>=20 >> Riley >> _______________________________________________ >> 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-AC77E4C9-E5AE-4BA5-B5EF-9540481D731A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,
Is any one here an expert in NS2 or knows someone who can help ?? Th= anks

Sent from Al's iPhone

On 2012-07-31, at 1:29 PM,= Rex Buddenberg <budden@nps.navy.m= il> wrote:


Riley,

This has been ki= cking around in the emergency services broadband
discussion.=  Most of the discussants are not long in understanding of
protocol stacks...  But they ARE long in experiencing 'the tower' g= oing
away and need to talk with 'that guy over there that I c= an see'.  

Qualcom only announced the s= tudy group news.  This is not a product
announcement or= even a proposed standard.

It appears that t= he alterations proposed would only affect layer 2 of
the LTE= protocol.  Totally agnostic about anything above layer 2.  

This leaves two questions open: can it be done u= sefully and scaleably?
and 2) what value is it?  


Speculating a bit on where the s= tudy group is going....  LTE and IEEE
802.16 use a hub&= amp;spoke structure (for that matter, so does WiFi).  The
LTE base station manages about four dozen MAC messages, the chief one is<= /span>
the UL-MAP (upload map in English) which tells each of the s= ubscriber
stations when it's that station's turn to transmit= .  The base station
also negotiates entry for new subsc= ribers -- ranging messages, X.509
cert exchange, etc.  = The processing load and the transmitting load on a
base stat= ion is significantly higher than a subscriber station.  

Our experience with IEEE 802.16 gear (LTE is a near-clone= ) is that the
hardware for both BS and SS is identical, only= the software load
changes.  
My students have hauled .16 gear, both BS and SS, out into the field= ,
plugged them in and gotten them to work (we know if you dr= op the antenna
off the back of the truck that it will break)= .  At the layer 3
interface, all the gear we've ever se= en is doing ethernet forwarding so
both SS and BS are passin= g ethernet frames out of the box, just like
your cable modem= at home.  

Cellphone implementations w= ill tend to load additional functions (like
beam steering) o= nto base stations to avoid having to do so with
subscriber s= tations (which may be embedded in cellphone handsets).  The
<= span>key diff between BS and SS here is electrical power usage -- a BS will<= /span>
drain the battery a lot faster.  

So the first question to ask is what would be the study group's<= /span>
criteria?  You can already make a subscriber station, w= ith a new
software load, act like a base station.  If y= ou have an adequate power
supply (e.g. vehicle mount rather t= han handset), then we have this
capability now and have had i= t for some years.  What's new?  

= The second question is what value this would be to emergency services=
(or ITS)?  Simply putting up a layer 2 network segment only g= ets you
layer 2 functionality -- all the rest of the applica= tions are outside
scope.  DNS support?  PKI white p= ages?  SIP server?  There's a lot left
to do in a r= eal-world usability exercise.  



On Mon, 2012-07-30 at 16:20 -0700, A. Riley Elle= r wrote:
While the working item is still a fair distance f= rom realizing
stand= ardization, I think it is worth mentioning that LTE Direct (a
peer-to-peer channel and symmetri= c transmission/reception mode) is
being proposed by Qualcomm. =46rom my interviews with their tec= hnical
team, I am v= ery excited about the possibility of mobile node to
<= /blockquote>
mobile node direct LTE link. If any of you a= re also interested, it
<= span>might be good to check in on their progress and offer your comments.

Certainly I (and a group of p= eople locally) are interested in the use
of LTE for direct= communications.

How would it be possib= le to check in on their progress and how could we
offer ou= r comments?

Alex

I am not an expert on the 3GPP process, so rather t= han muddle about and confuse things, I will include the following article wh= ich I hope will offer clues. I believe that the standards body has agreed to= investigate whether a direct mode is worth standardizing (??).

http://urgentcomm.com/networks_and_sy= stems/news/direct-mode-lte-study-20110928/

= My connection to this program came from direct industry contact, so I a= pologize for my obtuse response.

Riley
_______________________= ________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


___________________________= ____________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/li= stinfo/manet
= --Apple-Mail-AC77E4C9-E5AE-4BA5-B5EF-9540481D731A-- From prvs=5520a81f1=mukul@uwm.edu Tue Jul 31 10:32: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 275C321F8746 for ; Tue, 31 Jul 2012 10:32:08 -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, 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 zSrv5xLQwxad for ; Tue, 31 Jul 2012 10:32:07 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5821F87F8 for ; Tue, 31 Jul 2012 10:32:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHcVGFB/AAAB/2dsb2JhbABFhXi3KAEBAQQBAQEgSwsMDw4DBAEBAQICDRkCIwYoCAYTh34DDAupK4l/DUqJAASBIYlBZ4V3gRIDiE2LJ4FTiwqFA4J9 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 711DD2E1503; Tue, 31 Jul 2012 12:32:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7aho0wQ4dfc; Tue, 31 Jul 2012 12:32:02 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 34E8A2E1502; Tue, 31 Jul 2012 12:32:02 -0500 (CDT) Date: Tue, 31 Jul 2012 12:32:02 -0500 (CDT) From: Mukul Goyal To: Henning Rogge Message-ID: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 17:32:08 -0000 The wireless network of "fixed" temperature monitoring sensors and HVAC controllers in a building. This network is an LLN. Not sure if it qualifies as a MANET (since nothing is mobile). Thanks Mukul ----- Original Message ----- From: "Henning Rogge" To: "Abdussalam Baryun" Cc: "manet" Sent: Tuesday, July 31, 2012 8:49:08 AM Subject: Re: [manet] Discussing LOADng suggestions On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun wrote: > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. Could you state an example what would be considered a LLN but not a MANET. I normally consider LLNs a subset of what we call MANETs. 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 Tue Jul 31 10:37: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 961AC21F882D for ; Tue, 31 Jul 2012 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.378, 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 krXP-a6xkssm for ; Tue, 31 Jul 2012 10:37:37 -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 B1DCA21F880D for ; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6528690vbb.31 for ; Tue, 31 Jul 2012 10:37: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=8+0VHdb6tf8Aty/pxWFz27ubBYBJ6GfxaawTPaOklVo=; b=JVY6E9LQ6QxWlILSzlqCLe91IswSZwnL9/noJwBpuUHf4R00jHoeBTPgZHRSDS9YW+ 4UNWnBSbJ9Qh282aDDi3kY0OlwfXJy/A3MC+qn9YN4zp05LMAyU6jj1j1a6kacfk7VZH 9s3xzNcHOlxsYzyf2HUZhnGGDu+ZKYRdwREvc= 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=8+0VHdb6tf8Aty/pxWFz27ubBYBJ6GfxaawTPaOklVo=; b=J9wlssYFS/MHBlf+ZxEe3+k1WGCFqxEYPlxHTNWuQlIbn8484atkAxzE2ViNVp9hCS g2kYP5QoM2MUg1vdTnAbQYK/fUtsiW2RvofxXgguebn1AM55zAZAc90C4XxJ/XYeLuSu KZ/FA1mn7oQ61QXxzpaqT/eqQFlvoUQocflz6BWiI2/vMmv+Zr60CF9VSYax6LGFKJv+ fx/ombfHS8YYuK0iBYplEODjRuMLMEv7kxBX+UlpV8ToXbzldw7e7BPREfRWVs+XgoUU a5QTHpVAbUbMI4iHmZLSfsUdqrm/cSHl34+Hjvqoo7JxksA934/oInoztWx52TlpTzCC CA4A== MIME-Version: 1.0 Received: by 10.52.155.193 with SMTP id vy1mr12812926vdb.123.1343756255201; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) Received: by 10.58.56.130 with HTTP; Tue, 31 Jul 2012 10:37:35 -0700 (PDT) In-Reply-To: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Tue, 31 Jul 2012 10:37:35 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=bcaec53ae9ee418a4004c623a2a1 X-Gm-Message-State: ALoCoQnZsvrG1nsE90NK59QlyCp7llzyNNuQ6e+oBQEuyUOrBgqn/f8wSx/tYeFxAZMCwDyLKBsr Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 17:37:38 -0000 --bcaec53ae9ee418a4004c623a2a1 Content-Type: text/plain; charset=ISO-8859-1 MANETs are not defined by mobility. It is rather about very dynamic topologies. Otherwise, community networks such as FunkFeuer would also not be qualified as MANETs. Ulrich On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: > The wireless network of "fixed" temperature monitoring sensors and HVAC > controllers in a building. This network is an LLN. Not sure if it qualifies > as a MANET (since nothing is mobile). > > Thanks > Mukul > > ----- Original Message ----- > From: "Henning Rogge" > To: "Abdussalam Baryun" > Cc: "manet" > Sent: Tuesday, July 31, 2012 8:49:08 AM > Subject: Re: [manet] Discussing LOADng suggestions > > On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > wrote: > > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > > then changed its direction to MANET [3]. However, please note that > > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > > said, LOADng SHOULD specfy where is its limits. Then we can discuss > > adoption. > > Could you state an example what would be considered a LLN but not a > MANET. I normally consider LLNs a subset of what we call MANETs. > > 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 > --bcaec53ae9ee418a4004c623a2a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MANETs are not defined by mobility. It is rather about very dynamic topolog= ies. Otherwise, community networks such as FunkFeuer would also not be qual= ified as MANETs.

Ulrich

On Tue, Ju= l 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:
The wireless network of "fixed" te= mperature monitoring sensors and HVAC controllers in a building. This netwo= rk is an LLN. Not sure if it qualifies as a MANET (since nothing is mobile)= .

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <hrogge@googlemail.com>
To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
Cc: "manet" <manet@ietf.org<= /a>>
Sent: Tuesday, July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that
> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That
> said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption.

Could you state an example what would be considered a LLN but not a
MANET. I normally consider LLNs a subset of what we call MANETs.

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

--bcaec53ae9ee418a4004c623a2a1-- From antonin.bas@gmail.com Tue Jul 31 10:44: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 DCEBC21F884B for ; Tue, 31 Jul 2012 10:44:17 -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 JDX+OoDkE5ol for ; Tue, 31 Jul 2012 10:44:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 294D321F8842 for ; Tue, 31 Jul 2012 10:44:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so4264806qca.31 for ; Tue, 31 Jul 2012 10:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uE3feNkE/XoKVEu3cSvFnesXThYktBvVCw5UmTzcVgk=; b=Cv6Nl7LbrI0hY4Dc4At97W06miE1nH++UrHPHSOCtdmXwkv0wpLv2x/E4WLAhj4Jgb bPeqWx3r4L7lE7JUmTu7zp4ugg4p/WpMQaHNfIDC8wOsqIBSiy/QJIk7fCK3gA+5f1xd KaKLZ4fkYABkz+Akq9XquHXHgk4A42s3jfht1LZWfN82pnn3BZCcjYEQRd7qwrQj9Kdc 6xiLOfuH2oe9GEAYTM12+tzTXCHsUEDRk3MtryULV+8/OGUGnlUvXGSp+k7qJB5CwiZB 28bHR3HcQw6kym24xdwmIXsz20Go2oD/BtSQKM4PW1c/ISF9q3jonRX851BsKLFhMCkh 8gNA== MIME-Version: 1.0 Received: by 10.224.187.6 with SMTP id cu6mr31177741qab.63.1343756656610; Tue, 31 Jul 2012 10:44:16 -0700 (PDT) Sender: antonin.bas@gmail.com Received: by 10.224.137.35 with HTTP; Tue, 31 Jul 2012 10:44:16 -0700 (PDT) In-Reply-To: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Tue, 31 Jul 2012 19:44:16 +0200 X-Google-Sender-Auth: DmiTmd-3Z_8pK_4hFfdSRLzhZuA Message-ID: From: Antonin Bas To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 17:45:57 -0000 According to MANET charter, The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. So I don't think MANETs are defined by mobility, but by "increased dynamics",which can be due to motion, but also to lossy links. 2012/7/31 Ulrich Herberg : > MANETs are not defined by mobility. It is rather about very dynamic > topologies. Otherwise, community networks such as FunkFeuer would also not > be qualified as MANETs. > > Ulrich > > > On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >> >> The wireless network of "fixed" temperature monitoring sensors and HVAC >> controllers in a building. This network is an LLN. Not sure if it qualifies >> as a MANET (since nothing is mobile). >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Henning Rogge" >> To: "Abdussalam Baryun" >> Cc: "manet" >> Sent: Tuesday, July 31, 2012 8:49:08 AM >> Subject: Re: [manet] Discussing LOADng suggestions >> >> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >> wrote: >> > IMHO this protocol was intended as for ROLL WG not for MANET WG, but >> > then changed its direction to MANET [3]. However, please note that >> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >> > adoption. >> >> Could you state an example what would be considered a LLN but not a >> MANET. I normally consider LLNs a subset of what we call MANETs. >> >> 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 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From Ronald.intVelt@tno.nl Tue Jul 31 10:48: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 0225021F8877 for ; Tue, 31 Jul 2012 10:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6xYq4fPb0xy for ; Tue, 31 Jul 2012 10:48:46 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2AECF21F8874 for ; Tue, 31 Jul 2012 10:48:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,688,1336341600"; d="scan'208";a="15909994" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 31 Jul 2012 19:48:42 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 19:48:42 +0200 From: "Velt, R. (Ronald) in 't" To: manet Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNbyLfa7CsHKt+C0iNMj65Y8WjgZdDRrYAgAA+RwCAAAGNgIAAI/Fw Date: Tue, 31 Jul 2012 17:48:41 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A301B6D@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 17:48:47 -0000 > MANETs are not defined by mobility. It is rather about very dynamic topol= ogies. Otherwise, community networks such as FunkFeuer would also not be qu= alified as MANETs. Well, they shouldn't be. Ronald > Ulrich On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: The wireless network of "fixed" temperature monitoring sensors and HVAC con= trollers in a building. This network is an LLN. Not sure if it qualifies as= a MANET (since nothing is mobile). Thanks Mukul ----- Original Message ----- From: "Henning Rogge" To: "Abdussalam Baryun" Cc: "manet" Sent: Tuesday, July 31, 2012 8:49:08 AM Subject: Re: [manet] Discussing LOADng suggestions On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun wrote: > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. Could you state an example what would be considered a LLN but not a MANET. I normally consider LLNs a subset of what we call MANETs. 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 e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ulrich@herberg.name Tue Jul 31 10:58: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 E5B2421F8891 for ; Tue, 31 Jul 2012 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.361, 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 9HmiF78AD90u for ; Tue, 31 Jul 2012 10:58:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD9621F888D for ; Tue, 31 Jul 2012 10:58:51 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6497298vcb.31 for ; Tue, 31 Jul 2012 10:58:51 -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=JXqSm2w7+5CMMRAh820hevTdLmFzVzDdeuTkxKIi1As=; b=IUOG3t2awT0263ipEQV85RNFjtE3HMLj1gvvhQ7uFVfVmL7j8lIJqy4bGdH1+NiboK 3XJnVRN0qoPqToXBI6qPFdgNaSYvlRP8gCnKTJlDgW1ZyFnyhrVoILoGwqBSGZsMSXn5 G5ufHGuBy1xnOnT6+W9wNqPAGG/n0hWBxYYc0= 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=JXqSm2w7+5CMMRAh820hevTdLmFzVzDdeuTkxKIi1As=; b=SR2mTe4cA4ptOHU6mxTPOdW8GsYG9XH7+N6zCfRi6UCKSBRe8/D/AwY5bb/sj6Et8v heZm3r7LSY7zogjbaUUfMVrDLaP8VXBWA5uBLfuXxSnGjfU+PoBIlvR3Un1iWlXq+eJ0 K/cdqFSSOEizp6Hv5IwgN52IsLK75MXA1nSfYHLKuDR2EtJzpoJ19Eggpw+89nsMaj2o xZrsdM1Pch8Q+MPm3FO7CIObgYSCCEfjyu4V4uuvQg2C+8RM0aSVuxJRdbMEboqaJjgU NrgQnbRJlyzBHlBnVBqDw3xI3i1kbiVO5MqMLec7K0ShSp0EFP7wuBM9o6nNQ8+MEQ5d vklA== MIME-Version: 1.0 Received: by 10.220.215.138 with SMTP id he10mr7134617vcb.50.1343757531447; Tue, 31 Jul 2012 10:58:51 -0700 (PDT) Received: by 10.58.56.130 with HTTP; Tue, 31 Jul 2012 10:58:51 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A301B6D@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301B6D@EXC-MBX03.tsn.tno.nl> Date: Tue, 31 Jul 2012 10:58:51 -0700 Message-ID: From: Ulrich Herberg To: "Velt, R. (Ronald) in 't" Content-Type: multipart/alternative; boundary=bcaec54fb0c653818f04c623eeca X-Gm-Message-State: ALoCoQkIa5SG9hzwuLw6f97e7n6X/BaDCMLOAo7FrmnCtVbeOAm+imdRv9MGqVlxKUY08hbcrXV9 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 17:58:53 -0000 --bcaec54fb0c653818f04c623eeca Content-Type: text/plain; charset=ISO-8859-1 Why not? They use MANET routing protocols because they have a dynamic multi-hop topology and constrained resources. I know many MANET deployments where routers are not mobile. Ulrich On Tue, Jul 31, 2012 at 10:48 AM, Velt, R. (Ronald) in 't < Ronald.intVelt@tno.nl> wrote: > > > MANETs are not defined by mobility. It is rather about very dynamic > topologies. Otherwise, community networks such as FunkFeuer would also not > be qualified as MANETs. > > Well, they shouldn't be. > > Ronald > > > Ulrich > On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: > The wireless network of "fixed" temperature monitoring sensors and HVAC > controllers in a building. This network is an LLN. Not sure if it qualifies > as a MANET (since nothing is mobile). > > Thanks > Mukul > > ----- Original Message ----- > From: "Henning Rogge" > To: "Abdussalam Baryun" > Cc: "manet" > Sent: Tuesday, July 31, 2012 8:49:08 AM > Subject: Re: [manet] Discussing LOADng suggestions > > On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > wrote: > > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > > then changed its direction to MANET [3]. However, please note that > > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > > said, LOADng SHOULD specfy where is its limits. Then we can discuss > > adoption. > > Could you state an example what would be considered a LLN but not a > MANET. I normally consider LLNs a subset of what we call MANETs. > > 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 e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec54fb0c653818f04c623eeca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why not? They use MANET routing protocols because they have a dynamic multi= -hop topology and constrained resources. I know many MANET deployments wher= e routers are not mobile.

Ulrich


On Tue, Jul 31, 2012 at 10:48 AM, Velt, R. (Ronald) in 't <Ronald.= intVelt@tno.nl> wrote:

> MANETs are not defined by mobility. It is rather about very dynamic to= pologies. Otherwise, community networks such as FunkFeuer would also not be= qualified as MANETs.

Well, they shouldn't be.

Ronald

> Ulrich
On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:
The wireless network of "fixed" temperature monitoring sensors an= d HVAC controllers in a building. This network is an LLN. Not sure if it qu= alifies as a MANET (since nothing is mobile).

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <hrogge@googlemail.com>
To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
Cc: "manet" <manet@ietf.org<= /a>>
Sent: Tuesday, July 31, 2012 8:49:08 AM
Subject: Re: [manet] Discussing LOADng suggestions

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that
> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That
> said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption.

Could you state an example what would be considered a LLN but not a
MANET. I normally consider LLNs a subset of what we call MANETs.

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

This e-mail and its contents are subject to the DISCLAIMER at <= a href=3D"http://www.tno.nl/emaildisclaimer" target=3D"_blank">http://www.t= no.nl/emaildisclaimer

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

--bcaec54fb0c653818f04c623eeca-- From carlesgo@entel.upc.edu Tue Jul 31 11: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 8AE3121F88CC for ; Tue, 31 Jul 2012 11:07: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 Js1veDDU07ie for ; Tue, 31 Jul 2012 11:07:19 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3821F88B8 for ; Tue, 31 Jul 2012 11:07:18 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q6VI7GYH032262; Tue, 31 Jul 2012 20:07:16 +0200 Received: from webmail.entel.upc.edu (wireless.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 541192CBCFF; Tue, 31 Jul 2012 20:07:11 +0200 (CEST) Received: from 130.129.18.236 by webmail.entel.upc.edu with HTTP; Tue, 31 Jul 2012 20:07:11 +0200 Message-ID: In-Reply-To: References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Tue, 31 Jul 2012 20:07:11 +0200 From: "Carles Gomez Montenegro" To: "Antonin Bas" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 31 Jul 2012 20:07:17 +0200 (CEST) X-Mailman-Approved-At: Tue, 31 Jul 2012 11:13:44 -0700 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:07:20 -0000 +1 Carles > According to MANET charter, > > The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. > > So I don't think MANETs are defined by mobility, but by "increased > dynamics",which can be due to motion, but also to lossy links. > > 2012/7/31 Ulrich Herberg : >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not >> be qualified as MANETs. >> >> Ulrich >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>> >>> The wireless network of "fixed" temperature monitoring sensors and HVAC >>> controllers in a building. This network is an LLN. Not sure if it >>> qualifies >>> as a MANET (since nothing is mobile). >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Henning Rogge" >>> To: "Abdussalam Baryun" >>> Cc: "manet" >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> wrote: >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>> > then changed its direction to MANET [3]. However, please note that >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> > adoption. >>> >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> 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 >> >> >> >> _______________________________________________ >> 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 Jul 31 11:18: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 8D16F21F88F2; Tue, 31 Jul 2012 11:18:39 -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_35=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 69LNMAPnHlnM; Tue, 31 Jul 2012 11:18:38 -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 5B4CB21F88EC; Tue, 31 Jul 2012 11:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4879; q=dns/txt; s=iport; t=1343758718; x=1344968318; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D//Beu/e9gfj0V2GQsdBpxZOMlIMrJjPdnwRbuXlCiI=; b=Q8nCUnzO8OVP4z3RVuLTkiTaAuiRj2fvd9Y6QHxKgyi0yDboro3IcvQs z4ANOSiyLIPnbJ4YIENGvXfjRP1Q7C1FWsCjp6+NX32l1j8gOOcttuyMz /pD8Vn5rey0XPkFQ1ajMgeXDF7D59AaKxFAQEyKSsPyiv7r33CpvV8Qyi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD0hGFCtJXHB/2dsb2JhbABFuX2BB4IgAQEBAwEBAQEPAScxAwsQAgEIDgoeECcLJQIEDgUaCIdlBgube6Byi0kFFoYOYAOVR4EUjROBZoJf X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="107106210" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2012 18:18:37 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6VIIbSw028522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 18:18:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 13:18:37 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNbneJ32EEmGHxjUKeQ5Ynm1evrJdCaRiAgABheYCAAR+1gIAAHmcA Date: Tue, 31 Jul 2012 18:18:35 +0000 Message-ID: <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> In-Reply-To: <1343752185.981.856.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.202] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--49.919000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <79EDA33D1CE57345BC11E4DB0AE49E85@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:18:39 -0000 First off, I think the discussions on ITS are interesting, worthwhile, and = should continue. I wonder, though - aren't these scenarios essentially MANE= T's? I'm just asking whether one of the options here should be to pursue th= e work within the MANET WG. Regards, Stan On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >=20 > Riley, >=20 > This has been kicking around in the emergency services broadband > discussion. Most of the discussants are not long in understanding of > protocol stacks... But they ARE long in experiencing 'the tower' going > away and need to talk with 'that guy over there that I can see'. =20 >=20 > Qualcom only announced the study group news. This is not a product > announcement or even a proposed standard. >=20 > It appears that the alterations proposed would only affect layer 2 of > the LTE protocol. Totally agnostic about anything above layer 2. =20 >=20 > This leaves two questions open: can it be done usefully and scaleably? > and 2) what value is it? =20 >=20 >=20 > Speculating a bit on where the study group is going.... LTE and IEEE > 802.16 use a hub&spoke structure (for that matter, so does WiFi). The > LTE base station manages about four dozen MAC messages, the chief one is > the UL-MAP (upload map in English) which tells each of the subscriber > stations when it's that station's turn to transmit. The base station > also negotiates entry for new subscribers -- ranging messages, X.509 > cert exchange, etc. The processing load and the transmitting load on a > base station is significantly higher than a subscriber station. =20 >=20 > Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the > hardware for both BS and SS is identical, only the software load > changes. =20 >=20 > My students have hauled .16 gear, both BS and SS, out into the field, > plugged them in and gotten them to work (we know if you drop the antenna > off the back of the truck that it will break). At the layer 3 > interface, all the gear we've ever seen is doing ethernet forwarding so > both SS and BS are passing ethernet frames out of the box, just like > your cable modem at home. =20 >=20 > Cellphone implementations will tend to load additional functions (like > beam steering) onto base stations to avoid having to do so with > subscriber stations (which may be embedded in cellphone handsets). The > key diff between BS and SS here is electrical power usage -- a BS will > drain the battery a lot faster. =20 >=20 > So the first question to ask is what would be the study group's > criteria? You can already make a subscriber station, with a new > software load, act like a base station. If you have an adequate power > supply (e.g. vehicle mount rather than handset), then we have this > capability now and have had it for some years. What's new? =20 >=20 > The second question is what value this would be to emergency services > (or ITS)? Simply putting up a layer 2 network segment only gets you > layer 2 functionality -- all the rest of the applications are outside > scope. DNS support? PKI white pages? SIP server? There's a lot left > to do in a real-world usability exercise. =20 >=20 >=20 >=20 > On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>> While the working item is still a fair distance from realizing >>>> standardization, I think it is worth mentioning that LTE Direct (a >>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>> being proposed by Qualcomm. From my interviews with their technical >>>> team, I am very excited about the possibility of mobile node to >>>> mobile node direct LTE link. If any of you are also interested, it=20 >>>> might be good to check in on their progress and offer your comments. >>>=20 >>> Certainly I (and a group of people locally) are interested in the use >>> of LTE for direct communications. >>>=20 >>> How would it be possible to check in on their progress and how could we >>> offer our comments? >>>=20 >>> Alex >>=20 >> I am not an expert on the 3GPP process, so rather than muddle about and = confuse things, I will include the following article which I hope will offe= r clues. I believe that the standards body has agreed to investigate whethe= r a direct mode is worth standardizing (??). >>=20 >> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20= 110928/ >>=20 >> My connection to this program came from direct industry contact, so I ap= ologize for my obtuse response. >>=20 >> Riley >> _______________________________________________ >> 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 Tue Jul 31 11:21: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 472A221F88F9; Tue, 31 Jul 2012 11:21:30 -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_35=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 2Tgv-Com7Jyk; Tue, 31 Jul 2012 11:21:30 -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 C208121F8909; Tue, 31 Jul 2012 11:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4879; q=dns/txt; s=iport; t=1343758889; x=1344968489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D//Beu/e9gfj0V2GQsdBpxZOMlIMrJjPdnwRbuXlCiI=; b=j1G1z3ebucchxzYLQhZ+HALrwh3aRXHVolagkXUAFItAaKAhb0i4GjA0 0XUSjq9WRwTxpLIgiZrDyFEkTZTGK2KaEPrUFNc1Eb09gXcQhOFGOtDRI ceeSMO/CfZTRFI76J821W/ZLLHVPys5oWGKBx3lSVMZ1NZF8DwmZnFvBY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHghGFCtJV2Z/2dsb2JhbABFuX2BB4IgAQEBAwEBAQEPAScxAwsQAgEIDgoeECcLJQIEDgUaCIdlBgubfKByi0kFFoYOYAOVR4EUjROBZoJf X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="106901961" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2012 18:21:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6VILTXJ025778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 18:21:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 13:19:18 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNbneJ32EEmGHxjUKeQ5Ynm1evrJdCaRiAgABheYCAAR+1gIAAHzQA Date: Tue, 31 Jul 2012 18:21:28 +0000 Message-ID: <0B2B4B72-BCA6-4F85-8281-B2CE49856669@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> In-Reply-To: <1343752185.981.856.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.202] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--49.919000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8E904717AE0EE2419CA83CCE31A593E9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:21:30 -0000 First off, I think the discussions on ITS are interesting, worthwhile, and = should continue. I wonder, though - aren't these scenarios essentially MANE= T's? I'm just asking whether one of the options here should be to pursue th= e work within the MANET WG. Regards, Stan On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >=20 > Riley, >=20 > This has been kicking around in the emergency services broadband > discussion. Most of the discussants are not long in understanding of > protocol stacks... But they ARE long in experiencing 'the tower' going > away and need to talk with 'that guy over there that I can see'. =20 >=20 > Qualcom only announced the study group news. This is not a product > announcement or even a proposed standard. >=20 > It appears that the alterations proposed would only affect layer 2 of > the LTE protocol. Totally agnostic about anything above layer 2. =20 >=20 > This leaves two questions open: can it be done usefully and scaleably? > and 2) what value is it? =20 >=20 >=20 > Speculating a bit on where the study group is going.... LTE and IEEE > 802.16 use a hub&spoke structure (for that matter, so does WiFi). The > LTE base station manages about four dozen MAC messages, the chief one is > the UL-MAP (upload map in English) which tells each of the subscriber > stations when it's that station's turn to transmit. The base station > also negotiates entry for new subscribers -- ranging messages, X.509 > cert exchange, etc. The processing load and the transmitting load on a > base station is significantly higher than a subscriber station. =20 >=20 > Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the > hardware for both BS and SS is identical, only the software load > changes. =20 >=20 > My students have hauled .16 gear, both BS and SS, out into the field, > plugged them in and gotten them to work (we know if you drop the antenna > off the back of the truck that it will break). At the layer 3 > interface, all the gear we've ever seen is doing ethernet forwarding so > both SS and BS are passing ethernet frames out of the box, just like > your cable modem at home. =20 >=20 > Cellphone implementations will tend to load additional functions (like > beam steering) onto base stations to avoid having to do so with > subscriber stations (which may be embedded in cellphone handsets). The > key diff between BS and SS here is electrical power usage -- a BS will > drain the battery a lot faster. =20 >=20 > So the first question to ask is what would be the study group's > criteria? You can already make a subscriber station, with a new > software load, act like a base station. If you have an adequate power > supply (e.g. vehicle mount rather than handset), then we have this > capability now and have had it for some years. What's new? =20 >=20 > The second question is what value this would be to emergency services > (or ITS)? Simply putting up a layer 2 network segment only gets you > layer 2 functionality -- all the rest of the applications are outside > scope. DNS support? PKI white pages? SIP server? There's a lot left > to do in a real-world usability exercise. =20 >=20 >=20 >=20 > On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>> While the working item is still a fair distance from realizing >>>> standardization, I think it is worth mentioning that LTE Direct (a >>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>> being proposed by Qualcomm. From my interviews with their technical >>>> team, I am very excited about the possibility of mobile node to >>>> mobile node direct LTE link. If any of you are also interested, it=20 >>>> might be good to check in on their progress and offer your comments. >>>=20 >>> Certainly I (and a group of people locally) are interested in the use >>> of LTE for direct communications. >>>=20 >>> How would it be possible to check in on their progress and how could we >>> offer our comments? >>>=20 >>> Alex >>=20 >> I am not an expert on the 3GPP process, so rather than muddle about and = confuse things, I will include the following article which I hope will offe= r clues. I believe that the standards body has agreed to investigate whethe= r a direct mode is worth standardizing (??). >>=20 >> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20= 110928/ >>=20 >> My connection to this program came from direct industry contact, so I ap= ologize for my obtuse response. >>=20 >> Riley >> _______________________________________________ >> 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 Ronald.intVelt@tno.nl Tue Jul 31 11:23: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 4692021F8929 for ; Tue, 31 Jul 2012 11:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWnJGFQTsV08 for ; Tue, 31 Jul 2012 11:23:25 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73121F8928 for ; Tue, 31 Jul 2012 11:23:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,688,1336341600"; d="scan'208";a="15910088" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 31 Jul 2012 20:23:24 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 20:23:24 +0200 From: "Velt, R. (Ronald) in 't" To: Antonin Bas , Ulrich Herberg Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNbyLfa7CsHKt+C0iNMj65Y8WjgZdDRrYAgAA+RwCAAAGNgIAAAd4AgAAomxA= Date: Tue, 31 Jul 2012 18:23:23 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:23:26 -0000 >-----Original Message----- >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >Of Antonin Bas >Sent: dinsdag 31 juli 2012 19:44 >To: Ulrich Herberg >Cc: manet; Abdussalam Baryun >Subject: Re: [manet] Discussing LOADng suggestions > >According to MANET charter, > >The purpose of the MANET working group is to standardize IP routing > protocol functionality suitable for wireless routing application within > both static and dynamic topologies with increased dynamics due to node > motion or other factors. Strange wording, in my opinion. It seems to me that if the network _topolog= y_ is truly static, you do not need a routing protocol at all. (Note that j= ust as the absence of movement does not imply a static topology, a static t= opology does not imply stationary nodes). > >So I don't think MANETs are defined by mobility, but by "increased >dynamics",which can be due to motion, but also to lossy links. So why aren't they called ANETs? Ronald > >2012/7/31 Ulrich Herberg : >> MANETs are not defined by mobility. It is rather about very dynamic >> topologies. Otherwise, community networks such as FunkFeuer would also >> not be qualified as MANETs. >> >> Ulrich >> >> >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: >>> >>> The wireless network of "fixed" temperature monitoring sensors and >>> HVAC controllers in a building. This network is an LLN. Not sure if >>> it qualifies as a MANET (since nothing is mobile). >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Henning Rogge" >>> To: "Abdussalam Baryun" >>> Cc: "manet" >>> Sent: Tuesday, July 31, 2012 8:49:08 AM >>> Subject: Re: [manet] Discussing LOADng suggestions >>> >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun >>> wrote: >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, >>> > but then changed its direction to MANET [3]. However, please note >>> > that >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. >That >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> > adoption. >>> >>> Could you state an example what would be considered a LLN but not a >>> MANET. I normally consider LLNs a subset of what we call MANETs. >>> >>> 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 >> >> >> >> _______________________________________________ >> 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 e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ulrich@herberg.name Tue Jul 31 11:26: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 8B6AE21F88C8 for ; Tue, 31 Jul 2012 11:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.345, 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 Bl-Mr9UfDW54 for ; Tue, 31 Jul 2012 11:26:06 -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 09A8E21F88C5 for ; Tue, 31 Jul 2012 11:26:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6587138vbb.31 for ; Tue, 31 Jul 2012 11:26:04 -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=XB4xXFfq4DGtq0nh8PoHcDSWo6SFeJEIvpjeIdFqdDw=; b=QOlY3+9TmdPQm5fhqf4FpiIpXpKhVQB5vFG3D+Fg69I/JvFx5jEqVBO9fi1y276+rV gpi7MOpCJHTJ53dp9wxlZhtj7Qd6NqNZToj1EJRwf5A/MrWcQwxD20XIUTxIn4UkAfsY ncisIIHH7pNVKaCNgFlvjaqWMM5WfTDWLe+no= 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=XB4xXFfq4DGtq0nh8PoHcDSWo6SFeJEIvpjeIdFqdDw=; b=i7GOaoxKwLrPwnnYg6gcqdQzya9DR95ndMWpzqv8CcoeZvG57LszRPBiQg0AF/DX94 fac5DpaZEDxJRvY7ohPZinaf15n5C9PqgMnirpuAygoIIZ9Dh0M6om/gUJ74R4A8+8Cu hesTMeKOV0dZKRqNGXCR5FCj49McJqZps+HNWzoDvcMn15rBy8SzTov6IM6et0ld9sXc iwf2tftMxnirDIz4trCRCvcCdDa8fEVrx4ZZOWjRF8rK5NR4EhaxqHjXKHTNKTp3nVRn gO3rb0v+KWq3rTrICsmfKBPVchuDdpCPrnAQPg3wyBVI1awkoYNpDsZ9KrnOicLVS/XI QxSA== MIME-Version: 1.0 Received: by 10.52.93.75 with SMTP id cs11mr12865225vdb.52.1343759164327; Tue, 31 Jul 2012 11:26:04 -0700 (PDT) Received: by 10.58.56.130 with HTTP; Tue, 31 Jul 2012 11:26:04 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> Date: Tue, 31 Jul 2012 11:26:04 -0700 Message-ID: From: Ulrich Herberg To: "Velt, R. (Ronald) in 't" Content-Type: multipart/alternative; boundary=20cf3071c6aca7482904c6244feb X-Gm-Message-State: ALoCoQkArHGE5vIjY+SO+YnKB0y+v9AoJsu43GJ9BTcN2bSo79PUaVnykCn5MBthiqtJNWpMTucD Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:26:08 -0000 --20cf3071c6aca7482904c6244feb Content-Type: text/plain; charset=ISO-8859-1 Ronald, On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't < Ronald.intVelt@tno.nl> wrote: > > >-----Original Message----- > >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > >Of Antonin Bas > >Sent: dinsdag 31 juli 2012 19:44 > >To: Ulrich Herberg > >Cc: manet; Abdussalam Baryun > >Subject: Re: [manet] Discussing LOADng suggestions > > > >According to MANET charter, > > > >The purpose of the MANET working group is to standardize IP routing > > protocol functionality suitable for wireless routing application within > > both static and dynamic topologies with increased dynamics due to node > > motion or other factors. > > Strange wording, in my opinion. It seems to me that if the network > _topology_ is truly static, you do not need a routing protocol at all. I agree. > (Note that just as the absence of movement does not imply a static > topology, a static topology does not imply stationary nodes). > > > > >So I don't think MANETs are defined by mobility, but by "increased > >dynamics",which can be due to motion, but also to lossy links. > > So why aren't they called ANETs? > Or DANET ("dynamic"). It just did not sound as nice when the term was created. Best Ulrich > > Ronald > > > >2012/7/31 Ulrich Herberg : > >> MANETs are not defined by mobility. It is rather about very dynamic > >> topologies. Otherwise, community networks such as FunkFeuer would also > >> not be qualified as MANETs. > >> > >> Ulrich > >> > >> > >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal wrote: > >>> > >>> The wireless network of "fixed" temperature monitoring sensors and > >>> HVAC controllers in a building. This network is an LLN. Not sure if > >>> it qualifies as a MANET (since nothing is mobile). > >>> > >>> Thanks > >>> Mukul > >>> > >>> ----- Original Message ----- > >>> From: "Henning Rogge" > >>> To: "Abdussalam Baryun" > >>> Cc: "manet" > >>> Sent: Tuesday, July 31, 2012 8:49:08 AM > >>> Subject: Re: [manet] Discussing LOADng suggestions > >>> > >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > >>> wrote: > >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, > >>> > but then changed its direction to MANET [3]. However, please note > >>> > that > >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. > >That > >>> > said, LOADng SHOULD specfy where is its limits. Then we can discuss > >>> > adoption. > >>> > >>> Could you state an example what would be considered a LLN but not a > >>> MANET. I normally consider LLNs a subset of what we call MANETs. > >>> > >>> 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 > >> > >> > >> > >> _______________________________________________ > >> 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 e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > --20cf3071c6aca7482904c6244feb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ronald,

On Tue, Jul 31, 2012 at 11:23 AM,= Velt, R. (Ronald) in 't <Ronald.intVelt@tno.nl> wro= te:

>-----Original Message-----
>From: manet-bounces@ietf.org<= /a> [mailto:manet-bounces@ietf.or= g] On Behalf
>Of Antonin Bas
>Sent: dinsdag 31 juli 2012 19:44
>To: Ulrich Herberg
>Cc: manet; Abdussalam Baryun
>Subject: Re: [manet] Discussing LOADng suggestions
>
>According to MANET charter,
>
>The purpose of the MANET working group is to standardize IP routing
> =A0protocol functionality suitable for wireless routing application wi= thin
> =A0both static and dynamic topologies with increased dynamics due to n= ode
> =A0motion or other factors.

Strange wording, in my opinion. It seems to me that if the network _t= opology_ is truly static, you do not need a routing protocol at all.


I agree.

=A0
(Note that just as the absence of movement does not imply a static topology= , a static topology does not imply stationary nodes).

>
>So I don't think MANETs are defined by mobility, but by "incre= ased
>dynamics",which can be due to motion, but also to lossy links.

So why aren't they called ANETs?


Or = DANET ("dynamic"). It just did not sound as nice when the term wa= s created.

Best
Ulrich


=A0

Ronald
>
>2012/7/31 Ulrich Herberg <ulr= ich@herberg.name>:
>> MANETs are not defined by mobility. It is rather about very dynami= c
>> topologies. Otherwise, community networks such as FunkFeuer would = also
>> not be qualified as MANETs.
>>
>> Ulrich
>>
>>
>> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal <mukul@uwm.edu> wrote:
>>>
>>> The wireless network of "fixed" temperature monitori= ng sensors and
>>> HVAC controllers in a building. This network is an LLN. Not su= re if
>>> it qualifies as a MANET (since nothing is mobile).
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Henning Rogge" <hrogge@googlemail.com>
>>> To: "Abdussalam Baryun" <abdussalambaryun@gmail.com>
>>> Cc: "manet" <ma= net@ietf.org>
>>> Sent: Tuesday, July 31, 2012 8:49:08 AM
>>> Subject: Re: [manet] Discussing LOADng suggestions
>>>
>>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun
>>> <abdussalamba= ryun@gmail.com> wrote:
>>> > IMHO this protocol was intended as for ROLL WG not for MA= NET WG,
>>> > but then changed its direction to MANET [3]. However, ple= ase note
>>> > that
>>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are L= LNs.
>That
>>> > said, LOADng SHOULD specfy where is its limits. Then we c= an discuss
>>> > adoption.
>>>
>>> Could you state an example what would be considered a LLN but = not a
>>> MANET. I normally consider LLNs a subset of what we call MANET= s.
>>>
>>> Henning Rogge
>>>
>>> --
>>> Steven Hawkings about cosmic inflation: "An increase of b= illions 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
>>
>>
>>
>> _______________________________________________
>> 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 e-mail and its con= tents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer


--20cf3071c6aca7482904c6244feb-- From fjros@um.es Tue Jul 31 11:35: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 63D0221F88ED; Tue, 31 Jul 2012 11:35:50 -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=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, 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 ilPk70t8FBl7; Tue, 31 Jul 2012 11:35:46 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6191F21F8671; Tue, 31 Jul 2012 11:35:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id CA01B5D527; Tue, 31 Jul 2012 20:35:22 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xjt3Fc6R4TWi; Tue, 31 Jul 2012 20:35:22 +0200 (CEST) Received: from [192.168.1.35] (unknown [80.30.140.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon13.um.es (Postfix) with ESMTPSA id E02205D4D1; Tue, 31 Jul 2012 20:35:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> Date: Tue, 31 Jul 2012 20:35:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1084) Cc: Rex Buddenberg , Alexandru Petrescu , "its@ietf.org" , manet , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 18:35:50 -0000 Hi Stan, I guess that your comment refers to V2V communications (please correct = me if I misunderstood you). There are other issues in ITS that, in my = opinion, do not perfectly fit into the MANET WG (V2I among others). For V2V, MANET routing solutions have been shown to perform poorly in = vehicular scenarios. There are tons of references out there, check e.g. = [1]. In fact, most research in the field borrows concepts from = geographic routing and opportunistic communications. Standardization = bodies like the ETSI have also followed this path. To summarize: although the work could be undertaken by the MANET WG, I = feel that ITS features enough peculiarities to deserve a different (more = focused) WG. [1] I. Khan and A. Qayyum, =93Performance evaluation of aodv and olsr in = highly fading vehicular ad hoc network environments,=94 in Proceedings = of the 13th International Multitopic Conference (INMIC), December 2009, = pp. 1=965. Regards, fran El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribi=F3: > First off, I think the discussions on ITS are interesting, worthwhile, = and should continue. I wonder, though - aren't these scenarios = essentially MANET's? I'm just asking whether one of the options here = should be to pursue the work within the MANET WG. >=20 > Regards, > Stan >=20 > On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >=20 >>=20 >> Riley, >>=20 >> This has been kicking around in the emergency services broadband >> discussion. Most of the discussants are not long in understanding of >> protocol stacks... But they ARE long in experiencing 'the tower' = going >> away and need to talk with 'that guy over there that I can see'. =20 >>=20 >> Qualcom only announced the study group news. This is not a product >> announcement or even a proposed standard. >>=20 >> It appears that the alterations proposed would only affect layer 2 of >> the LTE protocol. Totally agnostic about anything above layer 2. =20 >>=20 >> This leaves two questions open: can it be done usefully and = scaleably? >> and 2) what value is it? =20 >>=20 >>=20 >> Speculating a bit on where the study group is going.... LTE and IEEE >> 802.16 use a hub&spoke structure (for that matter, so does WiFi). = The >> LTE base station manages about four dozen MAC messages, the chief one = is >> the UL-MAP (upload map in English) which tells each of the subscriber >> stations when it's that station's turn to transmit. The base station >> also negotiates entry for new subscribers -- ranging messages, X.509 >> cert exchange, etc. The processing load and the transmitting load on = a >> base station is significantly higher than a subscriber station. =20 >>=20 >> Our experience with IEEE 802.16 gear (LTE is a near-clone) is that = the >> hardware for both BS and SS is identical, only the software load >> changes. =20 >>=20 >> My students have hauled .16 gear, both BS and SS, out into the field, >> plugged them in and gotten them to work (we know if you drop the = antenna >> off the back of the truck that it will break). At the layer 3 >> interface, all the gear we've ever seen is doing ethernet forwarding = so >> both SS and BS are passing ethernet frames out of the box, just like >> your cable modem at home. =20 >>=20 >> Cellphone implementations will tend to load additional functions = (like >> beam steering) onto base stations to avoid having to do so with >> subscriber stations (which may be embedded in cellphone handsets). = The >> key diff between BS and SS here is electrical power usage -- a BS = will >> drain the battery a lot faster. =20 >>=20 >> So the first question to ask is what would be the study group's >> criteria? You can already make a subscriber station, with a new >> software load, act like a base station. If you have an adequate = power >> supply (e.g. vehicle mount rather than handset), then we have this >> capability now and have had it for some years. What's new? =20 >>=20 >> The second question is what value this would be to emergency services >> (or ITS)? Simply putting up a layer 2 network segment only gets you >> layer 2 functionality -- all the rest of the applications are outside >> scope. DNS support? PKI white pages? SIP server? There's a lot = left >> to do in a real-world usability exercise. =20 >>=20 >>=20 >>=20 >> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>> While the working item is still a fair distance from realizing >>>>> standardization, I think it is worth mentioning that LTE Direct (a >>>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>>> being proposed by Qualcomm. =46rom my interviews with their = technical >>>>> team, I am very excited about the possibility of mobile node to >>>>> mobile node direct LTE link. If any of you are also interested, it=20= >>>>> might be good to check in on their progress and offer your = comments. >>>>=20 >>>> Certainly I (and a group of people locally) are interested in the = use >>>> of LTE for direct communications. >>>>=20 >>>> How would it be possible to check in on their progress and how = could we >>>> offer our comments? >>>>=20 >>>> Alex >>>=20 >>> I am not an expert on the 3GPP process, so rather than muddle about = and confuse things, I will include the following article which I hope = will offer clues. I believe that the standards body has agreed to = investigate whether a direct mode is worth standardizing (??). >>>=20 >>> = http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-2011= 0928/ >>>=20 >>> My connection to this program came from direct industry contact, so = I apologize for my obtuse response. >>>=20 >>> Riley >>> _______________________________________________ >>> 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 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From reller@cococorp.com Tue Jul 31 12:27: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 1E7C721F8933; Tue, 31 Jul 2012 12:27:58 -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.450, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SARE_WEOFFER=0.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 8LDzMDGkwxcO; Tue, 31 Jul 2012 12:27:57 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3200521F8902; Tue, 31 Jul 2012 12:27:56 -0700 (PDT) Received: from EXHUB03.exchhosting.com (192.168.11.104) by exhub06.exchhosting.com (192.168.11.102) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 31 Jul 2012 12:27:55 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by EXHUB03.exchhosting.com ([fe80::ac41:fbe5:3959:ad64%12]) with mapi; Tue, 31 Jul 2012 12:27:54 -0700 From: "A. Riley Eller" To: Rex Buddenberg Date: Tue, 31 Jul 2012 12:27:52 -0700 Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: Ac1vOdctxfSlAyVySUieflgH3aEPXAAF8nSA Message-ID: <3D05610F3AC2E047AACAA68F63DF908D379D28E3EA@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> In-Reply-To: <1343752185.981.856.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 19:27:58 -0000 QWN0dWFsbHksIFF1YWxjb21tIGFubm91bmNlZCBhIHdvcmtpbmcgcHJvZHVjdCAoRmxhc2hMaW5x KSBiZWZvcmUgcHVsbGluZyBpdCBmcm9tIHRoZWlyIGZlYXR1cmUgcm9hZCBtYXAuIFRoZXkgY2hv c2UgdG8gcmV3aW5kIGFuZCBlbnRlciB0aGUgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MgZnJvbSBm aXJzdCBwcmluY2lwbGVzLiBZb3UgY2FuIGRlcml2ZSBtaW5pbWFsLCBidXQgaW50ZXJlc3Rpbmcs IGRldGFpbHMgZnJvbSB0aGUgZmV3IHByZXNzIHJlbGVhc2VzIGluIHRoYXQgYXJlYS4gSSBiZWxp ZXZlIHRoYXQgdGhleSBhcmUgc3dpdGNoaW5nIGZyb20gZXhwZXJpbWVudGFsIGZyYW1lcyB0byAz R1BQIHN0YW5kYXJkIGZyYW1lIHR5cGVzIGluIG9yZGVyIHRvIGFjaGlldmUgZ3JlYXRlciBhZG9w dGlvbi4gDQoNClRvIG15IHVuZGVyc3RhbmRpbmcsIHdoaWNoIElTIE5PVCBSRUxJQUJMRSwgdGhl eSBoYXZlIGltcGxlbWVudGVkIGEgcGVlci10by1wZWVyIFRETUEgc29sdXRpb24gKGkuZS4gd2l0 aCBkaXN0cmlidXRlZCBzeW5jaHJvbml6YXRpb24pLiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgdGhl eSBzcGVjaWZ5IG9yIGltcGxlbWVudCBhbnkgZm9yd2FyZGluZyBvciByb3V0aW5nIGluIHRoZSBt b2R1bGUsIGJ1dCB0aGUgZW5naW5lZXJzIHdobyByYW4gdGhlIHByb2dyYW0gc2VlbWVkIHZlcnkg ZmFtaWxpYXIgd2l0aCB0aGUgd29yayBvZiB0aGlzIGdyb3VwLg0KDQpTbywgSSB3b3VsZCBzYXkg dGhhdCB3ZSBhcmUgYWxsIHdhaXRpbmcgZm9yIDNHUFAgdG8gYWNrbm93bGVkZ2UgdGhlIHdvcmsu DQoNCk15IChwcmVzdW1wdGl2ZSkgY29uY2VwdGlvbiBvZiB0aGUgdmFsdWUgcHJvcG9zaXRpb25z IGdvZXMgbGlrZSB0aGlzOg0KMSkgc3RhbmRhcmQgcGVlci10by1wZWVyIHJhZGlvDQoyKSBsb3ct cG93ZXIsIG1vZGVyYXRlIHJhbmdlIGRlbGl2ZXJ5DQozKSBhdmFpbGFiaWxpdHkgaW4gQ09UUyA0 RyBwaG9uZXMNCjQpIGZsZXhpYmxlIGNob2ljZSBvZiBmb3J3YXJkaW5nIHN0cmF0ZWd5DQo1KSBT T01FIGFkb3B0aW9uIGJ5IHByb3hpbWl0eSBiYXNlZCBzZXJ2aWNlcyAoYWR2ZXJ0aXNpbmcsIGlu dmVudG9yeSwgZXRjKSB0byBoZWxwIHB1c2ggZGVtYW5kDQoNCkFsbCBpbiBhbGwsIGl0IG1pZ2h0 IGJlIHRoZSBiZXN0IHRoaW5nIHNpbmNlIHNsaWNlZCBtb25pdG9yIG1vZGUuDQoNCg0KUmlsZXkN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSZXggQnVkZGVuYmVyZyBb bWFpbHRvOmJ1ZGRlbkBucHMubmF2eS5taWxdDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMzEsIDIw MTIgOTozMCBBTQ0KPiBUbzogQS4gUmlsZXkgRWxsZXINCj4gQ2M6IEFsZXhhbmRydSBQZXRyZXNj dTsgbWFuZXQ7IGl0c0BpZXRmLm9yZzsgQWJkdXNzYWxhbSBCYXJ5dW4NCj4gU3ViamVjdDogUmU6 IFttYW5ldF0gW2l0c10gU2NlbmFyaW9zLCBwb3RlbnRpYWwgdG9waWNzLi4uDQo+IA0KPiANCj4g UmlsZXksDQo+IA0KPiBUaGlzIGhhcyBiZWVuIGtpY2tpbmcgYXJvdW5kIGluIHRoZSBlbWVyZ2Vu Y3kgc2VydmljZXMgYnJvYWRiYW5kDQo+IGRpc2N1c3Npb24uICBNb3N0IG9mIHRoZSBkaXNjdXNz YW50cyBhcmUgbm90IGxvbmcgaW4gdW5kZXJzdGFuZGluZyBvZg0KPiBwcm90b2NvbCBzdGFja3Mu Li4gIEJ1dCB0aGV5IEFSRSBsb25nIGluIGV4cGVyaWVuY2luZyAndGhlIHRvd2VyJyBnb2luZw0K PiBhd2F5IGFuZCBuZWVkIHRvIHRhbGsgd2l0aCAndGhhdCBndXkgb3ZlciB0aGVyZSB0aGF0IEkg Y2FuIHNlZScuDQo+IA0KPiBRdWFsY29tIG9ubHkgYW5ub3VuY2VkIHRoZSBzdHVkeSBncm91cCBu ZXdzLiAgVGhpcyBpcyBub3QgYSBwcm9kdWN0DQo+IGFubm91bmNlbWVudCBvciBldmVuIGEgcHJv cG9zZWQgc3RhbmRhcmQuDQo+IA0KPiBJdCBhcHBlYXJzIHRoYXQgdGhlIGFsdGVyYXRpb25zIHBy b3Bvc2VkIHdvdWxkIG9ubHkgYWZmZWN0IGxheWVyIDIgb2YNCj4gdGhlIExURSBwcm90b2NvbC4g IFRvdGFsbHkgYWdub3N0aWMgYWJvdXQgYW55dGhpbmcgYWJvdmUgbGF5ZXIgMi4NCj4gDQo+IFRo aXMgbGVhdmVzIHR3byBxdWVzdGlvbnMgb3BlbjogY2FuIGl0IGJlIGRvbmUgdXNlZnVsbHkgYW5k IHNjYWxlYWJseT8NCj4gYW5kIDIpIHdoYXQgdmFsdWUgaXMgaXQ/DQo+IA0KPiANCj4gU3BlY3Vs YXRpbmcgYSBiaXQgb24gd2hlcmUgdGhlIHN0dWR5IGdyb3VwIGlzIGdvaW5nLi4uLiAgTFRFIGFu ZCBJRUVFDQo+IDgwMi4xNiB1c2UgYSBodWImc3Bva2Ugc3RydWN0dXJlIChmb3IgdGhhdCBtYXR0 ZXIsIHNvIGRvZXMgV2lGaSkuICBUaGUNCj4gTFRFIGJhc2Ugc3RhdGlvbiBtYW5hZ2VzIGFib3V0 IGZvdXIgZG96ZW4gTUFDIG1lc3NhZ2VzLCB0aGUgY2hpZWYgb25lDQo+IGlzIHRoZSBVTC1NQVAg KHVwbG9hZCBtYXAgaW4gRW5nbGlzaCkgd2hpY2ggdGVsbHMgZWFjaCBvZiB0aGUNCj4gc3Vic2Ny aWJlciBzdGF0aW9ucyB3aGVuIGl0J3MgdGhhdCBzdGF0aW9uJ3MgdHVybiB0byB0cmFuc21pdC4g IFRoZQ0KPiBiYXNlIHN0YXRpb24gYWxzbyBuZWdvdGlhdGVzIGVudHJ5IGZvciBuZXcgc3Vic2Ny aWJlcnMgLS0gcmFuZ2luZw0KPiBtZXNzYWdlcywgWC41MDkgY2VydCBleGNoYW5nZSwgZXRjLiAg VGhlIHByb2Nlc3NpbmcgbG9hZCBhbmQgdGhlDQo+IHRyYW5zbWl0dGluZyBsb2FkIG9uIGEgYmFz ZSBzdGF0aW9uIGlzIHNpZ25pZmljYW50bHkgaGlnaGVyIHRoYW4gYQ0KPiBzdWJzY3JpYmVyIHN0 YXRpb24uDQo+IA0KPiBPdXIgZXhwZXJpZW5jZSB3aXRoIElFRUUgODAyLjE2IGdlYXIgKExURSBp cyBhIG5lYXItY2xvbmUpIGlzIHRoYXQgdGhlDQo+IGhhcmR3YXJlIGZvciBib3RoIEJTIGFuZCBT UyBpcyBpZGVudGljYWwsIG9ubHkgdGhlIHNvZnR3YXJlIGxvYWQNCj4gY2hhbmdlcy4NCj4gDQo+ IE15IHN0dWRlbnRzIGhhdmUgaGF1bGVkIC4xNiBnZWFyLCBib3RoIEJTIGFuZCBTUywgb3V0IGlu dG8gdGhlIGZpZWxkLA0KPiBwbHVnZ2VkIHRoZW0gaW4gYW5kIGdvdHRlbiB0aGVtIHRvIHdvcmsg KHdlIGtub3cgaWYgeW91IGRyb3AgdGhlDQo+IGFudGVubmEgb2ZmIHRoZSBiYWNrIG9mIHRoZSB0 cnVjayB0aGF0IGl0IHdpbGwgYnJlYWspLiAgQXQgdGhlIGxheWVyIDMNCj4gaW50ZXJmYWNlLCBh bGwgdGhlIGdlYXIgd2UndmUgZXZlciBzZWVuIGlzIGRvaW5nIGV0aGVybmV0IGZvcndhcmRpbmcg c28NCj4gYm90aCBTUyBhbmQgQlMgYXJlIHBhc3NpbmcgZXRoZXJuZXQgZnJhbWVzIG91dCBvZiB0 aGUgYm94LCBqdXN0IGxpa2UNCj4geW91ciBjYWJsZSBtb2RlbSBhdCBob21lLg0KPiANCj4gQ2Vs bHBob25lIGltcGxlbWVudGF0aW9ucyB3aWxsIHRlbmQgdG8gbG9hZCBhZGRpdGlvbmFsIGZ1bmN0 aW9ucyAobGlrZQ0KPiBiZWFtIHN0ZWVyaW5nKSBvbnRvIGJhc2Ugc3RhdGlvbnMgdG8gYXZvaWQg aGF2aW5nIHRvIGRvIHNvIHdpdGgNCj4gc3Vic2NyaWJlciBzdGF0aW9ucyAod2hpY2ggbWF5IGJl IGVtYmVkZGVkIGluIGNlbGxwaG9uZSBoYW5kc2V0cykuICBUaGUNCj4ga2V5IGRpZmYgYmV0d2Vl biBCUyBhbmQgU1MgaGVyZSBpcyBlbGVjdHJpY2FsIHBvd2VyIHVzYWdlIC0tIGEgQlMgd2lsbA0K PiBkcmFpbiB0aGUgYmF0dGVyeSBhIGxvdCBmYXN0ZXIuDQo+IA0KPiBTbyB0aGUgZmlyc3QgcXVl c3Rpb24gdG8gYXNrIGlzIHdoYXQgd291bGQgYmUgdGhlIHN0dWR5IGdyb3VwJ3MNCj4gY3JpdGVy aWE/ICBZb3UgY2FuIGFscmVhZHkgbWFrZSBhIHN1YnNjcmliZXIgc3RhdGlvbiwgd2l0aCBhIG5l dw0KPiBzb2Z0d2FyZSBsb2FkLCBhY3QgbGlrZSBhIGJhc2Ugc3RhdGlvbi4gIElmIHlvdSBoYXZl IGFuIGFkZXF1YXRlIHBvd2VyDQo+IHN1cHBseSAoZS5nLiB2ZWhpY2xlIG1vdW50IHJhdGhlciB0 aGFuIGhhbmRzZXQpLCB0aGVuIHdlIGhhdmUgdGhpcw0KPiBjYXBhYmlsaXR5IG5vdyBhbmQgaGF2 ZSBoYWQgaXQgZm9yIHNvbWUgeWVhcnMuICBXaGF0J3MgbmV3Pw0KPiANCj4gVGhlIHNlY29uZCBx dWVzdGlvbiBpcyB3aGF0IHZhbHVlIHRoaXMgd291bGQgYmUgdG8gZW1lcmdlbmN5IHNlcnZpY2Vz DQo+IChvciBJVFMpPyAgU2ltcGx5IHB1dHRpbmcgdXAgYSBsYXllciAyIG5ldHdvcmsgc2VnbWVu dCBvbmx5IGdldHMgeW91DQo+IGxheWVyIDIgZnVuY3Rpb25hbGl0eSAtLSBhbGwgdGhlIHJlc3Qg b2YgdGhlIGFwcGxpY2F0aW9ucyBhcmUgb3V0c2lkZQ0KPiBzY29wZS4gIEROUyBzdXBwb3J0PyAg UEtJIHdoaXRlIHBhZ2VzPyAgU0lQIHNlcnZlcj8gIFRoZXJlJ3MgYSBsb3QgbGVmdA0KPiB0byBk byBpbiBhIHJlYWwtd29ybGQgdXNhYmlsaXR5IGV4ZXJjaXNlLg0KPiANCj4gDQo+IA0KPiBPbiBN b24sIDIwMTItMDctMzAgYXQgMTY6MjAgLTA3MDAsIEEuIFJpbGV5IEVsbGVyIHdyb3RlOg0KPiA+ ID4gPiBXaGlsZSB0aGUgd29ya2luZyBpdGVtIGlzIHN0aWxsIGEgZmFpciBkaXN0YW5jZSBmcm9t IHJlYWxpemluZw0KPiA+ID4gPiBzdGFuZGFyZGl6YXRpb24sIEkgdGhpbmsgaXQgaXMgd29ydGgg bWVudGlvbmluZyB0aGF0IExURSBEaXJlY3QNCj4gKGENCj4gPiA+ID4gcGVlci10by1wZWVyIGNo YW5uZWwgYW5kIHN5bW1ldHJpYyB0cmFuc21pc3Npb24vcmVjZXB0aW9uIG1vZGUpDQo+IGlzDQo+ ID4gPiA+IGJlaW5nIHByb3Bvc2VkIGJ5IFF1YWxjb21tLiBGcm9tIG15IGludGVydmlld3Mgd2l0 aCB0aGVpcg0KPiA+ID4gPiB0ZWNobmljYWwgdGVhbSwgSSBhbSB2ZXJ5IGV4Y2l0ZWQgYWJvdXQg dGhlIHBvc3NpYmlsaXR5IG9mIG1vYmlsZQ0KPiA+ID4gPiBub2RlIHRvIG1vYmlsZSBub2RlIGRp cmVjdCBMVEUgbGluay4gSWYgYW55IG9mIHlvdSBhcmUgYWxzbw0KPiA+ID4gPiBpbnRlcmVzdGVk LCBpdCBtaWdodCBiZSBnb29kIHRvIGNoZWNrIGluIG9uIHRoZWlyIHByb2dyZXNzIGFuZA0KPiBv ZmZlciB5b3VyIGNvbW1lbnRzLg0KPiA+ID4NCj4gPiA+IENlcnRhaW5seSBJIChhbmQgYSBncm91 cCBvZiBwZW9wbGUgbG9jYWxseSkgYXJlIGludGVyZXN0ZWQgaW4gdGhlDQo+ID4gPiB1c2Ugb2Yg TFRFIGZvciBkaXJlY3QgY29tbXVuaWNhdGlvbnMuDQo+ID4gPg0KPiA+ID4gSG93IHdvdWxkIGl0 IGJlIHBvc3NpYmxlIHRvIGNoZWNrIGluIG9uIHRoZWlyIHByb2dyZXNzIGFuZCBob3cNCj4gY291 bGQNCj4gPiA+IHdlIG9mZmVyIG91ciBjb21tZW50cz8NCj4gPiA+DQo+ID4gPiBBbGV4DQo+ID4N Cj4gPiBJIGFtIG5vdCBhbiBleHBlcnQgb24gdGhlIDNHUFAgcHJvY2Vzcywgc28gcmF0aGVyIHRo YW4gbXVkZGxlIGFib3V0DQo+IGFuZCBjb25mdXNlIHRoaW5ncywgSSB3aWxsIGluY2x1ZGUgdGhl IGZvbGxvd2luZyBhcnRpY2xlIHdoaWNoIEkgaG9wZQ0KPiB3aWxsIG9mZmVyIGNsdWVzLiBJIGJl bGlldmUgdGhhdCB0aGUgc3RhbmRhcmRzIGJvZHkgaGFzIGFncmVlZCB0bw0KPiBpbnZlc3RpZ2F0 ZSB3aGV0aGVyIGEgZGlyZWN0IG1vZGUgaXMgd29ydGggc3RhbmRhcmRpemluZyAoPz8pLg0KPiA+ DQo+ID4gaHR0cDovL3VyZ2VudGNvbW0uY29tL25ldHdvcmtzX2FuZF9zeXN0ZW1zL25ld3MvZGly ZWN0LW1vZGUtbHRlLQ0KPiBzdHVkeS0NCj4gPiAyMDExMDkyOC8NCj4gPg0KPiA+IE15IGNvbm5l Y3Rpb24gdG8gdGhpcyBwcm9ncmFtIGNhbWUgZnJvbSBkaXJlY3QgaW5kdXN0cnkgY29udGFjdCwg c28gSQ0KPiBhcG9sb2dpemUgZm9yIG15IG9idHVzZSByZXNwb25zZS4NCj4gPg0KPiA+IFJpbGV5 DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gPiBtYW5ldEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4gDQoNCg== From reller@cococorp.com Tue Jul 31 12:28: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 EDF8611E8123; Tue, 31 Jul 2012 12:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SARE_WEOFFER=0.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 2K4hr1Xar2Jl; Tue, 31 Jul 2012 12:28:56 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD911E811F; Tue, 31 Jul 2012 12:28:56 -0700 (PDT) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub15.exchhosting.com (192.168.11.128) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 31 Jul 2012 12:28:56 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Tue, 31 Jul 2012 12:28:55 -0700 From: "A. Riley Eller" To: "Stan Ratliff (sratliff)" , Rex Buddenberg Date: Tue, 31 Jul 2012 12:28:52 -0700 Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNbneJ32EEmGHxjUKeQ5Ynm1evrJdCaRiAgABheYCAAR+1gIAAHmcA//+/ktA= Message-ID: <3D05610F3AC2E047AACAA68F63DF908D379D28E3EB@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> In-Reply-To: <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> 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 Cc: Alexandru Petrescu , manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 19:28:57 -0000 They intentionally do not specify the routing/forwarding strategy, so we mi= ght want to work on "which techniques work best with this radio" but QC wil= l likely continue full steam ahead with "LTE Direct". > -----Original Message----- > From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] > Sent: Tuesday, July 31, 2012 11:19 AM > To: Rex Buddenberg > Cc: A. Riley Eller; Alexandru Petrescu; manet; its@ietf.org; Abdussalam > Baryun > Subject: Re: [manet] [its] Scenarios, potential topics... >=20 > First off, I think the discussions on ITS are interesting, worthwhile, > and should continue. I wonder, though - aren't these scenarios > essentially MANET's? I'm just asking whether one of the options here > should be to pursue the work within the MANET WG. >=20 > Regards, > Stan >=20 > On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >=20 > > > > Riley, > > > > This has been kicking around in the emergency services broadband > > discussion. Most of the discussants are not long in understanding of > > protocol stacks... But they ARE long in experiencing 'the tower' > > going away and need to talk with 'that guy over there that I can > see'. > > > > Qualcom only announced the study group news. This is not a product > > announcement or even a proposed standard. > > > > It appears that the alterations proposed would only affect layer 2 of > > the LTE protocol. Totally agnostic about anything above layer 2. > > > > This leaves two questions open: can it be done usefully and > scaleably? > > and 2) what value is it? > > > > > > Speculating a bit on where the study group is going.... LTE and IEEE > > 802.16 use a hub&spoke structure (for that matter, so does WiFi). > The > > LTE base station manages about four dozen MAC messages, the chief one > > is the UL-MAP (upload map in English) which tells each of the > > subscriber stations when it's that station's turn to transmit. The > > base station also negotiates entry for new subscribers -- ranging > > messages, X.509 cert exchange, etc. The processing load and the > > transmitting load on a base station is significantly higher than a > subscriber station. > > > > Our experience with IEEE 802.16 gear (LTE is a near-clone) is that > the > > hardware for both BS and SS is identical, only the software load > > changes. > > > > My students have hauled .16 gear, both BS and SS, out into the field, > > plugged them in and gotten them to work (we know if you drop the > > antenna off the back of the truck that it will break). At the layer > 3 > > interface, all the gear we've ever seen is doing ethernet forwarding > > so both SS and BS are passing ethernet frames out of the box, just > > like your cable modem at home. > > > > Cellphone implementations will tend to load additional functions > (like > > beam steering) onto base stations to avoid having to do so with > > subscriber stations (which may be embedded in cellphone handsets). > > The key diff between BS and SS here is electrical power usage -- a BS > > will drain the battery a lot faster. > > > > So the first question to ask is what would be the study group's > > criteria? You can already make a subscriber station, with a new > > software load, act like a base station. If you have an adequate > power > > supply (e.g. vehicle mount rather than handset), then we have this > > capability now and have had it for some years. What's new? > > > > The second question is what value this would be to emergency services > > (or ITS)? Simply putting up a layer 2 network segment only gets you > > layer 2 functionality -- all the rest of the applications are outside > > scope. DNS support? PKI white pages? SIP server? There's a lot > > left to do in a real-world usability exercise. > > > > > > > > On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: > >>>> While the working item is still a fair distance from realizing > >>>> standardization, I think it is worth mentioning that LTE Direct (a > >>>> peer-to-peer channel and symmetric transmission/reception mode) is > >>>> being proposed by Qualcomm. From my interviews with their > technical > >>>> team, I am very excited about the possibility of mobile node to > >>>> mobile node direct LTE link. If any of you are also interested, it > >>>> might be good to check in on their progress and offer your > comments. > >>> > >>> Certainly I (and a group of people locally) are interested in the > >>> use of LTE for direct communications. > >>> > >>> How would it be possible to check in on their progress and how > could > >>> we offer our comments? > >>> > >>> Alex > >> > >> I am not an expert on the 3GPP process, so rather than muddle about > and confuse things, I will include the following article which I hope > will offer clues. I believe that the standards body has agreed to > investigate whether a direct mode is worth standardizing (??). > >> > >> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte- > study > >> -20110928/ > >> > >> My connection to this program came from direct industry contact, so > I apologize for my obtuse response. > >> > >> Riley > >> _______________________________________________ > >> 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 Jul 31 12:52: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 88B3D21F896A; Tue, 31 Jul 2012 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, 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 EewkRNN7cygJ; Tue, 31 Jul 2012 12:51:59 -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 0F5A921F8966; Tue, 31 Jul 2012 12:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6919; q=dns/txt; s=iport; t=1343764319; x=1344973919; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eeeRktLybvATcfZVfXgy9hzTtZNfg+/Bixu+psL1WWk=; b=NCgMRvgx+/6IFjSKS0Y65OdIGqaRDM1amh2nDdc9SvpeektkvAE9dlWG vgDUaUp6VLzSloJ07GDJKxbfBEvBTsutZhcF9dVdpGBJ46vUtwdwOBzAR G12QM7gZrXnIqBPKn8mbkzo3TAEYQeZoQ/xcovPzuNbhdIteUho7tiRlv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAI2GFCtJXHA/2dsb2JhbABFuXuBB4IgAQEBAwEBAQEPAVUDAwsFCwIBCBguJwslAgQOBRoBB4dlBgubVqBsi0kFFoYOYAOVR4EUiXmDGoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="107165279" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2012 19:51:58 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6VJpwYG005590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 19:51:58 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 14:51:58 -0500 From: "Stan Ratliff (sratliff)" To: =?Windows-1252?Q?Francisco_Javier_Ros_Mu=F1oz?= Thread-Topic: [its] [manet] Scenarios, potential topics... Thread-Index: AQHNb0tByl2zgw1Y50aAQ4SJBVvDcpdEIR2A Date: Tue, 31 Jul 2012 19:51:57 +0000 Message-ID: <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.242.181] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.001 x-tm-as-result: No--49.279700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <6C1AC52E80CDD34F9DFB194806653D67@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , Alexandru Petrescu , "its@ietf.org" , manet , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 19:52:00 -0000 Francisco, On Jul 31, 2012, at 2:35 PM, Francisco Javier Ros Mu=F1oz wrote: > Hi Stan, >=20 > I guess that your comment refers to V2V communications (please correct me= if I misunderstood you). There are other issues in ITS that, in my opinion= , do not perfectly fit into the MANET WG (V2I among others). >=20 > For V2V, MANET routing solutions have been shown to perform poorly in veh= icular scenarios. There are tons of references out there, check e.g. [1]. I= n fact, most research in the field borrows concepts from geographic routing= and opportunistic communications. Standardization bodies like the ETSI hav= e also followed this path. Fair enough. But the "MANET" deployments I've been working on for a while n= ow are pretty much exactly documented by the "instrumented ambulance" case.= And I've also got V2V scenarios in these MANETs=85 so from where I'm sitti= ng, they look pretty much alike to me.=20 Regards, Stan >=20 > To summarize: although the work could be undertaken by the MANET WG, I fe= el that ITS features enough peculiarities to deserve a different (more focu= sed) WG. >=20 > [1] I. Khan and A. Qayyum, =93Performance evaluation of aodv and olsr in = highly fading vehicular ad hoc network environments,=94 in Proceedings of t= he 13th International Multitopic Conference (INMIC), December 2009, pp. 1= =965. >=20 > Regards, > fran >=20 > El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribi=F3: >=20 >> First off, I think the discussions on ITS are interesting, worthwhile, a= nd should continue. I wonder, though - aren't these scenarios essentially M= ANET's? I'm just asking whether one of the options here should be to pursue= the work within the MANET WG. >>=20 >> Regards, >> Stan >>=20 >> On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >>=20 >>>=20 >>> Riley, >>>=20 >>> This has been kicking around in the emergency services broadband >>> discussion. Most of the discussants are not long in understanding of >>> protocol stacks... But they ARE long in experiencing 'the tower' going >>> away and need to talk with 'that guy over there that I can see'. =20 >>>=20 >>> Qualcom only announced the study group news. This is not a product >>> announcement or even a proposed standard. >>>=20 >>> It appears that the alterations proposed would only affect layer 2 of >>> the LTE protocol. Totally agnostic about anything above layer 2. =20 >>>=20 >>> This leaves two questions open: can it be done usefully and scaleably? >>> and 2) what value is it? =20 >>>=20 >>>=20 >>> Speculating a bit on where the study group is going.... LTE and IEEE >>> 802.16 use a hub&spoke structure (for that matter, so does WiFi). The >>> LTE base station manages about four dozen MAC messages, the chief one i= s >>> the UL-MAP (upload map in English) which tells each of the subscriber >>> stations when it's that station's turn to transmit. The base station >>> also negotiates entry for new subscribers -- ranging messages, X.509 >>> cert exchange, etc. The processing load and the transmitting load on a >>> base station is significantly higher than a subscriber station. =20 >>>=20 >>> Our experience with IEEE 802.16 gear (LTE is a near-clone) is that the >>> hardware for both BS and SS is identical, only the software load >>> changes. =20 >>>=20 >>> My students have hauled .16 gear, both BS and SS, out into the field, >>> plugged them in and gotten them to work (we know if you drop the antenn= a >>> off the back of the truck that it will break). At the layer 3 >>> interface, all the gear we've ever seen is doing ethernet forwarding so >>> both SS and BS are passing ethernet frames out of the box, just like >>> your cable modem at home. =20 >>>=20 >>> Cellphone implementations will tend to load additional functions (like >>> beam steering) onto base stations to avoid having to do so with >>> subscriber stations (which may be embedded in cellphone handsets). The >>> key diff between BS and SS here is electrical power usage -- a BS will >>> drain the battery a lot faster. =20 >>>=20 >>> So the first question to ask is what would be the study group's >>> criteria? You can already make a subscriber station, with a new >>> software load, act like a base station. If you have an adequate power >>> supply (e.g. vehicle mount rather than handset), then we have this >>> capability now and have had it for some years. What's new? =20 >>>=20 >>> The second question is what value this would be to emergency services >>> (or ITS)? Simply putting up a layer 2 network segment only gets you >>> layer 2 functionality -- all the rest of the applications are outside >>> scope. DNS support? PKI white pages? SIP server? There's a lot left >>> to do in a real-world usability exercise. =20 >>>=20 >>>=20 >>>=20 >>> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>>> While the working item is still a fair distance from realizing >>>>>> standardization, I think it is worth mentioning that LTE Direct (a >>>>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>>>> being proposed by Qualcomm. From my interviews with their technical >>>>>> team, I am very excited about the possibility of mobile node to >>>>>> mobile node direct LTE link. If any of you are also interested, it=20 >>>>>> might be good to check in on their progress and offer your comments. >>>>>=20 >>>>> Certainly I (and a group of people locally) are interested in the use >>>>> of LTE for direct communications. >>>>>=20 >>>>> How would it be possible to check in on their progress and how could = we >>>>> offer our comments? >>>>>=20 >>>>> Alex >>>>=20 >>>> I am not an expert on the 3GPP process, so rather than muddle about an= d confuse things, I will include the following article which I hope will of= fer clues. I believe that the standards body has agreed to investigate whet= her a direct mode is worth standardizing (??). >>>>=20 >>>> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-= 20110928/ >>>>=20 >>>> My connection to this program came from direct industry contact, so I = apologize for my obtuse response. >>>>=20 >>>> Riley >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 > -- > Francisco J. Ros, PhD > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ >=20 >=20 >=20 >=20 From teco@inf-net.nl Tue Jul 31 13:32: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 A4BDE21F8950 for ; Tue, 31 Jul 2012 13:32:12 -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, 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 3rsAIj5ckOJ3 for ; Tue, 31 Jul 2012 13:32:11 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3C1321F8944 for ; Tue, 31 Jul 2012 13:32:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so7050223ggn.31 for ; Tue, 31 Jul 2012 13:32: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=15P+hblry5m5q1BLYK7v1Eitmu/8WY+O6ikc0H3Ucc0=; b=NLnydrYq/AS0duEF3qArlyoUTlDp7foxBCF0EW/HDkHXVMCayE6zIy7+hLcq+dfIf8 NtSaN6FHnHGu9U3+Tcg1SNyLmO5MXmYZgAhMS/RvpLGMKBD2GuMGVr3Knl+AvelvDU2J OSDE1bcE1IgmfQryACMGHvWx1gRVacPRW7TZv/wNEOd+4BGRkyCzMoVobIv+7NAiWmcl 4p5XwnXRfuabs4bQPNBWiTMb7+Q34I57CXvDrNUuQYieg4V1ZLtORkmRSyMSB6UfK0Q8 E1fb+a3+PTmt/rtUw+DTSUco2xrbIO4wYFaGyuNoxsm4Ij/JDd1Ix/C1dDgBO+iMafeP 61Lw== Received: by 10.66.89.228 with SMTP id br4mr35028752pab.6.1343766730637; Tue, 31 Jul 2012 13:32:10 -0700 (PDT) Received: from dhcp-1333.meeting.ietf.org (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id pg9sm969212pbb.26.2012.07.31.13.32.08 (version=SSLv3 cipher=OTHER); Tue, 31 Jul 2012 13:32:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 31 Jul 2012 22:32:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <846E85B8-016E-48DC-B3FA-C3F7AE82D4AE@inf-net.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkTYsYmzNPE7D/Jl43RqEjxjpbAQ1DoKcl+6wYq2ph4kYWAW8VfzrXH2MCTzs2KPOMwxMG+ Cc: manet List , "Velt, R. \(Ronald\) in 't" Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 20:32:12 -0000 LLN and MANET share the characteristic that they are networks. LLN are not mobile/dynamic and ad hoc per se. I say they are=20 related to MANET. Either strongly or loosely, for what it matter. I am against adopting work that concurs with ROLL. I have=20 nothing against having LOADng as candidate for the MANET=20 reactive protocol. When LLN market accept it next to, or=20 instead of, RPL, so be it. Teco Op 31 jul. 2012, om 20:26 heeft Ulrich Herberg het volgende geschreven: > Ronald, >=20 > On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't = wrote: >=20 > >-----Original Message----- > >From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf > >Of Antonin Bas > >Sent: dinsdag 31 juli 2012 19:44 > >To: Ulrich Herberg > >Cc: manet; Abdussalam Baryun > >Subject: Re: [manet] Discussing LOADng suggestions > > > >According to MANET charter, > > > >The purpose of the MANET working group is to standardize IP routing > > protocol functionality suitable for wireless routing application = within > > both static and dynamic topologies with increased dynamics due to = node > > motion or other factors. >=20 > Strange wording, in my opinion. It seems to me that if the network = _topology_ is truly static, you do not need a routing protocol at all. >=20 >=20 > I agree. >=20 > =20 > (Note that just as the absence of movement does not imply a static = topology, a static topology does not imply stationary nodes). >=20 > > > >So I don't think MANETs are defined by mobility, but by "increased > >dynamics",which can be due to motion, but also to lossy links. >=20 > So why aren't they called ANETs? >=20 >=20 > Or DANET ("dynamic"). It just did not sound as nice when the term was = created. >=20 > Best > Ulrich >=20 >=20 > =20 >=20 > Ronald > > > >2012/7/31 Ulrich Herberg : > >> MANETs are not defined by mobility. It is rather about very dynamic > >> topologies. Otherwise, community networks such as FunkFeuer would = also > >> not be qualified as MANETs. > >> > >> Ulrich > >> > >> > >> On Tue, Jul 31, 2012 at 10:32 AM, Mukul Goyal = wrote: > >>> > >>> The wireless network of "fixed" temperature monitoring sensors and > >>> HVAC controllers in a building. This network is an LLN. Not sure = if > >>> it qualifies as a MANET (since nothing is mobile). > >>> > >>> Thanks > >>> Mukul > >>> > >>> ----- Original Message ----- > >>> From: "Henning Rogge" > >>> To: "Abdussalam Baryun" > >>> Cc: "manet" > >>> Sent: Tuesday, July 31, 2012 8:49:08 AM > >>> Subject: Re: [manet] Discussing LOADng suggestions > >>> > >>> On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun > >>> wrote: > >>> > IMHO this protocol was intended as for ROLL WG not for MANET WG, > >>> > but then changed its direction to MANET [3]. However, please = note > >>> > that > >>> > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. > >That > >>> > said, LOADng SHOULD specfy where is its limits. Then we can = discuss > >>> > adoption. > >>> > >>> Could you state an example what would be considered a LLN but not = a > >>> MANET. I normally consider LLNs a subset of what we call MANETs. > >>> > >>> 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 > >> > >> > >> > >> _______________________________________________ > >> 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 e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Tue Jul 31 14:48: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 0543421F88ED for ; Tue, 31 Jul 2012 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.399, 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 Abz9DDys9ntb for ; Tue, 31 Jul 2012 14:48:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E521F8904 for ; Tue, 31 Jul 2012 14:48:08 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6759880vcb.31 for ; Tue, 31 Jul 2012 14:48: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 :content-type; bh=0PMqzIGWgSnjPhmEiVxqyRNFWdo0D/I3hj04JXhZTZQ=; b=i9bewDbl0oDu7p5bR5/8Nh8IuWjRbZlWZgQ1xZC/GCYk3IqCqEJo/3hq41l26WoJA7 7VOn5d44xY3UvyZPtbUCmlLR1kUS5IeYrdM92PplwRfJ8ZBVyKHtmZ/me6Ujcnna73tO DrZnc1zBS2r7RTrt8d+PBgeBsrR+UoZLmJjWGURa93fjZTF/AKo8RmAHij316N/iqx6E K1PEZPj3SsDZvLo8+0SR9CPeiW8qQsrHlPyGj/wP6qMCpO7nvAE1MqcjSDtl0iBEKhV6 sX4XfarvJDFlTSwpJG2LGCDxFOrgIfEo/kGLyRvb3FbfMvUrsYtOkwfVfwPhvOalmS64 4ljQ== MIME-Version: 1.0 Received: by 10.52.94.172 with SMTP id dd12mr13292010vdb.62.1343771288231; Tue, 31 Jul 2012 14:48:08 -0700 (PDT) Received: by 10.58.94.40 with HTTP; Tue, 31 Jul 2012 14:48:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 14:48:08 -0700 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf307f342a4b5eed04c627221a Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 21:48:10 -0000 --20cf307f342a4b5eed04c627221a Content-Type: text/plain; charset=ISO-8859-1 I think a large set of WG comments and consensus input from the meeting was clear that the LLN needs to be deemphasized as the primary purpose if adopted as manet. See minutes when published. The verbage in the present document needs to emphasize more the MANET problem set as the fundamental direction and I think that can be accomplished. Since it derives somewhat from AODV MANET design I think that is relatively straightforward if the authors commit. I sensed agreement on this at the meeting. However, it should also pointed out why going beyond older AODV designs is helpful for manet problem areas such as improvements in heterogeneity support, simplification where sensible, improved control plane flooding, better IPv6 support, and a eventually clear border gateway specification (e.g., although there are several ways to do that in reactive cases but an initial approach should be specified). On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Thomas and All > > I am interested in LOADng and did discuss about it from May 2012 until > now. I gave comments [1] on LOADng but no respond so far, I asked from > before for more discussion but there was no, and hope that we don't > forget the past comments on any document in ietf. The LOADng SHOULD > specify use case that are related to MANET not LLN. I suggest that the > word LLN taken out of the name as well and specify mobility [1-2]. > > IMHO this protocol was intended as for ROLL WG not for MANET WG, but > then changed its direction to MANET [3]. However, please note that > *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > said, LOADng SHOULD specfy where is its limits. Then we can discuss > adoption. > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html > [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html > > thanking you, > AB > =========== > On 7/4/12, Abdussalam Baryun wrote: > > Hi Thomas, > > > >>Just for information, the coming version of LOADng will use 5444 > >> (cleanly). > > > > but last draft: does not use RFC5444 > > > > I am interested to know about the LOADng, while you requested its > > consideration in MANET, but we still not much discussed the status of > > the work, as now some participant and I thought that LOADng didn't use > > RFC5444. Please give us some input of updated issues. As was waiting > > for the new version which was expected within June as per one > > co-author discussion. Thanking you, > > > > Best Regards > > Abdussalam Baryun > > =============== > > > > To: "Dearlove, Christopher (UK)" > > Subject: Re: [manet] Status of DLEP-draft at Cisco? > > From: Thomas Heide Clausen > > > > Just for information, the coming version of LOADng will use 5444 > (cleanly). > > > > > > -- > > Thomas Heide Clausen > > http://www.thomasclausen.org > > ================================================ > >>Abdussalam, > > > >>we are aware that the LOADng draft needs some updates, before it could > > be considered by the MANET WG, notably support for RFC5444 and some > > editorial updates. We plan to work on these in the next days, and will > > submit a new revision likely next week. So, just stay tuned! > > > >>Best > >>Ulrich > > > > On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > > wrote: > >> On 5/29/12, JP Vasseur wrote: > >>> > >>> We already have two different WG: MANET and ROLL. > >>> > >> > >> Yes we know. That is why LOADng authors should choose either to serve > >> LLN that is considered by ROLL WG or they choose serving MANET, and it > >> is considered by MANET WG. But the question is which suggestion option > >> do you think is better for LOADng-draft? > >> > >>>MANET is tasked, amongst other, to publish a reactive > >>>routing protocol. > >> > >> MANET is tasked to publish routing protocols that serve the MANET > >> network. IMO, MANET-WG is not tasked to publish protocols serving only > >> LLN just because the protocol is reactive. Please note that LOADng > >> protocol does not even mention MANET nor mobile routers in its draft, > >> which confuses its purpose, the authors should look into that. > >> > >> Abdussalam Baryun > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf307f342a4b5eed04c627221a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think a large set of WG comments and consensus input from the meeting was= clear that the LLN needs to be deemphasized as the primary purpose if adop= ted as manet. See minutes when published.

The verbage in the present= document needs to emphasize more the MANET problem set as the fundamental = direction and I think that can be accomplished.=A0 Since it derives somewha= t from AODV MANET design I think that is relatively straightforward if the = authors commit.=A0 I sensed agreement on this at the meeting. However, it s= hould also pointed out why going beyond older AODV designs is helpful for m= anet problem areas such as improvements in heterogeneity support, simplific= ation where sensible, improved control plane flooding, better IPv6 support,= and a eventually clear border gateway specification (e.g., although there = are several ways to do that in reactive cases but an initial approach shoul= d be specified).

On Tue, Jul 31, 2012 at 6:45 AM, Abdussalam = Baryun <abdussalambaryun@gmail.com> wrote:
Hi Thomas and All

I am interested in LOADng and did discuss about it from May 2012 until
now. I gave comments [1] on LOADng but no respond so far, I asked from
before for more discussion but there was no, and hope that we don't
forget the past comments on any document in ietf. The LOADng SHOULD
specify use case that are related to MANET not LLN. I suggest that the
word LLN taken out of the name as well and specify mobility [1-2].

IMHO this protocol was intended as for ROLL WG not for MANET WG, but
then changed its direction to MANET [3]. However, please note that
*ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That
said, LOADng SHOULD specfy where is its limits. Then we can discuss
adoption.

[1] http://www.ietf.org/mail-archive/web/manet/current/= msg12924.html
[2] http://www.ietf.org/mail-archive/web/manet/current/= msg12928.html
[3] http://www.ietf.org/mail-archive/web/manet/current/= msg12933.html

thanking you,
AB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On 7/4/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> Hi Thomas,
>
>>Just for information, the coming version of LOADng will use 5444 >> (cleanly).
>
> but <draft-clausen-lln-loadng-04> last draft: does not use RFC54= 44
>
> I am interested to know about the LOADng, while you requested its
> consideration in MANET, but we still not much discussed the status of<= br> > the work, as now some participant and I thought that LOADng didn't= use
> RFC5444. Please give us some input of updated issues. As was waiting > for the new version which was expected within June as per one
> co-author discussion. Thanking you,
>
> Best Regards
> Abdussalam Baryun
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> To: "Dearlove, Christopher (UK)" <Chris.Dearlove at baesystems.com>
> Subject: Re: [manet] Status of DLEP-draft at Cisco?
> From: Thomas Heide Clausen <ietf at thomasclausen.org>
>
> Just for information, the coming version of LOADng will use 5444 (clea= nly).
>
>
> --
> Thomas Heide Clausen
> http://www.= thomasclausen.org
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>Abdussalam,
>
>>we are aware that the LOADng draft needs some updates, before it co= uld
> be considered by the MANET WG, notably support for RFC5444 and some > editorial updates. We plan to work on these in the next days, and will=
> submit a new revision likely next week. So, just stay tuned!
>
>>Best
>>Ulrich
>
> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun
> <abdussalambaryun at gmail.com> wrote:
>> On 5/29/12, JP Vasseur <jpv at cisco.com> wrote:
>>>
>>> We already have two different WG: MANET and ROLL.
>>>
>>
>> Yes we know. That is why LOADng authors should choose either to se= rve
>> LLN that is considered by ROLL WG or they choose serving MANET, an= d it
>> is considered by MANET WG. But the question is which suggestion op= tion
>> do you think is better for LOADng-draft?
>>
>>>MANET is tasked, amongst other, to publish a reactive
>>>routing protocol.
>>
>> MANET is tasked to publish routing protocols that serve the MANET<= br> >> network. IMO, MANET-WG is not tasked to publish protocols serving = only
>> LLN just because the protocol is reactive. Please note that LOADng=
>> protocol does not even mention MANET nor mobile routers in its dra= ft,
>> which confuses its purpose, the authors should look into that.
>>
>> Abdussalam Baryun
>
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--20cf307f342a4b5eed04c627221a-- From hrogge@googlemail.com Tue Jul 31 15:33: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 3E8EF21F86D3 for ; Tue, 31 Jul 2012 15:33:01 -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 lPStHnidULZ6 for ; Tue, 31 Jul 2012 15:33:00 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA521F85C7 for ; Tue, 31 Jul 2012 15:33:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so7170509yhq.31 for ; Tue, 31 Jul 2012 15:33:00 -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=GW51TTUNL1vhglzAt2vaGMi0/Z+bVoECxc4EpxTViPg=; b=TG1fPgpq2+2IS+AMQ/tJH29bGUBh4nbKgkyRjV6pkjR1dsrIOB7+u25A4PhOUA257R reR0pJD1TWNEdjSCd02Vy2CnrZO02z6f4npoiIguCMM10g9C1dDpzyN+Xpbu6qxUnJ7T vlUv1us6EytAeKa77Khn3Uk5EY9MnCGQgKl7iGKrfT2wryWIqejMHkMY0K4GoMa5plMf qzr6t2qS17Sfvnc9Lmvp2hNlbunAHaeKnpNqEYwS0Wmuyq2D5KJLCddY2hh2IxkqA5Ew Awze63iqltuOQ4rGrsUVxZ007JOsgleUmNk6ydCIWe+auDwae452UFzkHJgzvRVcwvSc poeQ== Received: by 10.66.73.193 with SMTP id n1mr6771643pav.81.1343773979729; Tue, 31 Jul 2012 15:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.241.131 with HTTP; Tue, 31 Jul 2012 15:32:39 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> From: Henning Rogge Date: Tue, 31 Jul 2012 15:32:39 -0700 Message-ID: To: "Velt, R. (Ronald) in 't" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 22:33:01 -0000 On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't wrote: > Strange wording, in my opinion. It seems to me that if the network _topol= ogy_ is truly static, you do not need a routing protocol at all. (Note that= just as the absence of movement does not imply a static topology, a static= topology does not imply stationary nodes). I think you are underestimating the amount of dynamics in large stationary radio network, especially built on 802.11 technology. We need MANET protocols in this community networks as Funkfeuer. 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 fjros@um.es Tue Jul 31 15:41: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 784C121F87FB; Tue, 31 Jul 2012 15:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, 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 m4PuIcz08Etw; Tue, 31 Jul 2012 15:41:33 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id E4B0121F87F8; Tue, 31 Jul 2012 15:41:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id E56D55369E; Wed, 1 Aug 2012 00:41:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GElJkoI2awKa; Wed, 1 Aug 2012 00:41:30 +0200 (CEST) Received: from [192.168.0.201] (unknown [178.139.167.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon11.um.es (Postfix) with ESMTPSA id 816F5535DD; Wed, 1 Aug 2012 00:41:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> Date: Wed, 1 Aug 2012 00:41:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B42D761-ECFF-4918-A61E-54D49C73EA54@um.es> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1084) Cc: Rex Buddenberg , Alexandru Petrescu , "its@ietf.org" , manet , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 22:41:34 -0000 Stan, El 31/07/2012, a las 21:51, Stan Ratliff (sratliff) escribi=F3: > Francisco, >=20 > On Jul 31, 2012, at 2:35 PM, Francisco Javier Ros Mu=F1oz wrote: >=20 >> Hi Stan, >>=20 >> I guess that your comment refers to V2V communications (please = correct me if I misunderstood you). There are other issues in ITS that, = in my opinion, do not perfectly fit into the MANET WG (V2I among = others). >>=20 >> For V2V, MANET routing solutions have been shown to perform poorly in = vehicular scenarios. There are tons of references out there, check e.g. = [1]. In fact, most research in the field borrows concepts from = geographic routing and opportunistic communications. Standardization = bodies like the ETSI have also followed this path. >=20 > Fair enough. But the "MANET" deployments I've been working on for a = while now are pretty much exactly documented by the "instrumented = ambulance" case. And I've also got V2V scenarios in these MANETs=85 so = from where I'm sitting, they look pretty much alike to me.=20 >=20 Thanks for sharing this, I'm glad to see that there are successful use = cases. If they are publicly documented, I'd be happy to take a look to = them. However, I'm not familiar with the instrumented ambulance case, = except for the email exchanges that have taken place in this list. As I = understand it, such use case mainly involves intra-vehicular = communications along with direct V2I. Unless you're thinking about = V2V2I, road-side units attached to the Internet, or something like that, = I can't see what multi-hop MANET protocols would help here (sure I'm = missing something). By the way, I couldn't make last meeting and I'm not really sure whether = multi-hop V2V protocols are being considered as a work item within ITS. = I'll just stay tuned to see how all this evolves. Regards, fran > Regards, > Stan >=20 >=20 >>=20 >> To summarize: although the work could be undertaken by the MANET WG, = I feel that ITS features enough peculiarities to deserve a different = (more focused) WG. >>=20 >> [1] I. Khan and A. Qayyum, =93Performance evaluation of aodv and olsr = in highly fading vehicular ad hoc network environments,=94 in = Proceedings of the 13th International Multitopic Conference (INMIC), = December 2009, pp. 1=965. >>=20 >> Regards, >> fran >>=20 >> El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribi=F3: >>=20 >>> First off, I think the discussions on ITS are interesting, = worthwhile, and should continue. I wonder, though - aren't these = scenarios essentially MANET's? I'm just asking whether one of the = options here should be to pursue the work within the MANET WG. >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >>>=20 >>>>=20 >>>> Riley, >>>>=20 >>>> This has been kicking around in the emergency services broadband >>>> discussion. Most of the discussants are not long in understanding = of >>>> protocol stacks... But they ARE long in experiencing 'the tower' = going >>>> away and need to talk with 'that guy over there that I can see'. =20= >>>>=20 >>>> Qualcom only announced the study group news. This is not a product >>>> announcement or even a proposed standard. >>>>=20 >>>> It appears that the alterations proposed would only affect layer 2 = of >>>> the LTE protocol. Totally agnostic about anything above layer 2. =20= >>>>=20 >>>> This leaves two questions open: can it be done usefully and = scaleably? >>>> and 2) what value is it? =20 >>>>=20 >>>>=20 >>>> Speculating a bit on where the study group is going.... LTE and = IEEE >>>> 802.16 use a hub&spoke structure (for that matter, so does WiFi). = The >>>> LTE base station manages about four dozen MAC messages, the chief = one is >>>> the UL-MAP (upload map in English) which tells each of the = subscriber >>>> stations when it's that station's turn to transmit. The base = station >>>> also negotiates entry for new subscribers -- ranging messages, = X.509 >>>> cert exchange, etc. The processing load and the transmitting load = on a >>>> base station is significantly higher than a subscriber station. =20 >>>>=20 >>>> Our experience with IEEE 802.16 gear (LTE is a near-clone) is that = the >>>> hardware for both BS and SS is identical, only the software load >>>> changes. =20 >>>>=20 >>>> My students have hauled .16 gear, both BS and SS, out into the = field, >>>> plugged them in and gotten them to work (we know if you drop the = antenna >>>> off the back of the truck that it will break). At the layer 3 >>>> interface, all the gear we've ever seen is doing ethernet = forwarding so >>>> both SS and BS are passing ethernet frames out of the box, just = like >>>> your cable modem at home. =20 >>>>=20 >>>> Cellphone implementations will tend to load additional functions = (like >>>> beam steering) onto base stations to avoid having to do so with >>>> subscriber stations (which may be embedded in cellphone handsets). = The >>>> key diff between BS and SS here is electrical power usage -- a BS = will >>>> drain the battery a lot faster. =20 >>>>=20 >>>> So the first question to ask is what would be the study group's >>>> criteria? You can already make a subscriber station, with a new >>>> software load, act like a base station. If you have an adequate = power >>>> supply (e.g. vehicle mount rather than handset), then we have this >>>> capability now and have had it for some years. What's new? =20 >>>>=20 >>>> The second question is what value this would be to emergency = services >>>> (or ITS)? Simply putting up a layer 2 network segment only gets = you >>>> layer 2 functionality -- all the rest of the applications are = outside >>>> scope. DNS support? PKI white pages? SIP server? There's a lot = left >>>> to do in a real-world usability exercise. =20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>>>> While the working item is still a fair distance from realizing >>>>>>> standardization, I think it is worth mentioning that LTE Direct = (a >>>>>>> peer-to-peer channel and symmetric transmission/reception mode) = is >>>>>>> being proposed by Qualcomm. =46rom my interviews with their = technical >>>>>>> team, I am very excited about the possibility of mobile node to >>>>>>> mobile node direct LTE link. If any of you are also interested, = it=20 >>>>>>> might be good to check in on their progress and offer your = comments. >>>>>>=20 >>>>>> Certainly I (and a group of people locally) are interested in the = use >>>>>> of LTE for direct communications. >>>>>>=20 >>>>>> How would it be possible to check in on their progress and how = could we >>>>>> offer our comments? >>>>>>=20 >>>>>> Alex >>>>>=20 >>>>> I am not an expert on the 3GPP process, so rather than muddle = about and confuse things, I will include the following article which I = hope will offer clues. I believe that the standards body has agreed to = investigate whether a direct mode is worth standardizing (??). >>>>>=20 >>>>> = http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-2011= 0928/ >>>>>=20 >>>>> My connection to this program came from direct industry contact, = so I apologize for my obtuse response. >>>>>=20 >>>>> Riley >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>=20 >> -- >> Francisco J. Ros, PhD >> Dept. of Information and Communications Engineering >> University of Murcia, Murcia (Spain) >> http://masimum.inf.um.es/fjrm/ >>=20 >>=20 >>=20 >>=20 >=20 -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From sratliff@cisco.com Tue Jul 31 15:47: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 5D2C921F8910; Tue, 31 Jul 2012 15:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, 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 HCbYkCdkuHSf; Tue, 31 Jul 2012 15:47:39 -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 2D0A721F8911; Tue, 31 Jul 2012 15:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=8753; q=dns/txt; s=iport; t=1343774859; x=1344984459; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TZMbxeNCU8yzY7uIMKOd1IV3ULVHCXN6E6BUtFEIhpI=; b=RpaAl8GzDvdiBmz70Jxb07Mw3FnknfagrS2HtsQfglpR1YuzZ8sd2cd8 PzByRLm60ri/9+MZYSJYRT1ttV0nsmw22Xt4GuWyqlhrPGdgZI78p9R77 ydzSCDstIDTY8uW3heTpoj8BhAFZHWdnwh662mmxK/YjzuOHvfD89LYuU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFFfGFCtJV2b/2dsb2JhbABFuXuBB4IgAQEBAwEBAQEPAVUDAwsFCwIBCBguJwslAgQOBRoBB4dlBgubWqBli0kFFoYOYAOVR4EUiXmDGoFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,689,1336348800"; d="scan'208";a="107211588" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2012 22:47:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6VMlcj3020199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 22:47:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.180]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 17:47:38 -0500 From: "Stan Ratliff (sratliff)" To: =?Windows-1252?Q?Francisco_Javier_Ros_Mu=F1oz?= Thread-Topic: [its] [manet] Scenarios, potential topics... Thread-Index: AQHNb0tByl2zgw1Y50aAQ4SJBVvDcpdEIR2AgAAvSICAAAHMgA== Date: Tue, 31 Jul 2012 22:47:37 +0000 Message-ID: References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> <1B42D761-ECFF-4918-A61E-54D49C73EA54@um.es> In-Reply-To: <1B42D761-ECFF-4918-A61E-54D49C73EA54@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.220.86] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.001 x-tm-as-result: No--61.102000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <8328C4D312F9B4428F46C5E56334F603@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , Alexandru Petrescu , "its@ietf.org" , manet , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 22:47:40 -0000 Francisco,=20 On Jul 31, 2012, at 6:41 PM, Francisco Javier Ros Mu=F1oz wrote: > Stan, >=20 > El 31/07/2012, a las 21:51, Stan Ratliff (sratliff) escribi=F3: >=20 >> Francisco, >>=20 >> On Jul 31, 2012, at 2:35 PM, Francisco Javier Ros Mu=F1oz wrote: >>=20 >>> Hi Stan, >>>=20 >>> I guess that your comment refers to V2V communications (please correct = me if I misunderstood you). There are other issues in ITS that, in my opini= on, do not perfectly fit into the MANET WG (V2I among others). >>>=20 >>> For V2V, MANET routing solutions have been shown to perform poorly in v= ehicular scenarios. There are tons of references out there, check e.g. [1].= In fact, most research in the field borrows concepts from geographic routi= ng and opportunistic communications. Standardization bodies like the ETSI h= ave also followed this path. >>=20 >> Fair enough. But the "MANET" deployments I've been working on for a whil= e now are pretty much exactly documented by the "instrumented ambulance" ca= se. And I've also got V2V scenarios in these MANETs=85 so from where I'm si= tting, they look pretty much alike to me.=20 >>=20 > Thanks for sharing this, I'm glad to see that there are successful use ca= ses. If they are publicly documented, I'd be happy to take a look to them. = However, I'm not familiar with the instrumented ambulance case, except for = the email exchanges that have taken place in this list. As I understand it,= such use case mainly involves intra-vehicular communications along with di= rect V2I. Unless you're thinking about V2V2I, road-side units attached to t= he Internet, or something like that, I can't see what multi-hop MANET proto= cols would help here (sure I'm missing something). >=20 There's not a lot of documentation on my deployments, unfortunately. They d= o require V2I, but also V2V. The primary uses for V2V are VoIP, and other c= ollaboration tools. The V2V communication is what compels employment of MAN= ET protocols.=20 Regards, Stan > By the way, I couldn't make last meeting and I'm not really sure whether = multi-hop V2V protocols are being considered as a work item within ITS. I'l= l just stay tuned to see how all this evolves. >=20 > Regards, > fran >=20 >> Regards, >> Stan >>=20 >>=20 >>>=20 >>> To summarize: although the work could be undertaken by the MANET WG, I = feel that ITS features enough peculiarities to deserve a different (more fo= cused) WG. >>>=20 >>> [1] I. Khan and A. Qayyum, =93Performance evaluation of aodv and olsr i= n highly fading vehicular ad hoc network environments,=94 in Proceedings of= the 13th International Multitopic Conference (INMIC), December 2009, pp. 1= =965. >>>=20 >>> Regards, >>> fran >>>=20 >>> El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribi=F3: >>>=20 >>>> First off, I think the discussions on ITS are interesting, worthwhile,= and should continue. I wonder, though - aren't these scenarios essentially= MANET's? I'm just asking whether one of the options here should be to purs= ue the work within the MANET WG. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >>>>=20 >>>>>=20 >>>>> Riley, >>>>>=20 >>>>> This has been kicking around in the emergency services broadband >>>>> discussion. Most of the discussants are not long in understanding of >>>>> protocol stacks... But they ARE long in experiencing 'the tower' goi= ng >>>>> away and need to talk with 'that guy over there that I can see'. =20 >>>>>=20 >>>>> Qualcom only announced the study group news. This is not a product >>>>> announcement or even a proposed standard. >>>>>=20 >>>>> It appears that the alterations proposed would only affect layer 2 of >>>>> the LTE protocol. Totally agnostic about anything above layer 2. =20 >>>>>=20 >>>>> This leaves two questions open: can it be done usefully and scaleably= ? >>>>> and 2) what value is it? =20 >>>>>=20 >>>>>=20 >>>>> Speculating a bit on where the study group is going.... LTE and IEEE >>>>> 802.16 use a hub&spoke structure (for that matter, so does WiFi). Th= e >>>>> LTE base station manages about four dozen MAC messages, the chief one= is >>>>> the UL-MAP (upload map in English) which tells each of the subscriber >>>>> stations when it's that station's turn to transmit. The base station >>>>> also negotiates entry for new subscribers -- ranging messages, X.509 >>>>> cert exchange, etc. The processing load and the transmitting load on= a >>>>> base station is significantly higher than a subscriber station. =20 >>>>>=20 >>>>> Our experience with IEEE 802.16 gear (LTE is a near-clone) is that th= e >>>>> hardware for both BS and SS is identical, only the software load >>>>> changes. =20 >>>>>=20 >>>>> My students have hauled .16 gear, both BS and SS, out into the field, >>>>> plugged them in and gotten them to work (we know if you drop the ante= nna >>>>> off the back of the truck that it will break). At the layer 3 >>>>> interface, all the gear we've ever seen is doing ethernet forwarding = so >>>>> both SS and BS are passing ethernet frames out of the box, just like >>>>> your cable modem at home. =20 >>>>>=20 >>>>> Cellphone implementations will tend to load additional functions (lik= e >>>>> beam steering) onto base stations to avoid having to do so with >>>>> subscriber stations (which may be embedded in cellphone handsets). T= he >>>>> key diff between BS and SS here is electrical power usage -- a BS wil= l >>>>> drain the battery a lot faster. =20 >>>>>=20 >>>>> So the first question to ask is what would be the study group's >>>>> criteria? You can already make a subscriber station, with a new >>>>> software load, act like a base station. If you have an adequate powe= r >>>>> supply (e.g. vehicle mount rather than handset), then we have this >>>>> capability now and have had it for some years. What's new? =20 >>>>>=20 >>>>> The second question is what value this would be to emergency services >>>>> (or ITS)? Simply putting up a layer 2 network segment only gets you >>>>> layer 2 functionality -- all the rest of the applications are outside >>>>> scope. DNS support? PKI white pages? SIP server? There's a lot le= ft >>>>> to do in a real-world usability exercise. =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>>>>> While the working item is still a fair distance from realizing >>>>>>>> standardization, I think it is worth mentioning that LTE Direct (a >>>>>>>> peer-to-peer channel and symmetric transmission/reception mode) is >>>>>>>> being proposed by Qualcomm. From my interviews with their technica= l >>>>>>>> team, I am very excited about the possibility of mobile node to >>>>>>>> mobile node direct LTE link. If any of you are also interested, it= =20 >>>>>>>> might be good to check in on their progress and offer your comment= s. >>>>>>>=20 >>>>>>> Certainly I (and a group of people locally) are interested in the u= se >>>>>>> of LTE for direct communications. >>>>>>>=20 >>>>>>> How would it be possible to check in on their progress and how coul= d we >>>>>>> offer our comments? >>>>>>>=20 >>>>>>> Alex >>>>>>=20 >>>>>> I am not an expert on the 3GPP process, so rather than muddle about = and confuse things, I will include the following article which I hope will = offer clues. I believe that the standards body has agreed to investigate wh= ether a direct mode is worth standardizing (??). >>>>>>=20 >>>>>> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-stud= y-20110928/ >>>>>>=20 >>>>>> My connection to this program came from direct industry contact, so = I apologize for my obtuse response. >>>>>>=20 >>>>>> Riley >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>>=20 >>> -- >>> Francisco J. Ros, PhD >>> Dept. of Information and Communications Engineering >>> University of Murcia, Murcia (Spain) >>> http://masimum.inf.um.es/fjrm/ >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > -- > Francisco J. Ros, PhD > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ >=20 >=20 >=20 >=20 From alexandru.petrescu@gmail.com Tue Jul 31 15:56: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 87B9211E813A; Tue, 31 Jul 2012 15:56:08 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.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 KRzjHSvzxqNZ; Tue, 31 Jul 2012 15:56:07 -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 4CF0121F88F4; Tue, 31 Jul 2012 15:56:07 -0700 (PDT) Received: by yenq13 with SMTP id q13so7206842yen.31 for ; Tue, 31 Jul 2012 15:56:06 -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:content-type:content-transfer-encoding; bh=9+jNsIvVjtdKs3UOwDJxQ0xZGJofmcd0upynvt8Rc0M=; b=RCNHV1EnwUWPm6wfyUBuOEv+vK3gm3GoOMVP8kT/wXz13pYqqCyWtIV+gP/CDNE5uD y3yKF1KTrAM4gIt8EuYPAAnhXpd2O6Tvnag0VfrYF8EFMvBo5FTYnbVhWJu5Tq80mopn T5z0Y94fRm9gOEsrsm3fiB4pAl7vyLwR+nmHdUcWYLb9TtM9J8615YQHcmX/8TowKpW4 4Nq6aYIKMxPKd8xfOrxlhbnn70lUxInCDH+LYXb34VumYodcIHIAwIApPC7I7Zud/2+/ 5pWcqqAElVbCBAXoONZxtcYZXY8c4V+iH5MuIM7jn+xwe0xnz00We1xOI3t543qRQhNl kRzQ== Received: by 10.50.158.195 with SMTP id ww3mr2133351igb.52.1343775366482; Tue, 31 Jul 2012 15:56:06 -0700 (PDT) Received: from [192.168.11.229] ([64.114.255.126]) by mx.google.com with ESMTPS id wm7sm1643949igb.6.2012.07.31.15.56.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 15:56:05 -0700 (PDT) Message-ID: <5018627D.7020107@gmail.com> Date: Tue, 31 Jul 2012 15:55:57 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?windows-1252?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> <1B42D761-ECFF-4918-A61E-54D49C73EA54@um.es> In-Reply-To: <1B42D761-ECFF-4918-A61E-54D49C73EA54@um.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , "its@ietf.org" , manet , "Stan Ratliff \(sratliff\)" , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 22:56:08 -0000 Le 31/07/2012 15:41, Francisco Javier Ros Muñoz a écrit : > Stan, > > El 31/07/2012, a las 21:51, Stan Ratliff (sratliff) escribió: > >> Francisco, >> >> On Jul 31, 2012, at 2:35 PM, Francisco Javier Ros Muñoz wrote: >> >>> Hi Stan, >>> >>> I guess that your comment refers to V2V communications (please >>> correct me if I misunderstood you). There are other issues in >>> ITS that, in my opinion, do not perfectly fit into the MANET WG >>> (V2I among others). >>> >>> For V2V, MANET routing solutions have been shown to perform >>> poorly in vehicular scenarios. There are tons of references out >>> there, check e.g. [1]. In fact, most research in the field >>> borrows concepts from geographic routing and opportunistic >>> communications. Standardization bodies like the ETSI have also >>> followed this path. >> >> Fair enough. But the "MANET" deployments I've been working on for >> a while now are pretty much exactly documented by the >> "instrumented ambulance" case. And I've also got V2V scenarios in >> these MANETs… so from where I'm sitting, they look pretty much >> alike to me. >> > Thanks for sharing this, I'm glad to see that there are successful > use cases. If they are publicly documented, I'd be happy to take a > look to them. However, I'm not familiar with the instrumented > ambulance case, except for the email exchanges that have taken place > in this list. As I understand it, such use case mainly involves > intra-vehicular communications along with direct V2I. Unless you're > thinking about V2V2I, road-side units attached to the Internet, or > something like that, I can't see what multi-hop MANET protocols > would help here (sure I'm missing something). I tend to agree. The instrumented ambulance use cases mentioned here are mostly V2I unless V2V2I. There may exist though ambulances that may need to talk just to the police car nearby in order to exchange health data and police file. At an incident scene (accident on highway) this may prove useful. > By the way, I couldn't make last meeting and I'm not really sure > whether multi-hop V2V protocols are being considered as a work item > within ITS. I'll just stay tuned to see how all this evolves. Well... depends what is meant by multihop. A connection from a laptop in a vehicle to a server in another vehicle nearby, through each vehicle's mobile router, is already a 3-hop communication. To me this _is_ multihop. However, other oppinions tend to see 'multihop' as more than just vehicles nearby. Maybe through specialized vehicles used to extend the range. As for consideration, there are at least two different partners seriously considering to work on this V2V communication at IETF (maybe ITS) and also contributing it to other SDO and back. Alex > > Regards, fran > >> Regards, Stan >> >> >>> >>> To summarize: although the work could be undertaken by the MANET >>> WG, I feel that ITS features enough peculiarities to deserve a >>> different (more focused) WG. >>> >>> [1] I. Khan and A. Qayyum, “Performance evaluation of aodv and >>> olsr in highly fading vehicular ad hoc network environments,” in >>> Proceedings of the 13th International Multitopic Conference >>> (INMIC), December 2009, pp. 1–5. >>> >>> Regards, fran >>> >>> El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribió: >>> >>>> First off, I think the discussions on ITS are interesting, >>>> worthwhile, and should continue. I wonder, though - aren't >>>> these scenarios essentially MANET's? I'm just asking whether >>>> one of the options here should be to pursue the work within >>>> the MANET WG. >>>> >>>> Regards, Stan >>>> >>>> On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >>>> >>>>> >>>>> Riley, >>>>> >>>>> This has been kicking around in the emergency services >>>>> broadband discussion. Most of the discussants are not long >>>>> in understanding of protocol stacks... But they ARE long in >>>>> experiencing 'the tower' going away and need to talk with >>>>> 'that guy over there that I can see'. >>>>> >>>>> Qualcom only announced the study group news. This is not a >>>>> product announcement or even a proposed standard. >>>>> >>>>> It appears that the alterations proposed would only affect >>>>> layer 2 of the LTE protocol. Totally agnostic about >>>>> anything above layer 2. >>>>> >>>>> This leaves two questions open: can it be done usefully and >>>>> scaleably? and 2) what value is it? >>>>> >>>>> >>>>> Speculating a bit on where the study group is going.... LTE >>>>> and IEEE 802.16 use a hub&spoke structure (for that matter, >>>>> so does WiFi). The LTE base station manages about four >>>>> dozen MAC messages, the chief one is the UL-MAP (upload map >>>>> in English) which tells each of the subscriber stations when >>>>> it's that station's turn to transmit. The base station also >>>>> negotiates entry for new subscribers -- ranging messages, >>>>> X.509 cert exchange, etc. The processing load and the >>>>> transmitting load on a base station is significantly higher >>>>> than a subscriber station. >>>>> >>>>> Our experience with IEEE 802.16 gear (LTE is a near-clone) >>>>> is that the hardware for both BS and SS is identical, only >>>>> the software load changes. >>>>> >>>>> My students have hauled .16 gear, both BS and SS, out into >>>>> the field, plugged them in and gotten them to work (we know >>>>> if you drop the antenna off the back of the truck that it >>>>> will break). At the layer 3 interface, all the gear we've >>>>> ever seen is doing ethernet forwarding so both SS and BS are >>>>> passing ethernet frames out of the box, just like your cable >>>>> modem at home. >>>>> >>>>> Cellphone implementations will tend to load additional >>>>> functions (like beam steering) onto base stations to avoid >>>>> having to do so with subscriber stations (which may be >>>>> embedded in cellphone handsets). The key diff between BS >>>>> and SS here is electrical power usage -- a BS will drain the >>>>> battery a lot faster. >>>>> >>>>> So the first question to ask is what would be the study >>>>> group's criteria? You can already make a subscriber >>>>> station, with a new software load, act like a base station. >>>>> If you have an adequate power supply (e.g. vehicle mount >>>>> rather than handset), then we have this capability now and >>>>> have had it for some years. What's new? >>>>> >>>>> The second question is what value this would be to emergency >>>>> services (or ITS)? Simply putting up a layer 2 network >>>>> segment only gets you layer 2 functionality -- all the rest >>>>> of the applications are outside scope. DNS support? PKI >>>>> white pages? SIP server? There's a lot left to do in a >>>>> real-world usability exercise. >>>>> >>>>> >>>>> >>>>> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>>>>> While the working item is still a fair distance from >>>>>>>> realizing standardization, I think it is worth >>>>>>>> mentioning that LTE Direct (a peer-to-peer channel and >>>>>>>> symmetric transmission/reception mode) is being >>>>>>>> proposed by Qualcomm. From my interviews with their >>>>>>>> technical team, I am very excited about the >>>>>>>> possibility of mobile node to mobile node direct LTE >>>>>>>> link. If any of you are also interested, it might be >>>>>>>> good to check in on their progress and offer your >>>>>>>> comments. >>>>>>> >>>>>>> Certainly I (and a group of people locally) are >>>>>>> interested in the use of LTE for direct communications. >>>>>>> >>>>>>> How would it be possible to check in on their progress >>>>>>> and how could we offer our comments? >>>>>>> >>>>>>> Alex >>>>>> >>>>>> I am not an expert on the 3GPP process, so rather than >>>>>> muddle about and confuse things, I will include the >>>>>> following article which I hope will offer clues. I believe >>>>>> that the standards body has agreed to investigate whether >>>>>> a direct mode is worth standardizing (??). >>>>>> >>>>>> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20110928/ >>>>>> >>>>>> >>>>>> >>>>>> My connection to this program came from direct industry contact, so I apologize for my obtuse response. >>>>>> >>>>>> Riley _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> -- Francisco J. Ros, PhD Dept. of Information and Communications >>> Engineering University of Murcia, Murcia (Spain) >>> http://masimum.inf.um.es/fjrm/ >>> >>> >>> >>> >> > > -- Francisco J. Ros, PhD Dept. of Information and Communications > Engineering University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > From alexandru.petrescu@gmail.com Tue Jul 31 16:05: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 0D29A21F8894; Tue, 31 Jul 2012 16:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.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 3EPCmZ2Flkug; Tue, 31 Jul 2012 16:05:26 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB15421F8795; Tue, 31 Jul 2012 16:05:25 -0700 (PDT) Received: by ghbg16 with SMTP id g16so7170526ghb.31 for ; Tue, 31 Jul 2012 16:05:25 -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:content-type:content-transfer-encoding; bh=eYX4dNKvuEZRkI7bk1l8Iug+Hx0lFwUknSJyohbwTjA=; b=UTvunvPnye7UaHIsDmjt2/Gwxgrla1W9QrIFbH+KVgMVwNwoqEIAigVN0wNWTQtwTi kEFNLWczfvJe2XigkEcbaWWJhRo4DHqkbPZjBlPq9MR+kiaji0KYEGjfuxfmV/Wf1BP8 C3Z/35UpS2utYlIgu69lnR9AZIcT7ggbHgmMEasuSBmVD6fPp+TsvByIBW0bTw6fujTN avywGcfS2mfyVdjPTzzhlEcR3USE+6xkZJbQlVujCRQ8Da5lX82NuHMhkJQtPfIEJEPm LgUJjpFW3QHN3NzoxjAUZWzOYToT/Cbv9uVQkCt0Qd7g5f5YwIEor8ZZpnzaaBw2QJ3f pb5A== Received: by 10.50.6.163 with SMTP id c3mr3451705iga.35.1343775925167; Tue, 31 Jul 2012 16:05:25 -0700 (PDT) Received: from [192.168.11.229] ([64.114.255.126]) by mx.google.com with ESMTPS id z3sm10629617igc.7.2012.07.31.16.05.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 16:05:24 -0700 (PDT) Message-ID: <501864AC.9040406@gmail.com> Date: Tue, 31 Jul 2012 16:05:16 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> <5016C4DD.3090603@gmail.com> <3D05610F3AC2E047AACAA68F63DF908D379D28E360@EXMBX13.exchhosting.com> <1343752185.981.856.camel@localhost.localdomain> <983198B7-F639-454D-85F6-F2F97CCD764D@cisco.com> <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> In-Reply-To: <174DB26F-BEED-4736-9953-6081464A89E8@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , "its@ietf.org" , manet , Abdussalam Baryun Subject: Re: [manet] [its] Scenarios, potential topics... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 23:05:27 -0000 Le 31/07/2012 12:51, Stan Ratliff (sratliff) a écrit : > Francisco, > > On Jul 31, 2012, at 2:35 PM, Francisco Javier Ros Muñoz wrote: > >> Hi Stan, >> >> I guess that your comment refers to V2V communications (please >> correct me if I misunderstood you). There are other issues in ITS >> that, in my opinion, do not perfectly fit into the MANET WG (V2I >> among others). >> >> For V2V, MANET routing solutions have been shown to perform poorly >> in vehicular scenarios. There are tons of references out there, >> check e.g. [1]. In fact, most research in the field borrows >> concepts from geographic routing and opportunistic communications. >> Standardization bodies like the ETSI have also followed this path. > > Fair enough. But the "MANET" deployments I've been working on for a > while now are pretty much exactly documented by the "instrumented > ambulance" case. And I've also got V2V scenarios in these MANETs… so > from where I'm sitting, they look pretty much alike to me. Excuse me for interfering here. This is a discussion that should take place and to which we can contribute. In a sense yes, MANET protocols tend to be adapted for use cases of vehicular communications. This could be discussed further in order to identify whether MANET protocols are adapted for the scenarios and use cases of V2V communications. Detail discussion may reveal some issues which may make some existing MANET protocols less adapted for these cases. For example, some MANET protocols are very powerful and may deal with very complex topologies; at the same time some of the V2V topologies are relatively simple: there's always a rigid network (within vehicle) and loops never form, simply because of the design of the link layer. It's an inner circled star topology. Other MANET protocols, as complete as they are in some cases, miss for example some primary form of address autoconfiguration. Finally, as much as I would like to see analysis of how MANET protocols would be adapted for V2V2I, such work could be highly demanding - which routing protocols precisely should we look at first. Which manet competitors would claim to this place as well. Yours, Alex > > Regards, Stan > > >> >> To summarize: although the work could be undertaken by the MANET >> WG, I feel that ITS features enough peculiarities to deserve a >> different (more focused) WG. >> >> [1] I. Khan and A. Qayyum, “Performance evaluation of aodv and >> olsr in highly fading vehicular ad hoc network environments,” in >> Proceedings of the 13th International Multitopic Conference >> (INMIC), December 2009, pp. 1–5. >> >> Regards, fran >> >> El 31/07/2012, a las 20:18, Stan Ratliff (sratliff) escribió: >> >>> First off, I think the discussions on ITS are interesting, >>> worthwhile, and should continue. I wonder, though - aren't these >>> scenarios essentially MANET's? I'm just asking whether one of >>> the options here should be to pursue the work within the MANET >>> WG. >>> >>> Regards, Stan >>> >>> On Jul 31, 2012, at 12:29 PM, Rex Buddenberg wrote: >>> >>>> >>>> Riley, >>>> >>>> This has been kicking around in the emergency services >>>> broadband discussion. Most of the discussants are not long in >>>> understanding of protocol stacks... But they ARE long in >>>> experiencing 'the tower' going away and need to talk with >>>> 'that guy over there that I can see'. >>>> >>>> Qualcom only announced the study group news. This is not a >>>> product announcement or even a proposed standard. >>>> >>>> It appears that the alterations proposed would only affect >>>> layer 2 of the LTE protocol. Totally agnostic about anything >>>> above layer 2. >>>> >>>> This leaves two questions open: can it be done usefully and >>>> scaleably? and 2) what value is it? >>>> >>>> >>>> Speculating a bit on where the study group is going.... LTE >>>> and IEEE 802.16 use a hub&spoke structure (for that matter, so >>>> does WiFi). The LTE base station manages about four dozen MAC >>>> messages, the chief one is the UL-MAP (upload map in English) >>>> which tells each of the subscriber stations when it's that >>>> station's turn to transmit. The base station also negotiates >>>> entry for new subscribers -- ranging messages, X.509 cert >>>> exchange, etc. The processing load and the transmitting load >>>> on a base station is significantly higher than a subscriber >>>> station. >>>> >>>> Our experience with IEEE 802.16 gear (LTE is a near-clone) is >>>> that the hardware for both BS and SS is identical, only the >>>> software load changes. >>>> >>>> My students have hauled .16 gear, both BS and SS, out into the >>>> field, plugged them in and gotten them to work (we know if you >>>> drop the antenna off the back of the truck that it will >>>> break). At the layer 3 interface, all the gear we've ever seen >>>> is doing ethernet forwarding so both SS and BS are passing >>>> ethernet frames out of the box, just like your cable modem at >>>> home. >>>> >>>> Cellphone implementations will tend to load additional >>>> functions (like beam steering) onto base stations to avoid >>>> having to do so with subscriber stations (which may be >>>> embedded in cellphone handsets). The key diff between BS and >>>> SS here is electrical power usage -- a BS will drain the >>>> battery a lot faster. >>>> >>>> So the first question to ask is what would be the study group's >>>> criteria? You can already make a subscriber station, with a >>>> new software load, act like a base station. If you have an >>>> adequate power supply (e.g. vehicle mount rather than handset), >>>> then we have this capability now and have had it for some >>>> years. What's new? >>>> >>>> The second question is what value this would be to emergency >>>> services (or ITS)? Simply putting up a layer 2 network >>>> segment only gets you layer 2 functionality -- all the rest of >>>> the applications are outside scope. DNS support? PKI white >>>> pages? SIP server? There's a lot left to do in a real-world >>>> usability exercise. >>>> >>>> >>>> >>>> On Mon, 2012-07-30 at 16:20 -0700, A. Riley Eller wrote: >>>>>>> While the working item is still a fair distance from >>>>>>> realizing standardization, I think it is worth >>>>>>> mentioning that LTE Direct (a peer-to-peer channel and >>>>>>> symmetric transmission/reception mode) is being proposed >>>>>>> by Qualcomm. From my interviews with their technical >>>>>>> team, I am very excited about the possibility of mobile >>>>>>> node to mobile node direct LTE link. If any of you are >>>>>>> also interested, it might be good to check in on their >>>>>>> progress and offer your comments. >>>>>> >>>>>> Certainly I (and a group of people locally) are interested >>>>>> in the use of LTE for direct communications. >>>>>> >>>>>> How would it be possible to check in on their progress and >>>>>> how could we offer our comments? >>>>>> >>>>>> Alex >>>>> >>>>> I am not an expert on the 3GPP process, so rather than >>>>> muddle about and confuse things, I will include the >>>>> following article which I hope will offer clues. I believe >>>>> that the standards body has agreed to investigate whether a >>>>> direct mode is worth standardizing (??). >>>>> >>>>> http://urgentcomm.com/networks_and_systems/news/direct-mode-lte-study-20110928/ >>>>> >>>>> >>>>> >>>>> My connection to this program came from direct industry contact, so I apologize for my obtuse response. >>>>> >>>>> Riley _______________________________________________ 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 >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> -- Francisco J. Ros, PhD Dept. of Information and Communications >> Engineering University of Murcia, Murcia (Spain) >> http://masimum.inf.um.es/fjrm/ >> >> >> >> > From Ronald.intVelt@tno.nl Tue Jul 31 16:45: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 9916E21F8976 for ; Tue, 31 Jul 2012 16:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+gF2zypTTLK for ; Tue, 31 Jul 2012 16:45:34 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id B8F1521F8975 for ; Tue, 31 Jul 2012 16:45:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,690,1336341600"; d="scan'208";a="73242341" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 01 Aug 2012 01:45:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 01:45:30 +0200 From: "Velt, R. (Ronald) in 't" To: Henning Rogge Thread-Topic: [manet] Discussing LOADng suggestions Thread-Index: AQHNbyLfa7CsHKt+C0iNMj65Y8WjgZdDRrYAgAA+RwCAAAGNgIAAAd4AgAAomxCAACf4gIAAMZeA Date: Tue, 31 Jul 2012 23:45:29 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A3023DA@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 23:45:34 -0000 Henning, >-----Original Message----- >From: Henning Rogge [mailto:hrogge@googlemail.com] >Sent: woensdag 1 augustus 2012 0:33 >To: Velt, R. (Ronald) in 't >Cc: Antonin Bas; Ulrich Herberg; manet; Abdussalam Baryun >Subject: Re: [manet] Discussing LOADng suggestions > >On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't > wrote: > >> Strange wording, in my opinion. It seems to me that if the network >_topology_ is truly static, you do not need a routing protocol at all. (No= te that >just as the absence of movement does not imply a static topology, a static >topology does not imply stationary nodes). > >I think you are underestimating the amount of dynamics in large stationary >radio network, especially built on 802.11 technology. We need MANET >protocols in this community networks as Funkfeuer. Where in the sentences quoted above do I underestimate the dynamics of larg= e stationary radio networks? Ronald > >Henning >-- >Steven Hawkings about cosmic inflation: "An increase of billions of billio= ns of >percent in a tiny fraction of a second. Of course, that was before the pre= sent >government." This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From hrogge@googlemail.com Tue Jul 31 16:47: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 BF16F21F898A for ; Tue, 31 Jul 2012 16:47:21 -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 FdazJx844hpK for ; Tue, 31 Jul 2012 16:47: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 4BC4121F8976 for ; Tue, 31 Jul 2012 16:47:21 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so65944pbb.31 for ; Tue, 31 Jul 2012 16:47:21 -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=vpwL7eEWF+cRi14B7a/AwK5J80RFdZy8hfHLH4h+0G0=; b=ffYqhJcpkYlCWFieiQ0GGZCxxvbMTxJlnf1O/E4mhcArFDTj4jBr4COQ9lgDJpmWPO 4yGWIpS+694ld4VegW/S4vBtkUfHH/OWZylawYH7cjgUGLGDhFgTWmotmqIdII6IhxEI HXHvwY+6bXTHEJlYiMS98bNk47IMUd3wTy/NedN073dgja3+bRlgJmctlO2zBdJrnksy HoyvZARdALsgrg93s4TVlD8vX4I3ssg/8SK/pDGgZZ/xaHP0Aih9VZgj7X8GNxPK45dq j7+dGt4YptofKmUs9oT66ct6d3F7N6Na5SLBQr0mxcM1gAl88fMlkAkbNmDdODhQ2qYU ePkQ== Received: by 10.68.231.233 with SMTP id tj9mr47383049pbc.39.1343778441076; Tue, 31 Jul 2012 16:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.241.131 with HTTP; Tue, 31 Jul 2012 16:47:00 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A3023DA@EXC-MBX03.tsn.tno.nl> References: <1339916196.339062.1343755922162.JavaMail.root@mail17.pantherlink.uwm.edu> <72FB622921C13746AD6349E70A8D9F307A301CEF@EXC-MBX03.tsn.tno.nl> <72FB622921C13746AD6349E70A8D9F307A3023DA@EXC-MBX03.tsn.tno.nl> From: Henning Rogge Date: Tue, 31 Jul 2012 16:47:00 -0700 Message-ID: To: "Velt, R. (Ronald) in 't" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 23:47:21 -0000 I was just getting the feeling that you are supporting this "they are not MANET". Henning Rogge On Tue, Jul 31, 2012 at 4:45 PM, Velt, R. (Ronald) in 't wrote: > Henning, > >>-----Original Message----- >>From: Henning Rogge [mailto:hrogge@googlemail.com] >>Sent: woensdag 1 augustus 2012 0:33 >>To: Velt, R. (Ronald) in 't >>Cc: Antonin Bas; Ulrich Herberg; manet; Abdussalam Baryun >>Subject: Re: [manet] Discussing LOADng suggestions >> >>On Tue, Jul 31, 2012 at 11:23 AM, Velt, R. (Ronald) in 't >> wrote: >> >>> Strange wording, in my opinion. It seems to me that if the network >>_topology_ is truly static, you do not need a routing protocol at all. (Note that >>just as the absence of movement does not imply a static topology, a static >>topology does not imply stationary nodes). >> >>I think you are underestimating the amount of dynamics in large stationary >>radio network, especially built on 802.11 technology. We need MANET >>protocols in this community networks as Funkfeuer. > > Where in the sentences quoted above do I underestimate the dynamics of large stationary radio networks? > > Ronald > >> >>Henning >>-- >>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 e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer > -- 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 Jul 31 17:39: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 3229521F88A7 for ; Tue, 31 Jul 2012 17:39:15 -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 9LF0pePEMoRZ for ; Tue, 31 Jul 2012 17:39:14 -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 32E8F21F88C9 for ; Tue, 31 Jul 2012 17:39:12 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so131707pbb.31 for ; Tue, 31 Jul 2012 17:39:12 -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=w8icPFGU1mYBl6ttSiTnjKH4X4t/SieXR0ZLPqLR0Q8=; b=CsDqt4114r4zKtL8CyiDQiZgptx+g5h7xR973IkJxI7Zbj3ScPQonOJmQy3mZgo4iB /ihoxf2miCLvsGZd87vfCd5i8rdNJFymZbxOnQLIFgSkmIEkjU9wrqELwS9IIXpMiFw7 6bsgPxKGYqAkPQhguin6rzDdyz8JFzhdtBg6wP5LaaX914xJXOEKBCH/bgmNc/Gr58tC ziqmdKBsJ7g1wkbDUC4GU138NtiRdWIl57orOCJ+Z0b9DYgy38qydIYYVeRpGJSI2hmE K7vyNki3D/6Ji2qsvQ0dzVjtV4inxl+XsUDafaBcG7EeZvIZ3tfzI3AHRCDV2DpB8VaP 3t/A== MIME-Version: 1.0 Received: by 10.68.218.103 with SMTP id pf7mr48117194pbc.67.1343781551947; Tue, 31 Jul 2012 17:39:11 -0700 (PDT) Received: by 10.68.42.201 with HTTP; Tue, 31 Jul 2012 17:39:11 -0700 (PDT) Date: Tue, 31 Jul 2012 20:39:11 -0400 Message-ID: From: James Nguyen To: manet@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff256800f3f6404c6298644 Subject: [manet] Router ID and Router Priority in ECDS Algorithm X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 01 Aug 2012 00:39:15 -0000 --e89a8ff256800f3f6404c6298644 Content-Type: text/plain; charset=UTF-8 Hi, After presented draft of ECDS-MIB - an extension to SMF-MIB, at IETF '84 meeting, I'd like to clarify that the tuple of router id and router priority is used for implementing selection of multipoint relay node in ECDS algorithm as stated in RFC6621's Appendix A. http://tools.ietf.org/html/rfc6621#appendix-A http://datatracker.ietf.org/doc/draft-nguyen-manet-ecds-mib/ -- James Nguyen Email: james.huy.nguyen@gmail.com --e89a8ff256800f3f6404c6298644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

After presented draft of ECDS-MIB - an extension to = SMF-MIB, at IETF '84 meeting, I'd like to clarify that the tuple of= router id and router priority is used for implementing selection of multip= oint relay node in ECDS algorithm as stated in RFC6621's Appendix A.


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

--
James Nguyen
Email: james.huy.nguyen@gmail.com
--e89a8ff256800f3f6404c6298644--