draft-ietf-manet-rfc5444-usage-02.txt   draft-ietf-manet-rfc5444-usage-03.txt 
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, 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: September 1, 2016 U. Herberg Expires: October 7, 2016 U. Herberg
H. Rogge H. Rogge
Fraunhofer FKIE Fraunhofer FKIE
February 29, 2016 April 5, 2016
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-02 draft-ietf-manet-rfc5444-usage-03
Abstract Abstract
This document updates the generalized MANET packet/message format, This document updates the generalized MANET packet/message format,
specified in RFC 5444, by providing rules and recommendations for how specified in RFC 5444, by providing rules and recommendations for how
protocols can use that packet/message format. In particular, the protocols can use that packet/message format. In particular, the
mandatory rules prohibit a number of uses of RFC 5444 that have been mandatory rules prohibit a number of uses of RFC 5444 that have been
suggested in various proposals, and which would have led to suggested in various proposals, and which would have led to
interoperability problems, to the impediment of protocol extension interoperability problems, to the impediment of protocol extension
development, and to an inability to use generic RFC 5444 parsers. development, and to an inability to use generic RFC 5444 parsers.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 1, 2016. This Internet-Draft will expire on October 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 18 skipping to change at page 2, line 18
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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.3. Status of This Document . . . . . . . . . . . . . . . . . 5 1.2.1. Packet/Message Format . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Multiplexing and Demultiplexing . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 1.3. Status of This Document . . . . . . . . . . . . . . . . . 6
4. Information Transmission . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Where to Record Information . . . . . . . . . . . . . . . 6 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 7 4. Information Transmission . . . . . . . . . . . . . . . . . . . 7
4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 9 4.1. Where to Record Information . . . . . . . . . . . . . . . 7
4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 9 4.2. Packets and Messages . . . . . . . . . . . . . . . . . . . 9
4.5. Information Representation . . . . . . . . . . . . . . . . 11 4.3. Messages, Addresses and Attributes . . . . . . . . . . . . 10
4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Addresses Require Attributes . . . . . . . . . . . . . . . 11
4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 13 4.5. Information Representation . . . . . . . . . . . . . . . . 13
5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 14
6.1. Address Block Compression . . . . . . . . . . . . . . . . 14 5. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Message Efficiency . . . . . . . . . . . . . . . . . . . . . . 16
6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Address Block Compression . . . . . . . . . . . . . . . . 16
6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.3. TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.4. Automation . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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, but did not quite succeed in, providing a packet/message
format accommodating for diverse protocol extensions. [RFC5444] was format accommodating for diverse protocol extensions. [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
skipping to change at page 3, line 37 skipping to change at page 3, line 37
of [RFC5444] for encoding some of its control signals. In developing of [RFC5444] for encoding some of its control signals. In developing
these specifications, experience with the use of [RFC5444] has been these specifications, experience with the use of [RFC5444] has been
acquired, specifically with respect to how to write specifications acquired, specifically with respect to how to write specifications
using [RFC5444] so as to ensure "forward compatibility" of a protocol using [RFC5444] so as to ensure "forward compatibility" of a protocol
with future extensions, to enable the creation of efficient messages, with future extensions, to enable the creation of efficient messages,
and to enable the use of an efficient and generic parser for all and to enable the use of an efficient and generic parser for all
protocols using [RFC5444]. 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, would potentially lead to interoperable protocol extensions, that would potentially lead to
inefficiencies, or 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 should be 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
Among the characteristics, and design criteria, of the packet/message [RFC5444] performs two main functions:
o It defines a packet/message format for use by MANET routing
protocols. Although not required by [RFC5444], it is natural to
implement this using protocol-independent packet/message creation
and parsing processes.
o It specifies, in its Appendix A combined with the intended usage
in its Appendix B, a multiplexing and demultiplexing process
whereby an entity which may be referred to as the "RFC 5444
multiplexer" (in this document, simply as the multiplexer, or
demultiplexer when performing that function) manages packets that
travel a single (logical) hop, and which contain messages that are
owned by individual protocols. A packet may contain messages from
more than one protocol. This process, and its usage, is mandated
for use on the "manet" UDP port and IP protocol (alternative means
for the transport of packets) by [RFC5498].
1.2.1. Packet/Message Format
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
signals. signals.
o It defines a packet as a Packet Header with a set of Packet TLVs o It defines a packet as a Packet Header with a set of Packet TLVs
(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 may include messages from different protocols, such as
[RFC6130] and [RFC7181], in a single transmission. This was [RFC6130] and [RFC7181], in a single transmission. This was
observed in [RFC3626] to be beneficial, especially in wireless observed in [RFC3626] to be beneficial, especially in wireless
networks where media contention may be significant. [RFC5444] networks where media contention may be significant.
defines a multiplexing process to achieve this that is mandated by
[RFC5498] for use on the manet IP port and UDP port. This makes
the contents of the Packet Header, which may also contain Packet
TLVs, and the transmission of packets over UDP or directly over
IP, the responsibility of this multiplexing process.
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/increment of interfaces, which will result in a single decrement/increment of
the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet
TLVs should convey information relevant to that link (for example, TLVs may thus convey information relevant to that link (for
the Packet Sequence Number can be used to count transmission example, the Packet Sequence Number can be used to count
successes across that link). Packets are not retransmitted, a transmission successes across that link). Packets are designed to
packet transmission following a successful packet reception may be constructed for a single hop transmission; a packet
include all, some, or none of the received messages, plus possibly transmission following a successful packet reception is by design
additional messages received in separate packets or generated at of a new packet that may include all, some, or none of the
that router. Messages may thus travel more than one hop, and are received messages, plus possibly additional messages either
designed to carry end-to-end protocol signals. received in separate packets, or generated locally at that router.
Messages may thus travel more than one hop, and are designed to
carry end-to-end protocol signals.
o It supports "internal extensibility" using TLVs; an extension can o It supports "internal extensibility" using TLVs; an extension can
add information to an existing message 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 may 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] multiplexing process). thus extending the [RFC5444] multiplexer).
Information can be added to the message as a whole, such as the Information, in the form of TLVs, can be added to the message as a
[RFC7182] integrity information, or may be associated with whole, such as the [RFC7182] integrity information, or may be
specific addresses in the message, such as the MPR selection and associated with specific addresses in the message, such as the MPR
link metric information added to HELLO messages by [RFC7181]. An selection and link metric information added to HELLO messages by
extension may 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) may 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 message (thus enabling MANET-wide flooding of a message) without a message (thus enabling MANET-wide flooding of a message) without
processing the body of the message. processing the body of the message.
1.2.2. Multiplexing and Demultiplexing
The primary purposes of the multiplexer are to:
o Accept messages from MANET protocols, which also indicate over
which interface(s) the messages are to be sent, and to which
destination address. The latter may be a unicast address or the
"LL-MANET-Routers" link local multicast address defined in
[RFC5498].
o Collect messages, possibly from multiple protocols, for the same
interface and destination, into packets to be sent one logical
hop, and to send packets using the "manet" UDP port or IP protocol
defined in [RFC5498].
o Extract messages from received packets, and pass them to their
owning protocols.
The multiplexer is also responsible for the Packet Header, including
any Packet Sequence Number and Packet TLVs. It may accept some
additional instructions from protocols, pass additional information
to protocols, and must follow some additional rules, see Section 4.2.
1.3. Status of This Document 1.3. Status of This Document
This document updates [RFC5444], and is intended for publication as a This document updates [RFC5444], and is intended for publication as a
Proposed Standard (rather than as Informational) because it specifies Proposed Standard (rather than as Informational) because it specifies
and mandates constraints on the use of [RFC5444] which, if not and mandates constraints on the use of [RFC5444] which, if not
followed, makes forms of extensions of those protocols impossible, followed, makes forms of extensions of those protocols impossible,
impedes the ability to generate efficient messages, or makes impedes the ability to generate efficient messages, or makes
desirable forms of generic parsers impossible. desirable forms of generic parsers impossible.
2. Terminology 2. Terminology
skipping to change at page 5, line 45 skipping to change at page 6, line 39
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
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:
Owning Protocol - As per [RFC5444], for each Message Type, a
protocol -- unless specified otherwise, the one making the IANA
reservation for that Message Type -- is designated as the "owning
protocol" of that Message Type. The (de)multiplexer inspects the
Message Type of each received message, and delivers each message
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 which are using the generic packet/message on how to design protocols which are using the generic packet/message
format defined in [RFC5444] which, if not followed, makes forms of format defined in [RFC5444] which, if not followed, makes forms of
extensions of those protocols impossible, impedes the ability to extensions of those protocols impossible, impedes the ability to
generate efficient (small) messages, or makes desirable forms of generate efficient (small) messages, or makes desirable forms of
generic parsers impossible. The use of this format is mandated by generic parsers impossible. The use of the [RFC5444] format is
[RFC5498] for all protocols running over the manet protocol and port mandated by [RFC5498] for all protocols running over the manet
number, defined therein. Thus, the constraints in this document protocol and port number, defined therein. Thus, the constraints in
apply to all protocols running over the manet protocol and port this document apply to all protocols running over the manet protocol
number. and port number.
4. Information Transmission 4. Information Transmission
Protocols need to transmit information from one instance implementing Protocols need to transmit information from one instance implementing
the protocol to another. the protocol to another.
4.1. Where to Record Information 4.1. Where to Record Information
A protocol has the following choices as to where to put information A protocol has the following choices as to where to put information
for transmission: for transmission:
skipping to change at page 6, line 31 skipping to change at page 7, line 38
o In a TLV to be added to the Packet Header. o In a TLV to be added to the Packet Header.
o In a message of a type owned by another protocol. o In a message of a type owned by another protocol.
o In a message of a type owned by the protocol. o In a message of a type owned by the protocol.
The first case (a Packet TLV) can only be used when the information The first case (a Packet TLV) can only be used when the information
is to be carried one hop. It SHOULD only be used either where the is to be carried one hop. It SHOULD only be used either where the
information relates to the packet as a whole (for example packet information relates to the packet as a whole (for example packet
integrity check values and timestamps, as specified in [RFC7182]) or integrity check values and timestamps, as specified in [RFC7182]) or
if the information is of expected wider application than the single if the information is of expected wider application than a single
protocol. A protocol can also request that the Packet Header include protocol. A protocol can also request that the Packet Header include
Packet Sequence Numbers, but does not control those numbers. Packet Sequence Numbers, but does not control those numbers.
The second case (in a message of a type owned by another protocol) is The second case (in a message of a type owned by another protocol) is
only possible if the adding protocol is an extension to the owning only possible if the adding protocol is an extension to the owning
protocol; for example OLSRv2 [RFC7181] is an extension of NHDP protocol; for example OLSRv2 [RFC7181] is an extension of NHDP
[RFC6130]. While this is not the most common case, protocols SHOULD [RFC6130]. While this is not the most common case, protocols SHOULD
be designed to enable this to be possible, and most rules in this be designed to enable this to be possible, and most rules in this
document are to help facilitate that. An extension to [RFC5444], document are to help facilitate that. An extension to [RFC5444],
such as [RFC7182], is considered to be an extension to all protocols such as [RFC7182], is considered to be an extension to all protocols
in this regard. in this regard.
The third case is the normal case for a new protocol. Protocols MUST The third case is the normal case for a new protocol. Protocols MUST
be conservative in the number of new message types that they require, be conservative in the number of new Message Types that they require,
as the total available number of allocatable message types is only as the total available number of allocatable Message Types is only
224. Protocol design SHOULD consider whether different functions can 224. Protocol design SHOULD consider whether different functions can
be implemented by differences in TLVs carried in the same Message be implemented by differences in TLVs carried in the same Message
Type, rather than using multiple Message Types. If a protocol's Type, rather than using multiple Message Types. If a protocol's
needs can be covered by use of the second case, then this SHOULD be needs can be covered by use of the second case, then this SHOULD be
done. done.
TLV space, although greater than message space, SHOULD also be used The TLV Type space, although greater than the Message Type space,
efficiently. The extended type of a TLV occupies two octets, thus SHOULD also be used efficiently. The extended type of a TLV occupies
there are many more available TLVs. However, in some cases two octets, thus there are many more available TLV extended types
(currently LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from than there are Message Types. However, in some cases (currently
[RFC7182] in the global TLV space) a full set of 256 TLVs is defined LINK_METRIC from [RFC7181] and ICV and TIMESTAMP from [RFC7182], all
(but not necessarily allocated). Each message also has a block of in the global TLV Type space) a TLV Type with a full set of 256 TLV
message specific TLV Types (128 to 233, each with 256 type extended types is defined (but not necessarily allocated).
extensions), these SHOULD be used in preference to the common TLV
Types (0 to 127, each with 256 type extensions) when a TLV is Each Message Type has an associated block of Message-Type-specific
message-specific. 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
these blocks SHOULD be used in preference to the Message-Type-
independent Message TLV Types (0 to 127, each with 256 type
extensions) when a TLV is specific to a message.
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 MUST be recognized by the combination of its type, A message MUST be recognized by the combination of its Message Type,
Originator Address and Message Sequence Number. This allows each Originator Address and Message Sequence Number. This allows each
protocol to manage its own Message Sequence Numbers, and also allows protocol to manage its own Message Sequence Numbers, and also allows
for the possibility that different Message Types may have greatly for the possibility that different Message Types may have greatly
differing transmission rates. [RFC7181] contains a general purpose differing transmission rates. [RFC7181] contains a general purpose
process for managing processing and forwarding decisions, albeit one process for managing processing and forwarding decisions, albeit one
presented as for use with MPR flooding. (Blind flooding can be presented as for use with MPR flooding. (Blind flooding can be
handled similarly by assuming that all other routers are MPR handled similarly by assuming that all other routers are MPR
selectors; it is not necessary in this case to differentiate between selectors; it is not necessary in this case to differentiate between
interfaces on which a message is received.) interfaces on which a message is received.)
skipping to change at page 7, line 45 skipping to change at page 9, line 7
Section 4.3 and Section 4.4. To use that model, addresses (for Section 4.3 and Section 4.4. 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 MAY 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. single message, in all Address Blocks and the Originator Address, and
is established by the router and protocol generating the message.
4.2. Packets and Messages 4.2. Packets and Messages
The [RFC5444] multiplexing process has to handle packet reception and The multiplexer has to handle message transmission and packet
message demultiplexing, and message transmission and packet multiplexing, and packet reception and message demultiplexing. The
multiplexing. multiplexer and the protocols that use it are subject to the
following rules.
When a packet arrives, the following steps are required:
o The packet and/or the messages it contains MAY be verified by an
extension to the demultiplexer, such as [RFC7182].
o Each message MUST be sent to its owning protocol, which MAY also
view the Packet Header, and the source address in the IP datagram
that included the packet.
o The owning protocol SHOULD verify each message, it SHOULD allow
any extending protocol(s) to also contribute to this.
o The owning protocol MUST process each message, or make an informed
decision not to do so. In the former case an owning protocol that
permits this MUST allow any extending protocols to process or
ignore the message.
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 RECOMMENDED that messages are not modified in the latter It is strongly RECOMMENDED that messages are not modified in the
case. latter case.
o Outgoing messages are then sent to the [RFC5444] multiplexing o Outgoing messages are then sent to the [RFC5444] multiplexer. The
process. The owning protocol MUST indicate which interface(s) the owning protocol MUST indicate which interface(s) the messages are
messages are to be sent on and their destination address, and MAY to be sent on and their destination address, and MAY request that
request that messages are kept together in a packet; the messages are kept together in a packet; the multiplexer SHOULD
multiplexing process SHOULD respect this request if possible. A respect this request if at all possible.
protocol MAY also request that a Packet Sequence Number and/or
specified Packet TLVs are included, such requests SHOULD also be
respected if possible.
o The multiplexing process SHOULD combine messages from multiple o The multiplexer SHOULD combine messages from multiple protocols
protocols that are sent on the same interface in a packet, that are sent on the same interface in a packet, provided that in
provided that in so doing the multiplexing process does not cause so doing the multiplexer does not cause an IP packet to exceed the
an IP packet to exceed the current MTU (Maximum Transmission current MTU (Maximum Transmission Unit). (Note that the
Unit). (Note that the multiplexing process cannot fragment multiplexer cannot fragment messages; creating suitable sized
messages; creating suitable sized messages is the responsibility messages is the responsibility of the protocol generating the
of the protocol.) message.)
o The multiplexer MAY delay messages briefly in order to assemble
more efficient packets. It SHOULD respect any constraints on such
delays requested by the protocol.
o If requested by a protocol, the multiplexer SHOULD, and otherwise o If requested by a protocol, the multiplexer SHOULD, and otherwise
MAY, include a Packet Sequence Number in the packet. Note that, MAY, include a Packet Sequence Number in the packet. Note that,
as per the errata to [RFC5444], this Packet Sequence Number MUST as per the errata to [RFC5444], this Packet Sequence Number MUST
be specific to the interface on which the packet is sent. be specific to the interface on which the packet is sent.
Separate sequence numbers SHOULD be maintained for each
destination to which packets are sent. (Note that packets travel
one hop; the destination is therefore either a link local
multicast address, if the packet is being multicast, or the
address of the neighbor interface to which the packet is sent.)
o An extension to the multiplexing process MAY add TLVs to the o An extension to the multiplexer MAY add TLVs to the packet and/or
packet and/or the messages (for example as by [RFC7182]). the messages (for example as by [RFC7182], which MAY be used by
the multiplexer to add Packet TLVs or Message TLVs, or by the
protocol to add Message TLVs).
When a packet is received, the following steps are required to be
performed by the demultiplexer:
o The packet and/or the messages it contains MAY be verified by an
extension to the demultiplexer, such as [RFC7182].
o Each message MUST be sent to its owning protocol. The
demultiplexer MUST also make the Packet Header, and the source and
destination addresses in the IP datagram that included the packet,
available to the protocol.
o The demultiplexer MUST remove any TLVs added to the message by the
multiplexer. The message MUST be passed on to the protocol
exactly as received from (another instance of) the protocol.
o The owning protocol SHOULD verify each message for correctness, it
SHOULD allow any extending protocol(s) to also contribute to this
verification.
o The owning protocol MUST process each message, or make an informed
decision not to do so. In the former case an owning protocol that
permits this MUST allow any extending protocols to process or
ignore the message.
o The owning protocol is responsible for managing the hop count
and/or hop limit in the message. It is RECOMMENDED that these are
handled as described in Appendix B of [RFC5444]; they MUST be so
handled if using hop count dependent TLVs such as those defined in
[RFC5497].
4.3. Messages, Addresses and Attributes 4.3. Messages, Addresses and Attributes
The information in a Message Body, including Message TLVs and Address The information in a Message Body, including Message TLVs and Address
Block TLVs, can be considered to consist of: Block TLVs, can be considered to consist of:
o Attributes of the message, each attribute consisting of an o Attributes of the message, each attribute consisting of an
extended type, a length, and a value (of that length). extended type, a length, and a value (of that length).
o A set of addresses, carried in one or more Address Blocks. o A set of addresses, carried in one or more Address Blocks.
o Attributes of each address, each attribute consisting of an o Attributes of each address, each attribute consisting of an
extended type, a length, and a value (of that length). extended type, a length, and a value (of that length).
Attributes are carried in TLVs. For Message TLVs the mapping from Attributes are carried in TLVs. For Message TLVs the mapping from
TLV to attribute is one to one. For Address Block TLVs the mapping TLV to attribute is one to one. For Address Block TLVs the mapping
from TLV to attribute is one to many, one TLV can carry attributes from TLV to attribute is one to many: one TLV can carry attributes
for multiple addresses, but only one attribute per address. for multiple addresses, but only one attribute per address.
Attributes for different addresses may be the same or different. Attributes for different addresses may be the same or different.
A TLV extended type MAY be (and this is RECOMMENDED whenever A TLV extended type MAY be (and this is RECOMMENDED whenever
possible) defined so that there may only be one TLV of that extended possible) defined so that there may only be one TLV of that extended
type associated with the packet (Packet TLV), message (Message TLV), type associated with the packet (Packet TLV), message (Message TLV),
or any value of any address (Address Block TLV). Note that an or any value of any address (Address Block TLV). Note that an
address may appear more than once in a message, but the restriction address may appear more than once in a message, but the restriction
on associating TLVs with addresses covers all copies of that address. on associating TLVs with addresses covers all copies of that address.
It is RECOMMENDED that addresses are not repeated in a message. It is RECOMMENDED that addresses are not repeated in a message.
skipping to change at page 10, line 10 skipping to change at page 11, line 43
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, to the ordering of addresses in an Address Block, of an address (either in a Message, or in a given Address Block in
or to the division of addresses among Address Blocks. a Message), to the ordering of addresses in an Address Block, or
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
MUST ignore any such Values when processing the message, but MUST MUST ignore any such Values when processing the message, but MUST
NOT ignore recognized Values in the such a TLV. The protocol MUST NOT ignore recognized Values in such a TLV. The protocol MUST NOT
NOT remove or change any such TLVs if the message is to be remove or change any such TLVs if the message is to be forwarded
forwarded unchanged. unchanged.
o Similar restrictions to the two preceding points apply to the o Similar restrictions to the two preceding points apply to the
packet multiplexing process, which also MUST NOT reject a packet demultiplexer, which also MUST NOT reject a packet based on an
based on an unrecognized message; although it will reject any such unrecognized message; although it will reject any such messages,
messages, it MUST deliver any other messages in the packet to it MUST deliver any other messages in the packet to their owning
their owning protocols. protocols.
The following points indicate the reasons for these rules, based on The following points indicate the reasons for these rules, based on
considerations of extensibility and efficiency. considerations of extensibility and efficiency.
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 Section 4.5, and approach to information representation described in Section 4.5, and
reduce the options available for message optimization described in reduce the options available for message optimization described in
Section 6. Section 6.
skipping to change at page 11, line 9 skipping to change at page 12, line 44
extension) in the use of LOST Values in the LINK_STATUS and extension) in the use of LOST Values in the LINK_STATUS and
OTHER_NEIGHB TLVs to report that an address is of a router known not OTHER_NEIGHB TLVs to report that an address is of a router known not
to be a neighbor. A future example might be to list an address to be to be a neighbor. A future example might be to list an address to be
added to a "blacklist" of addresses not to be used. This would be added to a "blacklist" of addresses not to be used. This would be
indicated by a new TLV (or a new Value of an existing TLV, see indicated by a new TLV (or a new Value of an existing TLV, see
below). An unmodified extension to NHDP would ignore such addresses, below). An unmodified extension to NHDP would ignore such addresses,
as required, as it does not support that specialized purpose. If as required, as it does not support that specialized purpose. If
NHDP had been designed so that just the presence of an address NHDP had been designed so that just the presence of an address
indicated a neighbor, that extension would not have been possible. indicated a neighbor, that extension would not have been possible.
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. must 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
skipping to change at page 14, line 42 skipping to change at page 16, line 29
other fields still have unused bits.) other fields still have unused bits.)
6. Message Efficiency 6. Message Efficiency
The ability to organize addresses into different, or the same, The ability to organize addresses into different, or the same,
Address Blocks, as well as to change the order of addresses within an Address Blocks, as well as to change the order of addresses within an
Address Block, and the flexibility of the TLV specification, enables Address Block, and the flexibility of the TLV specification, enables
avoiding unnecessary repetition of information, and consequently can avoiding unnecessary repetition of information, and consequently can
generate smaller messages. No algorithms for address organization or generate 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. that leave the information content unchanged MAY be used when
generating a message. Note, however, that this does not apply when
forwarding a message, a message that is (as strongly RECOMMENDED)
forwarded unchanged MUST have an identical octet representation,
other than that the owning protocol SHOULD increment and decrement,
respectively, the hop count and hop limit, if present.
6.1. Address Block Compression 6.1. Address Block Compression
Addresses in an Address Block can be compressed, and SHOULD be. Addresses in an Address Block can be compressed, and SHOULD be.
Compression of addresses in an Address Block considers addresses to Compression of addresses in an Address Block considers addresses to
consist of a Head, a Mid, and a Tail, where all addresses in an consist of a Head, a Mid, and a Tail, where all addresses in an
Address Block have the same Head and Tail, but different Mids. An Address Block have the same Head and Tail, but different Mids. An
additional compression is possible when the Tail consists of all additional compression is possible when the Tail consists of all
zero-valued octets. Expected use cases are IPv4 and IPv6 addresses zero-valued octets. Expected use cases are IPv4 and IPv6 addresses
skipping to change at page 17, line 24 skipping to change at page 19, line 17
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 create
more compact messages. The possible gain depends on the efficiency more compact messages. The possible gain depends on the efficiency
of the original message creation, and the specific details of the of the original message creation, and the specific details of the
message. Note that this process cannot be TLV Type independent, for message. Note that this process cannot be TLV Type independent, for
example a LINK_METRIC TLV has a more complicated Value structure than example a LINK_METRIC TLV has a more complicated Value structure than
a LINK_STATUS TLV does if using UNSPECIFIED Values. a LINK_STATUS TLV does if using UNSPECIFIED Values.
Such a protocol-independent optimizer MAY be used by the router
generating a message, but MUST NOT be used on a message that is
forwarded unchanged by a router.
7. Security Considerations 7. Security Considerations
This document does not specify a protocol, but provides rules and This document does not specify a protocol, but provides rules and
recommendations for how to design protocols using [RFC5444]. This recommendations for how to design protocols using [RFC5444]. This
document does not introduce any new security considerations; document does not introduce any new security considerations;
protocols designed according to these rules and recommendations are protocols designed according to these rules and recommendations are
subject to the security considerations detailed in [RFC5444]. In subject to the security considerations detailed in [RFC5444]. In
particular the applicability of the security framework for [RFC5444] particular the applicability of the security framework for [RFC5444]
specified in [RFC7182] is unchanged. specified in [RFC7182] is unchanged.
skipping to change at page 19, line 19 skipping to change at page 21, line 19
Generalized Packet/Message Format", RFC 7631, Generalized Packet/Message Format", RFC 7631,
January 2015. January 2015.
[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.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
LIX, Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33-6-6058-9349 Phone: +33-6-6058-9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org URI: http://www.thomasclausen.org
Christopher Dearlove Christopher Dearlove
BAE Systems Applied Intelligence Laboratories BAE Systems Applied Intelligence Laboratories
West Hanningfield Road West Hanningfield Road
 End of changes. 34 change blocks. 
124 lines changed or deleted 212 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/