draft-ietf-manet-packetbb-02.txt   draft-ietf-manet-packetbb-03.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
Expires: January 29, 2007 C. Dearlove Intended status: Standards Track C. Dearlove
BAE Systems Advanced Technology Expires: August 2, 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
July 28, 2006 January 29, 2007
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-02 draft-ietf-manet-packetbb-03
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 January 29, 2007. This Internet-Draft will expire on August 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (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 . . . . . . . . . . . . . . . . . . . 12
5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 25
Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 26 Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 26
Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 27 Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 28
Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 30 Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 31
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 33
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 33 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
Signaling in a MANET (mobile ad hoc network) routing protocol This document specifies the syntax of a general purpose multi-message
consists, mainly, of stating IP addresses and attributes associated packet format for information exchange between MANET routers.
with such IP addresses. Since this is a task common to many such Messages consist of a message header, which is designed for control
protocols, this specification presents a generalized packet format, of message dissemination, and a message body, which contains protocol
suitable for signaling. This format may be employed both by mobile information. Only the syntax of the message body is specified. All
ad hoc network routing protocols and by other protocols with similar syntactical entities, including messages and packets, are specified
requirements. using regular expressions.
This document is a specification of a multi-message packet format.
Messages encapsulate protocol information (including addresses and
their attributes), and are themselves are encapsulated in packets.
The structure of addresses, attributes, messages, and packets is
specified via regular expressions. This specification gives the
syntax, but not the interpretation, of the information carried within
a packet, other than the header information which may be used to
control the dissemination of the messages. Packets are intended to
be encapsulated by a suitable transport protocol, typically UDP, and
carried over IP (IPv4 or IPv6).
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.
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 4, line 8 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. 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 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 this Extensibility - packets and messages defined by a protocol using
specification are extensible through defining new message types this specification are extensible through defining new message
and new TLVs. Full backward compatibility can be maintained. types and new TLVs. Full backward compatibility can be
maintained.
Efficiency - when reported addresses share common bit sequences (e.g. Efficiency - when reported addresses share common bit sequences
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.
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 solely
using information contained in the message header, without using information contained in the message header, without
processing the message body. processing 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",
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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
transmitted hop-by-hop and are not forwarded. A packet contains transmitted hop-by-hop and are not forwarded. A packet contains
zero or more messages, and may contain a packet header. zero or more messages, and may contain a packet header.
Message - the fundamental entity carrying protocol information, in Message - the fundamental entity carrying protocol information, in
the form of addresses and TLVs. Messages are transmitted in the form of addresses and TLVs. Messages are transmitted in
packets, and may be forwarded based on their header information. packets, and may be forwarded based on their header information.
Address - an address of the same type and length as the source IP Address - an address of the same length as the source IP address in
address in the IP datagram carrying the packet. the IP datagram carrying the packet.
TLV - a Type-Length-Value structure. This is a generic way in which TLV - a Type-Length-Value structure. This is a generic way in which
an attribute can be represented and correctly parsed, without the an attribute can be represented and correctly parsed, without the
parser having to understand the attribute. parser having to understand the attribute.
element - a syntactic entity defined in the regular expression element - a syntactic entity defined in the regular expression
specification, represented using the notation <foo>. specification, represented using the notation <foo>.
<foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to <foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to
represent the value of that field. represent the value of that field.
? - zero or one occurrences of the preceding element. ? - zero or one occurrences of the preceding element.
* - zero or more occurrences of the preceding element. * - zero or more occurrences of the preceding element.
+ - one or more occurrences of the preceding element.
bar - a variable, usually obtained through calculations based on the bar - a variable, usually obtained through calculations based on the
value(s) of field(s). Variables are introduced in the value(s) of field(s). Variables are introduced into the
specification solely as a means to clarify the description. specification solely as a means to clarify the description.
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, 16 if using IPv6. in octets, it is 4 if using IPv4, 16 if using IPv6.
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 carried in IPv6 as specified in [2].
The packets defined by this specification may use any transport The messages defined by this specification are designed to carry
protocol appropriate to the protocol using this specification. When routing protocol signals between MANET routers, and to support scope
the diffusion mechanism enabled by this specification is employed, limited diffusion, as well as point to point signaling in a multi-hop
UDP may be most appropriate. network.
The packets defined by this specification are designed to carry a
number of messages between neighboring nodes in a single transmission
and over a single logical hop. The packets may use any transport
mechanism (unicast, multicast) and transport protocol (TCP, UDP, ...)
appropriate to the protocol using this specification. When the
diffusion mechanism enabled 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
specification may constrain the syntax (for example requiring a full
message header) and features (for example specifying the suggested
diffusion mechanism) that it 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,
represented by the element <packet> and the elements from which it is represented by the element <packet> and the elements from which it is
skipping to change at page 10, line 7 skipping to change at page 10, line 7
<hop-limit>? <hop-limit>?
<hop-count>? <hop-count>?
<msg-seq-number>? <msg-seq-number>?
where: where:
<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 type <msg-type> is an 8 bit field, specifying the type of message. A
with all bits cleared ('0') MUST NOT be used. The two most type with all bits cleared ('0') MUST NOT be used.
significant bits have the following semantics:
bit 7 (msguser): message types with this bit cleared ('0') are
defined in this specification or can be allocated via standards
action. Message types with this bit set ('1') are reserved for
private/local use.
bit 6 (msgprot): for message types with the msg-user bit cleared
('0'), this bit specifies, if cleared ('0'), that the message
type is protocol independent, i.e. is not specific to any one
protocol, or, if set ('1'), that the message type is specific
to the protocol for which it is defined.
<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> and
<msg-seq-number> are included in <msg-header-info>. If set <msg-seq-number> are included in <msg-header-info>. If set
('1'), then <originator-address> and <msg-seq-number> are not ('1'), then <originator-address> and <msg-seq-number> are not
included in <msg-header-info>; this reduced message header does included in <msg-header-info>; this reduced message header does
not provide for duplicate suppression. not provide for duplicate suppression.
bit 1 (nohops): if cleared ('0'), then <hop-limit> and <hop-count> bit 1 (nohops): if cleared ('0'), then <hop-limit> and <hop-
are included in the <msg-header-info>. If set ('1'), then count> are included in the <msg-header-info>. If set ('1'),
<hop-limit> and <hop-count> are not included in the <msg- then <hop-limit> and <hop-count> are not included in the <msg-
header-info>; this reduced message header does not provide for header-info>; this reduced message header does not provide for
scope-delimited forwarding. scope-delimited forwarding.
bit 2 (typedep): if cleared ('0'), then the message sequence bit 2 (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').
skipping to change at page 11, line 23 skipping to change at page 11, line 7
message has traveled. message has traveled.
<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 octets of the form head:mid: An address is specified as a sequence of address-length octets of the
tail. An address block is an ordered set of addresses sharing the form head:mid:tail. An address block is an ordered set of addresses
same head and tail, and having individual mids. sharing the same head and tail, and having individual mids.
<address block> is defined by: <address block> is defined by:
<address-block> = <num-addr> <address-block> = <num-addr>
<head-octet> <addr-semantics>
<head-length>?
<head>? <head>?
<tail-octet>? <tail-length>?
<tail>? <tail>?
<mid>* <mid>*
where: where:
<num-addr> is an 8 bit field containing the number of addresses <num-addr> is an 8 bit field containing the number of addresses
represented in the address block, which MUST NOT be zero. represented in the address block, which MUST NOT be zero.
<head-octet> is an 8 bit field, where: <addr-semantics> is an 8 bit field specifying the interpretation of
the remainder of the address block:
bits 0-6: contain the length of the head. The corresponding bit 0 (nohead): if cleared ('0'), then <head-length> is included
variable head-length is calculated by: in <address-block>, and <head> may be included in <address-
block>. If set ('1'), then <head-length> and <head> are not
included in <address-block>.
head-length = <head-octet> & 127 bit 1 (notail) and bit 2 (zerotail): MUST NOT both be set ('1').
Otherwise, they are interpreted according to Table 1.
bit 7 (notail): if cleared ('0') then the address block contains a +--------+----------+---------------+-----------------+
<tail-octet>. If set ('1') then no <tail-octet> is included. | notail | zerotail | <tail-length> | <tail> |
+--------+----------+---------------+-----------------+
| 0 | 0 | included | may be included |
| | | | |
| 0 | 1 | included | not included |
| | | | |
| 1 | 0 | not included | not included |
+--------+----------+---------------+-----------------+
<head> is omitted if head-length == 0, otherwise it is a field of the Table 1
head-length leftmost octets of all the addresses. bits 3-7: are RESERVED and MUST each be cleared ('0') to be in
accordance with this version of the specification.
<tail-octet> is omitted if the notail bit is set ('1'), otherwise it <head-length> if present is an 8 bit field, which contains the total
is an 8 bit field, where: length (in octets) of the head of all of the addresses.
bits 0-6: contain the length of the tail. The corresponding head-length is a variable, defined to equal <head-length> if
variable tail-length is calculated by: present, or 0 otherwise.
tail-length = <tail-octet> & 127 <head> is omitted if head-length == 0, otherwise it is a field of
the head-length leftmost octets of all the addresses.
bit 7 (zerotail): if cleared ('0'), then a <tail> is included. If <tail-length> if present is an 8 bit field, which contains the total
set ('1') then no <tail> is included, and the tail-length length (in octets) of the tail of all of the addresses.
rightmost octets of each address in the block are zero-valued.
If the <tail-octet> is omitted then tail-length = 0. tail-length is a variable, defined to equal <tail-length> if
present, or 0 otherwise.
<tail> is omitted if tail-length == 0 or the zerotail bit is set <tail> is omitted if tail-length == 0 or if the zerotail bit is set
('1'), otherwise it is a field of the head-length leftmost octets ('1'), otherwise it is a field of the tail-length rightmost octets
of all the addresses. of all the addresses. If the zerotail bit is set ('1') then the
tail-length rightmost octets of all the addresses are all 0.
mid-length is a variable, which MUST be non-negative, calculated by: mid-length is a variable, which MUST be non-negative, defined by:
mid-length = address-length - head-length - tail-length * mid-length = address-length - head-length - tail-length
<mid> is omitted if mid-length == 0, otherwise each <mid> is a field <mid> is omitted if mid-length == 0, otherwise each <mid> is a field
of length mid-length octets, representing the mid of the of length mid-length octets, representing the mid of the
corresponding address in the address block. corresponding address in the address block.
5.3. TLVs and TLV Blocks 5.3. TLVs and TLV Blocks
A TLV 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>s. octets) 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 29 skipping to change at page 13, line 33
<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. The <tlv-type> is an 8 bit field, specifying the type of the TLV,
two most significant bits have the following semantics: specific to the TLV kind (i.e. packet- message- or address block
TLV).
bit 7 (tlvuser): TLV types with this bit cleared ('0') are defined
in this specification or can be allocated via standards action.
TLV types with this bit set ('1') are reserved for private/
local use.
bit 6 (tlvprot): for TLV types with the tlv-user bit cleared
('0'), this bit specifies, if cleared ('0'), that the TLV type
is protocol independent, i.e. is not specific to any one
protocol, or, if set ('1'), that the TLV type is specific to
the protocol for which it is defined.
<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 1. Otherwise, they are interpreted according to Table 2.
+----------+---------+--------------+--------------+ +----------+---------+--------------+--------------+
| extended | novalue | length | value | | extended | novalue | <length> | <value> |
+----------+---------+--------------+--------------+ +----------+---------+--------------+--------------+
| 0 | 0 | 8 bits | included | | 0 | 0 | 8 bits | included |
| | | | | | | | | |
| 0 | 1 | not included | not included | | 0 | 1 | not included | not included |
| | | | | | | | | |
| 1 | 0 | 16 bits | included | | 1 | 0 | 16 bits | included |
+----------+---------+--------------+--------------+ +----------+---------+--------------+--------------+
Table 1 Table 2
bit 2 (noindex) and bit 3 (singleindex): must not both be set bit 2 (noindex) and bit 3 (singleindex): MUST NOT both be set
('1'). Otherwise, they are interpreted according to Table 2. ('1'). The former MUST be set ('1') and the latter MUST be
cleared ('0') for packet or message TLVs. They are interpreted
according to Table 3.
+---------+-------------+---------------+--------------+ +---------+-------------+---------------+--------------+
| noindex | singleindex | <index-start> | <index-stop> | | noindex | singleindex | <index-start> | <index-stop> |
+---------+-------------+---------------+--------------+ +---------+-------------+---------------+--------------+
| 0 | 0 | included | included | | 0 | 0 | included | included |
| | | | | | | | | |
| 0 | 1 | included | not included | | 0 | 1 | included | not included |
| | | | | | | | | |
| 1 | 0 | not included | not included | | 1 | 0 | not included | not included |
+---------+-------------+---------------+--------------+ +---------+-------------+---------------+--------------+
Table 2 Table 3
bit 4 (multivalue): this bit serves to specify how the value field bit 4 (multivalue): this bit serves to specify how the <value>
is interpreted as specified below. This bit MUST be cleared field is interpreted, as specified below. This bit MUST be
('0') for packet or message TLVs, if the singleindex bit is set cleared ('0') for packet or message TLVs, if the singleindex
('1'), or if the novalue bit is set ('1'). bit is set ('1'), or if the novalue bit is set ('1').
bits 5-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
accordance with this version of the specification. accordance with this version of the specification.
<index-start> and <index-stop> are each an 8 bit field, interpreted <index-start> and <index-stop> when present are each an 8 bit field,
as follows: interpreted as follows:
index-start and index-stop are variables, defined according to index-start and index-stop are variables, defined according to
Table 3. The variable end-index is calculated as follows: Table 4. The variable end-index is defined as follows:
+ For message and packet TLVs: + For message and packet TLVs:
- end-index = 0 - end-index = 0
+ For address block TLVs: + For address block TLVs:
- end-index = <num-addr> - 1 - end-index = <num-addr> - 1
+---------+-------------+---------------+---------------+ +---------+-------------+---------------+---------------+
| noindex | singleindex | index-start = | index-stop = | | noindex | singleindex | index-start = | index-stop = |
+---------+-------------+---------------+---------------+ +---------+-------------+---------------+---------------+
| 0 | 0 | <index-start> | <index-stop> | | 0 | 0 | <index-start> | <index-stop> |
| | | | | | | | | |
| 0 | 1 | <index-start> | <index-start> | | 0 | 1 | <index-start> | <index-start> |
| | | | | | | | | |
| 1 | 0 | 0 | end-index | | 1 | 0 | 0 | end-index |
+---------+-------------+---------------+---------------+ +---------+-------------+---------------+---------------+
Table 3 Table 4
For an address block TLV, the TLV applies to the addresses from For an address block TLV, the TLV applies to the addresses from
position index-start to position index-stop (inclusive) in the position index-start to position index-stop (inclusive) in the
address block. address block, where the first address has position zero.
number-values is a variable, calculated by: number-values is a variable, defined by:
number-values = index-stop - index-start + 1 + number-values = index-stop - index-start + 1
<length> is omitted or is a 8 or 16 bit field according to Table 1. <length> is omitted or is a 8 or 16 bit field according to Table 2.
If the multivalue bit is set ('1') then <length> MUST be an If present it MUST NOT be zero. If the multivalue bit is set
integral multiple of number-values, and the variable single-length ('1') then <length> MUST be an integral multiple of number-values,
is calculated by: and the variable single-length is defined by:
single-length = <length> / number-values * single-length = <length> / number-values
if the multivalue bit is cleared ('0'), the variable single-length If the multivalue bit is cleared ('0'), then the variable single-
is defined by: length is defined by:
single-length = <length> * single-length = <length>
<value> if present (see Table 1), this is a field of length <length> <value> if present (see Table 2) is a field of length <length>
octets. In an address block TLV, <value> is associated with the octets. In an address block TLV, <value> is associated with the
addresses from index-start to index-stop, inclusive. If the addresses from index-start to index-stop, inclusive. If the
multivalue bit is cleared ('0') then the whole of this field is multivalue bit is cleared ('0') then the whole of this field is
associated with each of the indicated addresses. If the associated with each of the indicated addresses. If the
multivalue bit is set ('1') then this field is divided equally multivalue bit is set ('1') then this field is divided equally
into number-values fields, each of length single-length octets and into number-values fields, each of length single-length octets and
these are associated, in order, with the indicated addresses. these are associated, in order, with the indicated addresses.
5.3.2. Constraints 5.3.2. Constraints
TLVs in the same tlv block MUST be sorted in ascending TLV type TLVs in the same TLV block MUST be sorted in ascending TLV type
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 can 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 syntactical elements are an integer multiple of octets, hence All elements are an integer multiple of octets, hence padding can be
padding can be accomplished by inserting an integer number of <pad- accomplished by inserting an integer number of <pad-octet> elements
octets> after the syntactical element that is to be 32 bit aligned. after the element that is to be 32 bit aligned.
The number of <pad-octet>s required to achieve this 32 bit alignment The number of <pad-octet> elements required to achieve this 32 bit
is calculated as 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.
<pad-octet> is an 8 bit field with all bits cleared ('0'). <pad-octet> is an 8 bit field with all bits cleared ('0').
There is no need to indicate if padding is included, since a <pad- There is no need to indicate if padding is included, since a <pad-
octet> will always precede either a message or the end of the packet. octet> will always precede either a message or the end of the packet.
In the former case, the start of a message is indicated by the next In the former case, the start of a message is indicated by the next
non-zero octet parsed. non-zero octet parsed.
The padding after a message may be freely changed when a message is The padding after a message may be freely changed when a message is
forwarded without affecting the message. forwarded without affecting the message.
skipping to change at page 17, line 23 skipping to change at page 17, line 23
| Name | Type | Length | Value | | Name | Type | Length | Value |
+----------------------+------+--------+----------------------------+ +----------------------+------+--------+----------------------------+
| PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address |
| | | | is a network address, | | | | | is a network address, |
| | | | rather than a host | | | | | rather than a host |
| | | | address. The value is the | | | | | address. The value is the |
| | | | length of the | | | | | length of the |
| | | | prefix/netmask. | | | | | prefix/netmask. |
+----------------------+------+--------+----------------------------+ +----------------------+------+--------+----------------------------+
Table 4 Table 5
An address in an address block without an associated PREFIX_LENGTH An address in an address block without an associated PREFIX_LENGTH
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). 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 5. Future values in the range assignments as specified in Table 6. Future values in the range
5-127 of the Message Type can be allocated using standards action 5-127 can be allocated using standards action [3]. Additionally,
[3]. Additionally, values in the range 128-255 are reserved for values in the range 128-255 are reserved for private/local use.
private/local use.
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 of the Message Type assignments. Future values in the range 0-127 can be allocated using
can be allocated using standards action [3]. Additionally, values in standards action [3]. Additionally, values in the range 128-255 are
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 of the Message Type assignments. Future values in the range 0-127 can be allocated using
can be allocated using standards action [3]. Additionally, values in standards action [3]. Additionally, values in the range 128-255 are
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 6. Future values in the initial assignments as specified in Table 7. Future values in the
range 1-127 of the Message Type can be allocated using standards range 1-127 can be allocated using standards action [3].
action [3]. Additionally, values in the range 128-255 are reserved Additionally, values in the range 128-255 are reserved for private/
for private/local use. local use.
+-------+----------------------------------------+ +-------+----------------------------------------+
| Value | Description | | Value | Description |
+-------+----------------------------------------+ +-------+----------------------------------------+
| 0 | MUST NOT be allocated. | | 0 | MUST NOT be allocated. |
| | | | | |
| 1-4 | RESERVED | | 1-4 | RESERVED |
+-------+----------------------------------------+ +-------+----------------------------------------+
Table 5 Table 6
Message type 0 MUST NOT be allocated because a zero-octet signifies a 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 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 to 4 are reserved because they are used by OLSR [4], which uses a
compatible packet/message header format. 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 6 Table 7
8. Security Considerations 8. Security Considerations
Packets are designed to be transmitted only one hop, and not Messages are designed to be carriers of protocol information and MAY,
forwarded. Hop-by-hop packet level security MAY be implemented, at each hop, be forwarded and/or processed according to the
between nodes with an existing security association, by including a information in the message header by the protocol using this
suitable packet TLV containing a cryptographic signature to the specification. If forwarded messages are unchanged by this protocol,
packet. Since packets are received as transmitted, signatures can be then end-to-end security MAY be implemented, between nodes with an
calculated based on the entire packet content, or on parts thereof as existing security association, by including a suitable message TLV
appropriate. containing a cryptographic signature to the message. Since <hop-
count> and <hop-limit> are the only fields that may be modified when
such a message is forwarded, 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.
Messages at each hop MAY be forwarded and/or processed, according to Packets are designed to carry a number of messages between
the information in the message header and the protocol employing this neighboring nodes in a single transmission and over a single logical
specification. With immutable messages, end-to-end security MAY be hop. Hop-by-hop packet level security MAY be implemented, between
implemented, between nodes with an existing security association, by nodes with an existing security association, by including a suitable
including a suitable message TLV containing a cryptographic signature packet TLV containing a cryptographic signature to the packet. Since
to the message. Since <hop-count> and <hop-limit> are the only packets are received as transmitted, this signature can be calculated
fields that may be modified when such a message is forwarded, based on the entire packet, or on parts thereof as appropriate.
signatures can be calculated based on the entire message, including
the message header with the <hop-count> and <hop-limit> fields set to
zero ('0').
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, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
skipping to change at page 26, line 10 skipping to change at page 26, line 10
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix A.4. Address Block Appendix A.4. Address Block
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0| Head Length | Head | | Number Addrs | Resv |0|0|0| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1| Head Length | Head | | Number Addrs | Resv |0|0|1| Tail Length | Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Tail Length | Tail | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Tail (cont) | Mid | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1| Head Length | Head | | Number Addrs | Resv |0|1|0| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Tail Length | Mid | | | Head (cont) | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs | Resv |0|1|1| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs | Resv |1|0|0| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs | Resv |1|0|1| Tail Length | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
: ... :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix A.5. TLV Block Appendix A.5. TLV Block
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| TLV | | TLV |
skipping to change at page 27, line 43 skipping to change at page 29, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |M|0|0|0|0| Index Start | Index Stop | | Type |Resv |M|0|0|0|0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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|0|0|0|1| Index Start | Index Stop | | Type |Resv |M|0|0|0|1| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |M|0|0|1|0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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|0|0|1|0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |M|0|1|0|0| Length | | | Type |Resv |M|0|1|0|0| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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|0|1|0|1| | Type |Resv |M|0|1|0|1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |M|0|1|1|0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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|0|1|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |0|1|0|0|0| Index Start | Length | | Type |Resv |0|1|0|0|0| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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|0|1| Index Start | | Type |Resv |0|1|0|0|1| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |0|1|0|1|0| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | | | Length (cont) | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |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, with a packet sequence number but
no packet TLV block, and contains a single unfragmented message. The no packet TLV block, and contains a single message. The message has
message has a complete message header, a message TLV block of content a complete message header, a message TLV block of content length 9
length 9 octets containing a single TLV (with the noindex bit of its octets containing a single TLV (with the noindex bit of its semantics
semantics set and value length 6 octets) and then two address blocks octet set and value length 6 octets) and then two address blocks each
each with a following TLV block. The first address block contains 3 with a following TLV block. The first address block contains 3
addresses (head length 2 octets, no tail, hence mid length two addresses, has the notail bit of the its semantics octet set, and has
octets) and is followed by a TLV block of content length 9 octets head length 2 octets, hence mid length two octets. It is followed by
containing two TLVs. The first of these TLVs has the noindex bit of a TLV block with content length 9 octets containing two TLVs. The
its semantics set and has a single value of length 2 octets, which first of these TLVs has the noindex bit of its semantics octet set
applies to all of the addresses in the preceding address block. The and has a single value of length 2 octets, which applies to all of
second of these TLVs has the novalue bit of its semantics set and the addresses in the preceding address block. The second of these
hence has no length or value fields (it does have index fields, which TLVs has the novalue bit of its semantics octet set and hence has no
indicate those addresses this TLV applies to). The second address length or value fields (it does have index fields, which indicate
block contains 2 addresses (head length 0 octets, hence no head those addresses this TLV applies to). The second address block
octets, tail length 2 octets, zero-valued tail not included, hence contains 2 addresses, has the nohead and zerotail bits of its
mid length two octets) and is followed by a TLV block of content semantics octet set, and has tail length 2 octets, hence mid length
length 5 octets. This TLV block contains a single TLV of type two octets. The two tail octets of each address are zero. It is
PREFIX_LENGTH that has the multivalue and noindex bits of its followed by a TLV block of content length 5 octets. This TLV block
semantics set and a value field length of 2 octets, indicating two contains a single TLV of type PREFIX_LENGTH that has the multivalue
values each of one octet length. There are two final padding octets and noindex bits of its semantics octet set and a value field length
that are not included in the message length of 62 octets. of 2 octets, indicating two values each of one octet length. There
is one final padding octet 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| Reserved |0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0| | Message Type | Resv |N|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 |Resv |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| Head | Mid | |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | | Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value | | TLV Type |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type |Resv |0|0|0|0|1| Index Start | Index Stop | | Value (cont) | TLV Type |Resv |0|0|0|1|0| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid | | 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 (cont) | Mid |0 0 0 0 0 0 0 0| | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value0 | Value1 |0 0 0 0 0 0 0 0|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.
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
skipping to change at page 33, line 9 skipping to change at page 34, line 9
o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp> o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@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, <monden@sdl.hitachi.co.jp> o Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp>
Appendix D. Acknowledgements Appendix D. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSRv1, as
specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent specified in RFC 3626, including Anis Laouiti, Pascale Minet, Laurent
Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Research in Engineering, Pakistan) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas
Schjonhaug (LIX), Florent Brunneau (LIX), and the entire IETF MANET Schjonhaug (LIX), Florent Brunneau (LIX), Yasunori Owada (Niigata
working group. University) and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
skipping to change at page 35, line 5 skipping to change at page 36, line 5
Email: jdean@itd.nrl.navy.mil Email: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/ URI: http://pf.itd.nrl.navy.mil/
Cedric Adjih Cedric Adjih
INRIA Rocquencourt INRIA Rocquencourt
Phone: +33 1 3963 5215 Phone: +33 1 3963 5215
Email: Cedric.Adjih@inria.fr Email: Cedric.Adjih@inria.fr
URI: http://menetou.inria.fr/~adjih/ URI: http://menetou.inria.fr/~adjih/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 35, line 29 skipping to change at page 36, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 97 change blocks. 
256 lines changed or deleted 297 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/