draft-ietf-manet-rfc5444-usage-00.txt   draft-ietf-manet-rfc5444-usage-01.txt 
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Updates: 5444 (if approved) C. Dearlove Updates: 5444 (if approved) C. Dearlove
Intended status: Standards Track BAE Systems AI Labs Intended status: Standards Track BAE Systems
Expires: December 25, 2015 U. Herberg Expires: June 24, 2016 U. Herberg
H. Rogge H. Rogge
June 23, 2015 December 22, 2015
Rules For Designing Protocols Using the RFC5444 Generalized Packet/ Rules For Designing Protocols Using the RFC 5444 Generalized Packet/
Message Format Message Format
draft-ietf-manet-rfc5444-usage-00 draft-ietf-manet-rfc5444-usage-01
Abstract Abstract
This document updates the generalized MANET packet/message format, This document updates the generalized MANET packet/message format,
specified in RFC5444, by providing prescriptive guidelines for how specified in RFC 5444, by providing rules and recommendations for how
protocols can use that packet/message format. In particular, these protocols can use that packet/message format. In particular, the
mandatory guidelines prohibit a number of uses of RFC5444 that have mandatory rules prohibit a number of uses of RFC 5444 that have been
been suggested in various proposals, and which would have lead to suggested in various proposals, and which would have led to
interoperability problems, to impediment of protocol extension interoperability problems, to the impediment of protocol extension
development, and to inability to use generic RFC5444 parsers. development, and to an inability to use generic RFC 5444 parsers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 25, 2015. This Internet-Draft will expire on June 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3 1.1. History and Purpose . . . . . . . . . . . . . . . . . . . 3
1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3 1.2. RFC 5444 Features . . . . . . . . . . . . . . . . . . . . 3
1.3. Status of This Document . . . . . . . . . . . . . . . . . 5 1.3. Status of This Document . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Information Transmission . . . . . . . . . . . . . . . . . . . 6 4. Information Transmission . . . . . . . . . . . . . . . . . . . 6
4.1. Where to Record Information . . . . . . . . . . . . . . . 6 4.1. Where to Record Information . . . . . . . . . . . . . . . 6
4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7 4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7
4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 8 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 9
4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9
4.5. Information Representation . . . . . . . . . . . . . . . . 10 4.5. Information Representation . . . . . . . . . . . . . . . . 11
4.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 11 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 12
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 13 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Addressesblock compression . . . . . . . . . . . . . . . . 13 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 14
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Address Block Compression . . . . . . . . . . . . . . . . 14
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
[RFC5444] specifies a generalized packet/message format, designed for [RFC5444] specifies a generalized packet/message format, designed for
use by MANET routing protocols. [RFC5498] mandates the use of this use by MANET routing protocols. [RFC5498] mandates the use of this
format by protocols operating over the manet IP protocol and port format by protocols operating over the manet IP protocol and port
numbers whose allocation it requested. numbers that were allocated following its request.
Following experiences with [RFC3626] which attempted - but did not Following experiences with [RFC3626] which attempted, but did not
quite succeed in - providing a packet/message format accommodating quite succeed in, providing a packet/message format accommodating for
for diverse protocol extensions, [RFC5444] was designed by the MANET diverse protocol extensions, [RFC5444] was designed by the MANET
working group as a common building block for use by both proactive working group as a common building block for use by both proactive
and reactive MANET routing protocols. and reactive MANET routing protocols.
1.1. History and Purpose 1.1. History and Purpose
Since the publication of [RFC5444] in 2009, several RFCs have been Since the publication of [RFC5444] in 2009, several RFCs have been
published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181],
[RFC7182], [RFC7183], and [RFC7188], which use the format of [RFC7182], [RFC7183], [RFC7188], and [RFC7631], that use the format
[RFC5444]. The ITU-T recommendation [G9903] also uses the format of of [RFC5444]. The ITU-T recommendation [G9903] also uses the format
[RFC5444] for encoding some of its control signals. In developing of [RFC5444] for encoding some of its control signals. In developing
these specifications, experience with the use of [RFC5444] has been these specifications, experience with the use of [RFC5444] has been
acquired, specifically with respect to how to write specifications acquired, specifically with respect to how to write specifications
using [RFC5444] so as to (i) enable the use of an efficient and using [RFC5444] so as to ensure "forward compatibility" of a protocol
generic parser for all protocols using [RFC5444], (ii) ensure with future extensions, to enable the creation of efficient messages,
"forward compatibility" of a protocol with future extensions, and and to enable the use of an efficient and generic parser for all
(iii) enable the creation of efficient messages. protocols using [RFC5444].
During the same time period, other suggestions have been made to use During the same time period, other suggestions have been made to use
[RFC5444] in a manner that would lead to incompatibilities with [RFC5444] in a manner that would inhibit the development of
generic RFC 5444 parsers, would inhibit the development of interoperable protocol extensions, would potentially lead to
interoperable protocol extensions, or would potentially lead to inefficiencies, or would lead to incompatibilities with generic
inefficiencies. While these uses were not all explicitly prohibited parsers for [RFC5444]. While these uses were not all explicitly
by [RFC5444], they should be strongly discouraged. This document is prohibited by [RFC5444], they should be strongly discouraged. This
intended to prohibit such uses, to present experiences from designing document is intended to prohibit such uses, to present experiences
protocols using [RFC5444] and to provide these as guidelines (with from designing protocols using [RFC5444], and to provide these as
their rationale) for future protocol designs using [RFC5444]. guidelines (with their rationale) for future protocol designs using
[RFC5444].
1.2. RFC 5444 Features 1.2. RFC 5444 Features
Among the characteristics, and design criteria, of the packet/message Among the characteristics, and design criteria, of the packet/message
format of [RFC5444] are: format of [RFC5444] are:
o It is designed for carrying MANET routing protocol control o It is designed for carrying MANET routing protocol control
signals. signals.
o It defines a packet as a packet header with a set of packet TLVs, o It defines a packet as a Packet Header with a set of Packet TLVs,
followed by a set of messages. Each message has a well-defined followed by a set of messages. Each message has a well-defined
structure consisting of a message header (designed for making structure consisting of a Message Header (designed for making
processing and forwarding decisions) followed by set of message processing and forwarding decisions) followed by a set of Message
TLVs (Type-Length-Value structures), and a set of (address, type, TLVs (Type-Length-Value structures), and a set of (address, type,
value) associations using address blocks and their address block value) associations using Address Blocks and their Address Block
TLVs. The [RFC5444] packet/message format then enables the use of TLVs. The [RFC5444] packet/message format then enables the use of
simple and generic parsing logic for packets, message headers, and simple and generic parsing logic for packets, Message Headers, and
message content. message content.
A packet may include messages from different protocols, such as A packet may include messages from different protocols, such as
[RFC6130] and [RFC7181], in a single transmission. This was [RFC6130] and [RFC7181], in a single transmission. This was
observed in [RFC3626] to be beneficial, especially in wireless observed in [RFC3626] to be beneficial, especially in wireless
networks where media contention may be significant. [RFC5444] networks where media contention may be significant. [RFC5444]
defines a multiplexing process to achieve this that is mandated by defines a multiplexing process to achieve this that is mandated by
[RFC5498] for use on the manet IP port and UDP port. This makes [RFC5498] for use on the manet IP port and UDP port. This makes
the contents of the packet header, which may also contain packet the contents of the Packet Header, which may also contain Packet
TLVs, and the transmission of packet over UDP or directly over IP, TLVs, and the transmission of packets over UDP or directly over
the responsibility of this multiplexing process. IP, the responsibility of this multiplexing process.
o A packet is designed to travel between two neighboring interfaces, o Its packets are designed to travel between two neighboring
which will result in a single decrement/increment of the IPv4 TTL interfaces, which will result in a single decrement/increment of
or IPv6 hop limit. The packet header and any packet TLVs should the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet
convey information relevant to that link (for example, the packet TLVs should convey information relevant to that link (for example,
sequence number can be used to count transmission successes across the Packet Sequence Number can be used to count transmission
that link). Packets are not retransmitted, a packet transmission successes across that link). Packets are not retransmitted, a
following a successful packet reception may include all, some, or packet transmission following a successful packet reception may
none of the received messages, plus possibly additional messages include all, some, or none of the received messages, plus possibly
received in separate packets or generated at that router. additional messages received in separate packets or generated at
Messages may thus travel more than one hop, and are designed to that router. Messages may thus travel more than one hop, and are
carry end-to-end protocol signals. designed to carry end-to-end protocol signals.
o It supports "internal extensibility" using TLVs; an extension can o It supports "internal extensibility" using TLVs; an extension can
add information to an existing message type without that add information to an existing message without that information
information rendering the message un-parseable by a router that rendering the message un-parseable by a router that does not
does not support the extension. An extension is typically of the support the extension. An extension is typically of the protocol
protocol that created the message to be extended, for example that created the message to be extended, for example [RFC7181]
[RFC7181] adds information to the HELLO messages created by adds information to the HELLO messages created by [RFC6130].
[RFC6130]. However an extension may also be independent of the However an extension may also be independent of the protocol, for
protocol, for example [RFC7182] can add ICV (Integrity Check example [RFC7182] can add ICV (Integrity Check Value) and
Value) and timestamp information to any message (or to a packet, timestamp information to any message (or to a packet, thus
thus extending the [RFC5444] multiplexing process). extending the [RFC5444] multiplexing process).
Information can be added to the message as a whole, such as the Information can be added to the message as a whole, such as the
[RFC7182] integrity information, or may be associated with [RFC7182] integrity information, or may be associated with
specific addresses in the message, such as the MPR selection and specific addresses in the message, such as the MPR selection and
link metric information added to HELLO messages by [RFC7181]. An link metric information added to HELLO messages by [RFC7181]. An
extension may also add addresses to a message. extension may also add addresses to a message.
o It uses address aggregation into compact address blocks by o It uses address aggregation into compact Address Blocks by
exploiting commonalities between addresses. In many deployments, exploiting commonalities between addresses. In many deployments,
addresses (IPv4 and IPv6) used on interfaces share a common prefix addresses (IPv4 and IPv6) used on interfaces share a common prefix
that need not be repeated. Using IPv6, several addresses (of the that need not be repeated. Using IPv6, several addresses (of the
same interface) may have a common interface Identifiers, also, same interface) may have common interface identifiers that need
that need not be repeated. not be repeated.
o It sets up common namespaces, formats, and data structures for use o It sets up common namespaces, formats, and data structures for use
by different protocols, where common parsing logic can be used. by different protocols, where common parsing logic can be used.
For example, [RFC5497] defines a generic TLV type for representing For example, [RFC5497] defines a generic TLV format for
time information (such as interval time or validity time). representing time information (such as interval time or validity
time).
o It contains a minimal message header (a maximum of five elements: o It contains a minimal Message Header (a maximum of five elements:
type, originator, sequence number, hop count and limit) that type, originator, sequence number, hop count and hop limit) that
permit decisions whether to locally process a message, or forward permit decisions whether to locally process a message, or forward
a message (thus enabling MANET-wide flooding of a message) without a message (thus enabling MANET-wide flooding of a message) without
processing the body of the message. processing the body of the message.
1.3. Status of This Document 1.3. Status of This Document
This document updates [RFC5444], and is intended for publication as a This document updates [RFC5444], and is intended for publication as a
Proposed Standard (rather than as Informational) because it specifies Proposed Standard (rather than as Informational) because it specifies
and mandates constraints on the use of [RFC5444] which, if not and mandates constraints on the use of [RFC5444] which, if not
followed, make desirable forms of generic parsers impossible, or make followed, makes forms of extensions of those protocols impossible,
forms of extensions of those protocols impossible, or impedes on the impedes the ability to generate efficient messages, or makes
ability to generate efficient messages. desirable forms of generic parsers impossible.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
specifically the terms "Packet", "Packet Header", "Message", "Message in particular the terms "packet", "Packet Header", "message",
Header", "Address", "Address Block", "TLV" and "TLV Block" are to be "Message Header", "address", "Address Block", "TLV" and "TLV Block"
interpreted as described therein. are to be interpreted as described therein.
3. Applicability Statement 3. Applicability Statement
This document does not specify a protocol, but documents constraints This document does not specify a protocol, but documents constraints
on how to design protocols which are using the generic packet/message on how to design protocols which are using the generic packet/message
format defined in [RFC5444] which, if not followed, make desirable format defined in [RFC5444] which, if not followed, makes forms of
forms of generic parsers impossible, or make forms of extensions of extensions of those protocols impossible, impedes the ability to
those protocols impossible, or impedes on the ability to generate generate efficient (small) messages, or makes desirable forms of
efficient (small) messages. The use of this format is mandated by generic parsers impossible. The use of this format is mandated by
[RFC5498] for all protocols running over the MANET protocol and port [RFC5498] for all protocols running over the manet protocol and port
number, defined therein. Thus, the constraints in this document number, defined therein. Thus, the constraints in this document
apply to all protocols running over the MANET protocol and port apply to all protocols running over the manet protocol and port
number. number.
4. Information Transmission 4. Information Transmission
Protocols need to transmit information from one instance implementing Protocols need to transmit information from one instance implementing
the protocol to another. the protocol to another.
4.1. Where to Record Information 4.1. Where to Record Information
A protocol has the following choices as to where to put information A protocol has the following choices as to where to put information
for transmission: for transmission:
o In a TLV to be added to the packet header. o In a TLV to be added to the Packet Header.
o In a message of a type owned by another protocol. o In a message of a type owned by another protocol.
o In a message of a type owned by the protocol. o In a message of a type owned by the protocol.
The first case (a Packet TLV) can only be used when the information The first case (a Packet TLV) can only be used when the information
is to be carried one hop. It SHOULD only be used either where the is to be carried one hop. It SHOULD only be used either where the
information relates to the packet as a whole (for example packet information relates to the packet as a whole (for example packet
integrity check values and timestamps, as specified in [RFC7182]) or integrity check values and timestamps, as specified in [RFC7182]) or
if the information is of expected wider application than the single if the information is of expected wider application than the single
protocol. A protocol can also request that the packet header include protocol. A protocol can also request that the Packet Header include
packet sequence numbers, but does not control those numbers. Packet Sequence Numbers, but does not control those numbers.
The second case (in a message of a type owned by another protocol) is The second case (in a message of a type owned by another protocol) is
only possible if the adding protocol is an extension to the owning only possible if the adding protocol is an extension to the owning
protocol, for example OLSRv2 [RFC7181] is an extension of NHDP protocol, for example OLSRv2 [RFC7181] is an extension of NHDP
[RFC6130]. #### SEE COMMENTS IN SVN COMMIT MESSAGE AND ON LIST #### [RFC6130]. While this is not the most common case, protocols SHOULD
While this is not the most common case, protocols SHOULD be designed be designed to enable this to be possible, and most rules in this
to enable this to be possible, and most rules in this document are to document are to help facilitate that. An extension to [RFC5444],
help facilitate that. An extension to [RFC5444], such as [RFC7182] such as [RFC7182], is considered to be an extension to all protocols
is considered to be an extension to all protocols in this regard. in this regard.
The third case is the normal case for a new protocol. Protocols MUST The third case is the normal case for a new protocol. Protocols MUST
be conservative in the number of new message types that they require, be conservative in the number of new message types that they require,
as the total available number of allocatable message types is only as the total available number of allocatable message types is only
224. Protocol design SHOULD consider whether different functions can 224. Protocol design SHOULD consider whether different functions can
be implemented by differences in TLVs carried in the same message be implemented by differences in TLVs carried in the same Message
type, rather than using multiple message types. If a protocol's Type, rather than using multiple Message Types. If a protocol's
needs can be covered by use of the second case, then this SHOULD be needs can be covered by use of the second case, then this SHOULD be
considered. done.
TLV space, although greater than message space, SHOULD also be used TLV space, although greater than message space, SHOULD also be used
efficiently. The full type of TLV occupies two octets, thus there efficiently. The extended type of a TLV occupies two octets, thus
are many more available TLVs. However, in some cases (currently there are many more available TLVs. However, in some cases
LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182] in (currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from
the global TLV space) a full set of 256 TLVs is defined (but not [RFC7182] in the global TLV space) a full set of 256 TLVs is defined
necessarily allocated). Each message has a block of message specific (but not necessarily allocated). Each message has a block of message
TLV types (128 to 233, each with 256 type extensions), these SHOULD specific TLV Types (128 to 233, each with 256 type extensions), these
be used in preference to the common TLV types (0 to 127, each with SHOULD be used in preference to the common TLV Types (0 to 127, each
256 type extensions) when a TLV is message-specific. with 256 type extensions) when a TLV is message-specific.
A message contains a message header and a message body; note that the A message contains a Message Header and a Message Body; note that the
Message TLV block is considered as part of the latter. The message Message TLV Block is considered as part of the latter. The Message
header contains information whose primary purpose is to decide Header contains information whose primary purpose is to decide
whether to process the message, and whether to forward the message. whether to process the message, and whether to forward the message.
[RFC7181] contains a general purpose process for doing that, albeit
one presented as for use with MPR flooding. (Blind flooding can be A message MUST be recognized by the combination of its type,
Originator Address and Message Sequence Number. This allows each
protocol to manage its own Message Sequence Numbers, and also allows
for the possibility that different Message Types may have greatly
differing transmission rates. [RFC7181] contains a general purpose
process for managing processing and forwarding decisions, albeit one
presented as for use with MPR flooding. (Blind flooding can be
handled similarly by assuming that all other routers are MPR handled similarly by assuming that all other routers are MPR
selectors; it is not necessary in this case to differentiate between selectors; it is not necessary in this case to differentiate between
interfaces on which a message is received.) interfaces on which a message is received.)
Most protocol information is thus contained in the message body. A Most protocol information is thus contained in the Message Body. A
model of how such information may be viewed is described in the model of how such information may be viewed is described in
following section. To use that model, addresses (for example of Section 4.3 and Section 4.4. To use that model, addresses (for
neighboring or otherwise known routers) SHOULD be recorded in address example of neighboring or otherwise known routers) SHOULD be recorded
blocks, not as data in TLVs. Recording addresses in TLV value fields in Address Blocks, not as data in TLVs. Recording addresses in TLV
both breaks the model of addresses as identities and associated Value fields both breaks the model of addresses as identities and
information (attributes) and also inhibits address compression. associated information (attributes) and also inhibits address
However in some cases alternative addresses (e.g., HW addresses when compression. However in some cases alternative addresses (e.g.,
the address block is recording IP addresses) MAY be carried as TLV hardware addresses when the Address Block is recording IP addresses)
values. Note that a message contains a Message Address Length (MAL) MAY be carried as TLV Values. Note that a message contains a Message
field that can be used to allow carrying alternative message sizes, Address Length field that can be used to allow carrying alternative
but only one length of addresses in all address blocks can be used in message sizes, but only one length of addresses can be used in a
a single message. single message, in all Address Blocks and the Originator Address.
4.2. Packets and Messages 4.2. Packets and Messages
The [RFC5444] multiplexing process has to handle packet reception and The [RFC5444] multiplexing process has to handle packet reception and
message demultiplexing, and message transmission and packet message demultiplexing, and message transmission and packet
multiplexing. multiplexing.
When a packet arrives, the following steps are required: When a packet arrives, the following steps are required:
o The packet and/or the messages it contains MAY be verified by an o The packet and/or the messages it contains MAY be verified by an
extension to the demultiplexer, such as [RFC7182]. extension to the demultiplexer, such as [RFC7182].
o Each message MUST be sent to its owning protocol, which MAY also o Each message MUST be sent to its owning protocol, which MAY also
view the packet header. view the Packet Header, and the source address in the IP datagram
that included the packet.
o The owning protocol SHOULD verify each message, it SHOULD allow o The owning protocol SHOULD verify each message, it SHOULD allow
any extending protocol(s) to also contribute to this. any extending protocol(s) to also contribute to this.
o The owning protocol MUST process each message, or make an informed o The owning protocol MUST process each message, or make an informed
decision not to do so. In the former case an owning protocol that decision not to do so. In the former case an owning protocol that
permits this MUST allow any extending protocols to process or permits this MUST allow any extending protocols to process or
ignore the message. ignore the message.
Packets are formed for transmission by: Packets are formed for transmission by:
o Outgoing messages MAY be created by the owning protocol, and MAY o Outgoing messages are created by their owning protocol, and MAY be
be modified by any extending protocols if the owning protocol modified by any extending protocols if the owning protocol permits
permits this. Messages MAY also be forwarded by their owning this. Messages MAY also be forwarded by their owning protocol.
protocol. It is RECOMMENDED that messages are not modified in the It is RECOMMENDED that messages are not modified in the latter
latter case. case.
o Outgoing messages are then sent to the [RFC5444] multiplexing o Outgoing messages are then sent to the [RFC5444] multiplexing
process. The owning protocol MAY request that messages are kept process. The owning protocol MUST indicate which interface(s) the
together in a packet, the multiplexing process SHOULD respect this messages are to be sent on and their destination address, and MAY
request if possible. A protocol MAY also request that a packet request that messages are kept together in a packet; the
sequence number and/or specified packet TLVs are included, such multiplexing process SHOULD respect this request if possible. A
requests SHOULD also be respected if possible. protocol MAY also request that a Packet Sequence Number and/or
specified Packet TLVs are included, such requests SHOULD also be
respected if possible.
o The multiplexing process MAY combine messages from multiple o The multiplexing process SHOULD combine messages from multiple
protocols in a packet. protocols that are sent on the same interface in a packet,
provided that in so doing the multiplexing process does not cause
an IP packet to exceed the current MTU (Maximum Transmission
Unit). (Note that the multiplexing process cannot fragment
messages, creating suitable sized messages is the responsibility
of the protocol.)
o If requested by a protocol the multiplexer SHOULD, and otherwise
MAY, include a Packet Sequence Number in the packet. Note that,
as per the errata to [RFC5444], this Packet Sequence Number MUST
be specific to the interface on which the packet is sent.
o An extension to the multiplexing process MAY add TLVs to the o An extension to the multiplexing process MAY add TLVs to the
packet and/or the messages (for example as by [RFC7182]). packet and/or the messages (for example as by [RFC7182]).
4.3. Messages, Addresses and Attributes 4.3. Messages, Addresses and Attributes
The information in a message body, including Message TLVs and Address The information in a Message Body, including Message TLVs and Address
Block TLVs, can be considered to consist of: Block TLVs, can be considered to consist of:
o Attributes of the message, each attribute consisting of an o Attributes of the message, each attribute consisting of an
extended type, a length, and a value (of that length). extended type, a length, and a value (of that length).
o A set of addresses, carried in one or more Address Blocks. o A set of addresses, carried in one or more Address Blocks.
o Attributes of each address, each attribute consisting of an o Attributes of each address, each attribute consisting of an
extended type, a length, and a value (of that length). extended type, a length, and a value (of that length).
Attributes are carried in TLVs. For Message TLVs the mapping from Attributes are carried in TLVs. For Message TLVs the mapping from
TLV to attribute is one to one. For Address Block TLVs the mapping TLV to attribute is one to one. For Address Block TLVs the mapping
from TLV to attribute is one to many, one TLV can carry attributes from TLV to attribute is one to many, one TLV can carry attributes
for multiple addresses, but only one attribute per address. for multiple addresses, but only one attribute per address.
Attributes for different addresses may be the same or different. Attributes for different addresses may be the same or different.
A TLV extended type may be (and this is RECOMMENDED whenever A TLV extended type MAY be (and this is RECOMMENDED whenever
possible) defined so that there may only be one TLV of that extended possible) defined so that there may only be one TLV of that extended
type associated with the message (Message TLV) or any value of any type associated with the message (Message TLV) or any value of any
address (Address TLV). Note that an address may appear more than address (Address Block TLV). Note that an address may appear more
once in a message, but the restriction on associating TLVs with than once in a message, but the restriction on associating TLVs with
addresses covers all copies of that address. It is RECOMMENDED that addresses covers all copies of that address. It is RECOMMENDED that
addresses are not repeated in a message. addresses are not repeated in a message.
4.4. Addresses Require Attributes 4.4. Addresses Require Attributes
It is not mandatory in [RFC5444] to associate an address with It is not mandatory in [RFC5444] to associate an address with
attributes using Address Block TLVs, information about an address attributes using Address Block TLVs. Information about an address
could thus, in principle be carried using: could thus, in principle be carried using:
o The simple presence of an address. o The simple presence of an address.
o The ordering of addresses in an address block. o The ordering of addresses in an Address Block.
o The use of different meanings for different address blocks. o The use of different meanings for different Address Blocks.
This specification, however, requires that those methods of carrying This specification, however, requires that those methods of carrying
information MUST NOT be used for any protocol using [RFC5444]. information MUST NOT be used for any protocol using [RFC5444].
Information about the meaning of an address MUST only be carried Information about the meaning of an address MUST only be carried
using Address Block TLVs. using Address Block TLVs.
In addition, rules for the extensibility of OLSRv2 and NHDP are In addition, rules for the extensibility of OLSRv2 and NHDP are
described in [RFC7188]. This specification extends their described in [RFC7188]. This specification extends their
applicability to other uses of [RFC5444]. applicability to other uses of [RFC5444].
skipping to change at page 9, line 46 skipping to change at page 10, line 19
A protocol MUST NOT assign any meaning to the presence, or absence, A protocol MUST NOT assign any meaning to the presence, or absence,
of an address, as this would prevent the addition of addresses with of an address, as this would prevent the addition of addresses with
other meanings. For example consider NHDP's HELLO messages other meanings. For example consider NHDP's HELLO messages
[RFC6130]. The basic function of a HELLO message is to indicate that [RFC6130]. The basic function of a HELLO message is to indicate that
an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB an address is of a neighbor, using the LINK_STATUS and OTHER_NEIGHB
TLVs. An extension to NHDP might decide to use the HELLO message to TLVs. An extension to NHDP might decide to use the HELLO message to
report that, for example, an address is one that could be used for a report that, for example, an address is one that could be used for a
specialized purpose, but not for normal NHDP-based purposes. Such an specialized purpose, but not for normal NHDP-based purposes. Such an
example already exists (but within the basic specification, rather example already exists (but within the basic specification, rather
than as an extension) in the use of LOST values in the LINK_STATUS than as an extension) in the use of LOST Values in the LINK_STATUS
and OTHER_NEIGHB TLVs to report that an address is of a router known and OTHER_NEIGHB TLVs to report that an address is of a router known
not to be a neighbor. A future example might be to list an address not to be a neighbor. A future example might be to list an address
to be added to a "blacklist" of addresses not to be used. This would to be added to a "blacklist" of addresses not to be used. This would
be indicated by a new TLV (or a new value of an existing TLV, see be indicated by a new TLV (or a new Value of an existing TLV, see
below). An unmodified extension to NHDP would ignore such addresses, below). An unmodified extension to NHDP would ignore such addresses,
as required, as it does not support that specialized purpose. If as required, as it does not support that specialized purpose. If
NHDP had been designed so that just the presence of an address NHDP had been designed so that just the presence of an address
indicated a neighbor, that extension would not have been possible. indicated a neighbor, that extension would not have been possible.
This example can be taken further. NHDP must also not reject a HELLO This example can be taken further. NHDP must also not reject a HELLO
message because it contains an unrecognized TLV. This also applies message because it contains an unrecognized TLV. This also applies
to unrecognized TLV values, where a TLV supports only a limited set to unrecognized TLV Values, where a TLV supports only a limited set
of values. For example, the blacklisting described in the previous of Values. For example, the blacklisting described in the previous
paragraph could be signaled not with a new TLV, but with a new value paragraph could be signaled not with a new TLV, but with a new Value
of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as of a LINK_STATUS or OTHER_NEIGHB TLV (requiring an IANA allocation as
described in [RFC7188]), as is already done in the LOST case. described in [RFC7188]), as is already done in the LOST case.
Information may also be added to addresses recognized by the base Information may also be added to addresses recognized by the base
protocol. For example OLSRv2 [RFC7181] is, among other things, an protocol. For example OLSRv2 [RFC7181] is, among other things, an
extension to NHDP. It adds information to addresses in an NHDP HELLO extension to NHDP. It adds information to addresses in an NHDP HELLO
message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP message using a LINK_METRIC TLV. A non-OLSRv2 implementation of
(for example, to support SMF [RFC6621]) must still process the HELLO NHDP, for example to support Simplified Multicast Flooding (SMF)
message, ignoring the LINK_METRIC TLVs. [RFC6621], must still process the HELLO message, ignoring the
LINK_METRIC TLVs.
This does not, however, mean that added information is completely This does not, however, mean that added information is completely
ignored for purposes of the base protocol. Suppose that a faulty ignored for purposes of the base protocol. Suppose that a faulty
implementation of OLSRv2 (including NHDP) creates a HELLO message implementation of OLSRv2 (including NHDP) creates a HELLO message
that assigns two different values of the same link metric to an that assigns two different values of the same link metric to an
address, something which is not permitted by [RFC7181]. A receiving address, something that is not permitted by [RFC7181]. A receiving
OLSRv2-aware implementation of NHDP should reject such a message, OLSRv2-aware implementation of NHDP MUST reject such a message, even
even though a receiving OLSRv2-unaware implementation of NHDP will though a receiving OLSRv2-unaware implementation of NHDP will process
process it. This is because the OLSRv2-aware implementation has it. This is because the OLSRv2-aware implementation has access to
access to additional information, that the HELLO message is additional information, that the HELLO message is definitely invalid,
definitely invalid, and the message is best ignored, as it is unknown and the message is best ignored, as it is unknown what other errors
what other errors it may contain. it may contain.
The restrictions on the use of address ordering and an address The restrictions on the use of address ordering and an address
presence or absence in given address blocks for carrying information presence or absence in given Address Blocks for carrying information
are for two reasons. First use of those prevents the approach to are for two reasons. First, use of those prevents the approach to
information representation described in Section 4.5. Second, it information representation described in Section 4.5. Second, it
reduces the options available for message optimization described in reduces the options available for message optimization described in
Section 6. Section 6.
4.5. Information Representation 4.5. Information Representation
A message (excluding the message header) can thus be represented by A message (excluding the Message Header) can thus be represented by
two, possibly multivalued, maps: two, possibly multivalued, maps:
o Message: (extended type) -> (length, value) o Message: (extended type) -> (length, value)
o Address: (address, extended type) -> (length, value) o Address: (address, extended type) -> (length, value)
These maps (plus a representation of the message header) can be the These maps (plus a representation of the Message Header) can be the
basis for a generic representation of information in a message. Such basis for a generic representation of information in a message. Such
maps can be created by parsing the message, or can be constructed maps can be created by parsing the message, or can be constructed
using the protocol rules for creating a message, and later converted using the protocol rules for creating a message, and later converted
into the octet form of the message specified in [RFC5444]. into the octet form of the message specified in [RFC5444].
While of course any implementation of software that represents While of course any implementation of software that represents
software in the above form can specify an application programming software in the above form can specify an application programming
interface (API) for that software, such an interface is not proposed interface (API) for that software, such an interface is not proposed
here. First, a full API would be programming language specific. here. First, a full API would be programming language specific.
Second, even within the above framework, there are alternative Second, even within the above framework, there are alternative
approaches to such an interface. For example, and for illustrative approaches to such an interface. For example, and for illustrative
purposes only, for the address mapping: purposes only, for the address mapping:
o Input: address and extended type. Output: list of (length, value) o Input: address and extended type. Output: list of (length, value)
pairs. Note that for most extended types it will be known in pairs. Note that for most extended types it will be known in
advance that this list will have length zero or one. The list of advance that this list will have length zero or one. The list of
addresses that can be used as inputs with non-empty output would addresses that can be used as inputs with non-empty output would
need to be provided as a separate output. need to be provided as a separate output.
o Input: extended type. Output: list of (address, length, value) o Input: extended type. Output: list of (address, length, value)
triples. As this list length may be significant, the likely triples. As this list length may be significant, a possible
output will be of one or two iterators that will allow iterating output will be of one or two iterators that will allow iterating
through that list. (One iterator that can detect the end of list, through that list. (One iterator that can detect the end of list,
or a pair of iterators specifying a range.) or a pair of iterators specifying a range.)
Additional differences in the interface may relate to, for example, Additional differences in the interface may relate to, for example,
the ordering of output lists. the ordering of output lists.
4.6. Message Integrity 4.6. TLVs
Within a message, the attributes are represented by TLVs.
Particularly for Address Block TLVs, different TLVs may represent the
same information. For example, using the LINK_STATUS TLV defined in
[RFC6130], if some addresses have Value SYMMETRIC and some have Value
HEARD, arranged in that order, then this information can be
represented using two single value TLVs or one multivalue TLV. The
latter can be used even if the addresses are not so ordered.
A protocol MAY use any representation of information using TLVs that
convey the required information. A protocol SHOULD use an efficient
representation, but this is a quality of implementation issue. A
protocol MUST recognize any permitted representation of the
information, even if it chooses to (for example) only use multivalue
TLVs, it MUST recognize single value TLVs (and vice versa).
A protocol defining new TLVs MUST respect the naming and
organizational rules in [RFC7631]. It SHOULD follow the guidance in
RFC [RFC7181], except where those requirements are ones that MUST be
followed as required by this specification (or when extending
[RFC6130] or [RFC7181], when these MUST also be followed).
4.7. Message Integrity
In addition to not rejecting a message due to unknown TLVs or TLV In addition to not rejecting a message due to unknown TLVs or TLV
values, a protocol MUST NOT fail to forward a message (by whatever Values, a protocol MUST NOT fail to forward a message (by whatever
means of message forwarding are appropriate to that protocol) due to means of message forwarding are appropriate to that protocol) due to
the presence of such TLVs or TLV values, and MUST NOT remove such the presence of such TLVs or TLV Values, and MUST NOT remove such
TLVs or values. Such behavior would have the consequences that: TLVs or TLV Values. Such behavior would have the consequences that:
o It might disrupt the operation of an extension of which it is o It might disrupt the operation of an extension of which it is
unaware. Note that it is the responsibility of a protocol unaware. Note that it is the responsibility of a protocol
extension to handle interoperation with unextended instances of extension to handle interoperation with unextended instances of
the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV the protocol. For example OLSRv2 [RFC7181] adds an MPR_WILLNG TLV
to HELLO messages (created by NHDP, [RFC6130], of which it is in to HELLO messages (created by NHDP, [RFC6130], of which it is in
part an extension) to recognize this case (and for other reasons). part an extension) to recognize this case (and for other reasons).
If an incompatible protocol extension were defined, it would be If an incompatible protocol extension were defined, it would be
the responsibility of network management to ensure that the responsibility of network management to ensure that
incompatible routers were not both present in the MANET, this case incompatible routers were not both present in the MANET; this case
is NOT RECOMMENDED. is NOT RECOMMENDED.
o It would prevent the operation of end to end message o It would prevent the operation of end to end message
authentication using [RFC7182], or any similar mechanism. The use authentication using [RFC7182], or any similar mechanism. The use
of immutable (apart from hop count and/or limit) messages by a of immutable (apart from hop count and/or hop limit) messages by a
protocol is strongly RECOMMENDED for that reason. protocol is strongly RECOMMENDED for that reason.
5. Structure 5. Structure
The elements defined in [RFC5444] have structures that are managed by The elements defined in [RFC5444] have structures that are managed by
a number of flags fields: a number of flags fields:
o Packet flags (4 bits, 2 used) that manages the contents of the o Packet flags field (4 bits, 2 used) that manages the contents of
packet header. the Packet Header.
o Message flags (4 bits, 4 used) that manages the contents of the o Message flags field (4 bits, 4 used) that manages the contents of
message header. the Message Header.
o Address Block flags (8 bits, 4 used) that manages the contents of o Address Block flags field (8 bits, 4 used) that manages the
an Address Block. contents of an Address Block.
o TLV flags (8 bits, 5 used) that manages the contents of a TLV. o TLV flags field (8 bits, 5 used) that manages the contents of a
TLV.
Note that all of these flags are structural, they specify which Note that all of these flags are structural, they specify which
elements are present or absent, or field lengths, or whether a field elements are present or absent, or field lengths, or whether a field
has one or multiple values in it. has one or multiple values in it.
In the current version of [RFC5444], indicated by version number 0 in In the current version of [RFC5444], indicated by version number 0 in
the <version> field of the packet header, unused bits in these flags the <version> field of the Packet Header, unused bits in these flags
fields "are RESERVED and SHOULD each be cleared ('0') on transmission fields "are RESERVED and SHOULD each be cleared ('0') on transmission
and SHOULD be ignored on reception.". and SHOULD be ignored on reception".
If a specification introduces new flags in one of the flags fields of If a specification updating [RFC5444] introduces new flags in one of
a packet, message or Address Block, the following rules MUST be the flags fields of a packet, message or Address Block, the following
followed: rules MUST be followed:
o The version number contained in the <version> field of the packet o The version number contained in the <version> field of the Packet
header MUST NOT be 0. Header MUST NOT be 0.
o The new flag(s) MUST indicate the structure of the corresponding o The new flag(s) MUST indicate the structure of the corresponding
packet, message, Address Block or TLV, and MUST NOT be used to packet, message, Address Block or TLV, and MUST NOT be used to
indicate any other semantics, such as message forwarding behavior. indicate any other semantics, such as message forwarding behavior.
During the development of [RFC5444], and since publication hereof, An update that would be incompatible with the current specification
of [RFC5444] SHOULD NOT be created unless there is a pressing reason
for it that cannot be satisfied using the current specification
(e.g., by use of a suitable Message TLV).
During the development of [RFC5444], and since publication thereof,
some proposals have been made to use these RESERVED flags to specify some proposals have been made to use these RESERVED flags to specify
behavior rather than structure, in particular message forwarding. behavior rather than structure, in particular message forwarding.
These were, after due consideration, not accepted, for a number of These proposals were, after due consideration, not accepted, for a
reasons. These include that message forwarding, in particular, is number of reasons. These reasons include that message forwarding, in
protocol-specific. For example [RFC7181] forwards messages using its particular, is protocol-specific; for example [RFC7181] forwards
MPR (Multi-Point Relay) mechanism, rather than a "blind" flooding messages using its MPR (Multi-Point Relay) mechanism, rather than a
mechanism. The later addition of a 4 bit Message Address Length "blind" flooding mechanism. (The later addition of a 4 bit Message
field later left no spare flags bits at the message level for such Address Length field later left no unused message flags bits, but
use. other fields still have unused bits.)
6. Message Efficiency 6. Message Efficiency
The ability to organize addresses into different, or the same, The ability to organize addresses into different, or the same,
address blocks, as well as to change the order of addresses within an Address Blocks, as well as to change the order of addresses within an
address block, enables avoiding unnecessary repetition of information Address Block, and the flexibility of the TLV specification, enables
- and, consequently, generation of smaller messages. avoiding unnecessary repetition of information, and consequently can
generate smaller messages. No algorithms for address organization or
6.1. Addressesblock compression compression or for TLV usage are given in [RFC5444], any algorithms
that leave the information content unchanged MAY be used.
Addresses in an address block can be compressed, and SHOULD be.
While no algorithm for compression is given in [RFC5444], an
efficient compression algorithm given a set of addresses, has to obey
certain contraints.
The protocol using RFC5444 sets the constraints by defining the list
of addresses and a list of addressblock TLV types and values for each
of the addresses. A compression strategy has to decide two
additional things which will have a major influence on the
compression efficiency.
o the split of the addresses into address blocks
o the order of the addresses within the address blocks. 6.1. Address Block Compression
The order of addresses can be as simple as sorting the addresses, but Addresses in an Address Block can be compressed, and SHOULD be.
if a lot of addresses have the same TLV types attached, it might be
more useful to group the messages by sections with same or similar
TLV types (e.g. RFC6130 HELLO messages with local interface
addresses first and neighbor addresses later).
Compression of address blocks is obtained by considering addresses to Compression of addresses in an Address Block considers addresses to
consist of a Head, a Mid, and a Tail, where all addresses in an consist of a Head, a Mid, and a Tail, where all addresses in an
address block have the same Head and Tail, but different Mids. An Address Block have the same Head and Tail, but different Mids. An
additional compression is possible when the Tail consists of all additional compression is possible when the Tail consists of all
zero-valued octets. Expected use cases are IPv4 and IPv6 addresses zero-valued octets. Expected use cases are IPv4 and IPv6 addresses
from within the same prefix and which therefore have a common Head, from within the same prefix and which therefore have a common Head,
IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with
a common Tail representing an interface identifier as well as a a common Tail representing an interface identifier as well as a
possible common Head. Note that when, for example, IPv4 addresses possible common Head. Note that when, for example, IPv4 addresses
have a common Head, their Tail will be empty. For example 192.0.2.1 have a common Head, their Tail will usually be empty. For example
and 192.0.2.2 would have a 3 octet Head, a 1 octet Mid, and a 0 octet 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3
Tail. octet Head, a 1 octet Mid, and a 0 octet Tail.
Address blocks with few similar addresses will save more bytes by Putting addresses into a message efficiently also has to include:
using longer Head and Tails in the address block header. Address
blocks with a lot of addresses will reduce the overhead created by o The split of the addresses into Address Blocks.
the address block header and TLV headers for multivalue TLVs. The
compression strategy will have to select the tradeof between these o The order of the addresses within the Address Blocks.
two optimizations that will lead to a minimal number of bytes.
This split and/or ordering is for efficiency only, it does not
provide any information. The split of the addresses affects both the
address compression and the TLV efficiency (see Section 6.2), the
order of the addresses within an Address Block affects only the TLV
efficiency. However using more Address Blocks than is needed can
increase the message size due to the overhead of each Address Block
and the following TLV Block, and/or if additional TLVs are now
required.
The order of addresses can be as simple as sorting the addresses, but
if many addresses have the same TLV Types attached, it might be more
useful to put these addresses together, either within the same
Address Block as other addresses, or in a separate Address Block. A
separate address block might also improve address compression, for
example if more than one address form is used (such as from
independent subnets). An example of the possible use of address
ordering is a HELLO message from [RFC6130] which MAY be generated
with local interface addresses first and neighbor addresses later.
These MAY be in separate Address Blocks.
6.2. TLVs 6.2. TLVs
The main opportunities for efficient messages when considering TLVs The main opportunities for efficient messages when considering TLVs
are Address Block TLVs, rather than Message TLVs. are in Address Block TLVs, rather than Message TLVs.
An Address Block TLV provides attributes for one address or a An Address Block TLV provides attributes for one address or a
contiguous (as stored in the address block) set of addresses (with a contiguous (as stored in the Address Block) set of addresses (with a
special case for when this is all addresses in an address block). special case for when this is all addresses in an Address Block).
When associated with more than one address, a TLV may be single- When associated with more than one address, a TLV may be single value
valued (associating the same attribute with each address) or multi- (associating the same attribute with each address) or multivalue
valued (associating a separate attribute with each address). (associating a separate attribute with each address).
The simplest to implement approach is to use multi-valued TLVs that The simplest to implement approach is to use multivalue TLVs that
cover all affected addresses. However unless care is taken to order cover all affected addresses. However unless care is taken to order
addresses appropriately, these affected addresses may not all be addresses appropriately, these affected addresses may not all be
contiguous. Approaches to this are to: contiguous. Approaches to this are to:
o Reorder the addresses. It is, for example, possible (though not o Reorder the addresses. It is, for example, possible (though not
straightforward) to order all addresses in HELLO message as straightforward) to order all addresses in HELLO message as
specified in [RFC6130] so that all TLVs used only cover contiguous specified in [RFC6130] so that all TLVs used only cover contiguous
addresses. This is even possible if the MPR TLV specified in addresses. This is even possible if the MPR TLV specified in
OLSRv2 [RFC7181] is added; but it is not possible, in general, if OLSRv2 [RFC7181] is added; but it is not possible, in general, if
the LINK_METRIC TLV is also added. the LINK_METRIC TLV is also added.
o Allow the TLV to span over addresses that do not need the o Allow the TLV to span over addresses that do not need the
corresponding attribute, using a value that indicates no corresponding attribute, using a Value that indicates no
information, see Section 6.3. information, see Section 6.3.
o Use more than one TLV. Note that this can be efficient when the o Use more than one TLV. Note that this can be efficient when the
TLVs thus become single-valued. In a typical case where a TLVs thus become single value TLVs. In a typical case where a
LINK_STATUS TLV uses only the values HEARD and SYMMETRIC, with LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with
enough addresses, sorted appropriately, two single-valued TLVs can enough addresses, sorted appropriately, two single value TLVs can
be more efficient than one multi-valued TLV. (When only one value be more efficient than one multivalue TLV. (When only one Value
is involved, such as NHDP in a steady state with LINK_STATUS equal is involved, such as NHDP in a steady state with LINK_STATUS equal
to SYMMETRIC in all cases, a single single-valued TLV should to SYMMETRIC in all cases, one single value TLV SHOULD always be
always be used.) used.)
6.3. TLV Values 6.3. TLV Values
If, for example, an address block contains five addresses, the first If, for example, an Address Block contains five addresses, the first
two and the last two requiring values assigned using a LINK_STATUS two and the last two requiring Values assigned using a LINK_STATUS
TLV, but the third does not, then this can be indicated using two TLV, but the third does not, then this can be indicated using two
TLVs. It is however more efficient to do this with a single TLVs. It is however more efficient to do this with one multivalue
multivalue LINK_STATUS TLV, assigning the third address the value LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED.
UNSPECIFIED. This approach was specified in [RFC7188], and required This approach was specified in [RFC7188], and required for protocols
for protocols that extend [RFC6130] and [RFC7181]. It is here that extend [RFC6130] and [RFC7181]. It is here RECOMMENDED that
RECOMMNDED that this approach is followed when defining any Address this approach is followed when defining any Address Block TLV that
Block TLV that may be used by a protocol using [RFC5444]. may be used by a protocol using [RFC5444].
It might be argued that this is not necessary in the example above, It might be argued that this is not necessary in the example above,
because the addresses can be reordered. However ordering addresses because the addresses can be reordered. However ordering addresses
in such a way for all possible TLVs is not, in general, possible. in such a way for all possible TLVs is not, in general, possible.
As indicated, the LINK_STATUS TLV, and some other TLVs that take As indicated, the LINK_STATUS TLV, and some other TLVs that take
single octet values (per address) has a value UNSPECIFIED defined, as single octet Values (per address), have a Value UNSPECIFIED defined,
the value 255, in [RFC7188]. A similar approach (and a similar as the Value 255, in [RFC7188]. A similar approach (and a similar
value) is RECOMMENDED in any similar cases. Some other TLVs may need Value) is RECOMMENDED in any similar cases. Some other TLVs may need
a different approach, as noted in [RFC7188], but implicitly a different approach. As noted in [RFC7188], but implicitly
permissible before then, the LINK_METRIC TLV has two octet values permissible before then, the LINK_METRIC TLV has two octet Values
whose first four bits are flags indicating whether the metric value whose first four bits are flags indicating whether the metric applies
applies in four cases; if these are all zero then the metric value in four cases; if these are all zero then the metric does not apply
does not apply in this case, which is thus the equivalent of an in this case, which is thus the equivalent of an UNSPECIFIED Value.
UNSPECIFIED value.
6.4. Automation 6.4. Automation
There is scope for creating a protocol-independent optimizer for There is scope for creating a protocol-independent optimizer for
[RFC5444] messages that performs appropriate address re-organization [RFC5444] messages that performs appropriate address re-organization
(ordering and block separation) and TLV changes (of number, single- (ordering and Address Block separation) and TLV changes (of number,
or multi- valuedness and use of unspecified values) to create more single- or multi- valuedness and use of UNSPECIFIED Values) to create
compact messages. The possible gain depends on the efficiency of the more compact messages. The possible gain depends on the efficiency
original message creation, and the specific details of the message. of the original message creation, and the specific details of the
Note that while protocol-independent, this cannot be entirely TLV- message. Note that this process cannot be TLV Type independent, for
independent, for example a LINK_METRIC TLV has a more complicated example a LINK_METRIC TLV has a more complicated Value structure than
value structure than a LINK_STATUS TLV does if using unspecified a LINK_STATUS TLV does if using UNSPECIFIED Values.
values.
7. Security Considerations 7. Security Considerations
This document does not specify a protocol, but provides rules and This document does not specify a protocol, but provides rules and
recommendations for how to design protocols using [RFC5444]. This recommendations for how to design protocols using [RFC5444]. This
document does not introduce any new security considerations; document does not introduce any new security considerations;
protocols designed according to these guidelines and recommendations protocols designed according to these rules and recommendations are
are subject to the security considerations detailed in [RFC5444]. In subject to the security considerations detailed in [RFC5444]. In
particular the applicability of the security framework for [RFC5444] particular the applicability of the security framework for [RFC5444]
specified in [RFC7182] is unchanged. specified in [RFC7182] is unchanged.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgments 9. Acknowledgments
TBD TBD.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
skipping to change at page 17, line 16 skipping to change at page 18, line 16
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014. Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, April 2014.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol version 2 (OLSRv2) and MANET Neighborhood Protocol version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7188, Discovery Protocol (NHDP) Extension TLVs", RFC 7183,
April 2014. April 2014.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the MANET
Generalized Packet/Message Format", RFC 7631,
January 2015.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33-6-6058-9349 Phone: +33-6-6058-9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org URI: http://www.thomasclausen.org
 End of changes. 92 change blocks. 
277 lines changed or deleted 334 lines changed or added

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