5.  Structure

   This section concerns the properties of the format defined in
   [RFC5444] itself, rather than the properties of protocols using it.

   The elements defined in [RFC5444] have structures that are managed by
   a number of flags fields:

   o  Packet flags field (4 bits, 2 used) that manages the contents of
      the Packet Header.

   o  Message flags field (4 bits, 4 used) that manages the contents of
      the Message Header.

   o  Address Block flags field (8 bits, 4 used) that manages the
      contents of an Address Block.

   o  TLV flags field (8 bits, 5 used) that manages the contents of a
      TLV.

   Note that all of these flags are structural; they specify which
   elements are present or absent, field lengths, or whether a field has
   one or multiple values in it.

   In the current version of [RFC5444], indicated by version number 0 in
   the <version> field of the Packet Header, unused bits in these flags
   fields are stated as "are RESERVED and SHOULD each be cleared ('0')

   on transmission and SHOULD be ignored on reception".  For the
   avoidance of any compatibility issues, with regard to version number
   0, this is updated to "MUST each be cleared ('0') on transmission and
   MUST be ignored on reception".

   If a specification updating [RFC5444] introduces new flags in one of
   the flags fields of a packet, Address Block, or TLV (there being no
   unused flags in the message flags field), the following rules MUST be
   followed:

   o  The version number contained in the <version> field of the Packet
      Header MUST NOT be 0.

   o  The new flag(s) MUST indicate the structure of the corresponding
      packet, Address Block, or TLV.  They MUST NOT be used to indicate
      any other semantics, such as message forwarding behavior.

   An update that would be incompatible with the current specification
   of [RFC5444] SHOULD NOT be created unless there is a pressing reason
   for it that cannot be satisfied using the current specification
   (e.g., by use of a suitable Message TLV or Address Block TLV).

   During the development of [RFC5444] (and since publication thereof),
   some proposals have been made to use these RESERVED flags to specify
   behavior rather than structure, message forwarding in particular.
   These proposals were, after due consideration, not accepted for a
   number of reasons.  These reasons include that message forwarding, in
   particular, is protocol specific; for example, [RFC7181] forwards
   messages using its MPR mechanism rather than a "blind" flooding
   mechanism.  (These proposals were made during the development of
   [RFC5444] when there were still unused message flags.  Later addition
   of a 4-bit Message Address Length field later left no unused message
   flags, but other flags fields still have unused flags.)

6.  Message Efficiency

   The ability to organize addresses into the same or different Address
   Blocks and to change the order of addresses within an Address Block
   (as well as the flexibility of the TLV specification) enables
   avoiding unnecessary repetition of information and can consequently
   generate smaller messages.  There are no algorithms for address
   organization, compression, or for TLV usage in [RFC5444]; any
   algorithms that leave the information content unchanged MAY be used
   when generating a message.  See also Appendix B.

6.1.  Address Block Compression

   [RFC5444] allows the addresses in an Address Block to be compressed.
   A protocol generating a message SHOULD compress addresses as much as
   it can.

   Addresses in an Address Block consist of a Head, a Mid, and a Tail,
   where all addresses in an Address Block have the same Head and Tail
   but different Mids.  Each has a length that is greater than or equal
   to zero, the sum of the lengths being the address length.  (The Mid
   length is deduced from this relationship.)  Compression is possible
   when the Head and/or the Tail have non-zero length.  An additional
   compression is possible when the Tail consists of all zero-valued
   octets.  Expected use cases include IPv4 and IPv6 addresses from
   within the same prefix and that therefore have a common Head, IPv4
   subnets with a common zero-valued Tail, and IPv6 addresses with a
   common Tail representing an interface identifier as well as having a
   possible common Head.  Note that when, for example, IPv4 addresses
   have a common Head, their Tail will usually have length zero.

   For example:

   o  The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest
      efficiency, have a 3-octet Head, a 1-octet Mid, and a 0-octet
      Tail.

   o  The IPv6 addresses 2001:DB8:prefix1:interface and
      2001:DB8:prefix2:interface that use the same interface identifier
      but completely different prefixes (except as noted) would, for
      greatest efficiency, have a 4-octet head, a 4-octet Mid, and an
      8-octet Tail.  (They could have a larger Head and/or Tail and a
      smaller Mid if the prefixes have any octets in common.)

   Putting addresses into a message efficiently also requires
   consideration of the following:

   o  The split of the addresses into Address Blocks.

   o  The order of the addresses within the Address Blocks.

   This split and/or ordering is for efficiency only; it does not
   provide any information.  The split of the addresses affects both the
   address compression and the TLV efficiency (see Section 6.2); the
   order of the addresses within an Address Block affects only the TLV
   efficiency.  However, using more Address Blocks than needed can
   increase the message size due to the overhead of each Address Block
   and the following TLV Block, and/or if additional TLVs are now
   required.

   The order of addresses can be as simple as sorting the addresses, but
   if many addresses have the same TLV Types attached, it might be more
   useful to put these addresses together, either within the same
   Address Block as other addresses or in a separate Address Block.  A
   separate Address Block might also improve address compression, for
   example, if more than one address form is used (such as from
   independent subnets).  An example of the possible use of address
   ordering is a HELLO message from [RFC6130] that could be generated
   with local interface addresses first and neighbor addresses later.
   These could be in separate Address Blocks.

6.2.  TLVs

   When considering TLVs, the main opportunities for creating more
   efficient messages are in Address Block TLVs rather than Message
   TLVs.  The approaches described here apply to each Address Block.

   An Address Block TLV provides attributes for one address or a
   contiguous (as stored in the Address Block) set of addresses (with a
   special case for when this set is of all of the addresses in the
   Address Block).  When associated with more than one address, a TLV
   can be single value (associating the same attribute with each
   address) or multivalue (associating a separate attribute with each
   address).

   The approach that is simplest to implement is to use multivalue TLVs
   that cover all affected addresses.  However, unless care is taken to
   order addresses appropriately, these affected addresses might not all
   be contiguous.  Some approaches to this are the following:

   o  Reorder the addresses.  It is, for example, possible (though not
      straightforward, and beyond the scope of this document to describe
      exactly how) to order all addresses in HELLO message as specified
      in [RFC6130] so that all TLVs used only cover contiguous
      addresses.  This is even possible if the MPR TLV specified in
      OLSRv2 [RFC7181] is added; but it is not possible, in general, if
      the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added.

   o  Allow the TLV to span over addresses that do not need the
      corresponding attribute and use a Value that indicates no
      information; see Section 6.3.

   o  Use more than one TLV.  Note that this can be efficient when the
      TLVs become single-value TLVs.  In a typical case where a
      LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
      enough addresses sorted appropriately, two single-value TLVs can
      be more efficient than one multivalue TLV.  If only one Value is

      involved (such as NHDP in a steady state with LINK_STATUS equal to
      SYMMETRIC in all cases) then one single-value TLV SHOULD always be
      used.

6.3.  TLV Values

   If, for example, an Address Block contains five addresses, the first
   two and the last two requiring Values assigned using a LINK_STATUS
   TLV but the third does not, then this can be indicated using two
   TLVs.  It is, however, more efficient to do this with one multivalue
   LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED
   (as defined in [RFC7188]).  In general, use of UNSPECIFIED Values
   allows use of fewer TLVs and is thus often an efficiency gain;
   however, a long run of consecutive UNSPECIFIED Values (more than the
   overhead of a TLV) can make use of more TLVs more efficient.

   Some other TLVs might need a different approach.  As noted in
   [RFC7188], but implicitly permissible before then, the LINK_METRIC
   TLV (defined in [RFC7181]) has two octet Values whose first four bits
   are flags indicating whether the metric applies in four cases; if
   these are all zero, then the metric does not apply in this case,
   which is thus the equivalent of an UNSPECIFIED Value.

   [RFC7188] requires that protocols that extend [RFC6130] and [RFC7181]
   allow unspecified values in TLVs where applicable; it is here
   RECOMMENDED that all protocols follow that advice.  In particular, it
   is RECOMMENDED that when defining an Address Block TLV with discrete
   Values, an UNSPECIFIED Value is defined with the same value (255),
   and a modified approach should be used where possible for other
   Address Block TLVs (for example, as is done for a LINK_METRIC TLV,
   though not necessarily using that exact approach).

   It might be argued that provision of an unspecified value (of any
   form) to allow an Address Block TLV to cover unaffected addresses is
   not always necessary because addresses can be reordered to avoid
   this.  However, ordering addresses to avoid this for all TLVs that
   might be used is not, in general, possible.

   In addition, [RFC7188] recommends that if a TLV Value (per address
   for an Address Block TLV) has a single-length that does not match the
   defined length for that TLV Type, then the following rules are
   adopted:

   o  If the received single-length is greater than the expected single
      length, then the excess octets MUST be ignored.

   o  If the received single-length is less than the expected single
      length, then the absent octets MUST be considered to have all bits
      cleared (0).

   This specification RECOMMENDS a similar rule for all protocols
   defining new TLVs.

7.  Security Considerations

   This document does not specify a protocol but provides rules and
   recommendations for how to design protocols using [RFC5444], whose
   security considerations apply.

   If the recommendation from Section 4.4.1 is followed, which specifies
   that messages are not modified (except for hop count and hop limit)
   when forwarded, then the security framework for [RFC5444] (specified
   in [RFC7182]) can be used in full.  If that recommendation is not
   followed, then the Packet TLVs from [RFC7182] can be used, but the
   Message TLVs from [RFC7182] cannot be used as intended.

   In either case, a protocol using [RFC5444] MUST document whether it
   is using [RFC7182] and if so, how.

8.  IANA Considerations

   The Expert Review guidelines in [RFC5444] are updated to include the
   general requirement that:

   o  The Designated Expert will consider the limited TLV and
      (especially) Message Type space when considering whether a
      requested allocation is allowed and whether a more efficient
      allocation than that requested is possible.

   IANA has added this document as a reference for the following Mobile
   Ad hoc NETwork (MANET) Parameters registries:

   o  Message Types
   o  Packet TLV Types
   o  Message TLV Types
   o  Address Block TLV Types

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
              Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
              <https://www.rfc-editor.org/info/rfc5444>.

   [RFC5498]  Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
              (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March
              2009, <https://www.rfc-editor.org/info/rfc5498>.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
              April 2014, <https://www.rfc-editor.org/info/rfc7182>.

   [RFC7631]  Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad
              Hoc Network (MANET) Generalized Packet/Message Format",
              RFC 7631, DOI 10.17487/RFC7631, September 2015,
              <https://www.rfc-editor.org/info/rfc7631>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [G9903]    ITU-T, "G.9903 : Narrowband orthogonal frequency division
              multiplexing power line communication transceivers for
              G3-PLC networks", ITU-T Recommendation G.9903, August
              2017.

   [RFC3626]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003,
              <https://www.rfc-editor.org/info/rfc3626>.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              DOI 10.17487/RFC5497, March 2009,
              <https://www.rfc-editor.org/info/rfc5497>.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011,
              <https://www.rfc-editor.org/info/rfc6130>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012,
              <https://www.rfc-editor.org/info/rfc6621>.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, DOI 10.17487/RFC7181, April 2014,
              <https://www.rfc-editor.org/info/rfc7181>.

   [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)
              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014,
              <https://www.rfc-editor.org/info/rfc7183>.

   [RFC7188]  Dearlove, C. and T. Clausen, "Optimized Link State Routing
              Protocol Version 2 (OLSRv2) and MANET Neighborhood
              Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
              DOI 10.17487/RFC7188, April 2014,
              <https://www.rfc-editor.org/info/rfc7188>.

   [RFC7722]  Dearlove, C. and T. Clausen, "Multi-Topology Extension for
              the Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015,
              <https://www.rfc-editor.org/info/rfc7722>.

Appendix A.  Information Representation

   This section describes a conceptual way to consider the information
   in a message.  It can be used as the basis of an approach to parsing
   a message from the information that it contains and to creating a
   message from the information that it is to contain.  However, there
   is no requirement that a protocol does so.  This approach can be used
   either to inform a protocol design or by a protocol (or generic
   parser) implementer.

   A message (excluding the Message Header) can be represented by two,
   possibly multivalued, maps:

   o  Message: (Full Type) -> (length, Value)

   o  Address: (address, Full Type) -> (length, Value)

   These maps (plus a representation of the Message Header) can be the
   basis for a generic representation of information in a message.  Such
   maps can be created by parsing the message or can be constructed
   using the protocol rules for creating a message and later converted
   into the octet form of the message specified in [RFC5444].

   While of course any implementation of software that represents
   software in the above form can specify an Application Programming
   Interface (API) for that software, such an interface is not proposed
   here.  First, a full API would be specific to a programming language.
   Second, even within the above framework, there are alternative
   approaches to such an interface.  For example, and for illustrative
   purposes only, consider the alternative address mappings:

   o  Input: address and Full Type.  Output: list of (length, Value)
      pairs.  Note that for most Full Types, it will be known in advance
      that this list will have a length of zero or one.  The list of
      addresses that can be used as inputs with non-empty output would
      need to be provided as a separate output.

   o  Input: Full Type.  Output: list of (address, length, Value)
      triples.  As this list length can be significant, a possible
      output will be of one or two iterators that will allow iterating
      through that list.  (One iterator that can detect the end of the
      list or a pair of iterators specifying a range.)

   Additional differences in the interface might relate to, for example,
   the ordering of output lists.

Appendix B.  Automation

   There is scope for creating a protocol-independent optimizer for
   [RFC5444] messages that performs appropriate address re-organization
   (ordering and Address Block separation) and TLV changes (of number,
   of being single value or multivalue, and use of unspecified values)
   to create more compact messages.  The possible gain depends on the
   efficiency of the original message creation and the specific details
   of the message.  Note that this process cannot be TLV Type
   independent; for example, a LINK_METRIC TLV has a more complicated
   Value structure than a LINK_STATUS TLV does if using UNSPECIFIED
   Values.

   Such a protocol-independent optimizer MAY be used by the router
   generating a message but MUST NOT be used on a message that is
   forwarded unchanged by a router.

Acknowledgments

   The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for
   their contributions as authors of RFC 5444.

Authors' Addresses

   Thomas Clausen
   Ecole Polytechnique
   91128 Palaiseau Cedex
   France

   Phone: +33-6-6058-9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org


   Christopher Dearlove
   BAE Systems Applied Intelligence Laboratories
   West Hanningfield Road
   Great Baddow, Chelmsford
   United Kingdom

   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com


   Ulrich Herberg

   Email: ulrich@herberg.name
   URI:   http://www.herberg.name


   Henning Rogge
   Fraunhofer FKIE
   Fraunhofer Strasse 20
   53343 Wachtberg
   Germany

   Email: henning.rogge@fkie.fraunhofer.de