Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5444

Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format

Pages: 60
Proposed Standard
Errata
Updated by:  7631
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC5444 - Page 1
Network Working Group                                         T. Clausen
Request for Comments: 5444                      LIX, Ecole Polytechnique
Category: Standards Track                                    C. Dearlove
                                                         BAE Systems ATC
                                                                 J. Dean
                                               Naval Research Laboratory
                                                                C. Adjih
                                                      INRIA Rocquencourt
                                                           February 2009


    Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols.
Top   ToC   RFC5444 - Page 2

Table of Contents

1. Introduction ....................................................3 2. Notation and Terminology ........................................4 2.1. Notation ...................................................4 2.1.1. Elements ............................................4 2.1.2. Variables ...........................................5 2.2. Terminology ................................................5 3. Applicability Statement .........................................6 4. Protocol Overview and Functioning ...............................7 5. Syntactical Specification .......................................7 5.1. Packets ....................................................8 5.2. Messages ...................................................9 5.3. Address Blocks ............................................11 5.4. TLVs and TLV Blocks .......................................14 5.4.1. TLVs ...............................................14 5.4.2. TLV Usage ..........................................17 5.5. Malformed Elements ........................................18 6. IANA Considerations ............................................18 6.1. Expert Review: Evaluation Guidelines ......................18 6.2. Message Types .............................................20 6.2.1. Message-Type-Specific TLV Registry Creation ........20 6.3. Packet TLV Types ..........................................21 6.3.1. Packet TLV Type Extension Registry Creation ........21 6.4. Message TLV Types .........................................21 6.4.1. Message TLV Type Extension Registry Creation .......22 6.5. Address Block TLV Types ...................................22 6.5.1. Address Block TLV Type Extension Registry Creation ...........................................23 7. Security Considerations ........................................23 7.1. Authentication and Integrity Suggestions ..................23 7.2. Confidentiality Suggestions ...............................24 8. Contributors ...................................................25 9. Acknowledgments ................................................25 10. References ....................................................26 10.1. Normative References .....................................26 10.2. Informative References ...................................27 Appendix A. Multiplexing and Demultiplexing .......................28 Appendix B. Intended Usage ........................................28 Appendix C. Examples ..............................................30 C.1. Address Block Examples ....................................30 C.2. TLV Examples ..............................................32 Appendix D. Illustrations .........................................34 D.1. Packet ....................................................34 D.2. Message ...................................................38 D.3. Message Body ..............................................44 D.4. Address Block .............................................45
Top   ToC   RFC5444 - Page 3
      D.5. TLV Block .................................................52
      D.6. TLV .......................................................53
   Appendix E. Complete Example ......................................57

1. Introduction

This document specifies the syntax of a packet format designed for carrying multiple routing protocol messages for information exchange between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a Message Header, which is designed for control of message dissemination, and a Message Body, which contains protocol information. Only the syntax of the packet and messages is specified. This document specifies: o A packet format, allowing zero or more messages to be contained within a single transmission. A packet with zero messages may be sent in case the only information to exchange is contained in the Packet Header. o A message format, where a message is composed of a Message Header and a Message Body. o A Message Header format, which contains information that may be sufficient to allow a protocol using this specification to make processing and forwarding decisions. o A Message Body format, containing attributes associated with the message or the originator of the message, as well as blocks of addresses, or address prefixes, with associated attributes. o An Address Block format, where an Address Block represents sets of addresses, or address prefixes, in a compact form with aggregated addresses. o A generalized type-length-value (TLV) format representing attributes. Each TLV can be associated with a packet, a message, or one or more addresses or address prefixes in a single Address Block. Multiple TLVs can be included, each associated with a packet, a message, and the same, different, or overlapping sets of addresses or address prefixes. The specification has been explicitly designed with the following properties, listed in no particular order, in mind: Parsing logic - The notation used in this specification facilitates generic, protocol-independent parsing logic.
Top   ToC   RFC5444 - Page 4
   Extensibility -  Packets and messages defined by a protocol using
      this specification are extensible by defining new messages and new
      TLVs.  Protocols using this specification will be able to
      correctly identify and skip such new messages and TLVs, while
      correctly parsing the remainder of the packet and message.

   Efficiency -  When reported addresses share common bit sequences
      (e.g., address prefixes or IPv6 interface identifiers), the
      Address Block representation allows for a compact representation.
      Compact Message Headers are ensured through permitting inclusion
      of only required Message Header elements.  The multi-message
      packet structure allows a reduction in the number of transmitted
      octets and in the number of transmitted packets.  The structure of
      packet and message encoding allows parsing, verifying, and
      identifying individual elements in a single pass.

   Separation of forwarding and processing -  A protocol using this
      specification can be designed such that duplicate detection and
      controlled-scope message forwarding decisions can be made using
      information contained in the Message Header, without processing
      the Message Body.

2. Notation and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Additionally, this document uses the notation in Section 2.1 and the terminology in Section 2.2.

2.1. Notation

The following notations, for elements and variables, are used in this document. This format uses network byte order (most significant octet first) for all fields. The most significant bit in an octet is numbered bit 0, and the least significant bit of an octet is numbered bit 7 [Stevens].

2.1.1. Elements

This specification defines elements. An element is a group of any number of consecutive bits that together form a syntactic entity represented using the notation <element>. Each element in this document is defined as either:
Top   ToC   RFC5444 - Page 5
   o  a specifically sized field of bits OR

   o  a composite element, composed of other <element>s.

   A composite element is defined as follows:

       <element> := specification

   where, on the right hand side following :=, specification is
   represented using the regular expression syntax defined in
   [SingleUNIX].  Only the following notation is used:

   <element1><element2> -  Indicates that <element1> is immediately
      followed by <element2>.

   (<element1><element2>) -  Indicates a grouping of the elements
      enclosed by the parentheses.

   ? -  Zero or one occurrences of the preceding element or group.

   * -  Zero or more occurrences of the preceding element or group.

2.1.2. Variables

Variables are introduced into the specification solely as a means to clarify the description. The following two notations are used: <foo> - If <foo> is an unsigned integer field, then <foo> is also used to represent the value of that field. bar - A variable, usually obtained through calculations based on the value(s) of element(s).

2.2. Terminology

This document uses the following terminology: Packet - The top level entity in this specification. A packet contains a Packet Header and zero or more messages. Message - The fundamental entity carrying protocol information, in the form of address objects and TLVs. Address - A number of octets that make up an address of the length indicated by the encapsulating Message Header. The meaning of an address is defined by the protocol using this specification.
Top   ToC   RFC5444 - Page 6
   Address Prefix -  An address plus a prefix length, with the prefix
      length being a number of address bits measured from the left/most
      significant end of the address.

   Address Object -  Either an address, or an address prefix, as
      specified in an Address Block in this specification.

   TLV -  A type-length-value structure.  This is a generic way in which
      an attribute can be represented and correctly parsed without the
      parser having to understand the attribute.

3. Applicability Statement

This specification describes a generic packet format, designed for use by MANET routing protocols. The specification has been inspired by and extended from that used by the OLSR (Optimized Link State Routing) protocol [RFC3626]. MANETs are, commonly though not exclusively, characterized as being able to run over wireless network interfaces of limited to moderate capacity. MANETs are therefore less tolerant of wasted transmitted octets than are most wired networks. This specification thus represents a tradeoff between sometimes competing attributes, specifically efficiency, extensibility, and ease of use. Efficiency is supported by reducing packet size and by allowing multiple disjoint messages in a single packet. Reduced packet size is primarily supported by address aggregation, optional Packet Header and Message Header fields, and optional fields in Address Blocks and TLVs. Supporting multi-message packets allows a reduction in the number of packets, each of which can incur significant bandwidth costs from transport, network, and lower layers. This specification provides both external and internal extensibility. External extensibility is supported by the ability to add Packet TLVs and to define new Message Types. Internal extensibility is supported by the ability to add Message TLVs and Address Block TLVs to existing messages. Protocols can define new TLV Types, and hence the contents of their Value fields, and new Message Types (see Section 6.1). Protocols can also reuse TLV Type definitions from other protocols that also use this specification. This specification aims at being sufficiently expressive and flexible to be able to accommodate different classes of MANET routing protocols (e.g., proactive, reactive, and hybrid routing protocols) as well as extensions thereto. Having a common packet and message
Top   ToC   RFC5444 - Page 7
   format, and a common way of representing IP addresses and associated
   attributes, allows generic parsing code to be developed, regardless
   of the algorithm used by the routing protocol.

   All addresses within a message are assumed to be of the same size,
   specified in the Message Header.  In the case of mixed IPv6 and IPv4
   addresses, IPv4 addresses can be represented as IPv4-mapped IPv6
   addresses as specified in [RFC4291].

   The messages defined by this specification are designed to carry
   MANET routing protocol signaling between MANET routers.  This
   specification includes elements that can support scope-limited
   flooding, as well as being usable for point-to-point delivery of
   MANET routing protocol signaling in a multi-hop network.  Packets may
   be unicast or multicast and may use any appropriate transport
   protocol or none.

   A MANET routing protocol using the message format defined by this
   specification can constrain the syntax (for example, requiring a
   specific set of Message Header fields) that the protocol will employ.
   Protocols with such restrictions need not be able to parse all
   possible message structures as defined by this document but must be
   coherent in message generation and reception of messages that they
   define.  If a protocol specifies which elements are included, then
   direct indexing of the appropriate fields is possible, dependent on
   the syntax restrictions imposed by the protocol.  Such protocols may
   have more limited extensibility.

4. Protocol Overview and Functioning

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

5. Syntactical Specification

This section normatively provides the syntactical specification of a packet, represented by the element <packet> and the elements from which it is composed. The specification is given using the notation in Section 2.1. Graphical illustrations of the layout of specified elements are given in Appendix D, a graphical illustration of a complete example (a packet including a message with Address Blocks and TLVs) is given in Appendix E. This format uses network byte order, as indicated in Section 2.1.
Top   ToC   RFC5444 - Page 8

5.1. Packets

<packet> is defined by: <packet> := <pkt-header> <message>* where <message> is as defined in Section 5.2. Successful parsing is terminated when all octets of the packet (as defined by the datagram containing the packet) are used. <pkt-header> is defined by: <pkt-header> := <version> <pkt-flags> <pkt-seq-num>? <tlv-block>? where: <version> is a 4-bit unsigned integer field and specifies the version of the specification on which the packet and the contained messages are constructed. This document specifies version 0. <pkt-flags> is a 4-bit field, specifying the interpretation of the remainder of the Packet Header: bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not included in the <pkt-header>. If set ('1'), then <pkt-seq-num> is included in the <pkt-header>. bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not included in the <pkt-header>. If set ('1'), then <tlv-block> is included in the <pkt-header>. bits 2-3: Are RESERVED and SHOULD each be cleared ('0') on transmission and SHOULD be ignored on reception. <pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0'); otherwise, is a 16-bit unsigned integer field, specifying a Packet Sequence Number. <tlv-block> is omitted if the phastlv flag is cleared ('0') and is otherwise as defined in Section 5.4. It is assumed that the network layer is able to deliver the exact payload length, thus avoiding having to carry the packet length in the packet.
Top   ToC   RFC5444 - Page 9

5.2. Messages

Packets may, in addition to the Packet Header, contain one or more messages. Messages contain: o A Message Header. o A Message TLV Block that contains zero or more TLVs, associated with the whole message. o Zero or more Address Blocks, each containing one or more address objects. o An Address Block TLV Block, containing zero or more TLVs and following each Address Block, through which addresses can be associated with additional attributes. <message> is defined by: <message> := <msg-header> <tlv-block> (<addr-block><tlv-block>)* <msg-header> := <msg-type> <msg-flags> <msg-addr-length> <msg-size> <msg-orig-addr>? <msg-hop-limit>? <msg-hop-count>? <msg-seq-num>? where: <tlv-block> is as defined in Section 5.4. <addr-block> is as defined in Section 5.3. <msg-type> is an 8-bit unsigned integer field, specifying the type of the message. <msg-flags> is a 4-bit field, specifying the interpretation of the remainder of the Message Header: bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not included in the <msg-header>. If set ('1'), then <msg-orig- addr> is included in the <msg-header>.
Top   ToC   RFC5444 - Page 10
      bit 1 (mhashoplimit):  If cleared ('0'), then <msg-hop-limit> is
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         limit> is included in the <msg-header>.

      bit 2 (mhashopcount):  If cleared ('0'), then <msg-hop-count> is
         not included in the <msg-header>.  If set ('1'), then <msg-hop-
         count> is included in the <msg-header>.

      bit 3 (mhasseqnum):  If cleared ('0'), then <msg-seq-num> is not
         included in the <msg-header>.  If set ('1'), then <msg-seq-num>
         is included in the <msg-header>.

   <msg-addr-length>  is a 4-bit unsigned integer field, encoding the
      length of all addresses included in this message (<msg-orig-addr>
      as well as each address included in Address Blocks as defined in
      Section 5.3), as follows:

         <msg-addr-length> = the length of an address in octets - 1

      <msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv6
      addresses.

   address-length is a variable whose value is the length of an address
      in octets and is calculated as follows:

         address-length = <msg-addr-length> + 1

   <msg-size>  is a 16-bit unsigned integer field, specifying the number
      of octets that make up the <message>, including the <msg-header>.

   <msg-orig-addr>  is omitted if the mhasorig flag is cleared ('0');
      otherwise, is an identifier with length equal to address-length
      that can serve to uniquely identify the MANET router that
      originated the message.

   <msg-hop-limit>  is omitted if the mhashoplimit flag is cleared
      ('0'); otherwise, is an 8-bit unsigned integer field that can
      contain the maximum number of hops that the message should be
      further transmitted.

   <msg-hop-count>  is omitted if the mhashopcount flag is cleared
      ('0'); otherwise, is an 8-bit unsigned integer field that can
      contain the number of hops that the message has traveled.

   <msg-seq-num>  is omitted if the mhasseqnum flag is cleared ('0');
      otherwise, is a 16-bit unsigned integer field that can contain a
      sequence number, generated by the message's originator MANET
      router.
Top   ToC   RFC5444 - Page 11

5.3. Address Blocks

An Address Block can specify one or more addresses, all of which will be address-length octets long, as specified using the <msg-addr- length> in the <msg-header> of the message containing the Address Block. An Address Block can also specify prefix lengths that can be applied to all addresses in the Address Block, if appropriate. This allows an Address Block to specify either addresses or address prefixes. A protocol may specify that an address with a maximum prefix length (equal to the address length in bits, i.e., 8 * address-length) is considered to be an address, rather than an address prefix, thus allowing an Address Block to contain a mixture of addresses and address prefixes. The common term "address object" is used in this specification to cover both of these; note that an address object in an Address Block always includes the prefix length, if present. An address is specified as a sequence of address-length octets of the form Head:Mid:Tail. There are no semantics associated with Head, Mid, or Tail; this representation is solely to allow aggregation of addresses, which often have common parts (e.g., common prefixes or multiple IPv6 addresses on the same interface). An Address Block contains an ordered set of addresses all sharing the same Head and the same Tail, but having individual Mids. Independently, Head and Tail may be empty, allowing for representation of address objects that do not have common Heads or common Tails. Detailed examples of Address Blocks are included in Appendix C.1. An Address Block can specify address prefixes: o with a single prefix length for all address prefixes OR o with a prefix length for each address prefix. <address-block> is defined by: <address-block> := <num-addr> <addr-flags> (<head-length><head>?)? (<tail-length><tail>?)? <mid>* <prefix-length>* where: <num-addr> is an 8-bit unsigned integer field containing the number of addresses represented in the Address Block, which MUST NOT be zero.
Top   ToC   RFC5444 - Page 12
   <addr-flags>  is an 8-bit field specifying the interpretation of the
      remainder of the Address Block:

      bit 0 (ahashead):  If cleared ('0'), then <head-length> and <head>
         are not included in the <address-block>.  If set ('1'), then
         <head-length> is included in the <address-block>, and <head> is
         included in the <address-block> unless <head-length> is zero.

      bit 1 (ahasfulltail) and bit 2 (ahaszerotail):  Are interpreted
         according to Table 1.  A combination not shown in that table
         MUST NOT be used.

      bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen):  Are
         interpreted according to Table 2.  A combination not shown in
         that table MUST NOT be used.

      bits 5-7:  Are RESERVED and SHOULD each be cleared ('0') on
         transmission and SHOULD be ignored on reception.

   +--------------+--------------+---------------+---------------------+
   | ahasfulltail | ahaszerotail | <tail-length> |        <tail>       |
   +--------------+--------------+---------------+---------------------+
   |       0      |       0      |  not included |     not included    |
   |       1      |       0      |    included   |   included unless   |
   |              |              |               |   <tail-length> is  |
   |              |              |               |         zero        |
   |       0      |       1      |    included   |     not included    |
   +--------------+--------------+---------------+---------------------+

    Table 1: Interpretation of the ahasfulltail and ahaszerotail flags

   +------------+-----------+------------------+-----------------------+
   | ahassingle | ahasmulti |     number of    |  prefix length of the |
   |   prelen   |   prelen  |  <prefix-length> |  nth address prefix,  |
   |            |           |      fields      |        in bits        |
   +------------+-----------+------------------+-----------------------+
   |      0     |     0     |         0        |   8 * address-length  |
   |      1     |     0     |         1        |    <prefix-length>    |
   |      0     |     1     |    <num-addr>    |  nth <prefix-length>  |
   +------------+-----------+------------------+-----------------------+

                      Table 2: Interpretation of the
                ahassingleprelen and ahasmultiprelen flags

   <head-length>  if present, is an 8-bit unsigned integer field that
      contains the number of octets in the Head of all of the addresses
      in the Address Block, i.e., each <head> element included is <head-
      length> octets long.
Top   ToC   RFC5444 - Page 13
   head-length is a variable, defined to equal <head-length>, if
      present, or 0 otherwise.

   <head>  is omitted if head-length is equal to 0; otherwise, it is a
      field of the head-length leftmost octets common to all the
      addresses in the Address Block.

   <tail-length>  if present, is an 8-bit unsigned integer field that
      contains the number of octets in the Tail of all of the addresses
      in the Address Block, i.e., each <tail> element included is <tail-
      length> octets long.

   tail-length is a variable, defined to equal <tail-length>, if
      present, or 0 otherwise.

   <tail>  is omitted if tail-length is equal to 0, or if the
      ahaszerotail flag is set ('1'); otherwise, it is a field of the
      tail-length rightmost octets common to all the addresses in the
      Address Block.  If the ahaszerotail flag is set ('1'), then the
      tail-length rightmost octets of all the addresses in the Address
      Block are 0.

   mid-length is a variable that MUST be non-negative, defined by:

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

      i.e., each <mid> element included is mid-length octets long.

   <mid>  is omitted if mid-length is equal to 0; otherwise, each <mid>
      is a field of length mid-length octets, representing the Mid of
      the corresponding address in the Address Block.  When not omitted,
      an Address Block contains exactly <num-addr> <mid> fields.

   <prefix-length>  is an 8-bit unsigned integer field containing the
      length, in bits, of an address prefix.  If the ahassingleprelen
      flag is set ('1'), then a single <prefix-length> field is included
      that contains the prefix length of all addresses in the Address
      Block.  If the ahasmultiprelen flag is set ('1'), then <num-addr>
      <prefix-length> fields are included, each of which contains the
      prefix length of the corresponding address prefix in the Address
      Block (in the same order).  Otherwise, no <prefix-length> fields
      are present; each address object can be considered to have a
      prefix length equal to 8 * address-length bits.  The Address Block
      is malformed if any <prefix-length> element has a value greater
      than 8 * address-length.
Top   ToC   RFC5444 - Page 14

5.4. TLVs and TLV Blocks

A TLV allows the association of an arbitrary attribute with a message or a packet, or with a single address or a contiguous set of addresses in an Address Block. The attribute (value) is made up from an integer number of consecutive octets. Different attributes have different types; attributes that are unknown when parsing can be skipped. TLVs are grouped in TLV Blocks, with all TLVs within a TLV Block associating attributes with either the packet (for the TLV Block in the Packet Header), the message (for the TLV Block immediately following the Message Header), or to addresses in the immediately preceding Address Block. Individual TLVs in a TLV Block immediately following an Address Block can associate attributes to a single address, a range of addresses, or all addresses in that Address Block. When associating an attribute with more than one address, a TLV can include one value for all addresses or one value per address. Detailed examples of TLVs are included in Appendix C.2. A TLV Block is defined by: <tlv-block> := <tlvs-length> <tlv>* where: <tlvs-length> is a 16-bit unsigned integer field that contains the total number of octets in all of the immediately following <tlv> elements (<tlvs-length> not included). <tlv> is as defined in Section 5.4.1.

5.4.1. TLVs

There are three kinds of TLV, each represented by an element <tlv>: o A Packet TLV, included in the Packet TLV Block in a Packet Header. o A Message TLV, included in the Message TLV Block in a message, before any Address Blocks. o An Address Block TLV, included in an Address Block TLV Block following an Address Block. An Address Block TLV applies to:
Top   ToC   RFC5444 - Page 15
      *  all address objects in the Address Block, OR

      *  any continuous sequence of address objects in the Address
         Block, OR

      *  a single address object in the Address Block.

   <tlv> is defined by:

       <tlv> := <tlv-type>
                <tlv-flags>
                <tlv-type-ext>?
                (<index-start><index-stop>?)?
                (<length><value>?)?

   where:

   <tlv-type>  is an 8-bit unsigned integer field, specifying the type
      of the TLV, specific to the TLV kind (i.e., Packet TLV, Message
      TLV, or Address Block TLV).

   <tlv-flags>  is an 8-bit field specifying the interpretation of the
      remainder of the TLV:

      bit 0 (thastypeext):  If cleared ('0'), then <tlv-type-ext> is not
         included in the <tlv>.  If set ('1'), then <tlv-type-ext> is
         included in the <tlv>.

      bit 1 (thassingleindex) and bit 2 (thasmultiindex):  Are
         interpreted according to Table 3.  A combination not shown in
         that table MUST NOT be used.  Both of these flags MUST be
         cleared ('0') in Packet TLVs and Message TLVs.

      bit 3 (thasvalue) and bit 4 (thasextlen):  Are interpreted
         according to Table 4.  A combination not shown in that table
         MUST NOT be used.

      bit 5 (tismultivalue):  This flag serves to specify how the
         <value> field is interpreted, as specified below.  This flag
         MUST be cleared ('0') in Packet TLVs and Message TLVs, if the
         thasmultiindex flag is cleared ('0'), or if the thasvalue flag
         is cleared ('0').

      bits 6-7:  Are RESERVED and SHOULD each be cleared ('0') on
         transmission and SHOULD be ignored on reception.
Top   ToC   RFC5444 - Page 16
    +-----------------+----------------+---------------+--------------+
    | thassingleindex | thasmultiindex | <index-start> | <index-stop> |
    +-----------------+----------------+---------------+--------------+
    |        0        |        0       |  not included | not included |
    |        1        |        0       |    included   | not included |
    |        0        |        1       |    included   |   included   |
    +-----------------+----------------+---------------+--------------+

                      Table 3: Interpretation of the
                 thassingleindex and thasmultiindex flags

   +-----------+------------+--------------+---------------------------+
   | thasvalue | thasextlen |   <length>   |          <value>          |
   +-----------+------------+--------------+---------------------------+
   |     0     |      0     | not included |        not included       |
   |     1     |      0     |    8 bits    |  included unless <length> |
   |           |            |              |          is zero          |
   |     1     |      1     |    16 bits   |  included unless <length> |
   |           |            |              |          is zero          |
   +-----------+------------+--------------+---------------------------+

       Table 4: Interpretation of the thasvalue and thasextlen flags

   <tlv-type-ext>  is an 8-bit unsigned integer field, specifying an
      extension of the TLV Type, specific to the TLV Type and kind
      (i.e., Packet TLV, Message TLV, or Address Block TLV).

   tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if
      present, or 0 otherwise.

   tlv-fulltype is a variable, defined by:

         tlv-fulltype := 256 * <tlv-type> + tlv-type-ext

   <index-start> and <index-stop>  when present, in an Address Block TLV
      only, are each an 8-bit unsigned integer field.

   index-start and index-stop are variables, defined according to
      Table 5.  The variable end-index is defined as follows:

      *  For Message TLVs and Packet TLVs:

            end-index := 0

      *  For Address Block TLVs:

            end-index := <num-addr> - 1
Top   ToC   RFC5444 - Page 17
      An Address Block TLV applies to the address objects from position
      index-start to position index-stop (inclusive) in the Address
      Block, where the first address object has position zero.

   +-----------------+----------------+----------------+---------------+
   | thassingleindex | thasmultiindex | index-start := | index-stop := |
   +-----------------+----------------+----------------+---------------+
   |        0        |        0       |        0       |   end-index   |
   |        1        |        0       |  <index-start> | <index-start> |
   |        0        |        1       |  <index-start> |  <index-stop> |
   +-----------------+----------------+----------------+---------------+

                      Table 5: Interpretation of the
                 thassingleindex and thasmultiindex flags

   number-values is a variable, defined by:

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

   <length>  is omitted or is an 8-bit or 16-bit unsigned integer field
      according to Table 4.  If the tismultivalue flag 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

      If the tismultivalue flag is cleared ('0'), then the variable
      single-length is defined by:

         single-length := <length>

   <value>  if present (see Table 4), is a field of length <length>
      octets.  In an Address Block TLV, <value> is associated with the
      address objects from positions index-start to index-stop,
      inclusive.  If the tismultivalue flag is cleared ('0'), then the
      whole of this field is associated with each of the indicated
      address objects.  If the tismultivalue flag 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,
      with the indicated address objects.

5.4.2. TLV Usage

A TLV associates an attribute with a packet, a message, or one or more consecutive address objects in an Address Block. The interpretation and processing of this attribute, and the relationship
Top   ToC   RFC5444 - Page 18
   (including order of processing) between different attributes
   associated with the same entity MUST be defined by any protocol that
   uses this specification.

   Any protocol using this specification MUST define appropriate
   behaviors if this associated information is inconsistent, in
   particular if two TLVs of the same type but with different values
   apply to the same entity (packet, message, or address) but this is
   not meaningful.  The protocol MUST also specify an appropriate
   processing order for TLVs associated with a given entity.

5.5. Malformed Elements

An element is malformed if it cannot be parsed according to its syntactical specification (including if there are insufficient octets available). If the malformed element is in the Packet Header, then the packet MUST be silently discarded, and contained messages MUST NOT be processed and MUST NOT be forwarded. If the malformed element is contained in a message (i.e., is in the Message TLV Block, an Address Block, or an Address Block TLV Block), then that message MUST be silently discarded; it MUST NOT be processed and MUST NOT be forwarded.


(page 18 continued on part 2)

Next Section