Internet DRAFT - draft-clausen-manet-olsrv2-fmt
draft-clausen-manet-olsrv2-fmt
Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France
Expires: June 12, 2006 C. Dearlove
BAE Systems Advanced Technology
Centre
J. Dean
Naval Research Laboratory
December 9, 2005
Generalized OLSRv2 Packet/Message Format
draft-clausen-manet-olsrv2-fmt-00
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 June 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a generalized multi-message packet format for
version 2 of the Optimized Link State Routing (OLSRv2) protocol for
mobile ad hoc networks. The packet and multi-message format may also
be useful for other protocols.
Clausen, et al. Expires June 12, 2006 [Page 1]
Internet-Draft OLSRv2-fmt December 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.1 Address Blocks . . . . . . . . . . . . . . . . . . . . 10
5.2.2 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.3 Constraints . . . . . . . . . . . . . . . . . . . . . 13
5.3 Message Content Fragmentation . . . . . . . . . . . . . . 13
6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Message TLV Specification . . . . . . . . . . . . . . . . 15
6.2 Address Block TLV Specification . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Protocol and Port Number . . . . . . . . . . . . . . . . . . . 20
B. Packet and Message Layout . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B.1 General OLSR Packet Format . . . . . . . . . . . . . . . . 21
C. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 29
Clausen, et al. Expires June 12, 2006 [Page 2]
Internet-Draft OLSRv2-fmt December 2005
1. Introduction
Signaling in the Optimized Link State Routing Protocol version 2
(OLSRv2) [2] consists, mainly, of stating IP addresses and attributes
associated to such IP addresses. Since this is a task common to
protocols other than OLSRv2, this specification presents a
generalized signaling framework, which may be employed both by OLSRv2
and by other protocols with similar signaling requirements.
The framework consists of a specification of:
o a mechanism whreby new message types can be specified and
(regardless of type) can still be correctly parsed and forwarded;
o a generalized multi-message packet format, in which the header
information contains the necessary information to allow single and
multi-hop diffusion in MANETs, as well as to accommodate both
multicast and unicast;
o a mechanism whereby addresses can be represented in a compact way
(address compression);
o an extensibility mechanism whereby arbitrary attributes, through
TLVs, 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 decissions.
Additionally, the signaling framework in this specification is
developed with the objective of minimizing the complexity of this
parser by providing a straight-forward message layout, minimizing
necessary branching, etc.
Clausen, et al. Expires June 12, 2006 [Page 3]
Internet-Draft OLSRv2-fmt December 2005
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:
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 to 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
Clausen, et al. Expires June 12, 2006 [Page 4]
Internet-Draft OLSRv2-fmt December 2005
3. Applicability Statement
This specification describes a generic multi-message packet format,
for carrying MANET routing protocol signals. The specification has
been developed as part of OLSRv2, however it has been generalized to
also be applicable for other protocols with requirements different
from those of OLSRv2.
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 [4].
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 June 12, 2006 [Page 5]
Internet-Draft OLSRv2-fmt December 2005
4. Protocol Overview and Functioning
This specification does not describe a protocol. It described a
packet format, which is used by OLSRv2, and which MAY be used by
other protocols.
Clausen, et al. Expires June 12, 2006 [Page 6]
Internet-Draft OLSRv2-fmt December 2005
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
transmission.
The packet format conforms to the following specification:
<packet> = <packet-header>?
{<message><pad-octet>*}+
where <message> is defined in Section 5.2, and with <pad-octet>
conforming to the following specification:
<pad-octet> is an 8 bit field with all bits set to zero ('0'). The
use of <pad-octet> is detailed in Section 5.1.1.
The <packet-header> is defined thus:
<packet-header> = <zero>
<reserved>
<packet-seq-number>
with the elements of <packet-header> conforming to the following
specification:
<zero> is an 8 bit field with all bits set to zero ('0'). This field
serves to identify if the first 32 bits of a packet constitutes a
packet header or not.
<reserved> is an 8 bit field with all bits set to zero ('0'). This
field MAY be used for future extensions.
<packet-seq-number> is an 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.
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.
Clausen, et al. Expires June 12, 2006 [Page 7]
Internet-Draft OLSRv2-fmt December 2005
5.1.1 Padding
The message specification in Section 5.2 ensures that a message
consists of an integral number of octets, with all defined
syntactical entities (<msg-header>, <address-block>, <tlv> etc.)
being octet-alligned. Messages and the start of the message body
(and, hence, also the <originator-address>, if any), can be 32 bit
alligned by adding the appropriate number of <pad-octet>s, as
specified above.
The number of <pad-octet>s required to achieve 32 bit alignment of a
message is calculated as the smallest number which when added to
<msg-size> produces a multiple of 4.
A recipient node needs not know if padding is included: the first
octet of a message (see Section 5.2) can not be zero. Thus if after
processing a message a recipient reads an octet with all bits set to
zero ('0'), this read octet is padding.
Thus, the <msg-size> does not include padding.
5.2 Messages
Information is carried through "messages". Messages may contain:
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. Each address SHALL appear only once in a
message;
o each address block is followed by zero or more TLVs, explained
with more details in Section 5.2.2, which convey information about
the addresses in that address block;
o zero or more TLVs, associated with the whole message
A message also contains a message header, which can be parsed without
examining the remainder of the packet, and which contains information
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
Clausen, et al. Expires June 12, 2006 [Page 8]
Internet-Draft OLSRv2-fmt December 2005
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.3.
A message has the following general layout:
<message> = <msg-header>
<tlv-block>
{<addr-block><tlv-block>}*
<msg-header> = <type>
<msg-semantics>
<msg-size>
<msg-header-info>?
<msg-header-info> = <originator-address>
<ttl>
<hop-count>
<msg-seq-number>
<tlv-block> = <tlv-length>
<tlv>*
The <msg-header-info> is included if bit 0 (LSB) in <msg-semantics>
is set to zero ('0').
The elements used above conform to the following specification:
<tlv-length> is a 16 bit field, which contains the total length (in
octets) of the immediately following TLV(s). If no TLV follows,
this field contains zero;
<tlv> is a TLV, providing information regarding the entire message or
the address block which it follows. TLVs are specified in
Section 5.2.2;
<addr-block> is a block of addresses, with which the originator of
the message has a special relationship, specific to the protocol.
Address blocks are specified in Section 5.2.1;
<type> is an 8 bit field, which specifies the type of message. A
type with all bits set to zero ('0') is not allowed;
<msg-semantics> 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:
Clausen, et al. Expires June 12, 2006 [Page 9]
Internet-Draft OLSRv2-fmt December 2005
bit 0 (LSB) indicates, if set to zero ('0') that a <msg-header-
info> be included, as specified in the above. If set to one
('1'), a reduced header which does not include a <msg-header-
info>, is used; this does not provide provisions for duplicate
suppression and/or forwarding;
bit 1 indicates, if set to zero ('0') that the message, if of a
message type unknown to the recipient, SHOULD be considered for
forwarding. If set to one ('1'), the message, if of a message
type unknown to the recipient, MUST NOT be considered for
forwarding;
bit 2 is RESERVED, and SHALL for compatibility with this
specification be set to zero ('0');
bit 3-7 (MSB) SHALL each be set to zero ('0').
<msg-size> is an 16 bit field, which specifies the size of the <msg-
header> and the following <msg-body>, counted in octets;
<originator-address> is the address of an interface of the node,
which originated the message. Each node SHOULD select one
interface address and MUST utilize this address consistently as
"originator address" for all messages it generates;
<ttl> is an 8 bit field, which contains the maximum number of hops a
message will be transmitted. Before a message is retransmitted,
the Time To Live MUST be decremented by 1. When a node receives a
message with a Time To Live equal to 0 or 1, the message MUST NOT
be retransmitted under any circumstances. Normally, a node will
not receive a message with a TTL of zero.
<hop-count> is an 8 bit field, which contains the number of hops a
message has attained. Before a message is retransmitted, the hop
count MUST be incremented by 1. Initially, this is set to '0' by
the originator of the message;
<msg-seq-number> is a 16 bit field, which contains a unique number,
generated by the originator node. The originator-address and msg-
seq-number 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:tail', then an address-block is a set of
Clausen, et al. Expires June 12, 2006 [Page 10]
Internet-Draft OLSRv2-fmt December 2005
addresses sharing the same 'head' and having different 'tails'.
Specifically, an address block conforms to the following
specification:
<address-block> = <head-length>
<head>
<num-tails>
<tail>+
with the elements defined thus:
<head-length> is the number of "common leftmost octets" in a set of
addresses, where 0 <= head-length <= the length of the address in
octets;
<head> is the longest sequence of leftmost octets which the addresses
in the address block have in common;
<num-tails> is the number of tails which follows, i.e. the number of
addresses represented in the address block;
<tail> is the sequence of octets which, when concatenated to the
head, makes up a single, complete, unique address.
This representation aims at providing a flexible, yet compact, way of
representing sets of addresses.
5.2.2 TLVs
A TLV is a carrier of information, relative to a message or to
addresses in an address block.
A TLV associated with an address-block specifies some attribute(s),
which associate 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 a single address in the address block;
o all addresses in the address block;
o any continuous sequence of addresses in the address block.
All TLVs conforms to the following specification:
Clausen, et al. Expires June 12, 2006 [Page 11]
Internet-Draft OLSRv2-fmt December 2005
<tlv> = <type>
<length>
<index-start>
<index-stop>
<value>
where the elements are defined thus:
<type> 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 is the "user" bit. Types with this bit unset are defined in
this specification or can be allocated via standards action.
Types with this bit set are reserved for private/local use.
bit 6 is the "multivalue" bit. TLVs with types with this bit
unset include a single value, which applies to each of the
addresses defined by <index-start> and <index-stop>. TLVs with
types with this bit set include separate values for each of the
addresses in the interval <index-start> to <index-stop>. This
bit MUST be unset for message TLVs.
<length> is an 16 bit field which specifies the length, counted in
octets, of the data contained in <value>. If the multivalue bit
is set, this MUST be an integral multiple of (<index-stop>-<index-
start>+1);
<index-start> is an 8 bit field. For a TLV associated with an
address block, specifies the index of the first address in the
address-block (starting at zero), for which this TLV applies. For
a TLV associated with a message, this field SHALL be set to zero;
<index-stop> is an 8 bit field. For a TLV associated with an address
block, specifies the index of the last address in the address-
block (starting at zero) for which this TLV applies. For a TLV
associated with a message, this field SHALL be set to zero;
<value> contains a payload, of the length specified in <length>,
which is to be processed according to the specification indexed by
the <type> field. If this is a TLV for an address block and the
multivalue bit is set, this field is divided into (<index-stop>-
<index-start>+1) equal-sized fields which are applied, in order,
to each address described by <index-start> and <index-stop>
Clausen, et al. Expires June 12, 2006 [Page 12]
Internet-Draft OLSRv2-fmt December 2005
5.2.3 Constraints
o An address SHALL NOT appear more than once in the same message;
o Two or more TLVs of the same type SHALL NOT apply to the same
address;
o TLVs in the same <tlv-block> SHALL be sorted in ascending TLV type
order;
o TLVs of the same type associated with the same <addr-block> SHALL
be sorted in ascending <index-start> order;
o If, for a given semantics, alternative TLVs with the multivalue
bit set and the multivalue bit cleared are defined, they SHALL NOT
both be used in the same <tlv-block>.
5.3 Message Content Fragmentation
A message may be larger than is desirable to include, with the
packet, message and other headers (UDP, IP) in a MAC frame. 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. Two messages with the same originator and of the same
type with different message bodies SHALL NOT be assigned the same
content sequence number. Two messages with the same originator and
of the same type with the same message body MAY be assigned the same
content sequence number, in which case they MUST be fragmented
identically.
A fragment of a message may have one of two forms:
o the fragment is "self contained" 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 "self contained" and may, thus, not be parsed
and processed until all fragments of a message have been received.
Regardless of type, each fragment MUST be a complete message, i.e.
MUST contain syntactically correct address blocks and TLVs.
Furthermore, all fragments of a given message MUST be of the same
type.
If a message is fragmented, each fragment MUST contain the following
TLVs:
Clausen, et al. Expires June 12, 2006 [Page 13]
Internet-Draft OLSRv2-fmt December 2005
o a message TLV with type FRAGMENTATION, specifying the number of
fragments, the fragment number (counting from zero) and if the
fragment is self-contained;
o a message TLV with type CONTENT-SEQ-NUMBER, specifying the content
sequence number associated with the information in the fragment.
Since fragmentation (see Section 6.1) is defined to be TLV type zero,
it can be determined if a message is fragmented by inspecting the
first octet of the message body (i.e. the first octet after the
message header).
A message SHOULD NOT be sent with a message TLV with type
FRAGMENTATION indicating "fragment zero of one".
Clausen, et al. Expires June 12, 2006 [Page 14]
Internet-Draft OLSRv2-fmt December 2005
6. TLV specification
This document specifies two message TLVs, which are required in the
case of message fragmentation, and two address-block TLVs. The
address block TLVs are included to allow a standardized way of
representing network addresses in control messages.
6.1 Message TLV Specification
Message TLV specification overview
+----------------------+--------+--------+--------------------------+
| Name | Type | Length | Value |
+----------------------+--------+--------+--------------------------+
| FRAGMENTATION | 0 | 24 | See Table 2 below. |
| | | bits | |
| | | | |
| CONTENT-SEQ-NUMBER | 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:
+--------------+----------------------------------------------------+
| Field Width | Value |
+--------------+----------------------------------------------------+
| 8 bits | Number of fragments |
| | |
| 8 bits | Fragment number |
| | |
| 8 bits | 0 means that the message TLV is self-contained. 1 |
| | means that the message TLV is not self-contained. |
+--------------+----------------------------------------------------+
Table 2
6.2 Address Block TLV Specification
The following address block TLVs are provided for general use, and
are included in this specification since they complement the address
representation by providing way of representing a network address in
a message.
Clausen, et al. Expires June 12, 2006 [Page 15]
Internet-Draft OLSRv2-fmt December 2005
Address block TLV specification overview
+----------------------+--------+--------+--------------------------+
| Name | Type | Length | Value |
+----------------------+--------+--------+--------------------------+
| MASK | 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. |
| | | | |
| MV-MASK | 64 | 8 bits | The multi-value version |
| | | /value | of the MASK address |
| | | | block TLV. |
+----------------------+--------+--------+--------------------------+
Table 3
Clausen, et al. Expires June 12, 2006 [Page 16]
Internet-Draft OLSRv2-fmt December 2005
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 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 | Signals that the following 24 bits |
| | | are a packet header, rather than a |
| | | message header |
| | | |
| OLSRv1-HELLO | 1 | Reserved for compatibility with |
| | | OLSRv1 [3] |
| | | |
| OLSRv1-TC | 2 | Reserved for compatibility with |
| | | OLSRv1 [3] |
| | | |
| OLSRv1-MID | 3 | Reserved for compatibility with |
| | | OLSRv1 [3] |
| | | |
| OLSRv1-HNA | 4 | Reserved for compatibility with |
| | | OLSRv1 [3] |
+--------------------+--------+-------------------------------------+
Table 4
Clausen, et al. Expires June 12, 2006 [Page 17]
Internet-Draft OLSRv2-fmt December 2005
Assigned message TLV Types
+--------------------+--------+-------------------------------------+
| Mnemonic | Value | Description |
+--------------------+--------+-------------------------------------+
| Fragmentation | 0 | Specifies behavior in case of |
| | | content fragmentation |
| | | |
| Content Sequence | 1 | A sequence number, associated with |
| Number | | the content of the message |
+--------------------+--------+-------------------------------------+
Table 5
Assigned address block TLV Types
+--------------------+--------+-------------------------------------+
| Mnemonic | Value | Description |
+--------------------+--------+-------------------------------------+
| Mask | 0 | Indicates that associated addresses |
| | | are network addresses |
| | | |
| MV-Mask | 64 | The multi-value version of the Mask |
| | | TLV |
+--------------------+--------+-------------------------------------+
Table 6
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Clausen, T. and The OLSRv2 Design Team, "The Optimized Link
State Routing Protocol version 2",
I-D draft-ietf-manet-olsrv2-00.txt, November 2005.
[3] Clausen, T., "The Optimized Link State Routing Protocol",
RFC 3626, October 2003.
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
Clausen, et al. Expires June 12, 2006 [Page 18]
Internet-Draft OLSRv2-fmt December 2005
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
Justin W. Dean
Naval Research Laboratory
Phone: +1 202 767 3397
Email: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/
Clausen, et al. Expires June 12, 2006 [Page 19]
Internet-Draft OLSRv2-fmt December 2005
Appendix A. Protocol and Port Number
Packets in OLSRv2 are communicated using UDP. Port 698 has been
assigned by IANA for exclusive usage by the OLSR (v1 and v2)
protocol.
Clausen, et al. Expires June 12, 2006 [Page 20]
Internet-Draft OLSRv2-fmt December 2005
Appendix B. 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 B.1 General OLSR Packet Format
The basic layout of a packet is as follows (omitting IP and UDP
headers), either
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 | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
Clausen, et al. Expires June 12, 2006 [Page 21]
Internet-Draft OLSRv2-fmt December 2005
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The basic layout of a message is as follows, either
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 | Reserved |U|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | 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 | Reserved |U|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body + Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clausen, et al. Expires June 12, 2006 [Page 22]
Internet-Draft OLSRv2-fmt December 2005
where U denotes a bit which specifies the handling of unknown
messages (0 = forward, 1 = discard).
The basic layout of a message body, plus padding, is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message TLV Block +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| |
| Address TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Address TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The final padding to a 32 bit boundary is optional, and is not
included in the message length.
Clausen, et al. Expires June 12, 2006 [Page 23]
Internet-Draft OLSRv2-fmt December 2005
The basic layout of an address block is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Length | Head | Number Tails |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The basic layout of a TLV block (message TLV block or address TLV
block) is 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 basic layout of a TLV is as follows (the value field may be
absent, if so the length field will be all zero bits)
Clausen, et al. Expires June 12, 2006 [Page 24]
Internet-Draft OLSRv2-fmt December 2005
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop | |
+-+-+-+-+-+-+-+-+ Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An example packet, containing a single message, is as follows. The
message has a message TLV block of length 6 octets containing a
single TLV (value length 1) then two address blocks, the first
containing 4 addresses (head length 3) followed by an empty TLV
block, the second containing 3 addresses (head length 2) and followed
by a TLV block of length 12 octets containing two TLVs (value lengths
2 and 0). There is a single final padding octet, which is not
included in the message length of 43 octets. The addresses used in
this example are IPv4 addresses.
Clausen, et al. Expires June 12, 2006 [Page 25]
Internet-Draft OLSRv2-fmt December 2005
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 | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reserved |U|0|0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| TLV Type |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Index Start | Index Stop | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Tail | Tail | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head |0 0 0 0 0 0 1 1| Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) | Tail | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0| TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Index Start | Index Stop |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Clausen, et al. Expires June 12, 2006 [Page 26]
Internet-Draft OLSRv2-fmt December 2005
Appendix C. 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, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, PCRI, France<T.Clausen@computer.org>
o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp>
Clausen, et al. Expires June 12, 2006 [Page 27]
Internet-Draft OLSRv2-fmt December 2005
Appendix D. 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), and the entire IETF MANET working group.
Clausen, et al. Expires June 12, 2006 [Page 28]
Internet-Draft OLSRv2-fmt December 2005
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 (2005). 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 June 12, 2006 [Page 29]