draft-ietf-manet-packetbb-17.txt   rfc5444.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Request for Comments: 5444 LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Category: Standards Track C. Dearlove
Expires: May 22, 2009 BAE Systems Advanced Technology BAE Systems ATC
Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
November 18, 2008 February 2009
Generalized MANET Packet/Message Format Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format
draft-ietf-manet-packetbb-17
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This document specifies an Internet standards track protocol for the
applicable patent or other IPR claims of which he or she is aware Internet community, and requests discussion and suggestions for
have been or will be disclosed, and any of which he or she becomes improvements. Please refer to the current edition of the "Internet
aware will be disclosed, in accordance with Section 6 of BCP 79. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on May 22, 2009. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Packets ....................................................8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Messages ...................................................9
5.3. Address Blocks . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Address Blocks ............................................11
5.4. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 5.4. TLVs and TLV Blocks .......................................14
5.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. TLVs ...............................................14
5.4.2. TLV Usage . . . . . . . . . . . . . . . . . . . . . . 17 5.4.2. TLV Usage ..........................................17
5.5. Malformed Elements . . . . . . . . . . . . . . . . . . . . 18 5.5. Malformed Elements ........................................18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations ............................................18
6.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 18 6.1. Expert Review: Evaluation Guidelines ......................18
6.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Message Types .............................................20
6.2.1. Message Type Specific TLV Registry Creation . . . . . 20 6.2.1. Message-Type-Specific TLV Registry Creation ........20
6.3. Packet TLV Types . . . . . . . . . . . . . . . . . . . . . 20 6.3. Packet TLV Types ..........................................21
6.3.1. Packet TLV Type Extension Registry Creation . . . . . 21 6.3.1. Packet TLV Type Extension Registry Creation ........21
6.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 21 6.4. Message TLV Types .........................................21
6.4.1. Message TLV Type Extension Registry Creation . . . . . 22 6.4.1. Message TLV Type Extension Registry Creation .......22
6.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 22 6.5. Address Block TLV Types ...................................22
6.5.1. Address Block TLV Type Extension Registry Creation . . 23 6.5.1. Address Block TLV Type Extension Registry
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 Creation ...........................................23
7.1. Authentication and Integrity Suggestions . . . . . . . . . 23 7. Security Considerations ........................................23
7.2. Confidentiality Suggestions . . . . . . . . . . . . . . . 24 7.1. Authentication and Integrity Suggestions ..................23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Confidentiality Suggestions ...............................24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8. Contributors ...................................................25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments ................................................25
Appendix A. Multiplexing and Demultiplexing . . . . . . . . . . . 25 10. References ....................................................26
Appendix B. Intended Usage . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References .....................................26
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References ...................................27
C.1. Address Block Examples . . . . . . . . . . . . . . . . . . 27 Appendix A. Multiplexing and Demultiplexing .......................28
C.2. TLV Examples . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Intended Usage ........................................28
Appendix D. Illustrations . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Examples ..............................................30
D.1. Packet . . . . . . . . . . . . . . . . . . . . . . . . . . 32 C.1. Address Block Examples ....................................30
D.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 35 C.2. TLV Examples ..............................................32
D.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix D. Illustrations .........................................34
D.4. Address Block . . . . . . . . . . . . . . . . . . . . . . 42 D.1. Packet ....................................................34
D.5. TLV Block . . . . . . . . . . . . . . . . . . . . . . . . 49 D.2. Message ...................................................38
D.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 D.3. Message Body ..............................................44
Appendix E. Complete Example . . . . . . . . . . . . . . . . . . 55 D.4. Address Block .............................................45
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 57 D.5. TLV Block .................................................52
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . . 58 D.6. TLV .......................................................53
Appendix E. Complete Example ......................................57
1. Introduction 1. Introduction
This document specifies the syntax of a packet format designed for This document specifies the syntax of a packet format designed for
carrying multiple routing protocol messages for information exchange carrying multiple routing protocol messages for information exchange
between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a between MANET (Mobile Ad hoc NETwork) routers. Messages consist of a
message header, which is designed for control of message Message Header, which is designed for control of message
dissemination, and a message body, which contains protocol dissemination, and a Message Body, which contains protocol
information. Only the syntax of the packet and messages is information. Only the syntax of the packet and messages is
specified. 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.
o A message header format, which contains information which may be o A Message Header format, which contains information that may be
sufficient to allow a protocol using this specification to make sufficient to allow a protocol using this specification to make
processing and forwarding decisions. processing and forwarding decisions.
o A message body format, containing attributes associated with the o A Message Body format, containing attributes associated with the
message or the originator of the message, as well as blocks of message or the originator of the message, as well as blocks of
addresses, or address prefixes, with associated attributes. addresses, or address prefixes, with associated attributes.
o An address block format, where an address block represents sets of o An Address Block format, where an Address Block represents sets of
addresses, or address prefixes, in a compact form with aggregated addresses, or address prefixes, in a compact form with aggregated
addresses. addresses.
o A generalized type-length-value (TLV) format representing o A generalized type-length-value (TLV) format representing
attributes. Each TLV can be associated with a packet, a message, attributes. Each TLV can be associated with a packet, a message,
or one or more addresses or address prefixes in a single address or one or more addresses or address prefixes in a single Address
block. Multiple TLVs can be included and each associated with a Block. Multiple TLVs can be included, each associated with a
packet, a message, and with the same, different or overlapping packet, a message, and the same, different, or overlapping sets of
sets of addresses or address prefixes. addresses or address prefixes.
The specification has been explicitly designed with the following The specification has been explicitly designed with the following
properties, listed in no particular order, in mind: properties, listed in no particular order, in mind:
Parsing logic - The notation used in this specification facilitates Parsing logic - The notation used in this specification facilitates
generic, protocol independent, parsing logic. generic, protocol-independent parsing logic.
Extensibility - Packets and messages defined by a protocol using Extensibility - Packets and messages defined by a protocol using
this specification are extensible by defining new message types this specification are extensible by defining new messages and new
and new TLVs. Protocols using this specification will be able to TLVs. Protocols using this specification will be able to
correctly identify and skip such new message types and TLVs, while correctly identify and skip such new messages and TLVs, while
correctly parsing the remainder of the packet and message. correctly parsing the remainder of the packet and message.
Efficiency - When reported addresses share common bit sequences Efficiency - When reported addresses share common bit sequences
(e.g. address prefixes or IPv6 interface identifiers) the address (e.g., address prefixes or IPv6 interface identifiers), the
block representation allows for a compact representation. Compact Address Block representation allows for a compact representation.
message headers are ensured through permitting inclusion of only Compact Message Headers are ensured through permitting inclusion
required message header elements. The multi message packet of only required Message Header elements. The multi-message
structure allows a reduction in the number of transmitted octets packet structure allows a reduction in the number of transmitted
and in the number of transmitted packets. The structure of packet octets and in the number of transmitted packets. The structure of
and message encoding allows parsing, verifying, and identifying packet and message encoding allows parsing, verifying, and
individual elements in a single pass. identifying individual elements in a single pass.
Separation of forwarding and processing - A protocol using this Separation of forwarding and processing - A protocol using this
specification can be designed such that duplicate detection and specification can be designed such that duplicate detection and
controlled scope message forwarding decisions can be made using controlled-scope message forwarding decisions can be made using
information contained in the message header, without processing information contained in the Message Header, without processing
the message body. the Message Body.
2. Notation and Terminology 2. Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses the notation in Section 2.1, and the Additionally, this document uses the notation in Section 2.1 and the
terminology in Section 2.2. terminology in Section 2.2.
2.1. Notation 2.1. Notation
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) This format uses network byte order (most significant octet first)
for all fields. The most significant bit in an octet is numbered bit 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 0, and the least significant bit of an octet is numbered bit 7
[Stevens]. [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 that 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.
A composite element is defined as follows: A composite element is defined as follows:
<element> := specification <element> := specification
where, on the right hand side following :=, specification is where, on the right hand side following :=, specification is
represented using the regular expression syntax defined in represented using the regular expression syntax defined in
[SingleUNIX]. Only the following notation is used: [SingleUNIX]. Only the following notation is used:
<element1><element2> - Indicates that <element1> is immediately <element1><element2> - Indicates that <element1> is immediately
skipping to change at page 5, line 32 skipping to change at page 5, line 32
? - Zero or one occurrences of the preceding element or group. ? - Zero or one occurrences of the preceding element or group.
* - Zero or more occurrences of the preceding element or group. * - Zero or more occurrences of the preceding element or group.
2.1.2. Variables 2.1.2. Variables
Variables are introduced into the specification solely as a means to Variables are introduced into the specification solely as a means to
clarify the description. The following two notations are used: clarify the description. The following two notations are used:
<foo> - If <foo> is an unsigned integer field then <foo> is also <foo> - If <foo> is an unsigned integer field, then <foo> is also
used to represent the value of that field. used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the bar - A variable, usually obtained through calculations based on the
value(s) of element(s). value(s) of element(s).
2.2. Terminology 2.2. Terminology
This document uses the following terminology: This document uses the following terminology:
Packet - The top level entity in this specification. A packet Packet - The top level entity in this specification. A packet
contains a packet header and zero or more messages. contains a Packet Header and zero or more messages.
Message - The fundamental entity carrying protocol information, in Message - The fundamental entity carrying protocol information, in
the form of address objects and TLVs. the form of address objects and TLVs.
Address - A number of octets that make up an address of the length Address - A number of octets that make up an address of the length
indicated by the encapsulating message header. The meaning of an indicated by the encapsulating Message Header. The meaning of an
address is defined by the protocol using this specification. address is defined by the protocol using this specification.
Address Prefix - An address plus a prefix length, with the prefix Address Prefix - An address plus a prefix length, with the prefix
length being a number of address bits measured from the left/most length being a number of address bits measured from the left/most
significant end of the address. significant end of the address.
Address Object - Either an address, or an address prefix, as Address Object - Either an address, or an address prefix, as
specified in an address block in this specification. specified in an Address Block in this specification.
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.
3. Applicability Statement 3. Applicability Statement
This specification describes a generic packet format, designed for This specification describes a generic packet format, designed for
use by MANET routing protocols. The specification has been inspired use by MANET routing protocols. The specification has been inspired
by and extended from that used by OLSR (The Optimized Link State by and extended from that used by the OLSR (Optimized Link State
Routing protocol) [RFC3626]. Routing) protocol [RFC3626].
MANETs are, commonly though not exclusively, characterized as being MANETs are, commonly though not exclusively, characterized as being
able to run over wireless network interfaces of limited to moderate able to run over wireless network interfaces of limited to moderate
capacity. MANETs are therefore less tolerant of wasted transmitted capacity. MANETs are therefore less tolerant of wasted transmitted
octets than are most wired networks. This specification thus octets than are most wired networks. This specification thus
represents a tradeoff between sometimes competing attributes, represents a tradeoff between sometimes competing attributes,
specifically efficiency, extensibility, and ease of use. specifically efficiency, extensibility, and ease of use.
Efficiency is supported by reducing packet size and by allowing Efficiency is supported by reducing packet size and by allowing
multiple disjoint messages in a single packet. Reduced packet size multiple disjoint messages in a single packet. Reduced packet size
is primarily supported by address aggregation, optional packet and is primarily supported by address aggregation, optional Packet Header
message header fields, and optional fields in address blocks and and Message Header fields, and optional fields in Address Blocks and
TLVs. Supporting multi-message packets allows a reduction in the TLVs. Supporting multi-message packets allows a reduction in the
number of packets, each of which can incur significant bandwidth number of packets, each of which can incur significant bandwidth
costs from transport, network, and lower layers. costs from transport, network, and lower layers.
This specification provides both external and internal extensibility. This specification provides both external and internal extensibility.
External extensibility is supported by the ability to add packet TLVs External extensibility is supported by the ability to add Packet TLVs
and to define new message types. Internal extensibility is supported and to define new Message Types. Internal extensibility is supported
by the ability to add message TLVs and address block TLVs to existing by the ability to add Message TLVs and Address Block TLVs to existing
messages. Protocols can define new TLV types, and hence the contents messages. Protocols can define new TLV Types, and hence the contents
of their value fields (see Section 6.1), and new message types. of their Value fields, and new Message Types (see Section 6.1).
Protocols can also reuse message and TLV type definitions from other Protocols can also reuse TLV Type definitions from other protocols
protocols which also use this specification. that also use this specification.
This specification aims at being sufficiently expressive and flexible This specification aims at being sufficiently expressive and flexible
to be able to accommodate both different classes of MANET routing to be able to accommodate different classes of MANET routing
protocols (e.g. proactive, reactive and hybrid routing protocols), as protocols (e.g., proactive, reactive, and hybrid routing protocols)
well as extensions thereto. Having a common packet and message as well as extensions thereto. Having a common packet and message
format, and a common way of representing IP addresses and associated format, and a common way of representing IP addresses and associated
attributes, allows generic parsing code to be developed, regardless attributes, allows generic parsing code to be developed, regardless
of the algorithm used by the routing protocol. of the algorithm used by the routing protocol.
All addresses within a message are assumed to be of the same size, All addresses within a message are assumed to be of the same size,
specified in the message header. In the case of mixed IPv6 and IPv4 specified in the Message Header. In the case of mixed IPv6 and IPv4
addresses, IPv4 addresses can be represented as IPv4-mapped IPv6 addresses, IPv4 addresses can be represented as IPv4-mapped IPv6
addresses as specified in [RFC4291]. addresses as specified in [RFC4291].
The messages defined by this specification are designed to carry The messages defined by this specification are designed to carry
MANET routing protocol signaling between MANET routers. This MANET routing protocol signaling between MANET routers. This
specification includes elements which can support scope limited specification includes elements that can support scope-limited
flooding, as well as being usable for point to point delivery of flooding, as well as being usable for point-to-point delivery of
MANET routing protocol signaling in a multi-hop network. Packets may MANET routing protocol signaling in a multi-hop network. Packets may
be unicast or multicast, and may use any appropriate transport be unicast or multicast and may use any appropriate transport
protocol, or none. protocol or none.
A MANET routing protocol using the message format defined by this A MANET routing protocol using the message format defined by this
specification can constrain the syntax (for example requiring a specification can constrain the syntax (for example, requiring a
specific set of message header fields) that the protocol will employ. specific set of Message Header fields) that the protocol will employ.
Protocols with such restrictions need not be able to parse all Protocols with such restrictions need not be able to parse all
possible message structures as defined by this document but must be possible message structures as defined by this document but must be
coherent in message generation and reception of messages which they coherent in message generation and reception of messages that they
define. If a protocol specifies which elements are included, then define. If a protocol specifies which elements are included, then
direct indexing of the appropriate fields is possible, dependent on direct indexing of the appropriate fields is possible, dependent on
the syntax restrictions imposed by the protocol. Such protocols may the syntax restrictions imposed by the protocol. Such protocols may
have more limited extensibility. have more limited extensibility.
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
protocol. protocol.
5. Syntactical Specification 5. Syntactical Specification
This section normatively provides syntactical specification of a This section normatively provides the syntactical specification of a
packet, represented by the element <packet> and the elements from packet, represented by the element <packet> and the elements from
which it is composed. The specification is given using the notation which it is composed. The specification is given using the notation
in Section 2.1. in Section 2.1.
Graphical illustrations of the layout of specified elements are given Graphical illustrations of the layout of specified elements are given
in Appendix D, a graphical illustration of a complete example (a in Appendix D, a graphical illustration of a complete example (a
packet including a message with address blocks and TLVs) is given in packet including a message with Address Blocks and TLVs) is given in
Appendix E. Appendix E.
This format uses network byte order, as indicated in Section 2.1. This format uses network byte order, as indicated in Section 2.1.
5.1. Packets 5.1. Packets
<packet> is defined by: <packet> is defined by:
<packet> := <pkt-header> <packet> := <pkt-header>
<message>* <message>*
skipping to change at page 8, line 25 skipping to change at page 8, line 25
<pkt-header> is defined by: <pkt-header> is defined by:
<pkt-header> := <version> <pkt-header> := <version>
<pkt-flags> <pkt-flags>
<pkt-seq-num>? <pkt-seq-num>?
<tlv-block>? <tlv-block>?
where: where:
<version> is a 4 bit unsigned integer field and specifies the <version> is a 4-bit unsigned integer field and specifies the
version of the specification on which the packet and the contained version of the specification on which the packet and the contained
messages are constructed. This document specifies version 0. messages are constructed. This document specifies version 0.
<pkt-flags> is a 4 bit field, specifying the interpretation of the <pkt-flags> is a 4-bit field, specifying the interpretation of the
remainder of the packet header: remainder of the Packet Header:
bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not bit 0 (phasseqnum): If cleared ('0'), then <pkt-seq-num> is not
included in the <pkt-header>. If set ('1'), then <pkt-seq-num> included in the <pkt-header>. If set ('1'), then <pkt-seq-num>
is included in the <pkt-header>. is included in the <pkt-header>.
bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not bit 1 (phastlv): If cleared ('0'), then <tlv-block> is not
included in the <pkt-header>. If set ('1'), then <tlv-block> included in the <pkt-header>. If set ('1'), then <tlv-block>
is included in the <pkt-header>. is included in the <pkt-header>.
bits 2-3: Are RESERVED, and SHOULD each be cleared ('0') on bits 2-3: Are RESERVED and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission and SHOULD be ignored on reception.
<pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0'), <pkt-seq-num> is omitted if the phasseqnum flag is cleared ('0');
otherwise is a 16 bit unsigned integer field, specifying a packet otherwise, is a 16-bit unsigned integer field, specifying a Packet
sequence number. 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 It is assumed that the network layer is able to deliver the exact
payload length, thus avoiding having to carry the packet length in payload length, thus avoiding having to carry the packet length in
the packet. 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.
o Zero or more address blocks, each containing one or more address o Zero or more Address Blocks, each containing one or more address
objects. objects.
o An address TLV block, containing zero or more TLVs, following each o An Address Block TLV Block, containing zero or more TLVs and
address block, through which addresses can be associated with following each Address Block, through which addresses can be
additional attributes. associated with additional attributes.
<message> is defined by: <message> is defined by:
<message> := <msg-header> <message> := <msg-header>
<tlv-block> <tlv-block>
(<addr-block><tlv-block>)* (<addr-block><tlv-block>)*
<msg-header> := <msg-type> <msg-header> := <msg-type>
<msg-flags> <msg-flags>
<msg-addr-length> <msg-addr-length>
skipping to change at page 9, line 43 skipping to change at page 9, line 43
<msg-hop-limit>? <msg-hop-limit>?
<msg-hop-count>? <msg-hop-count>?
<msg-seq-num>? <msg-seq-num>?
where: where:
<tlv-block> is as defined in Section 5.4. <tlv-block> is as defined in Section 5.4.
<addr-block> is as defined in Section 5.3. <addr-block> is as defined in Section 5.3.
<msg-type> is an 8 bit unsigned integer field, specifying the type <msg-type> is an 8-bit unsigned integer field, specifying the type
of the message. of the message.
<msg-flags> is a 4 bit field, specifying the interpretation of the <msg-flags> is a 4-bit field, specifying the interpretation of the
remainder of the message header: remainder of the Message Header:
bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not bit 0 (mhasorig): If cleared ('0'), then <msg-orig-addr> is not
included in the <msg-header>. If set ('1'), then <msg-orig- included in the <msg-header>. If set ('1'), then <msg-orig-
addr> is included in the <msg-header>. addr> is included in the <msg-header>.
bit 1 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is bit 1 (mhashoplimit): If cleared ('0'), then <msg-hop-limit> is
not included in the <msg-header>. If set ('1'), then <msg-hop- not included in the <msg-header>. If set ('1'), then <msg-hop-
limit> is included in the <msg-header>. limit> is included in the <msg-header>.
bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is bit 2 (mhashopcount): If cleared ('0'), then <msg-hop-count> is
not included in the <msg-header>. If set ('1'), then <msg-hop- not included in the <msg-header>. If set ('1'), then <msg-hop-
count> is included in the <msg-header>. count> is included in the <msg-header>.
bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not bit 3 (mhasseqnum): If cleared ('0'), then <msg-seq-num> is not
included in the <msg-header>. If set ('1'), then <msg-seq-num> included in the <msg-header>. If set ('1'), then <msg-seq-num>
is included in the <msg-header>. is included in the <msg-header>.
<msg-addr-length> is a 4 bit unsigned integer field, encoding the <msg-addr-length> is a 4-bit unsigned integer field, encoding the
length of all addresses included in this message (<msg-orig-addr> length of all addresses included in this message (<msg-orig-addr>
as well as each address included in address blocks as defined in as well as each address included in Address Blocks as defined in
Section 5.3), as follows: Section 5.3), as follows:
<msg-addr-length> = the length of an address in octets - 1 <msg-addr-length> = the length of an address in octets - 1
<msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv4 <msg-addr-length> is thus 3 for IPv4 addresses, or 15 for IPv6
addresses. addresses.
address-length is a variable whose value is the length of an address address-length is a variable whose value is the length of an address
in octets, and is calculated as follows: in octets and is calculated as follows:
address-length = <msg-addr-length> + 1 address-length = <msg-addr-length> + 1
<msg-size> is a 16 bit unsigned integer field, specifying the number <msg-size> is a 16-bit unsigned integer field, specifying the number
of octets that make up the <message>, including the <msg-header>. of octets that make up the <message>, including the <msg-header>.
<msg-orig-addr> is omitted if the mhasorig flag is cleared ('0'), <msg-orig-addr> is omitted if the mhasorig flag is cleared ('0');
otherwise is an identifier with length equal to address-length, otherwise, is an identifier with length equal to address-length
which can serve to uniquely identify the MANET router that that can serve to uniquely identify the MANET router that
originated the message. originated the message.
<msg-hop-limit> is omitted if the mhashoplimit flag is cleared <msg-hop-limit> is omitted if the mhashoplimit flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'); otherwise, is an 8-bit unsigned integer field that can
contain the maximum number of hops that the message should be contain the maximum number of hops that the message should be
further transmitted. further transmitted.
<msg-hop-count> is omitted if the mhashopcount flag is cleared <msg-hop-count> is omitted if the mhashopcount flag is cleared
('0'), otherwise is an 8 bit unsigned integer field, which can ('0'); otherwise, is an 8-bit unsigned integer field that can
contain the number of hops that the message has traveled. contain the number of hops that the message has traveled.
<msg-seq-num> is omitted if the mhasseqnum flag is cleared ('0'), <msg-seq-num> is omitted if the mhasseqnum flag is cleared ('0');
otherwise is a 16 bit unsigned integer field, which can contain a otherwise, is a 16-bit unsigned integer field that can contain a
sequence number, generated by the message's originator MANET sequence number, generated by the message's originator MANET
router. router.
5.3. Address Blocks 5.3. Address Blocks
An address block can specify one or more addresses, all of which will An Address Block can specify one or more addresses, all of which will
each be address-length octets long, as specified using the <msg-addr- be address-length octets long, as specified using the <msg-addr-
length> in the <msg-header> of the message containing the address length> in the <msg-header> of the message containing the Address
block. An address block can also specify prefix lengths that can be Block. An Address Block can also specify prefix lengths that can be
applied to all addresses in the address block, if appropriate. This applied to all addresses in the Address Block, if appropriate. This
allows an address block to specify either addresses or address allows an Address Block to specify either addresses or address
prefixes. A protocol may specify that an address with a maximum prefixes. A protocol may specify that an address with a maximum
prefix length (equal to the address length, in bits, i.e. 8 * prefix length (equal to the address length in bits, i.e., 8 *
address-length) is considered to be an address, rather than an address-length) is considered to be an address, rather than an
address prefix, thus allowing an address block to contain a mixture address prefix, thus allowing an Address Block to contain a mixture
of addresses and address prefixes. The common term "address object" of addresses and address prefixes. The common term "address object"
is used in this specification to cover both of these; note that an is used in this specification to cover both of these; note that an
address object in an address block always includes the prefix length, address object in an Address Block always includes the prefix length,
if present. if present.
An address is specified as a sequence of address-length octets of the An address is specified as a sequence of address-length octets of the
form head:mid:tail. There are no semantics associated with head, mid form Head:Mid:Tail. There are no semantics associated with Head,
or tail; this representation is solely to allow aggregation of Mid, or Tail; this representation is solely to allow aggregation of
addresses, which often have common parts (e.g. common prefixes or addresses, which often have common parts (e.g., common prefixes or
multiple IPv6 addresses on the same interface). An address block multiple IPv6 addresses on the same interface). An Address Block
contains an ordered set of addresses all sharing the same head and contains an ordered set of addresses all sharing the same Head and
the same tail, but having individual mids. Independently, head and the same Tail, but having individual Mids. Independently, Head and
tail may be empty, allowing for representation of address objects Tail may be empty, allowing for representation of address objects
which do not have common heads or common tails. Detailed examples of that do not have common Heads or common Tails. Detailed examples of
address blocks are included in Appendix C.1. Address Blocks are included in Appendix C.1.
An address block can specify address prefixes: An Address Block can specify address prefixes:
o with a single prefix length for all address prefixes; OR o with a single prefix length for all address prefixes OR
o with a prefix length for each address prefix. o with a prefix length for each address prefix.
<address-block> is defined by: <address-block> is defined by:
<address-block> := <num-addr> <address-block> := <num-addr>
<addr-flags> <addr-flags>
(<head-length><head>?)? (<head-length><head>?)?
(<tail-length><tail>?)? (<tail-length><tail>?)?
<mid>* <mid>*
<prefix-length>* <prefix-length>*
where: where:
<num-addr> is an 8 bit unsigned integer field containing the number <num-addr> is an 8-bit unsigned integer field containing the number
of addresses represented in the address block, which MUST NOT be of addresses represented in the Address Block, which MUST NOT be
zero. zero.
<addr-flags> is an 8 bit field specifying the interpretation of the <addr-flags> is an 8-bit field specifying the interpretation of the
remainder of the address block: remainder of the Address Block:
bit 0 (ahashead): If cleared ('0'), then <head-length> and <head> bit 0 (ahashead): If cleared ('0'), then <head-length> and <head>
are not included in the <address-block>. If set ('1'), then are not included in the <address-block>. If set ('1'), then
<head-length> is included in the <address-block>, and <head> is <head-length> is included in the <address-block>, and <head> is
included in the <address-block> unless <head-length> is zero. included in the <address-block> unless <head-length> is zero.
bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted bit 1 (ahasfulltail) and bit 2 (ahaszerotail): Are interpreted
according to Table 1. A combination not shown in that table according to Table 1. A combination not shown in that table
MUST NOT be used. MUST NOT be used.
bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are bit 3 (ahassingleprelen) and bit 4 (ahasmultiprelen): Are
interpreted according to Table 2. A combination not shown in interpreted according to Table 2. A combination not shown in
that table MUST NOT be used. that table MUST NOT be used.
bits 5-7: Are RESERVED, and SHOULD each be cleared ('0') on bits 5-7: Are RESERVED and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission and SHOULD be ignored on reception.
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| ahasfulltail | ahaszerotail | <tail-length> | <tail> | | ahasfulltail | ahaszerotail | <tail-length> | <tail> |
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not included |
| 1 | 0 | included | included unless | | 1 | 0 | included | included unless |
| | | | <tail-length> is | | | | | <tail-length> is |
| | | | zero | | | | | zero |
| 0 | 1 | included | not included | | 0 | 1 | included | not included |
+--------------+--------------+---------------+---------------------+ +--------------+--------------+---------------+---------------------+
skipping to change at page 12, line 50 skipping to change at page 12, line 46
+------------+-----------+------------------+-----------------------+ +------------+-----------+------------------+-----------------------+
| 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
flags ahassingleprelen and ahasmultiprelen flags
<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 <head-length> if present, is an 8-bit unsigned integer field that
in the address block, i.e. each <head> element included is <head- contains the number of octets in the Head of all of the addresses
in the Address Block, i.e., each <head> element included is <head-
length> octets long. 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 that
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, i.e. each <tail> element included is <tail- in the Address Block, i.e., each <tail> element included is <tail-
length> octets long. 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 flag is set ('1'), otherwise it is a field of the ahaszerotail flag 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 flag is set ('1') then the Address Block. If the ahaszerotail flag 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 0.
mid-length is a variable, which MUST be non-negative, defined by: mid-length is a variable that 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. 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
flag is set ('1') then a single <prefix-length> field is included, flag is set ('1'), then a single <prefix-length> field is included
which contains the prefix length of all addresses in the address that contains the prefix length of all addresses in the Address
block. If the ahasmultiprelen flag is set ('1') then <num-addr> Block. If the ahasmultiprelen flag is set ('1'), then <num-addr>
<prefix-length> fields are included, each of which contains the <prefix-length> fields are included, each of which contains the
prefix length of the corresponding address prefix in the address prefix length of the corresponding address prefix in the Address
block (in the same order). Otherwise no <prefix-length> fields Block (in the same order). Otherwise, no <prefix-length> fields
are present; each address object can be considered to have a are present; each address object can be considered to have a
prefix length equal to 8 * address-length bits. The address block prefix length equal to 8 * address-length bits. The Address Block
is malformed if any <prefix-length> element has a value greater is malformed if any <prefix-length> element has a value greater
than 8 * address-length. than 8 * address-length.
5.4. TLVs and TLV Blocks 5.4. TLVs and TLV Blocks
A TLV allows the association of an arbitrary attribute with a message A TLV allows the association of an arbitrary attribute with a message
or a packet, or with a single address or a contiguous set of or a packet, or with a single address or a contiguous set of
addresses in an address block. The attribute (value) is made up from addresses in an Address Block. The attribute (value) is made up from
an integer number of consecutive octets. Different attributes have an integer number of consecutive octets. Different attributes have
different types; attributes which are unknown when parsing can be different types; attributes that are unknown when parsing can be
skipped. skipped.
TLVs are grouped in TLV blocks, with all TLVs within a TLV block TLVs are grouped in TLV Blocks, with all TLVs within a TLV Block
associating attributes with either the packet (for the TLV block in associating attributes with either the packet (for the TLV Block in
the packet header), the message (for the TLV block immediately the Packet Header), the message (for the TLV Block immediately
following the message header) or to addresses in the immediately following the Message Header), or to addresses in the immediately
preceding address block. Individual TLVs in a TLV block immediately preceding Address Block. Individual TLVs in a TLV Block immediately
following an address block can associate attributes to a single following an Address Block can associate attributes to a single
address, a range of addresses or all addresses in that address block. address, a range of addresses, or all addresses in that Address
When associating an attribute with more than one address, a TLV can Block. When associating an attribute with more than one address, a
include one value for all addresses, or one value per address. TLV can include one value for all addresses or one value per address.
Detailed examples of TLVs are included in Appendix C.2. Detailed examples of TLVs are included in Appendix C.2.
A TLV block is defined by: A TLV Block is defined by:
<tlv-block> := <tlvs-length> <tlv-block> := <tlvs-length>
<tlv>* <tlv>*
where: where:
<tlvs-length> is a 16 bit unsigned integer field, which contains the <tlvs-length> is a 16-bit unsigned integer field that contains the
total number of octets in all of the immediately following <tlv> total number of octets in all of the immediately following <tlv>
elements (<tlvs-length> not included). elements (<tlvs-length> not included).
<tlv> is as defined in Section 5.4.1. <tlv> is as defined in Section 5.4.1.
5.4.1. TLVs 5.4.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 the packet TLV block in a packet header. o A Packet TLV, included in the Packet TLV Block in a Packet Header.
o A message TLV, included in the message TLV block in a message, o A Message TLV, included in the Message TLV Block in a message,
before any address blocks. before any Address Blocks.
o An address block TLV, included in an address TLV block following o An Address Block TLV, included in an Address Block TLV Block
an address block. An address block TLV applies to: following an Address Block. An Address Block TLV applies to:
* all address objects in the address block; OR * all address objects in the Address Block, OR
* any continuous sequence of address objects in the address * any continuous sequence of address objects in the Address
block; OR Block, OR
* a single address object in the address block. * a single address object in the Address Block.
<tlv> is defined by: <tlv> is defined by:
<tlv> := <tlv-type> <tlv> := <tlv-type>
<tlv-flags> <tlv-flags>
<tlv-type-ext>? <tlv-type-ext>?
(<index-start><index-stop>?)? (<index-start><index-stop>?)?
(<length><value>?)? (<length><value>?)?
where: where:
<tlv-type> is an 8 bit unsigned integer field, specifying the type <tlv-type> is an 8-bit unsigned integer field, specifying the type
of the TLV, specific to the TLV kind (i.e. packet, message, or of the TLV, specific to the TLV kind (i.e., Packet TLV, Message
address block TLV). TLV, or Address Block TLV).
<tlv-flags> is an 8 bit field specifying the interpretation of the <tlv-flags> is an 8-bit field specifying the interpretation of the
remainder of the TLV: remainder of the TLV:
bit 0 (thastypeext): If cleared ('0'), then <tlv-type-ext> is not bit 0 (thastypeext): If cleared ('0'), then <tlv-type-ext> is not
included in the <tlv>. If set ('1'), then <tlv-type-ext> is included in the <tlv>. If set ('1'), then <tlv-type-ext> is
included in the <tlv>. included in the <tlv>.
bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are bit 1 (thassingleindex) and bit 2 (thasmultiindex): Are
interpreted according to Table 3. A combination not shown in interpreted according to Table 3. A combination not shown in
that table MUST NOT be used. Both of these flags MUST be that table MUST NOT be used. Both of these flags MUST be
cleared ('0') in packet and message TLVs. cleared ('0') in Packet TLVs and Message TLVs.
bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted bit 3 (thasvalue) and bit 4 (thasextlen): Are interpreted
according to Table 4. A combination not shown in that table according to Table 4. A combination not shown in that table
MUST NOT be used. MUST NOT be used.
bit 5 (tismultivalue): This flag serves to specify how the bit 5 (tismultivalue): This flag serves to specify how the
<value> field is interpreted, as specified below. This flag <value> field is interpreted, as specified below. This flag
MUST be cleared ('0') in packet and message TLVs, if the MUST be cleared ('0') in Packet TLVs and Message TLVs, if the
thasmultiindex flag is cleared ('0'), or if the thasvalue flag thasmultiindex flag is cleared ('0'), or if the thasvalue flag
is cleared ('0'). is cleared ('0').
bits 6-7: Are RESERVED, and SHOULD each be cleared ('0') on bits 6-7: Are RESERVED and SHOULD each be cleared ('0') on
transmission, and SHOULD be ignored on reception. transmission and SHOULD be ignored on reception.
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
| thassingleindex | thasmultiindex | <index-start> | <index-stop> | | thassingleindex | thasmultiindex | <index-start> | <index-stop> |
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not included |
| 1 | 0 | included | not included | | 1 | 0 | included | not included |
| 0 | 1 | included | included | | 0 | 1 | included | included |
+-----------------+----------------+---------------+--------------+ +-----------------+----------------+---------------+--------------+
Table 3: Interpretation of the thassingleindex and thasmultiindex Table 3: Interpretation of the
flags thassingleindex and thasmultiindex flags
+-----------+------------+--------------+---------------------------+ +-----------+------------+--------------+---------------------------+
| thasvalue | thasextlen | <length> | <value> | | thasvalue | thasextlen | <length> | <value> |
+-----------+------------+--------------+---------------------------+ +-----------+------------+--------------+---------------------------+
| 0 | 0 | not included | not included | | 0 | 0 | not included | not included |
| 1 | 0 | 8 bits | included unless <length> | | 1 | 0 | 8 bits | included unless <length> |
| | | | is zero | | | | | is zero |
| 1 | 1 | 16 bits | included unless <length> | | 1 | 1 | 16 bits | included unless <length> |
| | | | is zero | | | | | is zero |
+-----------+------------+--------------+---------------------------+ +-----------+------------+--------------+---------------------------+
Table 4: Interpretation of the thasvalue and thasextlen flags Table 4: Interpretation of the thasvalue and thasextlen flags
<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
packet, message, or address block TLV). (i.e., Packet TLV, Message TLV, 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 TLVs 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
flags thassingleindex and thasmultiindex 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-bit or 16-bit unsigned integer field
according to Table 4. If the tismultivalue flag is set ('1') then according to Table 4. If the tismultivalue flag is set ('1'),
<length> MUST be an integral multiple of number-values, and the then <length> MUST be an integral multiple of number-values, and
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 flag is cleared ('0'), then the variable If the tismultivalue 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 flag is cleared ('0') then the inclusive. If the tismultivalue flag is cleared ('0'), then the
whole of this field is associated with each of the indicated whole of this field is associated with each of the indicated
address objects. If the tismultivalue flag is set ('1') then this address objects. If the tismultivalue flag is set ('1'), then
field is divided equally into number-values fields, each of length this field is divided equally into number-values fields, each of
single-length octets, and these are associated, in order, with the length single-length octets, and these are associated, in order,
indicated address objects. with the indicated address objects.
5.4.2. TLV Usage 5.4.2. TLV Usage
A TLV associates an attribute with a packet, a message or one or more A TLV associates an attribute with a packet, a message, or one or
consecutive address objects in an address block. The interpretation more consecutive address objects in an Address Block. The
and processing of this attribute, and the relationship (including interpretation and processing of this attribute, and the relationship
order of processing) between different attributes associated with the (including order of processing) between different attributes
same entity MUST be defined by any protocol which uses this associated with the same entity MUST be defined by any protocol that
specification. uses this specification.
Any protocol using this specification MUST define appropriate Any protocol using this specification MUST define appropriate
behaviors if this associated information is inconsistent, in behaviors if this associated information is inconsistent, in
particular if two TLVs of the same type but with different values particular if two TLVs of the same type but with different values
apply to the same entity (packet, message or address) but this is not apply to the same entity (packet, message, or address) but this is
meaningful. The protocol MUST also specify an appropriate processing not meaningful. The protocol MUST also specify an appropriate
order for TLVs associated with a given entity. processing order for TLVs associated with a given entity.
5.5. Malformed Elements 5.5. Malformed Elements
An element is malformed if it cannot be parsed according to its An element is malformed if it cannot be parsed according to its
syntactical specification (including if there are insufficient octets syntactical specification (including if there are insufficient octets
available). If the malformed element is in the packet header then available). If the malformed element is in the Packet Header, then
the packet MUST be silently discarded, and contained messages MUST the packet MUST be silently discarded, and contained messages MUST
NOT be processed and MUST NOT be forwarded. If the malformed element NOT be processed and MUST NOT be forwarded. If the malformed element
is contained in a message (i.e. is in the message TLV block, an is contained in a message (i.e., is in the Message TLV Block, an
address block, or an address block TLV block) then that message MUST Address Block, or an Address Block TLV Block), then that message MUST
be silently discarded; it MUST NOT be processed and MUST NOT be be silently discarded; it MUST NOT be processed and MUST NOT be
forwarded. forwarded.
6. IANA Considerations 6. IANA Considerations
This document introduces four namespaces that require registration: This document introduces four namespaces that have been registered:
Message Types, Packet TLV Types, Message TLV Types and Address Block Message Types, Packet TLV Types, Message TLV Types, and Address Block
TLV Types. This section specifies IANA registries for these TLV Types. This section specifies IANA registries for these
namespaces, and provides guidance to the Internet Assigned Numbers namespaces and provides guidance to the Internet Assigned Numbers
Authority regarding registrations in these namespaces. Authority regarding registrations in these namespaces.
The following terms are used with the meanings defined in [BCP26]: The following terms are used with the meanings defined in [BCP26]:
"Namespace", "Assigned Value", "Registration", "Unassigned", "Namespace", "Assigned Value", "Registration", "Unassigned",
"Reserved", "Hierarchical Allocation", "Designated Expert". "Reserved", "Hierarchical Allocation", and "Designated Expert".
The following policies are used with the meanings defined in [BCP26]: The following policies are used with the meanings defined in [BCP26]:
"Private Use", "Expert Review", "Standards Action". "Private Use", "Expert Review", and "Standards Action".
6.1. Expert Review: Evaluation Guidelines 6.1. Expert Review: Evaluation Guidelines
For registration requests where an Expert Review is required, the For registration requests where an Expert Review is required, the
Designated Expert SHOULD take the following general recommendations Designated Expert SHOULD take the following general recommendations
into consideration: into consideration:
o The purposes of these registries are to support Standard and o The purpose of these registries is to support Standard and
Experimental MANET routing and related protocols, and extensions Experimental MANET routing and related protocols and extensions to
to the same. these protocols.
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 thereto as designated by the Area list, or to a successor thereto as designated by the Area
Director, for comments and reviews. This request will include a Director, for comments and reviews. This request will include a
reference 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 inform IANA and the IESG. A denial note MUST be justified
justified by an explanation and, in cases where it is possible, by an explanation and, in cases where it is possible, suggestions
suggestions as to how the request can be modified so as to become as to how the request can be modified so as to become acceptable
acceptable SHOULD be provided. SHOULD be provided.
For the registry for Message Types, the following guidelines apply: For the registry for Message Types, the following guidelines apply:
o Registration of a message type implies creation of two registries o Registration of a Message Type implies creation of two registries
for message type specific message TLVs and message type specific for Message-Type-specific Message TLVs and Message-Type-specific
address block TLVs. The document which requests the registration Address Block TLVs. The document that requests the registration
of the message type MUST indicate how these message type specific of the Message Type MUST indicate how these Message-Type-specific
TLV types are to be allocated, from any options in [BCP26], and TLV Types are to be allocated, from any options in [BCP26], and
any initial allocations. The Designated Expert SHOULD take the any initial allocations. The Designated Expert SHOULD take the
allocation policies specified for these registries into allocation policies specified for these registries into
consideration in reviewing the message type allocation request. consideration in reviewing the Message Type allocation request.
For the registries for Packet TLV Types, Message TLV Types and For the registries for Packet TLV Types, Message TLV Types, and
Address Block TLV Types, the following guidelines apply: Address Block TLV Types, the following guidelines apply:
o These are Hierarchical Allocations, i.e. allocation of a type o These are Hierarchical Allocations, i.e., allocation of a type
creates a registry for the extended types corresponding to that creates a registry for the extended types corresponding to that
type. The document which requests the registration of the type type. The document that requests the registration of the type
MUST indicate how these extended types are to be allocated, from MUST indicate how these extended types are to be allocated, from
any options in [BCP26], and any initial allocations. Normally any options in [BCP26], and any initial allocations. Normally
this allocation should also be Expert Review, but with the this allocation should also undergo Expert Review, but with the
possible allocation of some type extensions as Reserved, possible allocation of some type extensions as Reserved,
Experimental and/or Private. Experimental, and/or Private.
o The request for a TLV type MUST include the specification of the o The request for a TLV Type MUST include the specification of the
permitted size, syntax of any internal structure of, and meaning permitted size, syntax of any internal structure, and meaning, of
of, the value field (if any) of the TLV. the Value field (if any) of the TLV.
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 that
which receive registrations from the 0-127 interval SHOULD be receive registrations from the 0-127 interval SHOULD be modular in
modular in design to allow reuse among protocols. 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
requires 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 that 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
SHOULD be used. SHOULD be used.
6.2. Message Types 6.2. Message Types
A new registry for message types must be created, with initial A new registry for Message Types has been created, with initial
assignments and allocation policies as specified in Table 6. assignments and allocation policies as specified in Table 6.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review | | 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 6: Message Types Table 6: Message Types
6.2.1. Message Type Specific TLV Registry Creation 6.2.1. Message-Type-Specific TLV Registry Creation
When a message type is registered then registries MUST be specified When a Message Type is registered, then registries MUST be specified
for both message type specific message TLVs (Table 8) and message for both Message-Type-specific Message TLVs (Table 8) and Message-
type specific address block TLVs (Table 10). A document which Type-specific Address Block TLVs (Table 10). A document that creates
creates a message type specific TLV registry MUST also specify the a Message-Type-specific TLV registry MUST also specify the mechanism
mechanism by which message specific TLV types are allocated, from by which Message-Type-specific TLV Types are allocated, from among
among those in [BCP26]. those in [BCP26].
6.3. Packet TLV Types 6.3. Packet TLV Types
A new registry for packet TLV types must be created, with initial A new registry for Packet TLV Types has been created, with initial
assignments and allocation policies as specified in Table 7. assignments and allocation policies as specified in Table 7.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 0-223 | Unassigned | Expert Review | | 0-223 | Unassigned | Expert Review |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 7: Packet TLV Types Table 7: Packet TLV Types
6.3.1. Packet TLV Type Extension Registry Creation 6.3.1. Packet TLV Type Extension Registry Creation
When a packet TLV type is registered then a new registry for type When a Packet TLV Type is registered, then a new registry for type
extensions of that type must be created. A document which defines a extensions of that type must be created. A document that defines a
packet TLV type MUST also specify the mechanism by which its type Packet TLV Type MUST also specify the mechanism by which its type
extensions are allocated, from among those in [BCP26]. extensions are allocated, from among those in [BCP26].
6.4. Message TLV Types 6.4. Message TLV Types
A new registry for message type independent message TLV types must be A new registry for Message-Type-independent Message TLV Types has
created, with initial assignments and allocation policies as been created, with initial assignments and allocation policies as
specified in Table 8. specified in Table 8.
+---------+-----------------------+-----------------------+ +---------+-----------------------+-----------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------+-----------------------+ +---------+-----------------------+-----------------------+
| 0-127 | Unassigned | Expert Review | | 0-127 | Unassigned | Expert Review |
| 128-223 | Message Type Specific | Reserved, see Table 9 | | 128-223 | Message-Type-specific | Reserved, see Table 9 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+-----------------------+ +---------+-----------------------+-----------------------+
Table 8: Message TLV Types Table 8: Message TLV Types
Message TLV Types 128-223 are reserved for message type specific Message TLV Types 128-223 are reserved for Message-Type-specific
Message TLVs, for which a new registry is created with the Message TLVs, for which a new registry is created with the
registration of a message type, and with initial assignments and registration of a Message Type, and with initial assignments and
allocation policies as specified in Table 9. allocation policies as specified in Table 9.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved | | 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message Type Specific | See Below | | 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved | | 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
Table 9: Message Specific Message TLV Types Table 9: Message-Type-specific Message TLV Types
Allocation policies for message type specific message TLV types MUST
Allocation policies for Message-Type-specific Message TLV Types MUST
be specified when creating the registry associated with the be specified when creating the registry associated with the
containing message type, see Section 6.2.1. containing Message Type, see Section 6.2.1.
6.4.1. Message TLV Type Extension Registry Creation 6.4.1. Message TLV Type Extension Registry Creation
If a message TLV type is registered then a new registry for type If a Message TLV Type is registered, then a new registry for type
extensions of that type must be created. A document which defines a extensions of that type must be created. A document that defines a
message TLV type MUST also specify the mechanism by which its type Message TLV Type MUST also specify the mechanism by which its type
extensions are allocated, from among those in [BCP26]. extensions are allocated, from among those in [BCP26].
6.5. Address Block TLV Types 6.5. Address Block TLV Types
A new registry for message type independent address block TLV types A new registry for Message-Type-independent Address Block TLV Types
must be created, with initial assignments and allocation policies as has been created, with initial assignments and allocation policies as
specified in Table 10. specified in Table 10.
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
| 0-127 | Unassigned | Expert Review | | 0-127 | Unassigned | Expert Review |
| 128-223 | Message Type Specific | Reserved, see Table 11 | | 128-223 | Message-Type-specific | Reserved, see Table 11 |
| 224-255 | Unassigned | Experimental Use | | 224-255 | Unassigned | Experimental Use |
+---------+-----------------------+------------------------+ +---------+-----------------------+------------------------+
Table 10: Address Block TLV Types Table 10: Address Block TLV Types
Address Block TLV Types 128-223 are reserved for message type Address Block TLV Types 128-223 are reserved for Message-Type-
specific Address Block TLVs, for which a new registry is created with specific Address Block TLVs, for which a new registry is created with
the registration of a message type, and with initial assignments and the registration of a Message Type, and with initial assignments and
allocation policies as specified in Table 11. allocation policies as specified in Table 11.
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
| 0-127 | Common to all Message Types | Reserved | | 0-127 | Common to all Message Types | Reserved |
| 128-223 | Message Type Specific | See Below | | 128-223 | Message-Type-specific | See Below |
| 224-255 | Common to all Message Types | Reserved | | 224-255 | Common to all Message Types | Reserved |
+---------+-----------------------------+-------------------+ +---------+-----------------------------+-------------------+
Table 11: Message Specific Address Block TLV Types Table 11: Message-Type-specific Address Block TLV Types
Allocation policies for message type specific address block TLV types Allocation policies for Message-Type-specific Address Block TLV Types
MUST be specified when creating the registry associated with the MUST be specified when creating the registry associated with the
containing message type, see Section 6.2.1. containing Message Type, see Section 6.2.1.
6.5.1. Address Block TLV Type Extension Registry Creation 6.5.1. Address Block TLV Type Extension Registry Creation
When an address block TLV type is registered then a new registry for When an Address Block TLV Type is registered, then a new registry for
type extensions of that type must be created. A document which type extensions of that type must be created. A document that
defines a message TLV type MUST also specify the mechanism by which defines a Message TLV Type MUST also specify the mechanism by which
its type extensions are allocated, from among those in [BCP26]. its type extensions are allocated, from among those in [BCP26].
7. Security Considerations 7. Security Considerations
This specification does not describe a protocol; it describes a This specification does not describe a protocol; it describes a
packet format. As such it does not specify any security packet format. As such, it does not specify any security
considerations, these are matters for a protocol using this considerations; these are matters for a protocol using this
specification. However some security mechanisms are enabled by this specification. However, some security mechanisms are enabled by this
specification, and may form part of a protocol using this specification and may form part of a protocol using this
specification. Mechanisms which may form part of an authentication specification. Mechanisms that may form part of an authentication
and integrity approach in a protocol using this specification, are and integrity approach in a protocol using this specification are
described in Section 7.1. Mechanisms which may form part of a described in Section 7.1. Mechanisms that may form part of a
confidentiality approach in a protocol using this specification, are confidentiality approach in a protocol using this specification are
described in Section 7.2. There is however no requirement that a described in Section 7.2. There is, however, no requirement that a
protocol using this specification should use either. protocol using this specification should use either.
7.1. Authentication and Integrity Suggestions 7.1. Authentication and Integrity Suggestions
The authentication and integrity suggestions made here, are based on The authentication and integrity suggestions made here are based on
the intended usage in Appendix B, specifically that: the intended usage in Appendix B, specifically that:
o Messages are designed to be carriers of protocol information and o Messages are designed to be carriers of protocol information and
MAY, at each hop, be forwarded and/or processed by the protocol MAY, at each hop, be forwarded and/or processed by the protocol
using this specification. using this specification.
o Packets are designed to carry a number of messages between o Packets are designed to carry a number of messages between
neighboring MANET routers in a single transmission and over a neighboring MANET routers in a single transmission and over a
single logical hop. single logical hop.
Consequently: Consequently:
o For forwarded messages where the message is unchanged by o For forwarded messages where the message is unchanged by
forwarding MANET routers, then end-to-end authentication and forwarding MANET routers, end-to-end authentication and integrity
integrity MAY be implemented, between MANET routers with an MAY be implemented, between MANET routers with an existing
existing security association, by including a suitable message TLV security association, by including a suitable Message TLV
containing a cryptographic signature in the message. Since <msg- containing a cryptographic signature in the message. Since <msg-
hop-count> and <msg-hop-limit> are the only fields that should be hop-count> and <msg-hop-limit> are the only fields that should be
modified when such a message is forwarded in this manner, this modified when such a message is forwarded in this manner, this
signature can be calculated based on the entire message, including signature can be calculated based on the entire message, including
the message header, with the <msg-hop-count> and <msg-hop-limit> the Message Header, with the <msg-hop-count> and <msg-hop-limit>
fields set to 0 if present. fields set to 0, if present.
o Hop-by-hop packet level authentication and integrity MAY be o Hop-by-hop packet level authentication and integrity MAY be
implemented, between MANET routers with an existing security implemented, between MANET routers with an existing security
association, by including a suitable packet TLV containing a association, by including a suitable Packet TLV containing a
cryptographic signature to the packet. Since packets are received cryptographic signature to the packet. Since packets are received
as transmitted, this signature can be calculated based on the as transmitted, this signature can be calculated based on the
entire packet, or on parts thereof as appropriate. entire packet or on parts thereof as appropriate.
7.2. Confidentiality Suggestions 7.2. Confidentiality Suggestions
This specification does not explicitly enable protecting packet/ This specification does not explicitly enable protecting packet/
message confidentiality. Such confidentiality would normally, when message confidentiality. Such confidentiality would normally, when
required, be provided hop-by-hop either by link-layer mechanisms, or required, be provided hop-by-hop, either by link-layer mechanisms or
at the IP layer using [RFC4301], and would apply to a packet only. at the IP layer using [RFC4301], and would apply to a packet only.
It is possible, however, for a protocol using this specification to It is possible, however, for a protocol using this specification to
protect the confidentiality of information included in a packet, protect the confidentiality of information included in a Packet,
message or address block TLV by specifying that the value field of Message, or Address Block TLV by specifying that the Value field of
that TLV type be encrypted, as well as specifying the encryption that TLV Type be encrypted, as well as specifying the encryption
mechanism. mechanism.
In an extreme case, all information can be encrypted by defining In an extreme case, all information can be encrypted by defining
either: either:
o A packet, consisting of only a packet header (with no messages), o A packet, consisting of only a Packet Header (with no messages)
and containing a packet TLV, where the packet TLV type indicates and containing a Packet TLV, where the Packet TLV Type indicates
that its value field contains one or more encrypted messages. that its Value field contains one or more encrypted messages.
Upon receipt, and once this packet TLV is successfully decrypted, Upon receipt, and once this Packet TLV is successfully decrypted,
these messages may then be parsed according to this specification these messages may then be parsed according to this specification
and processed according to the protocol using this specification. and processed according to the protocol using this specification.
o A message, consisting of only a message header and a single o A message, consisting of only a Message Header and a single
message TLV, where the message TLV type indicates that its value Message TLV, where the Message TLV Type indicates that its Value
field contains an encrypted version of the message's remaining field contains an encrypted version of the message's remaining
message TLVs, address blocks and address block TLVs. Upon Message TLVs, Address Blocks, and Address Block TLVs. Upon
receipt, and once this message TLV is successfully decrypted, the receipt, and once this Message TLV is successfully decrypted, the
complete message may then be parsed according to this complete message may then be parsed according to this
specification and processed according to the protocol using this specification and processed according to the protocol using this
specification. specification.
In either case, the protocol MUST define the encrypted TLV type, as In either case, the protocol MUST define the encrypted TLV Type, as
well as the format of the encrypted data block contained in the value well as the format of the encrypted data block contained in the Value
field of the TLV. field of the TLV.
8. References 8. Contributors
8.1. Normative References This specification is the result of the joint efforts of the
following contributors from the OLSRv2 Design Team, listed
alphabetically:
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org>
o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
9. Acknowledgments
The authors would like to acknowledge the team behind OLSR [RFC3626],
including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
(both at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Elwyn
Davies (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
for intense technical discussions, early reviews, and comments on the
specification and its components (listed alphabetically):
o Brian Adamson (NRL)
o Teco Boot (Infinity Networks)
o Florent Brunneau (LIX)
o Ian Chakeres (CenGen)
o Alan Cullen (BAE Systems)
o Ulrich Herberg (LIX)
o Joe Macker (NRL)
o Yasunori Owada (Niigata University)
o Charlie E. Perkins (WiChorus)
o Henning Rogge (FGAN)
o Andreas Schjonhaug (LIX)
and the entire IETF MANET working group.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
BCP 26, May 2008. RFC 5226, May 2008.
[SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC [SingleUNIX] IEEE Std 1003.1, The Open Group, and ISO/IEC JTC
1/SC22/WG15, "Single UNIX Specification, Version 3, 1/SC22/WG15, "Single UNIX Specification, Version 3,
2004 Edition", April 2004. 2004 Edition", April 2004.
8.2. Informative References 10.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The [Stevens] Stevens, W., "TCP/IP Illustrated Volume 1 - The
Protocols.", 1994. Protocols", 1994.
Appendix A. Multiplexing and Demultiplexing Appendix A. Multiplexing and Demultiplexing
The packet and message format specified in this document is designed The packet and message format specified in this document is designed
to allow zero or more messages to be contained within a single to allow zero or more messages to be contained within a single
packet. Such messages may be from the same or from different packet. Such messages may be from the same or different protocols.
protocols. Thus, a multiplexing and demultiplexing process MUST be Thus, a multiplexing and demultiplexing process MUST be present.
present.
Multiplexing messages on a given MANET router into a single packet, Multiplexing messages on a given MANET router into a single packet,
rather than to have each message generate its own packet, reduces the rather than having each message generate its own packet, reduces the
total number of octets, and the number of packets transmitted by that total number of octets and the number of packets transmitted by that
MANET router. MANET router.
The multiplexing and demultiplexing process running on a given UDP The multiplexing and demultiplexing process running on a given UDP
port or IP protocol number, and its associated protocols, MUST: port or IP protocol number, and its associated protocols, MUST:
o For each message type, a protocol - unless specified otherwise, o For each Message Type, a protocol -- unless specified otherwise,
the one making the IANA reservation for that message type - MUST the one making the IANA reservation for that Message Type -- MUST
be designated as the "owner" of that message type. be designated as the "owner" of that Message Type.
o The packet header fields, including the Packet TLV block, is used o The Packet Header fields, including the Packet TLV Block, are used
by the multiplexing and demultiplexing process, which MAY make by the multiplexing and demultiplexing process, which MAY make
such information available for use its protocol instances. such information available for use in its protocol instances.
o The <pkt-seq-num> field, if present, contains a sequence number o The <pkt-seq-num> field, if present, contains a sequence number
which is incremented by 1 for each packet generated by a node. that is incremented by 1 for each packet generated by a node. The
The sequence number after 65535 is 0. In other words, the sequence number after 65535 is 0. In other words, the sequence
sequence number "wraps" in the usual way. number "wraps" in the usual way.
o Incoming messages MUST be either silently discarded or MUST be o Incoming messages MUST be either silently discarded or MUST be
delivered to the instance of the protocol which owns the delivered to the instance of the protocol that owns the associated
associated message type. Incoming messages SHOULD NOT be Message Type. Incoming messages SHOULD NOT be delivered to any
delivered to any other protocol instances and SHOULD NOT be other protocol instances and SHOULD NOT be delivered to more than
delivered to more than one protocol instance. one protocol instance.
o Outgoing messages of a given type MUST be generated only by the o Outgoing messages of a given type MUST be generated only by the
protocol instance which owns that message type and delivered to protocol instance that owns that Message Type and be delivered to
the multiplexing and demultiplexing process. the multiplexing and demultiplexing process.
o If two protocols both wish to use the same message type then this o If two protocols both wish to use the same Message Type, then this
interaction SHOULD be specified by the protocol which is the interaction SHOULD be specified by the protocol that is the
designated owner of that message type. designated owner of that Message Type.
Appendix B. Intended Usage Appendix B. Intended Usage
This appendix describes the intended usage of message header fields This appendix describes the intended usage of Message Header fields,
including their content and use. Alternative uses of this including their content and use. Alternative uses of this
specification are permitted. specification are permitted.
The message format specified in this document is designed to carry The message format specified in this document is designed to carry
MANET routing protocol signaling between MANET routers, and to MANET routing protocol signaling between MANET routers and to support
support scope limited flooding as well as point-to-point delivery. scope-limited flooding as well as point-to-point delivery.
Messages are designed to be able to be forwarded over one or more Messages are designed to be able to be forwarded over one or more
logical hops, in a new packet for each logical hop. Each logical hop logical hops, in a new packet for each logical hop. Each logical hop
may consist of one or more IP hops. may consist of one or more IP hops.
Specifically Scope limited flooding is supported for messages by: Specifically, scope-limited flooding is supported for messages when:
o The <msg-orig-addr> field, if present, contains the unique o The <msg-orig-addr> field, if present, contains the unique
identifier of the MANET router which originated the message. identifier of the MANET router that originated the message.
o The <msg-seq-num> field, if present, contains a sequence number o The <msg-seq-num> field, if present, contains a sequence number
which starts at 0 when first message of a given type is generated that starts at 0 when the first message of a given type is
by the originator node, and is incremented by 1 for each message generated by the originator node, and that is incremented by 1 for
generated of that type. The sequence number after 65535 is 0. In each message generated of that type. The sequence number after
other words, the sequence number "wraps" in the usual way. 65535 is 0. In other words, the sequence number "wraps" in the
usual way.
o If the <msg-orig-addr> and <msg-seq-num> fields are both present, o If the <msg-orig-addr> and <msg-seq-num> fields are both present,
then the message header provides for duplicate suppression, using then the Message Header provides for duplicate suppression, using
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 discard 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-count> 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
This appendix contains some examples of parts of this specification. This appendix contains some examples of parts of this specification.
C.1. Address Block Examples C.1. Address Block Examples
The following examples illustrate how some combinations of addresses The following examples illustrate how some combinations of addresses
may be efficiently included in address blocks. These examples are may be efficiently included in Address Blocks. These examples are
for IPv4, with address-length equal to 4. a, b, c etc. represent for IPv4, with address-length equal to 4. a, b, c, etc. represent
distinct, non-zero, octet values. distinct, non-zero octet values.
Note that it is permissible to use a less efficient representation, Note that it is permissible to use a less efficient representation,
in particular one in which the ahashead and ahasfulltail flags are in particular one in which the ahashead and ahasfulltail flags are
cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length cleared ('0'), and hence head-length = 0, tail-length = 0, mid-length
= address-length, and (with no address prefixes) the address block = address-length, and (with no address prefixes) the Address Block
consists of the number of addresses, <addr-flags> with value 0, and a consists of the number of addresses, <addr-flags> with value 0, and a
list of the unaggregated addresses. This is the most efficient way list of the unaggregated addresses. This is the most efficient way
to represent a single address, and the only way to represent, for to represent a single address, and the only way to represent, for
example, a.b.c.d and e.f.g.h in one address block. example, a.b.c.d and e.f.g.h in one Address Block.
Examples: Examples:
o To include a.b.c.d, a.b.e.f and a.b.g.h: o To include a.b.c.d, a.b.e.f, and a.b.g.h:
* head-length = 2; * head-length = 2;
* tail-length = 0; * tail-length = 0;
* mid-length = 2; * mid-length = 2;
* <addr-flags> has ahashead set (value 128); * <addr-flags> has ahashead set (value 128);
* <tail-length> and <tail> are omitted. * <tail-length> and <tail> are omitted.
The address block is then 3 128 2 a b c d e f g h (11 octets). The Address Block is then 3 128 2 a b c d e f g h (11 octets).
o To include a.b.c.g and d.e.f.g: o To include a.b.c.g and d.e.f.g:
* head-length = 0; * head-length = 0;
* tail-length = 1; * tail-length = 1;
* mid-length = 3; * mid-length = 3;
* <addr-flags> has ahasfulltail set (value 64); * <addr-flags> has ahasfulltail set (value 64);
* <head-length> and <head> are omitted. * <head-length> and <head> are omitted.
The address block is then 2 64 1 g a b c d e f (10 octets). The Address Block is then 2 64 1 g a b c d e f (10 octets).
o To include a.b.d.e and a.c.d.e: o To include a.b.d.e and a.c.d.e:
* head-length = 1; * head-length = 1;
* tail-length = 2; * tail-length = 2;
* mid-length = 1; * mid-length = 1;
* <addr-flags> has ahashead and ahasfulltail set (value 192). * <addr-flags> has ahashead and ahasfulltail set (value 192).
The address block is then 2 192 1 a 2 d e b c (9 octets). The Address Block is then 2 192 1 a 2 d e b c (9 octets).
o To include a.b.0.0, a.c.0.0, and a.d.0.0: o To include a.b.0.0, a.c.0.0, and a.d.0.0:
* head-length = 1; * head-length = 1;
* tail-length = 2; * tail-length = 2;
* mid-length = 1; * mid-length = 1;
* <addr-flags> has ahashead and ahaszerotail set (value 160); * <addr-flags> has ahashead and ahaszerotail set (value 160);
* <tail> is omitted. * <tail> is omitted.
The address block is then 3 160 1 a 2 b c d (8 octets). The Address Block is then 3 160 1 a 2 b c d (8 octets).
o To include a.b.0.0 and c.d.0.0: o To include a.b.0.0 and c.d.0.0:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-flags> has ahaszerotail set (value 32); * <addr-flags> has ahaszerotail set (value 32);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 32 2 a b c d (7 octets). The Address Block is then 2 32 2 a b c d (7 octets).
o To include a.b.0.0/n and c.d.0.0/n: o To include a.b.0.0/n and c.d.0.0/n:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-flags> has ahaszerotail and ahassingleprelen set (value * <addr-flags> has ahaszerotail and ahassingleprelen set (value
48); 48);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 48 2 a b c d n (8 octets). The Address Block is then 2 48 2 a b c d n (8 octets).
o To include a.b.0.0/n and c.d.0.0/m: o To include a.b.0.0/n and c.d.0.0/m:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value * <addr-flags> has ahaszerotail and ahasmultiprelen set (value
skipping to change at page 30, line 4 skipping to change at page 32, line 23
o To include a.b.0.0/n and c.d.0.0/m: o To include a.b.0.0/n and c.d.0.0/m:
* head-length = 0; * head-length = 0;
* tail-length = 2; * tail-length = 2;
* mid-length = 2; * mid-length = 2;
* <addr-flags> has ahaszerotail and ahasmultiprelen set (value * <addr-flags> has ahaszerotail and ahasmultiprelen set (value
40); 40);
* <head> and <tail> are omitted. * <head> and <tail> are omitted.
The address block is then 2 40 2 a b c d n m (9 octets). The Address Block is then 2 40 2 a b c d n m (9 octets).
C.2. TLV Examples C.2. TLV Examples
Assuming the definition of an address block TLV with type EXAMPLE1 Assume the definition of an Address Block TLV with type EXAMPLE1 (and
(and no type extension) which has single octet values per address, no type extension) that has single octet values per address. There
then if values a, a, b and c are to be associated with the four are a number of ways in which values a, a, b, and c may be associated
addresses in the preceding address block, where c is a default value with the four addresses in the preceding Address Block, where c is a
that can be omitted, then this can be done in a number of ways. default value that can be omitted.
Examples: Examples:
o Using one multivalue TLV covering all of the addresses: o Using one multivalue TLV to cover all of the addresses:
* <tlv-flags> has thasvalue and tismultivalue set (value 20); * <tlv-flags> has thasvalue and tismultivalue set (value 20);
* <index-start> and <index-stop> are omitted; * <index-start> and <index-stop> are omitted;
* <length> = 4 (single-length = 1). * <length> = 4 (single-length = 1).
* The TLV is then EXAMPLE1 20 4 a a b c (7 octets). * The TLV is then EXAMPLE1 20 4 a a b c (7 octets).
o Using one multivalue TLV omitting the last address: o Using one multivalue TLV and omitting the last address:
* <tlv-flags> has thasmultiindex, thasvalue and tismultivalue set
(value 52);
* <tlv-flags> has thasmultiindex, thasvalue, and tismultivalue
set (value 52);
* <index-start> = 0; * <index-start> = 0;
* <index-stop> = 2 * <index-stop> = 2;
* <length> = 3 (single-length = 1). * <length> = 3 (single-length = 1).
* The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets). * The TLV is then EXAMPLE1 52 0 2 3 a a b (8 octets).
o Using two single value TLVs, omitting the last address. First: o Using two single value TLVs and omitting the last address. First:
* <tlv-flags> has thasmultiindex and thasvalue set (value 48); * <tlv-flags> has thasmultiindex and thasvalue set (value 48);
* <index-start> = 0; * <index-start> = 0;
* <index-stop> = 1; * <index-stop> = 1;
* <length> = 1; * <length> = 1;
* <value> = a. * <value> = a.
* The TLV is then EXAMPLE1 48 0 1 1 a (6 octets). * The TLV is then EXAMPLE1 48 0 1 1 a (6 octets).
Second: Second:
* <tlv-flags> has thassingleindex and thasvalue set (value 80); * <tlv-flags> has thassingleindex and thasvalue set (value 80);
* <index-start> = 2; * <index-start> = 2;
skipping to change at page 31, line 24 skipping to change at page 33, line 42
* <index-stop> is omitted; * <index-stop> is omitted;
* <length> = 1; * <length> = 1;
* <value> = b. * <value> = b.
* The TLV is then EXAMPLE1 80 2 1 b (5 octets). * The TLV is then EXAMPLE1 80 2 1 b (5 octets).
Total length of TLVs is 11 octets. Total length of TLVs is 11 octets.
In this case the first of these is the most efficient. In other In this case, the first of these is the most efficient. In other
cases patterns such as the others may be preferred. Regardless of cases, patterns such as the others may be preferred. Regardless of
efficiency, any of these may be used. efficiency, any of these may be used.
Assuming the definition of an address block TLV with type EXAMPLE2 Assume the definition of an Address Block TLV with type EXAMPLE2 (and
(and no type extension) which has no value, which is to be associated no type extension) that has no value and that is to be associated
with the second and third addresses in an address block, then this with the second and third addresses in an Address Block. This can be
can be indicated with a single TLV: indicated with a single TLV:
o <tlv-flags> has thasmultiindex set (value 32); o <tlv-flags> has thasmultiindex set (value 32);
o <index-start> = 1; o <index-start> = 1;
o <index-stop> = 2; o <index-stop> = 2;
o <length> and <value> are omitted. o <length> and <value> are omitted.
o The TLV is then EXAMPLE2 32 1 2 (4 octets). o The TLV is then EXAMPLE2 32 1 2 (4 octets).
Assuming the definition of a message TLV with type EXAMPLE3 (and no Assume the definition of a Message TLV with type EXAMPLE3 (and no
type extension) which can take a value field of any length, for such type extension) that can take a Value field of any length. For such
a TLV with 8 octets of data (a to h): a TLV with 8 octets of data (a to h):
o <tlv-flags> has thasvalue set (value 16); o <tlv-flags> has thasvalue set (value 16);
o <index-start> and <index-stop> are omitted; o <index-start> and <index-stop> are omitted;
o <length> = 8. o <length> = 8.
o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets). o The TLV is then EXAMPLE3 16 8 a b c d e f g h (11 octets).
If, in this example, the number of data octets were 256 or greater If, in this example, the number of data octets were 256 or greater,
then <tlv-flags> would also have thasextlen set and have value 24. then <tlv-flags> would also have thasextlen set and have value 24.
The length would require two octets (most significant first). The The length would require two octets (most significant first). The
TLV length would be 4 + N octets, where N is the number of data TLV length would be 4 + N octets, where N is the number of data
octets (it can be 3 + N octets if N is 255 or less). octets (it can be 3 + N octets if N is 255 or less).
Appendix D. Illustrations Appendix D. Illustrations
This informative appendix illustrates the elements which are This informative appendix illustrates the elements that are
normatively specified in Section 5. normatively specified in Section 5.
Bits labeled Rsv should be cleared ('0'). Bits labeled M may be Bits labeled Rsv should be cleared ('0'). Bits labeled M may be
cleared ('0') or set ('1'). cleared ('0') or set ('1').
D.1. Packet D.1. Packet
Possible options for the <packet> element. These are differentiated This section illustrates possible options for the <packet> element.
by the flags field in the first octet. The packet may include any These are differentiated by the flags field in the first octet. The
number (zero or more) of Messages. The number of Messages is packet may include any number (zero or more) of messages. The number
determined from when the packet is exhausted, given the packet length of messages is determined from when the packet is exhausted, given
from the network layer. the packet length from the network layer.
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|Rsv| | |0|0|0|0|0|0|Rsv| |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Message | | Message |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
skipping to change at page 35, line 35 skipping to change at page 38, line 7
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message | | Message |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.2. Message D.2. Message
Possible options for the <message> element. These are differentiated This section illustrates possible options for the <message> element.
by their second (flags) octet. The length of the Message Body is These are differentiated by their second (flags) octet. The length
determined using the Message Size field, which is the combined length of the Message Body is determined using the Message Size field, which
of all the fields shown. The field labeled MAL defines the length of is the combined length of all the fields shown. The field labeled
all addresses (including the Originator Address, if present, and all MAL defines the length of all addresses (including the Originator
addresses in address blocks) in octets, as one more than the value in Address, if present, and all addresses in Address Blocks) in octets,
the field. as one more than the value in the field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |0|0|0|0| MAL | Message Size | | Message Type |0|0|0|0| MAL | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 22 skipping to change at page 44, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.3. Message Body D.3. Message Body
Format of a message body (the <message> element excluding its initial This section illustrates the format of a Message Body (the <message>
<msg-header> element). The message body includes one Message TLV element excluding its initial <msg-header> element). The Message
Block (containing zero or more TLVs) and may include any number (zero Body includes one Message TLV Block (containing zero or more TLVs)
or more) of Address Block and Address TLV Block pairs. and may include any number (zero or more) of Address Block and
Address Block TLV Block pairs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message TLV Block | | Message TLV Block |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Address Block | | Address Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Address TLV Block | | Address Block TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Address Block | | Address Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Address TLV Block | | Address Block TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.4. Address Block D.4. Address Block
Possible options for the <addr-block> element. These are This section illustrates possible options for the <addr-block>
differentiated by their second (flags) octet. The number of Mid element. These are differentiated by their second (flags) octet.
elements is equal to the number of addresses (except when mid-length The number of Mid elements is equal to the number of addresses
is zero, when there are no Mid elements). Where a variable number of (except when mid-length is zero, when there are no Mid elements).
Prefix Length fields is shown, their number is equal to the number of Where a variable number of prefix length fields is shown, their
addresses. number is equal to the number of addresses.
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|0|0|0|0| Rsv | Mid | | Number Addrs |0|0|0|0|0| Rsv | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | | | Mid (cont) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
skipping to change at page 49, line 46 skipping to change at page 52, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length | | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.5. TLV Block D.5. TLV Block
Format of a <tlv-block> element. There may be any number (zero or This section illustrates the format of a <tlv-block> element. There
more) of TLVs, with total length of the TLVs (in octets) equal to the may be any number (zero or more) of TLVs, with total length of the
Length field. TLVs (in octets) equal to the Length field.
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 50, line 29 skipping to change at page 53, line 7
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| TLV | | TLV |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.6. TLV D.6. TLV
Possible options for the <tlv> element. These are differentiated by This section illustrates possible options for the <tlv> element.
their second (flags) octet. If there are no index fields then this These are differentiated by their second (flags) octet. If there are
may be a packet, message or address block TLV, if there are one or no Index fields, then this may be a Packet TLV, Message TLV, or
two index fields then this must be an address block TLV. The Length Address Block TLV; if there are one or two Index fields, then this
field gives the length of the value field (in octets). must be an Address Block TLV. The Length field gives the length of
the Value field (in 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |0|0|0|0|0|0|Rsv| | Type |0|0|0|0|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 55, line 35 skipping to change at page 57, line 35
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Appendix E. Complete Example Appendix E. Complete Example
The following example packet is included with the intent to exemplify The following example packet is included with the intent to exemplify
how packet and message headers are constructed, and how addresses and how Packet Headers and Message Headers are constructed, and how
attributes are encoded using address blocks and TLV blocks. This addresses and attributes are encoded using Address Blocks and TLV
example is specifically not constructed to exhibit maximum message or Blocks. This example is specifically not constructed to exhibit
packet size reduction. Appendix D contains illustrations of all maximum message or packet size reduction.
syntactical elements.
The packet header has the phasseqnum flag set of its flags field set The Packet Header has the phasseqnum flag of its flags field set
(value 8), and hence has a Packet Sequence Number, but no packet TLV (value 8), and hence has a Packet Sequence Number, but no Packet TLV
block. Block.
The packet contains a single message with length 54 octets. This The packet contains a single message with length 54 octets. This
message has the mhasorig, mhashoplimit, mhashopcount and mhasseqnum message has the mhasorig, mhashoplimit, mhashopcount, and mhasseqnum
flags of its four bit flags field set (value 15), and hence includes flags of its four-bit flags field set (value 15), and hence includes
an Originator Address, a Hop Limit, a Hop Count and a Message an Originator Address, a Hop Limit, a Hop Count, and a Message
Sequence Number (which is type independent). Its four bit message Sequence Number (which is type independent). Its four-bit Message
address length field has value 3 and hence addresses in the message Address Length field has value 3, and hence addresses in the message
have length four octets, here being IPv4 addresses. The message has have length four octets, here being IPv4 addresses. The message has
a message TLV block with content length 9 octets, containing a single a Message TLV Block with content length 9 octets, containing a single
message TLV. This TLV has the thasvalue flag of its flags octet set Message TLV. This TLV has the thasvalue flag of its flags octet set
(value 16), and hence contains a Value field, with preceding value (value 16), and hence contains a Value field, with preceding Value
length 6 octets. The message then has two address blocks each with a Length 6 octets. The message then has two Address Blocks, each with
following address TLV block. a following Address Block TLV Block.
The first address block contains 2 address prefixes. It has the The first Address Block contains 2 address prefixes. It has the
ahaszerotail and ahassingleprelen flags of its flags octet set (value ahaszerotail and ahassingleprelen flags of its flags octet set (value
48), and hence has no head (head-length is zero octets). It has a 48), and hence has no Head (head-length is zero octets). It has a
tail-length of 2 octets, hence mid-length is two octets. The two tail-length of 2 octets, hence mid-length is two octets. The two
tail octets of each address are not included (since ahaszerotail is Tail octets of each address are not included (since ahaszerotail is
set) and have value zero. The address block has a single Prefix set) and have value zero. The Address Block has a single prefix
Length. The following address TLV block is empty (content length 0 length. The following Address Block TLV Block is empty (content
octets). length 0 octets).
The second address block contains 3 addresses. It has the ahashead The second Address Block contains 3 addresses. It has the ahashead
flag of its flags octet set (value 128), and has head length 2 flag of its flags octet set (value 128), has head-length 2 octets,
octets, no tail (tail-length is zero octets) and hence mid-length is and no Tail (tail-length is zero octets); hence, mid-length is two
two octets. It is followed by an address TLV block, with content octets. It is followed by an Address Block TLV Block, with content
length 9 octets, containing two address block TLVs. The first of length 9 octets, containing two Address Block TLVs. The first of
these TLVs has the thasvalue flag of its flags octet set (value 16), these TLVs has the thasvalue flag of its flags octet set (value 16),
and has a single Value of length 2 octets, which applies to all of and has a single value of length 2 octets, which applies to all of
the addresses in the address block. The second of these TLVs has the the addresses in the Address Block. The second of these TLVs has the
thasmultiindex flag of its flags octet set (value 32), and hence has thasmultiindex flag of its flags octet set (value 32), and hence has
no value length or value fields. It has two index fields (Index no Value Length or Value fields. It has two Index fields (Index
Start and Index Stop), which indicate those addresses this TLV Start and Index Stop), which indicate those addresses this TLV
applies to (inclusive range, counting from zero). applies to (inclusive range, counting from zero).
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 1 0 0 0| Packet Sequence Number | Message Type | |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr | |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0| Orig Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 57, line 39 skipping to change at page 60, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0| | Mid (cont) | Mid |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0| |0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | TLV Type |0 0 1 0 0 0 0 0| | Value | TLV Type |0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index Start | Index Stop | | Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix F. Contributors
This specification is the result of the joint efforts of the
following contributors from the OLSRv2 Design Team, listed
alphabetically:
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org>
o Justin W. Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
Appendix G. Acknowledgments
The authors would like to acknowledge the team behind OLSR [RFC3626],
including Anis Laouiti (INT, France), Pascale Minet, Laurent Viennot
(both at INRIA, France), and Amir Qayyum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Elwyn
Davies (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
for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically):
o Brian Adamson (NRL)
o Teco Boot (Infinity Networks)
o Florent Brunneau (LIX)
o Ian Chakeres (Motorola)
o Alan Cullen (BAE Systems)
o Ulrich Herberg (LIX)
o Joe Macker (NRL)
o Yasunori Owada (Niigata University)
o Henning Rogge (FGAN)
o Charlie E. Perkins (WiChorus)
o Andreas Schjonhaug (LIX)
and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org EMail: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
Christopher M. Dearlove Christopher M. Dearlove
BAE Systems Advanced Technology Centre BAE Systems ATC
Phone: +44 1245 242194 Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Justin W. Dean Justin W. Dean
Naval Research Laboratory Naval Research Laboratory
Phone: +1 202 767 3397 Phone: +1 202 767 3397
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/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 242 change blocks. 
599 lines changed or deleted 599 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/