draft-ietf-manet-packetbb-01.txt   draft-ietf-manet-packetbb-02.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Expires: December 21, 2006 C. Dearlove Expires: January 29, 2007 C. Dearlove
BAE Systems Advanced Technology BAE Systems Advanced Technology
Centre Centre
J. Dean J. Dean
Naval Research Laboratory Naval Research Laboratory
C. Adjih C. Adjih
INRIA Rocquencourt INRIA Rocquencourt
June 19, 2006 July 28, 2006
Generalized MANET Packet/Message Format Generalized MANET Packet/Message Format
draft-ietf-manet-packetbb-01 draft-ietf-manet-packetbb-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006. This Internet-Draft will expire on January 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a generalized multi-message packet format This document specifies a multi-message packet format that may be
which may be used by mobile ad hoc network routing and other used by mobile ad hoc network routing and other protocols.
protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7
5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 7 5. Signaling Framework . . . . . . . . . . . . . . . . . . . . . 8
5.1. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 11
5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 14 5.3. TLVs and TLV Blocks . . . . . . . . . . . . . . . . . . . 12
5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 17 5.3.2. Constraints . . . . . . . . . . . . . . . . . . . . . 16
5.4. Message Content Fragmentation . . . . . . . . . . . . . . 17 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 20 6. TLV specification . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Message TLV Specification . . . . . . . . . . . . . . . . 20 6.1. Address Block TLV Specification . . . . . . . . . . . . . 17
6.2. Address Block TLV Specification . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Illustrations . . . . . . . . . . . . . . . . . . . 21
Appendix A. Packet and Message Layout . . . . . . . . . . . . . 26 Appendix A.1. Packet . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A.1. General Packet Format . . . . . . . . . . . . . . . 26 Appendix A.2. Message and Padding . . . . . . . . . . . . . . . . 23
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 38 Appendix A.3. Message Body . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Appendix A.4. Address Block . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix A.5. TLV Block . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Appendix A.6. TLV . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Complete Example . . . . . . . . . . . . . . . . . . 30
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 32
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
Signaling in a mobile ad hoc network routing protocol consists, Signaling in a MANET (mobile ad hoc network) routing protocol
mainly, of stating IP addresses and attributes associated to such IP consists, mainly, of stating IP addresses and attributes associated
addresses. Since this is a task common to many such protocols, this with such IP addresses. Since this is a task common to many such
specification presents a generalized signaling framework, which may protocols, this specification presents a generalized packet format,
be employed both by mobile ad hoc network routing protocols and other suitable for signaling. This format may be employed both by mobile
protocols with similar signaling requirements. ad hoc network routing protocols and by other protocols with similar
requirements.
The framework consists of a specification of: This document is a specification of a multi-message packet format.
Messages encapsulate protocol information (including addresses and
their attributes), and are themselves are encapsulated in packets.
The structure of addresses, attributes, messages, and packets is
specified via regular expressions. This specification gives the
syntax, but not the interpretation, of the information carried within
a packet, other than the header information which may be used to
control the dissemination of the messages. Packets are intended to
be encapsulated by a suitable transport protocol, typically UDP, and
carried over IP (IPv4 or IPv6).
o a mechanism whereby message types can be specified and (regardless This document specifies:
of type, whether known or unknown) can be correctly parsed and
forwarded;
o a generalized multi-message packet format, allowing multiple o A packet format, allowing zero or more messages to be contained
messages to be contained within a single transmission; within a single transmission, and optionally including a packet
header.
o a message format, composed of a message header and a message body, o A message format, where a message is composed of a message header
with the message header containing *all* necessary information to and a message body.
allow a node to make forwarding and processing decisions without
resorting to inspecting the message body. The message header
information permits single- and multi-hop diffusion whilst
supporting scope controlled multicast and unicast use of the
format;
o a message body structure, encouraging uniform message parsing, o A message header format containing *all* necessary information to
regardless of message body content; allow a node to make forwarding decisions without inspecting and
processing the message body. Message header information permits
single- and multi-hop message diffusion.
o a mechanism whereby addresses can be represented in a compact way o A message body format, containing attributes associated with the
(address compression); message or the originator of the message, as well as blocks of
addresses with associated attributes.
o an extensibility mechanism whereby arbitrary attributes, through o An address block format, where an address block represents sets of
TLVs (type-length-value triplets), can be included and associated addresses in a compact (compressed) form.
with a message, an address or a set of addresses, while being
correctly parseable by a generic message parser.
An important design criterion behind this specification is to allow o A generalized type-length-value (TLV) format representing
development of easy parsing logic, even in the face of a flexible attributes. Multiple TLVs can be included and associated with a
format. This implies that, given an incoming control message, a packet, a message, an address, or a set of addresses.
single parser is able to process the message independent of type and
present, to a protocol using this specification, an abstraction of The specification has been explicitly designed with the following
addresses with associated attributes directly. The information properties in mind:
contained in the message header furthermore allows the recipient node
to recognize duplicates and make appropriate forwarding decisions. Parsing logic - the regular expression specification facilitates
Additionally, the signaling framework in this specification is generic, protocol independent, parsing logic.
developed with the objective of minimizing the complexity of this
parser by providing a straightforward message layout. Extensibility - packets and messages defined by a protocol using this
specification are extensible through defining new message types
and new TLVs. Full backward compatibility can be maintained.
Efficiency - when reported addresses share common bit sequences (e.g.
prefixes or IPv6 interface identifiers) the address block
representation allows for a compact representation.
Separation of forwarding and processing - duplicate detection and
controlled scope message forwarding decisions can be made solely
using information contained in the message header, without
processing the message body.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1]. document are to be interpreted as described in RFC 2119. [1].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Packet - the top level entity in this specification. Packets are
transmitted hop-by-hop and are not forwarded. A packet contains
zero or more messages, and may contain a packet header.
Message - the fundamental entity carrying protocol information, in
the form of addresses and TLVs. Messages are transmitted in
packets, and may be forwarded based on their header information.
Address - an address of the same type and length as the source IP Address - an address of the same type and length as the source IP
address in the IP datagram carrying the packet. address in the IP datagram carrying the packet.
TLV - Type-Length-Value structure. This is a generic way in which an TLV - a Type-Length-Value structure. This is a generic way in which
attribute can be represented and correctly parsed, without knowing an attribute can be represented and correctly parsed, without the
the content, or understanding the type of the attribute by the parser having to understand the attribute.
parser. This allows internal extensibility, i.e. for a protocol
extension to add arbitrary attributes within a control message. element - a syntactic entity defined in the regular expression
specification, represented using the notation <foo>.
<foo> - if <foo> is an 8 or 16 bit field then <foo> is also used to
represent the value of that field.
? - zero or one occurrences of the preceding element. ? - zero or one occurrences of the preceding element.
* - zero or more occurrences of the preceding element. * - zero or more occurrences of the preceding element.
+ - one or more occurrences of the preceding element. + - one or more occurrences of the preceding element.
<foo> - An element specified in the parsing of a packet, message or bar - a variable, usually obtained through calculations based on the
other entity. If <foo> is an 8 or 16 bit field then <foo> is also
used to represent the value of that field.
bar - A variable, usually obtained through calculations based on the
value(s) of field(s). Variables are introduced in the value(s) of field(s). Variables are introduced in the
specification solely as a means to clarify the description. specification solely as a means to clarify the description.
address-length - A variable whose value is the length of an address address-length - a variable whose value is the length of an address
in octets, i.e. it is 4 if using IPv4, or 16 if using IPv6. in octets, it is 4 if using IPv4, 16 if using IPv6.
3. Applicability Statement 3. Applicability Statement
This specification describes a generic multi-message packet format, This specification describes a generic multi-message packet format,
for carrying MANET routing protocol signals. The specification has for carrying MANET routing protocol signals. The specification has
been developed from that used by OLSR [3]. been developed from that used by OLSR (The Optimized Link State
Routing Protocol) [4].
The specification is designed specifically with IP (IPv4/IPv6) in The specification is designed specifically with IP (IPv4/IPv6) in
mind. All addresses within a control message are assumed to be of mind. All addresses within a control message are assumed to be of
the same size, deduced from IP. In the case of mixed IPv6 and IPv4 the same size, deduced from IP. In the case of mixed IPv6 and IPv4
addresses, IPv4 addresses are carried in IPv6 as specified in [2]. addresses, IPv4 addresses are carried in IPv6 as specified in [2].
The packets defined by this specification may use any transport The packets defined by this specification may use any transport
protocol appropriate to the protocol using this specification. When protocol appropriate to the protocol using this specification. When
the diffusion mechanism enabled by this specification is employed, the diffusion mechanism enabled by this specification is employed,
UDP may be most appropriate. UDP may be most appropriate.
The multi-message package format in this specification is This specification is particularly appropriate for extensible
characterized by lending itself to low-complexity parsing logic, as protocols. It offers external extensibility in the form of new
well as to an efficient parsing for low-capacity routers. The header message types. It offers internal extensibility in the form of TLVs,
information in each message suffices to allow for each message to be which may be added to existing message types.
forwarded (if required) and delivered correctly with regards to the
message's delivery semantics, without parsing and inspecting the
message body.
The specification accommodates two types of extensibility: "external
extensibility", whereby new message types can be specified and
(regardless of type) still be correctly forwarded and parsed using
the simple parsing logic, and "internal extensibility", whereby new
attributes can be included in existing message types while these can
still be correctly forwarded and parsed using the simple parsing
logic.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
This specification does not describe a protocol. It describes a This specification does not describe a protocol. It describes a
packet format, which MAY be used by any mobile ad hoc network routing packet format, which may be used by any mobile ad hoc network routing
or other protocol. or other protocol.
5. Signaling Framework 5. Signaling Framework
This section provides abstract descriptions of message and packet This section provides syntactical specification of a packet,
formats. represented by the element <packet> and the elements from which it is
composed. The specification is given in the form of regular
expressions. Illustrations of specified elements are given in
Appendix A.
5.1. Packet Format The length of a <packet> is obtained as the size of the payload of
the transport protocol employed.
Messages are carried in a general packet format, allowing 5.1. Packets
piggybacking of several independent messages in a single packet
transmission.
The packet format conforms to the following specification: <packet> is defined by:
<packet> = {<packet-header><pad-octet>*}? <packet> = {<packet-header><pad-octet>*}?
{<message><pad-octet>*}* {<message><pad-octet>*}*
where <message> is defined in Section 5.2, and with <pad-octet> where <message> is defined in Section 5.2, and <pad-octet> is defined
conforming to the following specification: in Section 5.4. The packet is parsed until all octets are used.
<pad-octet> is an 8 bit field with all bits cleared ('0'). The use
of <pad-octet> is detailed in Section 5.1.1.
<packet-header> is defined by: <packet-header> is defined by:
<packet-header> = <zero> <packet-header> = <zero>
<packet-semantics> <packet-semantics>
<packet-seq-number>? <packet-seq-number>?
<tlv-block>? <tlv-block>?
with the elements of <packet-header> conforming to the following where:
specification:
<zero> is an 8 bit field with all bits cleared ('0'). This field <zero> is an 8 bit field with all bits cleared ('0'). This field
serves to identify if the packet starts with a packet header. serves to identify that the packet starts with a packet header.
<packet-semantics> is an 8 bit field, which specifies the composition <packet-semantics> is an 8 bit field, specifying the composition of
of the packet header: the packet header:
bit 0 (pseqnum) indicates, if cleared ('0'), that the packet bit 0 (pnoseqnum): if cleared ('0'), then the packet header
header contains a <packet-seq-number>. If set ('1'), the contains a <packet-seq-number>. If set ('1'), then the packet
packet header does not include a <packet-seq-number>. header does not include a <packet-seq-number>.
bit 1 (ptlv) indicates, if cleared ('0'), that the packet header bit 1 (ptlv): if cleared ('0'), then the packet header does not
does not include a TLV block. If set ('1'), the packet header include a TLV block. If set ('1'), then the packet header
includes a TLV block. includes a TLV block.
bits 2-7 are reserved, and SHOULD each be cleared ('0'). bits 2-7: are RESERVED, and MUST each be cleared ('0') to be in
conformance with this version of the specification.
<packet-seq-number> is omitted if the pseqnum bit is set ('1'), <packet-seq-number> is omitted if the pnoseqnum bit is set ('1'),
otherwise it is a 16 bit field, which specifies a packet sequence otherwise is a 16 bit field, specifying a packet sequence number.
number. If used, a separate packet sequence number MUST be
maintained for each transmitting interface. Each packet sequence
number MUST be incremented by one each time a packet, as defined
in this document and which includes the packet sequence number, is
transmitted over this interface.
<tlv-block> is omitted if the ptlv bit is cleared ('0'), otherwise it <tlv-block> is omitted if the ptlv bit is cleared ('0'), and is
is a TLV block as specified in Section 5.3. otherwise defined in Section 5.3.
Note that since the message type zero is reserved (see Section 7), Note that since the message type zero is reserved (see Section 7),
the presence or absence of a packet header can be determined by the presence or absence of a packet header can be determined by
inspecting the first octet of the packet. inspecting the first octet of the packet.
5.1.1. Padding
Packet headers and messages can be padded to ensure 32 bit alignment
of each message contained within the packet.
5.1.1.1. Packet Header Padding
The packet header specification in Section 5.1 ensures that a packet
header consists of an integral number of octets, with all defined
syntactical entities (<zero>, <packet-semantics>, <packet-seq-
number>, <tlv-block>) being octet-aligned.
The first <message> in a packet can be 32 bit aligned by adding the
appropriate number of <pad-octet>s subsequent to the <packet-header>.
The number of <pad-octet>s required to achieve this 32 bit alignment
is calculated as the smallest number which, when added to the size of
the packet header <tlv-block> (if any) and the size of the <packet-
seq-number> (if any) and the size of the fixed part of the header
(the <zero> and <packet-semantics> fields, which are each one octet
long) produces an integer multiple of 4.
If the <packet-header> contains a <packet-seq-number> and no <tlv-
block>, (i.e. if both the pseqnum and ptlv bits are cleared) then
there SHOULD NOT be any <pad-octets> subsequent to the <packet-
header>, since then the <packet-header> has length exactly 4 octets
and the first <message> is then already 32 bit aligned.
There is no need to indicate if padding is included subsequent to the
packet header: the first octet of a message (see Section 5.2 cannot
be zero. Thus, if after processing the packet header a recipient
reads an octet with all bits cleared ('0'), this read octet is
padding.
5.1.1.2. Message Padding
The message specification in Section 5.2 ensures that a message
consists of an integral number of octets, with all defined
syntactical entities (<msg-header>, <address-block>, <tlv> etc.)
being octet-aligned.
The first message can be 32 bit aligned by using packet header
padding, as described in Section 5.1.1.1. Subsequent messages (and,
hence, also the <originator-address>, if any), can be 32 bit aligned
by adding the appropriate number of <pad-octet>s subsequent to each
message. (When added to the last message this instead ensures that
the overall packet is a multiple of 32 bits in length.)
The number of <pad-octet>s required to achieve 32 bit alignment of
the end of message (and hence the start of the next, if any),
assuming that the start of the message is 32 bit aligned, is
calculated as the smallest number which when added to <msg-size>
produces a multiple of 4.
There is no need to indicate if padding is included subsequent to a
message: the first octet of a message (see Section 5.2) cannot be
zero. Thus if after processing a message a recipient reads any
octets with all bits cleared ('0'), these read octets are padding.
The <msg-size> does not include padding.
The padding after a message may be freely changed when a message is
forwarded without affecting the message.
5.2. Messages 5.2. Messages
Information is carried through "messages". Messages may contain: Information is carried through messages. Messages contain:
o zero or more TLVs, associated with the whole message;
o a set of addresses about which the originating node wishes to
convey information. These addresses MAY be divided into one or
more address blocks;
o zero or more TLVs following each address block. These are
explained in more detail in Section 5.3.1 and convey information
about the addresses in that address block.
A message also contains a message header, which can be parsed without
examining the remainder of the packet, and which contains information
sufficient to allow the recipient to:
o recognize duplicate messages; o A message header.
o determine considerations for forwarding; o A message TLV block that contains zero or more TLVs, associated
with the whole message.
o manage controlled-scope diffusion of messages. o Zero or more address blocks, each containing one or more
addresses.
Message content MAY (e.g. due to size limitations) be fragmented. o A TLV block, containing zero or more TLVs, following each address
Each fragment is transmitted such that it makes up a syntactically block.
correct message (i.e. all headers are set as if each fragment is a
message in its own right, and each message contains all necessary
message TLVs). Content fragmentation is detailed in Section 5.4.
A message has the following general layout: <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-semantics> <msg-semantics>
<msg-size> <msg-size>
<msg-header-info> <msg-header-info>
<msg-header-info> = <originator-address>? <msg-header-info> = <originator-address>?
<hop-limit>? <hop-limit>?
<hop-count>? <hop-count>?
<msg-seq-number>? <msg-seq-number>?
The elements of <msg-header-info> are included according to the flags where:
in <msg-semantics> as described below.
The elements used above conform to the following specification:
<tlv-block> is as specified in Section 5.3 <tlv-block> is defined in Section 5.3.
<addr-block> is a block of addresses, with which the originator of <addr-block> is defined in Section 5.2.1.
the message has a special relationship, specific to the protocol
using this specification. Address blocks are specified in
Section 5.2.1;
<msg-type> is an 8 bit field, which specifies the type of message. A <msg-type> is an 8 bit field, specifying the type of message. A type
type with all bits cleared ('0') MUST NOT be used. The two most with all bits cleared ('0') MUST NOT be used. The two most
significant bits are allocated with the following semantics: significant bits have the following semantics:
bit 7 (msg-user): message types with this bit cleared ('0') are bit 7 (msguser): message types with this bit cleared ('0') are
defined in this specification or can be allocated via standards defined in this specification or can be allocated via standards
action. Message types with this bit set ('1') are reserved for action. Message types with this bit set ('1') are reserved for
private/local use. private/local use.
bit 6 (msg-protocol): for message types with the msg-user bit bit 6 (msgprot): for message types with the msg-user bit cleared
cleared ('0'), this bit specifies, if cleared ('0'), that the ('0'), this bit specifies, if cleared ('0'), that the message
message type is protocol independent, i.e. is not specific to type is protocol independent, i.e. is not specific to any one
any one protocol, or, if set ('1'), that the message type is protocol, or, if set ('1'), that the message type is specific
specific to the protocol for which it is defined. to the protocol for which it is defined.
<msg-semantics> is an 8 bit field, which specifies the interpretation <msg-semantics> is an 8 bit field, specifying the interpretation of
of the remainder of the message header and the processing which the remainder of the message header:
can be undertaken only parsing the message header:
bit 0 (noorig): indicates, if cleared ('0') that the elements bit 0 (noorig): if cleared ('0'), then <originator-address> and
<originator-address> and <msg-seq-number> in the <msg-header- <msg-seq-number> are included in <msg-header-info>. If set
info> be included, as specified in the above. If set ('1'), a ('1'), then <originator-address> and <msg-seq-number> are not
reduced header which does not include <originator-address> and included in <msg-header-info>; this reduced message header does
<msg-seq-number> is used; this reduced header does not provide not provide for duplicate suppression.
provisions for duplicate suppression;
bit 1 (nohops): indicates, if cleared ('0') that the elements bit 1 (nohops): if cleared ('0'), then <hop-limit> and <hop-count>
<hop-limit> and <hop-count> in the <msg-header-info> be are included in the <msg-header-info>. If set ('1'), then
included, as specified in the above. If set ('1'), a reduced <hop-limit> and <hop-count> are not included in the <msg-
header which does not include the elements <hop-limit> <hop- header-info>; this reduced message header does not provide for
count> from the <msg-header-info> is used; this reduced header scope-delimited forwarding.
does not provide provisions for scope-delimited forwarding;
bit 2 (typedep): indicates, if cleared ('0'), that the message bit 2 (typedep): if cleared ('0'), then the message sequence
sequence number in the message is type-independent. If set number in the message is type-independent. If set ('1'), then
('1'), the message sequence number contained in the message is the message sequence number contained in the message is type
type dependent, i.e. the source of the message maintains a dependent (the message originator maintains a sequence number
sequence number separately for the type indicated in the <msg- specific to <msg-type>). This bit MUST be cleared ('0') if the
type> field; this bit SHALL be cleared ('0') if there is no noorig bit is set ('1').
message sequence number, i.e. if the noorig bit is set;
bits 3-7: are RESERVED and SHALL each be cleared ('0') to be in bits 3-7: are RESERVED and MUST each be cleared ('0') to be in
conformance with this version of the specification. conformance with this version of the specification.
<msg-size> is a 16 bit field, which specifies the size of the <msg- <msg-size> is a 16 bit field, specifying the size of the <message>,
header> and the following <msg-body>, counted in octets; counted in octets.
<originator-address> is the address of an interface of the node, <originator-address> is an identifier of length equal to address-
which originated the message. Its length is equal to address- length, which serves to uniquely identify the node that originated
length octets. Each node SHOULD select one of its interface the message.
addresses as its "originator address" and MUST utilize this
address consistently as the <originator address> in all messages
it generates which include this field. Note that the originator
address is distinct from the IP source address, and that the same
originator address MUST be used regardless of which interface a
message is transmitted on. Also note that if a message is
retransmitted the originator address MUST NOT be changed;
<hop-limit> is an 8 bit field, which contains the maximum number of <hop-limit> is an 8 bit field, which contains the maximum number of
hops a message will be transmitted. Before a message is hops a message should be further transmitted.
retransmitted, the hop-limit MUST be decremented by 1. When a
node receives a message with a hop-limit equal to 0 or 1, the
message MUST NOT be retransmitted under any circumstances.
Normally, a node will not receive a message with a hop-limit of 0
(note that this hop-limit is distinct from the IPv6 hop-limit);
<hop-count> is an 8 bit field, which contains the number of hops a <hop-count> is an 8 bit field, which contains the number of hops a
message has traveled. Before a message is retransmitted, the hop- message has traveled.
count MUST be incremented by 1. Initially, this hop-count SHOULD
be set to 0 by the originator of the message;
<msg-seq-number> is a 16 bit field, which contains a unique number, <msg-seq-number> is a 16 bit field, which contains a unique number,
generated by the originator node. The originator-address, msg- generated by the originator node. The <originator-address>, <msg-
seq-number and, if the typedep bit in the <msg-semantics> field is seq-number>, and, if the typedep bit in the <msg-semantics> field
set, the <msg-type> of a message serves to uniquely identify the is set, the <msg-type> of a message serves to uniquely identify
message in the network (allowing, among other things, duplicate the message in the network.
elimination).
5.2.1. Address Blocks 5.2.1. Address Blocks
An address block represents a set of addresses in a compact and An address is specified as a sequence of octets of the form head:mid:
simple form. Assuming that an address can be specified as a sequence tail. An address block is an ordered set of addresses sharing the
of bits of the form 'head:mid:tail', then an address block is a set same head and tail, and having individual mids.
of addresses sharing the same 'head' and 'tail' and having different
'mids'. (The case where the 'tail' is empty is treated specially, as
is the case where the 'tail' consists of zero-valued octets, the
latter is particularly appropriate when used with a TLV indicating a
prefix length, see Section 6.2.)
Specifically, an address block conforms to the following <address block> is defined by:
specification:
<address-block> = <num-addr> <address-block> = <num-addr>
<head-octet> <head-octet>
<head>? <head>?
<tail-octet>? <tail-octet>?
<tail>? <tail>?
<mid>* <mid>*
with the elements defined thus: where:
<num-addr> is an 8 bit field containing the number of addresses <num-addr> is an 8 bit field containing the number of addresses
represented in the address block, which MUST NOT be zero. It is represented in the address block, which MUST NOT be zero.
equal to the number of <mid>s following (except when, as defined
below, mid-length == 0 and no <mid>s are required);
<head-octet> is an 8 bit field, where: <head-octet> is an 8 bit field, where:
bits 0-6: contain the length of the <head>, if any. The bits 0-6: contain the length of the head. The corresponding
corresponding variable head-length is calculated by: variable head-length is calculated by:
head-length = <head-octet> & 127 head-length = <head-octet> & 127
bit 7 (notail): indicates, if cleared ('0'), that the address bit 7 (notail): if cleared ('0') then the address block contains a
block contains a <tail-octet> (see below), if set ('1') that no <tail-octet>. If set ('1') then no <tail-octet> is included.
<tail-octet> is included;
<head> is omitted if head-length == 0, otherwise it is a field of <head> is omitted if head-length == 0, otherwise it is a field of the
head-length octets which contains the leftmost octets which the head-length leftmost octets of all the addresses.
addresses in the block have in common (it SHOULD contain the
longest such sequence);
<tail-octet> is omitted if the notail bit is set ('1'), otherwise it <tail-octet> is omitted if the notail bit is set ('1'), otherwise it
is an 8 bit field, where: is an 8 bit field, where:
bits 0-6: contain the length of the <tail>, if any, or the bits 0-6: contain the length of the tail. The corresponding
equivalent number of zero-valued tail octets. The variable tail-length is calculated by:
corresponding variable tail-length is calculated by:
tail-length = <tail-octet> & 127 tail-length = <tail-octet> & 127
bit 7 (zerotail): indicates, if cleared ('0'), that a <tail> (see bit 7 (zerotail): if cleared ('0'), then a <tail> is included. If
below) is included, if set ('1') that no <tail> is included, set ('1') then no <tail> is included, and the tail-length
and that the tail-length rightmost octets of each address in rightmost octets of each address in the block are zero-valued.
the block are zero-valued;
If the <tail-octet> is omitted then tail-length = 0. If the <tail-octet> is omitted then tail-length = 0.
<tail> is omitted if tail-length == 0 or the zerotail bit is set <tail> is omitted if tail-length == 0 or the zerotail bit is set
('1'), otherwise it is a field of length tail-length octets which ('1'), otherwise it is a field of the head-length leftmost octets
contains the rightmost octets which the addresses in the block of all the addresses.
have in common (it SHOULD contain the longest such sequence in
this case);
If tail-length != 0 and the zerotail bit is set ('1') then all the mid-length is a variable, which MUST be non-negative, calculated by:
addresses in the block have tail-length zero-valued rightmost
octets (tail-length SHOULD be the largest such number in this
case);
mid-length is a variable, calculated by:
mid-length = address-length - head-length - tail-length mid-length = address-length - head-length - tail-length
mid-length MUST be non-negative. <mid> is omitted if mid-length == 0, otherwise each <mid> is a field
of length mid-length octets, representing the mid of the
<mid> is omitted if mid-length == 0 (in which case all addresses in corresponding address in the address block.
the block are the same), otherwise each <mid> is a field of length
mid-length octets, representing the 'mid' of the corresponding
address in the address block.
This representation aims at providing a flexible, yet compact, way of
representing sets of addresses.
5.3. TLVs and TLV Blocks 5.3. TLVs and TLV Blocks
A TLV block has the following general layout: A TLV is defined by:
<tlv-block> = <tlv-length> <tlv-block> = <tlv-length>
<tlv>* <tlv>*
with the elements defined thus: where:
<tlv-length> is a 16 bit field, which contains the total length (in <tlv-length> is a 16 bit field, which contains the total length (in
octets) of the immediately following TLV(s). It does not include octets) of the immediately following <tlv>s.
its own length, thus if no TLVs follow, this field contains zero;
<tlv> is a TLV, providing information regarding the entire packet or <tlv> is defined in Section 5.3.1.
message or the address block which it follows. TLVs are specified
in Section 5.3.1;
5.3.1. TLVs 5.3.1. TLVs
A TLV is a carrier of information, relative to a packet, to a message There are three kinds of TLV, each represented by an element <tlv>:
or to addresses in an address block.
A TLV associated with an address block specifies some attribute(s), o A packet TLV, included in a packet header.
which are associated with address(es) in the address-block. In order
to provide the largest amount of flexibility to benefit from address
aggregation as described in Section 5.2.1, a TLV associated to an
address block can apply to:
o all addresses in the address block; o A message TLV, included in a message before all address blocks.
o any continuous sequence of addresses in the address block; o An address block TLV, included in a TLV block following an address
block. An address block TLV applies to:
o a single address in the address block. * all addresses in the address block; OR
All TLVs conform to the following specification: * any continuous sequence of addresses in the address block; OR
* a single address in the address block.
<tlv> is defined by:
<tlv> = <tlv-type> <tlv> = <tlv-type>
<tlv-semantics> <tlv-semantics>
<index-start>? <index-start>?
<index-stop>? <index-stop>?
<length>? <length>?
<value>? <value>?
where the elements are defined thus: where:
<tlv-type> is an 8 bit field, which specifies the type of the TLV. <tlv-type> is an 8 bit field, specifying the type of the TLV. The
The two most significant bits are allocated with the following two most significant bits have the following semantics:
semantics:
bit 7 (tlv-user): TLV types with this bit cleared ('0') are bit 7 (tlvuser): TLV types with this bit cleared ('0') are defined
defined in this specification or can be allocated via standards in this specification or can be allocated via standards action.
action. TLV types with this bit set ('1') are reserved for TLV types with this bit set ('1') are reserved for private/
private/local use. local use.
bit 6 (msg-protocol): for TLV types with the tlv-user bit cleared bit 6 (tlvprot): for TLV types with the tlv-user bit cleared
('0'), this bit specifies, if cleared ('0'), that the TLV type ('0'), this bit specifies, if cleared ('0'), that the TLV type
is protocol independent, i.e. is not specific to any one is protocol independent, i.e. is not specific to any one
protocol, or, if set ('1'), that the TLV type is specific to protocol, or, if set ('1'), that the TLV type is specific to
the protocol for which it is defined. the protocol for which it is defined.
<tlv-semantics> is an 8 bit field which specifies the semantics of <tlv-semantics> is an 8 bit field specifying the interpretation of
the TLV according to the following: the remainder of the TLV:
bit 0 (novalue): if cleared ('0') contains <length> and <value>
elements. TLVs with this bit set ('1') contains no <length> or
<value> elements - the TLV type carries all the information
needed.
bit 1 (extended): if cleared ('0'), the size of the length field bit 0 (extended) and bit 1 (novalue): must not both be set ('1').
is 8 bits. If set ('1'), the size of the length field is 16 Otherwise, they are interpreted according to Table 1.
bits. This bit MUST be cleared ('0') if the novalue bit is set
('1').
bit 2 (noindex): if cleared ('0'), the <index-start> and <index- +----------+---------+--------------+--------------+
stop> elements are included. If set ('1'), the <index-start> | extended | novalue | length | value |
and <index-stop> elements are not included. This bit MUST be +----------+---------+--------------+--------------+
set for packet or message TLVs. If this bit is set ('1') for | 0 | 0 | 8 bits | included |
address block TLVs, the TLV applies to all addresses in the | | | | |
address block. | 0 | 1 | not included | not included |
| | | | |
| 1 | 0 | 16 bits | included |
+----------+---------+--------------+--------------+
bit 3 (multivalue): if cleared ('0'), the TLV includes a single Table 1
value which applies to all addresses described by <index-start>
and <index-stop>. If set ('1'), the TLV includes separate
values for each of the addresses indicated by <index-start> and
<index-stop>. This bit MUST be cleared ('0') for packet or
message TLVs or if the novalue bit is set ('1').
bits 4-7: are RESERVED and SHALL each be cleared ('0'). bit 2 (noindex) and bit 3 (singleindex): must not both be set
('1'). Otherwise, they are interpreted according to Table 2.
<index-start> is omitted if the noindex bit is set ('1'), otherwise +---------+-------------+---------------+--------------+
it is an 8 bit field. In the former case, the variable index- | noindex | singleindex | <index-start> | <index-stop> |
start is defined by: +---------+-------------+---------------+--------------+
| 0 | 0 | included | included |
| | | | |
| 0 | 1 | included | not included |
| | | | |
| 1 | 0 | not included | not included |
+---------+-------------+---------------+--------------+
index-start = <index-start> Table 2
in the latter case, the variable index-start is defined by: bit 4 (multivalue): this bit serves to specify how the value field
is interpreted as specified below. This bit MUST be cleared
('0') for packet or message TLVs, if the singleindex bit is set
('1'), or if the novalue bit is set ('1').
index-start = 0 bits 5-7: are RESERVED and MUST each be cleared ('0') to be in
accordance with this version of the specification.
If this TLV is associated with an address block then index-start <index-start> and <index-stop> are each an 8 bit field, interpreted
specifies the index of the first address in the address block as follows:
(starting at zero) for which this TLV applies;
<index-stop> is omitted if the noindex bit is set ('1'), otherwise it index-start and index-stop are variables, defined according to
is an 8 bit field. In the former case, the variable index-stop is Table 3. The variable end-index is calculated as follows:
defined by:
index-stop = <index-stop> + For message and packet TLVs:
in the latter case, for a TLV associated with an address block - end-index = 0
with <num-addr> addresses the variable index-stop is defined by: + For address block TLVs:
index-stop = <num-addr> - 1 - end-index = <num-addr> - 1
otherwise (a TLV associated with a packet or a message) the +---------+-------------+---------------+---------------+
variable index-stop is defined by: | noindex | singleindex | index-start = | index-stop = |
+---------+-------------+---------------+---------------+
| 0 | 0 | <index-start> | <index-stop> |
| | | | |
| 0 | 1 | <index-start> | <index-start> |
| | | | |
| 1 | 0 | 0 | end-index |
+---------+-------------+---------------+---------------+
index-stop = 0 Table 3
If this TLV is associated with an address block then index-stop For an address block TLV, the TLV applies to the addresses from
specifies the index of the last address in the address block position index-start to position index-stop (inclusive) in the
(starting at zero) for which this TLV applies. address block.
number-values is a variable, defined by number-values is a variable, calculated by:
number-values = <index-stop> - <index-start> + 1
If this TLV is associated with an address block then number-values number-values = index-stop - index-start + 1
is the number of addresses in that block to which this TLV
applies, otherwise it is 1.
<length> is omitted if the novalue bit is set ('1'), otherwise it is <length> is omitted or is a 8 or 16 bit field according to Table 1.
an 8 bit or 16 bit field, according to whether the extended bit is If the multivalue bit is set ('1') then <length> MUST be an
cleared ('0') or set ('1'), respectively. If present this field integral multiple of number-values, and the variable single-length
specifies the length, counted in octets, of the data contained in is calculated by:
<value>. If the multivalue bit is set ('1') then <length> MUST be
an integral multiple of number-values and the variable single-
length is defined by
single-length = <length> / number-values single-length = <length> / number-values
otherwise, if the multivalue bit is cleared ('0'), the variable if the multivalue bit is cleared ('0'), the variable single-length
single-length is defined by is defined by:
single-length = <length> single-length = <length>
<value> is omitted if the novalue bit is set ('1'), Otherwise it is a <value> if present (see Table 1), this is a field of length <length>
field of length <length> octets. If the multivalue bit is cleared octets. In an address block TLV, <value> is associated with the
('0') then this field is associated with the packet, message or addresses from index-start to index-stop, inclusive. If the
the relevant addresses (from index-start to index-stop) in the multivalue bit is cleared ('0') then the whole of this field is
address block with which this TLV is associated, as appropriate. associated with each of the indicated addresses. If the
If the multivalue bit is set ('1') then this field is divided multivalue bit is set ('1') then this field is divided equally
equally into number-values fields, each of length single-length into number-values fields, each of length single-length octets and
octets and these are associated, in order, to the relevant these are associated, in order, with the indicated addresses.
addresses (from index-start to index-stop) in the address block
with which this TLV is associated. The association is interpreted
according to the <tlv-type> field.
5.3.2. Constraints 5.3.2. Constraints
TLVs in the same <tlv-block> SHALL be sorted in ascending TLV type TLVs in the same tlv block MUST be sorted in ascending TLV type
order. order.
Two or more TLVs of the same type associated with the same <addr- Two or more TLVs of the same type associated with the same address
block> SHALL NOT both cover any index (address). block MUST NOT both cover any address.
TLVs of the same type associated with the same <addr-block> SHALL be
sorted in ascending <index-start> order.
5.4. Message Content Fragmentation
A message may be larger than is desirable to include, with the
packet, message and other headers (transport, IP), in a MAC frame.
In this case the message SHOULD be fragmented. Only the originator
of a message may decide to fragment a message. When a message is
fragmented it MUST be assigned a content sequence number by the
originator. A content sequence number may also be assigned for
reasons other than fragmentation.
A content sequence number may be specific to the type of the message
or not. If the content sequence number is to be used for
fragmentation then this is indicated as specified in Section 6.1.
Two messages with the same originator and, when the content sequence
number is type-specific, with the same type, with different message
bodies SHALL NOT be assigned the same content sequence number. Two
messages with the same originator and the same message body MAY be
assigned the same content sequence number, with the same type-
dependence, in which case they MUST be fragmented identically.
A fragment of a message may have one of two forms:
o the fragment is a "partially or wholly self-contained message" and
may, thus, be parsed and processed immediately by the recipient.
Additional processing MAY be necessary when all fragments are
received;
o the fragment is not a "partially or wholly self-contained message"
and may, thus, not be processed until all fragments of the message
have been received.
Regardless of under which of the above forms a message is fragmented,
each fragment MUST be a complete message as defined in this
specification, i.e. MUST contain syntactically correct address
blocks and TLVs. Furthermore, all fragments of a given message MUST
be of the same type, and have the same fragmentation semantics, see
Section 6.1.
If a message is fragmented, each fragment MUST contain the following
TLVs, defined in Section 6.1:
o a message TLV with type FRAGMENTATION, specifying the number of
fragments, the fragment number (counting from zero), if the
fragment is a partially or wholly self-contained message, and if
the CONTENT-SEQ-NUMBER generated by the originator of the
fragmented message is specific to the type of the fragmented
message or not;
o a message TLV with type CONTENT-SEQ-NUMBER, specifying the content TLVs of the same type associated with the same address block MUST be
sequence number associated with the information in the fragment. sorted in ascending index-start order.
If the content sequence number included in the CONTENT-SEQ-NUMBER TLV 5.4. Padding
of a message is specific to the type of the message then the
originating node MUST maintain a content sequence number for that
message type and MUST increment it when it originates a new message
of that type, but not of any other type. A node MAY maintain such
type-specific content sequence numbers for any number of types.
If the content sequence number included in the CONTENT-SEQ-NUMBER TLV Packet headers and messages can be padded to ensure 32 bit alignment
of a message is not specific to the type of the message then the of each message contained within the packet and of the overall packet
originating node MUST maintain a single content sequence number for length.
those message type for which a content sequence number is required,
but for which the node does not maintain a type-specific content
sequence number. The node MUST increment this single content
sequence number when it originates a new message of any relevant
type, but not of any other types (either those for which a content
sequence number is not appropriate, or for which a type-specific
content sequence number is maintained.)
Since FRAGMENTATION is defined to be TLV type zero (see Section 6.1), All syntactical elements are an integer multiple of octets, hence
it can be determined if a message is fragmented by inspecting the padding can be accomplished by inserting an integer number of <pad-
first three octets of the message body (the first three octets after octets> after the syntactical element that is to be 32 bit aligned.
the message header):
o if the first two octets (the message TLV block length) are both The number of <pad-octet>s required to achieve this 32 bit alignment
zero then the message is not a fragment; is calculated as the smallest number (0 to 3) that, when added to the
size of the preceding elements produces an integer multiple of 4.
o otherwise if the third octet (the first message TLV type) is zero <pad-octet> is an 8 bit field with all bits cleared ('0').
then the message is a fragment;
o otherwise the message is not a fragment. There is no need to indicate if padding is included, since a <pad-
octet> will always precede either a message or the end of the packet.
In the former case, the start of a message is indicated by the next
non-zero octet parsed.
A message SHOULD NOT be sent with a message TLV with type The padding after a message may be freely changed when a message is
FRAGMENTATION indicating "fragment zero of one". forwarded without affecting the message.
6. TLV specification 6. TLV specification
This document specifies two message TLVs, which are required in the This document specifies one address block TLV, which is included to
case of message fragmentation, and one address block TLV. The allow a standardized way of representing network addresses.
address block TLV is included to allow a standardized way of
representing network addresses, with a prefix length, in control
messages.
6.1. Message TLV Specification
Message TLV Specification Overview
+----------------------+------+--------+----------------------------+
| Name | Type | Length | Value |
+----------------------+------+--------+----------------------------+
| FRAGMENTATION | 0 | 24 | See Table 2 below. |
| | | bits | |
| | | | |
| CONT_SEQ_NUM | 1 | 16 | A sequence number, |
| | | bits | associated with the |
| | | | content of the message |
+----------------------+------+--------+----------------------------+
Table 1
The fragmentation TLV contains the following fields in the following
order:
FRAGMENTATION TLV Value Specification Overview
+-------------+----------------------------------------------------+
| Field Width | Value |
+-------------+----------------------------------------------------+
| 8 bits | Number of fragments |
| | |
| 8 bits | Fragment number |
| | |
| 8 bits | Fragmentation semantics bit vector. |
+-------------+----------------------------------------------------+
Table 2
The bits in the fragmentation semantics bit vector are defined as
follows:
bit 0 (notselfcont): indicates, if cleared ('0') that the message TLV
is a partially or wholly self-contained message, or if set ('1')
that the message TLV is not a partially or wholly self-contained
message.
bit 1 (typedepseq): indicates, if cleared ('0') that the originator
maintains a single sequence number for fragmented messages of
types including the type of this message, and that this is
included in the CONTENT-SEQ-NUMBER TLV. If set ('1'), the
originator node maintains a separate sequence number for the type
of this message, and that the sequence number in the CONTENT-SEQ-
NUMBER TLV is the sequence number corresponding to the type of
this message.
bits 2-7: are RESERVED and SHALL each be cleared ('0').
6.2. Address Block TLV Specification
The following address block TLV is provided for general use, and is
included in this specification since it complements the address
representation by providing a way of representing a network address
in a message.
Address Block TLV Specification Overview 6.1. Address Block TLV Specification
+----------------------+------+--------+----------------------------+ +----------------------+------+--------+----------------------------+
| Name | Type | Length | Value | | Name | Type | Length | Value |
+----------------------+------+--------+----------------------------+ +----------------------+------+--------+----------------------------+
| PREFIX_LENGTH | 0 | 8 bits | Indicates that the address | | PREFIX_LENGTH | 0 | 8 bits | Indicates that the address |
| | | | is a network address, | | | | | is a network address, |
| | | | rather than a host | | | | | rather than a host |
| | | | address. The value is the | | | | | address. The value is the |
| | | | length of the | | | | | length of the |
| | | | netmask/prefix. | | | | | prefix/netmask. |
+----------------------+------+--------+----------------------------+ +----------------------+------+--------+----------------------------+
Table 3 Table 4
An address in an address block without an associated PREFIX_LENGTH An address in an address block without an associated PREFIX_LENGTH
TLV may be considered to have a prefix length equal to the address TLV may be considered to have a prefix length equal to the address
length (in bits). length (in bits).
7. IANA Considerations 7. IANA Considerations
The message format in this specification defines a message "type"
field, as well as two TLV types for message TLVs and address block
TLVs respectively.
A new registry for message types must be created with initial A new registry for message types must be created with initial
assignments as specified in Table 4. assignments as specified in Table 5. Future values in the range
5-127 of the Message Type can be allocated using standards action
[3]. Additionally, values in the range 128-255 are reserved for
private/local use.
A new registry for packet TLV types must be created, with no initial A new registry for packet TLV types must be created, with no initial
assignments. assignments. Future values in the range 0-127 of the Message Type
can be allocated using standards action [3]. Additionally, values in
the range 128-255 are reserved for private/local use.
A new registry for message TLV types must be created with initial A new registry for message TLV types must be created with no initial
assignments as specified in Table 5. assignments. Future values in the range 0-127 of the Message Type
can be allocated using standards action [3]. Additionally, values in
the range 128-255 are reserved for private/local use.
A new registry for address block TLV types must be created with A new registry for address block TLV types must be created with
initial assignments as specified in Table 6. initial assignments as specified in Table 6. Future values in the
range 1-127 of the Message Type can be allocated using standards
Assigned Message Types action [3]. Additionally, values in the range 128-255 are reserved
for private/local use.
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| RESERVED | 0 | At start of packet signals that what |
| | | follows is a packet header, rather |
| | | than a message header, and to allow |
| | | packet header and message padding |
| | | with zero octets |
| | | |
| RESERVED | 1 | |
| | | |
| RESERVED | 2 | |
| | | |
| RESERVED | 3 | |
| | | |
| RESERVED | 4 | |
+--------------------+-------+--------------------------------------+
Table 4
Message types 1 to 4 are reserved because they are used by OLSRv1 [3]
which uses a compatible packet/message header format.
Assigned Message TLV Types
+--------------------+-------+--------------------------------------+ +-------+----------------------------------------+
| Mnemonic | Value | Description | | Value | Description |
+--------------------+-------+--------------------------------------+ +-------+----------------------------------------+
| FRAGMENTATION | 0 | Specifies behavior in case of | | 0 | MUST NOT be allocated. |
| | | content fragmentation | | | |
| | | | | 1-4 | RESERVED |
| CONT_SEQ_NUM | 1 | A sequence number, associated with | +-------+----------------------------------------+
| | | the content of the message |
+--------------------+-------+--------------------------------------+
Table 5 Table 5
Assigned Address Block TLV Types Message type 0 MUST NOT be allocated because a zero-octet signifies a
packet header and zero-octets are used for padding. Message types 1
to 4 are reserved because they are used by OLSR [4], which uses a
compatible packet/message header format.
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
| PREFIX_LENGTH | 0 | Indicates that associated addresses | | PREFIX_LENGTH | 0 | Indicates that associated addresses |
| | | are network addresses, with given | | | | are network addresses, with given |
| | | prefix length | | | | prefix length. |
+--------------------+-------+--------------------------------------+ +--------------------+-------+--------------------------------------+
Table 6 Table 6
8. Security Considerations 8. Security Considerations
Packets are designed to be transmitted only one hop, and not Packets are designed to be transmitted only one hop, and not
forwarded. Thus, hop-by-hop packet level security MAY be forwarded. Hop-by-hop packet level security MAY be implemented,
implemented, between nodes with an existing security association, between nodes with an existing security association, by including a
through including suitable packet TLV(s) containing a cryptographic suitable packet TLV containing a cryptographic signature to the
signature to the packet. Since packets are received as transmitted, packet. Since packets are received as transmitted, signatures can be
signatures can be calculated based on the entire packet content calculated based on the entire packet content, or on parts thereof as
(including message and packet headers), or on parts thereof as
appropriate. appropriate.
The messages contained in a packet are available at each hop, and Messages at each hop MAY be forwarded and/or processed, according to
MAY, according to the information in the message header, and the the information in the message header and the protocol employing this
protocol employing this specification, be forwarded and/or processed. specification. With immutable messages, end-to-end security MAY be
If a message is to be forwarded, the <hop-count> and <hop-limit> implemented, between nodes with an existing security association, by
fields in the message header, if present, SHOULD be modified. All including a suitable message TLV containing a cryptographic signature
other message header fields, and the message body, MAY, depending on to the message. Since <hop-count> and <hop-limit> are the only
the protocol employing this specification, be left intact. fields that may be modified when such a message is forwarded,
signatures can be calculated based on the entire message, including
Such a protocol (using immutable messages, other than the indicated the message header with the <hop-count> and <hop-limit> fields set to
fields) using this message format MAY, between nodes with an existing zero ('0').
security association, implement end-to-end message security by
including suitable message TLV(s) containing a cryptographic
signature to the message. This signature can be calculated based on
the entire message, including the message header, with the provision
that the <hop-count> and <hop-limit> fields MUST, if present, both be
set to zero ('0') for both calculation and verification of the
signature.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
9.2. Informative References 9.2. Informative References
[3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
Appendix A. Packet and Message Layout Appendix A. Illustrations
This section specifies the translation from the abstract descriptions This informative appendix illustrates the elements, which are
of packets employed in the protocol specification, and the bit-layout normatively specified in Section 5 using regular expressions.
packets actually exchanged between the nodes.
Appendix A.1. General Packet Format Bits labeled Reserved or Resv are cleared ('0'). Bits labeled N and
M may be cleared ('0') or set ('1'). Octets labeled Padding are
cleared ('0'), and are optional.
The basic layout of a packet (excluding transport and IP headers) Appendix A.1. Packet
SHALL be one of the following five options.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |0|1| Padding | |0 0 0 0 0 0 0 0| Reserved |0|1| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number | |0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
skipping to change at page 27, line 48 skipping to change at page 22, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |1|1| | |0 0 0 0 0 0 0 0| Reserved |1|1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Packet TLV Block | | Packet TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
skipping to change at page 28, line 27 skipping to change at page 23, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
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 + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message + Padding | | Message + Padding |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that in the first four cases the Reserved bits SHOULD be zero, Appendix A.2. Message and Padding
whilst in the last case the first octet MUST NOT be zero (this is
used to recognise this case). In all cases where they are present,
the octets indicated as Padding are optional and MAY be omitted. If
not omitted they SHOULD be used to pad to a 32 bit boundary and MUST
all be zero.
The basic layout of a message, plus padding, SHALL be one of the
following four options.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|0|0| Message Size | | Message Type | Resv |N|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|0|1| Message Size | | Message Type | Resv |0|0|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | | | Hop Limit | Hop Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|1|0| Message Size | | Message Type | Resv |N|1|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Sequence Number | | | Message Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|1|1| Message Size | | Message Type | Resv |0|1|1| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Body | | Message Body |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved bits marked Resv SHOULD be zero. The N bit is set ('1') Appendix A.3. Message Body
if the message sequence number is type-dependent, or cleared ('0') if
the message sequence number is type-independent. The octets
indicated as Padding are optional and MAY be omitted. If not omitted
they SHOULD be used to pad to a 32 bit boundary and MUST all be zero;
they are not included in the message size.
The basic layout of a message body SHALL be as follows.
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 |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
skipping to change at page 31, line 43 skipping to change at page 26, line 5
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Address TLV Block | | Address TLV Block |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The basic layout of an address block SHALL be one of the following Appendix A.4. Address Block
three options.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |0| Head Length | Head | | Number Addrs |0| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1| Head Length | Head |0| Tail Length | | Number Addrs |1| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail | Mid | | |0| Tail Length | Tail | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | |
+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Addrs |1| Head Length | Head |1| Tail Length | | Number Addrs |1| Head Length | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | | |1| Tail Length | Mid | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
: ... : : ... :
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Mid | | | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of each Mid section is equal to the address length minus
the Head Length and the Tail Length. In the first case there is no
Tail section, the Mid sections are actually tail sections. In the
third case the tail section is not included, it is all octets zero.
The basic layout of a TLV block (packet TLV block, message TLV block Appendix A.5. TLV Block
or address TLV block) SHALL be as follows.
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 33, line 48 skipping to change at page 27, line 29
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| TLV | | TLV |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length is of the TLV block contents, it does not include itself Appendix A.6. TLV
(hence if there are no TLVs then Length is zero).
The basic layout of a TLV SHALL be one of the following six options.
A packet TLV or message TLV SHALL be one of the last three options
only.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |M|0|0|0| Index Start | Index Stop | | Type |Resv |M|0|0|0|0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |0|0|0|1| Index Start | Index Stop | | Type |Resv |0|0|0|0|1| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |M|0|1|0| Index Start | Index Stop | | Type |Resv |M|0|0|1|0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| |
| Value | | Value |
| | | |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |M|1|0|0| Length | | | Type |Resv |M|0|1|0|0| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |0|1|0|1| | Type |Resv |0|0|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |M|1|1|0| Length | | Type |Resv |M|0|1|1|0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |0|1|0|0|0| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Value | | Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |0|1|0|0|1| Index Start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Resv |0|1|0|1|0| Index Start | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (cont) | |
+-+-+-+-+-+-+-+-+ |
| |
| Value |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
M denotes the multivalue bit in those cases when it may be set ('1') Appendix B. Complete Example
or cleared ('0'). In the cases where it MUST be cleared ('0') it is
shown thus; it MUST also be cleared ('0') in a packet TLV or message
TLV.) The reserved bits marked Resv SHOULD also be zero.
An example packet, using IPv4 addresses (length four octets) is An example packet, using IPv4 addresses (length four octets) is
shown. This packet has a header, with a packet sequence number but shown. This packet has a header, with a packet sequence number but
no packet TLV block, and contains a single unfragmented message. The no packet TLV block, and contains a single unfragmented message. The
message has a complete message header, a message TLV block of content message has a complete message header, a message TLV block of content
length 9 octets containing a single TLV (with the noindex bit of its length 9 octets containing a single TLV (with the noindex bit of its
semantics set and value length 6 octets) and then two address blocks semantics set and value length 6 octets) and then two address blocks
each with a following TLV block. The first address block contains 3 each with a following TLV block. The first address block contains 3
addresses (head length 2 octets, no tail, hence mid length two addresses (head length 2 octets, no tail, hence mid length two
octets) and is followed by a TLV block of content length 9 octets octets) and is followed by a TLV block of content length 9 octets
containing two TLVs. The first of these TLVs has the noindex bit of containing two TLVs. The first of these TLVs has the noindex bit of
its semantics set and has a single value of length 2 octets, which its semantics set and has a single value of length 2 octets, which
applies to all of the addresses in the preceding address block. The applies to all of the addresses in the preceding address block. The
second of these TLVs has the novalue bit of its semantics set and second of these TLVs has the novalue bit of its semantics set and
hence has no length or value fields (it does have index fields, which hence has no length or value fields (it does have index fields, which
indicate which of the addresses this TLV applies to). The second indicate those addresses this TLV applies to). The second address
address block contains 2 addresses (head length 0 octets, hence no block contains 2 addresses (head length 0 octets, hence no head
head octets, tail length 2 octets, zero-valued tail not included, octets, tail length 2 octets, zero-valued tail not included, hence
hence mid length two octets) and is followed by a TLV block of mid length two octets) and is followed by a TLV block of content
content length 5 octets. This TLV block contains a single TLV of length 5 octets. This TLV block contains a single TLV of type
type PREFIX_LENGTH which has the multivalue and no index bits of its PREFIX_LENGTH that has the multivalue and noindex bits of its
semantics set and a value field length of 2 octets, indicating two semantics set and a value field length of 2 octets, indicating two
values each of one octet length. There are two final padding octets values each of one octet length. There are two final padding octets
which are not included in the message length of 62 octets. that are not included in the message length of 62 octets.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number | |0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0| | Message Type | Resv |N|0|0|0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | Resv |0|1|0|0| |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |Resv |0|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| Value | |0 0 0 0 0 1 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 1| | Value (cont) |0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Head | Mid | |0 0 0 0 0 0 1 0| Head | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid | Mid | | Mid (cont) | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type | | Mid (cont) |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |0|1|0|0|0 0 0 0 0 0 1 0| Value | |Resv |0|0|1|0|0|0 0 0 0 0 0 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Resv |0|0|0|1| Index Start | Index Stop | | TLV Type |Resv |0|0|0|0|1| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid | |0 0 0 0 0 0 1 0|1 0 0 0 0 0 0 0|1 0 0 0 0 0 1 0| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 0 1 0 1| PREFIX_LENGTH | Resv |1|1|0|0|0 0 0 0 0 0 1 0| |0 0 0 0 0 1 0 1| PREFIX_LENGTH |Resv |1|0|1|0|0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value0 | Value1 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| | Value0 | Value1 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Contributors Appendix C. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributers from the OLSRv2 Design Team -- listed following contributors from the OLSRv2 Design Team -- listed
alphabetically. alphabetically.
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, Hitachi Labs Europe, France, o Emmanuel Baccelli, Hitachi Labs Europe, France,
<Emmanuel.Baccelli@inria.fr> <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, Ecole Polytechnique, France, o Thomas Heide Clausen, LIX, Ecole Polytechnique, France,
<T.Clausen@computer.org> <T.Clausen@computer.org>
skipping to change at page 39, line 5 skipping to change at page 33, line 5
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<chris.dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp> o Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp> o Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp>
Appendix C. Acknowledgements Appendix D. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSRv1, as
specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent
Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced Viennot (all at INRIA, France), and Amir Qayuum (Center for Advanced
Research in Engineering, Pakistan) for their contributions. Research in Engineering, Pakistan) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Joe Macker (NRL), Alan Cullen (BAE specification and its components: Joe Macker (NRL), Alan Cullen (BAE
Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas Systems), Ian Chakeres (Boeing), Charlie E. Perkins (Nokia), Andreas
skipping to change at page 41, line 4 skipping to change at page 34, line 33
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/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 186 change blocks. 
757 lines changed or deleted 457 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/