From hrogge@googlemail.com Sat Apr 2 09:15:33 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929AE3A685A for ; Sat, 2 Apr 2011 09:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uZV9jWW3HCf for ; Sat, 2 Apr 2011 09:15:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B74023A6859 for ; Sat, 2 Apr 2011 09:15:32 -0700 (PDT) Received: by eye13 with SMTP id 13so1514375eye.31 for ; Sat, 02 Apr 2011 09:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:mime-version :content-type:content-transfer-encoding:message-id; bh=ZODkpz/jh+cVN1pTkThTrHWymfgFWTbQoUV3JIuwaFc=; b=Jm91UwJYIzjuzuM2jMdG5bWjJrmyzPC36ioPS7JRKLrhLlINYQbfIlsU8GIxPfcC5Z NUFyRdp6wJZiXCgNGmtQqJtgfoCSbQm+HD04kuAWH9dnRYALMv8tRBMJGeJjnmUuoPgR KfHK7jEvsR2OyC5OQfKQujhJORkDbl0peBO4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=McY53BOxEkakGi4qToOjLVK5Xmeez8druPZ5fhAZ0zCiJXliAsro5tm5K0wts61wm2 CguDgLTUQuO3LFnEMLxzQaK2Ev1iGsfj+EDSjcYlMC6wUVE5WBBE3yBp8LMyBtU3/ymf 5/ympn71Ie+SPP+mqUBJYjWfatMtVhZ0NmX4E= Received: by 10.213.19.141 with SMTP id a13mr286880ebb.130.1301761032893; Sat, 02 Apr 2011 09:17:12 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id x54sm2141115eeh.5.2011.04.02.09.17.11 (version=SSLv3 cipher=OTHER); Sat, 02 Apr 2011 09:17:11 -0700 (PDT) From: Henning Rogge To: manet@ietf.org Date: Sat, 2 Apr 2011 18:16:59 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-gentoo-r1; KDE/4.6.1; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7527652.39zxtzxcAs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201104021817.09581.hrogge@googlemail.com> Subject: [manet] New OLSRv2 Draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 16:15:33 -0000 --nextPart7527652.39zxtzxcAs Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, is there an ETA (estimated time of arival) for the new OLSRv2 draft that wa= s=20 mentioned at the IETF meeting in Prague ? Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart7527652.39zxtzxcAs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk2XTAUACgkQcenvcwAcHWfqvwCfXFXZ63G0wE5h0IbRavT022RY mR0An2Y2dSY2hulSspQ4EL289ysc3eW4 =frMy -----END PGP SIGNATURE----- --nextPart7527652.39zxtzxcAs-- From ulrich@herberg.name Mon Apr 4 04:35:51 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC9528C10F for ; Mon, 4 Apr 2011 04:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxQKPdGYW-ht for ; Mon, 4 Apr 2011 04:35:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 639DA28C0E5 for ; Mon, 4 Apr 2011 04:35:45 -0700 (PDT) Received: by vws12 with SMTP id 12so4838013vws.31 for ; Mon, 04 Apr 2011 04:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=XTuaP8vofuZSPeOEkwQfSzTDZCrcSGXt4wcHGazt80s=; b=bWz313I5TCCh68c/XFn76Zz9VCSe0zGhfGkVCm9U+7BvBiPq70cs5sBHk0BUM7jmO6 RYai1MQ7LNm0lEIUQcdIzy0qq7tX1vkgmwaUEFPYrrocjggEZ8Mkc+YwTsa+HXseAXP4 BFoi/4prHoE/TUUgpjcDS50WvLScRy0d04tuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=N2Y/nSQrMPqVkFNAxXmPu0MBioOTUT308q4Nz0B3m6AW24lBdfJ3FHWPmX03Mugd6T qeNFOaiv9ayEOhbLtpBCJotlXKUJGijpV7KyuXrbYCoIHSJceeivjHh4brASEEVpg4MT hJRQz3uhefYDS/tFlIR+6llpoXz3u1KGzhRJs= MIME-Version: 1.0 Received: by 10.220.180.12 with SMTP id bs12mr137897vcb.63.1301917047568; Mon, 04 Apr 2011 04:37:27 -0700 (PDT) Received: by 10.220.71.142 with HTTP; Mon, 4 Apr 2011 04:37:27 -0700 (PDT) Date: Mon, 4 Apr 2011 13:37:27 +0200 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Cole Subject: [manet] Float in NHDP-MIB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 11:35:51 -0000 Hi, during Bob's presentation of the NHDP-MIB, one remaining issue that was mentioned was that we use floats in the MIB, referring to another draft (draft-ietf-opsawg-mib-floats-00) which specifies the use of floats in SMI. According to the author, the "float" draft is now in WG LC, such that the NHDP-MIB should not be delayed due to that reference. Best regards Ulrich From wwwrun@rfc-editor.org Tue Apr 5 17:31:56 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E85C3A69A2; Tue, 5 Apr 2011 17:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGs7GektxCp6; Tue, 5 Apr 2011 17:31:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 635263A68D2; Tue, 5 Apr 2011 17:31:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C852CE0768; Tue, 5 Apr 2011 17:33:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110406003316.C852CE0768@rfc-editor.org> Date: Tue, 5 Apr 2011 17:33:16 -0700 (PDT) Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 6130 on Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:31:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6130 Title: Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Author: T. Clausen, C. Dearlove, J. Dean Status: Standards Track Stream: IETF Date: April 2011 Mailbox: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil Pages: 88 Characters: 190678 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-nhdp-15.txt URL: http://www.rfc-editor.org/rfc/rfc6130.txt This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK] This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From joseph.macker@nrl.navy.mil Thu Apr 7 08:54:49 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86E528C0DB for ; Thu, 7 Apr 2011 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBw6MI8yyuLk for ; Thu, 7 Apr 2011 08:54:49 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 3218428C0D7 for ; Thu, 7 Apr 2011 08:54:49 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p37Ftx6a024913 for ; Thu, 7 Apr 2011 11:56:33 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011040711563220571 for ; Thu, 07 Apr 2011 11:56:32 -0400 From: Joe Macker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 11:56:32 -0400 Message-Id: To: MANET IETF Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [manet] Some actions items from Prague X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:54:49 -0000 All: We had several action items and questions to bring to list discussed in = Prague. I will send them out today in separate threads so they can be responded = to with appropo subject lines,etc. -Joe= From joseph.macker@nrl.navy.mil Thu Apr 7 09:15:11 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC423A6A1C for ; Thu, 7 Apr 2011 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ennUwJtE9InX for ; Thu, 7 Apr 2011 09:15:10 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 788103A6A14 for ; Thu, 7 Apr 2011 09:15:10 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p37GGnVg026910 for ; Thu, 7 Apr 2011 12:16:55 -0400 Received: from vpn217206.nrl.navy.mil ([132.250.217.206]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011040712165420748 for ; Thu, 07 Apr 2011 12:16:54 -0400 From: Joe Macker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Apr 2011 12:16:53 -0400 Message-Id: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> To: MANET IETF Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:15:11 -0000 As discussed in Prague we are presently considering adoption of NHDP = security related document as a WG document. reference is draft-herberg-manet-nhdp-sec-01 Please comment if you have an opinion. -Joe= From thomas@thomasclausen.org Thu Apr 7 09:20:48 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE1C3A6A1C for ; Thu, 7 Apr 2011 09:20:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBMib2FWjUeP for ; Thu, 7 Apr 2011 09:20:47 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 641163A6A14 for ; Thu, 7 Apr 2011 09:20:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 551EA4300B7; Thu, 7 Apr 2011 09:22:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.111] (AMontsouris-651-1-121-88.w83-202.abo.wanadoo.fr [83.202.64.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id A023743002D; Thu, 7 Apr 2011 09:22:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> Date: Thu, 7 Apr 2011 18:22:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75039777-676F-4CFA-85FC-FB9798707196@thomasclausen.org> References: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> To: Joe Macker X-Mailer: Apple Mail (2.1082) Cc: MANET IETF Subject: Re: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 16:20:48 -0000 Joe, all, I support WG adoption of this document. NHDP-SEC has a dependency on packetbb-sec. I assume that packetbb-sec = will see WGLC shortly, as it has been stable for a good while? Sincerely yours, Thomas On Apr 7, 2011, at 18:16 , Joe Macker wrote: > As discussed in Prague we are presently considering adoption of NHDP = security related document as a WG document. >=20 > reference is draft-herberg-manet-nhdp-sec-01 >=20 > Please comment if you have an opinion. >=20 > -Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Thu Apr 7 12:59:55 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57343A6980 for ; Thu, 7 Apr 2011 12:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAaSUU4n5-Q6 for ; Thu, 7 Apr 2011 12:59:55 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 07D0B3A6977 for ; Thu, 7 Apr 2011 12:59:54 -0700 (PDT) Received: by wwa36 with SMTP id 36so2441634wwa.13 for ; Thu, 07 Apr 2011 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=F8lYSRmG4E1BVHBtdGV4H11hsPiRsVOmxBJcNU+HK6E=; b=efqBcbI4H9NCDTaFtoPfEz7J0u0KigZdQuab4RnFJriImANZJ1ghUN16pbiAaiOnSb te3dAAYLnJkvfYK5QcK3XHEOzWN53c9Gb0gq9Uvrhja1HMIUMrGH0cd7SstWk8cc5uO5 i4O/jNhlwHhBZmqc6B2RTibXnDJUk8mkZyx+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XkBMZwGEJleY99iT9eBFmHyY2uRo3iJlpjM4rDBOqYylC0GAzoxTn8SHogHLwSKW6q nzYow6jBURNLUTiAehx7lx9GXs4H628TE4WPMh3mzqTRpmDx+ktBwjZgkLBDveQ043d7 0JOsoRQEojLovleU6dY5u09Zs9mFd2Rud1ABc= MIME-Version: 1.0 Received: by 10.216.171.133 with SMTP id r5mr1047991wel.91.1302206499013; Thu, 07 Apr 2011 13:01:39 -0700 (PDT) Received: by 10.216.178.2 with HTTP; Thu, 7 Apr 2011 13:01:38 -0700 (PDT) Date: Thu, 7 Apr 2011 16:01:38 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] 2 week WGLC for packetbb-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:59:55 -0000 As discussed and agreed in Prague, we are announcing a WGLC period for packetbb security document. draft-ietf-manet-packetbb-sec-03 The period will last for approx 2 weeks. So please have comments to authors and list by 1700 PST Friday, 22 April 2010. Regards, Joe From jpmacker@gmail.com Thu Apr 7 13:01:16 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9186128C13C for ; Thu, 7 Apr 2011 13:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soNfgoS9PnyU for ; Thu, 7 Apr 2011 13:01:16 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C11933A69A6 for ; Thu, 7 Apr 2011 13:01:15 -0700 (PDT) Received: by wyb29 with SMTP id 29so2789984wyb.31 for ; Thu, 07 Apr 2011 13:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+epoaRWKSOGpw287NsvRUqbveYgBzICcH9m83fZsYPQ=; b=JAY0/PkIhObMFC0sbaJqAX77o32m/17KZqO90pVSqXWWJgMvXsayXwU3tu1ZSB4XhJ O+xMGPZSxIBp8OSpcTBc6Is0dqsjJDKPlSZglfo+YM3C7P58+yjEg8ZD3l9jEquY995I hIXWHlRwNHKuCH8jqMkno7Li4C44Db4Lm7Ryc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pMhMk7TIWdcwShOtI0HxoNof4E2w0+7JcgoEo5Ts+HEWXolFTpYsYTJuJ2E0QjrO2p +3guw/KZzIWa+2Rl+PqOaeREAIhjSu2h+xl7YioPfAzx5e7vJAW6sEOufCYsEw+e4n8e fpgCCyVytCC4gxzH7Pg2jwTi0NABGQ+JnLugY= MIME-Version: 1.0 Received: by 10.216.61.136 with SMTP id w8mr1020673wec.61.1302206579847; Thu, 07 Apr 2011 13:02:59 -0700 (PDT) Received: by 10.216.178.2 with HTTP; Thu, 7 Apr 2011 13:02:59 -0700 (PDT) Date: Thu, 7 Apr 2011 16:02:59 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] WGLC for NHDP MIB document X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:01:16 -0000 As discussed and agreed in Prague, we are announcing a slightly extended WGLC period for NHDP-MIB. draft-ietf-manet-nhdp-mib-07 The period will last for approx 4 weeks since we want time for additional input. So please have comments to authors and list by 1700 PST Friday, 6 May 2010. I also request that the NHDP, RFC 6130 authors take a good look and this and make sure its ready. Thanks, Joe From jpmacker@gmail.com Thu Apr 7 13:45:06 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC12D28C112 for ; Thu, 7 Apr 2011 13:45:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCcXrlO2FBO6 for ; Thu, 7 Apr 2011 13:45:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 801933A6977 for ; Thu, 7 Apr 2011 13:45:04 -0700 (PDT) Received: by yxk30 with SMTP id 30so1403431yxk.31 for ; Thu, 07 Apr 2011 13:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=8hO7Kg6EivC3B/n0HyiVPWAHandmwZQTrTDJeP1QIFI=; b=YHDKgG5EunviTlCjuxqum/080VqcwFY1GVBVCyPSKoe23oM9uF7xLursZ5jBb01fuX s9kpXhpkkpqx/UMOzCiPKBgPAyM+U1YQF2ALO4VMTQU6MIGUZU8diSuUUsia46yNcetd KVaw30WnfIJcqL5mXXvQWMh9WZVZoR/0v1HWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LdxrtjyUEOVBf/Nmhbo8rA27elk+a31/xH9Vja/XdfpH2iVBvxZ+sRV1MHmFtyi4wa XyHcO4pCpab9jUsHnnoqqmgtL4m9EhoIPHD8fpUrNUnjeEmO445qXbqBofe9fZ9vxvGX jlQAST4AUeJ0PksFJO38TxtsZqtVNZNmRDnrI= Received: by 10.150.73.2 with SMTP id v2mr1181124yba.341.1302209208909; Thu, 07 Apr 2011 13:46:48 -0700 (PDT) Received: from aes247178.nrl.navy.mil ([132.250.247.178]) by mx.google.com with ESMTPS id t5sm1076737ybe.29.2011.04.07.13.46.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 13:46:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <75039777-676F-4CFA-85FC-FB9798707196@thomasclausen.org> Date: Thu, 7 Apr 2011 16:46:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62C45803-0069-44CA-A5ED-B4A235A3C866@gmail.com> References: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> <75039777-676F-4CFA-85FC-FB9798707196@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) Cc: MANET IETF Subject: Re: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:45:06 -0000 Got bounced initially so it was delayed. You should see it now. On Apr 7, 2011, at 12:22 PM, Thomas Heide Clausen wrote: > Joe, all, >=20 > I support WG adoption of this document. >=20 > NHDP-SEC has a dependency on packetbb-sec. I assume that packetbb-sec = will see WGLC shortly, as it has been stable for a good while? >=20 > Sincerely yours, >=20 > Thomas >=20 >=20 > On Apr 7, 2011, at 18:16 , Joe Macker wrote: >=20 >> As discussed in Prague we are presently considering adoption of NHDP = security related document as a WG document. >>=20 >> reference is draft-herberg-manet-nhdp-sec-01 >>=20 >> Please comment if you have an opinion. >>=20 >> -Joe >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 >=20 From jpmacker@gmail.com Thu Apr 7 13:52:52 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6813A6982 for ; Thu, 7 Apr 2011 13:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8tjdNH+2p-Q for ; Thu, 7 Apr 2011 13:52:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 30CA13A6974 for ; Thu, 7 Apr 2011 13:52:51 -0700 (PDT) Received: by wyb29 with SMTP id 29so2829257wyb.31 for ; Thu, 07 Apr 2011 13:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=7n08Bf3c6IZBdZ/R4jwfETLoTGT2qoNgXdSvnwr8n0w=; b=DcSoDmNwOGcoo8nP21h6nFBS58gGzpZYcvEHMay8n67sLkkSBGZFnZ2c0iktRabABw BdBf9mMvod+c1WA23iu9Q2n3Zr8Xxy09DDucyknCcXwOuHQX+u2uQRd5SL5nXMZhdYVW 1k+UtprDtVF1jgB5+wGK2UPdm+y5rLiYQ3wnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qStVI0AbtSTj1EIZPQEk7h1JszsOdZQFRMWq3ZrV3Er5Kf4NVXZnxCXWqI6vs+TrLK Kk/lWc+ZQ/zv5NRuhLqbqtz8cN74nh0XxyqDnwLjChyIv/1Cx1se6jAHFALqM1/eLySW g7iH6DDEoylNn5YENZfhCtYbqquyzUTwid7Ys= MIME-Version: 1.0 Received: by 10.216.136.67 with SMTP id v45mr1093538wei.106.1302209675245; Thu, 07 Apr 2011 13:54:35 -0700 (PDT) Received: by 10.216.178.2 with HTTP; Thu, 7 Apr 2011 13:54:35 -0700 (PDT) Date: Thu, 7 Apr 2011 16:54:35 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] WGLC for SMF version 11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:52:52 -0000 As discussed and agreed in Prague, we are announcing another WGLC period for SMF. draft-ietf-manet-smf-11 The period will last for approx 2 weeks. So please have comments to authors and list by 1700 PST Friday, 22 April 2010. Known topics to address and being discussed are: - reconciliation/decision re. IPv4 I-DPD mode and id field use (Boot, intarea, others) - request to soften MUST terminology in hash algorithm for generating HAV value --> SHOULD (Bo Berry) Thanks, Joe From ulrich@herberg.name Thu Apr 7 13:55:52 2011 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8233A69D8 for ; Thu, 7 Apr 2011 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKpY5ZFocGNT for ; Thu, 7 Apr 2011 13:55:51 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id F21513A6986 for ; Thu, 7 Apr 2011 13:55:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so2742862vxg.31 for ; Thu, 07 Apr 2011 13:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kgfsdZiqzSklaOBYzTWvNUeEtyIK+nlsvxqujMdx5b8=; b=s/s9WcyE8WUIMGD7YSKKsc/eiaFUx2M7yvadNRMb96dSCOaov3Tjfl5m0xf67l1QkP 53hRfdGeR9wu5USG3VaPNmlmCrHR3T8gZiTRZyC85e2uBROdMLkwJOwMHqCmjw7kp6xQ 3vePOU0a1mgQR7svRqsb9nROKcRK+Jem4X1/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XIXfBLz0s3KjYw8HBj0fjTWXCvRz6hu2O8zfOPbtScEQo0zmSWDsi1vy9+sTqI4iXR hdMjqceAqjnRVTe4sBpuUvDcA9h08I8zZhh8nQ4vp9PdM4IbNT0ARxRpRtSPIaP/iAc8 mKQZfpOwp2f5IcieQgGJR/L3fvfe4gK1T4xrE= MIME-Version: 1.0 Received: by 10.220.178.131 with SMTP id bm3mr404117vcb.28.1302209855264; Thu, 07 Apr 2011 13:57:35 -0700 (PDT) Received: by 10.220.71.142 with HTTP; Thu, 7 Apr 2011 13:57:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2011 22:57:35 +0200 Message-ID: From: Ulrich Herberg To: Joseph Macker Content-Type: multipart/alternative; boundary=90e6ba53a5cad896d304a05a5b85 Cc: manet@ietf.org Subject: Re: [manet] WGLC for SMF version 11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 20:55:52 -0000 --90e6ba53a5cad896d304a05a5b85 Content-Type: text/plain; charset=ISO-8859-1 As said in Prague, I support the document, assuming that my recent review is addressed during the WG LC. Ulrich On Thu, Apr 7, 2011 at 10:54 PM, Joseph Macker wrote: > As discussed and agreed in Prague, we are announcing another WGLC > period for SMF. > draft-ietf-manet-smf-11 > > The period will last for approx 2 weeks. > So please have comments to authors and list by 1700 PST Friday, 22 April > 2010. > > Known topics to address and being discussed are: > - reconciliation/decision re. IPv4 I-DPD mode and id field use > (Boot, > intarea, others) > - request to soften MUST terminology in hash algorithm for > generating > HAV value --> SHOULD (Bo Berry) > > Thanks, > Joe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --90e6ba53a5cad896d304a05a5b85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As said in Prague, I support the document, assuming that my recent review i= s addressed during the WG LC.

Ulrich

On Thu, Apr 7, 2011 at 10:54 PM, Joseph Macker <jpmacker@gmail.com> wrote:=
As discussed and agreed in Prague, we are a= nnouncing another WGLC
period for SMF.
draft-ietf-manet-smf-11

The period will last for approx 2 weeks.
So please have comments to authors and list by 1700 PST Friday, 22 April 20= 10.

Known topics to address and being discussed are:
=A0 =A0 =A0 =A0- reconciliation/decision re. IPv4 I-DPD mode and id field = use (Boot,
intarea, others)
=A0 =A0 =A0 =A0- request to soften MUST terminology in hash algorithm for = generating
HAV value --> SHOULD (Bo Berry)

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

--90e6ba53a5cad896d304a05a5b85-- From jdean@itd.nrl.navy.mil Mon Apr 11 15:42:15 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E407E066A for ; Mon, 11 Apr 2011 15:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 204dbhzQdpKh for ; Mon, 11 Apr 2011 15:42:06 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfc.amsl.com (Postfix) with ESMTP id 324AEE06AF for ; Mon, 11 Apr 2011 15:42:04 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p3BKadN7024344 for ; Mon, 11 Apr 2011 16:36:39 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011041116363601585 for ; Mon, 11 Apr 2011 16:36:36 -0400 From: "Justin Dean" To: Date: Mon, 11 Apr 2011 16:31:45 -0400 Message-ID: <00e801cbf887$7980f900$6c82eb00$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E9_01CBF865.F26F5900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv4h3ildVZ0FKYnReSEYgxGkZHoBg== Content-Language: en-us X-Mailman-Approved-At: Tue, 12 Apr 2011 08:13:35 -0700 Subject: [manet] NHDP-MIB review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 11 Apr 2011 22:42:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E9_01CBF865.F26F5900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00EA_01CBF865.F271CA00" ------=_NextPart_001_00EA_01CBF865.F271CA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have gotten about =BE of the way through the document. I will = continue reviewing it but I wanted to get these out there so work on fixes could start soon. ------=_NextPart_001_00EA_01CBF865.F271CA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have = gotten about =BE of the way through the document.=A0 I will continue = reviewing it but I wanted to get these out there so work on fixes could = start soon.

------=_NextPart_001_00EA_01CBF865.F271CA00-- ------=_NextPart_000_00E9_01CBF865.F26F5900 Content-Type: text/plain; name="draft-ietf-manet-nhdp-mib-07_justin-review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-manet-nhdp-mib-07_justin-review.txt" Internet Engineering Task Force U. Herberg Internet-Draft LIX, Ecole Polytechnique Intended status: Standards Track R. Cole Expires: July 7, 2011 US Army CERDEC I. Chakeres CenGen January 3, 2011 Definition of Managed Objects for the Neighborhood Discovery Protocol draft-ietf-manet-nhdp-mib-07 Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Herberg, et al. Expires July 7, 2011 [Page 1] =0C Internet-Draft The NHDP-MIB January 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 4 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 4 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 5 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 6 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 6 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 15 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 15 6.2. Relationship to Routing Protocol MIBs relying on the NHDP-MIB . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Relationship to the REPORT-MIB . . . . . . . . . . . . . . 16 6.4. MIB modules required for IMPORTS . . . . . . . . . . . . . 16 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 11.1. Normative References . . . . . . . . . . . . . . . . . . . 61 11.2. Informative References . . . . . . . . . . . . . . . . . . 62 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 62 Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Herberg, et al. Expires July 7, 2011 [Page 2] =0C Internet-Draft The NHDP-MIB January 2011 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol [NHDP] process on a router. The MIB defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in [RFC2578], [RFC2579] and [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Overview [NHDP] allows a router in a Mobile Ad Hoc Network (MANET) to discover and track topological information of routers up to two hops away by virtue of exchanging HELLO messages. This information is useful for routers running various routing and multicast flooding protocols developed within the IETF MANET Working Group. 4.1. Terms The following definitions apply throughout this document: o Notification Objects - triggers and associated notification messages allowing for asynchronous tracking of pre-defined events on the managed router. Herberg, et al. Expires July 7, 2011 [Page 3] =0C Internet-Draft The NHDP-MIB January 2011 o Configuration Objects - switches, tables, objects which are initialized to default settings or set through the management interface defined by this MIB. o State Objects - automatically generated values which define the current operating state of the NHDP protocol process in the router. o Performance Objects - automatically generated values which help an administrator or automated tool to assess the performance of the NHDP protocol process on the router and the overall discovery performance within the MANET. 5. Structure of the MIB Module This section presents the structure of the NHDP-MIB module. The MIB is arranged into the following structure: o nhdpNotifications - objects defining NHDP-MIB notifications. o nhdpObjects - defining objects within this MIB. The objects are arranged into the following groups: * Configuration Group - defining objects related to the configuration of the NHDP instance on the router. * State Group - defining objects which reflect the current state of the NHDP instance running on the router. * Performance Group - defining objects which are useful to a management station when characterizing the performance of NHDP on the router and in the MANET. o nhdpConformance - defining the minimal and maximal conformance requirements for implementations of this MIB. 5.1. Notifications This section describes the use of notifications, and mechanisms to enhance the ability to manage NHDP networks. 5.1.1. Introduction Notifications can be emitted by an NHDP router as a reaction to a specific event. This allows a network manager to efficiently determine the source of problems or significant changes of configuration or topology, instead of polling a possibly large number of NHDP routers. Herberg, et al. Expires July 7, 2011 [Page 4] =0C Internet-Draft The NHDP-MIB January 2011 5.1.2. Notification Generation When an exception event occurs, the application notifies the local agent, which sends a notification to the appropriate SNMP management stations. The message includes the notification type and may include a list of notification-specific variables. Section 7 contains, amongst others, the notification definitions, which includes the variable lists. At least one IP address of the NHDP router that originates the notification is included in the variable list so that the network manager may determine the source of the notification. 5.1.3. Limiting Frequency of Notifications To limit the frequency of notifications, the following additional mechanisms are suggested, similar to those in [RFC4750]: 5.1.3.1. Ignoring Initial Activity The majority of critical events occur when NHDP is enabled on a router, at which time the symmetric neighbors and two-hop neighbors of the NHDP router are discovered. During this initial period, a potential flood of notifications is unnecessary since the events are expected. To avoid unnecessary notifications, a router should not originate expected notifications until a certain time interval has elapsed, which is to be predefined by the network manager. 5.1.3.2. Throttling Traps The mechanism for throttling the notifications is the same as in [RFC4750] (i.e. the amount of transmitted notifications per time is bounded). Appropriate values for the window time and upper bound are to be selected by the network manager and depend on the deployment of the MANET. 5.1.3.3. One Notification per Event Similar to the according mechanism in [RFC4750], only one notification is sent per event. 5.2. The Configuration Group The NHDP router is configured with a set of controls. The authoritative list of configuration controls within the NHDP-MIB are found within the MIB module itself. Generally, an attempt was made in developing the NHDP-MIB module to support all configuration objects defined in [NHDP]. For all of the configuration parameters, //Justin //s/[NHDP]/RFC6130 Herberg, et al. Expires July 7, 2011 [Page 5] =0C Internet-Draft The NHDP-MIB January 2011 the same constraints and default values of these parameters as defined in [NHDP] are followed. 5.3. The State Group The State Group reports current state information of a router running [NHDP]. The NHDP-MIB State Group tables were designed to contain the complete set of state information defined within the information bases in [NHDP]. //Justin //Might be helpful to point to Sections 6-8 of RFC6130.=20 Two constructs, i.e., TEXTUAL CONVENTIONs, are defined in support of the tables in the State Group. These are NeighborIfIndex and NeighborRouterId. These are locally (to the NHDP router) defined, unique identifiers. They are used to define indexes to the appropriate State Group tables and to correlate table entries to interface addresses, interfaces and routers within the MANET. NeighborIfIndex is a unique identifier of discovered NHDP interfaces on all routers within the MANET. NeighborRouterId is a unique identifier of discovered NHDP routers within the MANET. //Justin =20 //NeighborIfIndex is confusing to me here. The name implies uniqueness=20 //for a router (ie 1,2,3) but it's said later that it is a unique = itentifier of //discovered NHDP interfaces suggesting interface ipaddresses. NHDP = does not=20 //limit use of an ip address to one interface (if interfaces can't = comunicate on=20 //a shared channel). Which means ip addresses by themselves won't work = for=20 //MANET wide unique interface indexes. Overall I am quite confused by = both what=20 //is meant hear and how it is to be used. 5.4. The Performance Group The Performance Group reports values relevant to system performance. This section lists objects for NHDP performance monitoring, some of which are explicitly defined in the NHDP-MIB and others which are obtainable through a combination of base objects from this MIB and reports available through the REPORT-MIB [REPORT]. Throughout this section, those objects will be pointed out that are intended as base objects which are explicitly defined within this MIB and those objects which are derived through a combination of the base objects and capabilities offered by the REPORT-MIB. Unstable neighbors or 2-hop neighbors and frequent changes of sets can have a negative influence on the performance of NHDP. The following objects allow management applications to acquire information related to the stability and performance of NHDP: The following objects return statistics related to HELLO messages: o Total number of sent HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessageXmits Herberg, et al. Expires July 7, 2011 [Page 6] =0C Internet-Draft The NHDP-MIB January 2011 Object type: Counter32 o Total number of received HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessageRecvd Object type: Counter32 //Justin=20 //given .5 second hello intervals and 10 neighbors this is only enough=20 //for ~6.8 years. Not really an issue but just checking. o Total number of sent periodic HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessagePeriodicXmits Object type: Counter32 o Total number of sent triggered HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessageTriggeredXmits Object type: Counter32 o Acquire history of HELLO message scheduling instances for a given time duration on an interface It is desirable to develop the history of the exact timestamps of each HELLO message that has been sent as well as the type of the message (triggered or periodical). The list of events starts at the given point of time t0 and ends at the given time t1. This is a Derived Object to be pulled from the REPORT-MIB. It is derived from, e.g., the nhdpIfHelloMessagePeriodicXmits Base Object from the NHDP-MIB along with the capabilities derived from the reportHistoryGroup from the REPORT-MIB. o Histogram of the intervals between HELLO messages on an interface It is desirable to track the values (in a 2-dimensional array) that represent a histogram of intervals between HELLO messages, separated by periodic and triggered types. The histogram would display the distribution of intervals between two consecutive HELLOs of the same type (triggered or periodical) using a given bin size. It includes all HELLOs that have been sent after the Herberg, et al. Expires July 7, 2011 [Page 7] =0C Internet-Draft The NHDP-MIB January 2011 given time t0 and before the given time t1. This is a Derived Object to be pulled from the REPORT-MIB. It can be derived from, e.g., the nhdpIfHelloMessagePeriodicXmits Base Object from the NHDP-MIB along with the capabilities derived from the reportHistoryGroup from the REPORT-MIB. The network management application could convert this information into the desired histogram. //Justin //seperating the histogram by type might end up providing somewhat = inferior //information than if it were combined. The high end of the histogram = will be //unbounded for both triggered and periodical. Having a combined = histogram=20 //would give the actual hello rate which would be bounded. I suggest = leaving //these in and adding a combined histogram. o Changes of the frequency of the message scheduling on an interface This object will divide the given time interval from t0 to t1 into a given number of equal parts. It then creates a histogram for each part and calculates the distances (e.g. using the Bhattacharyya distance) between each two adjacent histograms in time. A higher value between two histograms means more difference between the histograms. For instance, this is representative of an event that suddenly sends many triggered HELLO messages, whereas before there have been only very few such triggered messages. This is a Derived Object to be pulled from the REPORT-MIB, as previously discussed, albeit this is a bit more complex with respect to the management application. o Average number of sent HELLO messages per second between the given time t0 and t1 on an interface This is a Derived Object to be pulled from the reportSampledGroup from the REPORT-MIB. It is derived from, e.g., the nhdpIfHelloMessageXmits Base Object. o Average number of received HELLO messages per second on an interface between the given time t0 and t1 This is a Derived Object to be pulled from the REPORT-MIB. See the previous discussion. o Total accumulated size in octets of sent HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessageXmitAccumulatedSize Herberg, et al. Expires July 7, 2011 [Page 8] =0C Internet-Draft The NHDP-MIB January 2011 Object type: Counter32 o Total accumulated size in octets of received HELLO messages on an interface This is a Base Object. Object name: nhdpIfHelloMessageRecvdAccumulatedSize Object type: Counter32 //Justin //This on the other hand could wrap quite quickly given high hello rates //and dense networks. On the order of a few months wouldn't be = unreasonable. o Average size in octets of sent HELLO messages between the given time t0 and t1 on an interface This is a Derived Object to be pulled from the reportSampledGroup from the REPORT-MIB. It is derived from, e.g., the nhdpIfHelloMessageRecvdAccumulatedSize Base Object from this NHDP-MIB. o Average size in octets of received HELLO messages between the given time t0 and t1 on an interface This is a Derived Object to be pulled from the REPORT-MIB. See previous discussion. o Total accumulated number of advertised symmetric neighbors in HELLOs on that interface. This is a Base Object. Object name: nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount Object type: Counter32 o Total accumulated number of advertised heard neighbors in HELLOs on that interface This is a Base Object. Object name: nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount Object type: Counter32 o Total accumulated number of advertised lost neighbors in HELLOs on that interface Herberg, et al. Expires July 7, 2011 [Page 9] =0C Internet-Draft The NHDP-MIB January 2011 This is a Base Object. Object name: nhdpIfHelloMessageXmitAccumulatedLostNeighborCount Object type: Counter32 o Number of expected packets from a given neighbor based on the packet sequence number on an interface This is a Base Object. Object name: nhdpDiscIfExpectedPackets Object type: Counter32 o Success rate of received packets (number of received packets divided by number of expected packets based on the packet sequence number) This is a Derived Object to be pulled from this NHDP-MIB. It is derived from, e.g., the nhdpDiscIfRecvdPackets and the nhdpDiscIfExpectedPackets Base Objects defined in this MIB. This metric is then computed by the network management application. //Justin //nhdpDiscIfRecvPackets Base Object is not yet defined The following objects inspect the frequency of all Neighbor Set changes: o Number of Neighbor Set changes This object counts each Neighbor Set change. A change occurs whenever a new Neighbor Tuple has been added, a Neighbor Tuple has been removed or any entry of a Neighbor Tuple has been modified. This is a Base Object. Object name: nhdpNibNeighborSetChanges Object type: Counter32 o Acquire history of Neighbor Set changes This object returns the history of the exact timestamps of each time the Neighbor Set has been changed. Herberg, et al. Expires July 7, 2011 [Page 10] =0C Internet-Draft The NHDP-MIB January 2011 This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from the previously discussed Base Object. o Histogram of the intervals between Neighbor Set changes Returns the values (in a 2-dimensional array) that represent a histogram of intervals between Neighbor Set changes. This is a Derived Object to be pulled from the reportHistoryGroup from the REPORT-MIB. It is derived from the previously discussed Base Object. The network management application would develop the histograms based upon lists obtained from the REPORT-MIB. o Changes of the frequency of the Neighbor Set changes This object will divide the given time interval from t0 to t1 into a given number of equal parts. It then creates a histogram for each part and calculates the distances (e.g. using the Bhattacharyya distance) between each two adjacent histograms in time. A higher value between two histograms means more difference between the histograms. This is a Derived Object to be pulled from the reportHistoryGroup from the REPORT-MIB. It is derived from the previously discussed Base Object. The network management application could then compute the desired metrics. The next objects examine the uptime of a given neighbor: o Number of changes of a Neighbor Tuple Returns the number of changes to the given Neighbor Tuple. This is a Base Object. Object name: nhdpDiscNeighborNibNeighborSetChanges Object type: Counter32 o Neighbor uptime Returns the number of hundredths of a second since the Neighbor Tuple corresponding to the given neighbor exists. Herberg, et al. Expires July 7, 2011 [Page 11] =0C Internet-Draft The NHDP-MIB January 2011 This is a Base Object. Object name: nhdpDiscNeighborNibNeighborSetUpTime Object type: TimeTicks o Acquire history of change of onlink status of a given neighbor This object returns the history of the exact timestamps of each time the neighbor becomes onlink or offlink. A neighbor is said to become "onlink" if a new Neighbor Tuple is created that corresponds to the given neighbor. It becomes "offlink" if such a tuple has been deleted. //Justin //This is confusing some terminolog making the meaning confusing. Are = we=20 //talking about neighbor sets (neighbor tuple, lost neighbor tuple) or = link=20 //sets (link tuple)? //I see the Neighbor Tuple now. Suggest chagne the second tuple to=20 //"Neighbor Tuple" as well and include explination that the existance of = //"Lost Neighbor Tuples" do not mean that the neighbor is still "onlink" //Also the terms "onlink" and "offlink" were confusting to me. Perhaps = "nbrup" //"nbrdown" would be more appropriate. This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from, e.g., the nhdpDiscNeighborNibNeighborSetChanges Base Object defined in this MIB. o Histogram of the intervals between a change of the onlink status of a given neighbor Returns the values that represent a histogram of intervals between a change of the onlink status of a given neighbor. The histogram includes all changes that have been made after the given time t0 and before the given time t1. This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from, e.g. the nhdpDiscNeighborNibNeighborSetChanges Base Object defined in this MIB. This object sits in the nhdpDiscNeighborSetPerfTable which is indexed by the nhdpDiscNeighborSetRouterId. The following objects examine the stability of a neighbor. A neighbor is said to be unstable if it "flaps" frequently between several links. It is said to be stable if the set of Link Tuples that correspond to the given neighbor is stationary. o Count the changes of the interface over which a given neighbor can be reached This object counts each time the neighbor changes the interface over which it is reachable. That means that the corresponding Link Tuple of the given link moves from the Link Set of one interface to another interface. //Justin //I really don't get what this is trying to measure. Neighbors = (Neighbor Tuples) //contained in the Neighbor Set can have more than one = Link Set entry (Link Tuple) //What does "changes of the interface" mean? It implies the interface = is changing //(different ip address) but also hints with flapping that its just = switching=20 //connectivity. But NHDP doesn't switch anything it just records them = both. //I have an idea on what this is trying to measure but it is not clearly = defined. //It also really only makes sense when there is only one Link Tuple = connection //for a Neighbor Tuple //Open for rewording or removal. To me it is not really acceptable in = current form. Herberg, et al. Expires July 7, 2011 [Page 12] =0C Internet-Draft The NHDP-MIB January 2011 This is a Base Object. Object name: nhdpDiscNeighborNibNeighborSetReachableLinkChanges Object type: Counter32 o Acquire history of changes of the interface over which a given neighbor can be reached This object returns the history of the exact timestamps of each time the neighbor changes the interface over which it is reachable. That means that the corresponding Link Tuple of the given link moves from the Link Set of one interface to another interface. //Justin //Same as above. Link Tuples can't change interfaces, as Link Sets are = assigned //to an interface This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from, e.g., the nhdpDiscNeighborNibNeighborSetReachableLinkChanges Base Object. The network management could develop the desired histogram based upon the information retrieved from the REPORT- MIB. o Histogram of the intervals between a change of the interface over which a given neighbor is reachable Returns the values that represent a histogram of intervals between a change of the interface over which a given neighbor is reachable after the given time t0 and before the given time t1. This is a Derived Object to be pulled from the reportHistoryGroup from the REPORT-MIB. It is derived from the previously discussed Base Object, nhdpDiscNeighborNibNeighborSetChanges counter. The network management application would develop the histograms based upon lists obtained from the REPORT-MIB. //Justin //I like the idea of this one more but again it is not well defined. = How about //returning a list of hisograms which each item representing the = histogram of=20 //an appropriate Link Tuple (the Link Tuple is associated with the = Neighbor Tuple) The following objects inspect the stability of a given 2-hop neighbor: o Count the changes of the N2_neighbor_iface_addr_list of a given 2-hop neighbor This object returns the count of the times the 2-hop neighbor changes its N2_neighbor_iface_addr_list, i.e. the neighbor over which it is reachable. //Justin //The 2-hop neighobr isn't changing anything. The local state (2-Hop = Set) is=20 //changing but the 2-hop neighbor isn't doing any of that changing. //Also the N2_neighbor_iface_addr_list is just a list of addresses of A = (single) //symmetric one hop neighbor. It is not a list of ALL = symmetric one hop neighbors //which can reach the 2-hop node. What I = think you mean to say is. //Count the changes to the union of all N2_neighbor_iface_addr_list = entries=20 //of 2-Hop Tuples with an N2_2hop_addr equal to one of the 2-hop = neighbor's addresses. Herberg, et al. Expires July 7, 2011 [Page 13] =0C Internet-Draft The NHDP-MIB January 2011 This is a Base Object. Object name: nhdpIib2HopSetPerfChanges Object type: Counter32 o Acquire history of changes of the N2_neighbor_iface_addr_list of a given 2-hop neighbor This object returns the history of the exact timestamps of each time the 2-hop neighbor changes its N2_neighbor_iface_addr_list, i.e. the neighbor over which it is reachable. This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from the previously discussed Base Object, nhdpIib2HopSetPerfChanges counter. //Justin //Similar to above. N2_neighbor_iface_address_list does not work the = way it is //being used and is also used incorrectly below. o Histogram of the intervals between a change of a 2-hop neighbor's N2_neighbor_iface_addr_list Returns the values that represent a histogram of intervals between a change of the 2-hop neighbor's N2_neighbor_iface_addr_list after the given time t0 and before the given time t1. This is a Derived Object to be pulled from the reportHistoryGroup from the REPORT-MIB. It is derived from the previously discussed Base Object, nhdpIib2HopSetPerfChanges counter. The network management application would develop the histograms based upon lists obtained from the REPORT-MIB. The next objects examine the uptime of a given 2-hop neighbor: o 2-hop Neighbor uptime Returns the number of hundredths of a second since the 2-Hop Tuple corresponding to the given 2-hop neighbor IP address was registered. //Justin //There can be multiple 2-hop tuple entries for even a single 1-2 hop = link. //One entry for each address which the 2-hop neighbor has actually. A = more //useful measure would be the time since any 2-Hop Tuple existed with = N2_2hop_addr //of the given 2-hop neighbor, continuously to the current time. Again = this can //span across multiple 2-Hop Tuples. This is a Base Object. Object name: nhdpIib2HopSetPerfUpTime Herberg, et al. Expires July 7, 2011 [Page 14] =0C Internet-Draft The NHDP-MIB January 2011 Object type: TimeTicks o Acquire history of change of onlink status of a given 2-hop neighbor This object returns the history of the exact timestamps of each time the 2-hop neighbor becomes onlink or offlink. A 2-hop neighbor is said to become "onlink" if a new 2-hop Tuple is created that corresponds to the given 2-hop neighbor. It becomes "offlink" if such a tuple has been deleted. //Justin //suggest s/onlink/nbrup and s/offlink/nbrdown=20 //also //A 2-hop neighbor is said to become "nbrup" on the first instance of a = 2-hop Tuple //with N2-2hop_addr of the 2-hop neighbor. It becomes "nbrdown" if all = such tuples //have been deleted. This is a Derived Object to be pulled from the reportHistoryGroup of the REPORT-MIB. It is derived from the previously discussed Base Object, nhdpIib2HopSetPerfChanges counter. o Histogram of the intervals between a change of the onlink status of a given 2-hop neighbor Returns the values that represent a histogram of intervals between a change of the onlink status of a given 2-hop neighbor. The histogram includes all changes that have been made after the given time t0 and before the given time t1. This is a Derived Object to be pulled from the reportHistoryGroup from the REPORT-MIB. It is derived from the previously discussed Base Object, nhdpIib2HopSetPerfChanges counter. The network management application would develop the histograms based upon lists obtained from the REPORT-MIB. 6. Relationship to Other MIB Modules This section specifies the relationship of the MIB modules contained in this document to other standards, particularly to standards containing other MIB modules. Definitions imported from other MIB modules and other MIB modules that SHOULD be implemented in conjunction with the MIB module contained within this document are identified in this section. 6.1. Relationship to the SNMPv2-MIB The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The 'system' group provides identification of the management entity and certain other system-wide data. The NHDP-MIB does not duplicate those objects. Herberg, et al. Expires July 7, 2011 [Page 15] =0C Internet-Draft The NHDP-MIB January 2011 6.2. Relationship to Routing Protocol MIBs relying on the NHDP-MIB [NHDP] allows routing protocols to rely on the neighborhood information that is discovered by means of HELLO message exchange. In order to allow for troubleshoot, fault isolate, and manage such routing protocols through a routing protocol MIB, it may be desired to align the State Group tables of the NHDP-MIB and the routing protocol MIB. This is accomplished through the definition of two TEXTUAL-CONVENTIONS in the NHDP-MIB: the NeighborInterfaceId and the NeighborRouterId. These object types are used to develop indexes into common NHDP-MIB and routing protocol State Group tables. These objects are locally significant but should be locally common to the NHDP-MIB and the routing protocol MIB implemented on a common networked router. This will allow for improved cross referencing of information across the two MIBs. 6.3. Relationship to the REPORT-MIB This document describes several Performance Management metrics for the management of NHDP network routers. However, not all of these metrics are explicitly defined solely within the context of this NHDP-MIB. Some of these metrics are obtained through joint interaction between this MIB and the REPORT-MIB [REPORT]. This NHDP- MIB defines the minimum necessary objects (often of type COUNTER) which form the underlying basis for more sophisticated Performance Management reporting available in conjunction with the REPORT-MIB. See Section 5.4 for a discussion of the performance metrics for NHDP management. 6.4. MIB modules required for IMPORTS The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], INET-ADDRESS-MIB [RFC4001], and SMIng [RFC3781]. 7. Definitions This section contains the MIB module defined by the specification. NHDP-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32, Unsigned32, mib-2, TimeTicks FROM SNMPv2-SMI --[RFC2578] TEXTUAL-CONVENTION, TruthValue, TimeStamp, Herberg, et al. Expires July 7, 2011 [Page 16] =0C Internet-Draft The NHDP-MIB January 2011 RowStatus FROM SNMPv2-TC --[RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF --[STD58] InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB --[RFC4001] InterfaceIndexOrZero FROM IF-MIB --[RFC2863] Float32TC FROM FLOAT-TC-MIB --[RFCXXXX] ; nhdpMIB MODULE-IDENTITY LAST-UPDATED "201101031000Z" -- January 3, 2011 ORGANIZATION "IETF MANET working group" CONTACT-INFO "WG E-Mail: manet@ietf.org WG Chairs: ian.chakeres@gmail.com jmacker@nrl.navy.mil Editors: Ulrich Herberg Ecole Polytechnique LIX 91128 Palaiseau Cedex France +33 1 69 33 41 26 ulrich@herberg.name http://www.herberg.name/ Robert G. Cole US Army CERDEC Space and Terrestrial Communications 328 Hopkins Road Bldg 245, Room 16 Aberdeen Proving Ground, MD 21005 USA +1 410 278-6779 robert.g.cole@us.army.mil http://www.cs.jhu.edu/~rgcole/ Ian D Chakeres Herberg, et al. Expires July 7, 2011 [Page 17] =0C Internet-Draft The NHDP-MIB January 2011 CenGen 9250 Bendix Road North Columbia, Maryland 21045 USA ian.chakeres@gmail.com http://www.ianchak.com/" DESCRIPTION "This NHDP-MIB module is applicable to routers implementing the Neighborhood Discovery Protocol defined in [RFC XXXX]. Copyright (C) The IETF Trust (2009). This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- revision REVISION "201101031000Z" -- January 3, 2011 DESCRIPTION "The tenth version of this MIB module, published as draft-ietf-manet-nhdp-mib-07.txt. Added FLOAT32TC from FLOAT-TC-MIB using this for representing the link quality parameters. Added a threshold (number) and window (time interval) within the nhdpNotificationsControl for the nhdpNbrStateChange, nhdp2HopNbrStateChange and nhdpIfRxBadPacket notifications. " REVISION "201011111000Z" -- November 11, 2010 DESCRIPTION "The ninth version of this MIB module, published as draft-ietf-manet-nhdp-mib-06.txt. Corrected editorial issues, fixed some small bugs in the MIB." REVISION "201011081000Z" -- November 08, 2010 DESCRIPTION "The eight version of this MIB module, published as draft-ietf-manet-nhdp-mib-05.txt. Cleaned up defaults and interdependence's between objects." REVISION "201007071000Z" -- July 07, 2010 DESCRIPTION "The seventh version of this MIB module, published as draft-ietf-manet-nhdp-mib-04.txt. Cleaned up and condensed the textual material in the earlier sections of this draft. Checked consistency with NHDP draft, i.e., draft-ietf-manet-nhdp-12.txt." Herberg, et al. Expires July 7, 2011 [Page 18] =0C Internet-Draft The NHDP-MIB January 2011 REVISION "201003081000Z" -- March 08, 2010 DESCRIPTION "The sixth version of this MIB module, published as draft-ietf-manet-nhdp-mib-03.txt. Added the local nhdpIfIndex to the nhdpIibLinkSetTable." REVISION "200911091000Z" -- November 09, 2009 DESCRIPTION "The fifth version of this MIB module, published as draft-ietf-manet-nhdp-mib-02.txt. Cleaned up a few things and updated to newest revision of NHDP draft." REVISION "200910211000Z" -- October 21, 2009 DESCRIPTION "The fourth version of this MIB module, published as draft-ietf-manet-nhdp-mib-01.txt. Added objects pertaining to the performance group." REVISION "200905031500Z" -- May 3, 2009 DESCRIPTION "The third version of this MIB module, published as draft-ietf-manet-nhdp-mib-00.txt. No major revisions to this draft. Mainly rev'd as a new working group document. But also cleaned syntax errors, typos and other issues discovered with 'smilint'." REVISION "200902151500Z" -- February 15, 2009 DESCRIPTION "The second version of this MIB module, published as draft-cole-manet-nhdp-mib-01.txt. Major update adding objects for configuration and state." REVISION "200804251500Z" -- April 25, 2008 DESCRIPTION "The original version of this MIB module, published as draft-cole-manet-nhdp-mib-00.txt." -- RFC-Editor assigns XXXX ::=3D { mib-2 998 } -- to be assigned by IANA -- -- Top-Level Components of this MIB -- nhdpNotifications OBJECT IDENTIFIER ::=3D { nhdpMIB 0 } nhdpObjects OBJECT IDENTIFIER ::=3D { nhdpMIB 1 } nhdpConformance OBJECT IDENTIFIER ::=3D { nhdpMIB 2 } -- -- Textual Conventions Herberg, et al. Expires July 7, 2011 [Page 19] =0C Internet-Draft The NHDP-MIB January 2011 -- NeighborIfIndex ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A locally arbitrary unique identifier associated with an NHDP neighbor interface. //Justin //is locally modifying arbitrary or unique? Does the identifier need be //unique globally or only locally? All objects of type NeighborIfIndex are assigned by the agent out of a common number space. In other words, NeighborIfIndex values assigned to entries in one table must not overlap with NeighborIfIndex values assigned to entries in another table. The NeighborIfIndex defines a discovered interface of a 1-hop or 2-hop neighbor of the local router. The agent identifies a unique neighbor interface through the receipt of an address lists advertised through an NHDP HELLO message. //Justin //This not quite attainable with out of the box NHDP for interfaces = other than //symmetric one hop interfaces. Interfaces outside of this scope are = abstracted //away into addresses with no direct mapping to any interfaces. One = could treat //each address as an interface but this may not be correct. The value for each discovered neighbor interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization, except that if an application is deleted and re-created. The specific value is meaningful only within a given SNMP entity. An NeighborIfIndex value must not be re-used until the next agent restart." SYNTAX Unsigned32 (1..2147483647) NeighborRouterId ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A locally arbitrary unique identifier associated with an NHDP discovered peer router. All objects of type NeighborRouterId are assigned by the agent out of a common number space. The NeighborRouterId defines a discovered NHDP peer of the local router. The agent identifies a unique neighbor interface through the receipt of an address list advertised through an NHDP HELLO message. The value for each discovered neighbor ID must remain constant at least from one re-initialization of the entity's Herberg, et al. Expires July 7, 2011 [Page 20] =0C Internet-Draft The NHDP-MIB January 2011 network management system to the next re-initialization, except that if an application is deleted and re-created. The specific value is meaningful only within a given SNMP entity. An NeighborRouterId value must not be re-used until the next agent restart." SYNTAX Unsigned32 (1..2147483647) -- -- nhdpObjects -- -- 1) Configuration Objects Group -- 2) State Objects Group -- 3) Performance Objects Group -- -- nhdpConfigurationObjGrp -- -- Contains the NHDP objects which configure specific options -- which determine the overall performance and operation of the -- discovery protocol. nhdpConfigurationObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 1 } nhdpInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceTable describes the configuration of the interfaces of this NHDP router. The ifIndex is from the interfaces group defined in the Interfaces Group MIB. nhdpIfStatus provides the functionality expected by the NHDP in the Local Interface Base (LIB) Local Interface Set Table. Hence, the Local Interface Set Table will not be defined below. The objects in this table are persistent and when Herberg, et al. Expires July 7, 2011 [Page 21] =0C Internet-Draft The NHDP-MIB January 2011 written the entity SHOULD save the change to non-volatile storage." REFERENCE "RFC 2863 - The Interfaces Group MIB, McCloghrie, K., and F. Kastenholtz, June 2000." ::=3D { nhdpConfigurationObjGrp 1 } nhdpInterfaceEntry OBJECT-TYPE SYNTAX NhdpInterfaceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpInterfaceEntry describes one NHDP local interface configuration as indexed by its ifIndex as defined in the Standard MIB II Interface Table (RFC2863)." INDEX { nhdpIfIndex } ::=3D { nhdpInterfaceTable 1 } NhdpInterfaceEntry ::=3D SEQUENCE { nhdpIfIndex InterfaceIndexOrZero, nhdpIfStatus TruthValue, nhdpHelloInterval Unsigned32, nhdpHelloMinInterval Unsigned32, nhdpRefreshInterval Unsigned32, nhdpLHoldTime Unsigned32, nhdpHHoldTime Unsigned32, nhdpHystAcceptQuality Float32TC, nhdpHystRejectQuality Float32TC, nhdpInitialQuality Float32TC, nhdpInitialPending TruthValue, nhdpHpMaxJitter Unsigned32, nhdpHtMaxJitter Unsigned32, nhdpIfRowStatus Herberg, et al. Expires July 7, 2011 [Page 22] =0C Internet-Draft The NHDP-MIB January 2011 RowStatus } nhdpIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex for this interface." ::=3D { nhdpInterfaceEntry 1 } nhdpIfStatus OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "nhpdIfStatus indicates whether this interface is a MANET interface. A value of true(1) indicates that the interface is a MANET interface. A value of false(2) indicates that the interface is not a MANET interface. This corresponds to the I_manet parameter in the Local Interface Set, which is omitted in this MIB due to the redundancy with the nhdpInterfaceTable." DEFVAL { 2 } ::=3D { nhdpInterfaceEntry 2 } -- -- Interface Parameters - Message Intervals -- nhdpHelloInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhpdHelloInterval corresponds to HELLO_INTERVAL of NHDP. The following constraint applies to this parameter: nhpdHelloInterval >=3D nhdpHelloMinInterval" REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 2000 } Herberg, et al. Expires July 7, 2011 [Page 23] =0C Internet-Draft The NHDP-MIB January 2011 ::=3D { nhdpInterfaceEntry 3 } nhdpHelloMinInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhpdHelloMinInterval corresponds to HELLO_MIN_INTERVAL of NHDP." REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 4 } nhdpRefreshInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhpdRefreshInterval corresponds to REFRESH_INTERVAL of NHDP. The following constraint applies to this parameter: nhdpRefreshInterval >=3D nhdpHelloInterval" REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 2000 } ::=3D { nhdpInterfaceEntry 5 } -- -- Interface Parameters - Information Validity times -- nhdpLHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 24] =0C Internet-Draft The NHDP-MIB January 2011 "nhdpLHoldTime corresponds to L_HOLD_TIME of NHDP." REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpInterfaceEntry 6 } nhdpHHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpHHoldTime corresponds to H_HOLD_TIME of NHDP. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpInterfaceEntry 7 } -- -- Interface Parameters - Link Quality -- (is optional and settings define operation) -- nhdpHystAcceptQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpHystAcceptQuality corresponds to HYST_ACCEPT of NHDP. The following constraint applies to this parameter: 0 <=3D nhdpHystRejectQuality <=3D nhdpHystAcceptQuality <=3D 1.0" REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Herberg, et al. Expires July 7, 2011 [Page 25] =0C Internet-Draft The NHDP-MIB January 2011 Constraints." -- DEFVAL { 1.0 } ::=3D { nhdpInterfaceEntry 8 } nhdpHystRejectQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpHystRejectQuality corresponds to HYST_REJECT of NHDP. The following constraint applies to this parameter: 0 <=3D nhdpHystRejectQuality <=3D nhdpHystAcceptQuality <=3D 1.0" REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." -- DEFVAL { 0.0 } ::=3D { nhdpInterfaceEntry 9 } nhdpInitialQuality OBJECT-TYPE SYNTAX Float32TC MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpInitialQuality corresponds to INITIAL_QUALITY of NHDP. The following constraint applies to this parameter: 0 <=3D nhdpInitialQuality <=3D 1.0" REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." -- DEFVAL { 1.0 } ::=3D { nhdpInterfaceEntry 10 } nhdpInitialPending OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 26] =0C Internet-Draft The NHDP-MIB January 2011 "nhdpInitialPending corresponds to INITIAL_PENDING of NHDP." //Justin //The following constraints apply to this parameter: //If INITIAL_QUALITY >=3D HYST_ACCEPT, then INITIAL_PENDING :=3D false. //If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING :=3D true. REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 2 } -- i.e. false ::=3D { nhdpInterfaceEntry 11 } -- -- Interface Parameters - Jitter -- nhdpHpMaxJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpHpMaxJitter corresponds to HP_MAXJITTER of NHDP." //Justin //Constraints see 5.4 of RFC5148 REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 12 } nhdpHtMaxJitter OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpHtMaxJitter corresponds to HT_MAXJITTER of NHDP." REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 500 } ::=3D { nhdpInterfaceEntry 13 } nhdpIfRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 27] =0C Internet-Draft The NHDP-MIB January 2011 "This object permits management of the table by facilitating actions such as row creation, construction, and destruction. The value of this object has no effect on whether other objects in this conceptual row can be modified." REFERENCE "The NHDP draft." ::=3D { nhdpInterfaceEntry 14 } -- -- Router Parameters - Information Validity Time -- nhdpNHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpNHoldTime corresponds to N_HOLD_TIME of NHDP. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "The NHDP draft. Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpConfigurationObjGrp 2 } nhdpIHoldTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION "nhdpIHoldTime corresponds to I_HOLD_TIME of NHDP. This object is persistent and when written the entity SHOULD save the change to non-volatile storage." REFERENCE "The NHDP draft. Herberg, et al. Expires July 7, 2011 [Page 28] =0C Internet-Draft The NHDP-MIB January 2011 Section 5 on Protocol Parameters and Constraints." DEFVAL { 6000 } ::=3D { nhdpConfigurationObjGrp 3 } -- -- nhdpStateObjGrp -- -- Contains information describing the current state of the NHDP -- process. nhdpStateObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 2 } -- Two new constructs have been defined in this MIB for -- indexing into the following -- tables and indexing into other tables in other MIBs. -- The NeighborIfIndex defines a unique (to the local router) -- index referencing a discovered interface on another -- router within the MANET. The NeighborRouterId defines a -- unique (to the local router) index referencing a discovered -- router within the MANET. //Justin=20 //as mentioned before these definitions may be problematic; Not all //interfaces are known. -- This table is indexed by an IpAddr associated with -- NeighborIfIndex. Multiple addresses can be associated -- with a given NeighborIfIndex. Each NeighborIfIndex is -- associated with a NeighborRouterId. Throughout this MIB, -- the NeighborIfIndex and the NeighborRouterId are used -- to define the set of IpAddrs related to the interface -- in discussion. nhdpUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The number of hundredths of a second since the current NHDP process was initialized." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 1 } //Justin //Should we also have an nhdpIfUpTime which would give the time a given = local //interface was up and running NHDP? Herberg, et al. Expires July 7, 2011 [Page 29] =0C Internet-Draft The NHDP-MIB January 2011 nhdpDiscIfSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's set of discovered interfaces on neighboring routers." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 2 } nhdpDiscIfSetEntry OBJECT-TYPE SYNTAX NhdpDiscIfSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries include the nhdpDiscRouterId of the discovered router, the nhdpDiscIfIndex of the discovered interface and the current set of addresses associated with this neighbor interface. The nhdpDiscIfIndex has to uniquely identify the remote interface address sets. It does not need to be unique across the MANET. It must be unique within this router." //Justin //This clarifying statement regarding uniqueness should be presented = more clearly //well before this point. //It also isn't clear how the addresses are associated. It says = addresses associated //with the neighobr interface implying they should be from = L_neighbor_iface_addr_list //of a Link Tuple from the Link Set. However = the entry is for an entire router, //implying that it should be from N_neighbor_addr_list of a Neighbor = Tuple from the //Neighbor Set. REFERENCE "This document." INDEX { nhdpDiscIfSetIpAddrType, nhdpDiscIfSetIpAddr } ::=3D { nhdpDiscIfSetTable 1 } NhdpDiscIfSetEntry ::=3D SEQUENCE { nhdpDiscIfSetRouterId NeighborRouterId, nhdpDiscIfSetIndex NeighborIfIndex, nhdpDiscIfSetIpAddrType InetAddressType, nhdpDiscIfSetIpAddr InetAddress, nhdpDiscIfSetIpAddrPrefixLen InetAddressPrefixLength } //Justin //This Sequence is built in such a way such that only one address is = allowed //per interface. I believe that this issues persists throughtout this = document. //If I am correct I would suggest redefining the nhdpDiscIfSetIpAddr to=20 //NhdpDiscIfSetIpAddr where that is defined as: //SEQUENCE of NhdpDiscIfIpAddr=20 //where NhdpDiscIfIpAddr is defined as: //SEQUENCE { InetAddressType,InetAddress,InetAddressPrefixLength } //This address list construct could be reused throughout the document. nhdpDiscIfSetRouterId OBJECT-TYPE SYNTAX NeighborRouterId Herberg, et al. Expires July 7, 2011 [Page 30] =0C Internet-Draft The NHDP-MIB January 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "The NHDP router ID (locally created) of a neighboring router. Used for cross indexing into other NHDP tables and other MIBs." REFERENCE "This document." ::=3D { nhdpDiscIfSetEntry 1 } nhdpDiscIfSetIndex OBJECT-TYPE SYNTAX NeighborIfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The NHDP interface index (locally created) of a neighbor's interface. Used for cross indexing into other NHDP tables and other MIBs." REFERENCE "This document." ::=3D { nhdpDiscIfSetEntry 2 } nhdpDiscIfSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the nhdpDiscIfSetIpAddr in the InetAddress MIB [RFC 4001]." REFERENCE "The NHDP draft." ::=3D { nhdpDiscIfSetEntry 3 } nhdpDiscIfSetIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The nhdpDiscIfSetIpAddr is a recently used address of a neighbor of this router." REFERENCE "The NHDP draft." ::=3D { nhdpDiscIfSetEntry 4 } nhdpDiscIfSetIpAddrPrefixLen OBJECT-TYPE Herberg, et al. Expires July 7, 2011 [Page 31] =0C Internet-Draft The NHDP-MIB January 2011 SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask to be logical-ANDed with the destination address before being compared to the value in the nhdpDiscIfSetAddr field. If the resulting address block is contained in a block in this table, then a match should be returned." REFERENCE "The NHDP draft." ::=3D { nhdpDiscIfSetEntry 5 } -- An NHDP router's Local Information Base (LIB) -- Note: Local IF Set Table is not specified in this -- MIB because the table would be redundant with -- information in nhdpInterfaceTable. -- Removed Interface Addr Set Table -- Entry (foreach Addr): (IfAddrRemoved, -- ExpirationTime) nhdpLibRemovedIfAddrSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Removed Interface Address Set records network addresses which were recently used as local interface network addresses. If a router's interface network addresses are immutable then the Removed Interface Address Set is always empty and MAY be omitted. It consists of Removed Interface Address Tuples, one per network address." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 3 } nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE SYNTAX NhdpLibRemovedIfAddrSetEntry MAX-ACCESS not-accessible Herberg, et al. Expires July 7, 2011 [Page 32] =0C Internet-Draft The NHDP-MIB January 2011 STATUS current DESCRIPTION "A router's Removed Interface Address Set consists of Removed Interface Address Tuples, one per network address: (IR_local_iface_addr, IR_time) The association between these addrs and the router's Interface is found in the Standard MIB II's IP address table (RFC1213)." REFERENCE "The NHDP draft." INDEX { nhdpLibRemovedIfAddrSetIpAddrType, nhdpLibRemovedIfAddrSetIpAddr } ::=3D { nhdpLibRemovedIfAddrSetTable 1 } NhdpLibRemovedIfAddrSetEntry ::=3D SEQUENCE { nhdpLibRemovedIfAddrSetIpAddrType InetAddressType, nhdpLibRemovedIfAddrSetIpAddr InetAddress, nhdpLibRemovedIfAddrSetIpAddrPrefixLen InetAddressPrefixLength, nhdpLibRemovedIfAddrSetIfIndex InterfaceIndexOrZero, nhdpLibRemovedIfAddrSetIrTime TimeStamp } nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the nhdpLibRemovedIfAddrSetIpAddr in the InetAddress MIB [RFC 4001]." REFERENCE "The NHDP draft." ::=3D { nhdpLibRemovedIfAddrSetEntry 1 } nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 33] =0C Internet-Draft The NHDP-MIB January 2011 "nhdpLibRemovedIfAddrSetAddr is a recently used address of an interface of this router." REFERENCE "The NHDP draft." ::=3D { nhdpLibRemovedIfAddrSetEntry 2 } nhdpLibRemovedIfAddrSetIpAddrPrefixLen OBJECT-TYPE SYNTAX InetAddressPrefixLength MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of leading one bits that form the mask to be logical-ANDed with the address to determine the network address to which this interface is attached." REFERENCE "The NHDP draft." ::=3D { nhdpLibRemovedIfAddrSetEntry 3 } nhdpLibRemovedIfAddrSetIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the local IfIndex from which this IP address was recently removed." REFERENCE "The NHDP draft." ::=3D { nhdpLibRemovedIfAddrSetEntry 4 } nhdpLibRemovedIfAddrSetIrTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies when this Tuple expires and MUST be removed from this table." REFERENCE "The NHDP draft." ::=3D { nhdpLibRemovedIfAddrSetEntry 5 } -- Interface Information Base (IIB) Herberg, et al. Expires July 7, 2011 [Page 34] =0C Internet-Draft The NHDP-MIB January 2011 -- -- NHDP Interface Information Base (IIB) -- -- IIB Link Set -- Entry (foreach 1-H neighbor): (NeighborIfAddrList, -- HeardTime, -- SymTime, -- Quality, -- Pending, -- Lost, -- ExpireTime) nhdpIibLinkSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIibLinkSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Link Set of an interface records links from other routers which are, or recently were, 1-hop neighbors." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 4 } nhdpIibLinkSetEntry OBJECT-TYPE SYNTAX NhdpIibLinkSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Link Set consists of Link Tuples, each representing a single link indexed by the local and remote interface pair: (L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time). Note that L_quality is not included in the entries below, because updates may be required too frequently." REFERENCE "This document." INDEX { nhdpIfIndex, nhdpIibLinkSet1HopIfIndex } ::=3D { nhdpIibLinkSetTable 1 } NhdpIibLinkSetEntry ::=3D Herberg, et al. Expires July 7, 2011 [Page 35] =0C Internet-Draft The NHDP-MIB January 2011 SEQUENCE { nhdpIibLinkSet1HopIfIndex NeighborIfIndex, nhdpIibLinkSetIfIndex InterfaceIndexOrZero, nhdpIibLinkSetLHeardTime TimeStamp, nhdpIibLinkSetLSymTime TimeStamp, nhdpIibLinkSetLPending TruthValue, nhdpIibLinkSetLLost TruthValue, nhdpIibLinkSetLTime TimeStamp } nhdpIibLinkSet1HopIfIndex OBJECT-TYPE SYNTAX NeighborIfIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "nhdpIibLinkSet1HopIfIndex is the value of the NeighborIfIndex (from nhdpDiscIfSetTable). This object is repeated here to support table walks to view the set of neighbors of this router." REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 1 } nhdpIibLinkSetIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetIfIndex is the local router's interface index associated with the symmetric link to this entrie's neighbor interface. The set of IP addresses associated with this neighbor's interface is found in nhdpDiscIfSetTable." REFERENCE "The NHDP draft." Herberg, et al. Expires July 7, 2011 [Page 36] =0C Internet-Draft The NHDP-MIB January 2011 ::=3D { nhdpIibLinkSetEntry 2 } nhdpIibLinkSetLHeardTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLHeardTime corresponds to L_HEARD_time of NHDP." REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 3 } nhdpIibLinkSetLSymTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLSymTime corresponds to L_SYM_time of NHDP." REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 4 } nhdpIibLinkSetLPending OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLPending corresponds to L_pending of NHDP" REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 5 } nhdpIibLinkSetLLost OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLLost corresponds to L_lost of NHDP" REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 6 } nhdpIibLinkSetLTime OBJECT-TYPE SYNTAX TimeStamp Herberg, et al. Expires July 7, 2011 [Page 37] =0C Internet-Draft The NHDP-MIB January 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIibLinkSetLTime specifies when this Tuple expires and MUST be removed." REFERENCE "The NHDP draft." ::=3D { nhdpIibLinkSetEntry 7 } -- -- IIB 2-Hop Set -- Entry (foreach IF on a 2-H neighbor): -- (1NeighIfAddrList, -- 2NeighIfAddr, -- ExpireTime) -- nhdpIib2HopSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIib2HopSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A 2-Hop Set of an interface records network addresses of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors through which these symmetric 2-hop neighbors can be reached. It consists of 2-Hop Tuples, each representing a single network address of a symmetric 2-hop neighbor, and a single MANET interface of a symmetric 1-hop neighbor. (N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 5 } nhdpIib2HopSetEntry OBJECT-TYPE SYNTAX NhdpIib2HopSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries include the 2-hop neighbor addresses, which act as the table index, and associated Herberg, et al. Expires July 7, 2011 [Page 38] =0C Internet-Draft The NHDP-MIB January 2011 1-hop symmetric link address set, designated through nhdpDiscIfIndex, and an expiration time." REFERENCE "This document." INDEX { nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress } ::=3D { nhdpIib2HopSetTable 1 } NhdpIib2HopSetEntry ::=3D SEQUENCE { nhdpIib2HopSetIpAddressType InetAddressType, nhdpIib2HopSetIpAddress InetAddress, nhdpIib2HopSet1HopIfIndex NeighborIfIndex, nhdpIib2HopSetN2Time TimeStamp } nhdpIib2HopSetIpAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the nhdpIib2HopSetIpAddress in the InetAddress MIB [RFC 4001]." REFERENCE "The NHDP draft." ::=3D { nhdpIib2HopSetEntry 1 } nhdpIib2HopSetIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIib2HopSetIpAddr corresponds to N2_2hop_addr of NHDP." REFERENCE "The NHDP draft." ::=3D { nhdpIib2HopSetEntry 2 } nhdpIib2HopSet1HopIfIndex OBJECT-TYPE SYNTAX NeighborIfIndex MAX-ACCESS read-only STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 39] =0C Internet-Draft The NHDP-MIB January 2011 "nhdpIib2HopSet1HopIfIndex is NeighborIfIndex of the one hop neighbor which communicated the ipAddress of the 2-hop neighbor in this row entry." REFERENCE "The NHDP draft." ::=3D { nhdpIib2HopSetEntry 3 } nhdpIib2HopSetN2Time OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpIib2HopSetN2Time specifies when this column entry expires and MUST be removed." REFERENCE "The NHDP draft." ::=3D { nhdpIib2HopSetEntry 4 } -- -- Neighbor Information Base (NIB) -- -- Each router maintains a Neighbor Information Base -- that records information about addresses of -- current and recently symmetric 1-hop neighbors. -- NIB Neighbor Set -- Entry (foreach 1-H Neighbor): -- (AllIfAddrListOfIhNeighbor, -- SymmetricIndicator) -- The NIB Neighbor Set Table is small because -- most of the corresponding information is found -- in the nhdpDiscoveredIfTable above. -- //Justin //this foreach wording is different than the previous ones nhdpNibNeighborSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpNibNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Neighbor Set records all network addresses of each 1-hop neighbor." REFERENCE "The NHDP draft." Herberg, et al. Expires July 7, 2011 [Page 40] =0C Internet-Draft The NHDP-MIB January 2011 ::=3D { nhdpStateObjGrp 6 } nhdpNibNeighborSetEntry OBJECT-TYPE SYNTAX NhdpNibNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Neighbor Set consists of Neighbor Tuples, each representing a single 1-hop neighbor: (N_neighbor_addr_list, N_symmetric)" REFERENCE "This document." INDEX { nhdpDiscIfSetRouterId } ::=3D { nhdpNibNeighborSetTable 1 } NhdpNibNeighborSetEntry ::=3D SEQUENCE { nhdpNibNeighborSetNSymmetric TruthValue } //Justin //is this SEQUENCE complete or is some method for including=20 //N_neighbor_addr_list and/or index required? If yes then I may=20 //have missed some prior to here. I tried following the=20 //nhdpDiscIfSetRouterId to find a definition which would provide //the N_neighbor_addr_list but wasn't able to find it. //(updated from a later time) My issue would be resolved if my previous = comments //regarding multiple addresses per interface are fixed. Leaving this = comment here //to let you know that this needs checking once that is fixed. nhdpNibNeighborSetNSymmetric OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpNibNeighborNSymmetric corresponds to N_symmetric of NHDP." REFERENCE "The NHDP draft." ::=3D { nhdpNibNeighborSetEntry 1 } -- Lost Neighbor Set -- Entry ( foreach IF foreach 1-H Neighbor): (IfAddr, -- ExpireTime) -- //Justin //is "foreach IF foreach" correct? The way this is written should = reflect how //the all sequencable tables are written in this document. nhdpNibLostNeighborSetTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpNibLostNeighborSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Lost Neighbor Set records network addresses of routers which recently were Herberg, et al. Expires July 7, 2011 [Page 41] =0C Internet-Draft The NHDP-MIB January 2011 symmetric 1-hop neighbors, but which are now advertised as lost." REFERENCE "The NHDP draft." ::=3D { nhdpStateObjGrp 7 } nhdpNibLostNeighborSetEntry OBJECT-TYPE SYNTAX NhdpNibLostNeighborSetEntry //Justin=20 //as before do we not need an address (NL_neighbor_addr) included? //Either here or within the NhdpNibLostNeighborSetEntry? //(comment from later time) should work if RouterId index addresses are = fixed. MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's Lost Neighbor Set consists of Lost Neighbor Tuples, each representing a single such network address: (NL_neighbor_addr, NL_time)" REFERENCE "This document." INDEX { nhdpDiscIfSetRouterId } ::=3D { nhdpNibLostNeighborSetTable 1 } NhdpNibLostNeighborSetEntry ::=3D SEQUENCE { nhdpNibLostNeighborSetNLTime TimeStamp } nhdpNibLostNeighborSetNLTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "nhdpNibLostNeighborSetNLTime specifies when this Tuple expires and MUST be removed." REFERENCE "The NHDP draft." ::=3D { nhdpNibLostNeighborSetEntry 1 } -- -- nhdpPerformanceObjGrp -- -- Contains objects which help to characterize the performance of -- the NHDP process, typically counters. -- Herberg, et al. Expires July 7, 2011 [Page 42] =0C Internet-Draft The NHDP-MIB January 2011 nhdpPerformanceObjGrp OBJECT IDENTIFIER ::=3D { nhdpObjects 3 } -- -- Objects per local interface -- //Justin //Again there should be some standard way of describing a for each = entry. nhdpInterfacePerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpInterfacePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table summarizes performance objects that are measured per local NHDP interface." REFERENCE "The NHDP draft." ::=3D { nhdpPerformanceObjGrp 1 } nhdpInterfacePerfEntry OBJECT-TYPE SYNTAX NhdpInterfacePerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single entry contains performance counters for a local NHDP interface." INDEX { nhdpIfIndex } ::=3D { nhdpInterfacePerfTable 1 } NhdpInterfacePerfEntry ::=3D SEQUENCE { nhdpIfHelloMessageXmits Counter32, nhdpIfHelloMessageRecvd Counter32, nhdpIfHelloMessageXmitAccumulatedSize Counter32, nhdpIfHelloMessageRecvdAccumulatedSize Counter32, //Justin //Again this may or may not be an issue with regard to wrapping = counters. nhdpIfHelloMessageTriggeredXmits Counter32, nhdpIfHelloMessagePeriodicXmits Counter32, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount Counter32 } Herberg, et al. Expires July 7, 2011 [Page 43] =0C Internet-Draft The NHDP-MIB January 2011 nhdpIfHelloMessageXmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a HELLO message has been transmitted on that interface." ::=3D { nhdpInterfacePerfEntry 1 } nhdpIfHelloMessageRecvd OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a HELLO message has been received on that interface." ::=3D { nhdpInterfacePerfEntry 2 } nhdpIfHelloMessageXmitAccumulatedSize OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of octets in a HELLO message each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 3 } nhdpIfHelloMessageRecvdAccumulatedSize OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of octets in a HELLO message each time a HELLO message has been received." ::=3D { nhdpInterfacePerfEntry 4 } //Justin //Possible counter wrapping. nhdpIfHelloMessageTriggeredXmits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a triggered HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 5 } nhdpIfHelloMessagePeriodicXmits OBJECT-TYPE Herberg, et al. Expires July 7, 2011 [Page 44] =0C Internet-Draft The NHDP-MIB January 2011 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented each time a periodic HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 6 } nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised symmetric neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 7 } nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised heard neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 8 } nhdpIfHelloMessageXmitAccumulatedLostNeighborCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A counter is incremented by the number of advertised lost neighbors in a HELLO each time a HELLO message has been sent." ::=3D { nhdpInterfacePerfEntry 9 } -- -- Objects per discovered neighbor interface -- nhdpDiscIfSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscIfSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 45] =0C Internet-Draft The NHDP-MIB January 2011 "A router's set of performance properties for each discovered interface of a neighbor." REFERENCE "The NHDP draft." ::=3D { nhdpPerformanceObjGrp 2 } nhdpDiscIfSetPerfEntry OBJECT-TYPE SYNTAX NhdpDiscIfSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There is an entry for each discovered interface of a neighbor." REFERENCE "This document." INDEX { nhdpDiscIfSetIndex } ::=3D { nhdpDiscIfSetPerfTable 1 } NhdpDiscIfSetPerfEntry ::=3D SEQUENCE { nhdpDiscIfRecvdPackets Counter32, nhdpDiscIfExpectedPackets Counter32 } nhdpDiscIfRecvdPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time this router receives a packet from that interface of the neighbor." REFERENCE "The NHDP draft." ::=3D { nhdpDiscIfSetPerfEntry 1 } nhdpDiscIfExpectedPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments by the number of missed packets from this neighbor based on the packet sequence number each time this router receives a packet from that interface Herberg, et al. Expires July 7, 2011 [Page 46] =0C Internet-Draft The NHDP-MIB January 2011 of the neighbor." REFERENCE "The NHDP draft." ::=3D { nhdpDiscIfSetPerfEntry 2 } //Justin //It should also be noted that this counter should be set to 1 upon = creation. -- -- Objects concerning the neighbor set -- nhdpNibNeighborSetChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time the Neighbor Set changes. A change occurs whenever a new Neighbor Tuple has been added, a Neighbor Tuple has been removed or any entry of a Neighbor Tuple has been modified." ::=3D { nhdpPerformanceObjGrp 3 } -- -- Objects per discovered neighbor -- nhdpDiscNeighborSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpDiscNeighborSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A router's set of discovered neighbors and their properties." REFERENCE "The NHDP draft." ::=3D { nhdpPerformanceObjGrp 4 } nhdpDiscNeighborSetPerfEntry OBJECT-TYPE SYNTAX NhdpDiscNeighborSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries include the nhdpDiscRouterId of the discovered router, as well as performance objects related to changes of the Neighbor Set." REFERENCE "This document." Herberg, et al. Expires July 7, 2011 [Page 47] =0C Internet-Draft The NHDP-MIB January 2011 INDEX { nhdpDiscIfSetRouterId } ::=3D { nhdpDiscNeighborSetPerfTable 1 } NhdpDiscNeighborSetPerfEntry ::=3D SEQUENCE { nhdpDiscNeighborNibNeighborSetChanges Counter32, nhdpDiscNeighborNibNeighborSetUpTime TimeTicks, nhdpDiscNeighborNibNeighborSetReachableLinkChanges Counter32 } nhdpDiscNeighborNibNeighborSetChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time the neighbor becomes onlink or offlink. A neighbor is said to become 'onlink' if a new nhdpNibNeighborSetEntry is created for a particular nhdpNibNeighborSetRouterId. It becomes 'offlink' if the entry for that neighbor has been deleted." REFERENCE "The NHDP draft." ::=3D { nhdpDiscNeighborSetPerfEntry 1 } nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the time in hundredths of a second since the neighbor becomes 'onlink'. A neighbor is said to become 'onlink' if a new nhdpNibNeighborSetEntry is created for a particular nhdpNibNeighborSetRouterId. It becomes 'offlink' if the entry for that neighbor has been deleted." REFERENCE "This document." ::=3D { nhdpDiscNeighborSetPerfEntry 2 } nhdpDiscNeighborNibNeighborSetReachableLinkChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 48] =0C Internet-Draft The NHDP-MIB January 2011 "This counter increments each time the neighbor changes the interface over which it is reachable. That means that the corresponding Link Tuple of the given link moves from the Link Set of one interface to another interface." REFERENCE "The NHDP draft." ::=3D { nhdpDiscNeighborSetPerfEntry 3 } -- -- Objects per discovered 2-hop neighbor -- nhdpIib2HopSetPerfTable OBJECT-TYPE SYNTAX SEQUENCE OF NhdpIib2HopSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains performance objects per discovered 2-hop neighbor." REFERENCE "The NHDP draft." ::=3D { nhdpPerformanceObjGrp 5 } nhdpIib2HopSetPerfEntry OBJECT-TYPE SYNTAX NhdpIib2HopSetPerfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entries contain performance objects per discovered 2-hop neighbor." REFERENCE "This document." INDEX { nhdpDiscIfSetRouterId } ::=3D { nhdpIib2HopSetPerfTable 1 } NhdpIib2HopSetPerfEntry ::=3D SEQUENCE { nhdpIib2HopSetPerfChanges Counter32, nhdpIib2HopSetPerfUpTime TimeTicks } nhdpIib2HopSetPerfChanges OBJECT-TYPE SYNTAX Counter32 Herberg, et al. Expires July 7, 2011 [Page 49] =0C Internet-Draft The NHDP-MIB January 2011 MAX-ACCESS read-only STATUS current DESCRIPTION "This counter increments each time this 2-hop neighbor changes its N2_neighbor_iface_addr_list in the nhdpIib2HopSetTable." REFERENCE "The NHDP draft." ::=3D { nhdpIib2HopSetPerfEntry 1 } nhdpIib2HopSetPerfUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns the time in hundredths of a second when the 2-Hop Tuple corresponding to the given 2-hop neighbor IP address was registered in the nhdpIib2HopSetTable." REFERENCE "This document." ::=3D { nhdpIib2HopSetPerfEntry 2 } -- -- nhdpNotifications -- nhdpNotificationsControl OBJECT IDENTIFIER ::=3D { nhdpNotifications 1 } nhdpNotificationsObjects OBJECT IDENTIFIER ::=3D { nhdpNotifications 2 } nhdpNotificationsStates OBJECT IDENTIFIER ::=3D { nhdpNotifications 3 } -- nhdpNotificationsControl nhdpSetNotification OBJECT-TYPE SYNTAX OCTET STRING (SIZE(4)) MAX-ACCESS read-write STATUS current DESCRIPTION "A 4-octet string serving as a bit map for the notification events defined by the NHDP notifications. This object is used to enable Herberg, et al. Expires July 7, 2011 [Page 50] =0C Internet-Draft The NHDP-MIB January 2011 and disable specific NHDP notifications where a 1 in the bit field represents enabled. The right-most bit (least significant) represents notification 0. This object is persistent and when written the entity SHOULD save the change to non-volatile storage. " ::=3D { nhdpNotificationsControl 1 } nhdpNbrStateChangeThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value for the nhdpNbrStateChange object. If the number of occurences exceeds this threshold within the previous nhdpNbrStateChangeWindow, then the nhdpNbrStateChange notification is to be sent. " ::=3D { nhdpNotificationsControl 2 } nhdpNbrStateChangeWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "A time window for the nhdpNbrStateChange object. If the number of occurences exceeds the nhdpNbrStateChangeThreshold within the previous nhdpNbrStateChangeWindow, then the nhdpNbrStateChange notification is to be sent. This object represents the time in hundredths of a second. " ::=3D { nhdpNotificationsControl 3 } nhdp2HopNbrStateChangeThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 51] =0C Internet-Draft The NHDP-MIB January 2011 "A threshold value for the nhdp2HopNbrStateChange object. If the number of occurences exceeds this threshold within the previous nhdp2HopNbrStateChangeWindow, then the nhdp2HopNbrStateChange notification is to be sent. " ::=3D { nhdpNotificationsControl 4 } nhdp2HopNbrStateChangeWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "A time window for the nhdp2HopNbrStateChange object. If the number of occurences exceeds the nhdp2HopNbrStateChangeThreshold within the previous nhdp2HopNbrStateChangeWindow, then the nhdp2HopNbrStateChange notification is to be sent. This object represents the time in hundredths of a second. " ::=3D { nhdpNotificationsControl 5 } nhdpIfRxBadPacketThreshold OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value for the nhdpIfRxBadPacket object. If the number of occurences exceeds this threshold within the previous nhdpIfRxBadPacketWindow, then the nhdpIfRxBadPacket notification is to be sent. " ::=3D { nhdpNotificationsControl 6 } nhdpIfRxBadPacketWindow OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "A time window for the nhdpIfRxBadPacket object. If the Herberg, et al. Expires July 7, 2011 [Page 52] =0C Internet-Draft The NHDP-MIB January 2011 number of occurences exceeds the nhdpIfRxBadPacketThreshold within the previous nhdpIfRxBadPacketWindow, then the nhdpIfRxBadPacket notification is to be sent. This object represents the time in hundredths of a second. " ::=3D { nhdpNotificationsControl 7 } -- nhdpNotificationsObjects nhdpNbrStateChange NOTIFICATION-TYPE OBJECTS { nhdpDiscIfSetRouterId, -- The originator of -- the notification. nhdpNbrState -- The new state } STATUS current DESCRIPTION "nhdpNbrStateChange is a notification sent when a significant number of neighbors change their status (i.e. down, asymmetric, or symmetric) in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 1 } nhdp2HopNbrStateChange NOTIFICATION-TYPE OBJECTS { nhdpIib2HopSetIpAddress, -- The originator -- of the notification nhdp2HopNbrState -- The new state } STATUS current DESCRIPTION "nhdp2HopNbrStateChange is a notification sent when a significant number of 2-hop neighbors change their status (i.e. up or down) in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 2 } nhdpIfRxBadPacket NOTIFICATION-TYPE OBJECTS { nhdpDiscIfSetRouterId, -- The originator of -- the notification nhdpDiscIfSetIndex, -- The interface on which the Herberg, et al. Expires July 7, 2011 [Page 53] =0C Internet-Draft The NHDP-MIB January 2011 -- packet has been received nhdpPacketSrcType, -- The type of the source IP -- address of the packet nhdpPacketSrc -- The source IP address of -- the packet } STATUS current DESCRIPTION "nhdpIfRxBadPacket is a notification sent when a significant number of incoming packets have not been successfully parsed in a short time. The network administrator should select appropriate values for 'significant number of neighbors' and 'short time'." ::=3D { nhdpNotificationsObjects 3 } nhdpIfStateChange NOTIFICATION-TYPE OBJECTS { nhdpIfIndex, -- The local interface nhdpIfState -- The new state } STATUS current DESCRIPTION "nhdpIfStateChange is a notification sent when the status of an interface of this router has changed (i.e. an IP address has been added or removed to the interface, or the interface has changed its status from up to down or vice versa)." ::=3D { nhdpNotificationsObjects 4 } -- nhdpNotificationStates nhdpNbrState OBJECT-TYPE SYNTAX INTEGER { down (0), asymmetric (1), symmetric(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "NHDP neighbor states." DEFVAL { down } ::=3D { nhdpNotificationsStates 1 } Herberg, et al. Expires July 7, 2011 [Page 54] =0C Internet-Draft The NHDP-MIB January 2011 nhdp2HopNbrState OBJECT-TYPE SYNTAX INTEGER { down (0), up (1) } MAX-ACCESS read-only STATUS current DESCRIPTION "NHDP 2hop neighbor states." DEFVAL { down } ::=3D { nhdpNotificationsStates 2 } nhdpIfState OBJECT-TYPE SYNTAX INTEGER { down (0), up (1), addresschange(2) -- If a new address has been -- added or an address has -- been removed } MAX-ACCESS read-only STATUS current DESCRIPTION "NHDP interface states." DEFVAL { down } ::=3D { nhdpNotificationsStates 3 } nhdpPacketSrcType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address type of the address of an inbound packet that cannot be identified by a neighbor instance." ::=3D { nhdpNotificationsStates 4 } nhdpPacketSrc OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of an inbound packet that cannot be identified by a neighbor instance. When the last value of a notification using this object is needed, but no notifications of that type have been sent, this value pertaining to this object should be returned as 0.0.0.0 or :: respectively." Herberg, et al. Expires July 7, 2011 [Page 55] =0C Internet-Draft The NHDP-MIB January 2011 ::=3D { nhdpNotificationsStates 5 } -- -- nhdpConformance information -- nhdpCompliances OBJECT IDENTIFIER ::=3D { nhdpConformance 1 } nhdpMIBGroups OBJECT IDENTIFIER ::=3D { nhdpConformance 2 } -- Compliance Statements nhdpBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The basic implementation requirements for managed network entities that implement NHDP." MODULE -- this module MANDATORY-GROUPS { nhdpConfigurationGroup } ::=3D { nhdpCompliances 1 } nhdpFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The full implementation requirements for managed network entities that implement NHDP." MODULE -- this module MANDATORY-GROUPS { nhdpConfigurationGroup, nhdpStateGroup, nhdpPerformanceGroup, nhdpNotificationObjectGroup, nhdpNotificationGroup, nhdpPerformanceGroup } ::=3D { nhdpCompliances 2 } -- -- Units of Conformance -- Herberg, et al. Expires July 7, 2011 [Page 56] =0C Internet-Draft The NHDP-MIB January 2011 nhdpConfigurationGroup OBJECT-GROUP OBJECTS { nhdpIfIndex, nhdpIfStatus, nhdpHelloInterval, nhdpHelloMinInterval, nhdpRefreshInterval, nhdpLHoldTime, nhdpHHoldTime, nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, nhdpInitialPending, nhdpHpMaxJitter, nhdpHtMaxJitter, nhdpNHoldTime, nhdpIHoldTime, nhdpIfRowStatus } STATUS current DESCRIPTION "Set of NHDP configuration objects implemented in this module." ::=3D { nhdpMIBGroups 2 } nhdpStateGroup OBJECT-GROUP OBJECTS { nhdpUpTime, nhdpDiscIfSetRouterId, nhdpDiscIfSetIndex, nhdpDiscIfSetIpAddrPrefixLen, nhdpLibRemovedIfAddrSetIpAddrPrefixLen, nhdpLibRemovedIfAddrSetIfIndex, nhdpLibRemovedIfAddrSetIrTime, nhdpIibLinkSetIfIndex, nhdpIibLinkSetLHeardTime, nhdpIibLinkSetLSymTime, nhdpIibLinkSetLPending, nhdpIibLinkSetLLost, nhdpIibLinkSetLTime, nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress, nhdpIib2HopSet1HopIfIndex, nhdpIib2HopSetN2Time, nhdpNibNeighborSetNSymmetric, nhdpNibLostNeighborSetNLTime } STATUS current Herberg, et al. Expires July 7, 2011 [Page 57] =0C Internet-Draft The NHDP-MIB January 2011 DESCRIPTION "Set of NHDP state objects implemented in this module." ::=3D { nhdpMIBGroups 3 } nhdpPerformanceGroup OBJECT-GROUP OBJECTS { nhdpIfHelloMessageXmits, nhdpIfHelloMessageRecvd, nhdpIfHelloMessageXmitAccumulatedSize, nhdpIfHelloMessageRecvdAccumulatedSize, nhdpIfHelloMessageTriggeredXmits, nhdpIfHelloMessagePeriodicXmits, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount, nhdpDiscIfRecvdPackets, nhdpDiscIfExpectedPackets, nhdpNibNeighborSetChanges, nhdpDiscNeighborNibNeighborSetChanges, nhdpDiscNeighborNibNeighborSetUpTime, nhdpDiscNeighborNibNeighborSetReachableLinkChanges, nhdpIib2HopSetPerfChanges, nhdpIib2HopSetPerfUpTime } STATUS current DESCRIPTION "Set of NHDP performance objects implemented in this module." ::=3D { nhdpMIBGroups 4 } nhdpNotificationObjectGroup OBJECT-GROUP OBJECTS { nhdpSetNotification, nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold, nhdpIfRxBadPacketWindow, nhdpIfState, nhdpNbrState, nhdp2HopNbrState, nhdpPacketSrcType, nhdpPacketSrc } STATUS current DESCRIPTION Herberg, et al. Expires July 7, 2011 [Page 58] =0C Internet-Draft The NHDP-MIB January 2011 "Set of NHDP notification objects implemented in this module." ::=3D { nhdpMIBGroups 5 } nhdpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { nhdpNbrStateChange, nhdp2HopNbrStateChange, nhdpIfRxBadPacket, nhdpIfStateChange } STATUS current DESCRIPTION "Set of NHDP notifications implemented in this module." ::=3D { nhdpMIBGroups 6 } END 8. Security Considerations This MIB defines objects for the configuration, monitoring and notification of the Neighborhood Discovery Protocol [NHDP]. NHDP allows routers to acquire topological information up to two hops away by virtue of exchanging HELLO messages. The information acquired by NHDP may be used by routing protocols. The neighborhood information, exchanged between routers using NHDP, serves these routing protocols as a baseline for calculating paths to all destinations in the MANET, relay set selection for network-wide transmissions etc. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o nhdpIfStatus - this writable object turns on or off the NHDP process for the specified interface. If disabled, higher level protocol functions, e.g., routing, would fail causing network-wide disruptions. o nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval - these writable objects control the rate at which HELLO messages Herberg, et al. Expires July 7, 2011 [Page 59] =0C Internet-Draft The NHDP-MIB January 2011 are sent on a wireless interface. If set at too high a rate, this could represent a form of DOS attack by overloading interface resources. o nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, nhdpInitialPending - these writable objects affect the perceived quality of the NHDP links and hence the overall stability of the network. If improperly set, these settings could result in network-wide disruptions. o nhdpInterfaceTable - this table contains writable objects that affect the overall performance and stability of the NHDP process. Failure of the NHDP process would result in network-wide failure. Particularly sensitive objects from this table are discussed in the previous list items. This is the only table in the NHDP-MIB with writable objects. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o nhdpDiscIfSetTable - The contains information on discovered neighbors, specifically their IP address in the nhdpDiscIfSetIpAddr object. This information provides an adversary broad information on the members of the MANET, located within this single table. This information can be use to expedite attacks on the other members of the MANET without having to go through a laborious discovery process on their own. This object is the index into the table, and has a MAX-ACCESS of 'not- accessible'. However, this information can be exposed using SNMP operations. MANET technology is often deployed to support communications of emergency services or military tactical applications. In these applications, it is imperative to maintain the proper operation of the communications network and to protect sensitive information related to its operation. Therefore, when implementing these capabilities, the full use of SNMPv3 cryptographic mechanisms for authentication and privacy is RECOMMENDED. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this Herberg, et al. Expires July 7, 2011 [Page 60] =0C Internet-Draft The NHDP-MIB January 2011 MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 9. IANA Considerations Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXXX" (here and in the MIB module) with the assigned value and to remove this note. Note well: prior to official assignment by the IANA, a draft document MUST use placeholders (such as "XXXX" above) rather than actual numbers. See RFC4181 Section 4.5 for an example of how this is done in a draft MIB module. 10. Contributors This MIB document uses the template authored by D. Harrington which is based on contributions from the MIB Doctors, especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn. 11. References 11.1. Normative References [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Herberg, et al. Expires July 7, 2011 [Page 61] =0C Internet-Draft The NHDP-MIB January 2011 Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [NHDP] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-15 (work in progress), December 2010. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 11.2. Informative References [REPORT] Cole, R., Macker, J., and A. Morton, "Definition of Managed Objects for Performance Reporting", draft-ietf-manet-report-mib-00 (work in progress), July 2010. [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)", RFC 3781, May 2004. Appendix A. Open Issues This section contains the set of open issues related to the development and design of the NHDP-MIB. This section will not be present in the final version of the MIB and will be removed once all the open issues have been resolved. Herberg, et al. Expires July 7, 2011 [Page 62] =0C Internet-Draft The NHDP-MIB January 2011 1. Check out the definitions of the Notification Group and their relationship within the subtree of the NHDP-MIB. Should we specify thresholds for neighbor change Notifications? How do we specify these? 2. Also, specify specific SNMP response to the snmp set request, i.e., 'generic error', 'bad value', etc. Appendix B. *************************************************************** * Note to the RFC Editor (to be removed prior to publication) * * * * 1) The reference to RFCXXXX within the DESCRIPTION clauses * * of the MIB module point to this draft and are to be * * assigned by the RFC Editor. * * * * 2) The reference to RFCXXX2 throughout this document point * * to the current draft-ietf-manet-nhdp-mib-xx.txt. This * * need to be replaced with the XXX RFC number. * * * *************************************************************** Authors' Addresses Ulrich Herberg LIX, Ecole Polytechnique Palaiseau Cedex, 91128 France EMail: ulrich@herberg.name URI: http://www.herberg.name/ Robert G. Cole US Army CERDEC 328 Hopkins Road, Bldg 245 Aberdeen Proving Ground, Maryland 21005 USA Phone: +1 410 278 6779 EMail: robert.g.cole@us.army.mil URI: http://www.cs.jhu.edu/~rgcole/ Herberg, et al. Expires July 7, 2011 [Page 63] =0C Internet-Draft The NHDP-MIB January 2011 Ian D Chakeres CenGen 9250 Bendix Road North Columbia, Maryland 560093 USA EMail: ian.chakeres@gmail.com URI: http://www.ianchak.com/ Herberg, et al. Expires July 7, 2011 [Page 64] =0C ------=_NextPart_000_00E9_01CBF865.F26F5900-- From ulrich@herberg.name Tue Apr 12 19:16:06 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F13CDE0729 for ; Tue, 12 Apr 2011 19:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emi1vJU1YnCV for ; Tue, 12 Apr 2011 19:16:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4B2D1E0728 for ; Tue, 12 Apr 2011 19:16:06 -0700 (PDT) Received: by iye19 with SMTP id 19so201824iye.31 for ; Tue, 12 Apr 2011 19:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=DHtZb+tqoj3A7TpYiVzL1YuK1qLazW0DYlNixBWrPls=; b=AoXxF5Rc68V4pWyPoOA8G7AYpthY6qJDKJehq4a2VakVUPvtNJn08SZEVo4Mjeb0J3 tFSnAUnQHwPtWH3NVxTGygotNQbI+13APb2bF1lYtEhnvcq+BMh9kgczY1zINijPvPXt Wa//jOs2yVUw6398Gasmbj6pr7UxTTKiIyxCM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=rq2riyGLgVJrZGsAwDuAJ23SrZlT4XYhoaA4R+cGmSztl/vUAv3bufAZoLsyFF/dWj Spc23VbSp/yKKlxVCntwiuVXOVhQ9BQuy5iBjs26J4grBFWThkmh3/DxHJ/Mc9ii8L/E gdyJDova7Pe5SUodsYWirLIjAczo/Uebolzjg= Received: by 10.42.200.133 with SMTP id ew5mr7665877icb.182.1302660965765; Tue, 12 Apr 2011 19:16:05 -0700 (PDT) Received: from [175.203.0.149] ([175.203.0.149]) by mx.google.com with ESMTPS id o3sm63326ibd.61.2011.04.12.19.15.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2011 19:16:00 -0700 (PDT) References: <00e801cbf887$7980f900$6c82eb00$@nrl.navy.mil> In-Reply-To: <00e801cbf887$7980f900$6c82eb00$@nrl.navy.mil> Mime-Version: 1.0 (iPad Mail 8F191) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2-83738390 Message-Id: <4375C50C-4FD3-4974-993D-786B4621EB9F@herberg.name> X-Mailer: iPad Mail (8F191) From: Ulrich Herberg Date: Wed, 13 Apr 2011 11:16:06 +0900 To: Justin Dean Cc: "" Subject: Re: [manet] NHDP-MIB review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 13 Apr 2011 02:16:07 -0000 --Apple-Mail-2-83738390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 thanks Justin! Once I am back at work next week, I will start integrating your suggestions r= ight away! Ulrich On Apr 12, 2011, at 5:31, "Justin Dean" wrote: > I have gotten about =C2=BE of the way through the document. I will contin= ue reviewing it but I wanted to get these out there so work on fixes could s= tart soon. >=20 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-2-83738390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
thanks Justin!

Once I am back at work next week, I will start integrating your suggestions= right away!

Ulrich

On Apr 12, 2011, a= t 5:31, "Justin Dean" <jdean@it= d.nrl.navy.mil> wrote:

I have gotten ab= out =C2=BE of the way through the document.  I will continue reviewing i= t but I wanted to get these out there so work on fixes could start soon.

<draft= -ietf-manet-nhdp-mib-07_justin-review.txt>
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
= --Apple-Mail-2-83738390-- From zirrrrro@yahoo.fr Sat Apr 16 05:58:38 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18715E065A for ; Sat, 16 Apr 2011 05:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.983 X-Spam-Level: *** X-Spam-Status: No, score=3.983 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFzSDO3wXjBC for ; Sat, 16 Apr 2011 05:58:37 -0700 (PDT) Received: from nm6-vm0.bullet.mail.ukl.yahoo.com (nm6-vm0.bullet.mail.ukl.yahoo.com [217.146.183.234]) by ietfc.amsl.com (Postfix) with SMTP id 2709EE0613 for ; Sat, 16 Apr 2011 05:58:37 -0700 (PDT) Received: from [217.146.183.210] by nm6.bullet.mail.ukl.yahoo.com with NNFMP; 16 Apr 2011 12:58:31 -0000 Received: from [217.146.183.165] by tm3.bullet.mail.ukl.yahoo.com with NNFMP; 16 Apr 2011 12:58:31 -0000 Received: from [127.0.0.1] by omp1006.mail.ukl.yahoo.com with NNFMP; 16 Apr 2011 12:58:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 395669.56167.bm@omp1006.mail.ukl.yahoo.com Received: (qmail 52657 invoked by uid 60001); 16 Apr 2011 12:58:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1302958711; bh=25hBKw+W6rALQVxTrEVrGmBAaWMJTAlJbfCY1pvuGaU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=NbDsFZIf+3rKzpHtWXewcugnM7Ia3N+C2veGMdBD6ePStLzllmruIZgR3VjwsOeZPyet0BsSwgDcj+/h6bBy+CevYrXVA9pzdYgBenbu6tfJKMvRDcBpsoLt69VJNqtQ5MGcFLSGaYRUEH8WSj2nbrs4Qe4Gpi3GKAKnSrNQeN0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=Vh3Xe4pCRoqUzJ3BIaSnPGZPZ4TB/DsNloRT2TOpzYBOgnIcXWeSnL2l63OrAUHCOoJLOFhlYKtT9uYah/7Si8l978i4q7gdyj7SeK9XWO9DHEC0RhnYb2nh0FqGJn6mNBfQVLM20PjKoX/0B8Lb/JpfFVqDRCq+P0RrRkxVNms=; Message-ID: <175317.51839.qm@web25705.mail.ukl.yahoo.com> X-YMail-OSG: da72RnYVM1kcLE6jWXqoXHj9xfJI3JrewEqmQS1Y1NosAfu qKx3bBf8157vdK.eqHvANvL9GGgZwfhXddTI6Fb_0YQINgUltpB_6INaFnOW .Q0p_cprw22Ifq3a8lfhUv7yW2sguLX4N.Mtvj2mVJnZMhALMLWZfFUOFcso RbtlDI1E8yLcCfWvSvD0plc8Kc20BFnmvMG5rn5nzJR2CQoWl4mDPm9RHDpI tpUB0Qsp13pF40Wy5XiAnYoBzYaQ_ViQsT7u98di3icIZY4nDiOf5MvJKC0X pXjHqG6BqHkoZRJsy8qv1GfcBYhR8Jl6Mfyq9jP1CCin22NUU0XRipKyRjjK L071H15pcO.jHIywNfxTPht4- Received: from [180.222.117.49] by web25705.mail.ukl.yahoo.com via HTTP; Sat, 16 Apr 2011 13:58:30 BST X-Mailer: YahooMailWebService/0.8.109.295617 Date: Sat, 16 Apr 2011 13:58:30 +0100 (BST) From: amine elabidi To: manet@ietf.org, abidi.amine@cristal.rnu.tn, elabidi_amine@yahoo.fr, ns-users@isi.edu, sympa@cru.fr, pacman-autoconf-general@lists.sourceforge.net, qxue@ecs.umass.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1820582792-1302958710=:51839" Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 16 Apr 2011 12:58:38 -0000 --0-1820582792-1302958710=:51839 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable http://freightairsea.com/vci.html --0-1820582792-1302958710=:51839 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
http://freightairsea.com/vci.html
--0-1820582792-1302958710=:51839-- From zirrrrro@yahoo.fr Sat Apr 16 22:37:07 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 46488E06B2 for ; Sat, 16 Apr 2011 22:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.983 X-Spam-Level: *** X-Spam-Status: No, score=3.983 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VVgcvtd85cO for ; Sat, 16 Apr 2011 22:37:06 -0700 (PDT) Received: from nm16.bullet.mail.ukl.yahoo.com (nm16.bullet.mail.ukl.yahoo.com [217.146.183.190]) by ietfc.amsl.com (Postfix) with SMTP id 25E32E05F5 for ; Sat, 16 Apr 2011 22:37:05 -0700 (PDT) Received: from [217.146.183.208] by nm16.bullet.mail.ukl.yahoo.com with NNFMP; 17 Apr 2011 05:37:02 -0000 Received: from [217.146.183.178] by tm1.bullet.mail.ukl.yahoo.com with NNFMP; 17 Apr 2011 05:37:02 -0000 Received: from [127.0.0.1] by omp1019.mail.ukl.yahoo.com with NNFMP; 17 Apr 2011 05:37:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 292983.33145.bm@omp1019.mail.ukl.yahoo.com Received: (qmail 39926 invoked by uid 60001); 17 Apr 2011 05:37:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1303018622; bh=/njwMCyAveHiNvpTQNZzqoO65hr2o4nH//2RqeAZkqw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=EQcrIix1PezJULMueKhHjn6Uxpgbm03K+3hDt154LVTQ5PNxKeDVNRK8ESbp/YEDP7/VlVTHEE+gsMrz+N0E5PvZdMwBFz7b+P9iA2yvnp+IhiBooOaW+17sAe0QEtz2ME4+5gqFPcdSWgYZBop8X8epHIyG44dNccZjpTy+N4E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type; b=dAVVzValgTJi9D0yOJ9HNnuSHX1rfuRjpm4hb8mhep5xC+ciZcBs2I3ovZKAW4t4hoZqfIFGiQUrvxt2Q/r1Oxo5UwTFl0XB4yVuIkU2SBlxVDx728YqxMA0ITSRrJRvA0c5qmZvQ01b5yfnNLtE/zG5CmlEnwVBstnPthks8vw=; Message-ID: <39611.39305.qm@web25702.mail.ukl.yahoo.com> X-YMail-OSG: jWPpsn8VM1myYoM8.fsD5Xg8y.AhjGuKvNADzCUuz.QCDXC ifIrt.680d6AhCoXYa166i_I.2lyC6oWvNQF_LuZZqxcPwqyb8hp.zGOlLNQ _4_sEvd9NhQnSN.pcqGx87FrRby5B6MLHjiGK4s6Ou.OixgqJuFKQkHTyVs2 IsYrcj8MB5fzQ7jqWdZ7MliLg.ZDwsCnbw0hyiAa.TGFXThTxQnPteAAOw5u n0qWrHsa6clenQEqO8seqyV1JEaWKGoDGbUKSb4M6h7oYK26qLoY5c4EYRiS J672PJlM4mOWh_VMtLlgGSk0afufSK3eDGyuAG2Hc6HdkoTlOKnqHk1DwUoi KsS0Ib2bKF0U_siR.SE4JUQI.SuhxJyRoocg__PoOEsaTbY.vzWcpxQ-- Received: from [58.9.192.220] by web25702.mail.ukl.yahoo.com via HTTP; Sun, 17 Apr 2011 06:37:01 BST X-Mailer: YahooMailWebService/0.8.109.295617 Date: Sun, 17 Apr 2011 06:37:01 +0100 (BST) From: amine elabidi To: manet@ietf.org, abidi.amine@cristal.rnu.tn, elabidi_amine@yahoo.fr, ns-users@isi.edu, sympa@cru.fr, pacman-autoconf-general@lists.sourceforge.net, qxue@ecs.umass.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-325795466-1303018621=:39305" Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 17 Apr 2011 05:37:07 -0000 --0-325795466-1303018621=:39305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable http://aprowler.com/vci.html --0-325795466-1303018621=:39305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
http://aprowler.com/vci.html
--0-325795466-1303018621=:39305-- From yi.jiazi@gmail.com Wed Apr 20 01:23:40 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CD3F1E0730 for ; Wed, 20 Apr 2011 01:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1oZLp78x5Wd for ; Wed, 20 Apr 2011 01:23:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7A32CE0668 for ; Wed, 20 Apr 2011 01:23:17 -0700 (PDT) Received: by wyb29 with SMTP id 29so442631wyb.31 for ; Wed, 20 Apr 2011 01:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type; bh=mokCzcSfzgIvgAveqUQ5kTlQJjM/IsB6ZxF19v9lDXc=; b=UZlZS6HBxppBFKIVW3Xj8SwyIkg0ihNetMpAejUnAutmt6+ooKbefNL5EEkG/HDVQc FLD3NXkpFftahPsnDsMc7fPKfUVj7MYdc1aP+cnw1efObPjoN/D/f8YwjlsQ3OHT5dct rLuwXbgP/qXuIINB+B2c+a7zKIteRodH2a9Ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=xJpHMly0oqc+e1Sh21GR+Xu4kNCL1OrfBA72NdYiyi57/ja4TF37CKxgBOsYzgBNrj wOp7FdflW9tyeUj07tC0nyi/2ZrUzP982wjg6typHns80CLd6NV+0SRCL4y00NAn0k1l BSFQLlCA2hBknp7w9HS9JeH8h28NBgukLp8BY= Received: by 10.227.0.152 with SMTP id 24mr7205435wbb.126.1303287796735; Wed, 20 Apr 2011 01:23:16 -0700 (PDT) Received: from jz-mac-pro.local (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id p5sm400093wbg.62.2011.04.20.01.23.14 (version=SSLv3 cipher=OTHER); Wed, 20 Apr 2011 01:23:14 -0700 (PDT) Message-ID: <4DAE97F1.1060008@gmail.com> Date: Wed, 20 Apr 2011 10:23:13 +0200 From: YI Jiazi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------010907050900060404080105" X-Mailman-Approved-At: Wed, 20 Apr 2011 06:04:34 -0700 Subject: [manet] draft-ietf-manet-smf-11 Review X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 20 Apr 2011 08:23:41 -0000 This is a multi-part message in MIME format. --------------010907050900060404080105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I have my review of smf-11 attached. The comments appear as *********************** *JY* ************************ in the txt file. Or they can simply be found by searching *JY*. best regards -- Jiazi YI www.jiaziyi.com Postdoctoral researcher Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France --------------010907050900060404080105 Content-Type: text/plain; name="draft-ietf-manet-smf-11_comments_JY.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-ietf-manet-smf-11_comments_JY.txt" Network Working Group J. Macker, editor Internet-Draft NRL Intended status: Experimental SMF Design Team Expires: September 15, 2011 IETF MANET WG March 14, 2011 Simplified Multicast Forwarding draft-ietf-manet-smf-11 Abstract This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 1] Internet-Draft SMF March 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 2] Internet-Draft SMF March 2011 Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. SMF Applicability . . . . . . . . . . . . . . . . . . . . . . 8 5. SMF Packet Processing and Forwarding . . . . . . . . . . . . . 9 6. SMF Duplicate Packet Detection . . . . . . . . . . . . . . . . 11 6.1. IPv6 Duplicate Packet Detection . . . . . . . . . . . . . 12 6.1.1. IPv6 SMF-DPD Header Option . . . . . . . . . . . . . . 12 6.1.2. IPv6 Identification-based DPD . . . . . . . . . . . . 15 6.1.3. IPv6 Hash-based DPD . . . . . . . . . . . . . . . . . 17 6.2. IPv4 Duplicate Packet Detection . . . . . . . . . . . . . 18 6.2.1. IPv4 Identification-based DPD . . . . . . . . . . . . 18 6.2.2. IPv4 Hash-based DPD . . . . . . . . . . . . . . . . . 20 7. Relay Set Selection . . . . . . . . . . . . . . . . . . . . . 20 7.1. Non-Reduced Relay Set Forwarding . . . . . . . . . . . . . 20 7.2. Reduced Relay Set Forwarding . . . . . . . . . . . . . . . 21 8. SMF Neighborhood Discovery Requirements . . . . . . . . . . . 23 8.1. SMF Relay Algorithm TLV Types . . . . . . . . . . . . . . 24 8.1.1. SMF Message TLV Type . . . . . . . . . . . . . . . . . 24 8.1.2. SMF Address Block TLV Type . . . . . . . . . . . . . . 25 9. SMF Border Gateway Considerations . . . . . . . . . . . . . . 26 9.1. Forwarded Multicast Groups . . . . . . . . . . . . . . . . 27 9.2. Multicast Group Scoping . . . . . . . . . . . . . . . . . 28 9.3. Interface with Exterior Multicast Routing Protocols . . . 28 9.4. Multiple Border Routers . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11.1. IPv6 SMF-DPD Header Extension . . . . . . . . . . . . . . 32 11.2. SMF Type-Length-Value . . . . . . . . . . . . . . . . . . 33 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm . . . . . . . . . . . . . . . . . . . . . . 36 A.1. E-CDS Relay Set Selection Overview . . . . . . . . . . . . 37 A.2. E-CDS Forwarding Rules . . . . . . . . . . . . . . . . . . 38 A.3. E-CDS Neighborhood Discovery Requirements . . . . . . . . 38 A.4. E-CDS Selection Algorithm . . . . . . . . . . . . . . . . 41 Appendix B. Source-based Multipoint Relay (S-MPR) . . . . . . . . 43 B.1. S-MPR Relay Set Selection Overview . . . . . . . . . . . . 43 B.2. S-MPR Forwarding Rules . . . . . . . . . . . . . . . . . . 44 B.3. S-MPR Neighborhood Discovery Requirements . . . . . . . . 45 B.4. S-MPR Selection Algorithm . . . . . . . . . . . . . . . . 47 Appendix C. Multipoint Relay Connected Dominating Set Macker, editor & SMF Design Team Expires September 15, 2011 [Page 3] Internet-Draft SMF March 2011 (MPR-CDS) Algorithm . . . . . . . . . . . . . . . . . 48 C.1. MPR-CDS Relay Set Selection Overview . . . . . . . . . . . 48 C.2. MPR-CDS Forwarding Rules . . . . . . . . . . . . . . . . . 49 C.3. MPR-CDS Neighborhood Discovery Requirements . . . . . . . 50 C.4. MPR-CDS Selection Algorithm . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Macker, editor & SMF Design Team Expires September 15, 2011 [Page 4] Internet-Draft SMF March 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction and Scope Unicast routing protocol designs for MANET and wireless mesh use often apply distributed algorithms to flood routing control plane messages within an interior wireless routing domain. For example, algorithms specified within [RFC3626] and [RFC3684] provide distributed methods of dynamically electing reduced relay sets that attempt to efficiently flood routing control messages while maintaining a connected set under dynamic topological conditions. In one sense, Simplified Multicast Forwarding (SMF) extends the efficient flooding concept to the data forwarding plane. Therefore, SMF provides an appropriate multicast forwarding capability for use cases where localized, efficient flooding is considered an effective design approach. The baseline design is intended to provide a basic, best effort multicast forwarding capability that is constrained to operate within an interior MANET or wireless mesh routing domain. An ********************************************************************** *JY* What's an interior MANET routing domain? ********************************************************************** SMF routing domain is an instance of a SMF routing protocol with common policies that is under a single network administration authority. The main design goals of this SMF specification are to adapt efficient relay sets in MANET type environments [RFC2501] and to define the needed IPv4 and IPv6 multicast duplicate packet detection (DPD) mechanisms to support multi-hop, packet forwarding. 2.1. Terminology The following abbreviations are used throughout this document: Macker, editor & SMF Design Team Expires September 15, 2011 [Page 5] Internet-Draft SMF March 2011 +--------------+---------------------------------+ | Abbreviation | Definition | +--------------+---------------------------------+ | MANET | Mobile Ad hoc Network | | SMF | Simplified Multicast Forwarding | | CF | Classical Flooding | | CDS | Connected Dominating Set | | MPR | Multi-Point Relay | | S-MPR | Source-based MPR | | MPR-CDS | MPR-based CDS | | E-CDS | Essential CDS | | NHDP | Neighborhood Discovery Protocol | | SMF-DPD | SMF-Duplicate Packet Detection | | I-DPD | Identification-based DPD | | H-DPD | Hash-based DPD | | HAV | Hash-assist Value | | FIB | Forwarding Information Base | | TLV | type-length-value encoding | | DoS | Denial of Service | +--------------+---------------------------------+ ********************************************************************** *JY* It's better to have a brief description of some uncommon words, rather than *JY* just extending the definition, such as Essential CDS, what's the relationship *JY* of SMF-DPD, I-DPD and H-DPD. ********************************************************************** 3. Design Overview Figure 1 provides an overview of the logical SMF node architecture, consisting of "Neighborhood Discovery", "Relay Set Selection" and "Forwarding Process" components. Typically, relay set selection (or self-election) occurs based on dynamic input from a neighborhood discovery process. SMF supports the case where neighborhood discovery and/or relay set selection information is obtained from a coexistent process (e.g., a lower layer mechanism or a unicast routing protocol using relay sets). In some algorithm designs, the forwarding decision for a packet can also depend on previous hop or incoming interface information. The asterisks (*) in Figure 1 mark the primitives and relationships needed by relay set algorithms requiring previous-hop packet forwarding knowledge. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 6] Internet-Draft SMF March 2011 ______________ _____________ | | | | | Neighborhood | | Relay Set | | Discovery |------------->| Selection | | Protocol | neighbor | Algorithm | |______________| info |_____________| \ / \ / neighbor\ /forwarding info* \ ____________ / status \ | | / `-->| Forwarding |<--' | Process | ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~> incoming packet, forwarded packets interface id*, and previous hop* Figure 1: SMF Node Architecture There are certain IP multicast packets, defined later in this specification, that are "non-forwardable" and these multicast packets will be ignored by the SMF forwarding engine. The SMF forwarding engine MAY also work with policies and management interfaces to allow additional filtering control over which multicast packets are considered for potential SMF forwarding. This interface would allow more refined dynamic forwarding control once such techniques are matured for MANET operation. At present further discussion of dynamic control is left to future work. Interoperable SMF implementations MUST use a common DPD approach and be able to process the header options defined in this document for IPv6 operation. We define Classical Flooding (CF), as the simplest case of SMF multicast forwarding. With CF, each SMF router forwards each received multicast packet exactly once. In this case, the need for any relay set selection or neighborhood topology information is eliminated at the expense of additional network overhead. In CF mode, the SMF-DPD functionality is still required. While SMF supports a CF mode of operation the use of more efficient relay set modes is RECOMMENDED to reduce contention and congestion caused by unnecessary packet retransmissions [NTSC99]. An efficient, reduced relay set is realized by selecting and maintaining a subset of all possible routers in a MANET routing domain. Known distributed relay set selection algorithms have demonstrated the ability to provide and maintain a dynamic connected set for forwarding multicast IP packets [MDC04]. A few such relay set selection algorithms are described in the Appendices of this Macker, editor & SMF Design Team Expires September 15, 2011 [Page 7] Internet-Draft SMF March 2011 document and the basic designs borrow directly from previously documented IETF work. SMF relay set configuration is extensible and additional relay set algorithms beyond those specified here can be accommodated in future work. Determining and maintaining an optimized set of forwarding nodes generally requires dynamic neighborhood topology information. Neighborhood topology discovery functions MAY be externally provided by a MANET unicast routing protocol or by using the MANET NeighborHood Discovery Protocol (NHDP) [RFC6130] running in concurrence with SMF. Additionally, this specification allows alternative lower layer interfaces (radio router interface) to provide the necessary neighborhood information to aid in supporting more effective relay set election. Fundamentally, an SMF implementation SHOULD provide the ability for multicast forwarding state to be dynamically managed per operating network interface. Some of the relay state maintenance options and interactions are outlined later in Section 7. This document states specific requirements for neighborhood discovery with respect to the forwarding process and the relay set selection algorithms described herein. For determining dynamic relay sets in the absence of other control interfaces, SMF relies on the MANET NHDP specification to ********************************************************************** *JY* specification -> protocol ********************************************************************** assist in IP layer 2-hop neighborhood state discovery and maintenance for relay set election. "SMF_TYPE" and "SMF_NBR_TYPE" Message and Address Block, respectfully, TLV structures (per [RFC5444]) are defined for use with the NHDP protocol. ********************************************************************** *JY* The sentence is not very clear. I think it tries to say "*** message and *JY* address block based on TLVÉ"? ********************************************************************** It is RECOMMENDED that all nodes performing SMF operation in conjunction with NHDP, include these TLV types in any NHDP HELLO messages generated. This capability allows for nodes participating in SMF to be explicitly identified along with their respective dynamic relay set algorithm. 4. SMF Applicability Within dynamic wireless routing topologies, maintaining traditional forwarding trees to support a multicast routing protocol is often not as effective as in wired networks due to the reduced reliability and increased dynamics of mesh topologies [MGL04] [GM99]. A basic packet forwarding service reaching all connected routers running the SMF protocol within a localized routing domain may provide a useful group communication paradigm for various classes of applications. Applications that could take advantage of a simple multicast forwarding service include multimedia streaming, interactive group- based messaging and applications, peer-to-peer middleware multicasting, and multi-hop mobile discovery or registration services. SMF is likely only appropriate for deployment in limited dynamic wireless routing domains so that the flooding process can be contained. The limited SMF routing domains are further defined as Macker, editor & SMF Design Team Expires September 15, 2011 [Page 8] Internet-Draft SMF March 2011 administratively scoped multicast forwarding domains in Section 9.2. Note again that Figure 1 provides a notional architecture for typical SMF-capable nodes. A goal is that simple leaf nodes may also participate in multicast traffic transmission and reception with standard IP network layer semantics (e.g., special or unnecessary encapsulation of IP packets should be avoided in this case). It is important that SMF deployments in localized edge network settings are able to connect and interoperate with existing standard multicast protocols operating within more conventional Internet infrastructures. A multicast border router or proxy mechanism MUST be used when deployed alongside more fixed-infrastructure IP multicast routing such Protocol Independent Multicast (PIM) variants [RFC3973] and [RFC4601]. Present experimental SMF implementations have demonstrated gateway functionality at MANET border routers operating with existing external IP multicast routing protocols [CDHM07],[DHS08],and [DHG09]. SMF may be extended or combined with other mechanisms to provide increased reliability and group specific filtering, but the details for this are not discussed here. 5. SMF Packet Processing and Forwarding The SMF Packet Processing and Forwarding actions are conducted with the following packet handling activities: 1. Processing of outbound, locally-generated multicast packets. 2. Reception and processing of inbound packets on specific network interfaces. The purpose of intercepting outbound, locally-generated multicast packets is to apply any added packet marking needed to satisfy the DPD requirements so that proper forwarding may be conducted. Note that for some system configurations the interception of outbound packets for this purpose is not necessary. Inbound multicast packets are received by the SMF implementation and processed for possible forwarding. This document does not presently support forwarding of directed broadcast addresses [RFC2644]. SMF implementations MUST be capable of forwarding IP multicast packets with destination addresses that are not node-local and link-local for IPv6 as defined in [RFC4291] and that are not within the local network control block as defined by [RFC5771] This will help support generic multi-hop multicast application needs or to distribute designated multicast traffic ingressing the SMF routing domain via border routers. The multicast addresses to be forwarded should be maintained by an a priori list or a dynamic Macker, editor & SMF Design Team Expires September 15, 2011 [Page 9] Internet-Draft SMF March 2011 forwarding information base (FIB) that MAY interact with future MANET dynamic group membership extensions or management functions. There will also be a well-known multicast group for SMF. ********************************************************************** *JY* What's this "well-known" multicast group? The above is not very clear *JY* "There will be" means it doesn't exist at the moment? -> "IANA is requested to assign a well-known multicast group for SMF use" ********************************************************************** This multicast group is specified to contain all routers within an SMF routing domain, so that packets transmitted to the multicast address associated with the group will be delivered to all connected routers running SMF. Due the mobile nature of a MANET, routers running SMF may not be topologically connected at particular times. For IPv6, the multicast address is specified to be "site-local". The name of the multicast group is "SL-MANET-ROUTERS". Minimally SMF MUST forward, as instructed by the relay set selection algorithm, unique (non-duplicate) packets received for this well-known group address when the TTL or hop limit value in the IP header is greater than 1. SMF MUST forward all additional global scope addresses specified within the dynamic FIB or configured list as well. In all cases, the following rules MUST be observed for SMF multicast forwarding: 1. IP multicast packets with TTL <= 1 MUST NOT be forwarded. ********************************************************************** *JY* TTL/hoplimit, also in the following parts. TTL in IPv4, hop-limit in IPv6 - suggest being clear on this. Question: does SMF support either or both of IPv4 and IPv6? Should be said earlier (early? in the beginning of introduction or applicabilty statement) ********************************************************************** 2. Link local IP multicast packets MUST NOT be forwarded. 3. Incoming IP multicast packets with an IP source address matching one of those of the local SMF router interface(s) MUST NOT be forwarded. 4. Received frames with the MAC source address matching any MAC address of the routers interfaces MUST NOT be forwarded. ********************************************************************** *JY* router's or routers' ? ********************************************************************** 5. Received packets for which SMF cannot reasonably ensure temporal DPD uniqueness MUST NOT be forwarded. 6. When packets are forwarded, TTL or hop limit MUST be decremented by one. Note that rule #3 is important because over some types of wireless interfaces, the originating SMF router may receive re-transmissions of its own packets when they are forwarded by adjacent routers. This rule avoids unnecessary retransmission of locally-generated packets even when other forwarding decision rules would apply. An additional processing rule also needs to be considered based upon a potential security threat. As discussed further in Section 10, there may be concern in some SMF deployments that malicious nodes may conduct a denial-of-service attack by remotely "previewing" (e.g., via a directional receive antenna) packets that an SMF node would be forwarding and conduct a "pre-play" attack by transmitting the packet before the SMF node would otherwise receive it but with a reduced TTL (or Hop Limit) field value. This form of attack could cause an SMF node to create a DPD entry that would block the proper forwarding of the valid packet (with correct TTL) through the SMF area. A RECOMMENDED approach to prevent this attack, when it is a concern, would be to cache temporal packet TTL values along with the per- packet DPD state (hash value(s) and/or identifier as described in Macker, editor & SMF Design Team Expires September 15, 2011 [Page 10] Internet-Draft SMF March 2011 Section 6). Then, if a subsequent matching (with respect to DPD) packet arrives with a larger TTL value than the packet that was previously forwarded, SMF should forward the new packet and update the TTL value cached with corresponding DPD state to the new, larger TTL value. There may be temporal cases where SMF would unnecessarily ********************************************************************** *JY* TTL/hoplimit again .... ********************************************************************** forward some duplicate packets using this approach, but those cases are expected to be minimal and acceptable when compared with the potential threat of denied service. Once these criteria have been met, an SMF implementation MUST make a forwarding decision dependent upon the relay set selection algorithm in use. One of the requirements of SMF is that it be configured to run a particular relay set selection algorithm when launched. If the SMF implementation is using Classical Flooding (CF), the forwarding decision is implicit once DPD uniqueness is determined. Otherwise, a forwarding decision depends upon the current interface-specific relay set state. The descriptions of the relay set selection algorithms in the Appendices to this document specify the respective heuristics for multicast packet forwarding and specific DPD or other processing required to achieve correct SMF behavior in each case. For example, one class of forwarding is based upon relay set election status and the packet's previous hop, while other classes designate the local SMF router as a forwarder for all neighboring nodes. 6. SMF Duplicate Packet Detection Duplicate packet detection (DPD) is often a requirement in MANET or wireless mesh packet forwarding mechanisms because packets may be transmitted out the same physical interface upon which they arrived and nodes may also receive copies of previously-transmitted packets from other forwarding neighbors. SMF operation requires DPD and implementations MUST provide mechanisms to detect and reduce the likelihood of forwarding duplicate multicast packets using temporal packet identification. It is RECOMMENDED this be implemented by keeping a history of recently-processed multicast packets for comparison to incoming packets. A DPD packet cache history SHOULD be kept long enough to span the maximum network traversal lifetime, MAX_PACKET_LIFETIME, of multicast packets being forwarded within an SMF routing domain. The DPD mechanism SHOULD avoid keeping unnecessary state for packet flows such as those that are locally- generated or link-local destinations that would not be considered for forwarding as presented in Section 5. For both IPv4 and IPv6, this document describes two basic multicast duplicate packet detection mechanisms: header content identification-based (I-DPD) and hash- based (H-DPD) duplicate detection. I-DPD is a mechanism using specific packet headers, and option headers in the case of IPv6, in combination with flow state to estimate the temporal uniqueness of a Macker, editor & SMF Design Team Expires September 15, 2011 [Page 11] Internet-Draft SMF March 2011 packet. H-DPD uses hashing of the particular packet fields and payloads to provide an estimation of temporal uniqueness. Trade-offs of the two approaches to DPD merit different consideration dependent upon the specific SMF deployment scenario. Because of the potential addition of a hop-by-hop option header with IPv6, SMF deployments MUST be configured to use a common mechanism and DPD algorithm. The main difference between IPv4 and IPv6 SMF-DPD specification is the avoidance of any additional header options in the IPv4 case. For each network interface, SMF implementations MUST maintain DPD packet state as needed to support the forwarding heuristics of the relay set algorithm used. In general this involves keeping track of previously forwarded packets so that duplicates are not forwarded, but some relay techniques have additional considerations, such as discussed in Appendix B.2. Additional details of I-DPD and H-DPD processing and maintenance for different classes of packets are described in the following sections. 6.1. IPv6 Duplicate Packet Detection This section describes the mechanisms and options for SMF IPv6 DPD. The core IPv6 packet header does not provide any explicit identification header field that can be exploited for I-DPD. The following areas are described to support IPv6 DPD and each is covered in more detail in particular subsections: 1. the hop-by-hop SMF-DPD option header, 2. the use of IPv6 fragment header fields for I-DPD when they exist, 3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected, and 4. an H-DPD approach assisted, as needed, by the SMF-DPD option header. SMF MUST provide a DPD marking module that can insert the hop-by-hop IPv6 header option defined in this section. This process MUST come after any source-based fragmentation that may occur with IPv6. As with IPv4, SMF IPv6 DPD is presently specified to allow either a packet hash or header identification method for DPD. An SMF implementation MUST be configured to operate either in H-DPD or I-DPD mode and perform the appropriate routines outlined in the following sections. 6.1.1. IPv6 SMF-DPD Header Option The base IPv6 packet header does not contain a unique identifier suitable for DPD. This section defines an IPv6 Hop-by-Hop Option Macker, editor & SMF Design Team Expires September 15, 2011 [Page 12] Internet-Draft SMF March 2011 [RFC2460] to serve this purpose for IPv6 I-DPD. Additionally, the header option provides a mechanism to guarantee non-collision of hash values for different packets when H-DPD is used. If this is the only hop-by-hop option present, the optional "TaggerId" field (see below) is not included, and the size of the DPD ********************************************************************** *JY* It's better to mention Figure 2 *JY* *JY* What's TaggerId field? *JY* When I first saw "see blow", I try to find the TaggerId in the *JY* figure. Then I found that "it is not included". Just feel a little *JY* strange to be asked to see something don't exist :-P *JY* *JY* There are two figure 2 in the draft. one "Fig 2" and one "Figure 2" ********************************************************************** packet identifier (sequence number) or hash token is 24 bits or less, this will result in the addition of 8 bytes to the IPv6 packet header including the "Next Header", "Header Extension Length", SMF-DPD option fields, and padding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |H| DPD Identifier Option Fields or Hash Assist Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option "Option Type" = (Lower 5 bits pending IANA assignment, highest order MUST be 000). By having these three bits be zero, this specification requires that nodes not recognizing this option type should skip over this option and continue processing the header and that the option must not change en route [RFC2460]. "Opt. Data Len" = Length of option content (I.e., 1 + ( ? ( + 1): 0) + Length(DPD ID)). "H-bit" = a hash indicator bit value identifying DPD marking type. 0 == sequence-based approach w/ optional taggerId and a tuple-based ********************************************************************** *JY* What "w/" means here? Suggest expanding to "with" to be clear ********************************************************************** sequence number. 1 == indicates a hash assist value (HAV) field follows to aid in avoiding hash-based DPD collisions. When the "H-bit" is cleared (zero value), the SMF-DPD format to support I-DPD operation is specified as shown in Figure 2 and defines the extension header in accordance with [RFC2460]. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 13] Internet-Draft SMF March 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|TidTyp|TidLen| TaggerId (optional) ... | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode The "TidType" is a 3-bit field indicating the presence and type of the optional "TaggerId" field. ********************************************************************** *JY* Define the TidLen here. It will help the usage of in the *JY* following paragraph (It's seems not simply the length of Tid) ********************************************************************** The optional "TaggerId" is used to differentiate multiple ingressing border gateways that may commonly apply the SMF-DPD option header to packets from a particular source. This is provided for experimental purposes. The following table lists the valid TaggerId types: +---------+-------+-------------------------------------------------+ | Name | Value | Purpose | +---------+-------+-------------------------------------------------+ | NULL | 0 | Indicates no "TaggerId" field is present. | | | | "TidLen" MUST also be set to ZERO. | | DEFAULT | 1 | A "TaggerId" of non-specific context is | | | | present. "TidLen + 1" defines the length of | | | | the TaggerId field in bytes. | | IPv4 | 2 | A "TaggerId" representing an IPv4 address is | | | | present. The "TidLen" MUST be set to 3. | | IPv6 | 3 | A "TaggerId" representing an IPv6 address is | | | | present. The "TidLen" MUST be set to 15. | | ExtId | 7 | RESERVED FOR FUTURE USE (possible extended ID) | +---------+-------+-------------------------------------------------+ Table 1: TaggerId Types This format allows a quick check of the "TidType" field to determine if a "TaggerId" field is present. If the is NULL, then the length of the DPD packet field corresponds to the ( - 1). If the is non-NULL, then the length of the "TaggerId" field is equal to ( - 1) and the remainder of the ********************************************************************** *JY* It's seems that the is not the length of field *JY* Will be helpful to define before. ********************************************************************** option data comprises the DPD packet field. When the "TaggerId" field is present, the field can be considered a unique packet identifier in the context of the tuple. When the "TaggerId" field is not present, then it is assumed the source host applied the SMF-DPD option and the can be considered unique in the context of the IPv6 packet header tuple. IPv6 I-DPD operation details ********************************************************************** *JY* The paragraph describes: *JY* 1. TidType = NULL. *JY* 2. TidType = non-NULL. *JY* 3. TaggerId is present. *JY* 4. TaggerId is not present. *JY* It seems that No. 3 is the same case with No. 2 and No. 1 is *JY* the same case with No. 4. If it's like this, maybe it's easier to *JY* follow to have the same expression, or merge them. ********************************************************************** Macker, editor & SMF Design Team Expires September 15, 2011 [Page 14] Internet-Draft SMF March 2011 are described in Section 6.1.2. When the "H-bit" in the SMF-DPD option data is set, ********************************************************************** *JY* add "(one value)", to be consistent with the "zero value" before ********************************************************************** the data content value is interpreted as a Hash-Assist Value (HAV) used to facilitate H-DPD operation. In this case, source hosts or ingressing gateways apply the SMF-DPD with a HAV only when required to differentiate the hash value of a new packet with respect to hash values in the DPD cache. This situation can be detected locally on the node by running the hash algorithm and checking the DPD cache. prior ingressing a ********************************************************************** *JY* comma after "cache"? ********************************************************************** previously unmarked packet or a locally sourced packet. This helps to guarantee the uniqueness of generated hash values when H-DPD is used. Additionally, this also avoids the added overhead of applying the SMF-DPD option header to every packet. For many hash algorithms, it is expected that only sparse use of the SMF-DPD option may be required. The format of the SMF-DPD header option for H-DPD operation is given in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... |0|0|0| OptType | Opt. Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Hash Assist Value (HAV) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 SMF_DPD Header Option in H-DPD Mode The SMF-DPD option should be applied with a HAV to produce a unique hash digest for packets within the context of the IPv6 packet header . The size of the HAV field is implied by the "Opt. Data Len". The appropriate size of the field depends upon the collision properties of the specific hash algorithm used. More details on IPv6 H-DPD operation are provided in Section 6.1.3. 6.1.2. IPv6 Identification-based DPD The following table summarizes the IPv6 I-DPD processing and forwarding decision approach. Within the table '*' indicates an ignore field condition. ********************************************************************** *JY* What the "ignore field condition" means? *JY* It means the field is not important and we can just ignore it? ********************************************************************** Macker, editor & SMF Design Team Expires September 15, 2011 [Page 15] Internet-Draft SMF March 2011 +-------------+-----------+-----------+-----------------------------+ | IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action | | Fragment | IPsec | I-DPD | | | Header | Header | Header | | +-------------+-----------+-----------+-----------------------------+ | Present | * | * | Use Fragment Header I-DPD | | | | | Check and Process for | | | | | Forwarding | | Not Present | Present | * | Use IPsec Header I-DPD | | | | | Check and Process for | | | | | Forwarding | | Present | * | Present | Invalid, do not Forward | | Not Present | Present | Present | Invalid, do not Forward | | Not Present | Not | Not | Add I-DPD Header,and | | | Present | Present | Process for Forwarding | | Not Present | Not | Present | Use I-DPD Header Check and | | | Present | | Process for Forwarding | +-------------+-----------+-----------+-----------------------------+ Table 2: IPv6 I-DPD Processing Rules ********************************************************************** *JY* It's important to define the "*", so that we can distinguish *JY* Row 1: Present * * *JY* Row 3: Present * present *JY* and *JY* Row 2: not present Present * *JY* Row 4: not present present present *JY* *JY* because if we assume "*" as "not important", Row 3 is a subset of *JY* Row 1, and Row 4 is a subset of Row 4. ********************************************************************** If the IPv6 multicast packet is an IPv6 fragment, SMF MUST use the fragment extension header fields for packet identification. This identifier can be considered unique in the context of the of the IP packet. If the packet is an unfragmented IPv6 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header field can be considered a unique identifier in the context of the where the "IPsecType" is either AH or ESP [RFC4302]. For unfragmented, non-IPsec, IPv6 packets, the use of the SMF-DPD header option is necessary to support I-DPD operation. The SMF-DPD header option is applied in the context of the of the IP packet. End systems or ingressing SMF gateways are responsible for applying this option to support DPD. The following table summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv6 | Packet DPD ID Context | Packet DPD ID | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPsec | | | | Packet | | | | Regular | <[taggerId:]srcAddr:dstAddr> | | +-----------+---------------------------------+---------------------+ Macker, editor & SMF Design Team Expires September 15, 2011 [Page 16] Internet-Draft SMF March 2011 Table 3: IPv6 I-DPD Packet Identification Types "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). The "TaggerId" is an optional field of the IPv6 SMF-DPD header option. ********************************************************************** *JY* If defined before, not necessary here. ********************************************************************** 6.1.3. IPv6 Hash-based DPD A default hash-based DPD approach (H-DPD) for use by SMF is specified as follows. An MD5 [RFC1321] hash of the non-mutable header fields, options fields, and data content of the IPv6 multicast packet is used to produce a 128-bit digest. The least significant 64 bits of this digest is used for SMF packet identification. The approach for calculating this hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. This approach should have a reasonably low probability of digest collision when packet headers and content are varying. MD5 is being applied in SMF only to provide a low probability of collision and is not being used for cryptographic or authentication purposes. A history of the packet hash values SHOULD be maintained within the context of the IPv6 packet header . SMF ingress points (i.e., source hosts or gateways) use this history to confirm that new packets are unique with respect to their hash value. The Hash-assist Value (HAV) field described in Section 6.1.1 is provided as a differentiating field when a digest collision would otherwise occur. Note that the HAV is an immutable option field and SMF MUST process any included HAV values (see Section 6.1.1) in its hash calculation. If a packet results in a digest collision (i.e., by checking the H-DPD digest history) within the DPD cache kept by SMF forwarders, the packet should be silently dropped. If a digest collision is detected at an SMF ingress point the H-DPD option header is constructed with a randomly generated HAV. A HAV is recalculated as needed to produce a non-colliding hash value prior to forwarding. The multicast packet is then forwarded with the added IPv6 SMF-DPD header option. The MD5 indexing and IPv6 HAV approaches are specified at present for consistency and robustness to suit experimental uses. Future approaches and experimentation may discover designs tradeoffs in hash robustness and efficiency worth considering. Enhancements MAY include reducing the maximum payload length that is processed, determining shorter indexes, or applying more efficient hashing algorithms. Use of the HAV functionality may allow for application of "lighter-weight" hashing techniques that might not have been Macker, editor & SMF Design Team Expires September 15, 2011 [Page 17] Internet-Draft SMF March 2011 initially considered due to poor collision properties otherwise. Such techniques could reduce packet processing overhead and memory requirements. 6.2. IPv4 Duplicate Packet Detection This section describes the mechanisms and options for IPv4 DPD. The IPv4 packet header [RFC0791] 16-bit "Identification" field MAY be used for DPD assistance, but practical limitations may require alternative approaches in some situations. The following areas are described to support IPv4 DPD: 1. the use of IPv4 fragment header fields for I-DPD when they exist, 2. the use of IPsec sequencing for I-DPD when a non-fragmented IPv4 IPsec packet is detected, and 3. a H-DPD approach. A specific SMF-DPD marking option is not specified for IPv4 since header options are not as tractable for end systems as for IPv6. IPv4 packets from a particular source are assumed to be marked with a temporally unique value in the "Identification" field of the packet header that can serve for SMF-DPD purposes. However, in present operating system networking kernels, the IPv4 header "Identification" value is not always generated properly, especially when the "don't fragment" (DF) bit is set. The IPv4 I-DPD mode of this specification requires that IPv4 "Identification" fields are managed reasonably by source hosts and that temporally unique values are set within the context of the packet header tuple. If this is not expected during an SMF deployment, then it is RECOMMENDED that the H-DPD method be used as a more reliable approach. Since IPv4 SMF does not specify an options header, the interoperability constraints are looser than the IPv6 version and forwarders may be operate with mixed H-DPD and I-DPD modes as long as they consistently perform the appropriate DPD routines outlined in the following sections. However, it is RECOMMENDED that a deployment be configured with a common mode for operational consistency. 6.2.1. IPv4 Identification-based DPD The following table summarizes the IPv4 I-DPD processing approach once a packet has passed the basic forwardable criteria described in Section 5. Within the table '*' indicates an ignore field condition. DF, MF, Fragment offset correspond to related fields and flags defined in [RFC0791]. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 18] Internet-Draft SMF March 2011 +------+------+----------+---------+--------------------------------+ | DF | MF | Fragment | IPsec | IPv4 I-DPD Action | | flag | flag | offset | | | +------+------+----------+---------+--------------------------------+ | 1 | 1 | * | * | Invalid, Do Not Forward | | 1 | 0 | nonzero | * | Invalid, Do Not Forward | | * | 0 | zero | not | Tuple I-DPD Check and Process | | | | | Present | for Forwarding | | * | 0 | zero | Present | IPsec enhanced Tuple I-DPD | | | | | | Check and Process for | | | | | | Forwarding | | 0 | 0 | nonzero | * | Extended Fragment Offset Tuple | | | | | | I-DPD Check and Process for | | | | | | Forwarding | | 0 | 1 | zero or | * | Extended Fragment Offset Tuple | | | | nonzero | | I-DPD Check and Process for | | | | | | Forwarding | +------+------+----------+---------+--------------------------------+ Table 4: IPv4 I-DPD Processing Rules For performance reasons, IPv4 network fragmentation and reassembly of multicast packets within wireless MANET networks should be minimized, yet SMF provides the forwarding of fragments when they occur. If the IPv4 multicast packet is a fragment, SMF MUST use the fragmentation header fields for packet identification. This identification can be considered temporally unique in the context of the of the IPv4 packet. If the packet is an unfragmented IPv4 IPsec packet, SMF MUST use IPsec fields for packet identification. The IPsec header field can be considered a unique identifier in the context of the where the "IPsecType" is either AH or ESP [RFC4302]. Finally, for unfragmented, non-IPsec, IPv4 packets, the "Identification" field can be used for I-DPD purposes. The "Identification" field can be considered unique in the context of the IPv4 tuple. The following table summarizes these packet identification types: +-----------+---------------------------------+---------------------+ | IPv4 | Packet Identification Context | Packet Identifier | | Packet | | | | Type | | | +-----------+---------------------------------+---------------------+ | Fragment | | | | IPsec | | | | Packet | | | Macker, editor & SMF Design Team Expires September 15, 2011 [Page 19] Internet-Draft SMF March 2011 | Regular | | | +-----------+---------------------------------+---------------------+ Table 5: IPv4 I-DPD Packet Identification Types "IPsecType" is either Authentication Header (AH) or Encapsulating Security Payload (ESP). The limited size (16 bits) of the IPv4 header "Identification" field [RFC0791] may result in more frequent value field wrapping, particularly if a common sequence space is used by a source for multiple destinations. If I-DPD operation is required, the use of the "internal hashing" technique described in Section 10 may mitigate this limitation of the IPv4 "Identification" field for SMF-DPD. In this case the "internal hash" value would be concatenated with the "Identification" value for I-DPD operation. 6.2.2. IPv4 Hash-based DPD To ensure consistent IPv4 H-DPD operation among SMF nodes, a default hashing approach is specified. This is similar to that specified for IPv6, but the H-DPD header option with HAV is not considered. SMF MUST perform an MD5 [RFC1321] hash of the immutable header fields, option fields and data content of the IPv4 multicast packet resulting in a 128-bit digest. The least significant 64 bits of this digest is used for SMF packet identification. ********************************************************************** *JY* Where to put the 64-bits? ********************************************************************** The approach for calculating the hash value SHOULD follow the same guidelines described for calculating the Integrity Check Value (ICV) described in [RFC4302] with respect to non-mutable fields. A history of the packet hash values SHOULD be maintained in the context of . The context for IPv4 is more specific than that of IPv6 since the SMF-DPD HAV cannot be employed to mitigate hash collisions. The MD5 hash is specified at present for consistency and robustness. Future approaches and experimentation may discover design tradeoffs in hash robustness and efficiency worth considering for future revisions of SMF. This MAY include reducing the packet payload length that is processed, determining shorter indexes, or applying a more efficient hashing algorithm. 7. Relay Set Selection 7.1. Non-Reduced Relay Set Forwarding SMF implementations MUST support CF as a basic forwarding mechanism when reduced relay set information is not available or not selected Macker, editor & SMF Design Team Expires September 15, 2011 [Page 20] Internet-Draft SMF March 2011 for operation. In CF mode, each node transmits a locally generated or newly received forwardable packet exactly once. The DPD techniques described in Section 6 are critical to proper operation and prevent duplicate packet retransmissions by the same forwarding node. 7.2. Reduced Relay Set Forwarding MANET reduced relay sets are often achieved by distributed algorithms that can dynamically calculate a topological connected dominating set (CDS). A goal of SMF is to apply reduced relay sets for more efficient multicast dissemination within dynamic topologies. To accomplish this SMF MUST support the ability to modify its multicast packet forwarding rules based upon relay set state received dynamically during operation. In this way, SMF forwarding operates effectively as neighbor adjacencies or multicast forwarding policies within the topology change. In early SMF experimental prototyping, the relay set information has been derived from coexistent unicast routing control plane traffic flooding processes [MDC04]. From this experience, extra pruning considerations were sometimes required when utilizing a relay set from a separate routing protocol process. As an example, relay sets formed for the unicast control plane flooding MAY include additional redundancy that may not be desired for multicast forwarding use (e.g., biconnected relay set). Here is a recommended criteria list for SMF relay set selection algorithm candidates: 1. Robustness to topological dynamics and mobility 2. Localized election or coordination of any relay sets 3. Reasonable minimization of CDS relay set size given above constraints 4. Heuristic support for preference or election metrics Some relay set algorithms meeting these criteria are described in the Appendices of this document. Additional relay set selection algorithms may be specified in separate specifications in the future. Each Appendix subsection in this document can serve as a template for specifying additional relay algorithms. Figure 4 depicts a information flow diagram of possible relay set control options. The SMF Relay Set State represents the information base that is used by SMF in the forwarding decision process. The relay set control option diagram demonstrates that the SMF relay set Macker, editor & SMF Design Team Expires September 15, 2011 [Page 21] Internet-Draft SMF March 2011 state may be determined by fundamentally three different methods: independent operation with NHDP [RFC5444] ********************************************************************** *JY* RFC5444 is packetbb. *JY* Suggest replacing NHDP, packetbb with rfc numbers, for easier referencing/searching. *JY* packetbb doesn't appear in any official/published document ********************************************************************** input providing dynamic network neighborhood adjacency information that is then used by a particular relay set selection, slave operation with an existing unicast MANET routing protocol that is capable of providing CDS election information that can be used by SMF, and cross layer operation that may involve lower layer neighbor or link information. ********************************************************************** *JY* The 8-line sentence is a little long. Using bullets makes it clearer. *JY* The sentence try to say 1. NHDP, 2. unicast, 3. cross-layer, exactly *JY* the same with the following items. Maybe it's better to either make the *JY* statement simpler here, followed by a detailed description, or just *JY* merge them. *JY* *JY* Maybe it's better to make "cross-layer" in the text and "L2-information" *JY* in the figure consistent. ********************************************************************** Other heuristics to influence and control election can come from network management or other interfaces as shown on the right. Of course CF mode, simplifies the control and does not require other input but relies solely on DPD. Possible L2 Trigger/Information | | ______________ ______v_____ __________________ | MANET | | | | | | Neighborhood | | Relay Set | | Other Heuristics | | Discovery |----------->| Selection |<------| (Preference,etc) | | Protocol | neighbor | Algorithm | | Net Management | |______________| info |____________| |__________________| \ / \ / neighbor\ / Dynamic Relay info* \ ____________ / Set Status \ | SMF | / (State, {neighbor info}) `-->| Relay Set |<--' | State | -->|____________| / / ______________ | Coexistent | | MANET | | Unicast | | Process | |______________| Figure 4: SMF Reduced Relay Set Information Flow More discussion is provided on the three styles of SMF operation with reduced relay sets as illustrated in Figure 4 : 1. Independent operation: In this case, SMF operates independently from any unicast routing protocols. To support reduced relay sets SMF MUST perform its own relay set selection using information gathered from signaling. It is RECOMMENDED that an associated MANET NHDP process be use ********************************************************************** *JY* "be used"? ********************************************************************** for this signaling. NHDP Macker, editor & SMF Design Team Expires September 15, 2011 [Page 22] Internet-Draft SMF March 2011 messaging SHOULD be appended with additional [RFC5444] type- length-value (TLV) content to support SMF-specific requirements as discussed in [RFC6130] and for the applicable relay set algorithm described in the Appendices of this document or future specifications. Unicast routing protocols may co-exist, even using the same NHDP process, but signaling that supports reduced relay set selection for SMF is independent of these protocols. 2. Operation with CDS-aware unicast routing protocol: In this case, a coexistent unicast routing protocol provides dynamic relay set state based upon its own control plane CDS or neighborhood discovery information. ********************************************************************** *JY* We have "dynamic relay set state" here, "Dynamic Relay set status" and *JY* "SMF Relay set state" in the Figure. However, there are not well defined. *JY* What's the relationship between them? *JY* *JY* This item seems to correspond to the left-bottom block in the figure. *JY* However, I don't see the relation it "provides dynamic relay set" in the *JY* figure. In contrast, I see the relation of this "dynamic relay set" with *JY* other blocks, but not presented in the text. ********************************************************************** 3. Cross-layer Operation: In this case, SMF operates using neighborhood status and triggers from a cross-layer information base for dynamic relay set selection and maintenance (e.g., lower link layer). 8. SMF Neighborhood Discovery Requirements This section defines the requirements for use of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF operation. Note that basic CF forwarding requires no neighborhood topology knowledge since in this configured mode every SMF node relays all traffic. Supporting more reduced SMF relay set operation requires the discovery and maintenance of dynamic neighborhood topology information. The MANET NHDP protocol can be leveraged ********************************************************************** *JY* "be leveraged" ->"be leveraged to" ********************************************************************** provide this necessary information, however there are SMF-specific requirements for related NHDP use. This is the case for both "independent" SMF operation where NHDP is being used specifically to support SMF or when one NHDP instance is used for both for SMF and a coexistent MANET unicast routing protocol. NHDP HELLO messages and the resultant neighborhood information base are described separately within the NHDP specification. To summarize, the NHDP protocol provides the following basic functions: 1. 1-hop neighbor link sensing and bidirectionality checks of neighbor links, 2. 2-hop neighborhood discovery including collection of 2-hop neighbors and connectivity information, 3. Collection and maintenance of the above information across multiple interfaces, and 4. A method for signaling SMF information throughout the 2-hop neighborhood through the use of TLV extensions. Appendices (A-C) of this document describe CDS-based relay set selection algorithms that can achieve efficient SMF operation, even in dynamic, mobile networks and each of the algorithms has been Macker, editor & SMF Design Team Expires September 15, 2011 [Page 23] Internet-Draft SMF March 2011 initially experimented within a working SMF prototype [MDDA07]. When using these algorithms in conjunction with NHDP, a method verifying neighbor SMF operation is required in order to insure correct relay set selection. NHDP along with SMF operation verification provides the necessary information required by these algorithms to conduct relay set selection. Verification of SMF operation may be done administratively or through the use of the SMF relay algorithms TLVs defined in the following subsections. Use of the SMF relay algorithm TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery. The following sub-sections ********************************************************************** *JY* there is just one subsection. Suggest absolute references all through the document, i.e. always to reference to secton X.Y rather than "to the below section" In part, because it enables html-versions to have proper anchors on tools and other pages. ********************************************************************** specify some SMF-specific TLV types supporting general SMF operation or supporting the algorithms described in the Appendices. The Appendices describing several relay set algorithms also specify any additional requirements for use with NHDP and reference the applicable TLV types as needed. 8.1. SMF Relay Algorithm TLV Types This section ********************************************************************** *JY* *JY* We have 8.1 here, but no 8.2 and so on followed. It's a little strange *JY* to have just one numbered subsection. Maybe can remove the subsection *JY* number and go to the TLV types directly ********************************************************************** specifies TLV types to be used within NHDP messages to identify the CDS relay set selection algorithm(s) in use. Two TLV types are defined, one message TLV type and one address TLV type. 8.1.1. SMF Message TLV Type The message TLV type denoted SMF_TYPE is used to identify the existence of an SMF instance operating in conjunction with NHDP. This message TLV type makes use of the extended type field as defined by [RFC5444] to convey the CDS relay set selection algorithm currently in use by the SMF message originator. When NHDP is used to support SMF operation, the SMF_TYPE TLV, containing the extended type field with the appropriate value, SHOULD be included in NHDP_HELLO messages (HELLO messages as defined in [RFC6130]. ********************************************************************** *JY* right parenthesis missed here ********************************************************************** This allows SMF nodes to learn when neighbors are configured to use NHDP for information exchange including algorithm type and related algorithm information. This information can be used to take action, such as ignoring neighbor information using incompatible algorithms. It is possible that SMF neighbors MAY be configured differently and still operate cooperatively, but these cases will vary dependent upon the algorithm types designated. This document defines the following Message TLV type as specified in Table 6 conforming to [RFC5444]. The TLV extended type field is used to contain the sender's "Relay Algorithm Type". The interpretation of the "value" content of these TLVs is defined per "Relay Algorithm Type" and may contain algorithm specific information. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 24] Internet-Draft SMF March 2011 +---------------+----------------+--------------------+ | | TLV syntax | Field Values | +---------------+----------------+--------------------+ | type | | SMF_TYPE | | extended type | | | | length | | variable | | value | | variable | +---------------+----------------+--------------------+ Table 6: SMF Type Message TLV In Table 6 is an 8-bit field containing a number 0-255 representing the "Relay Algorithm Type" of the originator address of the corresponding NHDP message. ********************************************************************** *JY* Can we make the name relayAlgorithmId and "Relay algorithmType" be *JY* consistent? not sure ********************************************************************** Possible values for the are defined in Table 7. The table provides value assignments, future IANA assignment spaces, and an experimental space. The experimental space use MUST NOT assume uniqueness and thus should not be used for general interoperable deployment prior to official IANA assignment. +-------------+--------------------+--------------------------------+ | Type Value | Extended Type | Algorithm | | | Value | | +-------------+--------------------+--------------------------------+ | SMF_TYPE | 0 | CF | | SMF_TYPE | 1 | S-MPR | | SMF_TYPE | 2 | E-CDS | | SMF_TYPE | 3 | MPR-CDS | | SMF_TYPE | 4-127 | Future Assignment STD action | | SMF_TYPE | 128-239 | No STD action required | | SMF_TYPE | 240-255 | Experimental Space | +-------------+--------------------+--------------------------------+ Table 7: SMF Relay Algorithm Type Values Acceptable and fields of an SMF_TYPE TLV are dependent on the extended type value (i.e. relay algorithm type). The appropriate algorithm type, as conveyed in the field, defines the meaning and format of its TLV field. For the algorithms defined by this document, see the appropriate appendix for the field format. 8.1.2. SMF Address Block TLV Type An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor relay algorithm) is specified in Table 8. This TLV enables CDS relay algorithm operation and configuration to be shared among 2-hop Macker, editor & SMF Design Team Expires September 15, 2011 [Page 25] Internet-Draft SMF March 2011 neighborhoods. Some relay algorithms require two hop neighbor configuration in order to correctly select relay sets. It is also useful when mixed relay algorithm operation is possible, some examples of mixed use is outlined in the appendices. The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types share a common format. +---------------+----------------+--------------------+ | | TLV syntax | Field Values | +---------------+----------------+--------------------+ | type | | SMF_NBR_TYPE | | extended type | | | | length | | variable | | value | | variable | +---------------+----------------+--------------------+ Table 8: SMF Type Address Block TLV in Table 8 is an 8-bit unsigned integer field containing a number 0-255 representing the "Relay Algorithm Type" value that corresponds to any associated address in the address block. Note that "Relay Algorithm Type" values for 2-hop neighbors can be conveyed in a single TLV or multiple value TLVs as described in [RFC5444]. It is expected that SMF nodes using NHDP construct address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm Type" and to advertise neighbor algorithm values received in SMF_TYPE TLVs from those neighbors. Again values for the are defined in Table 8. The interpretation of the "value" field of SMF_NBR_TYPE TLVs is defined per "Relay Algorithm Type" and may contain algorithm specific information. See the appropriate appendix for definitions of value fields for the algorithms defined by this document. 9. SMF Border Gateway Considerations It is expected that SMF will be used to provide simple forwarding of multicast traffic within a MANET or mesh routing topology. A border router gateway approach should be used to allow interconnection of SMF areas with networks using other multicast routing protocols, such as PIM. It is important to note that there are many scenario- specific issues that should be addressed when discussing border multicast routers. At the present time, experimental deployments of SMF and PIM border router approaches have been demonstrated[DHS08]. Some of the functionality border routers may need to address includes Macker, editor & SMF Design Team Expires September 15, 2011 [Page 26] Internet-Draft SMF March 2011 the following: 1. Determining which multicast group traffic transits the border router whether entering or exiting the attached SMF routing domain. 2. Enforcement of TTL threshold or other scoping policies. 3. Any marking or labeling to enable DPD on ingressing packets. ********************************************************************** *JY* TTL -> hoplimit *JY* "Any" marking or labeling can enable DPD? ********************************************************************** 4. Interface with exterior multicast routing protocols. 5. Possible operation with multiple border routers (presently beyond scope of this document). 6. Provisions for participating non-SMF nodes. Each of these areas is discussed in more detail in the following subsections. ********************************************************************** *JY* It seems that not all of the areas is discussed in the sub-sections *JY* item 1 ----> 9.1 *JY* item 2 ----> 9.2 *JY* item 3 ----> ? *JY* item 4 ----> 9.3 *JY* item 5 ----> 9.4 *JY* item 6 ----> ? ********************************************************************** Note the behavior of SMF border routers is the same as that of non-border SMF nodes when forwarding packets on interfaces within the SMF routing domain. Packets that are passed outbound to interfaces operating fixed-infrastructure multicast routing protocols SHOULD be evaluated for duplicate packet status since present standard multicast forwarding mechanisms do not usually perform this function. 9.1. Forwarded Multicast Groups Mechanisms for dynamically determining groups for forwarding into a MANET SMF routing domain is an evolving technology area. Ideally, only groups for which there is active group membership should be injected into the SMF domain. This can be accomplished by providing an IPv4 Internet Group Membership Protocol (IGMP) or IPv6 Multicast Listener Discovery (MLD) proxy protocol so that MANET SMF nodes can inform attached border routers (and hence multicast networks) of their current group membership status. For specific systems and services it may be possible to statically configure group membership joins in border routers, but it is RECOMMENDED that some form of IGMP/MLD proxy or other explicit, dynamic control of membership be provided. Specification of such an IGMP/MLD proxy protocol is beyond the scope of this document. For outbound traffic, SMF border routers can perform duplicate packet detection and forward non-duplicate traffic that meets TTL/hop limit and scoping criteria and forward packet to interfaces external to the SMF routing domain. Appropriate IP multicast routing (PIM, etc) on those interfaces can then make further forwarding decisions with respect to the multicast packet. Note that the presence of multiple border routers associated with a MANET routing domain raises additional issues. This is further discussed in Section 9.4 but further work is expected to be needed here. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 27] Internet-Draft SMF March 2011 9.2. Multicast Group Scoping Multicast scoping is used by network administrators to control the network routing domains reachable by multicast packets. This is usually done by configuring external interfaces of border routers in the border of a routing domain to not forward multicast packets which must be kept within the routing region. This is commonly done based on TTL of messages or the basis of group addresses. These schemes are known respectively as: 1. TTL scoping. ********************************************************************** *JY* TTL/hoplimit ********************************************************************** 2. Administrative scoping. For IPv4, network administrators can configure border routers with the appropriate TTL thresholds or administratively scoped multicast groups for the router interfaces as with any traditional multicast router. However, for the case of TTL scoping it SHOULD be taken into account that the packet could traverse multiple hops within the MANET SMF routing domain before reaching the border router. Thus, TTL thresholds SHOULD be selected carefully. For IPv6, multicast address spaces include information about the scope of the group. Thus, border routers of an SMF routing domain know if they must forward a packet based on the IPv6 multicast group address. For the case of IPv6, it is RECOMMENDED that a MANET SMF routing domain be designated a site-scoped multicast domain. Thus, all IPv6 site-scoped multicast packets in the range FF05::/16 SHOULD be kept within the MANET SMF routing domain by border routers. IPv6 packets in any other wider range scopes (i.e. FF08::/16, FF0B::/16 and FF0E::16) MAY traverse border routers unless other restrictions different from the scope applies. Given that scoping of multicast packets is performed at the border routers, and given that existing scoping mechanisms are not designed to work with mobile routers, it is assumed that non-border routers running SMF will not stop forwarding multicast data packets of an appropriate site scoping. That is, it is assumed that an SMF routing domain is a site-scoped multicast area. 9.3. Interface with Exterior Multicast Routing Protocols The traditional operation of multicast routing protocols is tightly integrated with the group membership function. Leaf routers are configured to periodically gather group membership information, while intermediate routers conspire to create multicast trees connecting routers with directly-connected multicast sources and routers with active multicast receivers. In the concrete case of SMF, border routers can be considered leaf routers. Mechanisms for multicast Macker, editor & SMF Design Team Expires September 15, 2011 [Page 28] Internet-Draft SMF March 2011 sources and receivers to interoperate with border routers over the multihop MANET SMF routing domain as if they were directly connected to the router need to be defined. The following issues need to be addressed: 1. A mechanism by which border routers gather membership information 2. A mechanism by which multicast sources are known by the border router 3. A mechanism for exchange of exterior routing protocol messages across the SMF routing domain if the SMF routing domain is to provide transit connectivity for multicast traffic. It is beyond the scope of this document to address implementation solutions to these issues. As described in Section 9.1, IGMP/MLD proxy mechanisms can be deployed to address some of these issues. Similarly, exterior routing protocol messages could be tunneled or conveyed across an SMF routing domain but doing this robustly in a distributed wireless environment likely requires additional considerations outside the scope of this document. The need for the border router to receive traffic from recognized multicast sources within the SMF routing domain is important to potentially achieve interoperability with existing routing protocols. For instance, PIM-S requires routers with locally attached multicast sources to register them to the Rendezvous Point (RP) so that nodes can join the multicast tree. In addition, if those sources are not advertised to other autonomous systems (AS) using Multicast Source Discovery Protocol (MSDP), receivers in those external networks are not able to join the multicast tree for that source. 9.4. Multiple Border Routers An SMF domain might be deployed with multiple participating nodes having connectivity to external, fixed-infrastructure networks. Allowing multiple nodes to forward multicast traffic to/from the SMF routing domain can be beneficial since it can increase reliability, and provide better service. For example, if the SMF routing domain were to fragment with different SMF nodes maintaining connectivity to different border routers, multicast service could still continue successfully. But, the case of multiple border routers connecting a SMF routing domain to external networks presents several challenges for SMF: 1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec encapsulation or DPD option) packets possibly injected by multiple border routers. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 29] Internet-Draft SMF March 2011 2. Source-based relay algorithms handling of duplicate traffic injected by multiple border routers. 3. Determination of which border router(s) will forward outbound multicast traffic. 4. Additional challenges with interfaces to exterior multicast routing protocols. When multiple border routers are present they may be alternatively (due to route changes) or simultaneously injecting common traffic into the MANET routing region that has not been previously marked for SMF-DPD. Different border routers would not be able to implicitly synchronize sequencing of injected traffic since they may not receive exactly the same messages due to packet losses. For IPv6 I-DPD operation, the optional "TaggerId" field described for the SMF-DPD header option can be used to mitigate this issue. When multiple border routers are injecting a flow into a MANET routing region, there are two forwarding policies that SMF nodes running I-DPD may implement: 1. Redundantly forward the multicast flows (identified by ) from each border router, performing DPD processing on a or basis, or 2. Use some basis to select the flow of one tagger (border router) over the others and forward packets for applicable flows (identified by ) only for the selected "Tagger ID" until timeout or some other criteria to favor another tagger occurs. It is RECOMMENDED that the first approach be used in the case of I-DPD operation. Additional specification may be required to describe an interoperable forwarding policy based on this second option. Note that the implementation of the second option requires that per-flow (i.e., ) state be maintained for the selected "Tagger ID". The deployment of H-DPD operation may alleviate DPD resolution when ingressing traffic comes from multiple border routers. Non-colliding hash indexes (those not requiring the H-DPD options header in IPv6) should be resolved effectively. 10. Security Considerations Gratuitous use of option headers can cause problems in routers. Other IP routers external to an SMF routing domains that might receive forwarded multicast should ignore SMF-specific header options when encountered. The header options types are encoded appropriately to allow for this behavior. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 30] Internet-Draft SMF March 2011 Here we briefly discuss several SMF denial-of-service (DoS) attack scenarios and we provide some initial recommended mitigation strategies. A potential denial-of-service attack against SMF forwarding is possible when a malicious node has a form of wormhole access to multiple part of a network topology. In the wireless ad hoc case, a directional antenna is one way to provide such a wormhole physically. If such a node can preview forwarded packets in one part of the network and forward modified versions to another part of the network it can perform the following attack. The malicious node could reduce the TTL or Hop Limit of the packet and transmit it to the SMF node causing it to forward the packet with a limited TTL (or even drop it) ********************************************************************** *JY* TTL/hop limit ********************************************************************** and make a DPD entry that could block or limit the subsequent forwarding of later-arriving valid packets with correct TTL values. This would be a relatively low-cost, high-payoff attack that would be hard to detect and thus attractive to potential attackers. An approach of caching TTL information with DPD state and taking appropriate forwarding actions is identified in Section 5 to mitigate this form of attack. Sequence-based packet identifiers are predictable and thus provide an opportunity for a DoS attack against forwarding. Forwarding protocols that use DPD techniques, such as SMF, may be vulnerable to DoS attacks based on spoofing packets with apparently valid packet identifier fields. In wireless environments, where SMF will most likely be used, the opportunity for such attacks may be more prevalent than in wired networks. In the case of IPv4 packets, fragmented IP packets or packets with IPsec headers applied, the DPD "identifier portions" of potential future packets that might be forwarded is highly predictable and easily subject to denial-of- service attacks against forwarding. A RECOMMENDED technique to counter this concern is for SMF implementations to generate an "internal" hash value that is concatenated with the explicit I-DPD packet identifier to form a unique identifier that is a function of the packet content as well as the visible identifier. SMF implementations could seed their hash generation with a random value to make it unlikely that an external observer could guess how to spoof packets used in a denial-of-service attack against forwarding. Since the hash computation and state is kept completely internal to SMF nodes, the cryptographic properties of this hashing would not need to be extensive and thus possibly of low complexity. Experimental implementations may determine that a lightweight hash of even only portions of packets may suffice to serve this purpose. While H-DPD is not as readily susceptible to this form of DoS attack, it is possible that a sophisticated adversary could use side information to construct spoofing packets to mislead forwarders using Macker, editor & SMF Design Team Expires September 15, 2011 [Page 31] Internet-Draft SMF March 2011 a well-known hash algorithm. Thus, similarly, a separate "internal" hash value could be concatenated with the well-known hash value to alleviate this security concern. The support of forwarding IPsec packets without further modification for both IPv4 and IPv6 is supported by this specification. Authentication mechanisms to identify the source of IPv6 option headers should be considered to reduce vulnerability to a variety of attacks. 11. IANA Considerations This document raises multiple IANA Considerations. These include the IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type- Length-Value (TLV) constructs [RFC5444]) to be used with NHDP [RFC6130]operation as needed to support different forms of SMF operation. There is one message TLV type and one address TLV type needed to be assigned for SMF purposes as discussed in Section 8.1. The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be assigned). The SL-MANET-ROUTERS multicast address will be registered for both IPv4 and IPv6 multicast address spaces. 11.1. IPv6 SMF-DPD Header Extension This document requests IANA assignment of the "SMF_DPD" hop-by-hop option type from the IANA "IPv6 Hop-by-Hop Options Option Type" registry (see Section 5.5 of [RFC2780]). The format of this new option type is described in Section 6.1.1. A portion of the option data content is the taggger identifier type "TidType" that provides a context for the "TaggerId" that is optionally included to identify the node that added the SMF_DPD option to the packet. This document defines a namespace for IPv6 SMF_DPD Tagger Identifier Type values: ietf:manet:smf:taggerIdTypes The values that can be assigned within the "ietf:manet:smf: taggerIdTypes" name-space are numeric indexes in the range [0, 7], boundaries included. All assignment requests are granted on an "IETF Consensus" basis as defined in [RFC5226]. This specification registers Tagger Identification Type values from Table 9 in the registry "ietf:manet:smf:taggerIdTypes": Macker, editor & SMF Design Team Expires September 15, 2011 [Page 32] Internet-Draft SMF March 2011 +----------+-------+---------------+ | Mnemonic | Value | Reference | +----------+-------+---------------+ | NULL | 0 | This document | | DEFAULT | 1 | This document | | IPv4 | 2 | This document | | IPv6 | 3 | This document | | ExtId | 7 | This document | +----------+-------+---------------+ Table 9: TaggerId Types 11.2. SMF Type-Length-Value This document requests IANA assignment of one message "SMF_TYPE" TLV type and one address block "SMF_NBR_TYPE" TLV type from the [RFC6130] specific registry space. The common format of these new TLV types is described in Table 6 and Table 8. Furthermore this document defines a namespace for algorithm ID types using the extended type TLV value field defined by [RFC5444]. Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace. ietf:manet:packetbb:nhdp:smf:relayAlgorithmID The values that can be assigned within the "ietf:manet:packetbb:nhdp: smf:relayAlgorithmID" name-space are numeric indexes in the range [0, 239], boundaries included. Assignment requests for the [0-127] are granted on an "IETF Consensus" basis as defined in [RFC5226]. Standards action is not required for assignment requests of the range [128-239]. Documents requesting relayAlgorithmId values SHOULD define value field uses contained by the SMF_TYPE: and SMF_NBR_TYPE: full type TLVs. This specification registers the following Relay Algorithm ID Type values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp: smf:relayAlgorithmID +----------+-------+------------+ | Mnemonic | Value | Reference | +----------+-------+------------+ | CF | 0 | | | S-MPR | 1 | Appendix B | | E-CDS | 2 | Appendix A | | MPR-CDS | 3 | Appendix C | +----------+-------+------------+ Table 10: Relay Set Algorithm Type Values Macker, editor & SMF Design Team Expires September 15, 2011 [Page 33] Internet-Draft SMF March 2011 12. Acknowledgments Many of the concepts and mechanisms used and adopted by SMF resulted from many years of discussion and related work within the MANET working group since the late 1990s. There are obviously many contributors to past discussions and related draft documents within the working group that have influenced the development of SMF concepts that deserve acknowledgment. In particular, the document is largely a direct product of the earlier SMF design team within the IETF MANET working group and borrows text and implementation ideas from the related individuals and activities. Some of the direct contributors who have been involved in design, content editing, prototype implementation, major commenting, and core discussions are listed below in alphabetical order. We appreciate all the input and feedback from the many community members and early implementation users we have heard from that are not on this list as well. Key contributors/authors in alphabetical order: Brian Adamson Teco Boot Ian Chakeres Thomas Clausen Justin Dean Brian Haberman Ulrich Herberg Charles Perkins Pedro Ruiz Fred Templin Maoyu Wang The RFC text was produced using Marshall Rose's xml2rfc tool and Bill Fenner's XMLmind add-ons. 13. References 13.1. Normative References [E-CDS] Ogier, R., "MANET Extension of OSPF Using CDS Flooding", Proceedings of the 62nd IETF , March 2005. [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing Connected Dominating Sets with Multipoint Relays", Ad Hoc and Sensor Wireless Networks , January 2005. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 34] Internet-Draft SMF March 2011 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. [RFC2780] Bradner, S., "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", March 2000. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol", 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4302] Kent, S., "IP Authentication Header", December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5444] Clausen, T. and et al, "Generalized MANET Packet/Message Format", RFC 5444, February 2009. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignment", RFC 5771, March 2010. [RFC6130] Clausen, T. and et al, "MANET Neighborhood Discovery Protocol", RFC 6130, March 2011. 13.2. Informative References [CDHM07] Chakeres, I., Danilov, C., and T. Henderson, "Connecting MANET Multicast", IEEE MILCOM 2007 Proceedings , 2007. [DHG09] Danilov, C., Henderson, T., and T. Goff, "Experiment and field demonstration of a 802.11-based ground-UAV mobile ad-hoc network", Proceedings of the 28th IEEE conference on Military Communications , 2009. [DHS08] Danilov, C., Henderson, T., and T. Spagnolo, "MANET Multicast with Multiple Gateways", IEEE MILCOM 2008 Macker, editor & SMF Design Team Expires September 15, 2011 [Page 35] Internet-Draft SMF March 2011 Proceedings , 2008. [GM99] Garcia-Luna-Aceves, JJ. and E. Madruga, "The core-assisted mesh protocol", Selected Areas in Communications, IEEE Journal on Volume 17, Issue 8, August 1999. [JLMV02] Jacquet, P., Laouiti, V., Minet, P., and L. Viennot, "Performance of multipoint relaying in ad hoc mobile routing protocols", Networking , 2002. [MDC04] Macker, J., Dean, J., and W. Chao, "Simplified Multicast Forwarding in Mobile Ad hoc Networks", IEEE MILCOM 2004 Proceedings , 2004. [MDDA07] Macker, J., Downard, I., Dean, J., and R. Adamson, "Evaluation of distributed cover set algorithms in mobile ad hoc network for simplified multicast forwarding", ACM SIGMOBILE Mobile Computing and Communications Review Volume 11 , Issue 3, July 2007. [MGL04] Mohapatra, P., Gui, C., and J. Li, "Group Communications in Mobile Ad hoc Networks", IEEE Computer Vol. 37, No. 2, February 2004. [NTSC99] Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Storm Problem in Mobile Ad hoc Networks", Proceedings Of ACM Mobicom 99 , 1999. [RFC2501] Macker, JP. and MS. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", 1999. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding", 2003. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS] forms a single CDS mesh for the SMF operating region. It allows Macker, editor & SMF Design Team Expires September 15, 2011 [Page 36] Internet-Draft SMF March 2011 nodes to use 2-hop neighborhood topology information to dynamically perform relay self election to form a CDS. Its packet forwarding rules are not dependent upon previous hop knowledge. Additionally, E-CDS SMF forwarders can be easily mixed without problems with CF SMF forwarders, even those not participating in NHDP. Another benefit is that packets opportunistically received from non-symmetric neighbors may be forwarded without compromising flooding efficiency or correctness. Furthermore, multicast sources not participating in NHDP may freely inject their traffic and any neighboring E-CDS relays will properly forward the traffic. The E-CDS based relay set selection algorithm is based upon the summary within [E-CDS]. E-CDS was originally discussed in the context of forming partial adjacencies and efficient flooding for MANET OSPF extensions work and the core algorithm is applied here for SMF. It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV be included in NHDP_HELLO messages that are generated by nodes conducting E-CDS SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS address block TLV be used to advertise neighbor nodes that are also conducting E-CDS SMF operation. A.1. E-CDS Relay Set Selection Overview The E-CDS relay set selection requires 2-hop neighborhood information collected through NHDP or another process. Relay nodes, in E-CDS SMF selection, are "self-elected" using a router identifier (Router ID) and an optional nodal metric, referred to here as "Router Priority" for all 1-hop and 2-hop neighbors. To ensure proper relay set self- election, the Router ID and Router Priority MUST be consistent among participating nodes. ********************************************************************** *JY* see the comments in P.39 ********************************************************************** It is RECOMMENDED that NHDP be used to share Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs as described in this appendix.. ********************************************************************** *JY* two trailing periods here ********************************************************************** The Router ID is a logical identification that MUST be consistent across interoperating SMF neighborhoods and it is RECOMMENDED to be chosen as the numerically largest address contained in a nodes "Neighbor Address List" as ********************************************************************** *JY* node's *JY* Also, should we not talk about routers, rather than nodes? We do not *JY* know what a node is, we know what a host or a router is; SMF specifies *JY* router behavior. Suggest consistent on this point [other MANET RFCs use *JY* router ....] ********************************************************************** defined in NHDP. The E-CDS self-election process can be summarized as follows: 1. If an SMF node has a higher ordinal (Router Priority, Router ID) than all of its symmetric neighbors, it elects itself to act as a forwarder for all received multicast packets, 2. Else, if there does not exist a path from the neighbor with largest (Router Priority, Router ID) to any other neighbor, _via_ ********************************************************************** *JY* what's "_via_"? Underscore necessary? ********************************************************************** neighbors with larger values of (Router Priority, Router ID), then it elects itself to the relay set. The basic form of E-CDS described and applied within this specification does not provide for redundant relay set election Macker, editor & SMF Design Team Expires September 15, 2011 [Page 37] Internet-Draft SMF March 2011 (e.g., bi-connected) but such capability is supported by the basic E-CDS design. A.2. E-CDS Forwarding Rules With E-CDS, any SMF node that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous hop knowledge is not needed for forwarding decisions when using E-CDS. 1. Upon packet reception, DPD is performed. Note E-CDS requires a single duplicate table for the set of interfaces associated with the relay set selection. 2. If the packet is a duplicate, no further action is taken. 3. If the packet is non-duplicative: A. A DPD entry is made for the packet identifier B. The packet is forwarded out all interfaces associated with the relay set selection As previously mentioned, even packets sourced (or relayed) by nodes not participating in NHDP and/or the E-CDS relay set selection may be forwarded by E-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from previous hop nodes that have been not explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g. S-MPR) to allow coexistent deployments to operate correctly. Also, E-CDS relay set selection may be configured to be influenced by statically- configured CF relays that are identified via NHDP or other means. A.3. E-CDS Neighborhood Discovery Requirements It is possible to perform E-CDS relay set selection without modification of NHDP, basing the self-election process exclusively on the "Neighbor Address List" of participating SMF nodes. For example by setting the "Router Priority" to a default value and selecting the "Router ID" as the numerically largest address contained in the "Neighbor Address List". However steps MUST be taken to insure that all NHDP enabled nodes not using SMF_TYPE:E-CDS full type message TLVs are in fact running SMF E-CDS with the same methods for selecting "Router Priority" and "Router ID", otherwise incorrect forwarding may occur. Note that SMF nodes with higher "Router Priority" values will be favored as relays over nodes with lower "Router Priority". Thus, preferred relays MAY be administratively configured to be selected when possible. Additionally, other metrics (e.g. nodal degree, energy capacity, etc) may also be taken into account in constructing a "Router Priority" value. When using "Router Priority" with multiple interfaces all interfaces on a node MUST use and advertise a common "Router Priority" value. A nodes Macker, editor & SMF Design Team Expires September 15, 2011 [Page 38] Internet-Draft SMF March 2011 "Router Priority" value may be administratively or algorithmically selected. The method of selection does not need to be the same among different nodes. ********************************************************************** *JY* corresponding to P.37 *JY* the p.37 said "the Router ID and Router Priority MUST be consistent among participating nodes. " *JY* *JY* how this kind of consistent can be guaranteed if different methods are used? ********************************************************************** E-CDS relay set selection may be configured to be influenced by statically configured CF relays that are identified via NHDP or other means. Nodes advertising CF through NHDP may be considered E-CDS SMF nodes with maximal "Router Priority". To share a node's "Router Priority" with its 1-hop neighbors the SMF_TYPE:E-CDS message TLV's field is defined as shown in Table 11. +---------------+---------+-----------------+ | Length(bytes) | Value | Router Priority | +---------------+---------+-----------------+ | 0 | N/A | 64 | | 1 | | 0-127 | +---------------+---------+-----------------+ Table 11: E-CDS Message TLV Values Where is a one octet long bit field which is defined as: bit 0: the leftmost bit is reserved and SHOULD be set to 0. bit 1-7: contain the unsigned "Router Priority" value, 0-127, which is associated with the "Neighbor Address List". Combinations of value field lengths and values other than specified here are NOT permitted and SHOULD be ignored. Below ********************************************************************** *JY* mention "Figure 5" ********************************************************************** is an example SMF_TYPE:E-CDS message TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | SMF_TYPE |1|0|0|1|0|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-CDS |0|0|0|0|0|0|0|1|R| priority | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: E-CDS Message TLV Example To convey "Router Priority" values among 2-hop neighborhoods the SMF_NBR_TYPE:E-CDS address block TLV's field is used. Multi- index and multi-value TLV layouts as defined in [RFC5444] are supported. SMF_NBR_TYPE:E-CDS value fields are defined thus: Macker, editor & SMF Design Team Expires September 15, 2011 [Page 39] Internet-Draft SMF March 2011 +---------------+--------+----------+-------------------------------+ | Length(bytes) | # Addr | Value | Router Priority | +---------------+--------+----------+-------------------------------+ | 0 | Any | N/A | 64 | | 1 | Any | | is for all addresses | | N | N | * | Each address gets its own | | | | | | +---------------+--------+----------+-------------------------------+ Table 12: E-CDS Address Block TLV Values Where is a one byte bit field which is defined as: bit 0: the leftmost bit is reserved and SHOULD be set to 0. bit 1-7: contain the unsigned "Router Priority" value, 0-127, which is associated with the appropriate address(es). Combinations of value field lengths and # of addresses other than specified here are NOT permitted and SHOULD be ignored. A default technique of using nodal degree (i.e. count of 1-hop neighbors) is RECOMMENDED for the value field of these TLV types. Below are two example SMF_NBR_TYPE:E-CDS address block TLVs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | SMF_NBR_TYPE |1|0|0|1|0|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-CDS |0|0|0|0|0|0|0|1|R| priority | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: E-CDS Address Block TLV Example 1 The single value example TLV, depicted in Figure 6 , specifies that all address(es) contained in the address block are running SMF using the E-CDS algorithm and all address(es) share the value field and therefore the same "Router Priority". Macker, editor & SMF Design Team Expires September 15, 2011 [Page 40] Internet-Draft SMF March 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | SMF_NBR_TYPE |1|0|1|1|0|1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E-CDS | index-start | index-end | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| priority0 |R| priority1 | ... |R| priorityN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: E-CDS Address Block TLV Example 2 The example multivalued TLV, depicted in Figure 7, specifies that address(es) contained in the address block from index-start to index- end inclusive are running SMF using the E-CDS algorithm. Each address is associated with its own value byte and therefore its own "Router Priority". A.4. E-CDS Selection Algorithm This section describes an algorithm for E-CDS relay selection (self- election). The algorithm described uses 2-hop information. Note it is possible to extend this algorithm to use k-hop information with added computational complexity and mechanisms for sharing k-hop topology information that are not described in this document or within the NHDP specification. It should also be noted that this algorithm does not impose the "hop limit" bound described in [E-CDS] when performing the path search that is used for relay selection. However, the algorithm below could be easily augmented to accommodate this additional criterion. It is not expected that the "hop limit" bound will provide significant benefit to the algorithm defined in this appendix. The tuple of "Router Priority" and "Router ID" is used in E-CDS relay set selection. Precedence is given to the "Router Priority" portion and the "Router ID" value is used as a tie-breaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific node. Note it is possible that the "Router Priority" portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique "Router ID". Since there MUST NOT be any duplicate "Router ID" values among SMF nodes, a comparison of RtrPri(n) between any two nodes will always be an inequality. The use of nodal degree for calculating "Router Priority" is RECOMMENDED as default and the largest IP address in the "Neighbor Address List" as advertised by NHDP MUST be used as the "Router ID". NHDP provides all interface address throughout the 2-hop neighborhood through HELLO messages, so explicitly conveying a "Router ID" is not necessary. The following steps describe a basic Macker, editor & SMF Design Team Expires September 15, 2011 [Page 41] Internet-Draft SMF March 2011 algorithm for conducting E-CDS relay selection for a node "n0": 1. Initialize the set "N1" with tuples ("Router Priority", "Router ID", "Neighbor Address List" for each 1-hop neighbor of "n0". ********************************************************************** *JY* right parenthesis missed ********************************************************************** 2. If "N1" has less than 2 tuples, then "n0" does not elect itself as a relay and no further steps are taken. 3. Initialize the set "N2" with tuples ("Router Priority", "Router ID", "2-hop address") for each "2-hop address" of "n0", where "2-hop address" is defined in NHDP. 4. If "RtrPri(n0)" is greater than that of all tuples in the union of "N1" and "N2", then "n0" selects itself as a relay and no further steps are taken. 5. Initialize all tuples in the union of "N1" and "N2" as "unvisited". 6. Find the tuple "n1_Max" that has the largest "RtrPri()" of all tuples in "N1" 7. Initialize queue "Q" to contain "n1_Max", marking "n1_Max" as "visited" 8. While node queue "Q" is not empty, remove node "x" from the head of "Q", and for each 1-hop neighbor "n" of node "x" (excluding "n0") that is not marked "visited" A. Mark node "n" as "visited" B. If "RtrPri(n)" is greater than "RtrPri(n0), append "n" to "Q" 9. If any tuple in "N1" remains "unvisited", then "n0" selects itself as a relay. Otherwise "n0" does not act as a relay. Note these steps are re-evaluated upon neighborhood status changes. Steps 5 through 8 of this procedure describe an approach to a path search. The purpose of this path search is to determine if paths exist from the 1-hop neighbor with maximum "RtrPri()" to all other 1-hop neighbors without traversing an intermediate node with a "RtrPri()" value less than "RtrPri(n0)". These steps comprise a breadth-first traversal that evaluates only paths that meet that criteria. If all 1-hop neighbors of "n0" are "visited" during this traversal, then the path search has succeeded and node "n0" does not need to provide relay. It can be assumed that other nodes will provide relay operation to ensure SMF connectivity. It is possible to extend this algorithm to consider neighboring SMF nodes that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such nodes as having a maximum possible "Router Priority" value. It is expected that nodes configured for CF and participating in NHDP would indicate this with use of the SMF_TYPE:CF and SMF_NBR_TYPE:CF TLV types in their NHDP_HELLO message and address blocks, respectively. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 42] Internet-Draft SMF March 2011 Appendix B. Source-based Multipoint Relay (S-MPR) The source-based multipoint relay (S-MPR) set selection algorithm enables individual nodes, using two-hop topology information, to select relays from their set of neighboring nodes. Relays are selected so that forwarding to the node's complete two-hop neighbor set is covered. This distributed relay set selection technique has been shown to approximate a minimal connected dominating set (MCDS) in [JLMV02]. Individual nodes must collect two-hop neighborhood information from neighbors, determine an appropriate current relay set, and inform selected neighbors of their relay status. Note that since each node picks its neighboring relays independently, S-MPR forwarders depend upon previous hop information (e.g, source MAC address) to operate correctly. The Optimized Link State Routing (OLSR) protocol has used this algorithm and protocol for relay of link state updates and other control information [RFC3626] and it has been demonstrated operationally in dynamic network environments. It is RECOMMENDED that the SMF_TYPE:S-MPR message TLV be included in NHDP_HELLO messages that are generated by nodes conducting S-MPR SMF operation. It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR address block TLV be used to specify which neighbor nodes are conducting S-MPR SMF operation. B.1. S-MPR Relay Set Selection Overview The S-MPR algorithm uses bi-directional 1-hop and 2-hop neighborhood information collected via NHDP to select, from a node's 1-hop neighbors, a set of relays that will cover the node's entire 2-hop neighbor set upon forwarding. The algorithm described uses a "greedy" heuristic of first picking the 1-hop neighbor who will cover the most 2-hop neighbors. Then, excluding those 2-hop neighbors that have been covered, additional relays from its 1-hop neighbor set are iteratively selected until the entire 2-hop neighborhood is covered. Note that 1-hop neighbors also identified as 2-hop neighbors are considered as 1-hop neighbors only. NHDP HELLO messages supporting S-MPR forwarding operation SHOULD use the TLVs defined in Section 8.1 using the S-MPR extended type. The value field of an address block TLV which has a full type value of SMF_NBR_TYPE:S-MPR is defined in Table 14 such that signaling of MPR selections to 1-hop neighbors is possible. The value field of a message block TLV which has a full type value of SMF_TYPE:S-MPR is defined in Table 13 such that signaling of "Router Priority" (described as "WILLINGNESS" in [RFC3626]) to 1-hop neighbors is possible. It is important to note that S-MPR forwarding is dependent upon the previous hop of an incoming packet. An S-MPR node MUST forward packets only for neighbors which have explicitly selected it Macker, editor & SMF Design Team Expires September 15, 2011 [Page 43] Internet-Draft SMF March 2011 as a multi-point relay (i.e., its "selectors"). There are also some additional requirements for duplicate packet detection to support S-MPR SMF operation that are described below. For multiple interface operation, MPR selection SHOULD be conducted on a per-interface basis. However, it is possible to economize MPR selection among multiple interfaces by selecting common MPRs to the extent possible. B.2. S-MPR Forwarding Rules An S-MPR SMF node MUST only forward packets for neighbors that have explicitly selected it as an MPR. The source-based forwarding technique also stipulates some additional duplicate packet detection operations. For multiple network interfaces, independent DPD state MUST be maintained for each separate interface. The following table ********************************************************************** *JY* Is it following "items", rather than "the following table" (which would be "table 13")? ********************************************************************** provides the procedure for S-MPR packet forwarding given the arrival of a packet on a given interface, denoted . There are three possible actions, depending upon the previous-hop transmitter: 1. If the previous-hop transmitter has selected the current node as an MPR, A. The packet identifier is checked against the DPD state for each possible outbound interface, including the . B. If the packet is not a duplicate for an outbound interface, the packet is forwarded on that interface and a DPD entry is made for the given packet identifier for the interface. C. If the packet is a duplicate, no action is taken for that interface. 2. Else, if the previous-hop transmitter is a 1-hop symmetric neighbor, A. A DPD entry is added for that packet for the , but the packet is not forwarded. 3. Otherwise, no action is taken. Case number two in the above table is non-intuitive, but important to ensure correctness of S-MPR SMF operation. The selection of source- based relays does not result in a common set among neighboring nodes, so relays MUST mark in their DPD state, packets received from non- selector, symmetric, one-hop neighbors (for a given interface) and not forward subsequent duplicates of that packet if received on that interface. Deviation here can result in unnecessary, repeated packet forwarding throughout the network, or incomplete flooding. Nodes not participating in neighborhood discovery and relay set selection will not be able to source multicast packets into the area and have SMF forward them, unlike E-CDS or MPR-CDS where forwarding may occur dependent on topology. Correct S-MPR relay behavior will Macker, editor & SMF Design Team Expires September 15, 2011 [Page 44] Internet-Draft SMF March 2011 occur with the introduction of repeaters (non-NHDP/SMF participants that relay multicast packets using duplicate detection and CF) but the repeaters will not efficiently contribute to S-MPR forwarding as these nodes will not be identified as neighbors (symmetric or otherwise) in the S-MPR forwarding process. NHDP/SMF participants MUST NOT provide extra forwarding, forwarding packets which are not selected by the algorithm, as this can disrupt network-wide S-MPR flooding, resulting in incomplete or inefficient flooding. The result is that non S-MPR SMF nodes will be unable to source multicast packets and have them forwarded by other S-MPR SMF nodes. B.3. S-MPR Neighborhood Discovery Requirements Nodes may optionally signal a "Router Priority" value to their one hop neighbors by using the SMF_TYPE:S-MPR message block TLV value field. If the value field is omitted, a default "Router Priority" value of 64 is to be assumed. This is summarized here: +---------------+---------+-----------------+ | Length(bytes) | Value | Router Priority | +---------------+---------+-----------------+ | 0 | N/A | 64 | | 1 | | 0-127 | +---------------+---------+-----------------+ Table 13: S-MPR Message TLV Values Where is a one octet long bit field defined as: bit 0: the leftmost bit is reserved and SHOULD be set to 0. bit 1-7: contain the "Router Priority" value, 0-127, which is associated with the "Neighbor Address List". "Router Priority" values for S-MPR are interpreted in the same fashion as "WILLINGNESS" ([RFC3626])with value 0 indicating a node will NEVER forward and value 127 indicating a node will ALWAYS forward. Values 1-126 indicate how likely a S-MPR SMF router will be selected as an MPR by a neighboring SMF node, with higher values increasing the likelihood. Combinations of value field lengths and values other than specified here are NOT permitted and SHOULD be ignored. Below is an example SMF_TYPE:S-MPR message TLV. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 45] Internet-Draft SMF March 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | SMF_TYPE |1|0|0|1|0|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-MPR |0|0|0|0|0|0|0|1|R| priority | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: S-MPR Message TLV Example S-MPR election operation requires 2-hop neighbor knowledge as provided by the NHDP protocol [RFC6130] or from external sources. MPRs are dynamically selected by each node and selections MUST be advertised and dynamically updated within NHDP or an equivalent protocol or mechanism. For NHDP use, the SMF_NBR_TYPE:S-MPR address block TLV value field is defined as such: +---------------+--------+----------+-------------------------------+ | Length(bytes) | # Addr | Value | Meaning | +---------------+--------+----------+-------------------------------+ | 0 | Any | N/A | NOT MPRs | | 1 | Any | | is for all addresses | | N | N | * | Each address gets its own | | | | | | +---------------+--------+----------+-------------------------------+ Table 14: S-MPR Address Block TLV Values Where , if present, is a one octet bit field defined as: bit 0: The leftmost bit is the M bit. When set indicates MPR selection of the relevant interface, represented by the associated address(es), by the originator node of the NHDP HELLO message. When unset, indicates the originator node of the NHDP HELLO message has not selected the relevant interfaces, represented by the associated address(es), as its MPR. bit 1-7: are reserved and SHOULD be set to 0. Combinations of value field lengths and number of addresses other than specified here are NOT permitted and SHOULD be ignored. All bits, excepting the leftmost bit, are RESERVED and SHOULD be set to 0. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 46] Internet-Draft SMF March 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | SMF_NBR_TYPE |1|1|0|1|0|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S-MPR | start-index |0|0|0|0|0|0|0|1|M| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: S-MPR Address Block TLV Example The single index TLV example, depicted in Figure 9, indicates that the address specified by the field is running SMF using S-MPR and has been selected by the originator of the NHDP HELLO message as an MPR forwarder if the M bit is set. Multivalued TLVs may also be used to specify MPR selection status of multiple addresses using only one TLV. See Figure 7 for a similar example on how this may be done. B.4. S-MPR Selection Algorithm This section describes a basic algorithm for the S-MPR selection process. Note that the selection is with respect to a specific interface of the node performing selection and other node interfaces referenced are reachable from this reference node interface. This is consistent with the S-MPR forwarding rules described above. When multiple interfaces per node are used, it is possible to enhance the overall selection process across multiple interfaces such that common nodes are selected as MPRs for each interface to avoid unnecessary inefficiencies in flooding. The following steps describe a basic algorithm for conducting S-MPR selection for a node interface "n0": 1. Initialize the set "MPR" to empty. 2. Initialize the set "N1" to include all 1-hop neighbors of "n0". 3. Initialize the set "N2" to include all 2-hop neighbors, excluding "n0" and any nodes in "N1". Nodes which are only reachable via "N1" nodes with router priority values of NEVER are also excluded. 4. For each interface "y" in "N1", initialize a set "N2(y)" to include any interfaces in "N2" that are 1-hop neighbors of "y". 5. For each interface "x" in "N1" with a router priority value of "ALWAYS" (or using CF relay algorithm), select "x" as a MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2" C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)" 6. For each interface "z" in "N2", initialize the set "N1(z)" to include any interfaces in "N1" that are 1-hop neighbors of "z". Macker, editor & SMF Design Team Expires September 15, 2011 [Page 47] Internet-Draft SMF March 2011 7. For each interface "x" in "N2" where "N1(x)" has only one member, select "x" as a MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2" and delete "N1(z)" C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)" 8. While "N2" is not empty, select the interface "x" in "N1" with the largest router priority which has the number of members in "N_2(x)" as a MPR: A. Add "x" to the set "MPR" and remove "x" from "N1". B. For each interface "z" in "N2(x)", remove "z" from "N2" C. For each interface "y" in "N1", remove any interfaces in "N2(x)" from "N2(y)" After the set of nodes "MPR" is selected, node "n_0" must signal its selections to its neighbors. With NHDP, this is done by using the MPR address block TLV to mark selected neighbor addresses in NHDP_HELLO messages. Neighbors MUST record their MPR selection status and the previous hop address (e.g., link or MAC layer) of the selector. Note these steps are re-evaluated upon neighborhood status changes. Appendix C. Multipoint Relay Connected Dominating Set (MPR-CDS) Algorithm The MPR-CDS algorithm is an extension to the basic S-MPR election algorithm that results in a shared (non source-specific) SMF CDS. Thus its forwarding rules are not dependent upon previous hop information similar to E-CDS. An overview of the MPR-CDS selection algorithm is provided in [MPR-CDS]. It is RECOMMENDED that the SMF_TYPE Message TLV be included in NHDP_HELLO messages that are generated by nodes conducting MPR-CDS SMF operation. C.1. MPR-CDS Relay Set Selection Overview The MPR-CDS relay set selection process is based upon the MPR selection process of the S-MPR algorithm with the added refinement of a distributed technique for subsequently down-selecting to a common reduced, shared relay set. A node ordering (or "prioritization") metric is used as part of this down-selection process like the E-CDS algorithm, this metric can be based upon node address(es) or some other unique router identifier (e.g. "Router ID" based on largest address contained within the "Neighbor Address List") as well as an additional "Router Priority" measure, if desired. The process for Macker, editor & SMF Design Team Expires September 15, 2011 [Page 48] Internet-Draft SMF March 2011 MPR-CDS relay selection is as follows: 1. First, MPR selection per the S-MPR algorithm is conducted, with selectors informing their MPRs (via NHDP) of their selection. 2. Then, the following rules are used on a distributed basis by selected nodes to possibly deselect themselves and thus jointly establish a common set of shared SMF relays: A. If a selected node has a larger "RtrPri()" than all of its 1-hop symmetric neighbors, then it acts as a relay for all multicast traffic, regardless of the previous hop B. Else, if the 1-hop symmetric neighbor with the largest "RtrPri()" value has selected the node, then it also acts as a relay for all multicast traffic, regardless of the previous hop. C. Otherwise, it deselects itself as a relay and does not forward any traffic unless changes occur that require re- evaluation of the above steps. This technique shares many of the desirable properties of the E-CDS technique with regards to compatibility with multicast sources not participating in NHDP and the opportunity for statically-configure CF nodes to be present, regardless of their participation in NHDP. C.2. MPR-CDS Forwarding Rules The forwarding rules for MPR-CDS are common with those of E-CDS. Any SMF node that has selected itself as a relay performs DPD and forwards all non-duplicative multicast traffic allowed by the present forwarding policy. Packet previous hop knowledge is not needed for forwarding decisions when using MPR-CDS. 1. Upon packet reception, DPD is performed. Note MPR-CDS require one duplicate table for the set of interfaces associated with the relay set selection. 2. If the packet is a duplicate, no further action is taken. 3. If the packet is non-duplicative: A. A DPD entry is added for the packet identifier B. The packet is forwarded out all interfaces associated with the relay set selection As previously mentioned, even packets sourced (or relayed) by nodes not participating in NHDP and/or the MPR-CDS relay set selection may be forwarded by MPR-CDS forwarders without problem. A particular deployment MAY choose to not forward packets from sources or relays that have been explicitly identified via NHDP or other means as operating as part of a different relay set algorithm (e.g. S-MPR) to allow coexistent deployments to operate correctly. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 49] Internet-Draft SMF March 2011 C.3. MPR-CDS Neighborhood Discovery Requirements The neighborhood discovery requirements for MPR-CDS have commonality with both the S-MPR and E-CDS algorithms. MPR-CDS selection operation requires 2-hop neighbor knowledge as provided by the NHDP protocol [RFC6130] or from external sources. Unlike S-MPR operation, there is no need for associating link-layer address information with 1-hop neighbors since MPR-CDS forwarding is independent of the previous hop similar to E-CDS forwarding. To advertise an optional "Router Priority" value or "WILLINGNESS" an originating node may use the message TLV of type SMF_TYPE:MPR-CDS which shares a common format with both SMF_TYPE:E-CDS Table 11 and SMF_TYPE:S-MPR Table 13. MPR-CDS only requires 1-hop knowledge of "Router Priority" for correct operation. In the S-MPR phase of MPR-CDS selection, MPRs are dynamically determined by each node and selections MUST be advertised and dynamically updated using NHDP or an equivalent protocol or mechanism. Therefore the field of the SMF_NBR_TYPE:MPR-CDS type TLV shares a common format with SMF_NBR_TYPE:S-MPR Table 14 to convey MPR selection. C.4. MPR-CDS Selection Algorithm This section describes an algorithm for the MPR-CDS selection process. Note that the selection described is with respect to a specific interface of the node performing selection and other node interfaces referenced are reachable from this reference node interface. An ordered tuple of "Router Priority" and "Router ID" is used in MPR-CDS relay set selection. The "Router ID" value should be set to the largest advertised address of a given node, this information is provided to one hop neighbors via NHDP by default. Precedence is given to the "Router Priority" portion and the "Router ID" value is used as a tie-breaker. The evaluation of this tuple is referred to as "RtrPri(n)" in the description below where "n" references a specific node. Note it is possible that the "Router Priority" portion may be optional and the evaluation of "RtrPri()" be solely based upon the unique "Router ID". Since there MUST NOT be any duplicate address values among SMF nodes, a comparison of RtrPri(n) between any two nodes will always be an inequality. The following steps, repeated upon any changes detected within the 1-hop and 2-hop neighborhood, describe a basic algorithm for conducting MPR-CDS selection for a node interface "n0": 1. Perform steps 1-8 of Appendix B.4 to select MPRs from the set of 1-hop neighbors of "n0" and notify/update neighbors of selections. Macker, editor & SMF Design Team Expires September 15, 2011 [Page 50] Internet-Draft SMF March 2011 2. Upon being selected as an MPR (or any change in the set of nodes selecting "n0" as an MPR): A. If no neighbors have selected "n0" as an MPR, "n0" does not act as a relay and no further steps are taken until a change in neighborhood topology or selection status occurs. B. Determine the node "n1_max" that has the maximum "RtrPri()" of all 1-hop neighbors. C. If "RtrPri(n0)" is greater than "RtrPri(n1_max)", then "n0" selects itself as a relay for all multicast packets, D. Else, if "n1_max" has selected "n0" as an MPR, then "0" selects itself as a relay for all multicast packets. E. Otherwise, "n0" does not act as a relay. It is possible to extend this algorithm to consider neighboring SMF nodes that are known to be statically configured for CF (always relaying). The modification to the above algorithm is to process such nodes as having a maximum possible "Router Priority" value. This is the same as the case for participating nodes that have been configured with a S-MPR "WILLINGNESS" value of "WILL_ALWAYS". It is expected that nodes configured for CF and participating in NHDP would indicate their status with use of the SMF_TYPE TLV type in their NHDP_HELLO message TLV block. It is important to note however that CF nodes will not select MPR nodes and therefore cannot guarantee connectedness. Authors' Addresses Joseph Macker NRL Washington, DC 20375 USA Email: macker@itd.nrl.navy.mil SMF Design Team IETF MANET WG Email: manet@ietf.org Macker, editor & SMF Design Team Expires September 15, 2011 [Page 51] --------------010907050900060404080105-- From Chris.Dearlove@baesystems.com Thu Apr 21 08:17:43 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 67CA2E0705 for ; Thu, 21 Apr 2011 08:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5YOMx98n4OT for ; Thu, 21 Apr 2011 08:17:42 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfc.amsl.com (Postfix) with ESMTP id 669A2E0689 for ; Thu, 21 Apr 2011 08:17:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,252,1301871600"; d="scan'208";a="129735595" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 21 Apr 2011 16:17:41 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3LFHd1K024982; Thu, 21 Apr 2011 16:17:40 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 16:17:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Apr 2011 16:17:38 +0100 Message-ID: In-reply-to: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] WG adoption of NHDP-sec Thread-Index: Acv1PznkbGoKTKjIT5y8aUGQWZrkkgK9Vzyw References: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> From: "Dearlove, Christopher (UK)" To: "Joe Macker" , "MANET IETF" X-OriginalArrivalTime: 21 Apr 2011 15:17:39.0937 (UTC) FILETIME=[40ECE510:01CC0037] Cc: Ulrich Herberg , Thomas Heide Clausen Subject: Re: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 21 Apr 2011 15:17:43 -0000 Brief version: I think there's a two part change that should be included before finishing WGLC. My apologies in advance in that should this spark a discussion, I'll be out of the loop for a week and a half and no able to contribute. (The UK is largely shutting down, we have for a combination of rare reasons, two four day weekends, with a three day gap. Many of us are taking those three days off too.) My main concern over this document is that it specifies a signature as the composition of a hash function and a cryptographic function, in that order. There are other ways of constructing signatures that do not correspond to such a decomposition. The obvious response to that is to pick a new type extension for such. This can't be normative text in this document, but I think it should be described in the applicability statement, which should say that this specification describes a general approach to signatures (much of the document, such as how to traety hop counts/limits is not specific to this decomposition) and then a specific approach to signatures, and should provide the comment that other mathematical forms of signature are possible, and should be handled by use of alternative type extensions. In the main body of the specification, a bit more clarity on what is form-specific and what is not would then help. This then leads to the question a to whether the form described should be the privileged type extension = 0 case. Actually I would suggest it should be type extension = 1, with 0 reserved for "I'm not providing any information on algorithms, this is defined out of band, not in each packet. The reason I suggest that as type 0 (and including it in this document) is that it puts the two lowest-overhead options together (type extension 0, which can be omitted, and no algorithm information). Note that for timestamp, what other type extensions may be is alraedy covered, but not so for signatures, and timestamp uses the type extension 0 for the analogous case I suggest for type extension 0 for signature, i.e. detertmined otherwise (should the phrase "administrative action" be used in both cases?) I think there should be another iteration before going to SECDIR and IESG, as I think it will avoid work further down the line, as well as being a better specification this way. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Joe Macker Sent: 07 April 2011 17:17 To: MANET IETF Subject: [manet] WG adoption of NHDP-sec *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. As discussed in Prague we are presently considering adoption of NHDP security related document as a WG document. reference is draft-herberg-manet-nhdp-sec-01 Please comment if you have an opinion. -Joe _______________________________________________ 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 yi.jiazi@gmail.com Fri Apr 22 01:55:48 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB66EE0756 for ; Fri, 22 Apr 2011 01:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHLW7IH1jWnj for ; Fri, 22 Apr 2011 01:55:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id BD4B3E0688 for ; Fri, 22 Apr 2011 01:55:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so322083wwa.13 for ; Fri, 22 Apr 2011 01:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=iU/ZkqTnk2oLBmmVW7fP489AKxUfKnwGud2OYVoA3BM=; b=OM+zg+hT8CzmWIpo8RQTrP0nx8b+hEIcwbsn18/0bb1OTxw/XfkAmUCVwcZb3wu5YR 9fZD0YV/l7mqtSWMznQKG/OmXuQe1ySv/BXiALix3dF9WJaLr0Vzyv0tsh4ZUGUNO8di N5ftCbGx7OFpYiYiXc8+GTs3zq3JLaNPQbTPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=myMF0l9fw3AVZ7MwDFNxcUCm03dADrfmiu9bKnhE3rngF/ukwN420es9HR9CnCrdL6 JuKvljeMT61NXZfT/s5QfPMDJ50EGBY79pjtf9Mct+CPN0l3h1YssYxINgdXtG03ymSh Fjq9zZvzAwrBpH4gYUeeOt0Y/b8aOEc/Fzloo= Received: by 10.227.131.208 with SMTP id y16mr936843wbs.43.1303462542892; Fri, 22 Apr 2011 01:55:42 -0700 (PDT) Received: from jz-mac-pro.local (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id w12sm1633407wby.7.2011.04.22.01.55.41 (version=SSLv3 cipher=OTHER); Fri, 22 Apr 2011 01:55:42 -0700 (PDT) Message-ID: <4DB1428C.5090208@gmail.com> Date: Fri, 22 Apr 2011 10:55:40 +0200 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [manet] Some general comments on SMF-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 22 Apr 2011 08:55:48 -0000 Hi, After reading through the SMF-11, I still have some general comments (or I would rather call them questions) on it. Because I'm relatively new to the SMF, I'm sorry if those are too "naive" :-P 1. In the specification of the protocol, the multicast address or the multicast groups are not mentioned. What SMF does is mainly forwards the packets to all the nodes in the SMF domain. So SMF can also be regarded as a "broadcast" protocol ? 2. For the Relay Set Selection section, if I was trying to implement SMF, I'll have difficulties in choosing the three methods in the appendixes. What's the difference in those solutions and which one is recommended in difference scenarios? Concerning the E-CDS, the choice is based on (Router priority, Router ID). However, there is no recommendation made for defining the "priority". How can we set the values for "priority"? If we only choose the node based on the ID, it seems that it's not convincing enough. best regards -- Jiazi YI www.jiaziyi.com Postdoctoral researcher Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France From jdean@itd.nrl.navy.mil Fri Apr 22 06:36:13 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DAB5DE0745 for ; Fri, 22 Apr 2011 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[AWL=2.384, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4lU1CDUW+Ul for ; Fri, 22 Apr 2011 06:36:12 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfc.amsl.com (Postfix) with ESMTP id 0C0D5E0736 for ; Fri, 22 Apr 2011 06:36:11 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p3MDa2Ng003980; Fri, 22 Apr 2011 09:36:08 -0400 Received: (from bebe [132.250.93.61]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011042209360818378 ; Fri, 22 Apr 2011 09:36:08 -0400 From: "Justin Dean" To: "'Jiazi YI'" , References: <4DB1428C.5090208@gmail.com> In-Reply-To: <4DB1428C.5090208@gmail.com> Date: Fri, 22 Apr 2011 09:31:05 -0400 Message-ID: <002601cc00f1$883c6700$98b53500$@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwAyy2UFilYtakZQhi7Du/tqmNcGAAIoc5A Content-Language: en-us Subject: Re: [manet] Some general comments on SMF-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 22 Apr 2011 13:36:14 -0000 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Jiazi YI > Sent: Friday, April 22, 2011 4:56 AM > To: manet@ietf.org > Subject: [manet] Some general comments on SMF-11 > > Hi, > > After reading through the SMF-11, I still have some general comments > (or > I would rather call them questions) on it. Because I'm relatively new > to the SMF, I'm sorry if those are too "naive" :-P > > 1. In the specification of the protocol, the multicast address or the > multicast groups are not mentioned. What SMF does is mainly forwards > the > packets to all the nodes in the SMF domain. > So SMF can also be regarded as a "broadcast" protocol ? Correct to an extent. Future extensions and modifications to the election algorithm could possibly provide group based forwarding. Currently it is for "broadcast"ing within the MANET. Simply setting a low TTL can provide localized scoping. > > 2. For the Relay Set Selection section, if I was trying to implement > SMF, I'll have difficulties in choosing the three methods in the > appendixes. What's the difference in those solutions and which one is > recommended in difference scenarios? We really did try to include information related to algorithm requirements, and some general attributes of the algorithms. There is no one size fits all algorithm and debating which is "best" leads to never ending rabbit hole. In danger of stepping into the rabbit hole. S-MPR: source based flooding with shortest hop paths. Generally the most efficient in terms of #routers forwarding vs others provided. Good with sharp cutoff radio/link characteristics. E-CDS: single shared CDS. Shortest hops paths NOT guaranteed. MPR-CDS: single shared CDS. Shortest hop paths guaranteed. Generally most #of forwarders vs other two. All that being said the algorithms provided are only a sample of what is actually possible. The efficiencies are relatively speaking "close" and the greatest gains are to be had in selecting/sensing quality neighbor information. This paper presents some tests related to the various algorithms. http://cs.itd.nrl.navy.mil/pubs/docs/acm2007-macker.pdf > Concerning the E-CDS, the choice is based on (Router priority, Router > ID). However, there is no recommendation made for defining the > "priority". How can we set the values for "priority"? If we only choose > the node based on the ID, it seems that it's not convincing enough. > "priority" can be anything from preconfigured (for example a mixture of heterogeneous routers with differing power constraints), to an aggregate value of power/neighbors/MAC utilization/queue size or any number of things relevant to the deployment. Power and #neighbors are simple dynamic ones to implement. > best regards > > -- > Jiazi YI > > www.jiaziyi.com > Postdoctoral researcher > Hipercom@LIX, Ecole Polytechnique > 91128 Palaiseau Cedex France > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Fri Apr 22 10:05:20 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8565CE07BF for ; Fri, 22 Apr 2011 10:05:19 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX7zrq5LzuXK for ; Fri, 22 Apr 2011 10:05:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2028DE078C for ; Fri, 22 Apr 2011 10:05:18 -0700 (PDT) Received: by vws12 with SMTP id 12so689650vws.31 for ; Fri, 22 Apr 2011 10:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=UNn+xFsACARLThYXHrbJlXkiD8cT8rzCDMs/+UU4Iw0=; b=xKXbHNm7M3tt3DD5w9yl7b0LNO0oqqf1yCvayzCApwZywVCbyhqVDSfkEC2eRvXFob SBl7jM0vPBurtliGBsw3DWjOT3ZxcKdRMBQeWZcR2k8Q43T9FwiGkk7mV2j7VfRxG5/u TElkBrC9cm0brcxJ28eJ9RPgCW3nKJvsmXjFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=b6AZJAfrUVKgokKlCPeTeKia9pzF94ATPrDNP8cdiNEVvh7AWI0Vj1Uc4TCzQooIz2 Z4RtcsWX5LjlLbGucfOamSBQNUbO5bJ1pzsIzpFJPQb5dDs1PTcdt7TSkF0NNcJfgtzJ Wprmz9Wv6FwX4aaFkTOw11UnhL3GxLD+8PhrE= Received: by 10.52.167.230 with SMTP id zr6mr2013817vdb.6.1303491917681; Fri, 22 Apr 2011 10:05:17 -0700 (PDT) Received: from [192.168.1.101] (c-68-50-116-80.hsd1.md.comcast.net [68.50.116.80]) by mx.google.com with ESMTPS id p29sm568900vcr.7.2011.04.22.10.05.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 10:05:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Macker In-Reply-To: <4DB1428C.5090208@gmail.com> Date: Fri, 22 Apr 2011 13:05:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB1428C.5090208@gmail.com> To: Jiazi YI X-Mailer: Apple Mail (2.1084) Cc: manet@ietf.org Subject: Re: [manet] Some general comments on SMF-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 22 Apr 2011 17:05:20 -0000 On Apr 22, 2011, at 4:55 AM, Jiazi YI wrote: > Hi, >=20 > After reading through the SMF-11, I still have some general comments = (or > I would rather call them questions) on it. Because I'm relatively new > to the SMF, I'm sorry if those are too "naive" :-P No problem. >=20 > 1. In the specification of the protocol, the multicast address or the > multicast groups are not mentioned. What SMF does is mainly forwards = the > packets to all the nodes in the SMF domain. > So SMF can also be regarded as a "broadcast" protocol ? This is partially true and most of that is explained right up front in = the applicability part of the document. SMF is also about forwarding site-scoped multicast and any additional = multicast global addresses determined by the FIB. There is some discussion the forwarding rules for various multicast = groups. Link local is disallowed, site (admin)-scoped addresses are discussed, = and the role of global multicast addresses if forwarding is allowed in = by the FIB is defined. See processing rules an sections on forwarding, = multicast group scoping sections. It is intended for limited use in deployments where this may make sense. There is past and present discussion on applying more detailed = group-based forwarding decision. The control for that would live in another protocol layer but could be = support by the SMF mesh forwarding approach. So one can layer group specifics on top of something like SMF as a more = sophisticated control plane. SMF is fundamentally about a simplified core specification addressing = duplicate detection and optional cover set-based forwarding in limited = multi-hop wireless edge networks (e.g., MANETs) =20 There is also past and present work on more specific group-based = multicast forwarding in highly dynamic environments. >=20 > 2. For the Relay Set Selection section, if I was trying to implement > SMF, I'll have difficulties in choosing the three methods in the > appendixes. What's the difference in those solutions and which one is > recommended in difference scenarios? > Concerning the E-CDS, the choice is based on (Router priority, Router > ID). However, there is no recommendation made for defining the > "priority". How can we set the values for "priority"? If we only = choose > the node based on the ID, it seems that it's not convincing enough. There has been work done here in practice. The priority tuple value can = be based upon density or on some other admin knowledge (most advantaged = relay link). For example, there is paper showing the comparison of ID-alone vs. 2-hop = density-based priority election for E-CDS in various topological cases. = So I agree with you above although the ID approach works for maintaining = a dynamic CDS it is not as optimized. Priority is basically there as a protocol hook to provide additional = control (possible management control or more optimized election). Best practices are not established and we are not trying to limit people = here, one reason the WG has consensus on EXPERIMENTAL not STD TRACK = submission status. Some additional info: In practice, SMF implementation are often deployed = alongside something like MANET OSPF extensions or OLSR and these unicast = protocols can provide related relay set election information. There are = working implementations. I discuss this but implementation details are = not provided. NHDP and SMF interaction is specified but at present = there is not working implementation. >=20 > best regards >=20 > --=20 > Jiazi YI >=20 > www.jiaziyi.com > Postdoctoral researcher > Hipercom@LIX, Ecole Polytechnique > 91128 Palaiseau Cedex France >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 From ulrich@herberg.name Sat Apr 23 03:34:48 2011 Return-Path: X-Original-To: manet@ietfc.amsl.com Delivered-To: manet@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77181E06A7 for ; Sat, 23 Apr 2011 03:34:48 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQXUUIdq8cKh for ; Sat, 23 Apr 2011 03:34:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 5AFC8E0661 for ; Sat, 23 Apr 2011 03:34:46 -0700 (PDT) Received: by wwa36 with SMTP id 36so814715wwa.13 for ; Sat, 23 Apr 2011 03:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=sRmFt9M7ZITYKC19MLjIHj3BgtNJrYmqt2b6B09SbqE=; b=pWNjmHxWmprRM08LKqAguhLT+MLcH3daFkAV8g5YmDqzxUolDcI4PbRO4OOuQJ8gzM cpVrSgX8OBHO/KSMFO7l0dX+OI6eRDL49CcL7Befb/63nXldfHpMNwDuEE4kBvzhWSDh 2TQCKfv9xRezWUsfj+L8hdP7jyNw11F+jlF48= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZF3LnmXrn1BNEPKFzEU6PIHwLrsoOYDd9G6XWiv/hYzk9YXbTKFncvnbpUu2vuLCga ewtbrEzU0EmkDZjiOs9rv6OF+ER01mQ0upsjNOwI3zqD4qXSw5k1nb9YXEcG3WlIT5Mm C+g9XLyEX/H7D+xHxcE6EgXJCi4Smy21mW/A8= Received: by 10.227.10.149 with SMTP id p21mr1942505wbp.195.1303554885783; Sat, 23 Apr 2011 03:34:45 -0700 (PDT) Received: from [192.168.1.16] (AMontsouris-753-1-3-56.w90-2.abo.wanadoo.fr [90.2.130.56]) by mx.google.com with ESMTPS id bd8sm2192527wbb.65.2011.04.23.03.34.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2011 03:34:44 -0700 (PDT) References: <02F6C412-BA94-4319-B05B-FF0B5AD343DC@nrl.navy.mil> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7A7D1783-E567-4970-965C-ED138BD4EF79@herberg.name> X-Mailer: iPad Mail (8H7) From: Ulrich Herberg Date: Sat, 23 Apr 2011 12:34:45 +0200 To: "Dearlove, Christopher (UK)" Cc: Ulrich Herberg , MANET IETF , Thomas Heide Clausen Subject: Re: [manet] WG adoption of NHDP-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.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, 23 Apr 2011 10:34:48 -0000 Chris, before I will reply to your comments, I have a general question: Do your com= ments apply to packetbb-sec or to NHDP-sec? It seems to me they apply to pac= ketbb-sec, rather than NHDP-sec... Ulrich On Apr 21, 2011, at 17:17, "Dearlove, Christopher (UK)" wrote: > Brief version: I think there's a two part change that should > be included before finishing WGLC. >=20 > My apologies in advance in that should this spark a discussion, > I'll be out of the loop for a week and a half and no able to > contribute. (The UK is largely shutting down, we have for a > combination of rare reasons, two four day weekends, with a > three day gap. Many of us are taking those three days off too.) >=20 > My main concern over this document is that it specifies a > signature as the composition of a hash function and a > cryptographic function, in that order. There are other ways > of constructing signatures that do not correspond to such > a decomposition. >=20 > The obvious response to that is to pick a new type extension > for such. This can't be normative text in this document, but > I think it should be described in the applicability statement, > which should say that this specification describes a general > approach to signatures (much of the document, such as how to > traety hop counts/limits is not specific to this decomposition) > and then a specific approach to signatures, and should provide > the comment that other mathematical forms of signature are > possible, and should be handled by use of alternative type > extensions. In the main body of the specification, a bit more > clarity on what is form-specific and what is not would then > help. >=20 > This then leads to the question a to whether the form described > should be the privileged type extension =3D 0 case. Actually I > would suggest it should be type extension =3D 1, with 0 reserved > for "I'm not providing any information on algorithms, this is > defined out of band, not in each packet. The reason I suggest > that as type 0 (and including it in this document) is that it > puts the two lowest-overhead options together (type extension 0, > which can be omitted, and no algorithm information). >=20 > Note that for timestamp, what other type extensions may be is > alraedy covered, but not so for signatures, and timestamp uses > the type extension 0 for the analogous case I suggest for type > extension 0 for signature, i.e. detertmined otherwise (should > the phrase "administrative action" be used in both cases?) >=20 > I think there should be another iteration before going to > SECDIR and IESG, as I think it will avoid work further down the > line, as well as being a better specification this way. >=20 > --=20 > Christopher Dearlove > Technology Leader, Communications Group > Communications and Networks Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 Fax: +44 1245 242124 >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf > Of Joe Macker > Sent: 07 April 2011 17:17 > To: MANET IETF > Subject: [manet] WG adoption of NHDP-sec >=20 >=20 > *** WARNING *** >=20 > This message has originated outside your organisation, > either from an external partner or the Global Internet.=20 > Keep this in mind if you answer this message. >=20 >=20 > As discussed in Prague we are presently considering adoption of NHDP > security related document as a WG document. >=20 > reference is draft-herberg-manet-nhdp-sec-01 >=20 > Please comment if you have an opinion. >=20 > -Joe > _______________________________________________ > 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 thomas@thomasclausen.org Thu Apr 28 23:37:29 2011 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05331E06B0 for ; Thu, 28 Apr 2011 23:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kdNPahzOSyd for ; Thu, 28 Apr 2011 23:37:23 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43E15E065F for ; Thu, 28 Apr 2011 23:37:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34DB2430052; Thu, 28 Apr 2011 23:37:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.1.5] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 530F643009F; Thu, 28 Apr 2011 23:37:21 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=Apple-Mail-1--665678672 Date: Fri, 29 Apr 2011 08:37:15 +0200 Message-Id: <4DBFA8F3-BD19-4586-AF51-EC9A19A50E38@thomasclausen.org> To: manet@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 29 Apr 2011 00:01:46 -0700 Cc: draft-ietf-manet-smf@tools.ietf.org Subject: [manet] WGLC Review of draft-ietf-manet-smf-11.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, 29 Apr 2011 06:37:29 -0000 --Apple-Mail-1--665678672 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Below, my comments to the latest version of the SMF I-D. >=20 >=20 >=20 > Network Working Group J. Macker, = editor > Internet-Draft = NRL > Intended status: Experimental SMF Design = Team > Expires: September 15, 2011 IETF MANET = WG > March 14, = 2011 >=20 The RFC Editor did in a previous document (NHDP) request that = design-team be listed in the contributors section, and not in the = author's section. If I understood correctly, this was a strong request, = so I suggest that this be reflected in also SMF. >=20 > Simplified Multicast Forwarding > draft-ietf-manet-smf-11 >=20 > Abstract >=20 > This document describes a Simplified Multicast Forwarding (SMF) > mechanism that provides basic IP multicast forwarding suitable for > wireless mesh and mobile ad hoc network (MANET) use. SMF defines It may be worth noting in the abstract that the term "multicast" in this = context relates to "manet-wide broadcast", and that no groups or = group-driven broadcast tree pruning is in scope? > techniques for multicast duplicate packet detection (DPD) to be > applied in the forwarding process and includes maintenance and > checking operations for both IPv4 and IPv6 protocol use. It is a bit unclear what "maintenance and checking operations" are or = are for. > SMF also > specifies mechanisms for applying reduced relay sets to achieve = more > efficient multicast data distribution within a mesh topology versus > simple flooding. The document describes interactions with other > protocols and multiple deployment approaches.=20 "Other protocols" - more specifically, which? > Distributed algorithms > for selecting reduced relay sets and related discussion are = provided > in the Appendices. Basic issues relating to the operation of > multicast MANET border routers are discussed but ongoing work = remains > in this area beyond the scope of this document. >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 4] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > 1. Requirements Notation >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", = and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. >=20 >=20 > 2. Introduction and Scope >=20 > Unicast routing protocol designs for MANET and wireless mesh use > often apply distributed algorithms to flood routing control plane > messages within an interior wireless routing domain. For example, > algorithms specified within [RFC3626] and [RFC3684] provide > distributed methods of dynamically electing reduced relay sets that > attempt to efficiently flood routing control messages while > maintaining a connected set under dynamic topological conditions. >=20 > In one sense, Simplified Multicast Forwarding (SMF) extends the "In one sense"? Suggest removing. > efficient flooding concept to the data forwarding plane. = Therefore, Suggest removing "Therefore," > SMF provides an appropriate multicast forwarding capability for use > cases where localized, efficient flooding is considered an = effective > design approach. The baseline design is intended to provide a = basic, > best effort multicast forwarding capability that is constrained to > operate within an interior MANET or wireless mesh routing domain. = An > SMF routing domain is an instance of a SMF routing protocol with > common policies that is under a single network administration > authority. The main design goals of this SMF specification are to > adapt efficient relay sets in MANET type environments [RFC2501] and > to define the needed IPv4 and IPv6 multicast duplicate packet > detection (DPD) mechanisms to support multi-hop, packet forwarding. >=20 > 2.1. Terminology >=20 > The following abbreviations are used throughout this document: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 5] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > +--------------+---------------------------------+ > | Abbreviation | Definition | > +--------------+---------------------------------+ > | MANET | Mobile Ad hoc Network | > | SMF | Simplified Multicast Forwarding | > | CF | Classical Flooding | > | CDS | Connected Dominating Set | > | MPR | Multi-Point Relay | > | S-MPR | Source-based MPR | > | MPR-CDS | MPR-based CDS | > | E-CDS | Essential CDS | > | NHDP | Neighborhood Discovery Protocol | > | SMF-DPD | SMF-Duplicate Packet Detection | > | I-DPD | Identification-based DPD | > | H-DPD | Hash-based DPD | > | HAV | Hash-assist Value | > | FIB | Forwarding Information Base | > | TLV | type-length-value encoding | > | DoS | Denial of Service | > +--------------+---------------------------------+ >=20 It is a little untraditional to have terminology as a table, alas, that = is not in itself a problem. However, the table simply "expands = acronyms", but doesn't really explain what they mean. "MPR", "S-MPR", = "MPR-CDS" and "E-CDS", for example, may be well understood within the = narrow MANET community, a bit less elsewhere. Suggest either a somewhat = more verbose description, or informative references cited (or both) ? >=20 > 3. Design Overview >=20 > Figure 1 provides an overview of the logical SMF node architecture, > consisting of "Neighborhood Discovery", "Relay Set Selection" and > "Forwarding Process" components. Typically, relay set selection = (or > self-election) occurs based on dynamic input from a neighborhood > discovery process. SMF supports the case where neighborhood > discovery and/or relay set selection information is obtained from a > coexistent process (e.g., a lower layer mechanism or a unicast > routing protocol using relay sets). In some algorithm designs, the > forwarding decision for a packet can also depend on previous hop or > incoming interface information. The asterisks (*) in Figure 1 mark > the primitives and relationships needed by relay set algorithms > requiring previous-hop packet forwarding knowledge. I do not think it quite clear what the "asterisk-notation" means, at = least I had to do a double-read on it. Would it not be clearer to draw = the figure without, and textually mentioning that not all algorithms = necessarily needs all information - with reference to the algorithm = descriptions? > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 6] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > ______________ _____________ > | | | | > | Neighborhood | | Relay Set | > | Discovery |------------->| Selection | > | Protocol | neighbor | Algorithm | > |______________| info |_____________| > \ / > \ / > neighbor\ /forwarding > info* \ ____________ / status > \ | | / > `-->| Forwarding |<--' > | Process | > ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~> > incoming packet, forwarded packets > interface id*, and > previous hop* >=20 > Figure 1: SMF Node Architecture >=20 > There are certain IP multicast packets, defined later in this > specification, that are "non-forwardable" and these multicast = packets > will be ignored by the SMF forwarding engine.=20 Suggest rephrasing/adding how these multicast packets are identified? = Presumably by their addresses....? > The SMF forwarding > engine MAY also work with policies and management interfaces to = allow > additional filtering control over which multicast packets are > considered for potential SMF forwarding. This interface would = allow > more refined dynamic forwarding control once such techniques are > matured for MANET operation. At present further discussion of > dynamic control is left to future work. > Interoperable SMF implementations MUST use a common DPD approach = and > be able to process the header options defined in this document for > IPv6 operation. We define Classical Flooding (CF), as the simplest > case of SMF multicast forwarding. With CF, each SMF router = forwards > each received multicast packet exactly once. In this case, the = need > for any relay set selection or neighborhood topology information is > eliminated at the expense of additional network overhead. In CF > mode, the SMF-DPD functionality is still required. While SMF > supports a CF mode of operation the use of more efficient relay set > modes is RECOMMENDED to reduce contention and congestion caused by > unnecessary packet retransmissions [NTSC99]. >=20 The above paragraph is confusing. It starts by outlining a requirement for interoperability. It then = discusses characteristics of a specific forwarding algorithm. It is not = clear what the relationship between these two are. I would actually suggest to have a top-level section "Requirements for = Interoperability" somewhere in the document, assembling all the = different such conditions for two implementations to have a chance at = interoperating. That section would also be the place to discuss what = happens if two "non-interoperable" SMF-implementations are present in = the same routing domain. I am, for the record, also somewhat stylistically against "We = define....", and prefer "This document defines...." - although I = recognize that to be probably a matter of taste =20 > An efficient, reduced relay set is realized by selecting and realized -> constructed > maintaining a subset of all possible routers in a MANET routing > domain. Known distributed relay set selection algorithms have > demonstrated the ability to provide and maintain a dynamic = connected > set for forwarding multicast IP packets [MDC04]. A few such relay > set selection algorithms are described in the Appendices of this >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 7] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > document and the basic designs borrow directly from previously > documented IETF work. SMF relay set configuration is extensible = and > additional relay set algorithms beyond those specified here can be > accommodated in future work. >=20 > Determining and maintaining an optimized set of forwarding nodes Two things here, terminology-wise (also apply elsewhere in the I-D, but = I haven't pointed them all out explicitly): o "nodes" or "routers"? We have used "routers" pretty = systematically in most of the=20 recent MANET RFCs, and after all we are in the RTG area o "forwarding nodes" or "relay set" - seems to be the same = thing (if so, use same=20 terminology).....otherwise, explain why the need for = different terms. > generally requires dynamic neighborhood topology information. > Neighborhood topology discovery functions MAY be externally = provided > by a MANET unicast routing protocol or by using the MANET > NeighborHood Discovery Protocol (NHDP) [RFC6130] running in > concurrence with SMF. =20 Suggest removing "externally" > Additionally, this specification allows Suggest removing "Additionally," > alternative lower layer interfaces (radio router interface) to > provide the necessary neighborhood information to aid in supporting > more effective relay set election. Fundamentally, an SMF > implementation SHOULD provide the ability for multicast forwarding > state to be dynamically managed per operating network interface. > Some of the relay state maintenance options and interactions are > outlined later in Section 7.=20 This phrase leaves me a little cold: "Some of the relay state = maintenance options and interactions...." - but not all? Does this mean = that I cannot rely solely on this specification to create an = implementation of SMF? > This document states specific > requirements for neighborhood discovery with respect to the > forwarding process and the relay set selection algorithms described > herein. For determining dynamic relay sets in the absence of other > control interfaces, SMF relies on the MANET NHDP specification to > assist in IP layer 2-hop neighborhood state discovery and = maintenance > for relay set election. "SMF_TYPE" and "SMF_NBR_TYPE" Message and > Address Block, respectfully, TLV structures (per [RFC5444]) are > defined for use with the NHDP protocol. It is RECOMMENDED that all > nodes performing SMF operation in conjunction with NHDP, include > these TLV types in any NHDP HELLO messages generated. This > capability allows for nodes participating in SMF to be explicitly > identified along with their respective dynamic relay set algorithm. >=20 >=20 > 4. SMF Applicability >=20 Suggest "SMF Applicability" -> "Applicability Statement" ? > Within dynamic wireless routing topologies, maintaining traditional > forwarding trees to support a multicast routing protocol is often = not > as effective as in wired networks due to the reduced reliability = and > increased dynamics of mesh topologies [MGL04] [GM99]. A basic = packet > forwarding service reaching all connected routers running the SMF > protocol within a localized routing domain may provide a useful = group > communication paradigm for various classes of applications. > Applications that could take advantage of a simple multicast could -> can ? > forwarding service include multimedia streaming, interactive group- > based messaging and applications, peer-to-peer middleware > multicasting, and multi-hop mobile discovery or registration > services. SMF is likely only appropriate for deployment in limited > dynamic wireless routing domains so that the flooding process can = be > contained. The limited SMF routing domains are further defined as >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 8] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > administratively scoped multicast forwarding domains in Section = 9.2. >=20 > Note again that Figure 1 provides a notional architecture for = typical > SMF-capable nodes. A goal is that simple leaf nodes may also > participate in multicast traffic transmission and reception with Here, the use of "node" becomes critical. There apparently are two kinds = "simple leaf nodes" and "other nodes". Are those what we call "hosts" = and "routers", usually? If not, what's the difference? (And, suggest = that it be described in terminology) > standard IP network layer semantics (e.g., special or unnecessary > encapsulation of IP packets should be avoided in this case). It is > important that SMF deployments in localized edge network settings = are Sure, it is "important" - but is it supported by SMF? The applicability = statement doesn't seem to be the appropriate place to list design = requirements (that should probably be in the "Design Overview" section? > able to connect and interoperate with existing standard multicast > protocols operating within more conventional Internet > infrastructures. A multicast border router or proxy mechanism MUST 2119-style MUST used in the applicability statement seems wrong to me. = Would suggest stating in this section that "SMF can interoperate / = interact with a fixed-infrastructre IP multicast routing", and then hive = this more detailed discussion off to section 9? > be used when deployed alongside more fixed-infrastructure IP > multicast routing such Protocol Independent Multicast (PIM) = variants > [RFC3973] and [RFC4601]. Present experimental SMF implementations Suggest removing "Present" > have demonstrated gateway functionality at MANET border routers > operating with existing external IP multicast routing protocols > [CDHM07],[DHS08],and [DHG09]. SMF may be extended or combined with > other mechanisms to provide increased reliability and group = specific > filtering, but the details for this are not discussed here. >=20 >=20 > 5. SMF Packet Processing and Forwarding >=20 > The SMF Packet Processing and Forwarding actions are conducted with > the following packet handling activities: >=20 > 1. Processing of outbound, locally-generated multicast packets. > 2. Reception and processing of inbound packets on specific network > interfaces. >=20 > The purpose of intercepting outbound, locally-generated multicast > packets is to apply any added packet marking needed to satisfy the > DPD requirements so that proper forwarding may be conducted. Note > that for some system configurations the interception of outbound > packets for this purpose is not necessary. >=20 > Inbound multicast packets are received by the SMF implementation = and > processed for possible forwarding. This document does not = presently > support forwarding of directed broadcast addresses [RFC2644].=20 To "Applicability Statement" ? > SMF > implementations MUST be capable of forwarding IP multicast packets > with destination addresses that are not node-local and link-local = for > IPv6 as defined in [RFC4291] and that are not within the local > network control block as defined by [RFC5771] >=20 1) there's a period (".") missing after the final citation 2) this is again a design requirement, not a description of = protocol functioning, thus it probably should be moved to section 3?=20 > This will help support generic multi-hop multicast application = needs > or to distribute designated multicast traffic ingressing the SMF > routing domain via border routers. The multicast addresses to be > forwarded should be maintained by an a priori list or a dynamic >=20 Probably this would be better in a section called "Deployment = considerations", as it does not specify as such the functioning of the = protocol, but operational requirements? >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 9] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > forwarding information base (FIB) that MAY interact with future = MANET > dynamic group membership extensions or management functions. There > will also be a well-known multicast group for SMF. This multicast "will also be"? Suggest rephrasing to "The well-known SL-MANET-ROUTERS = multicast group ...". Actually, suggest writing the document as-if the = group has already been assigned (which it would be once published as = RFC) and hive all requests-to-IANA off to "IANA Considerations" =20 > group is specified to contain all routers within an SMF routing > domain, so that packets transmitted to the multicast address > associated with the group will be delivered to all connected = routers > running SMF. Due the mobile nature of a MANET, routers running SMF > may not be topologically connected at particular times. For IPv6, > the multicast address is specified to be "site-local". =20 > The name of > the multicast group is "SL-MANET-ROUTERS".=20 Suggest removing this phrase. > Minimally SMF MUST > forward, as instructed by the relay set selection algorithm, unique > (non-duplicate) packets received for this well-known group address > when the TTL or hop limit value in the IP header is greater than 1. > SMF MUST forward all additional global scope addresses specified > within the dynamic FIB or configured list as well. In all cases, = the > following rules MUST be observed for SMF multicast forwarding: >=20 > 1. IP multicast packets with TTL <=3D 1 MUST NOT be forwarded. > 2. Link local IP multicast packets MUST NOT be forwarded. > 3. Incoming IP multicast packets with an IP source address = matching > one of those of the local SMF router interface(s) MUST NOT be > forwarded. > 4. Received frames with the MAC source address matching any MAC > address of the routers interfaces MUST NOT be forwarded. > 5. Received packets for which SMF cannot reasonably ensure = temporal > DPD uniqueness MUST NOT be forwarded. Probably need an expansion or a reference to where this is expanded. > 6. When packets are forwarded, TTL or hop limit MUST be = decremented > by one. >=20 > Note that rule #3 is important because over some types of wireless > interfaces, the originating SMF router may receive re-transmissions > of its own packets when they are forwarded by adjacent routers. = This > rule avoids unnecessary retransmission of locally-generated packets > even when other forwarding decision rules would apply. >=20 > An additional processing rule also needs to be considered based = upon > a potential security threat. As discussed further in Section 10, > there may be concern in some SMF deployments that malicious nodes = may "nodes" ....? > conduct a denial-of-service attack by remotely "previewing" (e.g., > via a directional receive antenna) packets that an SMF node would = be > forwarding and conduct a "pre-play" attack by transmitting the = packet > before the SMF node would otherwise receive it but with a reduced = TTL > (or Hop Limit) field value. This form of attack could cause an SMF > node to create a DPD entry that would block the proper forwarding = of > the valid packet (with correct TTL) through the SMF area. A > RECOMMENDED approach to prevent this attack, when it is a concern, > would be to cache temporal packet TTL values along with the per- > packet DPD state (hash value(s) and/or identifier as described in >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 10] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > Section 6). Then, if a subsequent matching (with respect to DPD) > packet arrives with a larger TTL value than the packet that was > previously forwarded, SMF should forward the new packet and update > the TTL value cached with corresponding DPD state to the new, = larger > TTL value. There may be temporal cases where SMF would = unnecessarily > forward some duplicate packets using this approach, but those cases > are expected to be minimal and acceptable when compared with the > potential threat of denied service. It is unclear what the "additional processing rule" then is. Is it = possible to spell it out and add as rule #7 to the list above? > Once these criteria Which criteria? >=20 > 6.1. IPv6 Duplicate Packet Detection >=20 > This section describes the mechanisms and options for SMF IPv6 DPD. > The core IPv6 packet header does not provide any explicit > identification header field that can be exploited for I-DPD. The > following areas are described to support IPv6 DPD and each is = covered > in more detail in particular subsections: > 1. the hop-by-hop SMF-DPD option header, > 2. the use of IPv6 fragment header fields for I-DPD when they = exist, > 3. the use of IPsec sequencing for I-DPD when a non-fragmented, > IPsec header is detected, and > 4. an H-DPD approach assisted, as needed, by the SMF-DPD option > header. >=20 Suggest actually adding to each of these = subsections here. > SMF MUST provide a DPD marking module that can insert the = hop-by-hop > IPv6 header option defined in this section. This process MUST come > after any source-based fragmentation that may occur with IPv6. As > with IPv4, SMF IPv6 DPD is presently specified to allow either a > packet hash or header identification method for DPD. An SMF > implementation MUST be configured to operate either in H-DPD or = I-DPD > mode and perform the appropriate routines outlined in the following > sections. >=20 > 6.1.1. IPv6 SMF-DPD Header Option >=20 > The base IPv6 packet header does not contain a unique identifier > suitable for DPD. This section defines an IPv6 Hop-by-Hop Option >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 12] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > [RFC2460] to serve this purpose for IPv6 I-DPD. Additionally, the > header option provides a mechanism to guarantee non-collision of = hash > values for different packets when H-DPD is used. >=20 > If this is the only hop-by-hop option present, the optional > "TaggerId" field (see below) is not included, and the size of the = DPD > packet identifier (sequence number) or hash token is 24 bits or = less, > this will result in the addition of 8 bytes to the IPv6 packet = header > including the "Next Header", "Header Extension Length", SMF-DPD > option fields, and padding. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... |0|0|0| OptType | Opt. Data Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |H| DPD Identifier Option Fields or Hash Assist Value ... > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option >=20 > "Option Type" =3D (Lower 5 bits pending IANA assignment, highest = order > MUST be 000). By having these three bits be zero, this = specification > requires that nodes not recognizing this option type should skip = over > this option and continue processing the header and that the option > must not change en route [RFC2460]. >=20 > "Opt. Data Len" =3D Length of option content (I.e., 1 + ( ? > ( + 1): 0) + Length(DPD ID)). >=20 > "H-bit" =3D a hash indicator bit value identifying DPD marking = type. 0 > =3D=3D sequence-based approach w/ optional taggerId and a = tuple-based > sequence number. 1 =3D=3D indicates a hash assist value (HAV) field > follows to aid in avoiding hash-based DPD collisions. >=20 > When the "H-bit" is cleared (zero value), the SMF-DPD format to > support I-DPD operation is specified as shown in Figure 2 and = defines > the extension header in accordance with [RFC2460]. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 13] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... |0|0|0| OptType | Opt. Data Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|TidTyp|TidLen| TaggerId (optional) ... = | > +-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Identifier ... > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode >=20 > The "TidType" is a 3-bit field indicating the presence and type of > the optional "TaggerId" field. The optional "TaggerId" is used to > differentiate multiple ingressing border gateways that may commonly > apply the SMF-DPD option header to packets from a particular = source. This probably merits at least a reference to section 9, and some = discussion there detailing this operation a bit more? > This is provided for experimental purposes. The following table > lists the valid TaggerId types: >=20 > 6.1.2. IPv6 Identification-based DPD >=20 > The following table summarizes the IPv6 I-DPD processing and > forwarding decision approach. Within the table '*' indicates an > ignore field condition. >=20 What is "an ignore field condition" ? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 15] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > = +-------------+-----------+-----------+-----------------------------+ > | IPv6 | IPv6 | IPv6 | SMF IPv6 I-DPD Mode Action = | > | Fragment | IPsec | I-DPD | = | > | Header | Header | Header | = | > = +-------------+-----------+-----------+-----------------------------+ > | Present | * | * | Use Fragment Header I-DPD = | > | | | | Check and Process for = | > | | | | Forwarding = | > | Not Present | Present | * | Use IPsec Header I-DPD = | > | | | | Check and Process for = | > | | | | Forwarding = | > | Present | * | Present | Invalid, do not Forward = | > | Not Present | Present | Present | Invalid, do not Forward = | > | Not Present | Not | Not | Add I-DPD Header,and = | > | | Present | Present | Process for Forwarding = | > | Not Present | Not | Present | Use I-DPD Header Check and = | > | | Present | | Process for Forwarding = | > = +-------------+-----------+-----------+-----------------------------+ >=20 > Table 2: IPv6 I-DPD Processing Rules >=20 >=20 > 6.1.3. IPv6 Hash-based DPD >=20 > A default hash-based DPD approach (H-DPD) for use by SMF is = specified > as follows. An MD5 [RFC1321] hash of the non-mutable header = fields, > options fields, and data content of the IPv6 multicast packet is = used > to produce a 128-bit digest. The least significant 64 bits of this 1) Someone is likely to say that MD5 is deprecated; 2) Is the use of MD5 vs. any other hashing algorithm important? If = not, suggest citing MD5 as an example (and reserve a field for indicating which hash = algorithm is in use); Should be possible when inserting a header option in IPv6; 3) Suggest discussion of the impact of hash collisions (security = and performance)? >=20 > 6.2.1. IPv4 Identification-based DPD >=20 > The following table summarizes the IPv4 I-DPD processing approach > once a packet has passed the basic forwardable criteria described = in > Section 5. Within the table '*' indicates an ignore field = condition. > DF, MF, Fragment offset correspond to related fields and flags > defined in [RFC0791]. >=20 "ignore field condition" is unclear - what does it mean? >=20 > 6.2.2. IPv4 Hash-based DPD >=20 > To ensure consistent IPv4 H-DPD operation among SMF nodes, a = default > hashing approach is specified. This is similar to that specified = for > IPv6, but the H-DPD header option with HAV is not considered. SMF > MUST perform an MD5 [RFC1321] hash of the immutable header fields, > option fields and data content of the IPv4 multicast packet = resulting > in a 128-bit digest. The least significant 64 bits of this digest = is > used for SMF packet identification. The approach for calculating = the > hash value SHOULD follow the same guidelines described for > calculating the Integrity Check Value (ICV) described in [RFC4302] > with respect to non-mutable fields. A history of the packet hash > values SHOULD be maintained in the context of dstAddr>. The context for IPv4 is more specific than that of IPv6 > since the SMF-DPD HAV cannot be employed to mitigate hash = collisions. >=20 > The MD5 hash is specified at present for consistency and = robustness. > Future approaches and experimentation may discover design tradeoffs > in hash robustness and efficiency worth considering for future > revisions of SMF. This MAY include reducing the packet payload > length that is processed, determining shorter indexes, or applying = a > more efficient hashing algorithm. >=20 Same comments as to MD5 as above; >=20 > 7. Relay Set Selection >=20 > 7.1. Non-Reduced Relay Set Forwarding >=20 > SMF implementations MUST support CF as a basic forwarding mechanism > when reduced relay set information is not available or not selected >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 20] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > for operation. In CF mode, each node transmits a locally generated > or newly received forwardable packet exactly once. The DPD > techniques described in Section 6 are critical to proper operation > and prevent duplicate packet retransmissions by the same forwarding > node. >=20 > 7.2. Reduced Relay Set Forwarding >=20 > MANET reduced relay sets are often achieved by distributed = algorithms > that can dynamically calculate a topological connected dominating = set > (CDS). >=20 > A goal of SMF is to apply reduced relay sets for more efficient > multicast dissemination within dynamic topologies. To accomplish > this SMF MUST support the ability to modify its multicast packet > forwarding rules based upon relay set state received dynamically > during operation. In this way, SMF forwarding operates effectively > as neighbor adjacencies or multicast forwarding policies within the > topology change. >=20 > In early SMF experimental prototyping, the relay set information = has > been derived from coexistent unicast routing control plane traffic > flooding processes [MDC04]. =46rom this experience, extra pruning > considerations were sometimes required when utilizing a relay set > from a separate routing protocol process. As an example, relay = sets > formed for the unicast control plane flooding MAY include = additional > redundancy that may not be desired for multicast forwarding use > (e.g., biconnected relay set). >=20 > Here is a recommended criteria list for SMF relay set selection > algorithm candidates: >=20 > 1. Robustness to topological dynamics and mobility > 2. Localized election or coordination of any relay sets > 3. Reasonable minimization of CDS relay set size given above > constraints > 4. Heuristic support for preference or election metrics >=20 > Some relay set algorithms meeting these criteria are described in = the > Appendices of this document. Additional relay set selection > algorithms may be specified in separate specifications in the = future. > Each Appendix subsection in this document can serve as a template = for > specifying additional relay algorithms. >=20 > Figure 4 depicts a information flow diagram of possible relay set > control options. The SMF Relay Set State represents the = information > base that is used by SMF in the forwarding decision process. The > relay set control option diagram demonstrates that the SMF relay = set >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 21] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > state may be determined by fundamentally three different methods: > independent operation with NHDP [RFC5444] input providing dynamic > network neighborhood adjacency information that is then used by a > particular relay set selection, slave operation with an existing > unicast MANET routing protocol that is capable of providing CDS > election information that can be used by SMF, and cross layer > operation that may involve lower layer neighbor or link = information. > Other heuristics to influence and control election can come from > network management or other interfaces as shown on the right. Of > course CF mode, simplifies the control and does not require other > input but relies solely on DPD. >=20 > Possible L2 Trigger/Information > | > | > ______________ ______v_____ = __________________ > | MANET | | | | = | > | Neighborhood | | Relay Set | | Other Heuristics = | > | Discovery |----------->| Selection |<------| (Preference,etc) = | > | Protocol | neighbor | Algorithm | | Net Management = | > |______________| info |____________| = |__________________| > \ / > \ / > neighbor\ / Dynamic Relay > info* \ ____________ / Set Status > \ | SMF | / (State, {neighbor info}) > `-->| Relay Set |<--' > | State | > -->|____________| > / > / > ______________ > | Coexistent | > | MANET | > | Unicast | > | Process | > |______________| >=20 > Figure 4: SMF Reduced Relay Set Information Flow >=20 What does the asterisk next to the left "neighbor info" mean? > 8. SMF Neighborhood Discovery Requirements >=20 > This section defines the requirements for use of the MANET > Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF > operation. Note that basic CF forwarding requires no neighborhood > topology knowledge since in this configured mode every SMF node > relays all traffic. Supporting more reduced SMF relay set = operation > requires the discovery and maintenance of dynamic neighborhood > topology information. The MANET NHDP protocol can be leveraged leveraged -> used > provide this necessary information, however there are SMF-specific > requirements for related NHDP use. This is the case for both what does "related NHDP use" mean? Related to what? > "independent" SMF operation where NHDP is being used specifically = to > support SMF or when one NHDP instance is used for both for SMF and = a > coexistent MANET unicast routing protocol. >=20 > NHDP HELLO messages and the resultant neighborhood information base > are described separately within the NHDP specification. To > summarize, the NHDP protocol provides the following basic = functions: >=20 NHDP =3D NeighborHood Discovery Protocol. Saying "the NHDP Protocol" is = therefore redundant ("NeighborHood Discovery Protocol Protocol"). = Suggest: "To summarize, NHDP provides the following ...." > 1. 1-hop neighbor link sensing and bidirectionality checks of > neighbor links, > 2. 2-hop neighborhood discovery including collection of 2-hop > neighbors and connectivity information, > 3. Collection and maintenance of the above information across > multiple interfaces, and > 4. A method for signaling SMF information throughout the 2-hop > neighborhood through the use of TLV extensions. >=20 > Appendices (A-C) of this document describe CDS-based relay set > selection algorithms that can achieve efficient SMF operation, even > in dynamic, mobile networks and each of the algorithms has been >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 23] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > initially experimented within a working SMF prototype [MDDA07]. = When > using these algorithms in conjunction with NHDP, a method verifying > neighbor SMF operation is required in order to insure correct relay > set selection. NHDP along with SMF operation verification provides > the necessary information required by these algorithms to conduct > relay set selection. Verification of SMF operation may be done > administratively or through the use of the SMF relay algorithms = TLVs > defined in the following subsections. Use of the SMF relay = algorithm > TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery. >=20 > The following sub-sections=20 Suggest "Sections X, Y and Z" > specify some SMF-specific TLV types "some" is vague? Does it mean "some, but not all" -- and, if so, where = do I find the rest? Or, should "some" simply be removed? > supporting general SMF operation or supporting the algorithms > described in the Appendices. The Appendices describing several = relay > set algorithms also specify any additional requirements for use = with > NHDP and reference the applicable TLV types as needed. >=20 > 8.1. SMF Relay Algorithm TLV Types >=20 > This section specifies TLV types to be used within NHDP messages to > identify the CDS relay set selection algorithm(s) in use. Two TLV > types are defined, one message TLV type and one address TLV type. >=20 > 8.1.1. SMF Message TLV Type >=20 > The message TLV type denoted SMF_TYPE is used to identify the > existence of an SMF instance operating in conjunction with NHDP. > This message TLV type makes use of the extended type field as = defined > by [RFC5444] to convey the CDS relay set selection algorithm > currently in use by the SMF message originator. When NHDP is used = to > support SMF operation, the SMF_TYPE TLV, containing the extended = type > field with the appropriate value, SHOULD be included in NHDP_HELLO > messages (HELLO messages as defined in [RFC6130]. This allows SMF > nodes to learn when neighbors are configured to use NHDP for > information exchange including algorithm type and related algorithm > information. This information can be used to take action, such as > ignoring neighbor information using incompatible algorithms. It is > possible that SMF neighbors MAY be configured differently and still > operate cooperatively, but these cases will vary dependent upon the > algorithm types designated. >=20 > This document defines the following Message TLV type Which following TLV type? Do you mean "this documents defines one = Message TLV type 'SMF_TYPE', specified in table 6" ? > as specified in > Table 6 conforming to [RFC5444]. The TLV extended type field is = used > to contain the sender's "Relay Algorithm Type". The interpretation > of the "value" content of these TLVs is defined per "Relay = Algorithm > Type" and may contain algorithm specific information. >=20 >=20 >=20 >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 24] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > +---------------+----------------+--------------------+ > | | TLV syntax | Field Values | > +---------------+----------------+--------------------+ > | type | | SMF_TYPE | > | extended type | | | > | length | | variable | > | value | | variable | > +---------------+----------------+--------------------+ >=20 > Table 6: SMF Type Message TLV >=20 > In Table 6 is an 8-bit field containing a number > 0-255 representing the "Relay Algorithm Type" of the originator > address of the corresponding NHDP message. >=20 > Possible values for the are defined in Table 7. > The table provides value assignments, future IANA assignment = spaces, > and an experimental space. The experimental space use MUST NOT > assume uniqueness and thus should not be used for general > interoperable deployment prior to official IANA assignment. >=20 > = +-------------+--------------------+--------------------------------+ > | Type Value | Extended Type | Algorithm = | > | | Value | = | > = +-------------+--------------------+--------------------------------+ > | SMF_TYPE | 0 | CF = | > | SMF_TYPE | 1 | S-MPR = | > | SMF_TYPE | 2 | E-CDS = | > | SMF_TYPE | 3 | MPR-CDS = | > | SMF_TYPE | 4-127 | Future Assignment STD action = | > | SMF_TYPE | 128-239 | No STD action required = | > | SMF_TYPE | 240-255 | Experimental Space = | > = +-------------+--------------------+--------------------------------+ >=20 > Table 7: SMF Relay Algorithm Type Values >=20 I actually do not think that this belongs here. Table 7 details the = initial assignment of Extended Type Values, which is an IANA action once = the SMF_TYPE has been registered. Hence, I would suggest that this be = moved to the IANA section. Second, when a TLV Type is created, the Extended Type registry is also = created by IANA, and needs assignment policies; there are fairly = specific recommendations for how to select assignment policies for IANA = governed registries, see rfc5226. Third, I do not understand the difference between "No STD action = required" and "Experimental space"? Is it such that the former is = "first-come-first-served-free-for-all"? Or, does it mean "expert review, = but not necessarily std. action"? Fourth, the intended status of SMF is experimental, yes? If so, is std. = action even possible (std. action means that a std.track RFC is = published - which, likely, would not downref to an exp. RFC)? Recommend = section 4.1 of 5226 > Acceptable and fields of an SMF_TYPE TLV are > dependent on the extended type value (i.e. relay algorithm type). > The appropriate algorithm type, as conveyed in the > field, defines the meaning and format of its TLV field. = For > the algorithms defined by this document, see the appropriate = appendix > for the field format. >=20 > 8.1.2. SMF Address Block TLV Type >=20 > An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor > relay algorithm) is specified in Table 8. This TLV enables CDS = relay > algorithm operation and configuration to be shared among 2-hop >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 25] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > neighborhoods. Some relay algorithms require two hop neighbor > configuration in order to correctly select relay sets. It is also > useful when mixed relay algorithm operation is possible, some > examples of mixed use is outlined in the appendices. >=20 > The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types > share a common format. >=20 > +---------------+----------------+--------------------+ > | | TLV syntax | Field Values | > +---------------+----------------+--------------------+ > | type | | SMF_NBR_TYPE | > | extended type | | | > | length | | variable | > | value | | variable | > +---------------+----------------+--------------------+ >=20 > Table 8: SMF Type Address Block TLV >=20 > in Table 8 is an 8-bit unsigned integer field > containing a number 0-255 representing the "Relay Algorithm Type" > value that corresponds to any associated address in the address > block. Note that "Relay Algorithm Type" values for 2-hop neighbors > can be conveyed in a single TLV or multiple value TLVs as described > in [RFC5444]. It is expected that SMF nodes using NHDP construct > address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm > Type" and to advertise neighbor algorithm values received in = SMF_TYPE > TLVs from those neighbors. >=20 > Again values for the are defined in Table 8. No, they're not. Table 8 simply describes the TLV structure, does not = give values. Do you mean Table 7 >=20 > The interpretation of the "value" field of SMF_NBR_TYPE TLVs is > defined per "Relay Algorithm Type" and may contain algorithm = specific > information. See the appropriate appendix for definitions of value > fields for the algorithms defined by this document. >=20 >=20 > 9.4. Multiple Border Routers >=20 > An SMF domain might be deployed with multiple participating nodes > having connectivity to external, fixed-infrastructure networks. > Allowing multiple nodes to forward multicast traffic to/from the = SMF > routing domain can be beneficial since it can increase reliability, > and provide better service. For example, if the SMF routing domain > were to fragment with different SMF nodes maintaining connectivity = to > different border routers, multicast service could still continue > successfully. But, the case of multiple border routers connecting = a > SMF routing domain to external networks presents several challenges > for SMF: >=20 > 1. Handling duplicate unmarked IPv4 or IPv6 (without IPsec > encapsulation or DPD option) packets possibly injected by > multiple border routers. >=20 >=20 >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 29] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > 2. Source-based relay algorithms handling of duplicate traffic > injected by multiple border routers. > 3. Determination of which border router(s) will forward outbound > multicast traffic. > 4. Additional challenges with interfaces to exterior multicast > routing protocols. >=20 > When multiple border routers are present they may be alternatively > (due to route changes) or simultaneously injecting common traffic > into the MANET routing region that has not been previously marked = for > SMF-DPD. Different border routers would not be able to implicitly > synchronize sequencing of injected traffic since they may not = receive > exactly the same messages due to packet losses. For IPv6 I-DPD > operation, the optional "TaggerId" field described for the SMF-DPD > header option can be used to mitigate this issue.=20 As previously indicated, I would recommend adding some further = description here as to how this "tagging" is done. Also, is this _only_ = relevant when there are multiple border routers in the network? > 11. IANA Considerations >=20 > This document raises multiple IANA Considerations. These include = the > IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type- > Length-Value (TLV) constructs [RFC5444]) to be used with NHDP > [RFC6130]operation as needed to support different forms of SMF > operation. There is one message TLV type and one address TLV type > needed to be assigned for SMF purposes as discussed in Section 8.1. >=20 > The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be > assigned). >=20 > The SL-MANET-ROUTERS multicast address will be registered for both > IPv4 and IPv6 multicast address spaces. >=20 > 11.1. IPv6 SMF-DPD Header Extension >=20 > This document requests IANA assignment of the "SMF_DPD" hop-by-hop > option type from the IANA "IPv6 Hop-by-Hop Options Option Type" > registry (see Section 5.5 of [RFC2780]). >=20 > The format of this new option type is described in Section 6.1.1. = A > portion of the option data content is the taggger identifier type > "TidType" that provides a context for the "TaggerId" that is > optionally included to identify the node that added the SMF_DPD > option to the packet. This document defines a namespace for IPv6 > SMF_DPD Tagger Identifier Type values: > ietf:manet:smf:taggerIdTypes >=20 > The values that can be assigned within the "ietf:manet:smf: > taggerIdTypes" name-space are numeric indexes in the range [0, 7], > boundaries included. All assignment requests are granted on an = "IETF > Consensus" basis as defined in [RFC5226]. >=20 > This specification registers Tagger Identification Type values from > Table 9 in the registry "ietf:manet:smf:taggerIdTypes": >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 32] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > +----------+-------+---------------+ > | Mnemonic | Value | Reference | > +----------+-------+---------------+ > | NULL | 0 | This document | > | DEFAULT | 1 | This document | > | IPv4 | 2 | This document | > | IPv6 | 3 | This document | > | ExtId | 7 | This document | > +----------+-------+---------------+ >=20 > Table 9: TaggerId Types >=20 > 11.2. SMF Type-Length-Value >=20 > This document requests IANA assignment of one message "SMF_TYPE" = TLV > type and one address block "SMF_NBR_TYPE" TLV type from the = [RFC6130] > specific registry space. Specify which spaces those are from among those in 6130? >=20 > The common format of these new TLV types is described in Table 6 = and > Table 8. Furthermore this document defines a namespace for = algorithm > ID types using the extended type TLV value field defined by > [RFC5444]. Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace. >=20 > ietf:manet:packetbb:nhdp:smf:relayAlgorithmID >=20 > The values that can be assigned within the = "ietf:manet:packetbb:nhdp: > smf:relayAlgorithmID" name-space are numeric indexes in the range = [0, > 239], boundaries included. Assignment requests for the [0-127] are > granted on an "IETF Consensus" basis as defined in [RFC5226]. > Standards action is not required for assignment requests of the = range > [128-239]. Documents requesting relayAlgorithmId values SHOULD > define value field uses contained by the = SMF_TYPE: > and SMF_NBR_TYPE: full type TLVs. >=20 > This specification registers the following Relay Algorithm ID Type > values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp: > smf:relayAlgorithmID >=20 > +----------+-------+------------+ > | Mnemonic | Value | Reference | > +----------+-------+------------+ > | CF | 0 | | > | S-MPR | 1 | Appendix B | > | E-CDS | 2 | Appendix A | > | MPR-CDS | 3 | Appendix C | > +----------+-------+------------+ >=20 > Table 10: Relay Set Algorithm Type Values >=20 >=20 Suggest moving the type-extension description to here, with proper = assignment policies. >=20 > Appendix A. Essential Connecting Dominating Set (E-CDS) Algorithm >=20 > The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS] > forms a single CDS mesh for the SMF operating region. It allows >=20 >=20 >=20 > Macker, editor & SMF Design Team Expires September 15, 2011 [Page = 36] > =0C > Internet-Draft SMF March = 2011 >=20 >=20 > nodes to use 2-hop neighborhood topology information to dynamically > perform relay self election to form a CDS. Its packet forwarding > rules are not dependent upon previous hop knowledge. Additionally, > E-CDS SMF forwarders can be easily mixed without problems with CF = SMF > forwarders, even those not participating in NHDP. Another benefit = is > that packets opportunistically received from non-symmetric = neighbors > may be forwarded without compromising flooding efficiency or > correctness. Furthermore, multicast sources not participating in > NHDP may freely inject their traffic and any neighboring E-CDS = relays > will properly forward the traffic. The E-CDS based relay set > selection algorithm is based upon the summary within [E-CDS]. = E-CDS > was originally discussed in the context of forming partial > adjacencies and efficient flooding for MANET OSPF extensions work = and > the core algorithm is applied here for SMF. >=20 > It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV be included = in > NHDP_HELLO messages that are generated by nodes conducting E-CDS = SMF > operation. It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS > address block TLV be used to advertise neighbor nodes that are also > conducting E-CDS SMF operation. >=20 General comment to all appendices: I believe that it is inappropriate to = use 2119-style language in appendices, as I believe that appendices = default to informative, not normative? > A.1. E-CDS Relay Set Selection Overview >=20 > The E-CDS relay set selection requires 2-hop neighborhood = information > collected through NHDP or another process. Relay nodes, in E-CDS = SMF > selection, are "self-elected" using a router identifier (Router ID) "Relay nodes ..... using a router identifier (Router ID) and an optional = nodal metric" So: node-router-router-node ? > and an optional nodal metric, referred to here as "Router Priority" > for all 1-hop and 2-hop neighbors. To ensure proper relay set = self- > election, the Router ID and Router Priority MUST be consistent = among > participating nodes. It is RECOMMENDED that NHDP be used to share > Router ID and Router Priority through the use of SMF_TYPE:E-CDS = TLVs > as described in this appendix.. The Router ID is a logical Appendix followed by two periods. >=20 > It is RECOMMENDED that the SMF_TYPE:S-MPR message TLV be included = in > NHDP_HELLO messages that are generated by nodes conducting S-MPR = SMF > operation. It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR > address block TLV be used to specify which neighbor nodes are > conducting S-MPR SMF operation. >=20 Just latching on to this here, but.... Isn't it a normative requirement (i.e., to be stipulated outside of = appendices) that this TLV is included for SMF operation of NHDP? In general, SHOULD (and, so, also RECOMMENDED) often should be a MUST - = if not, then the consequences of disregarding the recommendation should = be specified. Thomas= --Apple-Mail-1--665678672 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

Below, my comments to = the latest version of the SMF I-D.



Network Working Group                                  J. Macker, editor
Internet-Draft                                                       NRL
Intended status: Experimental                            SMF Design Team
Expires: September 15, 2011                                IETF MANET WG
                                                          March 14, 2011
The RFC Editor did in a previous document (NHDP) = request that design-team be listed in the contributors section, and not = in the author's section. If I understood correctly, this was a strong = request, so I suggest that this be reflected in also SMF.
                    Simplified Multicast Forwarding
                        draft-ietf-manet-smf-11

Abstract

   This document describes a Simplified Multicast Forwarding (SMF)
   mechanism that provides basic IP multicast forwarding suitable for
   wireless mesh and mobile ad hoc network (MANET) use.  SMF defines
It may be worth noting in the abstract that the term = "multicast" in this context relates to "manet-wide broadcast", and that = no groups or group-driven broadcast tree pruning is in = scope?
   techniques for multicast duplicate packet =
detection (DPD) to be
   applied in the forwarding process and includes maintenance and
   checking operations for both IPv4 and IPv6 protocol =
use.
It is a bit unclear what "maintenance and = checking operations" are or are for.
  SMF also
   specifies mechanisms for applying reduced relay sets to achieve more
   efficient multicast data distribution within a mesh topology versus
   simple flooding.  The document describes interactions with other
   protocols and multiple deployment approaches. =
"Other protocols" - more specifically, = which?
 Distributed algorithms
   for selecting reduced relay sets and related discussion are provided
   in the Appendices.  Basic issues relating to the operation of
   multicast MANET border routers are discussed but ongoing work remains
   in this area beyond the scope of this document.
<SNIP>
Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 4]
=0C
Internet-Draft                     SMF                        March 2011


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].


2.  Introduction and Scope

   Unicast routing protocol designs for MANET and wireless mesh use
   often apply distributed algorithms to flood routing control plane
   messages within an interior wireless routing domain.  For example,
   algorithms specified within [RFC3626] and [RFC3684] provide
   distributed methods of dynamically electing reduced relay sets that
   attempt to efficiently flood routing control messages while
   maintaining a connected set under dynamic topological conditions.

   In one sense, Simplified Multicast Forwarding (SMF) extends the
"In one sense"? Suggest removing.
   efficient flooding concept to the data forwarding plane.  =
Therefore,
Suggest removing "Therefore,"
   SMF provides an appropriate multicast forwarding =
capability for use
   cases where localized, efficient flooding is considered an effective
   design approach.  The baseline design is intended to provide a basic,
   best effort multicast forwarding capability that is constrained to
   operate within an interior MANET or wireless mesh routing domain.  An
   SMF routing domain is an instance of a SMF routing protocol with
   common policies that is under a single network administration
   authority.  The main design goals of this SMF specification are to
   adapt efficient relay sets in MANET type environments [RFC2501] and
   to define the needed IPv4 and IPv6 multicast duplicate packet
   detection (DPD) mechanisms to support multi-hop, packet forwarding.

2.1.  Terminology

   The following abbreviations are used throughout this document:
















Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 5]
=0C
Internet-Draft                     SMF                        March 2011


            +--------------+---------------------------------+
            | Abbreviation | Definition                      |
            +--------------+---------------------------------+
            | MANET        | Mobile Ad hoc Network           |
            | SMF          | Simplified Multicast Forwarding |
            | CF           | Classical Flooding              |
            | CDS          | Connected Dominating Set        |
            | MPR          | Multi-Point Relay               |
            | S-MPR        | Source-based MPR                |
            | MPR-CDS      | MPR-based CDS                   |
            | E-CDS        | Essential CDS                   |
            | NHDP         | Neighborhood Discovery Protocol |
            | SMF-DPD      | SMF-Duplicate Packet Detection  |
            | I-DPD        | Identification-based DPD        |
            | H-DPD        | Hash-based DPD                  |
            | HAV          | Hash-assist Value               |
            | FIB          | Forwarding Information Base     |
            | TLV          | type-length-value encoding      |
            | DoS          | Denial of Service               |
            +--------------+---------------------------------+
It is a little untraditional to have terminology as a = table, alas, that is not in itself a problem. However, the table simply = "expands acronyms", but doesn't really explain what they mean. "MPR", = "S-MPR", "MPR-CDS" and "E-CDS", for example, may be well understood = within the narrow MANET community, a bit less elsewhere. Suggest either = a somewhat more verbose description, or informative references cited (or = both) ?
3.  Design Overview

   Figure 1 provides an overview of the logical SMF node architecture,
   consisting of "Neighborhood Discovery", "Relay Set Selection" and
   "Forwarding Process" components.  Typically, relay set selection (or
   self-election) occurs based on dynamic input from a neighborhood
   discovery process.  SMF supports the case where neighborhood
   discovery and/or relay set selection information is obtained from a
   coexistent process (e.g., a lower layer mechanism or a unicast
   routing protocol using relay sets).  In some algorithm designs, the
   forwarding decision for a packet can also depend on previous hop or
   incoming interface information.  The asterisks (*) in Figure 1 mark
   the primitives and relationships needed by relay set algorithms
   requiring previous-hop packet forwarding knowledge.
I do not think it quite clear what the = "asterisk-notation" means, at least I had to do a double-read on it. = Would it not be clearer to draw the figure without, and textually = mentioning that not all algorithms necessarily needs all information - = with reference to the algorithm descriptions?
Macker, editor & SMF Design Team  Expires September 15, =
2011    [Page 6]
=0C
Internet-Draft                     SMF                        March 2011


                ______________                _____________
               |              |              |             |
               | Neighborhood |              |  Relay Set  |
               |  Discovery   |------------->|  Selection  |
               |   Protocol   |   neighbor   |  Algorithm  |
               |______________|     info     |_____________|
                      \                              /
                       \                            /
                neighbor\                          /forwarding
                  info*  \      ____________      /  status
                          \    |            |    /
                           `-->| Forwarding |<--'
                               |  Process   |
             ~~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
             incoming packet,                 forwarded packets
             interface id*, and
             previous hop*

                      Figure 1: SMF Node Architecture

   There are certain IP multicast packets, defined later in this
   specification, that are "non-forwardable" and these multicast packets
   will be ignored by the SMF forwarding engine. =
Suggest rephrasing/adding how these multicast packets = are identified? Presumably by their addresses....?
 The SMF forwarding
   engine MAY also work with policies and management interfaces to allow
   additional filtering control over which multicast packets are
   considered for potential SMF forwarding.  This interface would allow
   more refined dynamic forwarding control once such techniques are
   matured for MANET operation.  At present further discussion of
   dynamic control is left to future work.

   Interoperable =
SMF implementations MUST use a common DPD approach and
   be able to process the header options defined in this document for
   IPv6 operation.  We define Classical Flooding (CF), as the simplest
   case of SMF multicast forwarding.  With CF, each SMF router forwards
   each received multicast packet exactly once.  In this case, the need
   for any relay set selection or neighborhood topology information is
   eliminated at the expense of additional network overhead.  In CF
   mode, the SMF-DPD functionality is still required.  While SMF
   supports a CF mode of operation the use of more efficient relay set
   modes is RECOMMENDED to reduce contention and congestion caused by
   unnecessary packet retransmissions [NTSC99].
The above paragraph is = confusing.

It starts by outlining a requirement = for interoperability. It then discusses characteristics of a specific = forwarding algorithm. It is not clear what the relationship between = these two are.

I would actually suggest to have = a top-level section "Requirements for Interoperability" somewhere in the = document, assembling all the different such conditions for two = implementations to have a chance at interoperating. That section would = also be the place to discuss what happens if two "non-interoperable" = SMF-implementations are present in the same routing = domain.

I am, for the record, also somewhat = stylistically against "We define....", and prefer "This document = defines...." - although I recognize that to be probably a matter of = taste  
   An efficient, reduced relay set =
is realized by selecting and
realized -> constructed
   maintaining a subset of all possible routers in a MANET =
routing
   domain.  Known distributed relay set selection algorithms have
   demonstrated the ability to provide and maintain a dynamic connected
   set for forwarding multicast IP packets [MDC04].  A few such relay
   set selection algorithms are described in the Appendices of this



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 7]
=0C
Internet-Draft                     SMF                        March 2011


   document and the basic designs borrow directly from previously
   documented IETF work.  SMF relay set configuration is extensible and
   additional relay set algorithms beyond those specified here can be
   accommodated in future work.

   Determining and maintaining an optimized set of forwarding nodes

Two things here, terminology-wise = (also apply elsewhere in the I-D, but I haven't pointed them all out = explicitly):

o "nodes" or "routers"? We have = used "routers" pretty systematically in most of = the 
recent MANET RFCs, = and after all we are in the RTG area

o = "forwarding nodes" or "relay set" - seems to be the same thing = (if so, use same 
= terminology).....otherwise, explain why the need for different = terms.

   generally requires dynamic =
neighborhood topology information.
   Neighborhood topology discovery functions MAY be externally provided
   by a MANET unicast routing protocol or by using the MANET
   NeighborHood Discovery Protocol (NHDP) [RFC6130] running in
   concurrence with SMF.
Suggest removing = "externally"

Additionally, this specification =
allows
Suggest removing "Additionally,"
   alternative lower layer interfaces (radio router =
interface) to
   provide the necessary neighborhood information to aid in supporting
   more effective relay set election.  Fundamentally, an SMF
   implementation SHOULD provide the ability for multicast forwarding
   state to be dynamically managed per operating network interface.
   Some of the relay state maintenance options and interactions are
   outlined later in Section 7.
This phrase leaves me = a little cold: "Some of the relay state maintenance options and = interactions...." - but not all? Does this mean that I cannot rely = solely on this specification to create an implementation of = SMF?
 This document states specific
   requirements for neighborhood discovery with respect to the
   forwarding process and the relay set selection algorithms described
   herein.  For determining dynamic relay sets in the absence of other
   control interfaces, SMF relies on the MANET NHDP specification to
   assist in IP layer 2-hop neighborhood state discovery and maintenance
   for relay set election.  "SMF_TYPE" and "SMF_NBR_TYPE" Message and
   Address Block, respectfully, TLV structures (per [RFC5444]) are
   defined for use with the NHDP protocol.  It is RECOMMENDED that all
   nodes performing SMF operation in conjunction with NHDP, include
   these TLV types in any NHDP HELLO messages generated.  This
   capability allows for nodes participating in SMF to be explicitly
   identified along with their respective dynamic relay set algorithm.


4.  SMF Applicability
Suggest "SMF Applicability" -> "Applicability = Statement" ?
   Within dynamic wireless routing =
topologies, maintaining traditional
   forwarding trees to support a multicast routing protocol is often not
   as effective as in wired networks due to the reduced reliability and
   increased dynamics of mesh topologies [MGL04] [GM99].  A basic packet
   forwarding service reaching all connected routers running the SMF
   protocol within a localized routing domain may provide a useful group
   communication paradigm for various classes of applications.
   Applications that could take advantage of a simple multicast
could -> can ?
   forwarding =
service include multimedia streaming, interactive group-
   based messaging and applications, peer-to-peer middleware
   multicasting, and multi-hop mobile discovery or registration
   services.  SMF is likely only appropriate for deployment in limited
   dynamic wireless routing domains so that the flooding process can be
   contained.  The limited SMF routing domains are further defined as



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 8]
=0C
Internet-Draft                     SMF                        March 2011


   administratively scoped multicast forwarding domains in Section 9.2.

   Note again that Figure 1 provides a notional architecture for typical
   SMF-capable nodes.  A goal is that simple leaf nodes may also
   participate in multicast traffic transmission and reception with
Here, the use of "node" becomes critical. There = apparently are two kinds "simple leaf nodes" and "other nodes". Are = those what we call "hosts" and "routers", usually? If not, what's the = difference? (And, suggest that it be described in = terminology)
   standard IP network layer =
semantics (e.g., special or unnecessary
   encapsulation of IP packets should be avoided in this case).  It is
   important that SMF deployments in localized edge network settings are
Sure, it is "important" - but is it supported by SMF? = The applicability statement doesn't seem to be the appropriate place to = list design requirements (that should probably be in the "Design = Overview" section?
   able to connect and interoperate =
with existing standard multicast
   protocols operating within more conventional Internet
   infrastructures.  A multicast border router or proxy mechanism MUST
2119-style MUST used in the applicability statement = seems wrong to me. Would suggest stating in this section that "SMF can = interoperate / interact with a fixed-infrastructre IP multicast = routing", and then hive this more detailed discussion off to section = 9?
   be used when deployed alongside more =
fixed-infrastructure IP
   multicast routing such Protocol Independent Multicast (PIM) variants
   [RFC3973] and [RFC4601].  Present experimental SMF implementations
Suggest removing "Present"
   have demonstrated gateway functionality at MANET border =
routers
   operating with existing external IP multicast routing protocols
   [CDHM07],[DHS08],and [DHG09].  SMF may be extended or combined with
   other mechanisms to provide increased reliability and group specific
   filtering, but the details for this are not discussed here.


5.  SMF Packet Processing and Forwarding

   The SMF Packet Processing and Forwarding actions are conducted with
   the following packet handling activities:

   1.  Processing of outbound, locally-generated multicast packets.
   2.  Reception and processing of inbound packets on specific network
       interfaces.

   The purpose of intercepting outbound, locally-generated multicast
   packets is to apply any added packet marking needed to satisfy the
   DPD requirements so that proper forwarding may be conducted.  Note
   that for some system configurations the interception of outbound
   packets for this purpose is not necessary.

   Inbound multicast packets are received by the SMF implementation and
   processed for possible forwarding.  This document does not presently
   support forwarding of directed broadcast addresses [RFC2644]. =
To "Applicability Statement" ?
 SMF
   implementations MUST be capable of forwarding IP multicast packets
   with destination addresses that are not node-local and link-local for
   IPv6 as defined in [RFC4291] and that are not within the local
   network control block as defined by [RFC5771]

1) there's a period (".") missing = after the final citation
2) this is again a design = requirement, not a description of protocol functioning, thus it probably = should be moved to section 3? 
   This will =
help support generic multi-hop multicast application needs
   or to distribute designated multicast traffic ingressing the SMF
   routing domain via border routers.  The multicast addresses to be
   forwarded should be maintained by an a priori list or a dynamic
Probably this would be better in a section called = "Deployment considerations", as it does not specify as such the = functioning of the protocol, but operational = requirements?

Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 9]
=0C
Internet-Draft                     SMF                        March 2011


   forwarding information base (FIB) that MAY interact with future MANET
   dynamic group membership extensions or management functions.  There
   will also be a well-known multicast group for SMF.  This multicast
"will also be"? Suggest rephrasing to "The well-known = SL-MANET-ROUTERS multicast group ...". Actually, suggest writing the = document as-if the group has already been assigned (which it would be = once published as RFC) and hive all requests-to-IANA off to "IANA = Considerations"  
   group is =
specified to contain all routers within an SMF routing
   domain, so that packets transmitted to the multicast address
   associated with the group will be delivered to all connected routers
   running SMF.  Due the mobile nature of a MANET, routers running SMF
   may not be topologically connected at particular times.  For IPv6,
   the multicast address is specified to be "site-local".  =


The name of
   the multicast group is "SL-MANET-ROUTERS".
Suggest = removing this phrase.
 Minimally SMF =
MUST
   forward, as instructed by the relay set selection algorithm, unique
   (non-duplicate) packets received for this well-known group address
   when the TTL or hop limit value in the IP header is greater than 1.
   SMF MUST forward all additional global scope addresses specified
   within the dynamic FIB or configured list as well.  In all cases, the
   following rules MUST be observed for SMF multicast forwarding:

   1.  IP multicast packets with TTL <=3D 1 MUST NOT be forwarded.
   2.  Link local IP multicast packets MUST NOT be forwarded.
   3.  Incoming IP multicast packets with an IP source address matching
       one of those of the local SMF router interface(s) MUST NOT be
       forwarded.
   4.  Received frames with the MAC source address matching any MAC
       address of the routers interfaces MUST NOT be forwarded.
   5.  Received packets for which SMF cannot reasonably ensure temporal
       DPD uniqueness MUST NOT be forwarded.
Probably need an expansion or a reference to where = this is expanded.
   6.  When packets are forwarded, =
TTL or hop limit MUST be decremented
       by one.

   Note that rule #3 is important because over some types of wireless
   interfaces, the originating SMF router may receive re-transmissions
   of its own packets when they are forwarded by adjacent routers.  This
   rule avoids unnecessary retransmission of locally-generated packets
   even when other forwarding decision rules would apply.

   An additional processing rule also needs to be considered based upon
   a potential security threat.  As discussed further in Section 10,
   there may be concern in some SMF deployments that malicious nodes may
"nodes" ....?
   conduct a =
denial-of-service attack by remotely "previewing" (e.g.,
   via a directional receive antenna) packets that an SMF node would be
   forwarding and conduct a "pre-play" attack by transmitting the packet
   before the SMF node would otherwise receive it but with a reduced TTL
   (or Hop Limit) field value.  This form of attack could cause an SMF
   node to create a DPD entry that would block the proper forwarding of
   the valid packet (with correct TTL) through the SMF area.  A
   RECOMMENDED approach to prevent this attack, when it is a concern,
   would be to cache temporal packet TTL values along with the per-
   packet DPD state (hash value(s) and/or identifier as described in



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 10]
=0C
Internet-Draft                     SMF                        March 2011


   Section 6).  Then, if a subsequent matching (with respect to DPD)
   packet arrives with a larger TTL value than the packet that was
   previously forwarded, SMF should forward the new packet and update
   the TTL value cached with corresponding DPD state to the new, larger
   TTL value.  There may be temporal cases where SMF would unnecessarily
   forward some duplicate packets using this approach, but those cases
   are expected to be minimal and acceptable when compared with the
   potential threat of denied service.

It is unclear what the "additional processing rule" then is. =
Is it possible to spell it out and add as rule #7 to the list above?


   Once these criteria
Which = criteria?

<SNIP>
6.1. IPv6 Duplicate Packet Detection This section describes the mechanisms and options for SMF IPv6 DPD. The core IPv6 packet header does not provide any explicit identification header field that can be exploited for I-DPD. The following areas are described to support IPv6 DPD and each is covered in more detail in particular subsections: 1. the hop-by-hop SMF-DPD option header, 2. the use of IPv6 fragment header fields for I-DPD when they exist, 3. the use of IPsec sequencing for I-DPD when a non-fragmented, IPsec header is detected, and 4. an H-DPD approach assisted, as needed, by the SMF-DPD option header.
Suggest actually adding <xref target=3D ..../> = to each of these subsections here.
   SMF MUST =
provide a DPD marking module that can insert the hop-by-hop
   IPv6 header option defined in this section.  This process MUST come
   after any source-based fragmentation that may occur with IPv6.  As
   with IPv4, SMF IPv6 DPD is presently specified to allow either a
   packet hash or header identification method for DPD.  An SMF
   implementation MUST be configured to operate either in H-DPD or I-DPD
   mode and perform the appropriate routines outlined in the following
   sections.

6.1.1.  IPv6 SMF-DPD Header Option

   The base IPv6 packet header does not contain a unique identifier
   suitable for DPD.  This section defines an IPv6 Hop-by-Hop Option



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 12]
=0C
Internet-Draft                     SMF                        March 2011


   [RFC2460] to serve this purpose for IPv6 I-DPD.  Additionally, the
   header option provides a mechanism to guarantee non-collision of hash
   values for different packets when H-DPD is used.

   If this is the only hop-by-hop option present, the optional
   "TaggerId" field (see below) is not included, and the size of the DPD
   packet identifier (sequence number) or hash token is 24 bits or less,
   this will result in the addition of 8 bytes to the IPv6 packet header
   including the "Next Header", "Header Extension Length", SMF-DPD
   option fields, and padding.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     ...              |0|0|0| OptType | Opt. Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |H|  DPD Identifier Option Fields or Hash Assist Value  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Fig. 2 - IPv6 SMF-DPD Hop-by-Hop Header Option

   "Option Type" =3D (Lower 5 bits pending IANA assignment, highest =
order
   MUST be 000).  By having these three bits be zero, this specification
   requires that nodes not recognizing this option type should skip over
   this option and continue processing the header and that the option
   must not change en route [RFC2460].

   "Opt. Data Len" =3D Length of option content (I.e., 1 + =
(<IdType> ?
   (<IdLen> + 1): 0) + Length(DPD ID)).

   "H-bit" =3D a hash indicator bit value identifying DPD marking type. =
0
   =3D=3D sequence-based approach w/ optional taggerId and a tuple-based
   sequence number. 1 =3D=3D indicates a hash assist value (HAV) field
   follows to aid in avoiding hash-based DPD collisions.

   When the "H-bit" is cleared (zero value), the SMF-DPD format to
   support I-DPD operation is specified as shown in Figure 2 and defines
   the extension header in accordance with [RFC2460].













Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 13]
=0C
Internet-Draft                     SMF                        March 2011


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ...              |0|0|0| OptType | Opt. Data Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0|TidTyp|TidLen|             TaggerId (optional) ...           |
       +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |            Identifier  ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: IPv6 SMF-DPD Header Option in I-DPD mode

   The "TidType" is a 3-bit field indicating the presence and type of
   the optional "TaggerId" field.  The optional "TaggerId" is used to
   differentiate multiple ingressing border gateways that may commonly
   apply the SMF-DPD option header to packets from a particular source.

This probably merits at least a = reference to section 9, and some discussion there detailing this = operation a bit more?
   This is =
provided for experimental purposes.  The following table
   lists the valid TaggerId types:
<SNIP>
6.1.2.  IPv6 =
Identification-based DPD

   The following table summarizes the IPv6 I-DPD processing and
   forwarding decision approach.  Within the table '*' indicates an
   ignore field condition.
What is "an ignore field condition" ?










Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 15]
=0C
Internet-Draft                     SMF                        March 2011


   +-------------+-----------+-----------+-----------------------------+
   | IPv6        | IPv6      | IPv6      | SMF IPv6 I-DPD Mode Action  |
   | Fragment    | IPsec     | I-DPD     |                             |
   | Header      | Header    | Header    |                             |
   +-------------+-----------+-----------+-----------------------------+
   | Present     | *         | *         | Use Fragment Header I-DPD   |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Not Present | Present   | *         | Use IPsec Header I-DPD      |
   |             |           |           | Check and Process for       |
   |             |           |           | Forwarding                  |
   | Present     | *         | Present   | Invalid, do not Forward     |
   | Not Present | Present   | Present   | Invalid, do not Forward     |
   | Not Present | Not       | Not       | Add I-DPD Header,and        |
   |             | Present   | Present   | Process for Forwarding      |
   | Not Present | Not       | Present   | Use I-DPD Header Check and  |
   |             | Present   |           | Process for Forwarding      |
   +-------------+-----------+-----------+-----------------------------+

                   Table 2: IPv6 I-DPD Processing Rules
<SNIP>
6.1.3.  IPv6 =
Hash-based DPD

   A default hash-based DPD approach (H-DPD) for use by SMF is specified
   as follows.  An MD5 [RFC1321] hash of the non-mutable header fields,
   options fields, and data content of the IPv6 multicast packet is used
   to produce a 128-bit digest.  The least significant 64 bits of this
1) Someone is likely to say that MD5 = is deprecated;

2) Is the use of MD5 vs. any other = hashing algorithm important? If not, suggest citing
MD5 as an = example (and reserve a field for indicating which hash algorithm is in = use);
= Should be possible when inserting a header option in = IPv6;

3) Suggest discussion of the impact = of hash collisions (security and = performance)?
<SNIP>
6.2.1.  IPv4 Identification-based DPD

   The following table summarizes the IPv4 I-DPD processing approach
   once a packet has passed the basic forwardable criteria described in
   Section 5.  Within the table '*' indicates an ignore field condition.
   DF, MF, Fragment offset correspond to related fields and flags
   defined in [RFC0791].
"ignore field condition" is unclear - what does it = mean?
<SNIP>
6.2.2.  IPv4 Hash-based DPD

   To ensure consistent IPv4 H-DPD operation among SMF nodes, a default
   hashing approach is specified.  This is similar to that specified for
   IPv6, but the H-DPD header option with HAV is not considered.  SMF
   MUST perform an MD5 [RFC1321] hash of the immutable header fields,
   option fields and data content of the IPv4 multicast packet resulting
   in a 128-bit digest.  The least significant 64 bits of this digest is
   used for SMF packet identification.  The approach for calculating the
   hash value SHOULD follow the same guidelines described for
   calculating the Integrity Check Value (ICV) described in [RFC4302]
   with respect to non-mutable fields.  A history of the packet hash
   values SHOULD be maintained in the context of <protocol:srcAddr:
   dstAddr>.  The context for IPv4 is more specific than that of IPv6
   since the SMF-DPD HAV cannot be employed to mitigate hash collisions.

   The MD5 hash is specified at present for consistency and robustness.
   Future approaches and experimentation may discover design tradeoffs
   in hash robustness and efficiency worth considering for future
   revisions of SMF.  This MAY include reducing the packet payload
   length that is processed, determining shorter indexes, or applying a
   more efficient hashing algorithm.
Same comments as to MD5 as above;
7.  Relay Set Selection

7.1.  Non-Reduced Relay Set Forwarding

   SMF implementations MUST support CF as a basic forwarding mechanism
   when reduced relay set information is not available or not selected



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 20]
=0C
Internet-Draft                     SMF                        March 2011


   for operation.  In CF mode, each node transmits a locally generated
   or newly received forwardable packet exactly once.  The DPD
   techniques described in Section 6 are critical to proper operation
   and prevent duplicate packet retransmissions by the same forwarding
   node.

7.2.  Reduced Relay Set Forwarding

   MANET reduced relay sets are often achieved by distributed algorithms
   that can dynamically calculate a topological connected dominating set
   (CDS).

   A goal of SMF is to apply reduced relay sets for more efficient
   multicast dissemination within dynamic topologies.  To accomplish
   this SMF MUST support the ability to modify its multicast packet
   forwarding rules based upon relay set state received dynamically
   during operation.  In this way, SMF forwarding operates effectively
   as neighbor adjacencies or multicast forwarding policies within the
   topology change.

   In early SMF experimental prototyping, the relay set information has
   been derived from coexistent unicast routing control plane traffic
   flooding processes [MDC04].  =46rom this experience, extra pruning
   considerations were sometimes required when utilizing a relay set
   from a separate routing protocol process.  As an example, relay sets
   formed for the unicast control plane flooding MAY include additional
   redundancy that may not be desired for multicast forwarding use
   (e.g., biconnected relay set).

   Here is a recommended criteria list for SMF relay set selection
   algorithm candidates:

   1.  Robustness to topological dynamics and mobility
   2.  Localized election or coordination of any relay sets
   3.  Reasonable minimization of CDS relay set size given above
       constraints
   4.  Heuristic support for preference or election metrics

   Some relay set algorithms meeting these criteria are described in the
   Appendices of this document.  Additional relay set selection
   algorithms may be specified in separate specifications in the future.
   Each Appendix subsection in this document can serve as a template for
   specifying additional relay algorithms.

   Figure 4 depicts a information flow diagram of possible relay set
   control options.  The SMF Relay Set State represents the information
   base that is used by SMF in the forwarding decision process.  The
   relay set control option diagram demonstrates that the SMF relay set



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 21]
=0C
Internet-Draft                     SMF                        March 2011


   state may be determined by fundamentally three different methods:
   independent operation with NHDP [RFC5444] input providing dynamic
   network neighborhood adjacency information that is then used by a
   particular relay set selection, slave operation with an existing
   unicast MANET routing protocol that is capable of providing CDS
   election information that can be used by SMF, and cross layer
   operation that may involve lower layer neighbor or link information.
   Other heuristics to influence and control election can come from
   network management or other interfaces as shown on the right.  Of
   course CF mode, simplifies the control and does not require other
   input but relies solely on DPD.

                       Possible L2 Trigger/Information
                                      |
                                      |
    ______________              ______v_____         __________________
   |    MANET     |            |            |       |                  |
   | Neighborhood |            | Relay Set  |       | Other Heuristics |
   |  Discovery   |----------->| Selection  |<------| =
(Preference,etc) |
   |   Protocol   | neighbor   | Algorithm  |       |  Net Management  |
   |______________|   info     |____________|       |__________________|
          \                              /
           \                            /
    neighbor\                          / Dynamic Relay
      info*  \      ____________      /    Set Status
              \    |    SMF     |    / (State, {neighbor info})
               `-->| Relay Set  |<--'
                   |   State    |
                -->|____________|
               /
              /
    ______________
   |  Coexistent  |
   |    MANET     |
   |   Unicast    |
   |   Process    |
   |______________|

             Figure 4: SMF Reduced Relay Set Information Flow
What does the asterisk next to the left "neighbor = info" mean?

<SNIP>
8.  SMF Neighborhood Discovery Requirements

   This section defines the requirements for use of the MANET
   Neighborhood Discovery Protocol (NHDP) [RFC6130] to support SMF
   operation.  Note that basic CF forwarding requires no neighborhood
   topology knowledge since in this configured mode every SMF node
   relays all traffic.  Supporting more reduced SMF relay set operation
   requires the discovery and maintenance of dynamic neighborhood
   topology information.  The MANET NHDP protocol can be leveraged
leveraged -> used
   provide this =
necessary information, however there are SMF-specific
   requirements for related NHDP use.  This is the case for both
what does "related NHDP use" mean? Related to = what?
   "independent" SMF operation where NHDP is =
being used specifically to
   support SMF or when one NHDP instance is used for both for SMF and a
   coexistent MANET unicast routing protocol.

   NHDP HELLO messages and the resultant neighborhood information base
   are described separately within the NHDP specification.  To
   summarize, the NHDP protocol provides the following basic functions:
NHDP =3D NeighborHood Discovery Protocol. Saying "the = NHDP Protocol" is therefore redundant ("NeighborHood Discovery Protocol = Protocol"). Suggest: "To summarize, NHDP provides the following = ...."
   1.  1-hop neighbor link sensing and =
bidirectionality checks of
       neighbor links,
   2.  2-hop neighborhood discovery including collection of 2-hop
       neighbors and connectivity information,
   3.  Collection and maintenance of the above information across
       multiple interfaces, and
   4.  A method for signaling SMF information throughout the 2-hop
       neighborhood through the use of TLV extensions.

   Appendices (A-C) of this document describe CDS-based relay set
   selection algorithms that can achieve efficient SMF operation, even
   in dynamic, mobile networks and each of the algorithms has been



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 23]
=0C
Internet-Draft                     SMF                        March 2011


   initially experimented within a working SMF prototype [MDDA07].  When
   using these algorithms in conjunction with NHDP, a method verifying
   neighbor SMF operation is required in order to insure correct relay
   set selection.  NHDP along with SMF operation verification provides
   the necessary information required by these algorithms to conduct
   relay set selection.  Verification of SMF operation may be done
   administratively or through the use of the SMF relay algorithms TLVs
   defined in the following subsections.  Use of the SMF relay algorithm
   TLVs is RECOMMENDED when using NHDP for SMF neighborhood discovery.

   The following sub-sections
Suggest "Sections X, Y = and Z"
specify some SMF-specific TLV types
"some" is vague? Does it mean "some, but not all" -- = and, if so, where do I find the rest? Or, should "some" simply be = removed?
   supporting general SMF operation =
or supporting the algorithms
   described in the Appendices.  The Appendices describing several relay
   set algorithms also specify any additional requirements for use with
   NHDP and reference the applicable TLV types as needed.

8.1.  SMF Relay Algorithm TLV Types

   This section specifies TLV types to be used within NHDP messages to
   identify the CDS relay set selection algorithm(s) in use.  Two TLV
   types are defined, one message TLV type and one address TLV type.

8.1.1.  SMF Message TLV Type

   The message TLV type denoted SMF_TYPE is used to identify the
   existence of an SMF instance operating in conjunction with NHDP.
   This message TLV type makes use of the extended type field as defined
   by [RFC5444] to convey the CDS relay set selection algorithm
   currently in use by the SMF message originator.  When NHDP is used to
   support SMF operation, the SMF_TYPE TLV, containing the extended type
   field with the appropriate value, SHOULD be included in NHDP_HELLO
   messages (HELLO messages as defined in [RFC6130].  This allows SMF
   nodes to learn when neighbors are configured to use NHDP for
   information exchange including algorithm type and related algorithm
   information.  This information can be used to take action, such as
   ignoring neighbor information using incompatible algorithms.  It is
   possible that SMF neighbors MAY be configured differently and still
   operate cooperatively, but these cases will vary dependent upon the
   algorithm types designated.

   This document defines the following Message TLV =
type

Which following TLV type? Do you = mean "this documents defines one Message TLV type 'SMF_TYPE', specified = in table 6" ?

 as specified in
   Table 6 conforming to [RFC5444].  The TLV extended type field is used
   to contain the sender's "Relay Algorithm Type".  The interpretation
   of the "value" content of these TLVs is defined per "Relay Algorithm
   Type" and may contain algorithm specific information.






Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 24]
=0C
Internet-Draft                     SMF                        March 2011


          +---------------+----------------+--------------------+
          |               | TLV syntax     | Field Values       |
          +---------------+----------------+--------------------+
          | type          | <tlv-type>     | SMF_TYPE           |
          | extended type | <tlv-type-ext> | =
<relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |
          +---------------+----------------+--------------------+

                       Table 6: SMF Type Message TLV

   In Table 6 <relayAlgorithmId> is an 8-bit field containing a =
number
   0-255 representing the "Relay Algorithm Type" of the originator
   address of the corresponding NHDP message.

   Possible values for the <relayAlgorithmId> are defined in Table =
7.
   The table provides value assignments, future IANA assignment spaces,
   and an experimental space.  The experimental space use MUST NOT
   assume uniqueness and thus should not be used for general
   interoperable deployment prior to official IANA assignment.

   +-------------+--------------------+--------------------------------+
   |  Type Value |    Extended Type   |            Algorithm           |
   |             |        Value       |                                |
   +-------------+--------------------+--------------------------------+
   |   SMF_TYPE  |          0         |               CF               |
   |   SMF_TYPE  |          1         |              S-MPR             |
   |   SMF_TYPE  |          2         |              E-CDS             |
   |   SMF_TYPE  |          3         |             MPR-CDS            |
   |   SMF_TYPE  |        4-127       |  Future Assignment STD action  |
   |   SMF_TYPE  |       128-239      |     No STD action required     |
   |   SMF_TYPE  |       240-255      |       Experimental Space       |
   +-------------+--------------------+--------------------------------+

                 Table 7: SMF Relay Algorithm Type Values
I actually do not think that this belongs here. Table = 7 details the initial assignment of Extended Type Values, which is an = IANA action once the SMF_TYPE has been registered. Hence, I would = suggest that this be moved to the IANA = section.

Second, when a TLV Type is created, = the Extended Type registry is also created by IANA, and needs assignment = policies; there are fairly specific recommendations for how to select = assignment policies for IANA governed registries, = see rfc5226.

Third, I do not understand = the difference between "No STD action required" and "Experimental = space"? Is it such that the former is = "first-come-first-served-free-for-all"? Or, does it mean "expert review, = but not necessarily std. action"?

Fourth, the = intended status of SMF is experimental, yes? If so, is std. action even = possible (std. action means that a std.track RFC is published - which, = likely, would not downref to an exp. RFC)? Recommend section 4.1 of = 5226

   Acceptable =
<length> and <value> fields of an SMF_TYPE TLV are
   dependent on the extended type value (i.e. relay algorithm type).
   The appropriate algorithm type, as conveyed in the =
<tlv-type-ext>
   field, defines the meaning and format of its TLV <value> field. =
 For
   the algorithms defined by this document, see the appropriate appendix
   for the <value> field format.

8.1.2.  SMF Address Block TLV Type

   An address block TLV type, denoted SMF_NBR_TYPE (i.e., SMF neighbor
   relay algorithm) is specified in Table 8.  This TLV enables CDS relay
   algorithm operation and configuration to be shared among 2-hop



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 25]
=0C
Internet-Draft                     SMF                        March 2011


   neighborhoods.  Some relay algorithms require two hop neighbor
   configuration in order to correctly select relay sets.  It is also
   useful when mixed relay algorithm operation is possible, some
   examples of mixed use is outlined in the appendices.

   The message SMF_TYPE TLV and address block SMF_NBR_TYPE TLV types
   share a common format.

          +---------------+----------------+--------------------+
          |               | TLV syntax     | Field Values       |
          +---------------+----------------+--------------------+
          | type          | <tlv-type>     | SMF_NBR_TYPE       |
          | extended type | <tlv-type-ext> | =
<relayAlgorithmId> |
          | length        | <length>       | variable           |
          | value         | <value>        | variable           |
          +---------------+----------------+--------------------+

                    Table 8: SMF Type Address Block TLV

   <relayAlgorithmId> in Table 8 is an 8-bit unsigned integer =
field
   containing a number 0-255 representing the "Relay Algorithm Type"
   value that corresponds to any associated address in the address
   block.  Note that "Relay Algorithm Type" values for 2-hop neighbors
   can be conveyed in a single TLV or multiple value TLVs as described
   in [RFC5444].  It is expected that SMF nodes using NHDP construct
   address blocks with SMF_NBR_TYPE TLVs to advertise "Relay Algorithm
   Type" and to advertise neighbor algorithm values received in SMF_TYPE
   TLVs from those neighbors.

   Again values for the <relayAlgorithmId> are defined in Table 8.

No, they're not. Table 8 simply = describes the TLV structure, does not give values. Do you mean Table = 7
   The interpretation of the "value" field of SMF_NBR_TYPE TLVs is
   defined per "Relay Algorithm Type" and may contain algorithm specific
   information.  See the appropriate appendix for definitions of value
   fields for the algorithms defined by this document.
<SNIP>
9.4.  Multiple =
Border Routers

   An SMF domain might be deployed with multiple participating nodes
   having connectivity to external, fixed-infrastructure networks.
   Allowing multiple nodes to forward multicast traffic to/from the SMF
   routing domain can be beneficial since it can increase reliability,
   and provide better service.  For example, if the SMF routing domain
   were to fragment with different SMF nodes maintaining connectivity to
   different border routers, multicast service could still continue
   successfully.  But, the case of multiple border routers connecting a
   SMF routing domain to external networks presents several challenges
   for SMF:

   1.  Handling duplicate unmarked IPv4 or IPv6 (without IPsec
       encapsulation or DPD option) packets possibly injected by
       multiple border routers.





Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 29]
=0C
Internet-Draft                     SMF                        March 2011


   2.  Source-based relay algorithms handling of duplicate traffic
       injected by multiple border routers.
   3.  Determination of which border router(s) will forward outbound
       multicast traffic.
   4.  Additional challenges with interfaces to exterior multicast
       routing protocols.

   When multiple border routers are present they may be alternatively
   (due to route changes) or simultaneously injecting common traffic
   into the MANET routing region that has not been previously marked for
   SMF-DPD.  Different border routers would not be able to implicitly
   synchronize sequencing of injected traffic since they may not receive
   exactly the same messages due to packet losses.  For IPv6 I-DPD
   operation, the optional "TaggerId" field described for the SMF-DPD
   header option can be used to mitigate this issue. =
As previously indicated, I would recommend adding = some further description here as to how this "tagging" is done. Also, is = this _only_ relevant when there are multiple border routers in the = network?

<SNIP>
11.  IANA =
Considerations

   This document raises multiple IANA Considerations.  These include the
   IPv6 SMF_DPD hop-by-hop Header Extension defined and multiple Type-
   Length-Value (TLV) constructs [RFC5444]) to be used with NHDP
   [RFC6130]operation as needed to support different forms of SMF
   operation.  There is one message TLV type and one address TLV type
   needed to be assigned for SMF purposes as discussed in Section 8.1.

   The value of the IPv6 SMF-DPD Hop-by-Hop Option Type is TBD (to be
   assigned).

   The SL-MANET-ROUTERS multicast address will be registered for both
   IPv4 and IPv6 multicast address spaces.

11.1.  IPv6 SMF-DPD Header Extension

   This document requests IANA assignment of the "SMF_DPD" hop-by-hop
   option type from the IANA "IPv6 Hop-by-Hop Options Option Type"
   registry (see Section 5.5 of [RFC2780]).

   The format of this new option type is described in Section 6.1.1.  A
   portion of the option data content is the taggger identifier type
   "TidType" that provides a context for the "TaggerId" that is
   optionally included to identify the node that added the SMF_DPD
   option to the packet.  This document defines a namespace for IPv6
   SMF_DPD Tagger Identifier Type values:
                        ietf:manet:smf:taggerIdTypes

   The values that can be assigned within the "ietf:manet:smf:
   taggerIdTypes" name-space are numeric indexes in the range [0, 7],
   boundaries included.  All assignment requests are granted on an "IETF
   Consensus" basis as defined in [RFC5226].

   This specification registers Tagger Identification Type values from
   Table 9 in the registry "ietf:manet:smf:taggerIdTypes":



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 32]
=0C
Internet-Draft                     SMF                        March 2011


                   +----------+-------+---------------+
                   | Mnemonic | Value | Reference     |
                   +----------+-------+---------------+
                   |   NULL   |   0   | This document |
                   |  DEFAULT |   1   | This document |
                   |   IPv4   |   2   | This document |
                   |   IPv6   |   3   | This document |
                   |   ExtId  |   7   | This document |
                   +----------+-------+---------------+

                          Table 9: TaggerId Types

11.2.  SMF Type-Length-Value

   This document requests IANA assignment of one message "SMF_TYPE" TLV
   type and one address block "SMF_NBR_TYPE" TLV type from the [RFC6130]
   specific registry space.
Specify which spaces those are from among those in = 6130?
   The common format of these new TLV types is described in Table 6 and
   Table 8.  Furthermore this document defines a namespace for algorithm
   ID types using the extended type TLV value field defined by
   [RFC5444].  Both SMF_TYPE and SMF_NBR_TYPE TLVs use this namespace.

               ietf:manet:packetbb:nhdp:smf:relayAlgorithmID

   The values that can be assigned within the "ietf:manet:packetbb:nhdp:
   smf:relayAlgorithmID" name-space are numeric indexes in the range [0,
   239], boundaries included.  Assignment requests for the [0-127] are
   granted on an "IETF Consensus" basis as defined in [RFC5226].
   Standards action is not required for assignment requests of the range
   [128-239].  Documents requesting relayAlgorithmId values SHOULD
   define value field uses contained by the =
SMF_TYPE:<relayAlgorithmId>
   and SMF_NBR_TYPE:<relayAlgorithmId> full type TLVs.

   This specification registers the following Relay Algorithm ID Type
   values shown in Table 10 in the registry "ietf:manet:packetbb:nhdp:
   smf:relayAlgorithmID

                     +----------+-------+------------+
                     | Mnemonic | Value | Reference  |
                     +----------+-------+------------+
                     | CF       | 0     |            |
                     | S-MPR    | 1     | Appendix B |
                     | E-CDS    | 2     | Appendix A |
                     | MPR-CDS  | 3     | Appendix C |
                     +----------+-------+------------+

                 Table 10: Relay Set Algorithm Type Values
Suggest moving the type-extension description to = here, with proper assignment policies.
<SNIP>
Appendix A.  Essential Connecting Dominating Set (E-CDS) Algorithm

   The "Essential Connected Dominating Set" (E-CDS) algorithm [E-CDS]
   forms a single CDS mesh for the SMF operating region.  It allows



Macker, editor & SMF Design Team  Expires September 15, 2011    =
[Page 36]
=0C
Internet-Draft                     SMF                        March 2011


   nodes to use 2-hop neighborhood topology information to dynamically
   perform relay self election to form a CDS.  Its packet forwarding
   rules are not dependent upon previous hop knowledge.  Additionally,
   E-CDS SMF forwarders can be easily mixed without problems with CF SMF
   forwarders, even those not participating in NHDP.  Another benefit is
   that packets opportunistically received from non-symmetric neighbors
   may be forwarded without compromising flooding efficiency or
   correctness.  Furthermore, multicast sources not participating in
   NHDP may freely inject their traffic and any neighboring E-CDS relays
   will properly forward the traffic.  The E-CDS based relay set
   selection algorithm is based upon the summary within [E-CDS].  E-CDS
   was originally discussed in the context of forming partial
   adjacencies and efficient flooding for MANET OSPF extensions work and
   the core algorithm is applied here for SMF.

   It is RECOMMENDED that the SMF_TYPE:E-CDS message TLV be included in
   NHDP_HELLO messages that are generated by nodes conducting E-CDS SMF
   operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:E-CDS
   address block TLV be used to advertise neighbor nodes that are also
   conducting E-CDS SMF operation.
General comment to all appendices: I believe that it = is inappropriate to use 2119-style language in appendices, as I believe = that appendices default to informative, not normative?
A.1.  E-CDS Relay Set Selection Overview

   The E-CDS relay set selection requires 2-hop neighborhood information
   collected through NHDP or another process.  Relay nodes, in E-CDS SMF
   selection, are "self-elected" using a router identifier (Router ID)

"Relay nodes ..... using a router = identifier (Router ID) and an optional nodal = metric"

So: node-router-router-node = ?
   and an optional nodal metric, referred to =
here as "Router Priority"
   for all 1-hop and 2-hop neighbors.  To ensure proper relay set self-
   election, the Router ID and Router Priority MUST be consistent among
   participating nodes.  It is RECOMMENDED that NHDP be used to share
   Router ID and Router Priority through the use of SMF_TYPE:E-CDS TLVs
   as described in this appendix..  The Router ID is a logical
Appendix followed by two = periods.
<SNIP>
   It is RECOMMENDED that the SMF_TYPE:S-MPR message TLV be included in
   NHDP_HELLO messages that are generated by nodes conducting S-MPR SMF
   operation.  It is also RECOMMENDED that the SMF_NBR_TYPE:S-MPR
   address block TLV be used to specify which neighbor nodes are
   conducting S-MPR SMF operation.
Just latching on to this here, = but....

Isn't it a normative requirement (i.e., = to be stipulated outside of appendices) that this TLV is included for = SMF operation of NHDP?

In general, SHOULD (and, = so, also RECOMMENDED) often should be a MUST - if not, then the = consequences of disregarding the recommendation should be = specified.

Thomas
= --Apple-Mail-1--665678672--