draft-ietf-manet-packetbb-04.txt   draft-ietf-manet-packetbb-05.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: July 5, 2007 BAE Systems Advanced Technology Expires: December 17, 2007 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
January 2007 June 15, 2007
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-04 draft-ietf-manet-packetbb-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2007. This Internet-Draft will expire on December 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a multi-message packet format that may be This document specifies a multi-message packet format that may be
used by mobile ad hoc network routing and other protocols. used by mobile ad hoc network routing and other protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8
5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11
5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 12 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13
5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16
5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 17 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Address Block TLV Specification . . . . . . . . . . . . . 17 6.1. Address Block TLV Specification . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . 21 Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . 21
Appendix A.1. Packet . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A.1. Packet . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A.2. Message and Padding . . . . . . . . . . . . . . . . 23 Appendix A.2. Message and Padding . . . . . . . . . . . . . . . . 23
Appendix A.3. Message Body . . . . . . . . . . . . . . . . . . . . 25 Appendix A.3. Message Body . . . . . . . . . . . . . . . . . . . . 29
Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 26 Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 30
Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 28 Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 32
Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 31 Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 35
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 33 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 37
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
This document specifies the syntax of a general purpose multi-message This document specifies the syntax of a general purpose multi-message
packet format for information exchange between MANET routers. packet format for information exchange between MANET routers.
Messages consist of a message header, which is designed for control Messages consist of a message header, which is designed for control
of message dissemination, and a message body, which contains protocol of message dissemination, and a message body, which contains protocol
information. Only the syntax of the message body is specified. All information. Only the syntax of the message body is specified. All
syntactical entities, including messages and packets, are specified syntactical entities, including messages and packets, are specified
using regular expressions. using regular expressions.
This document specifies: This document specifies:
o A packet format, allowing zero or more messages to be contained o A packet format, allowing zero or more messages to be contained
within a single transmission, and optionally including a packet within a single transmission, and optionally including a packet
header. header. A packet with zero messages may be sent in case the only
information to exchange is contained in the packet header (such as
a "keep alive" sequence number).
o A message format, where a message is composed of a message header o A message format, where a message is composed of a message header
and a message body. and a message body.
o A message header format containing *all* necessary information to o A message header format which allows a node to make forwarding
allow a node to make forwarding decisions without inspecting and decisions based on the node's present state and the message
processing the message body. Message header information permits header, without inspecting and processing the message body, and
single- and multi-hop message diffusion. independently of the TTL or hop limit information in the IP
header. Message header information permits single- and multi-hop
message diffusion.
o A message body format, containing attributes associated with the o A message body format, containing attributes associated with the
message or the originator of the message, as well as blocks of message or the originator of the message, as well as blocks of
addresses with associated attributes. addresses with associated attributes.
o An address block format, where an address block represents sets of o An address block format, where an address block represents sets of
addresses in a compact (compressed) form. addresses in a compact (compressed) form.
o A generalized type-length-value (TLV) format representing o A generalized type-length-value (TLV) format representing
attributes. Multiple TLVs can be included and associated with a attributes. Multiple TLVs can be included and associated with a
packet, a message, an address, or a set of addresses. packet, a message, an address, or a set of addresses.
The specification has been explicitly designed with the following The specification has been explicitly designed with the following
properties in mind: properties, listed in no particular order, in mind:
Parsing logic - the regular expression specification facilitates Parsing logic - the regular expression specification facilitates
generic, protocol independent, parsing logic. generic, protocol independent, parsing logic.
Extensibility - packets and messages defined by a protocol using Extensibility - packets and messages defined by a protocol using
this specification are extensible through defining new message this specification are extensible through defining new message
types and new TLVs. Full backward compatibility can be types and new TLVs. Existing protocol specifications using this
maintained. specification will be able to correctly identify and skip such new
message types and TLVs, while correctly parsing the remainder of
the packet and message.
Efficiency - when reported addresses share common bit sequences Efficiency - when reported addresses share common bit sequences
(e.g. prefixes or IPv6 interface identifiers) the address block (e.g. prefixes or IPv6 interface identifiers) the address block
representation allows for a compact representation. representation allows for a compact representation. Compact
message headers are ensured through permitting inclusion of only
required message header elements.
Separation of forwarding and processing - duplicate detection and Separation of forwarding and processing - duplicate detection and
controlled scope message forwarding decisions can be made solely controlled scope message forwarding decisions can be made using
using information contained in the message header, without information contained in the message header, without processing
processing the message body. the message body.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [1]. document are to be interpreted as described in RFC 2119. [1].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Packet - the top level entity in this specification. Packets are Packet - the top level entity in this specification. Packets are
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3. Applicability Statement 3. Applicability Statement
This specification describes a generic multi-message packet format, This specification describes a generic multi-message packet format,
for carrying MANET routing protocol signals. The specification has for carrying MANET routing protocol signals. The specification has
been developed from that used by OLSR (The Optimized Link State been developed from that used by OLSR (The Optimized Link State
Routing Protocol) [4]. Routing Protocol) [4].
The specification is designed specifically with IP (IPv4/IPv6) in The specification is designed specifically with IP (IPv4/IPv6) in
mind. All addresses within a control message are assumed to be of 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 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]. addresses, IPv4 addresses are represented as IPv4-mapped IPv6
addresses as specified in [2].
The messages defined by this specification are designed to carry The messages defined by this specification are designed to carry
routing protocol signals between MANET routers, and to support scope routing protocol signals between MANET routers, and to support scope
limited diffusion, as well as point to point signaling in a multi-hop limited diffusion, as well as point to point signaling in a multi-hop
network. network.
The packets defined by this specification are designed to carry a The packets defined by this specification are designed to carry a
number of messages between in a single transmission. The packets may number of messages between in a single transmission. The packets may
use any transport mechanism (unicast, multicast) and transport use any transport mechanism (unicast, multicast) and transport
protocol (TCP, UDP, ...) appropriate to the protocol using this protocol (TCP, UDP, ...) appropriate to the protocol using this
skipping to change at page 6, line 38 skipping to change at page 6, line 39
by this specification is employed, UDP may be most appropriate. by this specification is employed, UDP may be most appropriate.
This specification is particularly appropriate for extensible This specification is particularly appropriate for extensible
protocols. It offers external extensibility in the form of new protocols. It offers external extensibility in the form of new
message types. It offers internal extensibility in the form of TLVs, message types. It offers internal extensibility in the form of TLVs,
which may be added to existing message types. which may be added to existing message types.
A protocol using the multi-message packet format defined by this A protocol using the multi-message packet format defined by this
specification may constrain the syntax (for example requiring a full specification may constrain the syntax (for example requiring a full
message header) and features (for example specifying the suggested message header) and features (for example specifying the suggested
diffusion mechanism) that it will employ. diffusion mechanism) that the protocol will employ.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This specification does not describe a protocol. It describes a This specification does not describe a protocol. It describes a
packet format, which may be used by any mobile ad hoc network routing packet format, which may be used by any mobile ad hoc network routing
or other protocol. or other protocol.
5. Signaling Framework 5. Signaling Framework
This section provides syntactical specification of a packet, This section provides syntactical specification of a packet,
skipping to change at page 8, line 24 skipping to change at page 8, line 24
the transport protocol employed. the transport protocol employed.
5.1. Packets 5.1. Packets
<packet> is defined by: <packet> is defined by:
<packet> = {<packet-header><pad-octet>*}? <packet> = {<packet-header><pad-octet>*}?
{<message><pad-octet>*}* {<message><pad-octet>*}*
where <message> is defined in Section 5.2, and <pad-octet> is defined where <message> is defined in Section 5.2, and <pad-octet> is defined
in Section 5.4. The packet is parsed until all octets are used. in Section 5.4. Successful parsing is terminated when all octets are
used.
<packet-header> is defined by: <packet-header> is defined by:
<packet-header> = <zero> <packet-header> = <zero>
<packet-semantics> <packet-semantics>
<packet-seq-number>? <packet-seq-number>?
<tlv-block>? <tlv-block>?
where: where:
skipping to change at page 10, line 13 skipping to change at page 10, line 15
<tlv-block> is defined in Section 5.3. <tlv-block> is defined in Section 5.3.
<addr-block> is defined in Section 5.2.1. <addr-block> is defined in Section 5.2.1.
<msg-type> is an 8 bit field, specifying the type of message. A <msg-type> is an 8 bit field, specifying the type of message. A
type with all bits cleared ('0') MUST NOT be used. type with all bits cleared ('0') MUST NOT be used.
<msg-semantics> is an 8 bit field, specifying the interpretation of <msg-semantics> is an 8 bit field, specifying the interpretation of
the remainder of the message header: the remainder of the message header:
bit 0 (noorig): if cleared ('0'), then <originator-address> and bit 0 (noorig): If cleared ('0'), then <originator-address> is
<msg-seq-number> are included in <msg-header-info>. If set included in the <msg-header-info>. If set ('1'), then
('1'), then <originator-address> and <msg-seq-number> are not <originator-address> is not included in the <msg-header-info>.
included in <msg-header-info>; this reduced message header does
not provide for duplicate suppression.
bit 1 (nohops): if cleared ('0'), then <hop-limit> and <hop- bit 1 (nohoplimit): If cleared ('0'), then <hop-limit> is
count> are included in the <msg-header-info>. If set ('1'), included in the <msg-header-info>. If set ('1'), then <hop-
then <hop-limit> and <hop-count> are not included in the <msg- limit> is not included in the <msg-header-info>.
header-info>; this reduced message header does not provide for
scope-delimited forwarding.
bit 2 (typedep): if cleared ('0'), then the message sequence bit 2 (nohopcount): If cleared ('0'), then <hop-count> is
included in the <msg-header-info>. If set ('1'), then <hop-
count> is not included in the <msg-header-info>
bit 3 (noseqnum): If cleared ('0'), then <msg-seq-number> is
included in the <msg-header-info>. If set ('1'), then <msg-
seq-number> is not included in the <msg-header-info>.
bit 4 (typedep): If cleared ('0'), then the message sequence
number in the message is type-independent. If set ('1'), then number in the message is type-independent. If set ('1'), then
the message sequence number contained in the message is type the message sequence number contained in the message is type
dependent (the message originator maintains a sequence number dependent (the message originator maintains a sequence number
specific to <msg-type>). This bit MUST be cleared ('0') if the specific to <msg-type>). This bit MUST be cleared ('0') if the
noorig bit is set ('1'). noorig bit is set ('1').
bits 3-7: are RESERVED and MUST each be cleared ('0') to be in bits 5-7: are RESERVED and MUST each be cleared ('0') to be in
conformance with this version of the specification. conformance with this version of the specification.
If bit 0 (noorig) and bit 3 (noseqnum) are both cleared, then the
message header provides for duplicate suppression.
If bit 1 (nohoplimit) and bit 2 (nohopcount) are both cleared,
then the message header provides for scope-delimited forwarding.
<msg-size> is a 16 bit field, specifying the size of the <message>, <msg-size> is a 16 bit field, specifying the size of the <message>,
counted in octets. counted in octets.
<originator-address> is an identifier of length equal to address- <originator-address> is an identifier of length equal to address-
length, which serves to uniquely identify the node that originated length, which serves to uniquely identify the node that originated
the message. the message.
<hop-limit> is an 8 bit field, which contains the maximum number of <hop-limit> is an 8 bit field, which contains the maximum number of
logical hops a message should be further transmitted. logical hops a message should be further transmitted.
skipping to change at page 11, line 9 skipping to change at page 11, line 25
<msg-seq-number> is a 16 bit field, which contains a unique number, <msg-seq-number> is a 16 bit field, which contains a unique number,
generated by the originator node. The <originator-address>, <msg- generated by the originator node. The <originator-address>, <msg-
seq-number>, and, if the typedep bit in the <msg-semantics> field seq-number>, and, if the typedep bit in the <msg-semantics> field
is set, the <msg-type> of a message serves to uniquely identify is set, the <msg-type> of a message serves to uniquely identify
the message in the network. the message in the network.
5.2.1. Address Blocks 5.2.1. Address Blocks
An address is specified as a sequence of address-length octets of the An address is specified as a sequence of address-length octets of the
form head:mid:tail. An address block is an ordered set of addresses form head:mid:tail. An address block is an ordered set of addresses
sharing the same head and tail, and having individual mids. sharing the same head and tail, and having individual mids. Network
addresses may be represented using the PREFIX_LENGTH TLV defined in
Section 6.
<address block> is defined by: <address block> is defined by:
<address-block> = <num-addr> <address-block> = <num-addr>
<addr-semantics> <addr-semantics>
<head-length>? <head-length>?
<head>? <head>?
<tail-length>? <tail-length>?
<tail>? <tail>?
<mid>* <mid>*
skipping to change at page 12, line 45 skipping to change at page 13, line 15
5.3. TLVs and TLV Blocks 5.3. TLVs and TLV Blocks
A TLV block is defined by: A TLV block is defined by:
<tlv-block> = <tlv-length> <tlv-block> = <tlv-length>
<tlv>* <tlv>*
where: where:
<tlv-length> is a 16 bit field, which contains the total length (in <tlv-length> is a 16 bit field, which contains the total length (in
octets) of the immediately following <tlv> elements. octets) of all of the immediately following <tlv> elements.
<tlv> is defined in Section 5.3.1. <tlv> is defined in Section 5.3.1.
5.3.1. TLVs 5.3.1. TLVs
There are three kinds of TLV, each represented by an element <tlv>: There are three kinds of TLV, each represented by an element <tlv>:
o A packet TLV, included in a packet header. o A packet TLV, included in a packet header.
o A message TLV, included in a message before all address blocks. o A message TLV, included in a message before all address blocks.
skipping to change at page 13, line 34 skipping to change at page 13, line 48
<tlv> = <tlv-type> <tlv> = <tlv-type>
<tlv-semantics> <tlv-semantics>
<index-start>? <index-start>?
<index-stop>? <index-stop>?
<length>? <length>?
<value>? <value>?
where: where:
<tlv-type> is an 8 bit field, specifying the type of the TLV, <tlv-type> is an 8 bit field, specifying the type of the TLV,
specific to the TLV kind (i.e. packet- message- or address block specific to the TLV kind (i.e. packet, message, or address block
TLV). TLV).
<tlv-semantics> is an 8 bit field specifying the interpretation of <tlv-semantics> is an 8 bit field specifying the interpretation of
the remainder of the TLV: the remainder of the TLV:
bit 0 (extended) and bit 1 (novalue): MUST NOT both be set ('1'). bit 0 (extended) and bit 1 (novalue): MUST NOT both be set ('1').
Otherwise, they are interpreted according to Table 2. Otherwise, they are interpreted according to Table 2.
+----------+---------+--------------+--------------+ +----------+---------+--------------+--------------+
| extended | novalue | <length> | <value> | | extended | novalue | <length> | <value> |
skipping to change at page 16, line 18 skipping to change at page 16, line 21
order. order.
Two or more TLVs of the same type associated with the same address Two or more TLVs of the same type associated with the same address
block MUST NOT both cover any address. block MUST NOT both cover any address.
TLVs of the same type associated with the same address block MUST be TLVs of the same type associated with the same address block MUST be
sorted in ascending index-start order. sorted in ascending index-start order.
5.4. Padding 5.4. Padding
Packet headers and messages can be padded to ensure 32 bit alignment Packet headers and messages MAY be padded to ensure 32 bit alignment
of each message contained within the packet and of the overall packet of each message contained within the packet and of the overall packet
length. length.
All elements are an integer multiple of octets, hence padding can be All elements are an integer multiple of octets, hence padding can be
accomplished by inserting an integer number of <pad-octet> elements accomplished by inserting an integer number of <pad-octet> elements
after the element that is to be 32 bit aligned. after the element that is to be 32 bit aligned.
The number of <pad-octet> elements required to achieve this 32 bit The number of <pad-octet> elements required to achieve this 32 bit
alignment is the smallest number (0 to 3) that, when added to the alignment is the smallest number (0 to 3) that, when added to the
size of the preceding elements, produces an integer multiple of 4. size of the preceding elements, produces an integer multiple of 4.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
TLV may be considered to have a prefix length equal to the address TLV may be considered to have a prefix length equal to the address
length in bits (i.e. address-length times 8). length in bits (i.e. address-length times 8).
7. IANA Considerations 7. IANA Considerations
A new registry for message types must be created with initial A new registry for message types must be created with initial
assignments as specified in Table 6. Future values in the range assignments as specified in Table 6. Future values in the range
5-127 can be allocated using standards action [3]. Additionally, 5-127 can be allocated using standards action [3]. Additionally,
values in the range 128-255 are reserved for private/local use. values in the range 128-255 are reserved for private/local use.
+-------+----------------------------------------+
| Value | Description |
+-------+----------------------------------------+
| 0 | MUST NOT be allocated. |
| | |
| 1-4 | RESERVED |
+-------+----------------------------------------+
Table 6
Message type 0 MUST NOT be allocated because a zero-octet signifies a
packet header and zero-octets are used for padding. Message types 1
to 4 are reserved because they are used by OLSR [4], which uses a
compatible packet/message header format.
A new registry for packet TLV types must be created, with no initial A new registry for packet TLV types must be created, with no initial
assignments. Future values in the range 0-127 can be allocated using assignments. Future values in the range 0-127 can be allocated using
standards action [3]. Additionally, values in the range 128-255 are standards action [3]. Additionally, values in the range 128-255 are
reserved for private/local use. reserved for private/local use.
A new registry for message TLV types must be created with no initial A new registry for message TLV types must be created with no initial
assignments. Future values in the range 0-127 can be allocated using assignments. Future values in the range 0-127 can be allocated using
standards action [3]. Additionally, values in the range 128-255 are standards action [3]. Additionally, values in the range 128-255 are
reserved for private/local use. reserved for private/local use.
A new registry for address block TLV types must be created with A new registry for address block TLV types must be created with
initial assignments as specified in Table 7. Future values in the initial assignments as specified in Table 7. Future values in the
range 1-127 can be allocated using standards action [3]. range 1-127 can be allocated using standards action [3].
Additionally, values in the range 128-255 are reserved for private/ Additionally, values in the range 128-255 are reserved for private/
local use. local use.
+-------+----------------------------------------+
| Value | Description |
+-------+----------------------------------------+
| 0 | MUST NOT be allocated. |
| | |
| 1-4 | RESERVED |
+-------+----------------------------------------+
Table 6
Message type 0 MUST NOT be allocated because a zero-octet signifies a
packet header and zero-octets are used for padding. Message types 1
to 4 are reserved because they are used by OLSR [4], which uses a
compatible packet/message header format.
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| PREFIX_LENGTH | 0 | Indicates that associated addresses | | PREFIX_LENGTH | 0 | Indicates that associated addresses |
| | | are network addresses, with given | | | | are network addresses, with given |
| | | prefix length. | | | | prefix length. |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
Table 7 Table 7
8. Security Considerations 8. Security Considerations
Messages are designed to be carriers of protocol information and MAY, Messages are designed to be carriers of protocol information and MAY,
at each hop, be forwarded and/or processed according to the at each hop, be forwarded and/or processed according to the
information in the message header by the protocol using this information in the message header by the protocol using this
specification. If forwarded messages are unchanged by this protocol, specification.
then end-to-end security MAY be implemented, between nodes with an
existing security association, by including a suitable message TLV For forwarded messages where the message is unchanged by forwarding
containing a cryptographic signature to the message. Since <hop- nodes, then end-to-end security MAY be implemented, between nodes
count> and <hop-limit> are the only fields that may be modified when with an existing security association, by including a suitable
such a message is forwarded, this signature can be calculated based message TLV containing a cryptographic signature in the message.
on the entire message, including the message header, with the <hop- Since <hop-count> and <hop-limit> are the only fields that may be
count> and <hop-limit> fields set to zero ('0') if present. modified when such a message is forwarded in this manner, this
signature can be calculated based on the entire message, including
the message header, with the <hop-count> and <hop-limit> fields set
to zero ('0') if present.
Packets are designed to carry a number of messages between Packets are designed to carry a number of messages between
neighboring nodes in a single transmission and over a single logical neighboring nodes in a single transmission and over a single logical
hop. Hop-by-hop packet level security MAY be implemented, between hop. Hop-by-hop packet level security MAY be implemented, between
nodes with an existing security association, by including a suitable nodes with an existing security association, by including a suitable
packet TLV containing a cryptographic signature to the packet. Since packet TLV containing a cryptographic signature to the packet. Since
packets are received as transmitted, this signature can be calculated packets are received as transmitted, this signature can be calculated
based on the entire packet, or on parts thereof as appropriate. based on the entire packet, or on parts thereof as appropriate.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Addressing Architecture", RFC 3513, April 2003. Architecture", RFC 4291, February 2006.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998. Considerations Section in RFCs", October 1998.
9.2. Informative References 9.2. Informative References
[4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
Appendix A. Illustrations Appendix A. Illustrations
This informative appendix illustrates the elements, which are This informative appendix illustrates the elements, which are
normatively specified in Section 5 using regular expressions. normatively specified in Section 5 using regular expressions.
Bits labeled Reserved or Resv are cleared ('0'). Bits labeled N and Bits labeled Reserved, Resv, or Rsv are cleared ('0'). Bits labeled
M may be cleared ('0') or set ('1'). Octets labeled Padding are N and M may be cleared ('0') or set ('1'). Octets labeled Padding
cleared ('0'), and are optional. are cleared ('0'), and are optional.
Appendix A.1. Packet Appendix A.1. Packet
0 1 2 3 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 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 | |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
skipping to change at page 23, line 25 skipping to change at page 23, line 25
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix A.2. Message and Padding Appendix A.2. Message and Padding
0 1 2 3 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 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 | | Message Type | Rsv |N|0|0|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |0|0|1| Message Size | | Message Type | Rsv |0|0|0|0|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 | | Message Type | Rsv |N|0|0|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |0|0|0|1|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|0|1|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|0|1|0|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|0|1|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 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 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 |0|1|1| Message Size | | Message Type | Rsv |N|0|1|1|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|0|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|0|0|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|0|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|0|1|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|1|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|1|0|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | |
+-+-+-+-+-+-+-+-+ |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|1|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Rsv |N|1|1|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix A.3. Message Body Appendix A.3. Message Body
skipping to change at page 31, line 8 skipping to change at page 35, line 8
0 1 2 3 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 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|0| Index Start | | Type |Resv |0|1|0|1|0| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Complete Example Appendix B. Complete Example
An example packet, using IPv4 addresses (length four octets) is An example packet, using IPv4 addresses (length four octets) is
shown. This packet has a header, with a packet sequence number but shown. This packet has a header, indicated by the initial octet 0.
no packet TLV block, and contains a single message. The message has The packet header has semantics octet 0, and hence has a packet
a complete message header, a message TLV block of content length 9 sequence number, but no packet TLV block.
octets containing a single TLV (with the noindex bit of its semantics
octet set and value length 6 octets) and then two address blocks each The packet contains a single message. This message has semantics
with a following TLV block. The first address block contains 3 octet 0, and hence has a complete message header, including
addresses, has the notail bit of the its semantics octet set, and has originator address, hop limit, hop count and message sequence number
head length 2 octets, hence mid length two octets. It is followed by (which is type independent). The message has a message TLV block
a TLV block with content length 9 octets containing two TLVs. The with content length 9 octets, containing a single TLV. This TLV has
first of these TLVs has the noindex bit of its semantics octet set the noindex bit of its semantics octet 4 set, and has value length 6
and has a single value of length 2 octets, which applies to all of octets. The message then has two address blocks each with a
the addresses in the preceding address block. The second of these following TLV block.
TLVs has the novalue bit of its semantics octet set and hence has no
length or value fields (it does have index fields, which indicate The first address block contains 3 addresses. It has the notail bit
those addresses this TLV applies to). The second address block of its semantics octet 2 set, and has head length 2 octets, hence mid
contains 2 addresses, has the nohead and zerotail bits of its length two octets. It is followed by a TLV block, with content
semantics octet set, and has tail length 2 octets, hence mid length length 9 octets, containing two TLVs. The first of these TLVs has
two octets. The two tail octets of each address are zero. It is the noindex bit of its semantics octet 4 set, and has a single value
followed by a TLV block of content length 5 octets. This TLV block of length 2 octets, which applies to all of the addresses in the
contains a single TLV of type PREFIX_LENGTH that has the multivalue address block. The second of these TLVs has the novalue bit of its
and noindex bits of its semantics octet set and a value field length semantics octet 2 set, and hence has no length or value fields. It
of 2 octets, indicating two values each of one octet length. There does have index fields, which indicate those addresses this TLV
is one final padding octet that is not included in the message length applies to.
of 59 octets.
The second address block contains 2 addresses. It has the nohead and
zerotail bits of its semantics octet 5 set, and has tail length 2
octets, hence mid length two octets. The two tail octets of each
address are zero. It is followed by a TLV block with content length
5 octets. This TLV block contains a single TLV of type PREFIX_LENGTH
that has the multivalue and noindex bits of its semantics octet 20
set, and a value field length of 2 octets, indicating two values each
of one octet length. There is one final padding octet 0 that is not
included in the message length of 59 octets.
0 1 2 3 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 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 | |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1| | Message Type |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | 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|0|1|0|0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| Value | |0 0 0 0 0 1 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 1| | Value (cont) |0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head | |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| | Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value | | TLV Type |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) | TLV Type |Resv |0|0|0|1|0| Index Start | | Value (cont) | TLV Type |0 0 0 0 0 0 1 0| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Stop |0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 1 0| | Index Stop |0 0 0 0 0 0 1 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| PREFIX_LENGTH |0 0 0 1 0 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 1 0| Value0 | Value1 |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix C. Contributors Appendix C. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors from the OLSRv2 Design Team -- listed following contributors from the OLSRv2 Design Team -- listed
alphabetically. alphabetically.
 End of changes. 41 change blocks. 
109 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/