[Manet-dt] Expanded tlv type field for packetbb?

["Justin Dean" <[e-mail]>]

There has been some discussion among the authors of packetbb on the merits
of adding an optional extended TLV type field (as well as the comments
charlie has posted to the list.)  While attempting to write a metric TLV
document based on packetbb, for use with MANET protocols, the issue of how
to include/define multiple metric types without using up a lot of the TLV
type space came up.  By using an optional type sub field a generalized
metric TLV document can be written to allow for multiple metric types,
different sized value fields, differing value representations, and how the
metrics are to be used.  This can be done with the current TLV type field
but I can easily envision 10s if not 100s of metric types in the future.
With our current space there would be little room for official assignments.


The benefits are not limited to an unfinished not yet released TLV metric
document.  A TLV type field could be assigned to a commercial or research
entity which would then allow much more flexibility in defining TLVs by
using the subtype field, without having to resort to using the experimental
(and possibly conflicting) TLV type space in the current TLV type field.

On the negative side TLVs which used the extend type field would be 8 bits
longer per TLV.  TLVs which are concerned with 8 bits per TLV would not be
forced to use this subfield however and there would be no extra overhead
involved.  An extra semantics bit would be assigned as outlined below.  This
would make the specification slightly more complex and only 2 bits would be
left for future use in the semantics field.  (In my mind if we aren't using
them they are going to waste and if we have a good use for them we should be
using them)

The proposed changes would comprise mostly of the following. 

In Section 5.3 change to:

       <tlv> = <tlv-type>
               <tlv-semantics>
               <tlv-subtype>?               <-new optional field
               <index-start>?
               <index-stop>?
               <length>?
               <value>?


In Section 5.3 change to:

      bit 5 (hassubtype):  if cleared ('0'), then <tlv-subtype> is not
         included in <tlv>.  If set ('1'), then <tlv-subtype> is 
         included in <tlv>.

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


In Section 5.3 add:

   <tlv-subtype>  is an 8 bit field, specifying the subtype of the TLV,
      specific to the TLV type and kind (i.e. packet, message, or address
      block TLV).

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

   tlv-fulltype  is a variable, defined by:

      *  tlv-fulltype = 256 * <tlv-type> + tlv-subtype;


Section 5.3.2 change to:

   TLVs in the same TLV block MUST be sorted in ascending tlv-fulltype
   order.

   Two or more TLVs with the same tlv-fulltype associated with the same
   address block MUST NOT both cover any address.

   TLVs with the same tlv-fulltype associated with the same address block
   MUST be sorted in ascending index-start order.


In Section 6.1 Table 5 add column Subtype. In existing row set to 0.
Add new row for subtype 1-255 RESERVED.


In Section 7 change to

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

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

   A new registry for address block TLV types must be created with
   initial assignments as specified in Table 7.  Future values in the
   range 1-127 can be allocated using standards action [3].
   Additionally, values in the range 128-255 are reserved for private/
   local use.  If a TLV type is allocated a new registry for subtypes
   of that type must be created.

Justin Dean



_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt