Re: [manet] packetbb update idea

Having protocols (other than SMF) is a possible area for future work. But has absolutely nothing to do with any updates to RFC 5444.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 3300 467500  |  E: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 07 July 2017 11:56
To: Justin Dean
Cc: manet@ietf.org
Subject: Re: [manet] packetbb update idea

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hi Justin,

I thank you for this issue, yes we need to look into more issues of manet-routing specially multicast. In MANET we done only simple multicast using packetbb, but does packetbb solve most problems of Multicast Routing in MANETs? IMO it needs update for that.

AB

On Mon, Jul 3, 2017 at 7:29 PM, Justin Dean <bebemaster@gmail.com<mailto:bebemaster@gmail.com>> 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.
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

_______________________________________________
manet mailing list
manet@ietf.org<mailto: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.
********************************************************************