[manet] packetbb update idea

Justin Dean <bebemaster@gmail.com> Mon, 03 July 2017 17:29 UTC

Return-Path: <bebemaster@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BF7131449 for <manet@ietfa.amsl.com>; Mon, 3 Jul 2017 10:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F55mdsxvaN22 for <manet@ietfa.amsl.com>; Mon, 3 Jul 2017 10:29:14 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EE2129B77 for <manet@ietf.org>; Mon, 3 Jul 2017 10:29:14 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id v202so90471603itb.0 for <manet@ietf.org>; Mon, 03 Jul 2017 10:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nwUbQ2a8521AihWdJrki3UANQbc3faLFm3UYhWYMsic=; b=P7QUjydCP2NlKOceXkf06joJ8GpWn8ynMXVWz8+t6OJ+gUmOPB/eqWaFke8NUUX8Tl ylGstVM3SKdjWoL1g1hF0dvyPor/NUhBZlmUaBdmIMIHqBaMnggbtZ4qfFNSb/WVDCyq Bx9jPrSX6BLuRtK+Ku41ePUQvhw+RPc4EuO62eFlgECMXsJjpuwrscADILil7KycEI4P lZd+the/ymZDqbYivRQeSbbdKur2mGHGqPBeB0PcsUEvXNzG9FxrkEJUD9pF7KJjBjw2 FF1e6xegvV/xTCHczASWRIewFqcoOUZfdmEG721L8yRpCKhG+LoNMGo6bYAwZEA/y/XD Vhfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nwUbQ2a8521AihWdJrki3UANQbc3faLFm3UYhWYMsic=; b=QuANndb8AoHugWbmXBsAbqoP7lXU5xdrXrTjzHuIPsAnZFTDg0bTTDIybdFOgxFzFt 89ijvqzJ30Q9BPoL/pIbxy84AzbMPPm4rQoeZWTYs18XgjMh0rkxxy9C3SzK2uycPw4O bzPcyJ206agotvwSiIF86Sb17N37t1jL7tgX55QhzsoyajIf8Y7gjCqP3dhi+e3e6s0i IG3Cx0QyOwUN+B9aWmuM/PzufpSZgRo4qXfLD7hA2+jnfQZJNKjcT68Rs0H7m9jFMunV YGrYGFyfm0QoA35oFQ8LMSmIYBbNE0N5ErkWbYsd4WGIca4uzKB+yul7VYotbYzcFC+s S8Nw==
X-Gm-Message-State: AIVw110mzUIjkqCJqyQPebMwgsBDyXgMkr3jlPWh3xCDTUlZFa6xWb5k ggI67OnXpLPThSJL7R19NlM0pneTGJdaDmw=
X-Received: by 10.36.76.212 with SMTP id a203mr9444764itb.96.1499102953496; Mon, 03 Jul 2017 10:29:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.38.72 with HTTP; Mon, 3 Jul 2017 10:29:13 -0700 (PDT)
From: Justin Dean <bebemaster@gmail.com>
Date: Mon, 03 Jul 2017 13:29:13 -0400
Message-ID: <CA+-pDCcfXm-Vf11FZ+KmAk-ZMYBdTZ-+kPebNkd4KtEa8eEX4A@mail.gmail.com>
To: "manet@ietf.org" <manet@ietf.org>
Content-Type: multipart/alternative; boundary="001a11448b560662fb05536d1bda"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/UJDOujKKZAEq4CkX4tD-42Ifego>
Subject: [manet] packetbb update idea
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jul 2017 17:29:16 -0000

So while trying to encode some information using packetbb for the elastic
multicast stuff we have been working on I've run into a short coming.
RFC5444 allows one to efficiently encode information about addresses and
even pairs of addresses (as long as one of those addresses is the Oaddr)
with the TLV structure and the address block.  It does not allow for easy
encoding about pairs of addresses of which neither is the Oaddr.  After
some thinking on it I think most of what I'd like to be able to do could be
solved by using the RESERVED tlv flag bit number 6 to indicate inclusion of
a single index field <index-opt> which would specify a single address in
the address block.
So the tlv definition would change from
<tlv> := <tlv-type>

                <tlv-flags>
                <tlv-type-ext>?
                (<index-start><index-stop>?)?
                (<length><value>?)?

to

<tlv> := <tlv-type>
                <tlv-flags>
                <tlv-type-ext>?

                <index-opt>?
                (<index-start><index-stop>?)?
                (<length><value>?)?


This would allow one to specify information about pairs of addresses in a
compact way.  In the case of elastic multicast source/destination flow
pairs. Thoughts welcome.

Justin