draft-ietf-manet-packetbb-13.txt   draft-ietf-manet-packetbb-14.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: December 26, 2008 BAE Systems Advanced Technology Expires: February 2, 2009 BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
June 24, 2008 August 1, 2008
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-13 draft-ietf-manet-packetbb-14
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 December 26, 2008. This Internet-Draft will expire on February 2, 2009.
Abstract Abstract
This document specifies a packet format capable of carrying multiple This document specifies a packet format capable of carrying multiple
messages that may be used by mobile ad hoc network routing protocols. messages that may be used by mobile ad hoc network routing protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4 2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7 5. Syntactical Specification . . . . . . . . . . . . . . . . . . 7
5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10
5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13
5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 17 5.4.2. TLV Inclusion and Constraints . . . . . . . . . . . . 17
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19
6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1. Message Type Specific TLV Registry Creation . . . . . 21 6.2.1. Message Type Specific TLV Registry Creation . . . . . 21
6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 21 6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Packet TLV Type Extension Registry Creation . . . . . 21 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 22
6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 21 6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 22
6.4.1. Message TLV Type Extension Registry Creation . . . . . 22 6.4.1. Message TLV Type Extension Registry Creation . . . . . 22
6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 22 6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 23
6.5.1. Address Block TLV Type Extension Registry Creation . . 23 6.5.1. Address Block TLV Type Extension Registry Creation . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 7.1. Authentication and Integrity Suggestions . . . . . . . . . 24
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Intended Usage . . . . . . . . . . . . . . . . . . . 26 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 26
Appendix B. Multiplexing and Demultiplexing . . . . . . . . . . . 27 Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 27
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28
C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28 C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 28
C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This document specifies the syntax of a packet format designed to This document specifies the syntax of a packet format designed to
carrying multiple messages for information exchange between MANET carrying multiple messages for information exchange between MANET
(Mobile Ad hoc NETwork) routers. Messages consist of a message (Mobile Ad hoc NETwork) routers. Messages consist of a message
header, which is designed for control of message dissemination, and a header, which is designed for control of message dissemination, and a
message body, which contains protocol information. Only the syntax message body, which contains protocol information. Only the syntax
of the packet and messages is specified. All syntactical entities, of the packet and messages is specified.
including packets and messages, are specified using a regular
expression derived notation.
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. A packet with zero messages may be within a single transmission. A packet with zero messages may be
sent in case the only information to exchange is contained in the sent in case the only information to exchange is contained in the
packet header. packet header.
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.
skipping to change at page 3, line 48 skipping to change at page 3, line 46
o A generalized type-length-value (TLV) format representing o A generalized type-length-value (TLV) format representing
attributes. Each TLV can be associated with a packet, a message, attributes. Each TLV can be associated with a packet, a message,
or one or more addresses or address prefixes in a single address or one or more addresses or address prefixes in a single address
block. Multiple TLVs can be included and each associated with a block. Multiple TLVs can be included and each associated with a
packet, a message, and with the same, different or overlapping packet, a message, and with the same, different or overlapping
sets of addresses or address prefixes. sets of addresses or address prefixes.
The specification has been explicitly designed with the following The specification has been explicitly designed with the following
properties, listed in no particular order, in mind: properties, listed in no particular order, in mind:
Parsing logic - the regular expression derived notation used in this Parsing logic - The notation used in this specification facilitates
specification facilitates generic, protocol independent, parsing generic, protocol independent, parsing logic.
logic.
Extensibility - packets and messages defined by a protocol using Extensibility - Packets and messages defined by a protocol using
this specification are extensible by defining new message types this specification are extensible by defining new message types
and new TLVs. Protocols using this specification will be able to and new TLVs. Protocols using this specification will be able to
correctly identify and skip such new message types and TLVs, while correctly identify and skip such new message types and TLVs, while
correctly parsing the remainder of the packet and message. 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. address prefixes or IPv6 interface identifiers) the address (e.g. address prefixes or IPv6 interface identifiers) the address
block representation allows for a compact representation. Compact block representation allows for a compact representation. Compact
message headers are ensured through permitting inclusion of only message headers are ensured through permitting inclusion of only
required message header elements. The structure of packet and required message header elements. The multi message packet
message encoding allows parsing, verifying, and identifying structure allows a reduction in the number of transmitted octets
and in the number of transmitted packets. The structure of packet
and message encoding allows parsing, verifying, and identifying
individual elements in a single pass. individual elements in a single pass.
Separation of forwarding and processing - a protocol using this Separation of forwarding and processing - A protocol using this
specification can be designed such that duplicate detection and specification can be designed such that duplicate detection and
controlled scope message forwarding decisions can be made using controlled scope message forwarding decisions can be made using
information contained in the message header, without processing information contained in the message header, without processing
the message body. the message body.
2. Notation and Terminology 2. Notation and 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the notation in Section 2.1, and the Additionally, this document uses the notation in Section 2.1, and the
terminology in Section 2.2. terminology in Section 2.2.
2.1. Notation 2.1. Notation
This specification uses a derivative of the regular expression The following notations, for elements and variables, are used in this
language from [SingleUNIX], [POSIX] or [ECMAScript], using only the document.
following notation:
Element - A group of any number of consecutive bits which, together, 2.1.1. Elements
forms a syntactic entity, represented using the notation <foo>.
<foo> - If <foo> is an unsigned integer field then <foo> is also This specification defines elements. An element is a group of any
used to represent the value of that field. number of consecutive bits which together form a syntactic entity
represented using the notation <element>. Each element in this
document is defined as either:
bar - A variable, usually obtained through calculations based on the o A specifically sized field of bits; OR
value(s) of element(s). Variables are introduced into the
specification solely as a means to clarify the description.
:= - Indicates that the element or variable on the left hand side is o A composite element, composed of other <element>s.
defined as the expression on the right hand side.
A composite element is defined as follows:
<element> := specification
where, on the right hand side following :=, specification is
represented using the regular expression syntax defined in
[SingleUNIX]. Only the following notation is used:
<element1><element2> - Indicates that <element1> is immediately
followed by <element2>.
(<element1><element2>) - Indicates a grouping of the elements (<element1><element2>) - Indicates a grouping of the elements
enclosed by the parentheses. enclosed by the parentheses.
? - Zero or one occurrences of the preceding element or group. ? - Zero or one occurrences of the preceding element or group.
* - Zero or more occurrences of the preceding element or group. * - Zero or more occurrences of the preceding element or group.
2.1.2. Variables
Variables are introduced into the specification solely as a means to
clarify the description. The following two notations are used:
<foo> - If <foo> is an unsigned integer field then <foo> is also
used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the
value(s) of element(s).
The following variable is defined:
address-length - A variable whose value is the length of an address address-length - A variable whose value is the length of an address
in octets, it is 4 if using IPv4, or 16 if using IPv6. in octets, it is 4 if using IPv4, or 16 if using IPv6.
2.2. Terminology 2.2. Terminology
This document uses the following terminology: This document uses the following terminology:
Packet - The top level entity in this specification. A packet Packet - The top level entity in this specification. A packet
contains a packet header and zero or more messages. contains a packet header and zero or more messages.
skipping to change at page 6, line 41 skipping to change at page 7, line 10
of the algorithm used by the routing protocol. of the algorithm used by the routing protocol.
All addresses within a message are assumed to be of the same size, All addresses within a message are assumed to be of the same size,
deduced from the IP header. In the case of mixed IPv6 and IPv4 deduced from the IP header. In the case of mixed IPv6 and IPv4
addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6
addresses as specified in [RFC4291]. Packets may be unicast or addresses as specified in [RFC4291]. Packets may be unicast or
multicast, and may use any appropriate transport protocol, or none. multicast, and may use any appropriate transport protocol, or none.
The messages defined by this specification are designed to carry The messages defined by this specification are designed to carry
MANET routing protocol signaling between MANET routers. This MANET routing protocol signaling between MANET routers. This
specification includes elements which can support limited diffusion specification includes elements which can support scope limited
(flooding), as well as being usable for point to point delivery of flooding, as well as being usable for point to point delivery of
MANET routing protocol signaling in a multi-hop network. MANET routing protocol signaling in a multi-hop network.
A MANET routing protocol using the packet format defined by this A MANET routing protocol using the packet format defined by this
specification can constrain the syntax (for example requiring a specification can constrain the syntax (for example requiring a
specific set of message header fields) that the protocol will employ. specific set of message header fields) that the protocol will employ.
Protocols with such restrictions need not be able to parse all Protocols with such restrictions need not be able to parse all
possible packet structures as defined by this document but must be possible packet structures as defined by this document but must be
coherent in packet generation and reception of packets of which they coherent in packet generation and reception of packets of which they
define. If a protocol specifies which elements are included, then define. If a protocol specifies which elements are included, then
direct indexing of the appropriate fields is possible, dependant on direct indexing of the appropriate fields is possible, dependant on
skipping to change at page 9, line 45 skipping to change at page 10, line 13
limit> is included in the <msg-header>. limit> is included in the <msg-header>.
bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is
not included in the <msg-header>. If set ('1'), then <msg-hop- not included in the <msg-header>. If set ('1'), then <msg-hop-
count> is included in the <msg-header>. count> is included in the <msg-header>.
bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not
included in the <msg-header>. If set ('1'), then <msg-seq-num> included in the <msg-header>. If set ('1'), then <msg-seq-num>
is included in the <msg-header>. is included in the <msg-header>.
bit 4 (mistypedep): If cleared ('0'), then the message sequence bit 4 (mnouniord): If cleared ('0'), then the message TLV block
number in the message is type-independent. If set ('1'), then
the message sequence number contained in the message is type
dependent (the message originator maintains a sequence number
specific to <msg-type>). This msg-flag MUST be cleared ('0')
if the mhasorig msg-flag is cleared ('0').
bit 5 (mnouniord): If cleared ('0'), then the message TLV block
and all address TLV blocks in the message MUST conform to the and all address TLV blocks in the message MUST conform to the
constraints in Section 5.4.2. If set ('1'), then the message constraints in Section 5.4.2. If set ('1'), then the message
TLV block and all address TLV blocks in the message are not TLV block and all address TLV blocks in the message are not
subject to the constraints in Section 5.4.2. Additional subject to the constraints in Section 5.4.2. Additional
constraints MAY be imposed by a protocol using this constraints MAY be imposed by a protocol using this
specification. specification.
bit 6-7: Are RESERVED, and SHOULD each be cleared ('0') on bit 5-7: Are RESERVED, and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission, and SHOULD be ignored on reception.
<msg-size> is a 16 bit unsigned integer field, specifying the number <msg-size> is a 16 bit unsigned integer field, specifying the number
of octets that make up the <message>, including the <msg-header>. of octets that make up the <message>, including the <msg-header>.
<msg-orig-addr> is omitted if the mhasorig msg-flag is cleared <msg-orig-addr> is omitted if the mhasorig msg-flag is cleared
('0'), otherwise is an identifier with length equal to address- ('0'), otherwise is an identifier with length equal to address-
length, which can serve to uniquely identify the node that length, which can serve to uniquely identify the MANET router that
originated the message. originated the message.
<msg-hop-limit> is omitted if the mhashoplimit msg-flag is cleared <msg-hop-limit> is omitted if the mhashoplimit msg-flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'), otherwise is an 8 bit unsigned integer field, which can
contain the maximum number of hops that the message should be contain the maximum number of hops that the message should be
further transmitted. further transmitted.
<msg-hop-count> is omitted if the mhashopcount msg-flag is cleared <msg-hop-count> is omitted if the mhashopcount msg-flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'), otherwise is an 8 bit unsigned integer field, which can
contain the number of hops that the message has traveled. contain the number of hops that the message has traveled.
<msg-seq-num> is omitted if the mhasseqnum msg-flag is cleared <msg-seq-num> is omitted if the mhasseqnum msg-flag is cleared
('0'), otherwise is a 16 bit unsigned integer field, which can ('0'), otherwise is a 16 bit unsigned integer field, which can
contain a sequence number, generated by the message's originator contain a sequence number, generated by the message's originator
node. MANET router.
5.3. Address Blocks 5.3. Address Blocks
An address block can specify one or more addresses. It can also An address block can specify one or more addresses. It can also
specify prefix lengths that can be applied to all addresses in the specify prefix lengths that can be applied to all addresses in the
address block. This allows an address block to specify either address block. This allows an address block to specify either
addresses or address prefixes. A protocol may specify that an addresses or address prefixes. A protocol may specify that an
address with a maximum prefix length (equal to the address length, in address with a maximum prefix length (equal to the address length, in
bits) is considered to be an address, rather than an address prefix, bits) is considered to be an address, rather than an address prefix,
thus allowing an address block to contain a mixture of addresses and thus allowing an address block to contain a mixture of addresses and
skipping to change at page 24, line 9 skipping to change at page 24, line 22
specification. Mechanisms which may form part of an authentication specification. Mechanisms which may form part of an authentication
and integrity approach in a protocol using this specification, are and integrity approach in a protocol using this specification, are
described in Section 7.1. Mechanisms which may form part of a described in Section 7.1. Mechanisms which may form part of a
confidentiality approach in a protocol using this specification, are confidentiality approach in a protocol using this specification, are
described in Section 7.2. There is however no requirement that a described in Section 7.2. There is however no requirement that a
protocol using this specification should use either. protocol using this specification should use either.
7.1. Authentication and Integrity Suggestions 7.1. Authentication and Integrity Suggestions
The authentication and integrity suggestions made here, are based on The authentication and integrity suggestions made here, are based on
the intended usage in Appendix A, specifically that: the intended usage in Appendix B, specifically that:
o Messages are designed to be carriers of protocol information and o Messages are designed to be carriers of protocol information and
MAY, at each hop, be forwarded and/or processed by the protocol MAY, at each hop, be forwarded and/or processed by the protocol
using this specification. using this specification.
o Packets are designed to carry a number of messages between o Packets are designed to carry a number of messages between
neighboring nodes in a single transmission and over a single neighboring MANET routers in a single transmission and over a
logical hop. single logical hop.
Consequently: Consequently:
o For forwarded messages where the message is unchanged by o For forwarded messages where the message is unchanged by
forwarding nodes, then end-to-end authentication and integrity MAY forwarding MANET routers, then end-to-end authentication and
be implemented, between nodes with an existing security integrity MAY be implemented, between MANET routers with an
association, by including a suitable message TLV containing a existing security association, by including a suitable message TLV
cryptographic signature in the message. Since <hop-count> and containing a cryptographic signature in the message. Since <msg-
<hop-limit> are the only fields that should be modified when such hop-count> and <msg-hop-limit> are the only fields that should be
a message is forwarded in this manner, this signature can be modified when such a message is forwarded in this manner, this
calculated based on the entire message, including the message signature can be calculated based on the entire message, including
header, with the <hop-count> and <hop-limit> fields set to 0 if the message header, with the <msg-hop-count> and <msg-hop-limit>
present. fields set to 0 if present.
o Hop-by-hop packet level authentication and integrity MAY be o Hop-by-hop packet level authentication and integrity MAY be
implemented, between nodes with an existing security association, implemented, between MANET routers with an existing security
by including a suitable packet TLV containing a cryptographic association, by including a suitable packet TLV containing a
signature to the packet. Since packets are received as cryptographic signature to the packet. Since packets are received
transmitted, this signature can be calculated based on the entire as transmitted, this signature can be calculated based on the
packet, or on parts thereof as appropriate. entire packet, or on parts thereof as appropriate.
7.2. Confidentiality Suggestions 7.2. Confidentiality Suggestions
This specification does not explicitly enable protecting packet/ This specification does not explicitly enable protecting packet/
message confidentiality. Such confidentiality would normally, when message confidentiality. Such confidentiality would normally, when
required, be provided hop-by-hop either by link-layer mechanisms, or required, be provided hop-by-hop either by link-layer mechanisms, or
at the IP layer using [RFC4301], and would apply to a packet only. at the IP layer using [RFC4301], and would apply to a packet only.
It is possible, however, for a protocol using this specification to It is possible, however, for a protocol using this specification to
protect the confidentiality of information included in a packet, protect the confidentiality of information included in a packet,
skipping to change at page 25, line 46 skipping to change at page 26, line 10
an IANA Considerations Section in RFCs", RFC 5226, an IANA Considerations Section in RFCs", RFC 5226,
BCP 26, May 2008. BCP 26, May 2008.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
1/SC22/WG15, "Single UNIX Specification, Version 3, 1/SC22/WG15, "Single UNIX Specification, Version 3,
2004 Edition", April 2004. 2004 Edition", April 2004.
[POSIX] ISO/IEC Standard 9945-1:2003, "Portable Operating
System Interface (POSIX) - Part 1: Base Definitions",
January 2003.
[ECMAScript] ISO/IEC Standard 9845-1:2003, "Ecma-262, ECMAScript
Language Specification", January 2003.
8.2. Informative References 8.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The
Protocols.", 1994. Protocols.", 1994.
Appendix A. Intended Usage Appendix A. Multiplexing and Demultiplexing
The packet and message format specified in this document is designed The packet and message format specified in this document is designed
to carry MANET routing protocol signaling between MANET routers, and to allow zero or more messages to be contained within a single
to support scope limited diffusion (flooding) as well as point-to- packet. Such messages may be from the same or from different
point delivery. protocols. Thus, a multiplexing and demultiplexing process MUST be
present.
Specifically: Multiplexing messages on a given MANET router into a single packet,
rather than to have each message generate its own packet, reduces the
total number of octets, and the number of packets transmitted by that
MANET router.
o Packets are transmitted over a single logical hop and are not The multiplexing and demultiplexing process running on a given UDP
forwarded. Messages are designed to be able to be forwarded over port or IP protocol number, and its associated protocols, MUST:
one or more logical hops, in a new packet for each logical hop.
Each logical hop may consist of one or more IP hops. Packets may
contain a different combination of messages for each logical hop.
Packets may be formed from messages from more than one MANET
routing protocol; the use of a single message type space for all
such protocols allows these messages to be separated by protocol.
o Scope limited flooding is supported for messages thus: o For each message type, a protocol - unless specified otherwise,
the one making the IANA reservation for that message type - MUST
be designated as the "owner" of that message type.
* If the mhasorig and mhasseqnum msg-flags are both set ('1') o The packet header fields, including the Packet TLV block, is used
then the message header provides for duplicate suppression, by the multiplexing and demultiplexing process, which MAY make
using the identifier consisting of the message's <msg-orig- such information available for use its protocol instances.
addr>, <msg-seq-num>, and, if the mistypedep flag in the <msg-
flags> field is set ('1'), <msg-type>. These serve to uniquely
identify the message in the network within the time period
until <msg-seq-num> is repeated, i.e. wraps around to a
matching value if used sequentially.
* If the mhashoplimit msg-flag is set ('1'), then the message o The <pkt-seq-num> field, if present, contains a sequence number
header provides the information to make forwarding decisions which is incremented by 1 for each packet generated by a node.
for scope limited diffusion (flooding). This may be by any The sequence number after 65535 is 0. In other words, the
appropriate flooding mechanism specified by a protocol using sequence number "wraps" in the usual way.
this specification.
* <msg-hop-limit> SHOULD, if present, be decremented, usually by o Incoming messages MUST be either silently discarded or MUST be
one, if the message is forwarded. delivered to the instance of the protocol which owns the
associated message type. Incoming messages SHOULD NOT be
delivered to any other protocol instances and SHOULD NOT be
delivered to more than one protocol instance.
* <msg-hop-count> SHOULD, if present, be incremented, usually by o Outgoing messages of a given type MUST be generated only by the
one, if the message is forwarded. protocol instance which owns that message type and delivered to
the multiplexing and demultiplexing process.
Appendix B. Multiplexing and Demultiplexing o If two protocols both wish to use the same message type then this
interaction SHOULD be specified by the protocol which is the
designated owner of that message type.
The packet and message format specified in this document is designed Appendix B. Intended Usage
to allow zero or more messages to be contained within a single packet
(e.g. a single IP datagram or UDP datagram). Such messages may be
from the same or may be from different protocols. In the latter
case, multiplexing of outgoing messages from different protocols and
demultiplexing of incoming messages contained within a single packet,
must be addressed.
Multiplexing messages of different message types from different This appendix describes the intended usage of message header fields
protocols running on a given node into a single packet, rather than including their content and use. Alternative uses of this
to have each protocol generate its own packet, is an optimization. specification are permitted.
Doing so may reduce the total number of octets as transmitted by that
node, while not doing so should not have any adverse effects on
protocol functioning.
Having two different protocols (or, two different instances of the The message format specified in this document is designed to carry
same protocol) generate messages of the same message type on the same MANET routing protocol signaling between MANET routers, and to
interface may, however, cause inconsistencies, unless this message support scope limited flooding as well as point-to-point delivery.
generation is coordinated.
If a packet contains messages destined for multiple protocols, Messages are designed to be able to be forwarded over one or more
correct functioning of each of these protocols depends on the logical hops, in a new packet for each logical hop. Each logical hop
appropriate messages being delivered to each protocol. may consist of one or more IP hops.
If multiple protocols which are using the packet and message format Specifically Scope limited flooding is supported for messages by:
specified in this document are running over the same UDP port or IP
protocol number, multiplexing and demultiplexing of messages SHOULD
be accomplished based on message types, ensuring a correspondence
between message types and protocol instances thus:
o For each message type, a protocol - unless specified otherwise, o The <msg-orig-addr> field, if present, contains the unique
the one making the IANA reservation for that message type - SHOULD identifier of the MANET router which originated the message.
be designated as the "owner" of that message type.
o On a given interface, and for a given UDP port or IP protocol o The <msg-seq-num> field, if present, contains a sequence number
number, only one protocol instance of a protocol which is the which starts at 0 when first message of a given type is generated
designated "owner" of a message type SHOULD be running, by the originator node, and is incremented by 1 for each message
generated of that type. The sequence number after 65535 is 0. In
other words, the sequence number "wraps" in the usual way.
o Any incoming messages of a given message type SHOULD be delivered o If the <msg-orig-addr> and <msg-seq-num> fields are both present,
to the protocol instance on the receiving interface which "owns" then the message header provides for duplicate suppression, using
messages of that type. Specifically, any incoming message SHOULD the identifier consisting of the message's <msg-orig-addr>, <msg-
NOT be delivered to any other protocol instances and SHOULD NOT be seq-num>, and <msg-type>. These serve to uniquely identify the
delivered to more than one protocol instance. message in the MANET within the time period until <msg-seq-num> is
repeated, i.e. wraps around to a matching value.
o Any outgoing messages of a given type SHOULD be generated and o <msg-hop-limit> field, if present, contains the number of hops on
transmitted only by the protocol instance which "owns" that which the packet is allowed to travel before being discarded by a
message type. MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly
circulating in a MANET. When forwarding a message, a MANET router
SHOULD decrease the <msg-hop-limit> by 1, and the message SHOULD
be discarded when <msg-hop-limit> reaches 0.
o If two protocols both wish to use the same message type (e.g. o <msg-hop-count> field, if present, contains the number of hops on
through inspecting information carried in messages of that type, which the packet has traveled across the MANET. The <msg-hop-
or through inserting information into generated messages of that count< is set to 0 by the message originator and is used to
type) then this interaction SHOULD be specified by the protocol prevent messages from endlessly circulating in a MANET. When
which is the designated "owner" of that message type. forwarding a message, a MANET router SHOULD increase <msg-hop-
count> by 1 and SHOULD discarded the message when <msg-hop-count>
reaches 255.
o If the <msg-hop-limit> and <msg-hop-limit> fields are both
present, then the message header provides the information to make
forwarding decisions for scope limited flooding. This may be by
any appropriate flooding mechanism specified by a protocol using
this specification.
Appendix C. Examples Appendix C. Examples
This appendix contains some examples of parts of this specification. This appendix contains some examples of parts of this specification.
C.1. Address Block Examples C.1. Address Block Examples
The following examples illustrate how some combinations of addresses The following examples illustrate how some combinations of addresses
may be efficiently included in address blocks. These examples are may be efficiently included in address blocks. These examples are
for IPv4, with address-length equal to 4. a, b, c etc. represent for IPv4, with address-length equal to 4. a, b, c etc. represent
skipping to change at page 32, line 47 skipping to change at page 33, line 10
then <tlv-flags> would also have thasextlen set and have value 24. then <tlv-flags> would also have thasextlen set and have value 24.
The length would require two octets (most significant first). The The length would require two octets (most significant first). The
TLV length would be 4 + N octets, where N is the number of data TLV length would be 4 + N octets, where N is the number of data
octets (it can be 3 + N octets if N is 255 or less). octets (it can be 3 + N octets if N is 255 or less).
Appendix D. Illustrations Appendix D. Illustrations
This informative appendix illustrates the elements which are This informative appendix illustrates the elements which are
normatively specified in Section 5. normatively specified in Section 5.
Bits labeled Rsv or R should be cleared ('0'). Bits labeled C, N, or Bits labeled Rsv or R should be cleared ('0'). Bits labeled C or M
M may be cleared ('0') or set ('1'). may be cleared ('0') or set ('1').
D.1. Packet D.1. Packet
Possible options for the <packet> element. These are differentiated Possible options for the <packet> element. These are differentiated
by the flags field in the first octet. The packet may include any by the flags field in the first octet. The packet may include any
number (zero or more) of Messages. The number of Messages is number (zero or more) of Messages. The number of Messages is
determined from when the packet is exhausted, given the packet length determined from when the packet is exhausted, given the packet length
from the network layer. from the network layer.
0 1 2 3 0 1 2 3
skipping to change at page 36, line 43 skipping to change at page 36, line 43
D.2. Message D.2. Message
Possible options for the <message> element. These are differentiated Possible options for the <message> element. These are differentiated
by their second (flags) octet. The length of the Message Body is by their second (flags) octet. The length of the Message Body is
determined using the Message Size field, which is the combined length determined using the Message Size field, which is the combined length
of all the fields shown. of all the fields shown.
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 |0|0|0|0|0|C|Rsv| Message Size | | Message Type |0|0|0|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|0|0|0|0|C|Rsv| Message Size | | Message Type |1|0|0|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|1|0|0|0|C|Rsv| Message Size | | Message Type |0|1|0|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|1|0|0|0|C|Rsv| Message Size | | Message Type |1|1|0|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|1|0|0|C|Rsv| Message Size | | Message Type |0|0|1|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|0|1|0|0|C|Rsv| Message Size | | Message Type |1|0|1|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | | | Hop Count | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|1|1|0|0|C|Rsv| Message Size | | Message Type |0|1|1|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | | | Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|1|1|0|0|C|Rsv| Message Size | | Message Type |1|1|1|0|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | | | Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|0|1|N|C|Rsv| Message Size | | Message Type |0|0|0|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|0|0|1|N|C|Rsv| Message Size | | Message Type |1|0|0|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|1|0|1|N|C|Rsv| Message Size | | Message Type |0|1|0|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|1|0|1|N|C|Rsv| Message Size | | Message Type |1|1|0|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Message Sequence Number | | | Hop Limit | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|1|1|N|C|Rsv| Message Size | | Message Type |0|0|1|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | | | Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|0|1|1|N|C|Rsv| Message Size | | Message Type |1|0|1|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number | | | Hop Count | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|1|1|1|N|C|Rsv| Message Size | | Message Type |0|1|1|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |1|1|1|1|N|C|Rsv| Message Size | | Message Type |1|1|1|1|C| Rsv | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 58, line 4 skipping to change at page 58, line 4
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:
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr> o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org> <T.Clausen@computer.org>
o Justin W. Dean, NRL, USA<jdean@itd.nrl.navy.mil> o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, o Satoh Hiroki, Hitachi SDL, Japan,
<hiroki.satoh.yj@sdl.hitachi.co.jp> <hiroki.satoh.yj@sdl.hitachi.co.jp>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, o Monden Kazuya, Hitachi SDL, Japan,
 End of changes. 73 change blocks. 
169 lines changed or deleted 176 lines changed or added

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