Mobile Ad hoc Networking (MANET) T. Clausen Internet-Draft LIX, Ecole Polytechnique, France Intended status: Standards Track C. Dearlove Expires: May 22, 2009 BAE Systems Advanced Technology Centre J. Dean Naval Research Laboratory C. Adjih INRIA Rocquencourt November 18, 2008 Generalized MANET Packet/Message Format draft-ietf-manet-packetbb-17 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2009. Abstract This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 Clausen, et al. Expires May 22, 2009 [Page 1] Internet-Draft MANET packet format November 2008 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 . . . . . . . . . . . . . . . . . . . . . 20 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 25 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 26 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 27 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 32 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 35 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 41 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 42 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 49 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 55 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 Clausen, et al. Expires May 22, 2009 [Page 2] Internet-Draft MANET packet format November 2008 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 which 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 and each associated with a packet, a message, and with 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. Clausen, et al. Expires May 22, 2009 [Page 3] Internet-Draft MANET packet format November 2008 Extensibility - Packets and messages defined by a protocol using this specification are extensible by defining new message types and new TLVs. Protocols using this specification will be able to correctly identify and skip such new message types 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 which together form a syntactic entity represented using the notation . Each element in this document is defined as either: Clausen, et al. Expires May 22, 2009 [Page 4] Internet-Draft MANET packet format November 2008 o A specifically sized field of bits; OR o A composite element, composed of other s. A composite element is defined as follows: := 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: - Indicates that is immediately followed by . () - 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: - If is an unsigned integer field then 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. Clausen, et al. Expires May 22, 2009 [Page 5] Internet-Draft MANET packet format November 2008 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 OLSR (The 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 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 (see Section 6.1), and new message types. Protocols can also reuse message and TLV type definitions from other protocols which also use this specification. This specification aims at being sufficiently expressive and flexible to be able to accommodate both 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 format, and a common way of representing IP addresses and associated attributes, allows generic parsing code to be developed, regardless Clausen, et al. Expires May 22, 2009 [Page 6] Internet-Draft MANET packet format November 2008 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 which 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 which 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 syntactical specification of a packet, represented by the element 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. Clausen, et al. Expires May 22, 2009 [Page 7] Internet-Draft MANET packet format November 2008 5.1. Packets is defined by: := * where 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. is defined by: := ? ? where: 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. is a 4 bit field, specifying the interpretation of the remainder of the packet header: bit 0 (phasseqnum): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bit 1 (phastlv): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bits 2-3: Are RESERVED, and SHOULD each be cleared ('0') on transmission, and SHOULD be ignored on reception. is omitted if the phasseqnum flag is cleared ('0'), otherwise is a 16 bit unsigned integer field, specifying a packet sequence number. 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. Clausen, et al. Expires May 22, 2009 [Page 8] Internet-Draft MANET packet format November 2008 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 TLV block, containing zero or more TLVs, following each address block, through which addresses can be associated with additional attributes. is defined by: := ()* := ? ? ? ? where: is as defined in Section 5.4. is as defined in Section 5.3. is an 8 bit unsigned integer field, specifying the type of the message. is a 4 bit field, specifying the interpretation of the remainder of the message header: bit 0 (mhasorig): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . Clausen, et al. Expires May 22, 2009 [Page 9] Internet-Draft MANET packet format November 2008 bit 1 (mhashoplimit): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bit 2 (mhashopcount): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . bit 3 (mhasseqnum): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . is a 4 bit unsigned integer field, encoding the length of all addresses included in this message ( as well as each address included in address blocks as defined in Section 5.3), as follows: = the length of an address in octets - 1 is thus 3 for IPv4 addresses, or 15 for IPv4 addresses. address-length is a variable whose value is the length of an address in octets, and is calculated as follows: address-length = + 1 is a 16 bit unsigned integer field, specifying the number of octets that make up the , including the . is omitted if the mhasorig flag is cleared ('0'), otherwise is an identifier with length equal to address-length, which can serve to uniquely identify the MANET router that originated the message. is omitted if the mhashoplimit flag is cleared ('0'), otherwise is an 8 bit unsigned integer field, which can contain the maximum number of hops that the message should be further transmitted. is omitted if the mhashopcount flag is cleared ('0'), otherwise is an 8 bit unsigned integer field, which can contain the number of hops that the message has traveled. is omitted if the mhasseqnum flag is cleared ('0'), otherwise is a 16 bit unsigned integer field, which can contain a sequence number, generated by the message's originator MANET router. Clausen, et al. Expires May 22, 2009 [Page 10] Internet-Draft MANET packet format November 2008 5.3. Address Blocks An address block can specify one or more addresses, all of which will each be address-length octets long, as specified using the in the 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 which 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. is defined by: := (?)? (?)? * * where: Clausen, et al. Expires May 22, 2009 [Page 11] Internet-Draft MANET packet format November 2008 is an 8 bit unsigned integer field containing the number of addresses represented in the address block, which MUST NOT be zero. is an 8 bit field specifying the interpretation of the remainder of the address block: bit 0 (ahashead): If cleared ('0'), then and are not included in the . If set ('1'), then is included in the , and is included in the unless 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 | | | +--------------+--------------+---------------+---------------------+ | 0 | 0 | not included | not included | | 1 | 0 | included | included unless | | | | | 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 | | nth address prefix, | | | | fields | in bits | +------------+-----------+------------------+-----------------------+ | 0 | 0 | 0 | 8 * address-length | | 1 | 0 | 1 | | | 0 | 1 | | nth | +------------+-----------+------------------+-----------------------+ Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen flags Clausen, et al. Expires May 22, 2009 [Page 12] Internet-Draft MANET packet format November 2008 if present is an 8 bit unsigned integer field, which contains the number of octets in the head of all of the addresses in the address block, i.e. each element included is octets long. head-length is a variable, defined to equal if present, or 0 otherwise. 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. if present is an 8 bit unsigned integer field, which contains the number of octets in the tail of all of the addresses in the address block, i.e. each element included is octets long. tail-length is a variable, defined to equal if present, or 0 otherwise. 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 all 0. mid-length is a variable, which MUST be non-negative, defined by: mid-length := address-length - head-length - tail-length i.e. each element included is mid-length octets long. is omitted if mid-length is equal to 0, otherwise each 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 fields. 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 field is included, which contains the prefix length of all addresses in the address block. If the ahasmultiprelen flag is set ('1') then 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 fields are present; each address object can be considered to have a prefix length equal to 8 * address-length bits. The address block Clausen, et al. Expires May 22, 2009 [Page 13] Internet-Draft MANET packet format November 2008 is malformed if any element has a value greater than 8 * address-length. 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 which 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: := * where: is a 16 bit unsigned integer field, which contains the total number of octets in all of the immediately following elements ( not included). is as defined in Section 5.4.1. 5.4.1. TLVs There are three kinds of TLV, each represented by an element : 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 TLV block following an address block. An address block TLV applies to: Clausen, et al. Expires May 22, 2009 [Page 14] Internet-Draft MANET packet format November 2008 * 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. is defined by: := ? (?)? (?)? where: is an 8 bit unsigned integer field, specifying the type of the TLV, specific to the TLV kind (i.e. packet, message, or address block TLV). is an 8 bit field specifying the interpretation of the remainder of the TLV: bit 0 (thastypeext): If cleared ('0'), then is not included in the . If set ('1'), then is included in the . 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 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 field is interpreted, as specified below. This flag MUST be cleared ('0') in packet 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. Clausen, et al. Expires May 22, 2009 [Page 15] Internet-Draft MANET packet format November 2008 +-----------------+----------------+---------------+--------------+ | thassingleindex | thasmultiindex | | | +-----------------+----------------+---------------+--------------+ | 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 | | | +-----------+------------+--------------+---------------------------+ | 0 | 0 | not included | not included | | 1 | 0 | 8 bits | included unless | | | | | is zero | | 1 | 1 | 16 bits | included unless | | | | | is zero | +-----------+------------+--------------+---------------------------+ Table 4: Interpretation of the thasvalue and thasextlen flags is an 8 bit unsigned integer field, specifying an extension of the TLV type, specific to the TLV type and kind (i.e. packet, message, or address block TLV). tlv-type-ext is a variable, defined to equal if present, or 0 otherwise. tlv-fulltype is a variable, defined by: tlv-fulltype := 256 * + tlv-type-ext and 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 and packet TLVs: end-index := 0 * For address block TLVs: end-index := - 1 Clausen, et al. Expires May 22, 2009 [Page 16] Internet-Draft MANET packet format November 2008 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 | | | | 0 | 1 | | | +-----------------+----------------+----------------+---------------+ Table 5: Interpretation of the thassingleindex and thasmultiindex flags number-values is a variable, defined by: number-values := index-stop - index-start + 1 is omitted or is an 8 or 16 bit unsigned integer field according to Table 4. If the tismultivalue flag is set ('1') then MUST be an integral multiple of number-values, and the variable single-length is defined by: single-length := / number-values If the tismultivalue flag is cleared ('0'), then the variable single-length is defined by: single-length := if present (see Table 4) is a field of length octets. In an address block TLV, 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 (including order of processing) between different attributes associated with the same entity MUST be defined by any protocol which uses this Clausen, et al. Expires May 22, 2009 [Page 17] Internet-Draft MANET packet format November 2008 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. 6. IANA Considerations This document introduces four namespaces that require registration: 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", "Designated Expert". The following policies are used with the meanings defined in [BCP26]: "Private Use", "Expert Review", "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 purposes of these registries are to support Standard and Experimental MANET routing and related protocols, and extensions to the same. o The intention is that all registrations will be accompanied by a published RFC. Clausen, et al. Expires May 22, 2009 [Page 18] Internet-Draft MANET packet format November 2008 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 informing 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 which 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 which 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 be 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 of, and meaning of, the value field (if any) of the TLV. For the registries for Message TLV Types and Address Block TLV Types, the following additional guidelines apply: Clausen, et al. Expires May 22, 2009 [Page 19] Internet-Draft MANET packet format November 2008 o TLV type values 0-127 are common for all message types. TLVs which 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 which 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 must be 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 which creates a message type specific TLV registry MUST also specify the mechanism by which message specific TLV types are allocated, from among those in [BCP26]. 6.3. Packet TLV Types A new registry for packet TLV types must be created, with initial assignments and allocation policies as specified in Table 7. Clausen, et al. Expires May 22, 2009 [Page 20] Internet-Draft MANET packet format November 2008 +---------+-------------+-------------------+ | 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 which 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 must be 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. +---------+-----------------------------+-------------------+ | 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 Specific Message TLV Types Clausen, et al. Expires May 22, 2009 [Page 21] Internet-Draft MANET packet format November 2008 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 which 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 must be 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. +---------+-----------------------------+-------------------+ | 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 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. Clausen, et al. Expires May 22, 2009 [Page 22] Internet-Draft MANET packet format November 2008 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 which 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 which may form part of an authentication and integrity approach in a protocol using this specification, are described in Section 7.1. Mechanisms which 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. Consequently: o For forwarded messages where the message is unchanged by forwarding MANET routers, then 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 and 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 and fields set to 0 if present. Clausen, et al. Expires May 22, 2009 [Page 23] Internet-Draft MANET packet format November 2008 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 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. Clausen, et al. Expires May 22, 2009 [Page 24] Internet-Draft MANET packet format November 2008 8. References 8.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", RFC 5226, BCP 26, 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. 8.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. 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 from different protocols. Thus, a multiplexing and demultiplexing process MUST be present. Multiplexing messages on a given MANET router into a single packet, rather than to have 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. Clausen, et al. Expires May 22, 2009 [Page 25] Internet-Draft MANET packet format November 2008 o The packet header fields, including the Packet TLV block, is used by the multiplexing and demultiplexing process, which MAY make such information available for use its protocol instances. o The field, if present, contains a sequence number which 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 which 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 which owns that message type and 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 which 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. 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 by: o The field, if present, contains the unique identifier of the MANET router which originated the message. o The field, if present, contains a sequence number which starts at 0 when first message of a given type is generated by the originator node, and 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. Clausen, et al. Expires May 22, 2009 [Page 26] Internet-Draft MANET packet format November 2008 o If the and fields are both present, then the message header provides for duplicate suppression, using the identifier consisting of the message's , , and . These serve to uniquely identify the message in the MANET within the time period until is repeated, i.e. wraps around to a matching value. o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The 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 by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the packet has traveled across the MANET. The by 1 and should discard the message when reaches 255. o If the and 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. 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, 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. Clausen, et al. Expires May 22, 2009 [Page 27] Internet-Draft MANET packet format November 2008 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; * has ahashead set (value 128); * and 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; * has ahasfulltail set (value 64); * and are omitted. 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; * 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; Clausen, et al. Expires May 22, 2009 [Page 28] Internet-Draft MANET packet format November 2008 * mid-length = 1; * has ahashead and ahaszerotail set (value 160); * 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; * has ahaszerotail set (value 32); * and 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; * mid-length = 2; * has ahaszerotail and ahassingleprelen set (value 48); * and 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; * has ahaszerotail and ahasmultiprelen set (value 40); Clausen, et al. Expires May 22, 2009 [Page 29] Internet-Draft MANET packet format November 2008 * and are omitted. The address block is then 2 40 2 a b c d n m (9 octets). C.2. TLV Examples Assuming the definition of an address block TLV with type EXAMPLE1 (and no type extension) which has single octet values per address, then if values a, a, b and c are to be associated with the four addresses in the preceding address block, where c is a default value that can be omitted, then this can be done in a number of ways. Examples: o Using one multivalue TLV covering all of the addresses: * has thasvalue and tismultivalue set (value 20); * and are omitted; * = 4 (single-length = 1). * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). o Using one multivalue TLV omitting the last address: * has thasmultiindex, thasvalue and tismultivalue set (value 52); * = 0; * = 2 * = 3 (single-length = 1). * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). o Using two single value TLVs, omitting the last address. First: * has thasmultiindex and thasvalue set (value 48); * = 0; * = 1; * = 1; Clausen, et al. Expires May 22, 2009 [Page 30] Internet-Draft MANET packet format November 2008 * = a. * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). Second: * has thassingleindex and thasvalue set (value 80); * = 2; * is omitted; * = 1; * = 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. Assuming the definition of an address block TLV with type EXAMPLE2 (and no type extension) which has no value, which is to be associated with the second and third addresses in an address block, then this can be indicated with a single TLV: o has thasmultiindex set (value 32); o = 1; o = 2; o and are omitted. o The TLV is then EXAMPLE2 32 1 2 (4 octets). Assuming the definition of a message TLV with type EXAMPLE3 (and no type extension) which can take a value field of any length, for such a TLV with 8 octets of data (a to h): o has thasvalue set (value 16); o and are omitted; Clausen, et al. Expires May 22, 2009 [Page 31] Internet-Draft MANET packet format November 2008 o = 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 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). Appendix D. Illustrations This informative appendix illustrates the elements which are normatively specified in Section 5. Bits labeled Rsv should be cleared ('0'). Bits labeled M may be cleared ('0') or set ('1'). D.1. Packet Possible options for the element. These are differentiated by the flags field in the first octet. The packet may include any number (zero or more) of Messages. The number of Messages is determined from when the packet is exhausted, given the packet length from the network layer. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|Rsv| | +-+-+-+-+-+-+-+-+ | | Message | | | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 32] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|Rsv| Packet Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 33] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|Rsv| | +-+-+-+-+-+-+-+-+ | | | | Packet TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ | | Message | | | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 34] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|Rsv| Packet Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Packet TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.2. Message Possible options for the element. These are differentiated by their second (flags) octet. The length of the Message Body is determined using the Message Size field, which is the combined length of all the fields shown. The field labeled MAL defines the length of all addresses (including the Originator Address, if present, and all addresses in address blocks) in octets, as one more than the value in the field. Clausen, et al. Expires May 22, 2009 [Page 35] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|0|0|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|0|0|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|1|0|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | | +-+-+-+-+-+-+-+-+ | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 36] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|1|0|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | | +-+-+-+-+-+-+-+-+ | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|0|1|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | | +-+-+-+-+-+-+-+-+ | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|0|1|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | | +-+-+-+-+-+-+-+-+ | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 37] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|1|1|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|1|1|0| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|0|0|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 38] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|0|0|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|1|0|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|1|0|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 39] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|0|1|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|0|1|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |0|1|1|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 40] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type |1|1|1|1| MAL | Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.3. Message Body Format of a message body (the element excluding its initial element). The message body includes one Message TLV Block (containing zero or more TLVs) and may include any number (zero or more) of Address Block and Address TLV Block pairs. Clausen, et al. Expires May 22, 2009 [Page 41] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message TLV Block | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Address Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ | | Address TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Address Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Address TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.4. Address Block Possible options for the element. These are differentiated by their second (flags) octet. The number of Mid elements is equal to the number of addresses (except when mid-length is zero, when there are no Mid elements). Where a variable number of Prefix Length fields is shown, their number is equal to the number of addresses. Clausen, et al. Expires May 22, 2009 [Page 42] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|0|0|0| Rsv | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|0|0|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|1|0|0|0| Rsv | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 43] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|1|0|0|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|1|0|0| Rsv | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|1|0|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 44] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|0|1|0| Rsv | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|0|1|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|1|0|1|0| Rsv | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 45] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|1|0|1|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | +-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|1|1|0| Rsv | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|1|1|0| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 46] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|0|0|1| Rsv | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|0|0|1| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 47] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|1|0|0|1| Rsv | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail (cont) | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|1|0|0|1| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Tail | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ | : ... : | +-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 48] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |0|0|1|0|1| Rsv | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | | +-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Addrs |1|0|1|0|1| Rsv | Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Tail Length | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.5. TLV Block Format of a element. There may be any number (zero or more) of TLVs, with total length of the TLVs (in octets) equal to the Length field. Clausen, et al. Expires May 22, 2009 [Page 49] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | TLV | | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | TLV | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.6. TLV Possible options for the element. These are differentiated by their second (flags) octet. If there are no index fields then this may be a packet, message or address block TLV, if there are one or two index fields then this must be an address block TLV. The Length field gives the length of the value field (in octets). 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 |0|0|0|0|0|0|Rsv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|0|0|0|0|Rsv| Type Ext | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |0|1|0|0|0|0|Rsv| Index Start | Clausen, et al. Expires May 22, 2009 [Page 50] Internet-Draft MANET packet format November 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|1|0|0|0|0|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |0|0|1|0|0|0|Rsv| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |1|0|1|0|0|0|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Stop | +-+-+-+-+-+-+-+-+ 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 |0|0|0|1|0|M|Rsv| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 51] Internet-Draft MANET packet format November 2008 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 |1|0|0|1|0|M|Rsv| Type Ext | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |0|1|0|1|0|0|Rsv| Index Start | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |1|1|0|1|0|0|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 52] Internet-Draft MANET packet format November 2008 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 |0|0|1|1|0|M|Rsv| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |1|0|1|1|0|M|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Stop | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |0|0|0|0|1|M|Rsv| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 53] Internet-Draft MANET packet format November 2008 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 |1|0|0|1|1|M|Rsv| Type Ext | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (cont) | | +-+-+-+-+-+-+-+-+ | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |0|1|0|1|1|0|Rsv| Index Start | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (cont) | | +-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |1|1|0|1|1|0|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Clausen, et al. Expires May 22, 2009 [Page 54] Internet-Draft MANET packet format November 2008 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 |0|0|1|1|1|M|Rsv| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ 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 |1|0|1|1|1|M|Rsv| Type Ext | Index Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Stop | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Appendix E. Complete Example The following example packet is included with the intent to exemplify how packet and message headers are constructed, and how addresses and attributes are encoded using address blocks and TLV blocks. This example is specifically not constructed to exhibit maximum message or packet size reduction. Appendix D contains illustrations of all syntactical elements. The packet header has the phasseqnum flag set of its flags field set (value 8), and hence has a Packet Sequence Number, but no packet TLV block. The packet contains a single message with length 54 octets. This message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum flags of its four bit flags field set (value 15), and hence includes an Originator Address, a Hop Limit, a Hop Count and a Message Sequence Number (which is type independent). Its four bit message address length field has value 3 and hence addresses in the message Clausen, et al. Expires May 22, 2009 [Page 55] Internet-Draft MANET packet format November 2008 have length four octets, here being IPv4 addresses. The message has a message TLV block with content length 9 octets, containing a single message TLV. This TLV has the thasvalue flag of its flags octet set (value 16), and hence contains a Value field, with preceding value length 6 octets. The message then has two address blocks each with a following address TLV block. The first address block contains 2 address prefixes. It has the ahaszerotail and ahassingleprelen flags of its flags octet set (value 48), and hence has no head (head-length is zero octets). It has a tail-length of 2 octets, hence mid-length is two octets. The two tail octets of each address are not included (since ahaszerotail is set) and have value zero. The address block has a single Prefix Length. The following address TLV block is empty (content length 0 octets). The second address block contains 3 addresses. It has the ahashead flag of its flags octet set (value 128), and has head length 2 octets, no tail (tail-length is zero octets) and hence mid-length is two octets. It is followed by an address TLV block, with content length 9 octets, containing two address block TLVs. The first of these TLVs has the thasvalue flag of its flags octet set (value 16), and has a single Value of length 2 octets, which applies to all of the addresses in the address block. The second of these TLVs has the thasmultiindex flag of its flags octet set (value 32), and hence has no value length or value fields. It has two index fields (Index Start and Index Stop), which indicate those addresses this TLV applies to (inclusive range, counting from zero). Clausen, et al. Expires May 22, 2009 [Page 56] Internet-Draft MANET packet format November 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address (cont) | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont) |0 0 0 0 0 0 1 0|0 0 1 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Prefix Length |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Head (cont) | Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Mid |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | TLV Type |0 0 1 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix F. 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, o Emmanuel Baccelli, INRIA, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, Clausen, et al. Expires May 22, 2009 [Page 57] Internet-Draft MANET packet format November 2008 o Justin W. Dean, NRL, USA, o Christopher Dearlove, BAE Systems, UK, o Satoh Hiroki, Hitachi SDL, Japan, o Philippe Jacquet, INRIA, France, o Monden Kazuya, Hitachi SDL, Japan, Appendix G. 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): o Brian Adamson (NRL) o Teco Boot (Infinity Networks) o Florent Brunneau (LIX) o Ian Chakeres (Motorola) o Alan Cullen (BAE Systems) o Ulrich Herberg (LIX) o Joe Macker (NRL) o Yasunori Owada (Niigata University) o Henning Rogge (FGAN) o Charlie E. Perkins (WiChorus) o Andreas Schjonhaug (LIX) Clausen, et al. Expires May 22, 2009 [Page 58] Internet-Draft MANET packet format November 2008 and the entire IETF MANET working group. Authors' Addresses Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.thomasclausen.org/ Christopher M. Dearlove BAE Systems Advanced Technology Centre Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Justin W. Dean Naval Research Laboratory Phone: +1 202 767 3397 EMail: jdean@itd.nrl.navy.mil URI: http://pf.itd.nrl.navy.mil/ Cedric Adjih INRIA Rocquencourt Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr URI: http://menetou.inria.fr/~adjih/ Clausen, et al. Expires May 22, 2009 [Page 59] Internet-Draft MANET packet format November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Clausen, et al. Expires May 22, 2009 [Page 60]