draft-ietf-manet-rfc5444-usage-06.txt   draft-ietf-manet-rfc5444-usage-07.txt 
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft Ecole Polytechnique Internet-Draft Ecole Polytechnique
Updates: 5444 (if approved) C. Dearlove Updates: 5444 (if approved) C. Dearlove
Intended status: Standards Track BAE Systems Intended status: Standards Track BAE Systems
Expires: November 18, 2017 U. Herberg Expires: January 19, 2018 U. Herberg
H. Rogge H. Rogge
Fraunhofer FKIE Fraunhofer FKIE
May 17, 2017 July 18, 2017
Rules for Designing Protocols Using the RFC 5444 Generalized Packet/ Rules for Designing Protocols Using the RFC 5444 Generalized Packet/
Message Format Message Format
draft-ietf-manet-rfc5444-usage-06 draft-ietf-manet-rfc5444-usage-07
Abstract Abstract
RFC 5444 specifies a generalized MANET packet/message format and RFC 5444 specifies a generalized MANET packet/message format and
describes an intended use for multiplexed MANET routing protocol describes an intended use for multiplexed MANET routing protocol
messages that is mandated to use on the port/protocol specified by messages that is mandated to use on the port or protocol specified by
RFC 5498. This document updates RFC 5444 by providing rules and RFC 5498. This document updates RFC 5444 by providing rules and
recommendations for how the multiplexer operates and how protocols recommendations for how the multiplexer operates and how protocols
can use the packet/message format. In particular, the mandatory can use the packet/message format. In particular, the mandatory
rules prohibit a number of uses that have been suggested in various rules prohibit a number of uses that have been suggested in various
proposals, and which would have led to interoperability problems, to proposals, and which would have led to interoperability problems, to
the impediment of protocol extension development, and to an inability the impediment of protocol extension development, and to an inability
to use optional generic parsers. to use optional generic parsers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 November 18, 2017. This Internet-Draft will expire on January 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
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.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4
1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 6
1.3. Status of This Document . . . . . . . . . . . . . . . . . 7 1.3. Status of This Document . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
4. Information Transmission . . . . . . . . . . . . . . . . . . . 8 4. Information Transmission . . . . . . . . . . . . . . . . . . . 8
4.1. Where to Record Information . . . . . . . . . . . . . . . 8 4.1. Where to Record Information . . . . . . . . . . . . . . . 8
4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 9 4.2. Message and TLV Type Allocation . . . . . . . . . . . . . 9
4.3. Message Recognition . . . . . . . . . . . . . . . . . . . 9 4.3. Message Recognition . . . . . . . . . . . . . . . . . . . 9
4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10 4.4. Message Multiplexing and Packets . . . . . . . . . . . . . 10
4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10 4.4.1. Packet Transmission . . . . . . . . . . . . . . . . . 10
4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 11 4.4.2. Packet Reception . . . . . . . . . . . . . . . . . . . 12
4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13 4.5. Messages, Addresses and Attributes . . . . . . . . . . . . 13
4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 13 4.6. Addresses Require Attributes . . . . . . . . . . . . . . . 14
4.7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.7. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 16 4.8. Message Integrity . . . . . . . . . . . . . . . . . . . . 17
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 18 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Address Block Compression . . . . . . . . . . . . . . . . 18 6.1. Address Block Compression . . . . . . . . . . . . . . . . 19
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 20 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Information Representation . . . . . . . . . . . . . 24 Appendix A. Information Representation . . . . . . . . . . . . . 25
Appendix B. Automation . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Automation . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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. use by MANET routing protocols.
[RFC5444] was designed following experiences with [RFC3626], which [RFC5444] was designed following experiences with [RFC3626], which
attempted, but did not quite succeed in, providing a packet/message attempted to provide a packet/message format accommodating for
format accommodating for diverse protocol extensions. [RFC5444] was diverse protocol extensions but did not fully succeed. [RFC5444] was
designed as a common building block for use by both proactive and designed as a common building block for use by both proactive and
reactive MANET routing protocols. reactive MANET routing protocols.
[RFC5498] mandates the use of this packet/message format, and of the [RFC5498] mandates the use of this packet/message format and of the
packet multiplexing process described in an Appendix to [RFC5444], by packet multiplexing process described in an Appendix to [RFC5444] by
protocols operating over the manet IP protocol and port numbers that protocols operating over the manet IP protocol and port numbers that
were allocated following [RFC5498]. were allocated by [RFC5498].
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], [RFC7188], [RFC7631], and [RFC7722], that use [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722], that use
the format of [RFC5444]. The ITU-T recommendation [G9903] also uses the format of [RFC5444]. The ITU-T recommendation [G9903] also uses
the format of [RFC5444] for encoding some of its control signals. In the format of [RFC5444] for encoding some of its control signals. In
developing these specifications, experience with the use of [RFC5444] developing these specifications, experience with the use of [RFC5444]
has been acquired, specifically with respect to how to write has been acquired, specifically with respect to how to write
specifications using [RFC5444] so as to ensure "forward specifications using [RFC5444] so as to ensure forward compatibility
compatibility" of a protocol with future extensions, to enable the of a protocol with future extensions, to enable the creation of
creation of efficient messages, and to enable the use of an efficient efficient messages, and to enable the use of an efficient and generic
and generic parser for all protocols using [RFC5444]. parser for all 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 inhibit the development of [RFC5444] in a manner that would inhibit the development of
interoperable protocol extensions, that would potentially lead to interoperable protocol extensions, that would potentially lead to
inefficiencies, or that would lead to incompatibilities with generic inefficiencies, or that would lead to incompatibilities with generic
parsers for [RFC5444]. While these uses were not all explicitly parsers for [RFC5444]. While these uses were not all explicitly
prohibited by [RFC5444], they should be strongly discouraged. This prohibited by [RFC5444], they are strongly discouraged. This
document is intended to prohibit such uses, to present experiences document is intended to prohibit such uses, to present experiences
from designing protocols using [RFC5444], and to provide these as from designing protocols using [RFC5444], and to provide these as
guidelines (with their rationale) for future protocol designs using guidelines (with their rationale) for future protocol designs using
[RFC5444]. [RFC5444].
1.2. RFC 5444 Features 1.2. RFC 5444 Features
[RFC5444] performs two main functions: [RFC5444] performs two main functions:
o It defines a packet/message format for use by MANET routing o It defines a packet/message format for use by MANET routing
protocols. As far as [RFC5444] is concerned, it is up to each protocols. As far as [RFC5444] is concerned, it is up to each
protocol that uses it to implement the required message parsing protocol that uses it to implement the required message parsing
and formation. It is natural, especially when implementing more and formation. It is natural, especially when implementing more
than one such protocol, to implement these processes using than one such protocol, to implement these processes using
protocol-independent packet/message creation and parsing protocol-independent packet/message creation and parsing
procedures, however this is not required by [RFC5444]. Some procedures, however this is not required by [RFC5444]. Some
comments in this document may be particularly applicable to such a comments in this document might be particularly applicable to such
case, but all that is required is that the messages passed to and a case, but all that is required is that the messages passed to
from protocols are correctly formatted, and that packets and from protocols are correctly formatted, and that packets
containing those messages are correctly formatted as described in containing those messages are correctly formatted as described in
the following point. the following point.
o It specifies, in its Appendix A combined with the intended usage o It specifies, in its Appendix A combined with the intended usage
in its Appendix B, a multiplexing and demultiplexing process in its Appendix B, a multiplexing and demultiplexing process
whereby an entity which may be referred to as the "RFC 5444 whereby an entity that can be referred to as the "RFC 5444
multiplexer" (in this document simply as the multiplexer, or the multiplexer" (in this document simply as the multiplexer, or the
demultiplexer when performing that function) manages packets that demultiplexer when performing that function) manages packets that
travel a single (logical) hop, and which contain messages that are travel a single (logical) hop, and that contain messages that are
owned by individual protocols. A packet may contain messages from owned by individual protocols. A packet can contain messages from
more than one protocol. This process, and its usage, is mandated more than one protocol. This process is mandated for use on the
for use on the manet UDP port and IP protocol (alternative means manet UDP port and IP protocol (alternative means for the
for the transport of packets) by [RFC5498]. The multiplexer is transport of packets) by [RFC5498]. The multiplexer is
responsible for creating packets and for parsing packet headers, responsible for creating packets and for parsing packet headers,
extracting messages, and passing them to the appropriate protocol extracting messages, and passing them to the appropriate protocol
according to their type (the first octet in the message). according to their type (the first octet in the message).
1.2.1. Packet/Message Format 1.2.1. Packet/Message Format
Among the characteristics and design objectives of the packet/message Among the characteristics and design objectives 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
skipping to change at page 4, line 46 skipping to change at page 4, line 46
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
(Type-Length-Value structures), followed by a set of messages. (Type-Length-Value structures), followed by a set of messages.
Each message has a well-defined structure consisting of a Message Each message has a well-defined structure consisting of a Message
Header (designed for making processing and forwarding decisions) Header (designed for making processing and forwarding decisions)
followed by a set of Message TLVs, and a set of (address, type, followed by a set of Message TLVs, 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 Packet Headers, Message simple and generic parsing logic for Packet Headers, Message
Headers, and message content. Headers, and message content.
A packet may include messages from different protocols, such as A packet can 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. networks where media contention can be significant.
o Its packets are designed to travel between two neighboring o Its packets are designed to travel between two neighboring
interfaces, which will result in a single decrement of the IPv4 interfaces, which will result in a single decrement of the IPv4
TTL or IPv6 hop limit. The Packet Header and any Packet TLVs may TTL or IPv6 hop limit. The Packet Header and any Packet TLVs can
thus convey information relevant to that link (for example, the thus convey information relevant to that link (for example, the
Packet Sequence Number can be used to count transmission successes Packet Sequence Number can be used to count transmission successes
across that link). Packets are designed to be constructed for a across that link). Packets are designed to be constructed for a
single hop transmission; a packet transmission following a single hop transmission; a packet transmission following a
successful packet reception is by design of a new packet that may successful packet reception is by design a new packet that can
include all, some, or none of the received messages, plus possibly include all, some, or none of the received messages, plus possibly
additional messages either received in separate packets, or additional messages either received in separate packets or
generated locally at that router. Messages may thus travel more generated locally at that router. Messages can thus travel more
than one hop, and are designed to carry end-to-end protocol than one hop and are designed to carry end-to-end protocol
signals. 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 without that information add information to an existing message without that information
rendering the message unparseable or unusable by a router that rendering the message unparseable or unusable by a router that
does not support the extension. An extension is typically of the does not support the extension. An extension is typically of the
protocol that created the message to be extended, for example protocol that created the message to be extended, for example
[RFC7181] adds information to the HELLO messages created by [RFC7181] adds information to the HELLO messages created by
[RFC6130]. However an extension may also be independent of the [RFC6130]. However an extension can also be independent of the
protocol, for example [RFC7182] can add ICV (Integrity Check protocol, for example [RFC7182] can add ICV (Integrity Check
Value) and timestamp information to any message (or to a packet, Value) and timestamp information to any message (or to a packet,
thus extending the [RFC5444] multiplexer). thus extending the [RFC5444] multiplexer).
Information, in the form of TLVs, can be added to the message as a Information, in the form of TLVs, can be added to the message as a
whole, such as the [RFC7182] integrity information, or may be whole, such as the [RFC7182] integrity information, or can be
associated with specific addresses in the message, such as the MPR associated with specific addresses in the message, such as the MPR
selection and link metric information added to HELLO messages by selection and link metric information added to HELLO messages by
[RFC7181]. An extension can also add addresses to a message. [RFC7181]. An extension can 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 common interface identifiers that need same interface) might have common interface identifiers 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 format for For example, [RFC5497] defines a generic TLV format for
representing time information (such as interval time or validity representing time information (such as interval time or validity
time). 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 hop 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
a message (thus enabling MANET-wide flooding of a message) without message (thus enabling MANET-wide flooding of a message) without
processing the body of the message. processing the body of the message.
1.2.2. Multiplexing and Demultiplexing 1.2.2. Multiplexing and Demultiplexing
The multiplexer (and demultiplexer) is defined in Appendix A of The multiplexer (and demultiplexer) is defined in Appendix A of
[RFC5444]. Its purpose is to allow multiple protocols to share the [RFC5444]. Its purpose is to allow multiple protocols to share the
same IP protocol or UDP port. That sharing was made necessary by the same IP protocol or UDP port. That sharing was made necessary by the
separation of [RFC6130] from [RFC7181] as separate protocols, and by separation of [RFC6130] from [RFC7181] as separate protocols, and by
the allocation of a single IP protocol and UDP port to all MANET the allocation of a single IP protocol and UDP port to all MANET
protocols, including those protocols, following [RFC5498], which protocols, including those protocols, following [RFC5498], which
states that "All interoperable protocols running on these well-known states that "All interoperable protocols running on these well-known
IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a
common format that enables one or more protocols to share the IANA common format that enables one or more protocols to share the IANA
allocations defined in this document unambiguously.". The allocations defined in this document unambiguously.". The
multiplexer is the mechanism in [RFC5444] that enables that sharing. multiplexer is the mechanism in [RFC5444] that enables that sharing.
The primary purposes of the multiplexer are to: The primary purposes of the multiplexer are to:
o Accept messages from MANET protocols, which also indicate over o Accept messages from MANET protocols, which also indicate over
which interface(s) the messages are to be sent, and to which which interface(s) the messages are to be sent, and to which
destination address. The latter may be a unicast address or the destination address. The latter can be a unicast address or the
"LL-MANET-Routers" link local multicast address defined in "LL-MANET-Routers" link local multicast address defined in
[RFC5498]. [RFC5498].
o Collect messages, possibly from multiple protocols, for the same o Collect messages, possibly from multiple protocols, for the same
interface and destination, into packets to be sent one logical interface and destination, into packets to be sent one logical
hop, and to send packets using the manet UDP port or IP protocol hop, and to send packets using the manet UDP port or IP protocol
defined in [RFC5498]. defined in [RFC5498].
o Extract messages from received packets, and pass them to their o Extract messages from received packets, and pass them to their
owning protocols. owning protocols.
skipping to change at page 6, line 46 skipping to change at page 6, line 46
The multiplexer's relationship is with the protocols that own the The multiplexer's relationship is with the protocols that own the
corresponding Message Types. Where those protocols have their own corresponding Message Types. Where those protocols have their own
relationships, for example as extensions, this is the responsibility relationships, for example as extensions, this is the responsibility
of the protocols. For example OLSRv2 [RFC7181] extends the HELLO of the protocols. For example OLSRv2 [RFC7181] extends the HELLO
messages created by NHDP [RFC6130]. However the multiplexer will messages created by NHDP [RFC6130]. However the multiplexer will
deliver HELLO messages to NHDP and will expect to receive HELLO deliver HELLO messages to NHDP and will expect to receive HELLO
messages from NHDP, the relationship between NHDP and OLSRv2 is messages from NHDP, the relationship between NHDP and OLSRv2 is
between those two protocols. between those two protocols.
The multiplexer is also responsible for the Packet Header, including The multiplexer is also responsible for the Packet Header, including
any Packet Sequence Number and Packet TLVs. It may accept some any Packet Sequence Number and Packet TLVs. It can accept some
additional instructions from protocols, pass additional information additional instructions from protocols, can pass additional
to protocols, and must follow some additional rules, see Section 4.4. information to protocols, and will follow some additional rules; see
Section 4.4.
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] that, if not
followed, makes forms of extensions of those protocols impossible, followed, make forms of extensions of those protocols impossible,
impedes the ability to generate efficient messages, or makes impede the ability to generate efficient messages, or make desirable
desirable forms of generic parsers impossible. forms of generic parsers impossible.
Each use of [RFC2119] key words (see Section 2) can be considered as
an update to [RFC5444]. In most cases these codify obvious best
practice, or constrain the use of [RFC5444] in the circumstances
where this specification is applicable (see Section 3). In a few
circumstances, operation of [RFC5444] is modified. These are all
circumstances that do not occur in its main current uses, in
particular by [RFC6130] and [RFC7181] (that might already include the
requirement, in particular through [RFC7181]). That such modifying
cases are an update to [RFC5444] is explicitly indicated in this
specification.
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].
Use of those key words applies in some cases directly to use of
[RFC5444] and applies to existing protocols using it, and applies in
some cases to future protocols that use or update [RFC5444] or update
existing protocols using it.
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
in particular the terms "packet", "Packet Header", "message", in particular the terms "packet", "Packet Header", "message",
"Message Header", "address", "Address Block", "TLV" and "TLV Block" "Message Header", "address", "Address Block", "TLV", and "TLV Block"
are to be interpreted as described therein. are to be interpreted as described therein.
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Full Type (of TLV) - As per [RFC5444], the 16-bit combination of the Full Type (of TLV) - As per [RFC5444], the 16-bit combination of the
TLV Type and Type Extension is given the symbolic name <tlv- TLV Type and Type Extension is given the symbolic name <tlv-
fulltype>, but is not assigned the term "Full Type", which is fulltype>, but is not assigned the term "Full Type", which is
however assigned by this document as standard terminology. however assigned by this document as standard terminology.
Owning Protocol - As per [RFC5444], for each Message Type, a Owning Protocol - As per [RFC5444], for each Message Type, a
protocol -- unless specified otherwise, the one making the IANA protocol -- unless specified otherwise, the one making the IANA
reservation for that Message Type -- is designated as the "owning reservation for that Message Type -- is designated as the "owning
protocol" of that Message Type. The (de)multiplexer inspects the protocol" of that Message Type. The (de)multiplexer inspects the
Message Type of each received message, and delivers each message Message Type of each received message, and delivers each message
to its corresponding "owning protocol". to its corresponding "owning protocol".
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 that are using the generic packet/message on how to design protocols that use the generic packet/message format
format defined in [RFC5444] which, if not followed, makes forms of defined in [RFC5444] that, if not followed, makes forms of extensions
extensions of those protocols impossible, impedes the ability to of those protocols impossible, impedes the ability to generate
generate efficient (small) messages, or makes desirable forms of efficient (small) messages, or makes desirable forms of generic
generic parsers impossible. The use of the [RFC5444] format is parsers impossible. The use of the [RFC5444] format is mandated by
mandated by [RFC5498] for all protocols running over the manet [RFC5498] for all protocols running over the manet protocol and port,
protocol and port, defined therein. Thus, the constraints in this defined therein. Thus, the constraints in this document apply to all
document apply to all protocols running over the manet protocol and protocols running over the manet protocol and port. The constraints
port. The constraints are strongly recommended for other uses of are strongly recommended for other uses of [RFC5444].
[RFC5444].
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:
skipping to change at page 8, line 38 skipping to change at page 9, line 9
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]. [RFC6130].
The third case is the normal case for a new protocol. The third case is the normal case for a new protocol.
A protocol extension may be either simply an update of the protocol A protocol extension can either be simply an update of the protocol
(the third case) or be a new protocol that also updates another (the third case) or be a new protocol that also updates another
protocol (the second case). An example of the latter is that OLSRv2 protocol (the second case). An example of the latter is that OLSRv2
[RFC7181] is a protocol that also extends the HELLO message owned by [RFC7181] is a protocol that also extends the HELLO message owned by
NHDP [RFC6130]; it thus is an example of both the second and third NHDP [RFC6130]; it thus is an example of both the second and third
cases (the latter using the OLSRv2 owned TC message). An extension cases (the latter using the OLSRv2 owned TC message). An extension
to [RFC5444], such as [RFC7182], is considered to be an extension to to [RFC5444], such as [RFC7182], is considered to be an extension to
all protocols. Protocols SHOULD be designed to enable extension by all protocols. Protocols SHOULD be designed to enable extension by
any of these means to be possible, and some of the rules in this any of these means to be possible, and some of the rules in this
document (in particular on Section 4.6 and Section 4.8) are to help document (in particular in Section 4.6 and Section 4.8) are to help
facilitate that. facilitate that.
4.2. Message and TLV Type Allocation 4.2. Message and TLV Type Allocation
Protocols SHOULD be conservative in the number of new Message Types Protocols SHOULD be conservative in the number of new Message Types
that they require, as the total available number of allocatable that they require, as the total available number of allocatable
Message Types is only 224. Protocol design SHOULD consider whether Message Types is only 224. Protocol design SHOULD consider whether
different functions can be implemented by differences in TLVs carried different functions can be implemented by differences in TLVs carried
in the same Message Type, rather than using multiple Message Types. in the same Message Type, rather than using multiple Message Types.
The TLV type space, although greater than the Message Type space, The TLV Type space, although greater than the Message Type space,
SHOULD also be used efficiently. The Full Type of a TLV occupies two SHOULD also be used efficiently. The Full Type of a TLV occupies two
octets, thus there are many more available TLV Full Types than there octets, thus there are many more available TLV Full Types than there
are Message Types. However, in some cases (currently LINK_METRIC are Message Types. However, in some cases (currently LINK_METRIC
from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all in the
global TLV type space) a TLV Type with a complete set of 256 TLV Full global TLV type space) a TLV Type with a complete set of 256 TLV Full
Types is defined (but not necessarily allocated). Types is defined (but not necessarily allocated).
Each Message Type has an associated block of Message-Type-specific Each Message Type has an associated block of Message-Type-specific
TLV Types (128 to 233, each of with 256 type extensions), both for TLV Types (128 to 233, each of with 256 type extensions), both for
Address Block TLV Types and Message TLV Types. TLV Types from within Address Block TLV Types and Message TLV Types. TLV Types from within
skipping to change at page 9, line 36 skipping to change at page 10, line 4
extensions) when a TLV is specific to a message. extensions) when a TLV is specific to a message.
The Expert Review guidelines in [RFC5444] are accordingly updated as The Expert Review guidelines in [RFC5444] are accordingly updated as
described in Section 8. described in Section 8.
4.3. Message Recognition 4.3. Message Recognition
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.
A message can be recognized as one that has been previously seen A protocol might need to recognize whether a message, especially a
(which may determine whether it is processed and/or forwarded) if it flooded message, is one that it has previously received, for example
contains sufficient information in its Message Header. A message to determine whether to process and/or forward it, or to discard it.
A message can be recognized as one that has been previously seen if
it contains sufficient information in its Message Header. A message
MUST be so recognized by the combination of all three of its Message MUST be so recognized by the combination of all three of its Message
Type, Originator Address and Message Sequence Number. The inclusion Type, Originator Address, and Message Sequence Number. The inclusion
of Message Type allows each protocol to manage its own Message of Message Type allows each protocol to manage its own Message
Sequence Numbers, and also allows for the possibility that different Sequence Numbers, and also allows for the possibility that different
Message Types may have greatly differing transmission rates. As an Message Types can have greatly differing transmission rates. As an
example of such use, [RFC7181] contains a general purpose process for example of such use, [RFC7181] contains a general purpose process for
managing processing and forwarding decisions, albeit one presented as managing processing and forwarding decisions, albeit one presented as
for use with MPR flooding. (Blind flooding can be handled similarly for use with MPR flooding. (Blind flooding can be handled similarly
by assuming that all other routers are MPR selectors; it is not by assuming that all other routers are MPR selectors; it is not
necessary in this case to differentiate between interfaces on which a necessary in this case to differentiate between interfaces on which a
message is received.) 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 model of how such information can be viewed is described in
Section 4.5 and Section 4.6. To use that model, addresses (for Section 4.5 and Section 4.6. To use that model, addresses (for
example of neighboring or otherwise known routers) SHOULD be recorded example of neighboring or otherwise known routers) SHOULD be recorded
in Address Blocks, not as data in TLVs. Recording addresses in TLV in Address Blocks, not as data in TLVs. Recording addresses in TLV
Value fields both breaks the model of addresses as identities and Value fields both breaks the model of addresses as identities and
associated information (attributes) and also inhibits address associated information (attributes) and also inhibits address
compression. However in some cases alternative addresses (e.g., compression. However in some cases alternative addresses (e.g.,
hardware addresses when the Address Block is recording IP addresses) hardware addresses when the Address Block is recording IP addresses)
MAY be carried as TLV Values. Note that a message contains a Message can be carried as TLV Values. Note that a message contains a Message
Address Length field that can be used to allow carrying alternative Address Length field that can be used to allow carrying alternative
message sizes, but only one length of addresses can be used in a message sizes, but only one length of addresses can be used in a
single message, in all Address Blocks and the Originator Address, and single message, in all Address Blocks and the Originator Address, and
is established by the router and protocol generating the message. is established by the router and protocol generating the message.
4.4. Message Multiplexing and Packets 4.4. Message Multiplexing and Packets
The multiplexer has to handle message multiplexing into packets and The multiplexer has to handle message multiplexing into packets and
their transmission, and packet reception and demultiplexing into their transmission, and packet reception and demultiplexing into
messages. The multiplexer and the protocols that use it are subject messages. The multiplexer and the protocols that use it are subject
to the following rules. to the following rules.
4.4.1. Packet Transmission 4.4.1. Packet Transmission
Packets are formed for transmission by: Packets are formed for transmission by:
o Outgoing messages are created by their owning protocol, and MAY be o Outgoing messages are created by their owning protocol and MAY be
modified by any extending protocols if the owning protocol permits modified by any extending protocols if the owning protocol permits
this. Messages MAY also be forwarded by their owning protocol. this. Messages MAY also be forwarded by their owning protocol.
It is strongly RECOMMENDED that messages are not modified in the It is strongly RECOMMENDED that messages are not modified in the
latter case, other than updates to their hop count and hop limit latter case, other than updates to their hop count and hop limit
fields, as described in Section 7.1.1 of [RFC5444]. Note that fields, as described in Section 7.1.1 of [RFC5444]. Note that
this includes having an identical octet representation, including this includes having an identical octet representation, including
not allowing a different TLV representation of the same not allowing a different TLV representation of the same
information. This is because it enables end to end authentication information. This is because it enables end-to-end authentication
that ignores (zeros) those two fields (only), as is done by for that ignores (zeros) those two fields (only), as is done by for
the Message TLV ICV (Integrity Check Value) calculations in the Message TLV ICV (Integrity Check Value) calculations in
[RFC7182]. Protocols are strongly RECOMMENDED to document their [RFC7182]. Protocols MUST document their behavior with regard to
behavior with regard to modifiability of messages. modifiability of messages.
o Outgoing messages are then sent to the multiplexer. The owning o Outgoing messages are then sent to the multiplexer. The owning
protocol MUST indicate which interface(s) the messages are to be protocol MUST indicate which interface(s) the messages are to be
sent on and their destination address. Note that packets travel sent on and their destination address. Note that packets travel
one hop; the destination is therefore either a link local one hop; the destination is therefore either a link local
multicast address, if the packet is being multicast, or the multicast address, if the packet is being multicast, or the
address of the neighbor interface to which the packet is sent. address of the neighbor interface to which the packet is sent.
o The owning protocol MAY request that messages are kept together in o The owning protocol MAY request that messages are kept together in
a packet; the multiplexer SHOULD respect this request if at all a packet; the multiplexer SHOULD respect this request if at all
possible. The multiplexer SHOULD combine messages that are sent possible. The multiplexer SHOULD combine messages that are sent
on the same interface in a packet, whether from the same of on the same interface in a packet, whether from the same or
different protocols, provided that in so doing the multiplexer different protocols, provided that in so doing the multiplexer
does not cause an IP packet to exceed the current MTU (Maximum does not cause an IP packet to exceed the current MTU (Maximum
Transmission Unit). Note that the multiplexer cannot fragment Transmission Unit). Note that the multiplexer cannot fragment
messages; creating suitable sized messages that will not cause the messages; creating suitable sized messages that will not cause the
MTU to be exceeded if sent in a single message packet is the MTU to be exceeded if sent in a single message packet is the
responsibility of the protocol generating the message. If a responsibility of the protocol generating the message. If a
larger message is created then only IP fragmentation is available larger message is created then only IP fragmentation is available
to allow the packet to be sent, and this is generally considered to allow the packet to be sent, and this is generally considered
undesirable, especially when transmission may be unreliable. undesirable, especially when transmission can be unreliable.
o The multiplexer MAY delay messages in order to assemble more o The multiplexer MAY delay messages in order to assemble more
efficient packets. It MUST respect any constraints on such delays efficient packets. It MUST respect any constraints on such delays
requested by the protocol if it is practical to do so. requested by the protocol if it is practical to do so.
o If requested by a protocol, the multiplexer MUST, and otherwise o If requested by a protocol, the multiplexer MUST, and otherwise
MAY, include a Packet Sequence Number in the packet. Such a MAY, include a Packet Sequence Number in the packet. Such a
request MUST be respected as long as the protocol is active. Note request MUST be respected as long as the protocol is active. Note
that the errata to [RFC5444], indicates that the Packet Sequence that the errata to [RFC5444] indicates that the Packet Sequence
Number SHOULD be specific to the interface on which the packet is Number SHOULD be specific to the interface on which the packet is
sent. This specification updates [RFC5444] by requiring that this sent. This specification updates [RFC5444] by requiring that this
sequence number MUST be specific to that interface and also that sequence number MUST be specific to that interface and also that
separate sequence numbers MUST be maintained for each destination separate sequence numbers MUST be maintained for each destination
to which packets are sent with included Packet Sequence Numbers. to which packets are sent with included Packet Sequence Numbers.
Addition of Packet Sequence Numbers MUST be consistent, i.e., for Addition of Packet Sequence Numbers MUST be consistent, i.e., for
each interface and destination the Packet Sequence Number MUST be each interface and destination the Packet Sequence Number MUST be
added to all packets or to none. added to all packets or to none.
o An extension to the multiplexer MAY add TLVs to the packet. It o An extension to the multiplexer MAY add TLVs to the packet. It
may also add TLVs to the messages, in which case it is considered MAY also add TLVs to the messages, in which case it is considered
as also extended the corresponding protocols. For example as also extended the corresponding protocols. For example
[RFC7182] can be used by the multiplexer to add Packet TLVs or [RFC7182] can be used by the multiplexer to add Packet TLVs or
Message TLVs, or by the protocol to add Message TLVs. Message TLVs, or by the protocol to add Message TLVs.
4.4.2. Packet Reception 4.4.2. Packet Reception
When a packet is received, the following steps are performed by the When a packet is received, the following steps are performed by the
demultiplexer and by protocols: demultiplexer and by protocols:
o The Packet Header and the organization into the messages that it o The Packet Header and the organization into the messages that it
skipping to change at page 12, line 15 skipping to change at page 12, line 32
o Each message MUST be sent to its owning protocol, or discarded if o Each message MUST be sent to its owning protocol, or discarded if
the Message Type is not recognized. The demultiplexer MUST also the Message Type is not recognized. The demultiplexer MUST also
make the Packet Header, and the source and destination addresses make the Packet Header, and the source and destination addresses
in the IP datagram that included the packet, available to the in the IP datagram that included the packet, available to the
protocol. protocol.
o The demultiplexer MUST remove any Message TLVs that were added by o The demultiplexer MUST remove any Message TLVs that were added by
an extension to the multiplexer. The message MUST be passed on to an extension to the multiplexer. The message MUST be passed on to
the protocol exactly as received from (another instance of) the the protocol exactly as received from (another instance of) the
protocol. This is in part an implementation detail. For example protocol. This is in part an implementation detail. For example
an implementation of [RFC7182] could add Message TLV either in the an implementation of the multiplexer and of [RFC7182] could add a
multiplexer or in the protocol; an implementation MUST ensure that Message TLV either in the multiplexer or in the protocol, and on
the message passed to a protocol is as it would be passed from reception remove it in the same place. An implementation MUST
that protocol by this implementation. ensure that the message passed to a protocol is as it would be
passed from that protocol by the same implementation, i.e., that
the combined implementation on a router is self-consistent, and
that messages included in packets by the multiplexer are
independent of this implementation detail.
o The owning protocol MUST verify each message for correctness, it o The owning protocol MUST verify each message for correctness; it
MUST allow any extending protocol(s) to also contribute to this MUST allow any extending protocol(s) to also contribute to this
verification. verification.
o The owning protocol MUST process each message. In some cases, o The owning protocol MUST process each message. In some cases,
which will be defined in the protocol specification, this which will be defined in the protocol specification, this
processing will determine that the message MUST be ignored. processing will determine that the message will be ignored.
Except in the latter case, the owning protocol MUST also allow any Except in the latter case, the owning protocol MUST also allow any
extending protocols to process the message. extending protocols to process the message.
o The owning protocol MUST manage the hop count and/or hop limit in o The owning protocol MUST manage the hop count and/or hop limit in
the message. It is RECOMMENDED that these are handled as the message. It is RECOMMENDED that these are handled as
described in Appendix B of [RFC5444]; they MUST be so handled if described in Appendix B of [RFC5444]; they MUST be so handled if
using hop count dependent TLVs such as those defined in [RFC5497]. using hop count dependent TLVs such as those defined in [RFC5497].
4.4.2.1. Other Information 4.4.2.1. Other Information
In addition to the messages between the multiplexer and the protocols In addition to the messages between the multiplexer and the protocols
in each direction, the following additional information, summarized in each direction, the following additional information, summarized
from other sections in this specification, can be exchanged. from other sections in this specification, can be exchanged.
o The packet source and destination addresses MUST be sent from o The packet source and destination addresses MUST be sent from
(de)multiplexer to protocol. (de)multiplexer to protocol.
o The Packet Header, including packet sequence number, MUST be sent o The Packet Header, including packet sequence number, MUST be sent
from (de)multiplexer to protocol if present. (An implementation from (de)multiplexer to protocol if present. (An implementation
may choose to only do so, or only report the packet sequence MAY choose to only do so, or only report the packet sequence
number, on request.) number, on request.)
o A protocol MAY require that all outgoing packets contain a packet o A protocol MAY require that all outgoing packets contain a packet
sequence number. sequence number.
o The interface over which a message is to be sent and its o The interface over which a message is to be sent and its
destination address MUST be sent from protocol to multiplexer. destination address MUST be sent from protocol to multiplexer.
The destination address may be a multicast address, in particular The destination address MAY be a multicast address, in particular
the LL-MANET-Routers link-local multicast address defined in the LL-MANET-Routers link-local multicast address defined in
[RFC5498]. [RFC5498].
o A request to keep messages together in one packet MAY be sent from o A request to keep messages together in one packet MAY be sent from
protocol to multiplexer. protocol to multiplexer.
o A requested maximum message delay MAY be sent from protocol to o A requested maximum message delay MAY be sent from protocol to
multiplexer. multiplexer.
The protocol SHOULD also be aware of the MTU that will apply to its The protocol SHOULD also be aware of the MTU that will apply to its
skipping to change at page 13, line 30 skipping to change at page 13, line 49
4.5. Messages, Addresses and Attributes 4.5. 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 a Full o Attributes of the message, each attribute consisting of a Full
Type, a length, and a Value (of that length). 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 Full o Attributes of each address, each attribute consisting of a Full
Type, a length, and a Value (of that length). 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 can be the same or different.
It is RECOMMENDED that a TLV Full Type MAY be defined so that there [RFC5444] requires that when a TLV Full Type is defined, then it MUST
MUST only be one TLV of that Full Type associated with the packet also be defined how to handle the cases of multiple TLVs of the same
(Packet TLV), message (Message TLV), or any value of any address type applying to the same information element - i.e., when more than
(Address Block TLV). Note that an address may appear more than once one Packet TLV of the same TLV Full Type is included in the same
in a message, but the restriction on associating TLVs with addresses Packet Header, when more than one Message TLV of the same TLV Full
covers all copies of that address. It is RECOMMENDED that addresses Type is included in the same Message TLV Block, or when more than one
are not repeated in a message. Address Block TLV of the same TLV Full Type applies to the same value
of any address. It is RECOMMEMDED that when defining a new TLV Full
Type that a rule of the following form is adopted.
o If used, there MUST only be only one TLV of that Full Type
associated with the packet(Packet TLV), message (Message TLV), or
any value of any address (Address Block TLV).
Note that this applies to address values; an address can appear more
than once in a message, but the restriction on associating TLVs with
addresses covers all copies of that address. It is RECOMMENDED that
addresses are not repeated in a message.
A conceptual way to view this information is described in Appendix A. A conceptual way to view this information is described in Appendix A.
4.6. Addresses Require Attributes 4.6. 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.
skipping to change at page 14, line 24 skipping to change at page 15, line 8
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].
These rules are: These rules are:
o A protocol MUST NOT assign any meaning to the presence or absence o A protocol MUST NOT assign any meaning to the presence or absence
of an address (either in a Message, or in a given Address Block in of an address (either in a Message or in a given Address Block in
a Message), to the ordering of addresses in an Address Block, or a Message), to the ordering of addresses in an Address Block, or
to the division of addresses among Address Blocks. to the division of addresses among Address Blocks.
o A protocol MUST NOT reject a message based on the inclusion of a o A protocol MUST NOT reject a message based on the inclusion of a
TLV of an unrecognized type. The protocol MUST ignore any such TLV of an unrecognized type. The protocol MUST ignore any such
TLVs when processing the message. The protocol MUST NOT remove or TLVs when processing the message. The protocol MUST NOT remove or
change any such TLVs if the message is to be forwarded unchanged. change any such TLVs if the message is to be forwarded unchanged.
o A protocol MUST NOT reject a message based on the inclusion of an o A protocol MUST NOT reject a message based on the inclusion of an
unrecognized Value in a TLV of a recognized type. The protocol unrecognized Value in a TLV of a recognized type. The protocol
skipping to change at page 15, line 10 skipping to change at page 15, line 42
Assigning a meaning to the presence, absence or location, of an Assigning a meaning to the presence, absence or location, of an
address would reduce the extensibility of the protocol, prevent the address would reduce the extensibility of the protocol, prevent the
approach to information representation described in Appendix A, and approach to information representation described in Appendix A, and
reduce the options available for message optimization described in reduce the options available for message optimization described in
Section 6. Section 6.
To consider how the simple presence of an address conveying To consider how the simple presence of an address conveying
information would have restricted the development of an extension, information would have restricted the development of an extension,
two examples, one actual (included in the base specification, but two examples, one actual (included in the base specification, but
could have been added later) and one hypothetical, are considered. which could have been added later) and one hypothetical, are
considered.
The basic function of NHDP's HELLO messages [RFC6130] is to indicate The basic function of NHDP's HELLO messages [RFC6130] is to indicate
that addresses are of neighbors, using the LINK_STATUS and that addresses are of neighbors, using the LINK_STATUS and
OTHER_NEIGHB TLVs. (The message may also indicate the routers own OTHER_NEIGHB TLVs. (The message can also indicate the router's own
addresses, which could also serve as a further example.) addresses, which could also serve as a further example.)
An extension to NHDP might decide to use the HELLO message to report An extension to NHDP might decide to use the HELLO message to report
that an address is one that could be used for a specialized purpose that an address is one that could be used for a specialized purpose
rather than for normal NHDP-based purposes. Such an example already rather than for normal NHDP-based purposes. Such an example already
exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB exists in the use of LOST Values in the LINK_STATUS and OTHER_NEIGHB
TLVs to report that an address is of a router known not to be a TLVs to report that an address is of a router known not to be a
neighbor. neighbor.
A future example could be to indicate that an address is to be added A future example could be to indicate that an address is to be added
to a "blacklist" of addresses not to be used. This would use a new to a "blacklist" of addresses not to be used. This would use a new
TLV (or a new Value of an existing TLV, see below). Assuming that no TLV (or a new Value of an existing TLV, see below). Assuming that no
other TLVs are attached to such blacklisted addresses, then an other TLVs are attached to such blacklisted addresses, then an
unmodified extension to NHDP would ignore those addresses, as unmodified extension to NHDP would ignore those addresses, as
required. (If however, for example, a LINK_STATUS or OTHER_NEIGHB required. (If however, for example, a LINK_STATUS or OTHER_NEIGHB
TLV with Value LOST were also attached to that address, then the TLV with Value LOST were also attached to that address, then the
receiving router would process that address for that TLV.) If NHDP receiving router would process that address for that TLV.) If NHDP
had been designed so that just the presence of an address indicated a had been designed so that just the presence of an address indicated a
neighbor, this blacklist extension would not be possible. neighbor, this blacklist extension would not be possible.
Rejecting a message because it contains an unrecognized TLV Type, or Rejecting a message because it contains an unrecognized TLV Type or
an unrecognized TLV Value, reduces the extensibility of the protocol. an unrecognized TLV Value reduces the extensibility of the protocol.
For example, OLSRv2 [RFC7181] is, among other things, an extension to For example, OLSRv2 [RFC7181] is, among other things, an extension to
NHDP. It adds information to addresses in an NHDP HELLO message NHDP. It adds information to addresses in an NHDP HELLO message
using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP, for
example to support Simplified Multicast Flooding (SMF) [RFC6621], example to support Simplified Multicast Flooding (SMF) [RFC6621],
must still process the HELLO message, ignoring the LINK_METRIC TLVs. will still process the HELLO message, ignoring the LINK_METRIC TLVs.
Also, the blacklisting described in the example above could be Also, the blacklisting described in the example above could be
signaled not with a new TLV, but with a new Value of a LINK_STATUS or signaled not with a new TLV, but with a new Value of a LINK_STATUS or
OTHER_NEIGHB TLV (requiring an IANA allocation as described in OTHER_NEIGHB TLV (requiring an IANA allocation as described in
[RFC7188]), as is already done in the LOST case. [RFC7188]), as is already done in the LOST case.
The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an
extension to OLSRv2 that can interoperate with unextended instances extension to OLSRv2 that can interoperate with unextended instances
of OLSRv2, would not have been possible without these restrictions, of OLSRv2, would not have been possible without these restrictions,
which were applied to NHDP and OLSRv2 by [RFC7181]. which were applied to NHDP and OLSRv2 by [RFC7181].
These restrictions do not, however, mean that added information is These restrictions do not, however, mean that added information is
completely ignored for purposes of the base protocol. Suppose that a completely ignored for purposes of the base protocol. Suppose that a
faulty implementation of OLSRv2 (including NHDP) creates a HELLO faulty implementation of OLSRv2 (including NHDP) creates a HELLO
message that assigns two different values of the same link metric to message that assigns two different values of the same link metric to
an address, something that is not permitted by [RFC7181]. A an address, something that is not permitted by [RFC7181]. A
receiving OLSRv2-aware implementation of NHDP will reject such a receiving OLSRv2-aware implementation of NHDP will reject such a
message, even though a receiving OLSRv2-unaware implementation of message, even though a receiving OLSRv2-unaware implementation of
NHDP will process it. This is because the OLSRv2-aware NHDP will process it. This is because the OLSRv2-aware
implementation has access to additional information, that the HELLO implementation has access to additional information, that the HELLO
message is definitely invalid, and the message is best ignored, as it message is definitely invalid and the message is best ignored, as it
is unknown what other errors it may contain. is unknown what other errors it might contain.
4.7. TLVs 4.7. TLVs
Within a message, the attributes are represented by TLVs. Within a message, the attributes are represented by TLVs.
Particularly for Address Block TLVs, different TLVs may represent the Particularly for Address Block TLVs, different TLVs can represent the
same information. For example, using the LINK_STATUS TLV defined in same information. For example, using the LINK_STATUS TLV defined in
[RFC6130], if some addresses have Value SYMMETRIC and some have Value [RFC6130], if some addresses have Value SYMMETRIC and some have Value
HEARD, arranged in that order, then this information can be HEARD, arranged in that order, then this information can be
represented using two single value TLVs or one multivalue TLV. The represented using two single value TLVs or one multivalue TLV. The
latter can be used even if the addresses are not so ordered. latter can be used even if the addresses are not so ordered.
A protocol MAY use any representation of information using TLVs that A protocol MAY use any representation of information using TLVs that
convey the required information. A protocol SHOULD use an efficient convey the required information. A protocol SHOULD use an efficient
representation, but this is a quality of implementation issue. A representation, but this is a quality of implementation issue. A
protocol MUST recognize any permitted representation of the protocol MUST recognize any permitted representation of the
information; even if it chooses to (for example) only use multivalue information; even if it chooses to (for example) only use multivalue
TLVs, it must recognize single value TLVs (and vice versa). TLVs, it MUST recognize single value TLVs (and vice versa).
A protocol defining new TLVs MUST respect the naming and A protocol defining new TLVs MUST respect the naming and
organizational rules in [RFC7631]. It SHOULD follow the guidance in organizational rules in [RFC7631]. It SHOULD follow the guidance in
[RFC7188], in particular see Section 6.3. (This specification does [RFC7188], in particular see Section 6.3. (This specification does
not however relax the application of [RFC7188] where it is mandated.) not however relax the application of [RFC7188] where it is mandated.)
4.8. Message Integrity 4.8. 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 reject a message based on the inclusion Values, a protocol MUST NOT reject a message based on the inclusion
of a TLV of an unrecognized type. The protocol MUST ignore any such of a TLV of an unrecognized type. The protocol MUST ignore any such
TLVs when processing the message. The protocol MUST NOT remove or TLVs when processing the message. The protocol MUST NOT remove or
change any such TLVs if the message is to be forwarded unchanged. change any such TLVs if the message is to be forwarded unchanged.
Such behavior would have the consequences that: 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_WILLING
to HELLO messages (created by NHDP, [RFC6130], of which it is in TLV to HELLO messages (created by NHDP, [RFC6130], of which it is
part an extension) to recognize this case (and for other reasons). in part an extension) to recognize this case (and for other
reasons).
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 hop 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
This section concerns the properties of the format defined in This section concerns the properties of the format defined in
[RFC5444] itself, rather than the properties of protocols using it. [RFC5444] itself, rather than the properties of protocols using it.
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:
skipping to change at page 17, line 33 skipping to change at page 18, line 25
o Message flags field (4 bits, 4 used) that manages the contents of o Message flags field (4 bits, 4 used) that manages the contents of
the Message Header. the Message Header.
o Address Block flags field (8 bits, 4 used) that manages the o Address Block flags field (8 bits, 4 used) that manages the
contents of an Address Block. contents of an Address Block.
o TLV flags field (8 bits, 5 used) that manages the contents of a o TLV flags field (8 bits, 5 used) that manages the contents of a
TLV. 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, field lengths, or whether a field has
has one or multiple values in it. 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 stated as "are RESERVED and SHOULD each be cleared ('0') fields are stated as "are RESERVED and SHOULD each be cleared ('0')
on transmission and SHOULD be ignored on reception". For the on transmission and SHOULD be ignored on reception". For the
avoidance of any compatibility issues, for version number 0 this is avoidance of any compatibility issues, for version number 0 this is
updated to "MUST each be cleared ('0') on transmission and MUST be updated to "MUST each be cleared ('0') on transmission and MUST be
ignored on reception". ignored on reception".
If a specification updating [RFC5444] introduces new flags in one of If a specification updating [RFC5444] introduces new flags in one of
the flags fields of a packet, Address Block or TLV (there being no the flags fields of a packet, Address Block or TLV (there being no
unused flags in the message flags field), the following rules MUST be unused flags in the message flags field), the following rules MUST be
followed: 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, Address Block or TLV, and MUST NOT be used to indicate any packet, Address Block, or TLV. They MUST NOT be used to indicate
other semantics, such as message forwarding behavior. any other semantics, such as message forwarding behavior.
An update that would be incompatible with the current specification An update that would be incompatible with the current specification
of [RFC5444] should not be created unless there is a pressing reason of [RFC5444] SHOULD NOT be created unless there is a pressing reason
for it that cannot be satisfied using the current specification for it that cannot be satisfied using the current specification
(e.g., by use of a suitable Message TLV). (e.g., by use of a suitable Message TLV or Address Block TLV).
During the development of [RFC5444], and since publication thereof, 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 proposals were, after due consideration, not accepted, for a These proposals were, after due consideration, not accepted for a
number of reasons. These reasons include that message forwarding, in number of reasons. These reasons include that message forwarding, in
particular, is protocol-specific; for example [RFC7181] forwards particular, is protocol-specific; for example [RFC7181] forwards
messages using its MPR (Multi-Point Relay) mechanism, rather than a messages using its MPR (Multi-Point Relay) mechanism rather than a
"blind" flooding mechanism. (These proposals were made during the "blind" flooding mechanism. (These proposals were made during the
development of [RFC5444] when there were still unused message flags. development of [RFC5444] when there were still unused message flags.
Later addition of a 4 bit Message Address Length field later left no Later addition of a 4-bit Message Address Length field later left no
unused message flags, but other flags fields still have unused unused message flags, but other flags fields still have unused
flags.) flags.)
6. Message Efficiency 6. Message Efficiency
The ability to organize addresses into different, or the same, The ability to organize addresses into the same or different Address
Address Blocks, as well as to change the order of addresses within an Blocks and to change the order of addresses within an Address Block,
Address Block, and the flexibility of the TLV specification, enables and the flexibility of the TLV specification, enables avoiding
avoiding unnecessary repetition of information, and consequently can unnecessary repetition of information, and consequently can generate
generate smaller messages. No algorithms for address organization or smaller messages. No algorithms for address organization or
compression or for TLV usage are given in [RFC5444], any algorithms compression or for TLV usage are given in [RFC5444]; any algorithms
that leave the information content unchanged MAY be used when that leave the information content unchanged MAY be used when
generating a message. See also Appendix B. generating a message. See also Appendix B.
6.1. Address Block Compression 6.1. Address Block Compression
[RFC5444] allows the addresses in an Address Block to be compressed. [RFC5444] allows the addresses in an Address Block to be compressed.
A protocol generating a message SHOULD compress addresses as much as A protocol generating a message SHOULD compress addresses as much as
it can. it can.
Addresses in an Address Block consist of a Head, a Mid, and a Tail, Addresses in an Address Block consist of a Head, a Mid, and a Tail,
skipping to change at page 19, line 32 skipping to change at page 20, line 22
greatest efficiency, have a 4 octet head, a 4 octet Mid, and an 8 greatest efficiency, have a 4 octet head, a 4 octet Mid, and an 8
octet Tail. (They could have a larger Head and/or Tail and a octet Tail. (They could have a larger Head and/or Tail and a
smaller Mid if the prefixes have any octets in common.) smaller Mid if the prefixes have any octets in common.)
Putting addresses into a message efficiently also has to consider: Putting addresses into a message efficiently also has to consider:
o The split of the addresses into Address Blocks. o The split of the addresses into Address Blocks.
o The order of the addresses within the Address Blocks. o The order of the addresses within the Address Blocks.
This split and/or ordering is for efficiency only, it does not This split and/or ordering is for efficiency only; it does not
provide any information. The split of the addresses affects both the provide any information. The split of the addresses affects both the
address compression and the TLV efficiency (see Section 6.2), the address compression and the TLV efficiency (see Section 6.2); the
order of the addresses within an Address Block affects only the TLV order of the addresses within an Address Block affects only the TLV
efficiency. However using more Address Blocks than is needed can efficiency. However using more Address Blocks than is needed can
increase the message size due to the overhead of each Address Block increase the message size due to the overhead of each Address Block
and the following TLV Block, and/or if additional TLVs are now and the following TLV Block, and/or if additional TLVs are now
required. required.
The order of addresses can be as simple as sorting the addresses, but 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 if many addresses have the same TLV Types attached, it might be more
useful to put these addresses together, either within the same useful to put these addresses together, either within the same
Address Block as other addresses, or in a separate Address Block. A Address Block as other addresses or in a separate Address Block. A
separate Address Block might also improve address compression, for separate Address Block might also improve address compression, for
example if more than one address form is used (such as from example if more than one address form is used (such as from
independent subnets). An example of the possible use of address independent subnets). An example of the possible use of address
ordering is a HELLO message from [RFC6130] which could be generated ordering is a HELLO message from [RFC6130] that could be generated
with local interface addresses first and neighbor addresses later. with local interface addresses first and neighbor addresses later.
These could be in separate Address Blocks. These could be in separate Address Blocks.
6.2. TLVs 6.2. TLVs
The main opportunities for creating more efficient messages when The main opportunities for creating more efficient messages when
considering TLVs are in Address Block TLVs, rather than Message TLVs. considering TLVs are in Address Block TLVs rather than Message TLVs.
The approaches described here apply to each Address Block.
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 the Address Block).
When associated with more than one address, a TLV may be single value When associated with more than one address, a TLV can be single value
(associating the same attribute with each address) or multivalue (associating the same attribute with each address) or multivalue
(associating a separate attribute with each address). (associating a separate attribute with each address).
The simplest to implement approach is to use multivalue 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 might 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, and beyond the scope of this document to describe straightforward, and beyond the scope of this document to describe
exactly how) to order all addresses in HELLO message as specified exactly how) to order all addresses in HELLO message as specified
in [RFC6130] so that all TLVs used only cover contiguous 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 specified in OLSRv2 [RFC7181] is also added. the LINK_METRIC TLV specified in OLSRv2 [RFC7181] 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 value TLVs. 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 value TLVs can enough addresses, sorted appropriately, two single value TLVs can
be more efficient than one multivalue TLV. If only one Value is be more efficient than one multivalue TLV. If only one Value is
involved, such as NHDP in a steady state with LINK_STATUS equal to involved, such as NHDP in a steady state with LINK_STATUS equal to
SYMMETRIC in all cases, then one single value TLV SHOULD always be SYMMETRIC in all cases, then one single value TLV SHOULD 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 one multivalue TLVs. It is however more efficient to do this with one multivalue
LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED. LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED.
In general, use of UNSPECIFIED Values allows use of fewer TLVs and In general, use of UNSPECIFIED Values allows use of fewer TLVs and
thus often an efficiency gain; however a long run of consecutive thus often an efficiency gain; however a long run of consecutive
UNSPECIFIED Values (more than the overhead of a TLV) may make more UNSPECIFIED Values (more than the overhead of a TLV) can make more
TLVs more efficient. TLVs more efficient.
Some other TLVs may need a different approach. As noted in Some other TLVs might need a different approach. As noted in
[RFC7188], but implicitly permissible before then, the LINK_METRIC [RFC7188], but implicitly permissible before then, the LINK_METRIC
TLV, defined in [RFC7181], has two octet Values whose first four bits TLV, defined in [RFC7181], has two octet Values whose first four bits
are flags indicating whether the metric applies in four cases; if are flags indicating whether the metric applies in four cases; if
these are all zero then the metric does not apply in this case, which these are all zero then the metric does not apply in this case, which
is thus the equivalent of an UNSPECIFIED Value. is thus the equivalent of an UNSPECIFIED Value.
[RFC7188] required that protocols that extend [RFC6130] and [RFC7181] [RFC7188] requires that protocols that extend [RFC6130] and [RFC7181]
allow unspecified values in TLVs where applicable. It is here allow unspecified values in TLVs where applicable; it is here
RECOMMENDED that all protocols follow that advice, and use the same RECOMMENDED that all protocols follow that advice. In particular it
value (255). In particular, when defining any Address Block TLV with is RECOMMENDED that when defining an Address Block TLV with discrete
discrete Values that an UNSPECIFIED Value is defined, and that a Values that an UNSPECIFIED Value is defined with the same value
modified approach is used where possible for other Address Block (255); and that a modified approach is used where possible for other
TLVs, for example as is done for a LINK_METRIC TLV (though not Address Block TLVs, for example as is done for a LINK_METRIC TLV
necessarily using that exact approach). (though not necessarily using that exact approach).
It might be argued that provision of an unspecified value (of any It might be argued that provision of an unspecified value (of any
form) to allow an Address Block TLV to cover unaffected addresses is form) to allow an Address Block TLV to cover unaffected addresses is
not always necessary because addresses can be reordered to avoid not always necessary because addresses can be reordered to avoid
this. However ordering addresses to avoid this for all TLVs that may this. However ordering addresses to avoid this for all TLVs that
be used is not, in general, possible. might be used is not, in general, possible.
In addition, [RFC7188] RECOMMENDS that if a TLV Value (per address In addition, [RFC7188] recommends that if a TLV Value (per address
for an Address Block TLV) has a single-length that does not match the for an Address Block TLV) has a single-length that does not match the
defined length for that TLV Type, then the following rules are defined length for that TLV Type, then the following rules are
adopted: adopted:
o If the received single-length is greater than the expected single- o If the received single-length is greater than the expected single-
length, then the excess octets MUST be ignored. length, then the excess octets MUST be ignored.
o If the received single-length is less than the expected single- o If the received single-length is less than the expected single-
length, then the absent octets MUST be considered to have all bits length, then the absent octets MUST be considered to have all bits
cleared (0). cleared (0).
This specification RECOMMENDEDS a similar rule for all protocols
defining new TLVs.
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], whose recommendations for how to design protocols using [RFC5444], whose
security considerations apply. security considerations apply.
If the recommendation in Section 4.4.1 that messages are not modified If the recommendation in Section 4.4.1 that messages are not modified
(except for hop count and hop limit) when forwarded is followed, then (except for hop count and hop limit) when forwarded is followed, then
the security framework for [RFC5444] specified in [RFC7182] can be the security framework for [RFC5444] specified in [RFC7182] can be
used in full. If that recommendation is not followed, then the used in full. If that recommendation is not followed, then the
skipping to change at page 24, line 19 skipping to change at page 25, line 19
Discovery Protocol (NHDP) Extension TLVs", RFC 7188, Discovery Protocol (NHDP) Extension TLVs", RFC 7188,
April 2014. April 2014.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for [RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for
the Optimized Link State Routing Protocol Version 2 the Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7722, December 2015. (OLSRv2)", RFC 7722, December 2015.
Appendix A. Information Representation Appendix A. Information Representation
This section describes a conceptual way to consider the information This section describes a conceptual way to consider the information
in a message. It may be used as the basis of an approach to parsing, in a message. It can be used as the basis of an approach to parsing
or creating, a message to, or from, the information that it contains, a message from the information that it contains and to creating a
or is to contain. However there is no requirement that a protocol message from the information that it is to contain. However there is
does so. This approach may be used either to inform a protocol no requirement that a protocol does so. This approach can be used
design, or by a protocol (or generic parser) implementer. either to inform a protocol design, or by a protocol (or generic
parser) implementer.
A message (excluding the Message Header) can be represented by two, A message (excluding the Message Header) can be represented by two,
possibly multivalued, maps: possibly multivalued, maps:
o Message: (Full Type) -> (length, Value) o Message: (Full Type) -> (length, Value)
o Address: (address, Full Type) -> (length, Value) o Address: (address, Full 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 Full Type. Output: list of (length, Value) o Input: address and Full Type. Output: list of (length, Value)
pairs. Note that for most Full Types it will be known in advance pairs. Note that for most Full Types it will be known in advance
that this list will have length zero or one. The list of 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: Full Type. Output: list of (address, length, Value) o Input: Full Type. Output: list of (address, length, Value)
triples. As this list length may be significant, a possible triples. As this list length can 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 might relate to, for example,
the ordering of output lists. the ordering of output lists.
Appendix B. Automation Appendix B. 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 Address Block separation) and TLV changes (of number, (ordering and Address Block separation) and TLV changes (of number,
single- or multi- valuedness and use of unspecified values) to create single- or multi- valuedness, and use of unspecified values) to
more compact messages. The possible gain depends on the efficiency create more compact messages. The possible gain depends on the
of the original message creation, and the specific details of the efficiency of the original message creation and the specific details
message. Note that this process cannot be TLV Type independent, for of the message. Note that this process cannot be TLV Type
example a LINK_METRIC TLV has a more complicated Value structure than independent; for example a LINK_METRIC TLV has a more complicated
a LINK_STATUS TLV does if using UNSPECIFIED Values. Value structure than a LINK_STATUS TLV does if using UNSPECIFIED
Values.
Such a protocol-independent optimizer MAY be used by the router Such a protocol-independent optimizer MAY be used by the router
generating a message, but MUST NOT be used on a message that is generating a message, but MUST NOT be used on a message that is
forwarded unchanged by a router. forwarded unchanged by a router.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
 End of changes. 95 change blocks. 
177 lines changed or deleted 220 lines changed or added

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