Re: [manet] packetbb update idea

[Justin Dean <[e-mail]>]

On Mon, Jul 3, 2017 at 1:41 PM, Henning Rogge <[e-mail]> wrote:

> On Mon, Jul 3, 2017 at 7:29 PM, Justin Dean <[e-mail]> wrote:
> > 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.
>
> You mean for things like source-specific routing (having a source- and
> destination prefix for an attached network)?
>
> I remember I did a rough sketch for this (I have implemented in my
> Olsrd2-Implementation) and I was forced to put one of the addresses
> uncompressed into a data TLV.
>
> Yes it could work for that.  I did the same thing when I started to sketch
out a layout that worked with RFC5444.  Having the extra index instead of
including the full address saves a bunch of space when transmitting a lot
of pairwise information. 1 byte instead of 16 when working with ipv6.


> > 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.
>
> IF (not sure it is worth) we add something to RFC5444, I would also
> like to suggest an option in the address block TLVs to refer to the
> originator address as the prefix/postfix part.
>

Hmm.  I could see how that might reduce some overhead although the
originator being optional may make that a little bit tricky.  I'm open to
the idea.

One other thing I think might be nice is an address block block.  It would
be a simple container (or an implied container but I think that could get
ugly) for address blocks so different similar addresses could be compressed
but share an indexing scheme.

>
> Henning
>