Subject: Re: [manet] Ideas about a schema-based compression/decompression for RFC5444

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 24 Jan 2013 09:57:47 +0000

I'm a definite +1 on this.   Having implemented RFC5444 parsers/generators, I can definitely see the improvement schema compression could make.

There are obviously some finer details that need to be thought about, but if you'd like some assistance, Henning, please let me know.

I would imagine a <compressed-message> definition, compatible with RFC5444 <message> definition would be the correct place to start...

This proposal may go a long way to resolve the black/white positional TLV arguments not only for in-progress protocols, but also stop future groups having the same discussions again.

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Rogge
> Sent: 23 January 2013 11:32
> To: [email-masked]
> Subject: [manet] Ideas about a schema-based compression/decompression for
> RFC5444
>
> This is an example for a "schema based compression" I am thinking about.
> I use NHDP without the address part as an example to describe the idea.
>
> This example is not complete, because I still have to work through the
> details of the address block.
>
>
> Schema Number: 42
> -----------------
> Header:
> * Message Type 0
> * Optional Fields: mhashoplimit, mhassequencenumber
> * Address Length: 4
> * Hop Limit 1
>
> Mandatory Message TLVs:
> * TLV type 1
> *-- extension type 0
> *-- value length 1
>
> Optional Message TLVs:
> * TLV type 0:
> *-- extension type 0
> *-- value length 1
>
>
>
> Compression idea
> ----------------
>
> Remove everything from RFC5444 message that can be reconstructed from
> Schema. Use bitfields to describe which optional TLVs are present in
> TLV-block.
>
> The message to be compressed is a normal NHDP message with 4-byte
> addresses, hoplimit 1, sequence number 0x1234, a VALDIITY_TIME TLV with
> value 0x10 and an INTERVAL_TIME TLV with value 0x01.
>
>
>
> Compression
> -----------
>
> The message always starts with the schema number (maybe a two-byte
> schema number would be better to allow versioning?)
>
> # 42
>
> Add compressed msg-size to message.
>
> # xx xx
>
> If the msg-flags and msg-addr-length field is specified in the schema,
> skip them. Otherwise add them to the message
>
> # (none in this example)
>
> Add all optional message header fields that are marked in the flags and
> are not already defined in the schema.
>
> # 12 34 (sequence number value)
>
> Add a bitfield with one bit for each Optional Message TLV. Add another
> bit if TLVs follow that are not present in the Schema.
>
> # 80 ( 1st optional message TLV is present, no "other TLVs")
>
> Add all mandatory and all selected optional TLVs to the message. Leave
> out all fields that can be reconstructed from the Schema.
>
> # 10 (value of VALIDITY-TIME TLV)
> # 01 (value of INTERVAL-TIME TLV)
>
> If there are other TLVs (not described in the schema), add the number of
> bytes needed to describe them and the TLVs itself
>
> # (none in this example)
>
>
>
> Result
> ------
>
> The complete message (without the address block and its TLVs has been
> reduced from
>
> # 00 yy yy 53 01 12 34 (message header)
> # 00 08 (tlv block length)
> # 01 10 01 10 (VALIDITY-TIME 0x10)
> # 00 10 01 01 (INTERVAL-TIME 0x01)
>
> to
>
> # 00 xx xx 12 34 80 10 01
>
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Straße 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:[email-masked] http://www.fkie.fraunhofer.de

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 12:07:05 +0100

+1

AB

On 1/24/13, Taylor, Rick <[email-masked]> wrote:
> I'm a definite +1 on this.   Having implemented RFC5444 parsers/generators,
> I can definitely see the improvement schema compression could make.
>
> There are obviously some finer details that need to be thought about, but if
> you'd like some assistance, Henning, please let me know.
>
> I would imagine a <compressed-message> definition, compatible with RFC5444
> <message> definition would be the correct place to start...
>
> This proposal may go a long way to resolve the black/white positional TLV
> arguments not only for in-progress protocols, but also stop future groups
> having the same discussions again.
>
> Rick Taylor
>
> The information contained within this e-mail and any files attached to this
> e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient only
> and therefore if you wish to disclose the information contained within this
> e-mail or attached files, please contact the sender prior to any such
> disclosure. If you are not the intended recipient, any disclosure, copying
> or distribution is prohibited. Please also contact the sender and inform
> them of the error and delete the e-mail, including any attached files from
> your system. Cassidian Limited, Registered Office : Quadrant House, Celtic
> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>