Subject: [manet] I-D Action:draft-ietf-manet-packetbb-16.txt

From: [email-masked]
Date: Fri, 26 Sep 2008 10:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title           : Generalized MANET Packet/Message Format
	Author(s)       : T. Clausen, et al.
	Filename        : draft-ietf-manet-packetbb-16.txt
	Pages           : 61
	Date            : 2008-09-26

This document specifies a packet format capable of carrying multiple
messages that may be used by mobile ad hoc network routing protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-16.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Tue, 30 Sep 2008 10:30:22 +0200

Am Freitag 26 September 2008 19:00:01 schrieb [email-masked]:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Mobile Ad-hoc Networks
> Working Group of the IETF.
>
> draft-ietf-manet-packetbb-16.txt

I like the idea to encode the address length into the message header, this 
allows a parser to parse unknown packetbb packets without context 
information.

But the definition of the message-address-family field can be a little bit 
misleading. All fields in packetbb are octets or multiple octets, but 
<msg-flags> and <msg-addr-family> are 5/3 bits. Maybe <msg-addr-family> could 
just be considered as a three bit field of <msg-flags> so we don't have 
fields sharing a single byte.

In addition to this I would suggest two other address families:

- an address-family for MAC addresses (6 octets)
- an address family for specifying an additional 1 octet header field that 
contains the address length. This will allow the use of packetbb with any 
kind of network address without the need for proprietary address families.

The last option allows the creation of generic packetbb parser/tools (For 
example plugin for wireshark) which can parse a message with any kind of 
address type. Otherwise this tools cannot understand the _whole message_ 
because of an unknown address length.

proposal for new message-header structure:
------------------------------------------

       <msg-header> := <msg-type>
                       <msg-flags>
                       <msg-size>
                       <msg-addr-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 8 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>.

      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>.

      bit 4 (mnouniord):  If cleared ('0'), then the message TLV block
         and all address TLV blocks in the message MUST conform to the
         constraints in Section 5.4.2.  If set ('1'), then the message
         TLV block and all address TLV blocks in the message are not
         subject to the constraints in Section 5.4.2.  Additional
         constraints MAY be imposed by a protocol using this
         specification.

      bit 5-7 (msgaddrfamily): A 3 bit unsigned integer field,
         specifying the address family (and hence, the address size)
         of all addresses included in this message. The value of this
         field MUST be interpreted according to table X.

   +---------------+------------------+--------------------------------+
   | msgaddrfamily | <address-length> |         address-length         |
   +---------------+------------------+--------------------------------+
   |    0  -  6    |   not included   | size defined according to the  |
   |               |                  |  IANA registry in Section 6.2. |
   |       7       |     included     |        <address-length>        |
   +---------------+------------------+--------------------------------+

   Table X: Interpretation of of msgaddrfamily in <msg-flags>

   <address-length> if present is a 8 bit unsigned integer field, which
      contains the number of octets of all addresses included in this
      message

   address-length  is a variable whose value is the length  in octets of
      all addresses in this message, i.e. of the <msg-orig-addr> as well
      as of addresses included in address blocks as defined in Section 5.3.
      It's value is specified according to table X. For example,
      address-length is 4 if the address family is IPv4, or 16 if the
      address family is IPv6.

proposal for standard IANA registry (section 6.2):
--------------------------------------------------

    +--------+-----------------------------------+-------------------+
    | Family | Description                       | Allocation Policy |
    +--------+-----------------------------------+-------------------+
    |    0   | 4 octet IPv4 addresses [RFC791]   |                   |
    |    1   | 16 octet IPv6 addresses [RFC2460] |                   |
    |    2   | 6 octet IEEE 802 addresses        |                   |
    |   3-6  | Unassigned                        | Expert Review     |
    |    7   | Implicit specified address length |                   |
    +--------+-----------------------------------+-------------------+

Henning Rogge

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet