Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Expires: December 21, 2006 January 29, 2007                                    C. Dearlove
                                         BAE Systems Advanced Technology
                                                                  Centre
                                                                 J. Dean
                                               Naval Research Laboratory
                                                                C. Adjih
                                                      INRIA Rocquencourt
                                                           June 19,
                                                           July 28, 2006

                Generalized MANET Packet/Message Format
                      draft-ietf-manet-packetbb-01
                      draft-ietf-manet-packetbb-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2006. January 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes specifies a generalized multi-message packet format
   which that may be
   used by mobile ad hoc network routing and other protocols.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  5  6
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  6  7
   5.  Signaling Framework  . . . . . . . . . . . . . . . . . . . . .  7  8
     5.1.  Packet Format  . . . . . . . . . . . . . . . . . . . .  Packets  . .  7
       5.1.1.  Padding . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Messages . . . . . . . . . . . . . . . . . . . . . . . . .  9
       5.2.1.  Address Blocks . . . . . . . . . . . . . . . . . . . . 12 11
     5.3.  TLVs and TLV Blocks  . . . . . . . . . . . . . . . . . . . 14 12
       5.3.1.  TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 12
       5.3.2.  Constraints  . . . . . . . . . . . . . . . . . . . . . 17 16
     5.4.  Message Content Fragmentation  . . . . .  Padding  . . . . . . . . . 17
   6.  TLV specification . . . . . . . . . . . . . . . . 16
   6.  TLV specification  . . . . . . 20
     6.1.  Message TLV Specification . . . . . . . . . . . . . . . . 20
     6.2. 17
     6.1.  Address Block TLV Specification  . . . . . . . . . . . . . 21 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25 20
   Appendix A.   Illustrations  . . . . . . . . . . . . . . . . . . . 21
   Appendix A.1. Packet . . . . . . . . . . . . . . . . . . . . . . . 21
   Appendix A.2. Message and Padding  . . . . . . . . . . . . . . . . 23
   Appendix A.3. Message Layout Body . . . . . . . . . . . . . 26 . . . . . . . 25
   Appendix A.1. General Packet Format A.4. Address Block  . . . . . . . . . . . . . . . . . . . 26
   Appendix A.5. TLV Block  . . . . . . . . . . . . . . . . . . . . . 27
   Appendix A.6. TLV  . . . . . . . . . . . . . . . . . . . . . . . . 27
   Appendix B.   Complete Example . . . . . . . . . . . . . . . . . . 30
   Appendix C.   Contributors . . . . . . . . . . . . . . . . . . . . 38 32
   Appendix C. D.   Acknowledgements . . . . . . . . . . . . . . . . . . 39 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 41 35

1.  Introduction

   Signaling in a mobile MANET (mobile ad hoc network network) routing protocol
   consists, mainly, of stating IP addresses and attributes associated to
   with such IP addresses.  Since this is a task common to many such
   protocols, this specification presents a generalized signaling framework, which packet format,
   suitable for signaling.  This format may be employed both by mobile
   ad hoc network routing protocols and by other protocols with similar signaling
   requirements.

   The framework consists of

   This document is a specification of:

   o of a mechanism whereby message types can be specified multi-message packet format.
   Messages encapsulate protocol information (including addresses and
   their attributes), and (regardless are themselves are encapsulated in packets.
   The structure of type, whether known or unknown) can addresses, attributes, messages, and packets is
   specified via regular expressions.  This specification gives the
   syntax, but not the interpretation, of the information carried within
   a packet, other than the header information which may be correctly parsed used to
   control the dissemination of the messages.  Packets are intended to
   be encapsulated by a suitable transport protocol, typically UDP, and
      forwarded;
   carried over IP (IPv4 or IPv6).

   This document specifies:

   o  a generalized multi-message  A packet format, allowing multiple zero or more messages to be contained
      within a single transmission;

   o transmission, and optionally including a packet
      header.

   o  A message format, where a message is composed of a message header
      and a message body,
      with the body.

   o  A message header format containing *all* necessary information to
      allow a node to make forwarding and processing decisions without
      resorting to inspecting and
      processing the message body.  The message  Message header information permits
      single- and multi-hop diffusion whilst
      supporting scope controlled multicast and unicast use of the
      format; message diffusion.

   o  a  A message body structure, encouraging uniform format, containing attributes associated with the
      message parsing,
      regardless or the originator of message body content; the message, as well as blocks of
      addresses with associated attributes.

   o  a mechanism whereby  An address block format, where an address block represents sets of
      addresses can be represented in a compact way
      (address compression); (compressed) form.

   o  an extensibility mechanism whereby arbitrary attributes, through  A generalized type-length-value (TLV) format representing
      attributes.  Multiple TLVs (type-length-value triplets), can be included and associated with a
      packet, a message, an address address, or a set of addresses, while being
      correctly parseable by a generic message parser.

   An important design criterion behind this addresses.

   The specification is to allow
   development of easy parsing logic, even in has been explicitly designed with the face of a flexible
   format.  This implies that, given an incoming control message, a
   single parser is able to process following
   properties in mind:

   Parsing logic - the message independent of type regular expression specification facilitates
      generic, protocol independent, parsing logic.

   Extensibility - packets and
   present, to messages defined by a protocol using this specification, an abstraction of
      specification are extensible through defining new message types
      and new TLVs.  Full backward compatibility can be maintained.

   Efficiency - when reported addresses with associated attributes directly.  The information
   contained in share common bit sequences (e.g.
      prefixes or IPv6 interface identifiers) the message header furthermore address block
      representation allows the recipient node
   to recognize duplicates and make appropriate for a compact representation.

   Separation of forwarding decisions.
   Additionally, the signaling framework and processing - duplicate detection and
      controlled scope message forwarding decisions can be made solely
      using information contained in this specification is
   developed with the objective of minimizing message header, without
      processing the complexity of this
   parser by providing a straightforward message layout. body.

2.  Terminology

   The keywords key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 RFC 2119. [1].

   Additionally, this document uses the following terminology:

   Packet - the top level entity in this specification.  Packets are
      transmitted hop-by-hop and are not forwarded.  A packet contains
      zero or more messages, and may contain a packet header.

   Message - the fundamental entity carrying protocol information, in
      the form of addresses and TLVs.  Messages are transmitted in
      packets, and may be forwarded based on their header information.

   Address - an address of the same type and length as the source IP
      address in the IP datagram carrying the packet.

   TLV - a Type-Length-Value structure.  This is a generic way in which
      an attribute can be represented and correctly parsed, without knowing the content, or understanding
      parser having to understand the type of attribute.

   element - a syntactic entity defined in the attribute by regular expression
      specification, represented using the
      parser.  This allows internal extensibility, i.e. for a protocol
      extension notation <foo>.

   <foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to add arbitrary attributes within a control message.
      represent the value of that field.

   ?  - zero or one occurrences of the preceding element.

   *  - zero or more occurrences of the preceding element.

   +  - one or more occurrences of the preceding element.

   <foo> - An element specified in the parsing of a packet, message or
      other entity.  If <foo> is an 8 or 16 bit field then <foo> is also
      used to represent the value of that field.

   bar - A a variable, usually obtained through calculations based on the
      value(s) of field(s).  Variables are introduced in the
      specification solely as a means to clarify the description.

   address-length - A a variable whose value is the length of an address
      in octets, i.e. it is 4 if using IPv4, or 16 if using IPv6.

3.  Applicability Statement

   This specification describes a generic multi-message packet format,
   for carrying MANET routing protocol signals.  The specification has
   been developed from that used by OLSR [3]. (The Optimized Link State
   Routing Protocol) [4].

   The specification is designed specifically with IP (IPv4/IPv6) in
   mind.  All addresses within a control message are assumed to be of
   the same size, deduced from IP.  In the case of mixed IPv6 and IPv4
   addresses, IPv4 addresses are carried in IPv6 as specified in [2].

   The packets defined by this specification may use any transport
   protocol appropriate to the protocol using this specification.  When
   the diffusion mechanism enabled by this specification is employed,
   UDP may be most appropriate.

   The multi-message package format in this

   This specification is
   characterized by lending itself to low-complexity parsing logic, as
   well as to an efficient parsing particularly appropriate for low-capacity routers.  The header
   information extensible
   protocols.  It offers external extensibility in each message suffices to allow for each message to be
   forwarded (if required) and delivered correctly with regards to the
   message's delivery semantics, without parsing and inspecting the
   message body.

   The specification accommodates two types form of extensibility: "external
   extensibility", whereby new
   message types can be specified and
   (regardless of type) still be correctly forwarded and parsed using types.  It offers internal extensibility in the simple parsing logic, and "internal extensibility", whereby new
   attributes can form of TLVs,
   which may be included in added to existing message types while these can
   still be correctly forwarded and parsed using the simple parsing
   logic. types.

4.  Protocol Overview and Functioning

   This specification does not describe a protocol.  It describes a
   packet format, which MAY may be used by any mobile ad hoc network routing
   or other protocol.

5.  Signaling Framework

   This section provides abstract descriptions syntactical specification of message a packet,
   represented by the element <packet> and packet
   formats.

5.1.  Packet Format

   Messages are carried the elements from which it is
   composed.  The specification is given in a general packet format, allowing
   piggybacking the form of several independent messages regular
   expressions.  Illustrations of specified elements are given in a single packet
   transmission.
   Appendix A.

   The packet format conforms to length of a <packet> is obtained as the following specification: size of the payload of
   the transport protocol employed.

5.1.  Packets

   <packet> is defined by:

       <packet> = {<packet-header><pad-octet>*}?
                  {<message><pad-octet>*}*

   where <message> is defined in Section 5.2, and with <pad-octet>
   conforming to the following specification:

   <pad-octet> is an 8 bit field with all bits cleared ('0').  The use
      of <pad-octet> is detailed defined
   in Section 5.1.1. 5.4.  The packet is parsed until all octets are used.

   <packet-header> is defined by:

       <packet-header> = <zero>
                         <packet-semantics>
                         <packet-seq-number>?
                         <tlv-block>?

   with the elements of <packet-header> conforming to the following
   specification:

   where:

   <zero> is an 8 bit field with all bits cleared ('0').  This field
      serves to identify if that the packet starts with a packet header.

   <packet-semantics> is an 8 bit field, which specifies specifying the composition of
      the packet header:

      bit 0 (pseqnum) indicates, (pnoseqnum): if cleared ('0'), that then the packet header
         contains a <packet-seq-number>.  If set ('1'), then the packet
         header does not include a <packet-seq-number>.

      bit 1 (ptlv) indicates, (ptlv): if cleared ('0'), that then the packet header does not
         include a TLV block.  If set ('1'), then the packet header
         includes a TLV block.

      bits 2-7 2-7: are reserved, RESERVED, and SHOULD MUST each be cleared ('0'). ('0') to be in
         conformance with this version of the specification.

   <packet-seq-number> is omitted if the pseqnum pnoseqnum bit is set ('1'),
      otherwise it is a 16 bit field, which specifies specifying a packet sequence number.  If used, a separate packet sequence number MUST be
      maintained for each transmitting interface.  Each packet sequence
      number MUST be incremented by one each time a packet, as defined
      in this document and which includes the packet sequence number, is
      transmitted over this interface.

   <tlv-block> is omitted if the ptlv bit is cleared ('0'), otherwise it and is a TLV block as specified
      otherwise defined in Section 5.3.

   Note that since the message type zero is reserved (see Section 7),
   the presence or absence of a packet header can be determined by
   inspecting the first octet of the packet.

5.1.1.  Padding

   Packet headers and messages can be padded to ensure 32 bit alignment
   of each

5.2.  Messages

   Information is carried through messages.  Messages contain:

   o  A message contained within the packet.

5.1.1.1.  Packet Header Padding

   The packet header specification in Section 5.1 ensures header.

   o  A message TLV block that a packet
   header consists of contains zero or more TLVs, associated
      with the whole message.

   o  Zero or more address blocks, each containing one or more
      addresses.

   o  A TLV block, containing zero or more TLVs, following each address
      block.

   <message> is defined by:

       <message>         = <msg-header>
                           <tlv-block>
                           {<addr-block><tlv-block>}*

       <msg-header>      = <msg-type>
                           <msg-semantics>
                           <msg-size>
                           <msg-header-info>

       <msg-header-info> = <originator-address>?
                           <hop-limit>?
                           <hop-count>?
                           <msg-seq-number>?

   where:

   <tlv-block> is defined in Section 5.3.

   <addr-block> is defined in Section 5.2.1.

   <msg-type> is an integral number 8 bit field, specifying the type of octets, message.  A type
      with all defined
   syntactical entities (<zero>, <packet-semantics>, <packet-seq-
   number>, <tlv-block>) being octet-aligned. bits cleared ('0') MUST NOT be used.  The first <message> two most
      significant bits have the following semantics:

      bit 7 (msguser): message types with this bit cleared ('0') are
         defined in a packet this specification or can be 32 allocated via standards
         action.  Message types with this bit aligned by adding the
   appropriate number of <pad-octet>s subsequent to set ('1') are reserved for
         private/local use.

      bit 6 (msgprot): for message types with the <packet-header>.

   The number of <pad-octet>s required to achieve msg-user bit cleared
         ('0'), this 32 bit alignment
   is calculated as specifies, if cleared ('0'), that the smallest number which, when added message
         type is protocol independent, i.e. is not specific to any one
         protocol, or, if set ('1'), that the size of
   the packet header <tlv-block> (if any) and the size of message type is specific
         to the <packet-
   seq-number> (if any) and protocol for which it is defined.

   <msg-semantics> is an 8 bit field, specifying the size interpretation of
      the fixed part remainder of the header
   (the <zero> message header:

      bit 0 (noorig): if cleared ('0'), then <originator-address> and <packet-semantics> fields, which
         <msg-seq-number> are each one octet
   long) produces an integer multiple of 4.

   If the <packet-header> contains a <packet-seq-number> included in <msg-header-info>.  If set
         ('1'), then <originator-address> and no <tlv-
   block>, (i.e. <msg-seq-number> are not
         included in <msg-header-info>; this reduced message header does
         not provide for duplicate suppression.

      bit 1 (nohops): if both the pseqnum cleared ('0'), then <hop-limit> and ptlv bits <hop-count>
         are cleared) then
   there SHOULD NOT be any <pad-octets> subsequent to included in the <packet-
   header>, since <msg-header-info>.  If set ('1'), then the <packet-header> has length exactly 4 octets
         <hop-limit> and the first <message> is then already 32 bit aligned.

   There is no need to indicate if padding is <hop-count> are not included subsequent to the
   packet header: in the first octet of a <msg-
         header-info>; this reduced message (see Section 5.2 cannot
   be zero.  Thus, if after processing the packet header a recipient
   reads an octet with all bits does not provide for
         scope-delimited forwarding.

      bit 2 (typedep): if cleared ('0'), this read octet is
   padding.

5.1.1.2.  Message Padding

   The message specification in Section 5.2 ensures that a then the message
   consists of an integral sequence
         number of octets, with all defined
   syntactical entities (<msg-header>, <address-block>, <tlv> etc.)
   being octet-aligned.

   The first message can be 32 bit aligned by using packet header
   padding, as described in Section 5.1.1.1.  Subsequent messages (and,
   hence, also the <originator-address>, if any), can be 32 bit aligned
   by adding message is type-independent.  If set ('1'), then
         the appropriate message sequence number of <pad-octet>s subsequent to each
   message.  (When added to contained in the last message this instead ensures that
   the overall packet is type
         dependent (the message originator maintains a multiple of 32 bits in length.)

   The sequence number of <pad-octet>s required
         specific to achieve 32 <msg-type>).  This bit alignment of
   the end of message (and hence the start of the next, MUST be cleared ('0') if any),
   assuming that the start
         noorig bit is set ('1').

      bits 3-7: are RESERVED and MUST each be cleared ('0') to be in
         conformance with this version of the message specification.

   <msg-size> is 32 a 16 bit aligned, is
   calculated as field, specifying the smallest number which when added to <msg-size>
   produces a multiple size of 4.

   There the <message>,
      counted in octets.

   <originator-address> is no need an identifier of length equal to indicate if padding is included subsequent address-
      length, which serves to a
   message: uniquely identify the first octet node that originated
      the message.

   <hop-limit> is an 8 bit field, which contains the maximum number of
      hops a message (see Section 5.2) cannot should be
   zero.  Thus if after processing further transmitted.

   <hop-count> is an 8 bit field, which contains the number of hops a
      message has traveled.

   <msg-seq-number> is a recipient reads any
   octets with all bits cleared ('0'), these read octets are padding.
   The <msg-size> does not include padding. 16 bit field, which contains a unique number,
      generated by the originator node.  The padding after <originator-address>, <msg-
      seq-number>, and, if the typedep bit in the <msg-semantics> field
      is set, the <msg-type> of a message may be freely changed when a serves to uniquely identify
      the message is
   forwarded without affecting in the message.

5.2.  Messages

   Information network.

5.2.1.  Address Blocks

   An address is carried through "messages".  Messages may contain:

   o  zero or more TLVs, associated with the whole message;

   o specified as a sequence of octets of the form head:mid:
   tail.  An address block is an ordered set of addresses about which sharing the originating node wishes to
      convey information.  These addresses MAY be divided into one or
      more address blocks;

   o  zero or more TLVs following each address block.  These are
      explained in more detail in Section 5.3.1
   same head and convey information
      about tail, and having individual mids.

   <address block> is defined by:

       <address-block> = <num-addr>
                         <head-octet>
                         <head>?
                         <tail-octet>?
                         <tail>?
                         <mid>*

   where:

   <num-addr> is an 8 bit field containing the number of addresses
      represented in that the address block.

   A message also contains a message header, block, which can MUST NOT be parsed without
   examining the remainder of the packet, and which contains information
   sufficient to allow the recipient to:

   o  recognize duplicate messages;

   o  determine considerations for forwarding;

   o  manage controlled-scope diffusion of messages.

   Message content MAY (e.g. due to size limitations) be fragmented.
   Each fragment is transmitted such that it makes up a syntactically
   correct message (i.e. all headers are set as if each fragment is a
   message in its own right, and each message contains all necessary
   message TLVs).  Content fragmentation zero.

   <head-octet> is detailed in Section 5.4.

   A message has an 8 bit field, where:

      bits 0-6: contain the following general layout:

       <message>         = <msg-header>
                           <tlv-block>
                           {<addr-block><tlv-block>}*

       <msg-header>      = <msg-type>
                           <msg-semantics>
                           <msg-size>
                           <msg-header-info>

       <msg-header-info> = <originator-address>?
                           <hop-limit>?
                           <hop-count>?
                           <msg-seq-number>?

   The elements length of <msg-header-info> are included according to the flags
   in <msg-semantics> as described below. head.  The elements used above conform to corresponding
         variable head-length is calculated by:

         head-length = <head-octet> & 127

      bit 7 (notail): if cleared ('0') then the following specification:

   <tlv-block> address block contains a
         <tail-octet>.  If set ('1') then no <tail-octet> is as specified in Section 5.3

   <addr-block> included.

   <head> is omitted if head-length == 0, otherwise it is a block field of addresses, with which the originator
      head-length leftmost octets of all the message has a special relationship, specific to addresses.

   <tail-octet> is omitted if the protocol
      using this specification.  Address blocks are specified in
      Section 5.2.1;

   <msg-type> notail bit is set ('1'), otherwise it
      is an 8 bit field, which specifies where:

      bits 0-6: contain the type length of message.  A
      type with all bits cleared ('0') MUST NOT be used.  The two most
      significant bits are allocated with the following semantics: tail.  The corresponding
         variable tail-length is calculated by:

         tail-length = <tail-octet> & 127

      bit 7 (msg-user): message types with this bit cleared ('0') are
         defined in this specification or can be allocated via standards
         action.  Message types with this bit set ('1') are reserved for
         private/local use.

      bit 6 (msg-protocol): for message types with the msg-user bit
         cleared ('0'), this bit specifies, if (zerotail): if cleared ('0'), that then a <tail> is included.  If
         set ('1') then no <tail> is included, and the
         message type tail-length
         rightmost octets of each address in the block are zero-valued.

      If the <tail-octet> is protocol independent, i.e. omitted then tail-length = 0.

   <tail> is not specific to
         any one protocol, or, omitted if set ('1'), that tail-length == 0 or the message type zerotail bit is
         specific to the protocol for which set
      ('1'), otherwise it is defined.

   <msg-semantics> is an 8 bit field, which specifies the interpretation a field of the remainder head-length leftmost octets
      of all the message header and the processing addresses.

   mid-length is a variable, which
      can MUST be undertaken only parsing the message header:

      bit 0 (noorig): indicates, non-negative, calculated by:

         mid-length = address-length - head-length - tail-length

   <mid> is omitted if cleared ('0') that mid-length == 0, otherwise each <mid> is a field
      of length mid-length octets, representing the elements
         <originator-address> and <msg-seq-number> in mid of the <msg-header-
         info> be included, as specified
      corresponding address in the above.  If set ('1'), a
         reduced header which does not include <originator-address> address block.

5.3.  TLVs and
         <msg-seq-number> TLV Blocks

   A TLV is defined by:

       <tlv-block>       = <tlv-length>
                           <tlv>*

   where:

   <tlv-length> is used; this reduced header does not provide
         provisions for duplicate suppression;

      bit 1 (nohops): indicates, if cleared ('0') that the elements
         <hop-limit> and <hop-count> in the <msg-header-info> be
         included, as specified in the above.  If set ('1'), a reduced
         header 16 bit field, which does not include contains the elements <hop-limit> <hop-
         count> from total length (in
      octets) of the <msg-header-info> immediately following <tlv>s.

   <tlv> is used; this reduced header
         does not provide provisions for scope-delimited forwarding;

      bit 2 (typedep): indicates, if cleared ('0'), that the defined in Section 5.3.1.

5.3.1.  TLVs

   There are three kinds of TLV, each represented by an element <tlv>:

   o  A packet TLV, included in a packet header.

   o  A message
         sequence number TLV, included in the a message is type-independent.  If set
         ('1'), before all address blocks.

   o  An address block TLV, included in a TLV block following an address
      block.  An address block TLV applies to:

      *  all addresses in the message address block; OR

      *  any continuous sequence number contained of addresses in the message address block; OR

      *  a single address in the address block.

   <tlv> is
         type dependent, i.e. defined by:

       <tlv> = <tlv-type>
               <tlv-semantics>
               <index-start>?
               <index-stop>?
               <length>?
               <value>?

   where:

   <tlv-type> is an 8 bit field, specifying the source type of the message maintains a
         sequence number separately for the type indicated in TLV.  The
      two most significant bits have the <msg-
         type> field; following semantics:

      bit 7 (tlvuser): TLV types with this bit SHALL be cleared ('0') are defined
         in this specification or can be allocated via standards action.
         TLV types with this bit set ('1') are reserved for private/
         local use.

      bit 6 (tlvprot): for TLV types with the tlv-user bit cleared
         ('0'), this bit specifies, if there cleared ('0'), that the TLV type
         is no
         message sequence number, protocol independent, i.e. is not specific to any one
         protocol, or, if set ('1'), that the noorig bit TLV type is set;

      bits 3-7: are RESERVED and SHALL each be cleared ('0') specific to be in
         conformance with this version of
         the specification.

   <msg-size> protocol for which it is a 16 defined.

   <tlv-semantics> is an 8 bit field, which specifies field specifying the size interpretation of
      the <msg-
      header> and the following <msg-body>, counted in octets;

   <originator-address> is the address remainder of an interface of the node,
      which originated the message.  Its length is equal TLV:

      bit 0 (extended) and bit 1 (novalue): must not both be set ('1').
         Otherwise, they are interpreted according to address- Table 1.

           +----------+---------+--------------+--------------+
           | extended | novalue |    length octets.  Each node SHOULD select one of its interface
      addresses as its "originator address"    |     value    |
           +----------+---------+--------------+--------------+
           |     0    |    0    |    8 bits    |   included   |
           |          |         |              |              |
           |     0    |    1    | not included | not included |
           |          |         |              |              |
           |     1    |    0    |    16 bits   |   included   |
           +----------+---------+--------------+--------------+

                                     Table 1

      bit 2 (noindex) and MUST utilize this
      address consistently as the <originator address> in all messages
      it generates which include bit 3 (singleindex): must not both be set
         ('1').  Otherwise, they are interpreted according to Table 2.

         +---------+-------------+---------------+--------------+
         | noindex | singleindex | <index-start> | <index-stop> |
         +---------+-------------+---------------+--------------+
         |    0    |      0      |    included   |   included   |
         |         |             |               |              |
         |    0    |      1      |    included   | not included |
         |         |             |               |              |
         |    1    |      0      |  not included | not included |
         +---------+-------------+---------------+--------------+

                                     Table 2

      bit 4 (multivalue): this field.  Note that bit serves to specify how the originator
      address value field
         is distinct from the IP source address, and that the same
      originator address interpreted as specified below.  This bit MUST be used regardless of which interface a cleared
         ('0') for packet or message is transmitted on.  Also note that TLVs, if a message the singleindex bit is
      retransmitted set
         ('1'), or if the originator address novalue bit is set ('1').

      bits 5-7: are RESERVED and MUST NOT each be changed;

   <hop-limit> is cleared ('0') to be in
         accordance with this version of the specification.

   <index-start> and <index-stop> are each an 8 bit field, which contains the maximum number of
      hops a message will be transmitted.  Before a message interpreted
      as follows:

      index-start and index-stop are variables, defined according to
         Table 3.  The variable end-index is
      retransmitted, the hop-limit MUST be decremented by 1.  When a
      node receives a calculated as follows:

         +  For message with a hop-limit equal to and packet TLVs:

            -  end-index = 0 or 1, the
      message MUST NOT be retransmitted under any circumstances.
      Normally, a node will not receive a message with a hop-limit of
         +  For address block TLVs:

            -  end-index = <num-addr> - 1

         +---------+-------------+---------------+---------------+
         | noindex | singleindex | index-start = |  index-stop = |
         +---------+-------------+---------------+---------------+
         |    0
      (note that this hop-limit is distinct    |      0      | <index-start> |  <index-stop> |
         |         |             |               |               |
         |    0    |      1      | <index-start> | <index-start> |
         |         |             |               |               |
         |    1    |      0      |       0       |   end-index   |
         +---------+-------------+---------------+---------------+

                                     Table 3

         For an address block TLV, the TLV applies to the addresses from
         position index-start to position index-stop (inclusive) in the IPv6 hop-limit);

   <hop-count>
         address block.

      number-values is an a variable, calculated by:

            number-values = index-stop - index-start + 1

   <length> is omitted or is a 8 or 16 bit field, which contains field according to Table 1.
      If the number of hops a
      message has traveled.  Before a message multivalue bit is retransmitted, the hop-
      count set ('1') then <length> MUST be incremented by 1.  Initially, this hop-count SHOULD
      be set to 0 by the originator an
      integral multiple of number-values, and the message;

   <msg-seq-number> variable single-length
      is a 16 bit field, which contains a unique number,
      generated by the originator node.  The originator-address, msg-
      seq-number and, calculated by:

         single-length = <length> / number-values

      if the typedep multivalue bit in the <msg-semantics> field is
      set, cleared ('0'), the <msg-type> of variable single-length
      is defined by:

         single-length = <length>

   <value> if present (see Table 1), this is a message serves to uniquely identify the
      message in the network (allowing, among other things, duplicate
      elimination).

5.2.1.  Address Blocks

   An address block represents a set of addresses in a compact and
   simple form.  Assuming that an address can be specified as a sequence
   of bits field of the form 'head:mid:tail', then length <length>
      octets.  In an address block TLV, <value> is a set
   of associated with the
      addresses sharing from index-start to index-stop, inclusive.  If the same 'head' and 'tail' and having different
   'mids'.  (The case where
      multivalue bit is cleared ('0') then the 'tail' whole of this field is empty
      associated with each of the indicated addresses.  If the
      multivalue bit is treated specially, as set ('1') then this field is divided equally
      into number-values fields, each of length single-length octets and
      these are associated, in order, with the case where indicated addresses.

5.3.2.  Constraints

   TLVs in the 'tail' consists same tlv block MUST be sorted in ascending TLV type
   order.

   Two or more TLVs of zero-valued octets, the
   latter is particularly appropriate when used same type associated with a TLV indicating a
   prefix length, see Section 6.2.)

   Specifically, an the same address
   block conforms to MUST NOT both cover any address.

   TLVs of the following
   specification:

       <address-block> = <num-addr>
                         <head-octet>
                         <head>?
                         <tail-octet>?
                         <tail>?
                         <mid>* same type associated with the elements defined thus:

   <num-addr> is an 8 bit field containing the number of addresses
      represented in the same address block, which block MUST NOT be zero.  It is
      equal
   sorted in ascending index-start order.

5.4.  Padding

   Packet headers and messages can be padded to the number ensure 32 bit alignment
   of <mid>s following (except when, as defined
      below, mid-length == 0 each message contained within the packet and no <mid>s of the overall packet
   length.

   All syntactical elements are required);

   <head-octet> is an 8 bit field, where:

      bits 0-6: contain the length integer multiple of octets, hence
   padding can be accomplished by inserting an integer number of <pad-
   octets> after the <head>, if any.  The
         corresponding variable head-length is calculated by:

         head-length = <head-octet> & 127

      bit 7 (notail): indicates, if cleared ('0'), that the address
         block contains a <tail-octet> (see below), if set ('1') that no
         <tail-octet> is included;

   <head> is omitted if head-length == 0, otherwise it is a field of
      head-length octets which contains the leftmost octets which the
      addresses in the block have in common (it SHOULD contain the
      longest such sequence);

   <tail-octet> is omitted if the notail bit is set ('1'), otherwise it
      is an 8 bit field, where:

      bits 0-6: contain the length of the <tail>, if any, or the
         equivalent number of zero-valued tail octets.  The
         corresponding variable tail-length is calculated by:

         tail-length = <tail-octet> & 127

      bit 7 (zerotail): indicates, if cleared ('0'), that a <tail> (see
         below) is included, if set ('1') that no <tail> is included,
         and that the tail-length rightmost octets of each address in
         the block are zero-valued;

      If the <tail-octet> is omitted then tail-length = 0.

   <tail> is omitted if tail-length == 0 or the zerotail bit is set
      ('1'), otherwise it is a field of length tail-length octets which
      contains the rightmost octets which the addresses in the block
      have in common (it SHOULD contain the longest such sequence in
      this case);

      If tail-length != 0 and the zerotail bit is set ('1') then all the
      addresses in the block have tail-length zero-valued rightmost
      octets (tail-length SHOULD be the largest such number in this
      case);
   mid-length is a variable, calculated by:

      mid-length = address-length - head-length - tail-length

      mid-length MUST be non-negative.

   <mid> is omitted if mid-length == 0 (in which case all addresses in
      the block are the same), otherwise each <mid> is a field of length
      mid-length octets, representing the 'mid' of the corresponding
      address in the address block.

   This representation aims at providing a flexible, yet compact, way of
   representing sets of addresses.

5.3.  TLVs and TLV Blocks

   A TLV block has the following general layout:

       <tlv-block>       = <tlv-length>
                           <tlv>*

   with the elements defined thus:

   <tlv-length> is a 16 bit field, which contains the total length (in
      octets) of the immediately following TLV(s).  It does not include
      its own length, thus if no TLVs follow, this field contains zero;

   <tlv> is a TLV, providing information regarding the entire packet or
      message or the address block which it follows.  TLVs are specified
      in Section 5.3.1;

5.3.1.  TLVs

   A TLV is a carrier of information, relative to a packet, to a message
   or to addresses in an address block.

   A TLV associated with an address block specifies some attribute(s),
   which are associated with address(es) in the address-block.  In order
   to provide the largest amount of flexibility to benefit from address
   aggregation as described in Section 5.2.1, a TLV associated to an
   address block can apply to:

   o  all addresses in the address block;

   o  any continuous sequence of addresses in the address block;

   o  a single address in the address block.

   All TLVs conform to the following specification:

       <tlv> = <tlv-type>
               <tlv-semantics>
               <index-start>?
               <index-stop>?
               <length>?
               <value>?

   where the elements are defined thus:

   <tlv-type> is an 8 bit field, which specifies the type of the TLV.
      The two most significant bits are allocated with the following
      semantics:

      bit 7 (tlv-user): TLV types with this bit cleared ('0') are
         defined in this specification or can be allocated via standards
         action.  TLV types with this bit set ('1') are reserved for
         private/local use.

      bit 6 (msg-protocol): for TLV types with the tlv-user bit cleared
         ('0'), this bit specifies, if cleared ('0'), that the TLV type
         is protocol independent, i.e. is not specific to any one
         protocol, or, if set ('1'), that the TLV type is specific to
         the protocol for which it is defined.

   <tlv-semantics> is an 8 bit field which specifies the semantics of
      the TLV according to the following:

      bit 0 (novalue): if cleared ('0') contains <length> and <value>
         elements.  TLVs with this bit set ('1') contains no <length> or
         <value> elements - the TLV type carries all the information
         needed.

      bit 1 (extended): if cleared ('0'), the size of the length field
         is 8 bits.  If set ('1'), the size of the length field is 16
         bits.  This bit MUST be cleared ('0') if the novalue bit is set
         ('1').

      bit 2 (noindex): if cleared ('0'), the <index-start> and <index-
         stop> elements are included.  If set ('1'), the <index-start>
         and <index-stop> elements are not included.  This bit MUST be
         set for packet or message TLVs.  If this bit is set ('1') for
         address block TLVs, the TLV applies to all addresses in the
         address block.

      bit 3 (multivalue): if cleared ('0'), the TLV includes a single
         value which applies to all addresses described by <index-start>
         and <index-stop>.  If set ('1'), the TLV includes separate
         values for each of the addresses indicated by <index-start> and
         <index-stop>.  This bit MUST be cleared ('0') for packet or
         message TLVs or if the novalue bit is set ('1').

      bits 4-7: are RESERVED and SHALL each be cleared ('0').

   <index-start> is omitted if the noindex bit is set ('1'), otherwise
      it is an 8 bit field.  In the former case, the variable index-
      start is defined by:

      index-start = <index-start>

      in the latter case, the variable index-start is defined by:

      index-start = 0

      If this TLV is associated with an address block then index-start
      specifies the index of the first address in the address block
      (starting at zero) for which this TLV applies;

   <index-stop> is omitted if the noindex bit is set ('1'), otherwise it
      is an 8 bit field.  In the former case, the variable index-stop is
      defined by:

      index-stop = <index-stop>

      in the latter case, for a TLV associated with an address block
      with <num-addr> addresses the variable index-stop is defined by:

      index-stop = <num-addr> - 1

      otherwise (a TLV associated with a packet or a message) the
      variable index-stop is defined by:

      index-stop = 0

      If this TLV is associated with an address block then index-stop
      specifies the index of the last address in the address block
      (starting at zero) for which this TLV applies.

   number-values is a variable, defined by
      number-values = <index-stop> - <index-start> + 1

      If this TLV is associated with an address block then number-values
      is the number of addresses in that block to which this TLV
      applies, otherwise it is 1.

   <length> is omitted if the novalue bit is set ('1'), otherwise it is
      an 8 bit or 16 bit field, according to whether the extended bit is
      cleared ('0') or set ('1'), respectively.  If present this field
      specifies the length, counted in octets, of the data contained in
      <value>.  If the multivalue bit is set ('1') then <length> MUST be
      an integral multiple of number-values and the variable single-
      length is defined by

      single-length = <length> / number-values

      otherwise, if the multivalue bit is cleared ('0'), the variable
      single-length is defined by

      single-length = <length>

   <value> is omitted if the novalue bit is set ('1'), Otherwise it is a
      field of length <length> octets.  If the multivalue bit is cleared
      ('0') then this field is associated with the packet, message or
      the relevant addresses (from index-start to index-stop) in the
      address block with which this TLV is associated, as appropriate.
      If the multivalue bit is set ('1') then this field is divided
      equally into number-values fields, each of length single-length
      octets and these are associated, in order, to the relevant
      addresses (from index-start to index-stop) in the address block
      with which this TLV is associated.  The association is interpreted
      according to the <tlv-type> field.

5.3.2.  Constraints

   TLVs in the same <tlv-block> SHALL be sorted in ascending TLV type
   order.

   Two or more TLVs of the same type associated with the same <addr-
   block> SHALL NOT both cover any index (address).

   TLVs of the same type associated with the same <addr-block> SHALL be
   sorted in ascending <index-start> order.

5.4.  Message Content Fragmentation

   A message may be larger than is desirable to include, with the
   packet, message and other headers (transport, IP), in a MAC frame.

   In this case the message SHOULD be fragmented.  Only the originator
   of a message may decide to fragment a message.  When a message is
   fragmented it MUST be assigned a content sequence number by the
   originator.  A content sequence number may also be assigned for
   reasons other than fragmentation.

   A content sequence number may be specific to the type of the message
   or not.  If the content sequence number is to be used for
   fragmentation then this is indicated as specified in Section 6.1.

   Two messages with the same originator and, when the content sequence
   number is type-specific, with the same type, with different message
   bodies SHALL NOT be assigned the same content sequence number.  Two
   messages with the same originator and the same message body MAY be
   assigned the same content sequence number, with the same type-
   dependence, in which case they MUST be fragmented identically.

   A fragment of a message may have one of two forms:

   o  the fragment is a "partially or wholly self-contained message" and
      may, thus, be parsed and processed immediately by the recipient.
      Additional processing MAY be necessary when all fragments are
      received;

   o  the fragment is not a "partially or wholly self-contained message"
      and may, thus, not be processed until all fragments of the message
      have been received.

   Regardless of under which of the above forms a message is fragmented,
   each fragment MUST be a complete message as defined in this
   specification, i.e.  MUST contain syntactically correct address
   blocks and TLVs.  Furthermore, all fragments of a given message MUST
   be of the same type, and have the same fragmentation semantics, see
   Section 6.1.

   If a message is fragmented, each fragment MUST contain the following
   TLVs, defined in Section 6.1:

   o  a message TLV with type FRAGMENTATION, specifying the number of
      fragments, the fragment number (counting from zero), if the
      fragment is a partially or wholly self-contained message, and if
      the CONTENT-SEQ-NUMBER generated by the originator of the
      fragmented message is specific to the type of the fragmented
      message or not;

   o  a message TLV with type CONTENT-SEQ-NUMBER, specifying the content
      sequence number associated with the information in the fragment.

   If the content sequence number included in the CONTENT-SEQ-NUMBER TLV
   of a message is specific to the type of the message then the
   originating node MUST maintain a content sequence number for that
   message type and MUST increment it when it originates a new message
   of that type, but not of any other type.  A node MAY maintain such
   type-specific content sequence numbers for any number of types.

   If the content sequence number included in the CONTENT-SEQ-NUMBER TLV
   of a message is not specific to the type of the message then the
   originating node MUST maintain a single content sequence number for
   those message type for which a content sequence number is required,
   but for which the node does not maintain a type-specific content
   sequence number.  The node MUST increment this single content
   sequence number when it originates a new message of any relevant
   type, but not of any other types (either those for which a content
   sequence number is not appropriate, or for which a type-specific
   content sequence number is maintained.)

   Since FRAGMENTATION is defined to be TLV type zero (see Section 6.1),
   it can be determined if a message is fragmented by inspecting the
   first three octets of the message body (the first three octets after
   the message header):

   o  if the first two octets (the message TLV block length) are both
      zero then the message is not a fragment;

   o  otherwise if the third octet (the first message TLV type) is zero
      then the message is a fragment;

   o  otherwise the message syntactical element that is not a fragment.

   A message SHOULD NOT to be sent with a message TLV with type
   FRAGMENTATION indicating "fragment zero 32 bit aligned.

   The number of one".

6.  TLV specification

   This document specifies two message TLVs, which are <pad-octet>s required in the
   case of message fragmentation, and one address block TLV.  The
   address block TLV to achieve this 32 bit alignment
   is included calculated as the smallest number (0 to 3) that, when added to allow a standardized way of
   representing network addresses, with a prefix length, in control
   messages.

6.1.  Message TLV Specification

                    Message TLV Specification Overview

   +----------------------+------+--------+----------------------------+
   |         Name         | Type | Length | Value                      |
   +----------------------+------+--------+----------------------------+
   |     FRAGMENTATION    |   0  |   24   | See Table 2 below.         |
   |                      |      |  bits  |                            |
   |                      |      |        |                            |
   |     CONT_SEQ_NUM     |   1  |   16   | A sequence number,         |
   |                      |      |  bits  | associated with the        |
   |                      |      |        | content
   size of the message     |
   +----------------------+------+--------+----------------------------+

                                  Table 1

   The fragmentation TLV contains the following fields in the following
   order:

              FRAGMENTATION TLV Value Specification Overview

   +-------------+----------------------------------------------------+
   | Field Width | Value                                              |
   +-------------+----------------------------------------------------+
   |    8 bits   | Number preceding elements produces an integer multiple of fragments                                |
   |             |                                                    |
   |    8 bits   | Fragment number                                    |
   |             |                                                    |
   | 4.

   <pad-octet> is an 8 bits   | Fragmentation semantics bit vector.                |
   +-------------+----------------------------------------------------+

                                  Table 2

   The field with all bits in the fragmentation semantics bit vector are defined as
   follows:

   bit 0 (notselfcont): indicates, if cleared ('0') that the message TLV ('0').

   There is a partially or wholly self-contained message, or if set ('1')
      that the message TLV no need to indicate if padding is not included, since a partially or wholly self-contained
      message.

   bit 1 (typedepseq): indicates, if cleared ('0') that the originator
      maintains <pad-
   octet> will always precede either a single sequence number for fragmented messages of
      types including message or the type end of this message, and that this is
      included in the CONTENT-SEQ-NUMBER TLV.  If set ('1'), packet.
   In the
      originator node maintains a separate sequence number for former case, the type start of this message, and that the sequence number in the CONTENT-SEQ-
      NUMBER TLV a message is indicated by the sequence number corresponding to next
   non-zero octet parsed.

   The padding after a message may be freely changed when a message is
   forwarded without affecting the type of
      this message.

   bits 2-7: are RESERVED and SHALL each be cleared ('0').

6.2.  Address Block

6.  TLV Specification

   The following specification

   This document specifies one address block TLV is provided for general use, and TLV, which is included in this specification since it complements the address
   representation by providing to
   allow a standardized way of representing a network address
   in a message. addresses.

6.1.  Address Block TLV Specification Overview

   +----------------------+------+--------+----------------------------+
   |         Name         | Type | Length | Value                      |
   +----------------------+------+--------+----------------------------+
   |     PREFIX_LENGTH    |   0  | 8 bits | Indicates that the address |
   |                      |      |        | is a network address,      |
   |                      |      |        | rather than a host         |
   |                      |      |        | address.  The value is the |
   |                      |      |        | length of the              |
   |                      |      |        | netmask/prefix. prefix/netmask.            |
   +----------------------+------+--------+----------------------------+

                                  Table 3 4

   An address in an address block without an associated PREFIX_LENGTH
   TLV may be considered to have a prefix length equal to the address
   length (in bits).

7.  IANA Considerations

   The message format in this specification defines a message "type"
   field, as well as two TLV types for message TLVs and address block
   TLVs respectively.

   A new registry for message types must be created with initial
   assignments as specified in Table 4. 5.  Future values in the range
   5-127 of the Message Type can be allocated using standards action
   [3].  Additionally, values in the range 128-255 are reserved for
   private/local use.

   A new registry for packet TLV types must be created, with no initial
   assignments.  Future values in the range 0-127 of the Message Type
   can be allocated using standards action [3].  Additionally, values in
   the range 128-255 are reserved for private/local use.

   A new registry for message TLV types must be created with no initial
   assignments as specified
   assignments.  Future values in Table 5. the range 0-127 of the Message Type
   can be allocated using standards action [3].  Additionally, values in
   the range 128-255 are reserved for private/local use.

   A new registry for address block TLV types must be created with
   initial assignments as specified in Table 6.

                          Assigned  Future values in the
   range 1-127 of the Message Types

   +--------------------+-------+--------------------------------------+
   |      Mnemonic Type can be allocated using standards
   action [3].  Additionally, values in the range 128-255 are reserved
   for private/local use.

            +-------+----------------------------------------+
            | Value | Description                            |
   +--------------------+-------+--------------------------------------+
   |      RESERVED
            +-------+----------------------------------------+
            |   0   | At start of packet signals that what | MUST NOT be allocated.                 |
            |       | follows is a packet header, rather                                        |
            |  1-4  | RESERVED                               | than
            +-------+----------------------------------------+

                                  Table 5

   Message type 0 MUST NOT be allocated because a zero-octet signifies a message header, and to allow  |
   |                    |       |
   packet header and message padding    |
   |                    |       | with zero octets                     |
   |                    |       |                                      |
   |      RESERVED      |   1   |                                      |
   |                    |       |                                      |
   |      RESERVED      |   2   |                                      |
   |                    |       |                                      |
   |      RESERVED      |   3   |                                      |
   |                    |       |                                      |
   |      RESERVED      |   4   |                                      |
   +--------------------+-------+--------------------------------------+

                                  Table 4 zero-octets are used for padding.  Message types 1
   to 4 are reserved because they are used by OLSRv1 [3] OLSR [4], which uses a
   compatible packet/message header format.

                        Assigned Message TLV Types

   +--------------------+-------+--------------------------------------+
   |      Mnemonic      | Value | Description                          |
   +--------------------+-------+--------------------------------------+
   |    FRAGMENTATION   |   0   | Specifies behavior in case of        |
   |                    |       | content fragmentation                |
   |                    |       |                                      |
   |    CONT_SEQ_NUM    |   1   | A sequence number, associated with   |
   |                    |       | the content of the message           |
   +--------------------+-------+--------------------------------------+

                                  Table 5

                     Assigned Address Block TLV Types

   +--------------------+-------+--------------------------------------+
   |      Mnemonic      | Value | Description                          |
   +--------------------+-------+--------------------------------------+
   |    PREFIX_LENGTH   |   0   | Indicates that associated addresses  |
   |                    |       | are network addresses, with given    |
   |                    |       | prefix length length.                       |
   +--------------------+-------+--------------------------------------+

                                  Table 6

8.  Security Considerations

   Packets are designed to be transmitted only one hop, and not
   forwarded.  Thus, hop-by-hop  Hop-by-hop packet level security MAY be implemented,
   between nodes with an existing security association,
   through by including a
   suitable packet TLV(s) TLV containing a cryptographic signature to the
   packet.  Since packets are received as transmitted, signatures can be
   calculated based on the entire packet content
   (including message and packet headers), content, or on parts thereof as
   appropriate.

   The messages contained in a packet are available

   Messages at each hop, and
   MAY, according to the information in the message header, and the
   protocol employing this specification, hop MAY be forwarded and/or processed.
   If a message is processed, according to be forwarded,
   the <hop-count> and <hop-limit>
   fields information in the message header, if present, SHOULD be modified.  All
   other message header fields, and the message body, MAY, depending on
   the protocol employing this specification, be left intact.

   Such a protocol (using
   specification.  With immutable messages, other than the indicated
   fields) using this message format MAY, end-to-end security MAY be
   implemented, between nodes with an existing security association, implement end-to-end message security by
   including a suitable message TLV(s) TLV containing a cryptographic signature
   to the message.  This signature  Since <hop-count> and <hop-limit> are the only
   fields that may be modified when such a message is forwarded,
   signatures can be calculated based on the entire message, including
   the message header, header with the provision
   that the <hop-count> and <hop-limit> fields MUST, if present, both be set to
   zero ('0') for both calculation and verification of the
   signature. ('0').

9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [2]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
        Addressing Architecture", RFC 3513, April 2003.

   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", October 1998.

9.2.  Informative References

   [3]

   [4]  Clausen, T. and P. Jacquet, "The Optimized Link State Routing
        Protocol", RFC 3626, October 2003.

Appendix A.  Packet and Message Layout  Illustrations

   This section specifies the translation from informative appendix illustrates the abstract descriptions
   of packets employed elements, which are
   normatively specified in the protocol specification, Section 5 using regular expressions.

   Bits labeled Reserved or Resv are cleared ('0').  Bits labeled N and the bit-layout
   packets actually exchanged between the nodes.
   M may be cleared ('0') or set ('1').  Octets labeled Padding are
   cleared ('0'), and are optional.

Appendix A.1.  General  Packet Format

   The basic layout of a packet (excluding transport and IP headers)
   SHALL be one of the following five options.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Reserved  |0|0|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Reserved  |0|1|            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Reserved  |1|0|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Reserved  |1|1|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                       Packet TLV Block                        |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message + Padding                       |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that in the first four cases the Reserved bits SHOULD be zero,
   whilst in the last case the first octet MUST NOT be zero (this is
   used to recognise this case).  In all cases where they are present,
   the octets indicated as Padding are optional and MAY be omitted.  If
   not omitted they SHOULD be used to pad to a 32 bit boundary

Appendix A.2.  Message and MUST
   all be zero.

   The basic layout of a message, plus padding, SHALL be one of the
   following four options. Padding

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |N|0|0|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |N|0|1|   |0|0|1|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |N|1|0|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Message Sequence Number    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |N|1|1|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The reserved bits marked Resv SHOULD be zero.  The N bit is set ('1')
   if the message sequence number is type-dependent, or cleared ('0') if
   the message sequence number is type-independent.  The octets
   indicated as Padding are optional and MAY be omitted.  If not omitted
   they SHOULD be used to pad to a 32 bit boundary and MUST all be zero;
   they are not included in the message size.

   The basic layout of a message body SHALL be as follows. 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |0|1|1|         Message Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         Message Body                          |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix A.3.  Message Body

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Message TLV Block                       |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Address Block                         |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                       Address TLV Block                       |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         Address Block                         |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                       Address TLV Block                       |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The basic layout of an address block SHALL be one of the following
   three options.

Appendix A.4.  Address Block

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |0| Head Length |             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |1| Head Length |             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| Tail Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Tail              |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Mid (cont)   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number Addrs  |1| Head Length |             Head              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1| Tail Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Mid              |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              Mid              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix A.5.  TLV Block

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of each Mid section is equal to the address length minus
   the Head
     |            Length and the Tail Length.  In the first case there is no
   Tail section, the Mid sections are actually tail sections.  In the
   third case the tail section is not included, it is all octets zero.

   The basic layout of a TLV block (packet             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                              TLV block, message                              |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     :                              ...                              :
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                              TLV block
   or address                              |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix A.6.  TLV block) SHALL be as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                              TLV                              |
     |                                               +-+-+-+-+-+-+-+-+
     |     Type      |Resv |M|0|0|0|0|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |0|0|0|0|1|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |M|0|0|1|0|  Index Start  |  Index Stop   |
     :                              ...                              :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                             Value                             |
     |                              TLV                                                               |
     |                                               +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length is of the TLV block contents, it does not include itself
   (hence if there are no TLVs then Length is zero).

   The basic layout of a TLV SHALL be one of the following six options.
   A packet TLV or message TLV SHALL be one of the last three options
   only.
     +-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |M|0|1|0|0|    Length     | Resv  |M|0|0|0|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |    Length
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |
     +-+-+-+-+-+-+-+-+                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      | Resv  |0|0|0|1|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or      |Resv |0|0|1|0|1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      | Resv  |M|0|1|0|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      |Resv |M|0|1|1|0|            Length             |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

   or
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |0|1|0|0|0|  Index Start  | Resv  |M|1|0|0|    Length     |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

   or

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |0|1|0|0|1|  Index Start  | Resv  |0|1|0|1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   or
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |Resv |0|1|0|1|0|  Index Start  | Resv  |M|1|1|0|    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length (cont) |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                             Value                                                               |
     |                             Value                             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |
     +-+-+-+-+-+-+-+-+

   M denotes the multivalue bit in those cases when it may be set ('1')
   or cleared ('0').  In the cases where it MUST be cleared ('0') it is
   shown thus; it MUST also be cleared ('0') in a packet TLV or message
   TLV.)  The reserved bits marked Resv SHOULD also be zero.

Appendix B.  Complete Example

   An example packet, using IPv4 addresses (length four octets) is
   shown.  This packet has a header, with a packet sequence number but
   no packet TLV block, and contains a single unfragmented message.  The
   message has a complete message header, a message TLV block of content
   length 9 octets containing a single TLV (with the noindex bit of its
   semantics set and value length 6 octets) and then two address blocks
   each with a following TLV block.  The first address block contains 3
   addresses (head length 2 octets, no tail, hence mid length two
   octets) and is followed by a TLV block of content length 9 octets
   containing two TLVs.  The first of these TLVs has the noindex bit of
   its semantics set and has a single value of length 2 octets, which
   applies to all of the addresses in the preceding address block.  The
   second of these TLVs has the novalue bit of its semantics set and
   hence has no length or value fields (it does have index fields, which
   indicate which of the those addresses this TLV applies to).  The second address
   block contains 2 addresses (head length 0 octets, hence no head
   octets, tail length 2 octets, zero-valued tail not included, hence
   mid length two octets) and is followed by a TLV block of content
   length 5 octets.  This TLV block contains a single TLV of type
   PREFIX_LENGTH which that has the multivalue and no index noindex bits of its
   semantics set and a value field length of 2 octets, indicating two
   values each of one octet length.  There are two final padding octets
   which
   that are not included in the message length of 62 octets.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0| Reserved  |0|0|    Packet Sequence Number     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |  Resv   |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Originator Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Hop Limit   |   Hop Count   |    Message Sequence Number    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|   TLV Type    | Resv  |0|1|0|0|    |Resv |0|0|1|0|0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 1 0|                     Value                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Value (cont)                  |0 0 0 0 0 0 1 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|             Head              |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |              Mid              |      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|   TLV Type    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Resv  |0|1|0|0|0
     |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0|             Value             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   TLV Type    | Resv  |0|0|0|1|    |Resv |0|0|0|0|1|  Index Start  |  Index Stop   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0|      Mid      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mid (cont)   |              Mid              |0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 0 0 1 0 1| PREFIX_LENGTH | Resv  |1|1|0|0|0 |Resv |1|0|1|0|0|0 0 0 0 0 0 1 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Value0     |    Value1     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Appendix B. C.  Contributors

   This specification is the result of the joint efforts of the
   following contributers contributors from the OLSRv2 Design Team -- listed
   alphabetically.

   o  Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>

   o  Emmanuel Baccelli, Hitachi Labs Europe, France,
      <Emmanuel.Baccelli@inria.fr>

   o  Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
      <T.Clausen@computer.org>

   o  Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil>

   o  Christopher Dearlove, BAE Systems, UK,
      <chris.dearlove@baesystems.com>

   o  Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp>

   o  Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>

   o  Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp>

Appendix C. D.  Acknowledgements

   The authors would like to acknowledge the team behind OLSRv1, as
   specified in RFC3626, RFC 3626, including Anis Laouiti, Pascale Minet, Laurent
   Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced
   Research in Engineering, Pakistan) for their contributions.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments on the
   specification and its components: Joe Macker (NRL), Alan Cullen (BAE
   Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas
   Schjonhaug (LIX), Florent Brunneau (LIX), and the entire IETF MANET
   working group.

Authors' Addresses

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/

   Christopher M. Dearlove
   BAE Systems Advanced Technology Centre

   Phone: +44 1245 242194
   Email: chris.dearlove@baesystems.com
   URI:   http://www.baesystems.com/ocs/sharedservices/atc/

   Justin W. Dean
   Naval Research Laboratory

   Phone: +1 202 767 3397
   Email: jdean@itd.nrl.navy.mil
   URI:   http://pf.itd.nrl.navy.mil/

   Cedric Adjih
   INRIA Rocquencourt

   Phone: +33 1 3963 5215
   Email: Cedric.Adjih@inria.fr
   URI:   http://menetou.inria.fr/~adjih/

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.