draft-ietf-manet-packetbb-14.txt   draft-ietf-manet-packetbb-15.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: February 2, 2009 BAE Systems Advanced Technology Expires: March 20, 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
August 1, 2008 September 16, 2008
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-14 draft-ietf-manet-packetbb-15
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 February 2, 2009. This Internet-Draft will expire on March 20, 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.1. Elements . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Variables . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11
5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 13 5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . 18
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. Packet TLV Type Extension Registry Creation . . . . . 22 6.3.1. Packet TLV Type Extension Registry Creation . . . . . 22
6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . 23
6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 23 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 . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Authentication and Integrity Suggestions . . . . . . . . . 24 7.1. Authentication and Integrity Suggestions . . . . . . . . . 24
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25 7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 26 Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 26
Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33 Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 33
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33 D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 33
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 37
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 42 D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 43
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 43 D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 44
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 50 D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 51
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 56 Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 57
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 58
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 59
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 for
carrying multiple messages for information exchange between MANET carrying multiple routing protocol messages for information exchange
(Mobile Ad hoc NETwork) routers. Messages consist of a message between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a
header, which is designed for control of message dissemination, and a message header, which is designed for control of message
message body, which contains protocol information. Only the syntax dissemination, and a message body, which contains protocol
of the packet and messages is specified. information. Only the syntax of the packet and messages is
specified.
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 4, line 37 skipping to change at page 4, line 42
[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
The following notations, for elements and variables, are used in this The following notations, for elements and variables, are used in this
document. document.
This format uses network byte order (most significant octet first)
for all fields. The most significant bit in an octet is numbered bit
0, and the least significant bit of an octet is numbered bit 7
[Stevens].
2.1.1. Elements 2.1.1. Elements
This specification defines elements. An element is a group of any This specification defines elements. An element is a group of any
number of consecutive bits which together form a syntactic entity number of consecutive bits which together form a syntactic entity
represented using the notation <element>. Each element in this represented using the notation <element>. Each element in this
document is defined as either: document is defined as either:
o A specifically sized field of bits; OR o A specifically sized field of bits; OR
o A composite element, composed of other <element>s. o A composite element, composed of other <element>s.
skipping to change at page 7, line 39 skipping to change at page 7, line 50
protocol. protocol.
5. Syntactical Specification 5. Syntactical Specification
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
composed. The specification is given using the notation in composed. The specification is given using the notation in
Section 2.1. Illustrations of specified elements are given in Section 2.1. Illustrations of specified elements are given in
Appendix D. Appendix D.
This format uses network byte order (most significant octet first) This format uses network byte order, as indicated in Section 2.1.
for all fields. The most significant bit in an octet is numbered bit
0, and the least significant bit of an octet is numbered bit 7
[Stevens].
5.1. Packets 5.1. Packets
<packet> is defined by: <packet> is defined by:
<packet> := <pkt-header> <packet> := <pkt-header>
<message>* <message>*
where <message> is as defined in Section 5.2. Successful parsing is where <message> is as defined in Section 5.2. Successful parsing is
terminated when all octets of the packet (as defined by the datagram terminated when all octets of the packet (as defined by the datagram
skipping to change at page 8, line 47 skipping to change at page 9, line 12
bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission, bit 3: Is RESERVED, and SHOULD be cleared ('0') on transmission,
and SHOULD be ignored on reception. and SHOULD be ignored on reception.
<pkt-seq-num> is omitted if the phasseqnum pkt-flag is cleared <pkt-seq-num> is omitted if the phasseqnum pkt-flag is cleared
('0'), otherwise is a 16 bit unsigned integer field, specifying a ('0'), otherwise is a 16 bit unsigned integer field, specifying a
packet sequence number. packet sequence number.
<tlv-block> is omitted if the phastlv flag is cleared ('0'), and is <tlv-block> is omitted if the phastlv flag is cleared ('0'), and is
otherwise as defined in Section 5.4. otherwise as defined in Section 5.4.
It is assumed that the network layer is able to deliver the exact
payload length, thus avoiding having to carry the packet length in
the packet.
5.2. Messages 5.2. Messages
Packets may, in addition to the packet header, contain one or more Packets may, in addition to the packet header, contain one or more
messages. Messages contain: messages. Messages contain:
o A message header. o A message header.
o A message TLV block that contains zero or more TLVs, associated o A message TLV block that contains zero or more TLVs, associated
with the whole message. with the whole message.
skipping to change at page 12, line 38 skipping to change at page 13, line 4
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
| ahassingle | ahasmulti | number of | prefix length of the | | ahassingle | ahasmulti | number of | prefix length of the |
| prelen | prelen | <prefix-length> | nth address prefix, | | prelen | prelen | <prefix-length> | nth address prefix, |
| | | fields | in bits | | | | fields | in bits |
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
| 0 | 0 | 0 | 8 * address-length | | 0 | 0 | 0 | 8 * address-length |
| 1 | 0 | 1 | <prefix-length> | | 1 | 0 | 1 | <prefix-length> |
| 0 | 1 | <num-addr> | nth <prefix-length> | | 0 | 1 | <num-addr> | nth <prefix-length> |
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen Table 2: Interpretation of the ahassingleprelen and ahasmultiprelen
addr-flags addr-flags
<head-length> if present is an 8 bit unsigned integer field, which <head-length> if present is an 8 bit unsigned integer field, which
contains the number of octets in the head of all of the addresses contains the number of octets in the head of all of the addresses
in the address block. in the address block, i.e. each <head> element included is <head-
length> octets long.
head-length is a variable, defined to equal <head-length> if head-length is a variable, defined to equal <head-length> if
present, or 0 otherwise. present, or 0 otherwise.
<head> is omitted if head-length is equal to 0, otherwise it is a <head> is omitted if head-length is equal to 0, otherwise it is a
field of the head-length leftmost octets common to all the field of the head-length leftmost octets common to all the
addresses in the address block. addresses in the address block.
<tail-length> if present is an 8 bit unsigned integer field, which <tail-length> if present is an 8 bit unsigned integer field, which
contains the number of octets in the tail of all of the addresses contains the number of octets in the tail of all of the addresses
in the address block. in the address block, i.e. each <tail> element included is <tail-
length> octets long.
tail-length is a variable, defined to equal <tail-length> if tail-length is a variable, defined to equal <tail-length> if
present, or 0 otherwise. present, or 0 otherwise.
<tail> is omitted if tail-length is equal to 0, or if the <tail> is omitted if tail-length is equal to 0, or if the
ahaszerotail bit is set ('1'), otherwise it is a field of the ahaszerotail bit is set ('1'), otherwise it is a field of the
tail-length rightmost octets common to all the addresses in the tail-length rightmost octets common to all the addresses in the
address block. If the ahaszerotail bit is set ('1') then the address block. If the ahaszerotail bit is set ('1') then the
tail-length rightmost octets of all the addresses in the address tail-length rightmost octets of all the addresses in the address
block are all 0. block are all 0.
mid-length is a variable, which MUST be non-negative, defined 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
i.e. each <mid> element included is mid-length octets long.
<mid> is omitted if mid-length is equal to 0, otherwise each <mid> <mid> is omitted if mid-length is equal to 0, otherwise each <mid>
is a field of length mid-length octets, representing the mid of is a field of length mid-length octets, representing the mid of
the corresponding address in the address block. When not omitted, the corresponding address in the address block. When not omitted,
an address block contains exactly <num-addr> <mid> fields. an address block contains exactly <num-addr> <mid> fields.
<prefix-length> is an 8 bit unsigned integer field containing the <prefix-length> is an 8 bit unsigned integer field containing the
length, in bits, of an address prefix. If the ahassingleprelen length, in bits, of an address prefix. If the ahassingleprelen
addr-flag is set ('1') then a single <prefix-length> field is addr-flag is set ('1') then a single <prefix-length> field is
included, which contains the prefix length of all addresses in the included, which contains the prefix length of all addresses in the
skipping to change at page 16, line 25 skipping to change at page 16, line 40
<tlv-type-ext> is an 8 bit unsigned integer field, specifying an <tlv-type-ext> is an 8 bit unsigned integer field, specifying an
extension of the TLV type, specific to the TLV type and kind (i.e. extension of the TLV type, specific to the TLV type and kind (i.e.
packet, message, or address block TLV). packet, message, or address block TLV).
tlv-type-ext is a variable, defined to equal <tlv-type-ext> if tlv-type-ext is a variable, defined to equal <tlv-type-ext> if
present, or 0 otherwise. present, or 0 otherwise.
tlv-fulltype is a variable, defined by: tlv-fulltype is a variable, defined by:
* tlv-fulltype := 256 * <tlv-type> + tlv-type-ext tlv-fulltype := 256 * <tlv-type> + tlv-type-ext
<index-start> and <index-stop> when present, in an address block TLV <index-start> and <index-stop> when present, in an address block TLV
only, are each an 8 bit unsigned integer field. only, are each an 8 bit unsigned integer field.
index-start and index-stop are variables, defined according to index-start and index-stop are variables, defined according to
Table 5. The variable end-index is defined as follows: Table 5. 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
An address block TLV applies to the address objects from position An address block TLV applies to the address objects from position
index-start to position index-stop (inclusive) in the address index-start to position index-stop (inclusive) in the address
block, where the first address object has position zero. block, where the first address object has position zero.
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| thassingleindex | thasmultiindex | index-start := | index-stop := | | thassingleindex | thasmultiindex | index-start := | index-stop := |
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
| 0 | 0 | 0 | end-index | | 0 | 0 | 0 | end-index |
| 1 | 0 | <index-start> | <index-start> | | 1 | 0 | <index-start> | <index-start> |
| 0 | 1 | <index-start> | <index-stop> | | 0 | 1 | <index-start> | <index-stop> |
+-----------------+----------------+----------------+---------------+ +-----------------+----------------+----------------+---------------+
Table 5: Interpretation of the thassingleindex and thasmultiindex Table 5: Interpretation of the thassingleindex and thasmultiindex
tlv-flags tlv-flags
number-values is a variable, defined 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 an 8 or 16 bit unsigned integer field <length> is omitted or is an 8 or 16 bit unsigned integer field
according to Table 4. If the tismultivalue tlv-flag is set ('1') according to Table 4. If the tismultivalue tlv-flag is set ('1')
then <length> MUST be an integral multiple of number-values, and then <length> MUST be an integral multiple of number-values, and
the variable single-length is defined by: the variable single-length is defined by:
* single-length := <length> / number-values single-length := <length> / number-values
If the tismultivalue tlv-flag is cleared ('0'), then the variable If the tismultivalue tlv-flag is cleared ('0'), then the variable
single-length is defined by: single-length is defined by:
* single-length := <length> single-length := <length>
<value> if present (see Table 4) is a field of length <length> <value> if present (see Table 4) 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
address objects from positions index-start to index-stop, address objects from positions index-start to index-stop,
inclusive. If the tismultivalue tlv-flag is cleared ('0') then inclusive. If the tismultivalue tlv-flag is cleared ('0') then
the whole of this field is associated with each of the indicated the whole of this field is associated with each of the indicated
address objects. If the tismultivalue tlv-flag is set ('1') then address objects. If the tismultivalue tlv-flag is set ('1') then
this field is divided equally into number-values fields, each of this field is divided equally into number-values fields, each of
length single-length octets, and these are associated, in order, length single-length octets, and these are associated, in order,
with the indicated address objects. with the indicated address objects.
skipping to change at page 19, line 33 skipping to change at page 19, line 44
o The intention is that all registrations will be accompanied by a o The intention is that all registrations will be accompanied by a
published RFC. published RFC.
o In order to allow for registration prior to the RFC being approved o In order to allow for registration prior to the RFC being approved
for publication, the Designated Expert can approve the for publication, the Designated Expert can approve the
registration once it seems clear that an RFC is expected to be registration once it seems clear that an RFC is expected to be
published. published.
o The Designated Expert will post a request to the MANET WG mailing o The Designated Expert will post a request to the MANET WG mailing
list, or to a successor hereto as designated by the Area Director, list, or to a successor thereto as designated by the Area
for comments and reviews. This request will include a reference Director, for comments and reviews. This request will include a
to the Internet-Draft requesting the registration. reference to the Internet-Draft requesting the registration.
o Before a period of 30 days has passed, the Designated Expert will o Before a period of 30 days has passed, the Designated Expert will
either approve or deny the registration request and publish a note either approve or deny the registration request and publish a note
of the decision to the MANET WG mailing list or its successor, as of the decision to the MANET WG mailing list or its successor, as
well as informing IANA and the IESG. A denial note MUST be well as informing IANA and the IESG. A denial note MUST be
justified by an explanation and, in cases where it is possible, justified by an explanation and, in cases where it is possible,
suggestions as to how the request can be modified so as to become suggestions as to how the request can be modified so as to become
acceptable SHOULD be provided. acceptable SHOULD be provided.
For the registry for Message Types, the following guidelines apply: For the registry for Message Types, the following guidelines apply:
skipping to change at page 20, line 41 skipping to change at page 21, line 4
For the registries for Message TLV Types and Address Block TLV Types, For the registries for Message TLV Types and Address Block TLV Types,
the following additional guidelines apply: the following additional guidelines apply:
o TLV type values 0-127 are common for all message types. TLVs o TLV type values 0-127 are common for all message types. TLVs
which receive registrations from the 0-127 interval SHOULD be which receive registrations from the 0-127 interval SHOULD be
modular in design to allow reuse among protocols. modular in design to allow reuse among protocols.
o TLV type values 128-223 are message type specific TLV type values, o TLV type values 128-223 are message type specific TLV type values,
relevant only in the context of the containing message type. relevant only in the context of the containing message type.
Registration of TLV type values within the 128-223 interval Registration of TLV type values within the 128-223 interval
require that a registry in the 128-223 interval exists for a requires that a registry in the 128-223 interval exists for a
specific message type value (see Section 6.2.1), and registrations specific message type value (see Section 6.2.1), and registrations
are made in accordance with the allocation policies specified for are made in accordance with the allocation policies specified for
these message type specific registries. Message type specific TLV these message type specific registries. Message type specific TLV
types SHOULD be registered for TLVs which the Designated Expert types SHOULD be registered for TLVs which the Designated Expert
deems too message type specific for registration of a 0-127 value. deems too message type specific for registration of a 0-127 value.
Multiple different TLV definitions MAY be assigned the same TLV Multiple different TLV definitions MAY be assigned the same TLV
type value within the 128-223 interval, given that they are type value within the 128-223 interval, given that they are
associated with different message type specific TLV type associated with different message type specific TLV type
registries. Where possible, existing global TLV definitions and registries. Where possible, existing global TLV definitions and
modular global TLV definitions for registration in the 0-127 range modular global TLV definitions for registration in the 0-127 range
skipping to change at page 28, line 5 skipping to change at page 28, line 26
the identifier consisting of the message's <msg-orig-addr>, <msg- the identifier consisting of the message's <msg-orig-addr>, <msg-
seq-num>, and <msg-type>. These serve to uniquely identify the seq-num>, and <msg-type>. These serve to uniquely identify the
message in the MANET within the time period until <msg-seq-num> is message in the MANET within the time period until <msg-seq-num> is
repeated, i.e. wraps around to a matching value. repeated, i.e. wraps around to a matching value.
o <msg-hop-limit> field, if present, contains the number of hops on o <msg-hop-limit> field, if present, contains the number of hops on
which the packet is allowed to travel before being discarded by a which the packet is allowed to travel before being discarded by a
MANET router. The <msg-hop-limit> is set by the message MANET router. The <msg-hop-limit> is set by the message
originator and is used to prevent messages from endlessly originator and is used to prevent messages from endlessly
circulating in a MANET. When forwarding a message, a MANET router circulating in a MANET. When forwarding a message, a MANET router
SHOULD decrease the <msg-hop-limit> by 1, and the message SHOULD should decrease the <msg-hop-limit> by 1, and the message should
be discarded when <msg-hop-limit> reaches 0. be discarded when <msg-hop-limit> reaches 0.
o <msg-hop-count> field, if present, contains the number of hops on o <msg-hop-count> field, if present, contains the number of hops on
which the packet has traveled across the MANET. The <msg-hop- which the packet has traveled across the MANET. The <msg-hop-
count< is set to 0 by the message originator and is used to count< is set to 0 by the message originator and is used to
prevent messages from endlessly circulating in a MANET. When prevent messages from endlessly circulating in a MANET. When
forwarding a message, a MANET router SHOULD increase <msg-hop- forwarding a message, a MANET router should increase <msg-hop-
count> by 1 and SHOULD discarded the message when <msg-hop-count> count> by 1 and should discard the message when <msg-hop-count>
reaches 255. reaches 255.
o If the <msg-hop-limit> and <msg-hop-limit> fields are both o If the <msg-hop-limit> and <msg-hop-limit> fields are both
present, then the message header provides the information to make present, then the message header provides the information to make
forwarding decisions for scope limited flooding. This may be by forwarding decisions for scope limited flooding. This may be by
any appropriate flooding mechanism specified by a protocol using any appropriate flooding mechanism specified by a protocol using
this specification. this specification.
Appendix C. Examples Appendix C. Examples
skipping to change at page 58, line 22 skipping to change at page 59, line 22
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,
<kazuya.monden.vw@sdl.hitachi.co.jp> <kazuya.monden.vw@sdl.hitachi.co.jp>
Appendix G. Acknowledgments Appendix G. Acknowledgments
The authors would like to acknowledge the team behind OLSR [RFC3626], The authors would like to acknowledge the team behind OLSR [RFC3626],
including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
(both at INRIA, France), and Amir Qayyum (Center for Advanced (both at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Research in Engineering, Pakistan) for their contributions. Elwyn
Davis (Folly Consulting, UK), Lars Eggert (Nokia, Finland), Chris
Newman (Sun Microsystems, USA), Tim Polk (NIST, USA), and Magnus
Westerlund (Ericsson, Sweden) all provided detailed reviews and
insightful comments.
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 (listed alphabetically): specification and its components (listed alphabetically):
o Brian Adamson (NRL) o Brian Adamson (NRL)
o Teco Boot (Infinity Networks) o Teco Boot (Infinity Networks)
o Florent Brunneau (LIX) o Florent Brunneau (LIX)
 End of changes. 33 change blocks. 
53 lines changed or deleted 67 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/