Subject: Re: [Manet-dt] Unknown TLVs

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 30 Sep 2005 14:20:27 +0300

Hello folks,

Since the subject has been raised, I will dare to make an
initial proposal about it for comment.  I like the idea of
converged generic packet format very much.  There are
several particulars which I think need very close consideration.

The converged packet format I offer depends quite a bit
on "Message-specific data fields" after a very slim header.
I also offer a converged "address block" which is, I think,
close to the OLSR specification.   I tried to make the converged
header from scratch, so that it doesn't really look very much
like either OLSR or DYMO.  As far as I can tell, it can serve
the needs of both, with some reservations as are listed in the
design points accompanying the diagrams.

Herewith:

===============================================================

onverged routing block/Address block
		(DYMO figure 4, OLSRv2 page 51)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |# addresses|Head length|    #TLV   |  RBHopCnt |v|R|G|#|  Res  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                             Head                              :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tail      |       Tail      |       ........            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         ...........                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ........                   |       Tail      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :   List of NodeSeqNum values (one per address) [if present]    :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes: The number of "Tail" fields is always equal to the value
of the "# addresses" field.  The value of the 'v' bit controls
whether each address is considered to be an IPv6 address or an
IPv4 address.  If 'v' is set to 1, then the number of bits in
each "Tail" field is equal to (128 - "Head Length").
If 'v' is set to 0, then the number of bits in each "Tail" field
is equal to (32 - "Head Length").

If the 'G' bit is set, the first address is a gateway.
If the 'R' bit is set, "Head Length" cannot be zero, and the
first address is the default router for the implied subnet.
When the "#" bit is set, there is a list of NodeSeqNum values,
one per address.

Converged Message Header

   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      |          Len          |    TTL    |I|  flags  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                 Message-specific data fields                  :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :             Routing Block 1 (RBlock1) (if needed)             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :             Additional Routing Blocks (as needed)             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes: First routing block is assumed to belong to the originator.

This header is for a single message.  Packing multiple message TLVs
into a single message needs more discussion...!  Plus, I did not see
any indication that multiple message types would use the same
list of addresses, but I didn't study it yet.  Furthermore, the
fact that this converged message header only allows a single
message type, does not preclude making a definition for another
message type which encloses several individual messages.  If you
like, we could define this to be message type 0, and then have
a special case definition for that message type.  If this seems
to be useful or not unpopular, I would volunteer to write up the
particulars.

With only one message per packet, "Message Sequence Number" is
the same as "Packet Sequence Number".

Note that, for each message type, there are 5 flags that can be
defined in a message-specific way.  Q: should we make the 'A' bit
into a bit of the converged generic message header?

The "Message Sequence Number" field is likely to be message specific
enough so that it does not need to be in the generic header.

The "Vtime" field seems to need reconsideration anyway.  In the
first place, it is specific to certain message types.  In the
second place, I think this needs to be a protocol parameter for
any particular message type.  It seems quite weird to make the
validity time for _every_ message type to be variable per message
of that type.  I'm not even sure if we have enough confidence
yet to do it for any message type, although for RREP we are getting
closer.  Plus, if there were multiple message types wrapped together
in a single packet, I would be surprised if the same Vtime would
be valid for all of them, in general.

For instance, the message-specific data fields for the DYMO
Routing Element would be as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         TargetAddress                         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          TargetSeqNum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  THopCnt  |Res|
   +-+-+-+-+-+-+-+-+

This does not specify any alignment requirement for the converged
header.  However, since the "tail" fields can have weird lengths
in terms of number of bits, I think some words are neede to ensure
at least byte alignment if not greater.

===============================================================

Regards,
Charlie P.

PS. Sorry about the duplications for recipients.  Are all the
    CC:'s also on the design team mailing list?

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