Mobile Ad hoc Networking (MANET) T. Clausen Internet-Draft LIX, Ecole Polytechnique, France Expires: December 21, 2006 C. Dearlove BAE Systems Advanced Technology Centre J. Dean Naval Research Laboratory C. Adjih INRIA Rocquencourt June 19, 2006 Generalized MANET Packet/Message Format draft-ietf-manet-packetbb-01 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a generalized multi-message packet format which may be used by mobile ad hoc network routing and other Clausen, et al. Expires December 21, 2006 [Page 1] Internet-Draft MANET packet format June 2006 protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 7 5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 12 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 17 5.4. Message Content Fragmentation . . . . . . . . . . . . . . 17 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Message TLV Specification . . . . . . . . . . . . . . . . 20 6.2. Address Block TLV Specification . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Packet and Message Layout . . . . . . . . . . . . . 26 Appendix A.1. General Packet Format . . . . . . . . . . . . . . . 26 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 41 Clausen, et al. Expires December 21, 2006 [Page 2] Internet-Draft MANET packet format June 2006 1. Introduction Signaling in a mobile ad hoc network routing protocol consists, mainly, of stating IP addresses and attributes associated to such IP addresses. Since this is a task common to many such protocols, this specification presents a generalized signaling framework, which may be employed both by mobile ad hoc network routing protocols and other protocols with similar signaling requirements. The framework consists of a specification of: o a mechanism whereby message types can be specified and (regardless of type, whether known or unknown) can be correctly parsed and forwarded; o a generalized multi-message packet format, allowing multiple messages to be contained within a single transmission; o a message format, composed of a message header and a message body, with the message header containing *all* necessary information to allow a node to make forwarding and processing decisions without resorting to inspecting the message body. The message header information permits single- and multi-hop diffusion whilst supporting scope controlled multicast and unicast use of the format; o a message body structure, encouraging uniform message parsing, regardless of message body content; o a mechanism whereby addresses can be represented in a compact way (address compression); o an extensibility mechanism whereby arbitrary attributes, through TLVs (type-length-value triplets), can be included and associated with a message, an address or a set of addresses, while being correctly parseable by a generic message parser. An important design criterion behind this specification is to allow development of easy parsing logic, even in the face of a flexible format. This implies that, given an incoming control message, a single parser is able to process the message independent of type and present, to a protocol using this specification, an abstraction of addresses with associated attributes directly. The information contained in the message header furthermore allows the recipient node to recognize duplicates and make appropriate forwarding decisions. Additionally, the signaling framework in this specification is developed with the objective of minimizing the complexity of this parser by providing a straightforward message layout. Clausen, et al. Expires December 21, 2006 [Page 3] Internet-Draft MANET packet format June 2006 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. Additionally, this document uses the following terminology: Address - an address of the same type and length as the source IP address in the IP datagram carrying the packet. TLV - Type-Length-Value structure. This is a generic way in which an attribute can be represented and correctly parsed, without knowing the content, or understanding the type of the attribute by the parser. This allows internal extensibility, i.e. for a protocol extension to add arbitrary attributes within a control message. ? - zero or one occurrences of the preceding element. * - zero or more occurrences of the preceding element. + - one or more occurrences of the preceding element. - An element specified in the parsing of a packet, message or other entity. If is an 8 or 16 bit 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 field(s). Variables are introduced in the specification solely as a means to clarify the description. address-length - A variable whose value is the length of an address in octets, i.e. it is 4 if using IPv4, or 16 if using IPv6. Clausen, et al. Expires December 21, 2006 [Page 4] Internet-Draft MANET packet format June 2006 3. Applicability Statement This specification describes a generic multi-message packet format, for carrying MANET routing protocol signals. The specification has been developed from that used by OLSR [3]. The specification is designed specifically with IP (IPv4/IPv6) in mind. All addresses within a control message are assumed to be of the same size, deduced from IP. In the case of mixed IPv6 and IPv4 addresses, IPv4 addresses are carried in IPv6 as specified in [2]. The packets defined by this specification may use any transport protocol appropriate to the protocol using this specification. When the diffusion mechanism enabled by this specification is employed, UDP may be most appropriate. The multi-message package format in this specification is characterized by lending itself to low-complexity parsing logic, as well as to an efficient parsing for low-capacity routers. The header information in each message suffices to allow for each message to be forwarded (if required) and delivered correctly with regards to the message's delivery semantics, without parsing and inspecting the message body. The specification accommodates two types of extensibility: "external extensibility", whereby new message types can be specified and (regardless of type) still be correctly forwarded and parsed using the simple parsing logic, and "internal extensibility", whereby new attributes can be included in existing message types while these can still be correctly forwarded and parsed using the simple parsing logic. Clausen, et al. Expires December 21, 2006 [Page 5] Internet-Draft MANET packet format June 2006 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 or other protocol. Clausen, et al. Expires December 21, 2006 [Page 6] Internet-Draft MANET packet format June 2006 5. Signaling Framework This section provides abstract descriptions of message and packet formats. 5.1. Packet Format Messages are carried in a general packet format, allowing piggybacking of several independent messages in a single packet transmission. The packet format conforms to the following specification: = {*}? {*}* where is defined in Section 5.2, and with conforming to the following specification: is an 8 bit field with all bits cleared ('0'). The use of is detailed in Section 5.1.1. is defined by: = ? ? with the elements of conforming to the following specification: is an 8 bit field with all bits cleared ('0'). This field serves to identify if the packet starts with a packet header. is an 8 bit field, which specifies the composition of the packet header: bit 0 (pseqnum) indicates, if cleared ('0'), that the packet header contains a . If set ('1'), the packet header does not include a . bit 1 (ptlv) indicates, if cleared ('0'), that the packet header does not include a TLV block. If set ('1'), the packet header includes a TLV block. Clausen, et al. Expires December 21, 2006 [Page 7] Internet-Draft MANET packet format June 2006 bits 2-7 are reserved, and SHOULD each be cleared ('0'). is omitted if the pseqnum bit is set ('1'), otherwise it is a 16 bit field, which specifies a packet sequence number. If used, a separate packet sequence number MUST be maintained for each transmitting interface. Each packet sequence number MUST be incremented by one each time a packet, as defined in this document and which includes the packet sequence number, is transmitted over this interface. is omitted if the ptlv bit is cleared ('0'), otherwise it is a TLV block as specified in Section 5.3. Note that since the message type zero is reserved (see Section 7), the presence or absence of a packet header can be determined by inspecting the first octet of the packet. 5.1.1. Padding Packet headers and messages can be padded to ensure 32 bit alignment of each message contained within the packet. 5.1.1.1. Packet Header Padding The packet header specification in Section 5.1 ensures that a packet header consists of an integral number of octets, with all defined syntactical entities (, , , ) being octet-aligned. The first in a packet can be 32 bit aligned by adding the appropriate number of s subsequent to the . The number of s required to achieve this 32 bit alignment is calculated as the smallest number which, when added to the size of the packet header (if any) and the size of the (if any) and the size of the fixed part of the header (the and fields, which are each one octet long) produces an integer multiple of 4. If the contains a and no , (i.e. if both the pseqnum and ptlv bits are cleared) then there SHOULD NOT be any subsequent to the , since then the has length exactly 4 octets and the first is then already 32 bit aligned. There is no need to indicate if padding is included subsequent to the packet header: the first octet of a message (see Section 5.2 cannot be zero. Thus, if after processing the packet header a recipient Clausen, et al. Expires December 21, 2006 [Page 8] Internet-Draft MANET packet format June 2006 reads an octet with all bits cleared ('0'), this read octet is padding. 5.1.1.2. Message Padding The message specification in Section 5.2 ensures that a message consists of an integral number of octets, with all defined syntactical entities (, , etc.) being octet-aligned. The first message can be 32 bit aligned by using packet header padding, as described in Section 5.1.1.1. Subsequent messages (and, hence, also the , if any), can be 32 bit aligned by adding the appropriate number of s subsequent to each message. (When added to the last message this instead ensures that the overall packet is a multiple of 32 bits in length.) The number of s required to achieve 32 bit alignment of the end of message (and hence the start of the next, if any), assuming that the start of the message is 32 bit aligned, is calculated as the smallest number which when added to produces a multiple of 4. There is no need to indicate if padding is included subsequent to a message: the first octet of a message (see Section 5.2) cannot be zero. Thus if after processing a message a recipient reads any octets with all bits cleared ('0'), these read octets are padding. The does not include padding. The padding after a message may be freely changed when a message is forwarded without affecting the message. 5.2. Messages Information is carried through "messages". Messages may contain: o zero or more TLVs, associated with the whole message; o a set of addresses about which the originating node wishes to convey information. These addresses MAY be divided into one or more address blocks; o zero or more TLVs following each address block. These are explained in more detail in Section 5.3.1 and convey information about the addresses in that address block. A message also contains a message header, which can be parsed without examining the remainder of the packet, and which contains information Clausen, et al. Expires December 21, 2006 [Page 9] Internet-Draft MANET packet format June 2006 sufficient to allow the recipient to: o recognize duplicate messages; o determine considerations for forwarding; o manage controlled-scope diffusion of messages. Message content MAY (e.g. due to size limitations) be fragmented. Each fragment is transmitted such that it makes up a syntactically correct message (i.e. all headers are set as if each fragment is a message in its own right, and each message contains all necessary message TLVs). Content fragmentation is detailed in Section 5.4. A message has the following general layout: = {}* = = ? ? ? ? The elements of are included according to the flags in as described below. The elements used above conform to the following specification: is as specified in Section 5.3 is a block of addresses, with which the originator of the message has a special relationship, specific to the protocol using this specification. Address blocks are specified in Section 5.2.1; is an 8 bit field, which specifies the type of message. A type with all bits cleared ('0') MUST NOT be used. The two most significant bits are allocated with the following semantics: Clausen, et al. Expires December 21, 2006 [Page 10] Internet-Draft MANET packet format June 2006 bit 7 (msg-user): message types with this bit cleared ('0') are defined in this specification or can be allocated via standards action. Message types with this bit set ('1') are reserved for private/local use. bit 6 (msg-protocol): for message types with the msg-user bit cleared ('0'), this bit specifies, if cleared ('0'), that the message type is protocol independent, i.e. is not specific to any one protocol, or, if set ('1'), that the message type is specific to the protocol for which it is defined. is an 8 bit field, which specifies the interpretation of the remainder of the message header and the processing which can be undertaken only parsing the message header: bit 0 (noorig): indicates, if cleared ('0') that the elements and in the be included, as specified in the above. If set ('1'), a reduced header which does not include and is used; this reduced header does not provide provisions for duplicate suppression; bit 1 (nohops): indicates, if cleared ('0') that the elements and in the be included, as specified in the above. If set ('1'), a reduced header which does not include the elements from the is used; this reduced header does not provide provisions for scope-delimited forwarding; bit 2 (typedep): indicates, if cleared ('0'), that the message sequence number in the message is type-independent. If set ('1'), the message sequence number contained in the message is type dependent, i.e. the source of the message maintains a sequence number separately for the type indicated in the field; this bit SHALL be cleared ('0') if there is no message sequence number, i.e. if the noorig bit is set; bits 3-7: are RESERVED and SHALL each be cleared ('0') to be in conformance with this version of the specification. is a 16 bit field, which specifies the size of the and the following , counted in octets; is the address of an interface of the node, which originated the message. Its length is equal to address- length octets. Each node SHOULD select one of its interface addresses as its "originator address" and MUST utilize this address consistently as the in all messages Clausen, et al. Expires December 21, 2006 [Page 11] Internet-Draft MANET packet format June 2006 it generates which include this field. Note that the originator address is distinct from the IP source address, and that the same originator address MUST be used regardless of which interface a message is transmitted on. Also note that if a message is retransmitted the originator address MUST NOT be changed; is an 8 bit field, which contains the maximum number of hops a message will be transmitted. Before a message is retransmitted, the hop-limit MUST be decremented by 1. When a node receives a message with a hop-limit equal to 0 or 1, the message MUST NOT be retransmitted under any circumstances. Normally, a node will not receive a message with a hop-limit of 0 (note that this hop-limit is distinct from the IPv6 hop-limit); is an 8 bit field, which contains the number of hops a message has traveled. Before a message is retransmitted, the hop- count MUST be incremented by 1. Initially, this hop-count SHOULD be set to 0 by the originator of the message; is a 16 bit field, which contains a unique number, generated by the originator node. The originator-address, msg- seq-number and, if the typedep bit in the field is set, the of a message serves to uniquely identify the message in the network (allowing, among other things, duplicate elimination). 5.2.1. Address Blocks An address block represents a set of addresses in a compact and simple form. Assuming that an address can be specified as a sequence of bits of the form 'head:mid:tail', then an address block is a set of addresses sharing the same 'head' and 'tail' and having different 'mids'. (The case where the 'tail' is empty is treated specially, as is the case where the 'tail' consists of zero-valued octets, the latter is particularly appropriate when used with a TLV indicating a prefix length, see Section 6.2.) Specifically, an address block conforms to the following specification: = ? ? ? * with the elements defined thus: Clausen, et al. Expires December 21, 2006 [Page 12] Internet-Draft MANET packet format June 2006 is an 8 bit field containing the number of addresses represented in the address block, which MUST NOT be zero. It is equal to the number of s following (except when, as defined below, mid-length == 0 and no s are required); is an 8 bit field, where: bits 0-6: contain the length of the , if any. The corresponding variable head-length is calculated by: head-length = & 127 bit 7 (notail): indicates, if cleared ('0'), that the address block contains a (see below), if set ('1') that no is included; is omitted if head-length == 0, otherwise it is a field of head-length octets which contains the leftmost octets which the addresses in the block have in common (it SHOULD contain the longest such sequence); is omitted if the notail bit is set ('1'), otherwise it is an 8 bit field, where: bits 0-6: contain the length of the , if any, or the equivalent number of zero-valued tail octets. The corresponding variable tail-length is calculated by: tail-length = & 127 bit 7 (zerotail): indicates, if cleared ('0'), that a (see below) is included, if set ('1') that no is included, and that the tail-length rightmost octets of each address in the block are zero-valued; If the is omitted then tail-length = 0. is omitted if tail-length == 0 or the zerotail bit is set ('1'), otherwise it is a field of length tail-length octets which contains the rightmost octets which the addresses in the block have in common (it SHOULD contain the longest such sequence in this case); If tail-length != 0 and the zerotail bit is set ('1') then all the addresses in the block have tail-length zero-valued rightmost octets (tail-length SHOULD be the largest such number in this case); Clausen, et al. Expires December 21, 2006 [Page 13] Internet-Draft MANET packet format June 2006 mid-length is a variable, calculated by: mid-length = address-length - head-length - tail-length mid-length MUST be non-negative. is omitted if mid-length == 0 (in which case all addresses in the block are the same), otherwise each is a field of length mid-length octets, representing the 'mid' of the corresponding address in the address block. This representation aims at providing a flexible, yet compact, way of representing sets of addresses. 5.3. TLVs and TLV Blocks A TLV block has the following general layout: = * with the elements defined thus: is a 16 bit field, which contains the total length (in octets) of the immediately following TLV(s). It does not include its own length, thus if no TLVs follow, this field contains zero; is a TLV, providing information regarding the entire packet or message or the address block which it follows. TLVs are specified in Section 5.3.1; 5.3.1. TLVs A TLV is a carrier of information, relative to a packet, to a message or to addresses in an address block. A TLV associated with an address block specifies some attribute(s), which are associated with address(es) in the address-block. In order to provide the largest amount of flexibility to benefit from address aggregation as described in Section 5.2.1, a TLV associated to an address block can apply to: o all addresses in the address block; o any continuous sequence of addresses in the address block; o a single address in the address block. Clausen, et al. Expires December 21, 2006 [Page 14] Internet-Draft MANET packet format June 2006 All TLVs conform to the following specification: = ? ? ? ? where the elements are defined thus: is an 8 bit field, which specifies the type of the TLV. The two most significant bits are allocated with the following semantics: bit 7 (tlv-user): TLV types with this bit cleared ('0') are defined in this specification or can be allocated via standards action. TLV types with this bit set ('1') are reserved for private/local use. bit 6 (msg-protocol): for TLV types with the tlv-user bit cleared ('0'), this bit specifies, if cleared ('0'), that the TLV type is protocol independent, i.e. is not specific to any one protocol, or, if set ('1'), that the TLV type is specific to the protocol for which it is defined. is an 8 bit field which specifies the semantics of the TLV according to the following: bit 0 (novalue): if cleared ('0') contains and elements. TLVs with this bit set ('1') contains no or elements - the TLV type carries all the information needed. bit 1 (extended): if cleared ('0'), the size of the length field is 8 bits. If set ('1'), the size of the length field is 16 bits. This bit MUST be cleared ('0') if the novalue bit is set ('1'). bit 2 (noindex): if cleared ('0'), the and elements are included. If set ('1'), the and elements are not included. This bit MUST be set for packet or message TLVs. If this bit is set ('1') for address block TLVs, the TLV applies to all addresses in the address block. Clausen, et al. Expires December 21, 2006 [Page 15] Internet-Draft MANET packet format June 2006 bit 3 (multivalue): if cleared ('0'), the TLV includes a single value which applies to all addresses described by and . If set ('1'), the TLV includes separate values for each of the addresses indicated by and . This bit MUST be cleared ('0') for packet or message TLVs or if the novalue bit is set ('1'). bits 4-7: are RESERVED and SHALL each be cleared ('0'). is omitted if the noindex bit is set ('1'), otherwise it is an 8 bit field. In the former case, the variable index- start is defined by: index-start = in the latter case, the variable index-start is defined by: index-start = 0 If this TLV is associated with an address block then index-start specifies the index of the first address in the address block (starting at zero) for which this TLV applies; is omitted if the noindex bit is set ('1'), otherwise it is an 8 bit field. In the former case, the variable index-stop is defined by: index-stop = in the latter case, for a TLV associated with an address block with addresses the variable index-stop is defined by: index-stop = - 1 otherwise (a TLV associated with a packet or a message) the variable index-stop is defined by: index-stop = 0 If this TLV is associated with an address block then index-stop specifies the index of the last address in the address block (starting at zero) for which this TLV applies. number-values is a variable, defined by Clausen, et al. Expires December 21, 2006 [Page 16] Internet-Draft MANET packet format June 2006 number-values = - + 1 If this TLV is associated with an address block then number-values is the number of addresses in that block to which this TLV applies, otherwise it is 1. is omitted if the novalue bit is set ('1'), otherwise it is an 8 bit or 16 bit field, according to whether the extended bit is cleared ('0') or set ('1'), respectively. If present this field specifies the length, counted in octets, of the data contained in . If the multivalue bit is set ('1') then MUST be an integral multiple of number-values and the variable single- length is defined by single-length = / number-values otherwise, if the multivalue bit is cleared ('0'), the variable single-length is defined by single-length = is omitted if the novalue bit is set ('1'), Otherwise it is a field of length octets. If the multivalue bit is cleared ('0') then this field is associated with the packet, message or the relevant addresses (from index-start to index-stop) in the address block with which this TLV is associated, as appropriate. If the multivalue bit 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, to the relevant addresses (from index-start to index-stop) in the address block with which this TLV is associated. The association is interpreted according to the field. 5.3.2. Constraints TLVs in the same SHALL be sorted in ascending TLV type order. Two or more TLVs of the same type associated with the same SHALL NOT both cover any index (address). TLVs of the same type associated with the same SHALL be sorted in ascending order. 5.4. Message Content Fragmentation A message may be larger than is desirable to include, with the packet, message and other headers (transport, IP), in a MAC frame. Clausen, et al. Expires December 21, 2006 [Page 17] Internet-Draft MANET packet format June 2006 In this case the message SHOULD be fragmented. Only the originator of a message may decide to fragment a message. When a message is fragmented it MUST be assigned a content sequence number by the originator. A content sequence number may also be assigned for reasons other than fragmentation. A content sequence number may be specific to the type of the message or not. If the content sequence number is to be used for fragmentation then this is indicated as specified in Section 6.1. Two messages with the same originator and, when the content sequence number is type-specific, with the same type, with different message bodies SHALL NOT be assigned the same content sequence number. Two messages with the same originator and the same message body MAY be assigned the same content sequence number, with the same type- dependence, in which case they MUST be fragmented identically. A fragment of a message may have one of two forms: o the fragment is a "partially or wholly self-contained message" and may, thus, be parsed and processed immediately by the recipient. Additional processing MAY be necessary when all fragments are received; o the fragment is not a "partially or wholly self-contained message" and may, thus, not be processed until all fragments of the message have been received. Regardless of under which of the above forms a message is fragmented, each fragment MUST be a complete message as defined in this specification, i.e. MUST contain syntactically correct address blocks and TLVs. Furthermore, all fragments of a given message MUST be of the same type, and have the same fragmentation semantics, see Section 6.1. If a message is fragmented, each fragment MUST contain the following TLVs, defined in Section 6.1: o a message TLV with type FRAGMENTATION, specifying the number of fragments, the fragment number (counting from zero), if the fragment is a partially or wholly self-contained message, and if the CONTENT-SEQ-NUMBER generated by the originator of the fragmented message is specific to the type of the fragmented message or not; o a message TLV with type CONTENT-SEQ-NUMBER, specifying the content sequence number associated with the information in the fragment. Clausen, et al. Expires December 21, 2006 [Page 18] Internet-Draft MANET packet format June 2006 If the content sequence number included in the CONTENT-SEQ-NUMBER TLV of a message is specific to the type of the message then the originating node MUST maintain a content sequence number for that message type and MUST increment it when it originates a new message of that type, but not of any other type. A node MAY maintain such type-specific content sequence numbers for any number of types. If the content sequence number included in the CONTENT-SEQ-NUMBER TLV of a message is not specific to the type of the message then the originating node MUST maintain a single content sequence number for those message type for which a content sequence number is required, but for which the node does not maintain a type-specific content sequence number. The node MUST increment this single content sequence number when it originates a new message of any relevant type, but not of any other types (either those for which a content sequence number is not appropriate, or for which a type-specific content sequence number is maintained.) Since FRAGMENTATION is defined to be TLV type zero (see Section 6.1), it can be determined if a message is fragmented by inspecting the first three octets of the message body (the first three octets after the message header): o if the first two octets (the message TLV block length) are both zero then the message is not a fragment; o otherwise if the third octet (the first message TLV type) is zero then the message is a fragment; o otherwise the message is not a fragment. A message SHOULD NOT be sent with a message TLV with type FRAGMENTATION indicating "fragment zero of one". Clausen, et al. Expires December 21, 2006 [Page 19] Internet-Draft MANET packet format June 2006 6. TLV specification This document specifies two message TLVs, which are required in the case of message fragmentation, and one address block TLV. The address block TLV is included to allow a standardized way of representing network addresses, with a prefix length, in control messages. 6.1. Message TLV Specification Message TLV Specification Overview +----------------------+------+--------+----------------------------+ | Name | Type | Length | Value | +----------------------+------+--------+----------------------------+ | FRAGMENTATION | 0 | 24 | See Table 2 below. | | | | bits | | | | | | | | CONT_SEQ_NUM | 1 | 16 | A sequence number, | | | | bits | associated with the | | | | | content of the message | +----------------------+------+--------+----------------------------+ Table 1 The fragmentation TLV contains the following fields in the following order: FRAGMENTATION TLV Value Specification Overview +-------------+----------------------------------------------------+ | Field Width | Value | +-------------+----------------------------------------------------+ | 8 bits | Number of fragments | | | | | 8 bits | Fragment number | | | | | 8 bits | Fragmentation semantics bit vector. | +-------------+----------------------------------------------------+ Table 2 The bits in the fragmentation semantics bit vector are defined as follows: Clausen, et al. Expires December 21, 2006 [Page 20] Internet-Draft MANET packet format June 2006 bit 0 (notselfcont): indicates, if cleared ('0') that the message TLV is a partially or wholly self-contained message, or if set ('1') that the message TLV is not a partially or wholly self-contained message. bit 1 (typedepseq): indicates, if cleared ('0') that the originator maintains a single sequence number for fragmented messages of types including the type of this message, and that this is included in the CONTENT-SEQ-NUMBER TLV. If set ('1'), the originator node maintains a separate sequence number for the type of this message, and that the sequence number in the CONTENT-SEQ- NUMBER TLV is the sequence number corresponding to the type of this message. bits 2-7: are RESERVED and SHALL each be cleared ('0'). 6.2. Address Block TLV Specification The following address block TLV is provided for general use, and is included in this specification since it complements the address representation by providing a way of representing a network address in a message. Address Block TLV Specification Overview +----------------------+------+--------+----------------------------+ | Name | Type | Length | Value | +----------------------+------+--------+----------------------------+ | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | | | | | is a network address, | | | | | rather than a host | | | | | address. The value is the | | | | | length of the | | | | | netmask/prefix. | +----------------------+------+--------+----------------------------+ Table 3 An address in an address block without an associated PREFIX_LENGTH TLV may be considered to have a prefix length equal to the address length (in bits). Clausen, et al. Expires December 21, 2006 [Page 21] Internet-Draft MANET packet format June 2006 7. IANA Considerations The message format in this specification defines a message "type" field, as well as two TLV types for message TLVs and address block TLVs respectively. A new registry for message types must be created with initial assignments as specified in Table 4. A new registry for packet TLV types must be created, with no initial assignments. A new registry for message TLV types must be created with initial assignments as specified in Table 5. A new registry for address block TLV types must be created with initial assignments as specified in Table 6. Assigned Message Types +--------------------+-------+--------------------------------------+ | Mnemonic | Value | Description | +--------------------+-------+--------------------------------------+ | RESERVED | 0 | At start of packet signals that what | | | | follows is a packet header, rather | | | | than a message header, and to allow | | | | packet header and message padding | | | | with zero octets | | | | | | RESERVED | 1 | | | | | | | RESERVED | 2 | | | | | | | RESERVED | 3 | | | | | | | RESERVED | 4 | | +--------------------+-------+--------------------------------------+ Table 4 Message types 1 to 4 are reserved because they are used by OLSRv1 [3] which uses a compatible packet/message header format. Clausen, et al. Expires December 21, 2006 [Page 22] Internet-Draft MANET packet format June 2006 Assigned Message TLV Types +--------------------+-------+--------------------------------------+ | Mnemonic | Value | Description | +--------------------+-------+--------------------------------------+ | FRAGMENTATION | 0 | Specifies behavior in case of | | | | content fragmentation | | | | | | CONT_SEQ_NUM | 1 | A sequence number, associated with | | | | the content of the message | +--------------------+-------+--------------------------------------+ Table 5 Assigned Address Block TLV Types +--------------------+-------+--------------------------------------+ | Mnemonic | Value | Description | +--------------------+-------+--------------------------------------+ | PREFIX_LENGTH | 0 | Indicates that associated addresses | | | | are network addresses, with given | | | | prefix length | +--------------------+-------+--------------------------------------+ Table 6 Clausen, et al. Expires December 21, 2006 [Page 23] Internet-Draft MANET packet format June 2006 8. Security Considerations Packets are designed to be transmitted only one hop, and not forwarded. Thus, hop-by-hop packet level security MAY be implemented, between nodes with an existing security association, through including suitable packet TLV(s) containing a cryptographic signature to the packet. Since packets are received as transmitted, signatures can be calculated based on the entire packet content (including message and packet headers), or on parts thereof as appropriate. The messages contained in a packet are available at each hop, and MAY, according to the information in the message header, and the protocol employing this specification, be forwarded and/or processed. If a message is to be forwarded, the and fields in the message header, if present, SHOULD be modified. All other message header fields, and the message body, MAY, depending on the protocol employing this specification, be left intact. Such a protocol (using immutable messages, other than the indicated fields) using this message format MAY, between nodes with an existing security association, implement end-to-end message security by including suitable message TLV(s) containing a cryptographic signature to the message. This signature can be calculated based on the entire message, including the message header, with the provision that the and fields MUST, if present, both be set to zero ('0') for both calculation and verification of the signature. Clausen, et al. Expires December 21, 2006 [Page 24] Internet-Draft MANET packet format June 2006 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. 9.2. Informative References [3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003. Clausen, et al. Expires December 21, 2006 [Page 25] Internet-Draft MANET packet format June 2006 Appendix A. Packet and Message Layout This section specifies the translation from the abstract descriptions of packets employed in the protocol specification, and the bit-layout packets actually exchanged between the nodes. Appendix A.1. General Packet Format The basic layout of a packet (excluding transport and IP headers) SHALL be one of the following five options. 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 0 0| Reserved |0|0| Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 26] Internet-Draft MANET packet format June 2006 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 0 0| Reserved |0|1| Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 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 0 0| Reserved |1|0| Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Packet TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 27] Internet-Draft MANET packet format June 2006 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 0 0| Reserved |1|1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Packet TLV Block | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 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 + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message + Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that in the first four cases the Reserved bits SHOULD be zero, whilst in the last case the first octet MUST NOT be zero (this is used to recognise this case). In all cases where they are present, Clausen, et al. Expires December 21, 2006 [Page 28] Internet-Draft MANET packet format June 2006 the octets indicated as Padding are optional and MAY be omitted. If not omitted they SHOULD be used to pad to a 32 bit boundary and MUST all be zero. The basic layout of a message, plus padding, SHALL be one of the following four options. 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 | Resv |N|0|0| Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 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 | Resv |N|0|1| Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Hop Count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 29] Internet-Draft MANET packet format June 2006 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 | Resv |N|1|0| Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 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 | Resv |N|1|1| Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Body | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The reserved bits marked Resv SHOULD be zero. The N bit is set ('1') if the message sequence number is type-dependent, or cleared ('0') if the message sequence number is type-independent. The octets indicated as Padding are optional and MAY be omitted. If not omitted they SHOULD be used to pad to a 32 bit boundary and MUST all be zero; they are not included in the message size. The basic layout of a message body SHALL be as follows. Clausen, et al. Expires December 21, 2006 [Page 30] Internet-Draft MANET packet format June 2006 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 | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The basic layout of an address block SHALL be one of the following three options. Clausen, et al. Expires December 21, 2006 [Page 31] Internet-Draft MANET packet format June 2006 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| Head Length | Head | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 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| Head Length | Head |0| Tail Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 32] Internet-Draft MANET packet format June 2006 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| Head Length | Head |1| Tail Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | : ... : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length of each Mid section is equal to the address length minus the Head Length and the Tail Length. In the first case there is no Tail section, the Mid sections are actually tail sections. In the third case the tail section is not included, it is all octets zero. The basic layout of a TLV block (packet TLV block, message TLV block or address TLV block) SHALL be as follows. 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 | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length is of the TLV block contents, it does not include itself Clausen, et al. Expires December 21, 2006 [Page 33] Internet-Draft MANET packet format June 2006 (hence if there are no TLVs then Length is zero). The basic layout of a TLV SHALL be one of the following six options. A packet TLV or message TLV SHALL be one of the last three options only. 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 | Resv |M|0|0|0| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+ | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ or 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 | Resv |0|0|0|1| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 34] Internet-Draft MANET packet format June 2006 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 | Resv |M|0|1|0| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Value | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ or 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 | Resv |M|1|0|0| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Value | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ or 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 | Resv |0|1|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Clausen, et al. Expires December 21, 2006 [Page 35] Internet-Draft MANET packet format June 2006 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 | Resv |M|1|1|0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Value | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ M denotes the multivalue bit in those cases when it may be set ('1') or cleared ('0'). In the cases where it MUST be cleared ('0') it is shown thus; it MUST also be cleared ('0') in a packet TLV or message TLV.) The reserved bits marked Resv SHOULD also be zero. An example packet, using IPv4 addresses (length four octets) is shown. This packet has a header, with a packet sequence number but no packet TLV block, and contains a single unfragmented message. The message has a complete message header, a message TLV block of content length 9 octets containing a single TLV (with the noindex bit of its semantics set and value length 6 octets) and then two address blocks each with a following TLV block. The first address block contains 3 addresses (head length 2 octets, no tail, hence mid length two octets) and is followed by a TLV block of content length 9 octets containing two TLVs. The first of these TLVs has the noindex bit of its semantics set and has a single value of length 2 octets, which applies to all of the addresses in the preceding address block. The second of these TLVs has the novalue bit of its semantics set and hence has no length or value fields (it does have index fields, which indicate which of the addresses this TLV applies to). The second address block contains 2 addresses (head length 0 octets, hence no head octets, tail length 2 octets, zero-valued tail not included, hence mid length two octets) and is followed by a TLV block of content length 5 octets. This TLV block contains a single TLV of type PREFIX_LENGTH which has the multivalue and no index bits of its semantics set and a value field length of 2 octets, indicating two values each of one octet length. There are two final padding octets which are not included in the message length of 62 octets. Clausen, et al. Expires December 21, 2006 [Page 36] Internet-Draft MANET packet format June 2006 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 0 0| Reserved |0|0| Packet Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | Resv |0|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1 0| Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (cont) |0 0 0 0 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| Head | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Mid | Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv |0|1|0|0|0 0 0 0 0 0 1 0| Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | Resv |0|0|0|1| Index Start | Index Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mid (cont) | Mid |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1| PREFIX_LENGTH | Resv |1|1|0|0|0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value0 | Value1 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Clausen, et al. Expires December 21, 2006 [Page 37] Internet-Draft MANET packet format June 2006 Appendix B. Contributors This specification is the result of the joint efforts of the following contributers from the OLSRv2 Design Team -- listed alphabetically. o Cedric Adjih, INRIA, France, o Emmanuel Baccelli, Hitachi Labs Europe, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, 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, Clausen, et al. Expires December 21, 2006 [Page 38] Internet-Draft MANET packet format June 2006 Appendix C. Acknowledgements The authors would like to acknowledge the team behind OLSRv1, as specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced Research in Engineering, Pakistan) for their contributions. The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews and comments on the specification and its components: Joe Macker (NRL), Alan Cullen (BAE Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas Schjonhaug (LIX), Florent Brunneau (LIX), and the entire IETF MANET working group. Clausen, et al. Expires December 21, 2006 [Page 39] Internet-Draft MANET packet format June 2006 Authors' Addresses Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ Christopher M. Dearlove BAE Systems Advanced Technology Centre Phone: +44 1245 242194 Email: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ocs/sharedservices/atc/ 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 Clausen, et al. Expires December 21, 2006 [Page 40] Internet-Draft MANET packet format June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Clausen, et al. Expires December 21, 2006 [Page 41]