tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5444

 
 
 

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

Part 2 of 3, p. 18 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
6.  IANA Considerations

   This document introduces four namespaces that have been registered:
   Message Types, Packet TLV Types, Message TLV Types, and Address Block
   TLV Types.  This section specifies IANA registries for these
   namespaces and provides guidance to the Internet Assigned Numbers
   Authority regarding registrations in these namespaces.

   The following terms are used with the meanings defined in [BCP26]:
   "Namespace", "Assigned Value", "Registration", "Unassigned",
   "Reserved", "Hierarchical Allocation", and "Designated Expert".

   The following policies are used with the meanings defined in [BCP26]:
   "Private Use", "Expert Review", and "Standards Action".

6.1.  Expert Review: Evaluation Guidelines

   For registration requests where an Expert Review is required, the
   Designated Expert SHOULD take the following general recommendations
   into consideration:

   o  The purpose of these registries is to support Standard and
      Experimental MANET routing and related protocols and extensions to
      these protocols.

Top      Up      ToC       Page 19 
   o  The intention is that all registrations will be accompanied by a
      published RFC.

   o  In order to allow for registration prior to the RFC being approved
      for publication, the Designated Expert can approve the
      registration once it seems clear that an RFC is expected to be
      published.

   o  The Designated Expert will post a request to the MANET WG mailing
      list, or to a successor thereto as designated by the Area
      Director, for comments and reviews.  This request will include a
      reference to the Internet-Draft requesting the registration.

   o  Before a period of 30 days has passed, the Designated Expert will
      either approve or deny the registration request and publish a note
      of the decision to the MANET WG mailing list or its successor, as
      well as inform IANA and the IESG.  A denial note MUST be justified
      by an explanation and, in cases where it is possible, suggestions
      as to how the request can be modified so as to become acceptable
      SHOULD be provided.

   For the registry for Message Types, the following guidelines apply:

   o  Registration of a Message Type implies creation of two registries
      for Message-Type-specific Message TLVs and Message-Type-specific
      Address Block TLVs.  The document that requests the registration
      of the Message Type MUST indicate how these Message-Type-specific
      TLV Types are to be allocated, from any options in [BCP26], and
      any initial allocations.  The Designated Expert SHOULD take the
      allocation policies specified for these registries into
      consideration in reviewing the Message Type allocation request.

   For the registries for Packet TLV Types, Message TLV Types, and
   Address Block TLV Types, the following guidelines apply:

   o  These are Hierarchical Allocations, i.e., allocation of a type
      creates a registry for the extended types corresponding to that
      type.  The document that requests the registration of the type
      MUST indicate how these extended types are to be allocated, from
      any options in [BCP26], and any initial allocations.  Normally
      this allocation should also undergo Expert Review, but with the
      possible allocation of some type extensions as Reserved,
      Experimental, and/or Private.

   o  The request for a TLV Type MUST include the specification of the
      permitted size, syntax of any internal structure, and meaning, of
      the Value field (if any) of the TLV.

Top      Up      ToC       Page 20 
   For the registries for Message TLV Types and Address Block TLV Types,
   the following additional guidelines apply:

   o  TLV Type values 0-127 are common for all Message Types.  TLVs that
      receive registrations from the 0-127 interval SHOULD be modular in
      design to allow reuse among protocols.

   o  TLV Type values 128-223 are Message-Type-specific TLV Type values,
      relevant only in the context of the containing Message Type.
      Registration of TLV Type values within the 128-223 interval
      requires that a registry in the 128-223 interval exists for a
      specific Message Type value (see Section 6.2.1), and registrations
      are made in accordance with the allocation policies specified for
      these Message-Type-specific registries.  Message-Type-specific TLV
      Types SHOULD be registered for TLVs that the Designated Expert
      deems too Message-Type-specific for registration of a 0-127 value.
      Multiple different TLV definitions MAY be assigned the same TLV
      Type value within the 128-223 interval, given that they are
      associated with different Message-Type-specific TLV Type
      registries.  Where possible, existing global TLV definitions and
      modular global TLV definitions for registration in the 0-127 range
      SHOULD be used.

6.2.  Message Types

   A new registry for Message Types has been created, with initial
   assignments and allocation policies as specified in Table 6.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               |  0-223  | Unassigned  | Expert Review     |
               | 224-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+

                          Table 6: Message Types

6.2.1.  Message-Type-Specific TLV Registry Creation

   When a Message Type is registered, then registries MUST be specified
   for both Message-Type-specific Message TLVs (Table 8) and Message-
   Type-specific Address Block TLVs (Table 10).  A document that creates
   a Message-Type-specific TLV registry MUST also specify the mechanism
   by which Message-Type-specific TLV Types are allocated, from among
   those in [BCP26].

Top      Up      ToC       Page 21 
6.3.  Packet TLV Types

   A new registry for Packet TLV Types has been created, with initial
   assignments and allocation policies as specified in Table 7.

               +---------+-------------+-------------------+
               |   Type  | Description | Allocation Policy |
               +---------+-------------+-------------------+
               |  0-223  | Unassigned  | Expert Review     |
               | 224-255 | Unassigned  | Experimental Use  |
               +---------+-------------+-------------------+

                         Table 7: Packet TLV Types

6.3.1.  Packet TLV Type Extension Registry Creation

   When a Packet TLV Type is registered, then a new registry for type
   extensions of that type must be created.  A document that defines a
   Packet TLV Type MUST also specify the mechanism by which its type
   extensions are allocated, from among those in [BCP26].

6.4.  Message TLV Types

   A new registry for Message-Type-independent Message TLV Types has
   been created, with initial assignments and allocation policies as
   specified in Table 8.

        +---------+-----------------------+-----------------------+
        |   Type  | Description           | Allocation Policy     |
        +---------+-----------------------+-----------------------+
        |  0-127  | Unassigned            | Expert Review         |
        | 128-223 | Message-Type-specific | Reserved, see Table 9 |
        | 224-255 | Unassigned            | Experimental Use      |
        +---------+-----------------------+-----------------------+

                        Table 8: Message TLV Types

   Message TLV Types 128-223 are reserved for Message-Type-specific
   Message TLVs, for which a new registry is created with the
   registration of a Message Type, and with initial assignments and
   allocation policies as specified in Table 9.

Top      Up      ToC       Page 22 
       +---------+-----------------------------+-------------------+
       |   Type  | Description                 | Allocation Policy |
       +---------+-----------------------------+-------------------+
       |  0-127  | Common to all Message Types | Reserved          |
       | 128-223 | Message-Type-specific       | See Below         |
       | 224-255 | Common to all Message Types | Reserved          |
       +---------+-----------------------------+-------------------+

             Table 9: Message-Type-specific Message TLV Types

   Allocation policies for Message-Type-specific Message TLV Types MUST
   be specified when creating the registry associated with the
   containing Message Type, see Section 6.2.1.

6.4.1.  Message TLV Type Extension Registry Creation

   If a Message TLV Type is registered, then a new registry for type
   extensions of that type must be created.  A document that defines a
   Message TLV Type MUST also specify the mechanism by which its type
   extensions are allocated, from among those in [BCP26].

6.5.  Address Block TLV Types

   A new registry for Message-Type-independent Address Block TLV Types
   has been created, with initial assignments and allocation policies as
   specified in Table 10.

       +---------+-----------------------+------------------------+
       |   Type  | Description           | Allocation Policy      |
       +---------+-----------------------+------------------------+
       |  0-127  | Unassigned            | Expert Review          |
       | 128-223 | Message-Type-specific | Reserved, see Table 11 |
       | 224-255 | Unassigned            | Experimental Use       |
       +---------+-----------------------+------------------------+

                     Table 10: Address Block TLV Types

   Address Block TLV Types 128-223 are reserved for Message-Type-
   specific Address Block TLVs, for which a new registry is created with
   the registration of a Message Type, and with initial assignments and
   allocation policies as specified in Table 11.

Top      Up      ToC       Page 23 
       +---------+-----------------------------+-------------------+
       |   Type  | Description                 | Allocation Policy |
       +---------+-----------------------------+-------------------+
       |  0-127  | Common to all Message Types | Reserved          |
       | 128-223 | Message-Type-specific       | See Below         |
       | 224-255 | Common to all Message Types | Reserved          |
       +---------+-----------------------------+-------------------+

          Table 11: Message-Type-specific Address Block TLV Types

   Allocation policies for Message-Type-specific Address Block TLV Types
   MUST be specified when creating the registry associated with the
   containing Message Type, see Section 6.2.1.

6.5.1.  Address Block TLV Type Extension Registry Creation

   When an Address Block TLV Type is registered, then a new registry for
   type extensions of that type must be created.  A document that
   defines a Message TLV Type MUST also specify the mechanism by which
   its type extensions are allocated, from among those in [BCP26].

7.  Security Considerations

   This specification does not describe a protocol; it describes a
   packet format.  As such, it does not specify any security
   considerations; these are matters for a protocol using this
   specification.  However, some security mechanisms are enabled by this
   specification and may form part of a protocol using this
   specification.  Mechanisms that may form part of an authentication
   and integrity approach in a protocol using this specification are
   described in Section 7.1.  Mechanisms that may form part of a
   confidentiality approach in a protocol using this specification are
   described in Section 7.2.  There is, however, no requirement that a
   protocol using this specification should use either.

7.1.  Authentication and Integrity Suggestions

   The authentication and integrity suggestions made here are based on
   the intended usage in Appendix B, specifically that:

   o  Messages are designed to be carriers of protocol information and
      MAY, at each hop, be forwarded and/or processed by the protocol
      using this specification.

   o  Packets are designed to carry a number of messages between
      neighboring MANET routers in a single transmission and over a
      single logical hop.

Top      Up      ToC       Page 24 
   Consequently:

   o  For forwarded messages where the message is unchanged by
      forwarding MANET routers, end-to-end authentication and integrity
      MAY be implemented, between MANET routers with an existing
      security association, by including a suitable Message TLV
      containing a cryptographic signature in the message.  Since <msg-
      hop-count> and <msg-hop-limit> are the only fields that should be
      modified when such a message is forwarded in this manner, this
      signature can be calculated based on the entire message, including
      the Message Header, with the <msg-hop-count> and <msg-hop-limit>
      fields set to 0, if present.

   o  Hop-by-hop packet level authentication and integrity MAY be
      implemented, between MANET routers with an existing security
      association, by including a suitable Packet TLV containing a
      cryptographic signature to the packet.  Since packets are received
      as transmitted, this signature can be calculated based on the
      entire packet or on parts thereof as appropriate.

7.2.  Confidentiality Suggestions

   This specification does not explicitly enable protecting packet/
   message confidentiality.  Such confidentiality would normally, when
   required, be provided hop-by-hop, either by link-layer mechanisms or
   at the IP layer using [RFC4301], and would apply to a packet only.

   It is possible, however, for a protocol using this specification to
   protect the confidentiality of information included in a Packet,
   Message, or Address Block TLV by specifying that the Value field of
   that TLV Type be encrypted, as well as specifying the encryption
   mechanism.

   In an extreme case, all information can be encrypted by defining
   either:

   o  A packet, consisting of only a Packet Header (with no messages)
      and containing a Packet TLV, where the Packet TLV Type indicates
      that its Value field contains one or more encrypted messages.
      Upon receipt, and once this Packet TLV is successfully decrypted,
      these messages may then be parsed according to this specification
      and processed according to the protocol using this specification.

   o  A message, consisting of only a Message Header and a single
      Message TLV, where the Message TLV Type indicates that its Value
      field contains an encrypted version of the message's remaining
      Message TLVs, Address Blocks, and Address Block TLVs.  Upon
      receipt, and once this Message TLV is successfully decrypted, the

Top      Up      ToC       Page 25 
      complete message may then be parsed according to this
      specification and processed according to the protocol using this
      specification.

   In either case, the protocol MUST define the encrypted TLV Type, as
   well as the format of the encrypted data block contained in the Value
   field of the TLV.

8.  Contributors

   This specification is the result of the joint efforts of the
   following contributors from the OLSRv2 Design Team, listed
   alphabetically:

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

   o  Emmanuel Baccelli, INRIA, 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, <hiroki.satoh.yj@hitachi.com>

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

   o  Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>

9.  Acknowledgments

   The authors would like to acknowledge the team behind OLSR [RFC3626],
   including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
   (both at INRIA, France), and Amir Qayyum (Center for Advanced
   Research in Engineering, Pakistan) for their contributions.  Elwyn
   Davies (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris
   Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus
   Westerlund (Ericsson, Sweden) all provided detailed reviews and
   insightful comments.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews, and comments on the
   specification and its components (listed alphabetically):

Top      Up      ToC       Page 26 
   o  Brian Adamson (NRL)

   o  Teco Boot (Infinity Networks)

   o  Florent Brunneau (LIX)

   o  Ian Chakeres (CenGen)

   o  Alan Cullen (BAE Systems)

   o  Ulrich Herberg (LIX)

   o  Joe Macker (NRL)

   o  Yasunori Owada (Niigata University)

   o  Charlie E. Perkins (WiChorus)

   o  Henning Rogge (FGAN)

   o  Andreas Schjonhaug (LIX)

   and the entire IETF MANET working group.

10.  References

10.1.  Normative References

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

   [RFC4291]     Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 4291, February 2006.

   [BCP26]       Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26,
                 RFC 5226, May 2008.

   [SingleUNIX]  IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
                 1/SC22/WG15, "Single UNIX Specification, Version 3,
                 2004 Edition", April 2004.

Top      Up      ToC       Page 27 
10.2.  Informative References

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

   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [Stevens]     Stevens, W., "TCP/IP Illustrated Volume 1 - The
                 Protocols", 1994.

Top      Up      ToC       Page 28 
Appendix A.  Multiplexing and Demultiplexing

   The packet and message format specified in this document is designed
   to allow zero or more messages to be contained within a single
   packet.  Such messages may be from the same or different protocols.
   Thus, a multiplexing and demultiplexing process MUST be present.

   Multiplexing messages on a given MANET router into a single packet,
   rather than having each message generate its own packet, reduces the
   total number of octets and the number of packets transmitted by that
   MANET router.

   The multiplexing and demultiplexing process running on a given UDP
   port or IP protocol number, and its associated protocols, MUST:

   o  For each Message Type, a protocol -- unless specified otherwise,
      the one making the IANA reservation for that Message Type -- MUST
      be designated as the "owner" of that Message Type.

   o  The Packet Header fields, including the Packet TLV Block, are used
      by the multiplexing and demultiplexing process, which MAY make
      such information available for use in its protocol instances.

   o  The <pkt-seq-num> field, if present, contains a sequence number
      that is incremented by 1 for each packet generated by a node.  The
      sequence number after 65535 is 0.  In other words, the sequence
      number "wraps" in the usual way.

   o  Incoming messages MUST be either silently discarded or MUST be
      delivered to the instance of the protocol that owns the associated
      Message Type.  Incoming messages SHOULD NOT be delivered to any
      other protocol instances and SHOULD NOT be delivered to more than
      one protocol instance.

   o  Outgoing messages of a given type MUST be generated only by the
      protocol instance that owns that Message Type and be delivered to
      the multiplexing and demultiplexing process.

   o  If two protocols both wish to use the same Message Type, then this
      interaction SHOULD be specified by the protocol that is the
      designated owner of that Message Type.

Appendix B.  Intended Usage

   This appendix describes the intended usage of Message Header fields,
   including their content and use.  Alternative uses of this
   specification are permitted.

Top      Up      ToC       Page 29 
   The message format specified in this document is designed to carry
   MANET routing protocol signaling between MANET routers and to support
   scope-limited flooding as well as point-to-point delivery.

   Messages are designed to be able to be forwarded over one or more
   logical hops, in a new packet for each logical hop.  Each logical hop
   may consist of one or more IP hops.

   Specifically, scope-limited flooding is supported for messages when:

   o  The <msg-orig-addr> field, if present, contains the unique
      identifier of the MANET router that originated the message.

   o  The <msg-seq-num> field, if present, contains a sequence number
      that starts at 0 when the first message of a given type is
      generated by the originator node, and that is incremented by 1 for
      each message generated of that type.  The sequence number after
      65535 is 0.  In other words, the sequence number "wraps" in the
      usual way.

   o  If the <msg-orig-addr> and <msg-seq-num> fields are both present,
      then the Message Header provides for duplicate suppression, using
      the identifier consisting of the message's <msg-orig-addr>, <msg-
      seq-num>, and <msg-type>.  These serve to uniquely identify the
      message in the MANET within the time period until <msg-seq-num> is
      repeated, i.e., wraps around to a matching value.

   o  <msg-hop-limit> field, if present, contains the number of hops on
      which the packet is allowed to travel before being discarded by a
      MANET router.  The <msg-hop-limit> is set by the message
      originator and is used to prevent messages from endlessly
      circulating in a MANET.  When forwarding a message, a MANET router
      should decrease the <msg-hop-limit> by 1, and the message should
      be discarded when <msg-hop-limit> reaches 0.

   o  <msg-hop-count> field, if present, contains the number of hops on
      which the packet has traveled across the MANET.  The <msg-hop-
      count> is set to 0 by the message originator and is used to
      prevent messages from endlessly circulating in a MANET.  When
      forwarding a message, a MANET router should increase <msg-hop-
      count> by 1 and should discard the message when <msg-hop-count>
      reaches 255.

   o  If the <msg-hop-limit> and <msg-hop-count> fields are both
      present, then the Message Header provides the information to make
      forwarding decisions for scope-limited flooding.  This may be by
      any appropriate flooding mechanism specified by a protocol using
      this specification.

Top      Up      ToC       Page 30 
Appendix C.  Examples

   This appendix contains some examples of parts of this specification.

C.1.  Address Block Examples

   The following examples illustrate how some combinations of addresses
   may be efficiently included in Address Blocks.  These examples are
   for IPv4, with address-length equal to 4. a, b, c, etc. represent
   distinct, non-zero octet values.

   Note that it is permissible to use a less efficient representation,
   in particular one in which the ahashead and ahasfulltail flags are
   cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length
   = address-length, and (with no address prefixes) the Address Block
   consists of the number of addresses, <addr-flags> with value 0, and a
   list of the unaggregated addresses.  This is the most efficient way
   to represent a single address, and the only way to represent, for
   example, a.b.c.d and e.f.g.h in one Address Block.

   Examples:

   o  To include a.b.c.d, a.b.e.f, and a.b.g.h:

      *  head-length = 2;

      *  tail-length = 0;

      *  mid-length = 2;

      *  <addr-flags> has ahashead set (value 128);

      *  <tail-length> and <tail> are omitted.

      The Address Block is then 3 128 2 a b c d e f g h (11 octets).

   o  To include a.b.c.g and d.e.f.g:

      *  head-length = 0;

      *  tail-length = 1;

      *  mid-length = 3;

      *  <addr-flags> has ahasfulltail set (value 64);

      *  <head-length> and <head> are omitted.

Top      Up      ToC       Page 31 
      The Address Block is then 2 64 1 g a b c d e f (10 octets).

   o  To include a.b.d.e and a.c.d.e:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-flags> has ahashead and ahasfulltail set (value 192).

      The Address Block is then 2 192 1 a 2 d e b c (9 octets).

   o  To include a.b.0.0, a.c.0.0, and a.d.0.0:

      *  head-length = 1;

      *  tail-length = 2;

      *  mid-length = 1;

      *  <addr-flags> has ahashead and ahaszerotail set (value 160);

      *  <tail> is omitted.

      The Address Block is then 3 160 1 a 2 b c d (8 octets).

   o  To include a.b.0.0 and c.d.0.0:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail set (value 32);

      *  <head> and <tail> are omitted.

      The Address Block is then 2 32 2 a b c d (7 octets).

   o  To include a.b.0.0/n and c.d.0.0/n:

      *  head-length = 0;

      *  tail-length = 2;

Top      Up      ToC       Page 32 
      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail and ahassingleprelen set (value
         48);

      *  <head> and <tail> are omitted.

      The Address Block is then 2 48 2 a b c d n (8 octets).

   o  To include a.b.0.0/n and c.d.0.0/m:

      *  head-length = 0;

      *  tail-length = 2;

      *  mid-length = 2;

      *  <addr-flags> has ahaszerotail and ahasmultiprelen set (value
         40);

      *  <head> and <tail> are omitted.

      The Address Block is then 2 40 2 a b c d n m (9 octets).

C.2.  TLV Examples

   Assume the definition of an Address Block TLV with type EXAMPLE1 (and
   no type extension) that has single octet values per address.  There
   are a number of ways in which values a, a, b, and c may be associated
   with the four addresses in the preceding Address Block, where c is a
   default value that can be omitted.

   Examples:

   o  Using one multivalue TLV to cover all of the addresses:

      *  <tlv-flags> has thasvalue and tismultivalue set (value 20);

      *  <index-start> and <index-stop> are omitted;

      *  <length> = 4 (single-length = 1).

      *  The TLV is then EXAMPLE1 20 4 a a b c (7 octets).

   o  Using one multivalue TLV and omitting the last address:

      *  <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
         set (value 52);

Top      Up      ToC       Page 33 
      *  <index-start> = 0;

      *  <index-stop> = 2;

      *  <length> = 3 (single-length = 1).

      *  The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).

   o  Using two single value TLVs and omitting the last address.  First:

      *  <tlv-flags> has thasmultiindex and thasvalue set (value 48);

      *  <index-start> = 0;

      *  <index-stop> = 1;

      *  <length> = 1;

      *  <value> = a.

      *  The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).

      Second:

      *  <tlv-flags> has thassingleindex and thasvalue set (value 80);

      *  <index-start> = 2;

      *  <index-stop> is omitted;

      *  <length> = 1;

      *  <value> = b.

      *  The TLV is then EXAMPLE1 80 2 1 b (5 octets).

      Total length of TLVs is 11 octets.

   In this case, the first of these is the most efficient.  In other
   cases, patterns such as the others may be preferred.  Regardless of
   efficiency, any of these may be used.

   Assume the definition of an Address Block TLV with type EXAMPLE2 (and
   no type extension) that has no value and that is to be associated
   with the second and third addresses in an Address Block.  This can be
   indicated with a single TLV:

Top      Up      ToC       Page 34 
   o  <tlv-flags> has thasmultiindex set (value 32);

   o  <index-start> = 1;

   o  <index-stop> = 2;

   o  <length> and <value> are omitted.

   o  The TLV is then EXAMPLE2 32 1 2 (4 octets).

   Assume the definition of a Message TLV with type EXAMPLE3 (and no
   type extension) that can take a Value field of any length.  For such
   a TLV with 8 octets of data (a to h):

   o  <tlv-flags> has thasvalue set (value 16);

   o  <index-start> and <index-stop> are omitted;

   o  <length> = 8.

   o  The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).

   If, in this example, the number of data octets were 256 or greater,
   then <tlv-flags> would also have thasextlen set and have value 24.
   The length would require two octets (most significant first).  The
   TLV length would be 4 + N octets, where N is the number of data
   octets (it can be 3 + N octets if N is 255 or less).



(page 34 continued on part 3)

Next RFC Part