Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 8245 Ecole Polytechnique
Updates: 5444 C. Dearlove
Category: Standards Track BAE Systems
ISSN: 2070-1721 U. Herberg
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 8245 Ecole Polytechnique
Updates: 5444 C. Dearlove
Category: Standards Track BAE Systems
ISSN: 2070-1721 U. Herberg
H. Rogge Fraunhofer FKIE October 2017
H.Rogge Fraunhofer FKIE 2017年10月
Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444
使用RFC 5444中的通用数据包/消息格式设计协议的规则
Abstract
摘要
RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.
RFC 5444规定了通用移动自组织网络（MANET）分组/消息格式，并描述了多路复用MANET路由协议消息的预期用途；当使用指定的MANET端口或协议号时，RFC 5498强制要求进行此使用。本文档通过提供关于多路复用器如何工作以及协议如何使用分组/消息格式的规则和建议来更新RFC 5444。特别是，强制性规则禁止在各种提案中提出的一些用途，这些用途可能导致互操作性问题、协议扩展开发障碍和/或无法使用可选的通用解析器。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8245.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8245.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. History and Purpose ........................................4
1.2. Features of RFC 5444 .......................................4
1.2.1. Packet/Message Format ...............................5
1.2.2. Multiplexing and Demultiplexing .....................7
1.3. Status of This Document ....................................8
2. Terminology .....................................................8
3. Applicability Statement .........................................9
4. Information Transmission ........................................9
4.1. Where to Record Information ................................9
4.2. Message and TLV Type Allocation ...........................10
4.3. Message Recognition .......................................11
4.4. Message Multiplexing and Packets ..........................11
4.4.1. Packet Transmission ................................12
4.4.2. Packet Reception ...................................13
4.5. Messages, Addresses, and Attributes .......................15
4.6. Addresses Require Attributes ..............................16
4.7. TLVs ......................................................18
4.8. Message Integrity .........................................19
5. Structure ......................................................19
6. Message Efficiency .............................................20
6.1. Address Block Compression .................................21
6.2. TLVs ......................................................22
6.3. TLV Values ................................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................25
Appendix A. Information Representation ............................27
Appendix B. Automation ............................................28
Acknowledgments ...................................................28
Authors' Addresses ................................................29
1. Introduction ....................................................4
1.1. History and Purpose ........................................4
1.2. Features of RFC 5444 .......................................4
1.2.1. Packet/Message Format ...............................5
1.2.2. Multiplexing and Demultiplexing .....................7
1.3. Status of This Document ....................................8
2. Terminology .....................................................8
3. Applicability Statement .........................................9
4. Information Transmission ........................................9
4.1. Where to Record Information ................................9
4.2. Message and TLV Type Allocation ...........................10
4.3. Message Recognition .......................................11
4.4. Message Multiplexing and Packets ..........................11
4.4.1. Packet Transmission ................................12
4.4.2. Packet Reception ...................................13
4.5. Messages, Addresses, and Attributes .......................15
4.6. Addresses Require Attributes ..............................16
4.7. TLVs ......................................................18
4.8. Message Integrity .........................................19
5. Structure ......................................................19
6. Message Efficiency .............................................20
6.1. Address Block Compression .................................21
6.2. TLVs ......................................................22
6.3. TLV Values ................................................23
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................25
Appendix A. Information Representation ............................27
Appendix B. Automation ............................................28
Acknowledgments ...................................................28
Authors' Addresses ................................................29
[RFC5444] specifies a generalized packet/message format that is designed for use by MANET routing protocols.
[RFC5444]指定为MANET路由协议使用而设计的通用数据包/消息格式。
[RFC5444] was designed following experiences with [RFC3626], which attempted to provide a packet/message format accommodating diverse protocol extensions but did not fully succeed. [RFC5444] was designed as a common building block for use by both proactive and reactive MANET routing protocols.
[RFC5444]是根据[RFC3626]的经验设计的，它试图提供一种适应不同协议扩展的数据包/消息格式，但没有完全成功。[RFC5444]被设计为一个公共构建块，用于主动式和反应式MANET路由协议。
[RFC5498] mandates the use of this packet/message format and of the packet multiplexing process described in an appendix to [RFC5444] by protocols operating over the MANET IP protocol and UDP port numbers that were allocated by [RFC5498].
[RFC5498]通过在[RFC5498]分配的MANET IP协议和UDP端口号上运行的协议，强制使用该数据包/消息格式和[RFC5444]附录中描述的数据包多路复用过程。
Since the publication of [RFC5444] in 2009, several RFCs have been published, including [RFC5497], [RFC6130], [RFC6621], [RFC7181], [RFC7182], [RFC7183], [RFC7188], [RFC7631], and [RFC7722], that use the format of [RFC5444]. The ITU-T recommendation [G9903] also uses the format of [RFC5444] for encoding some of its control signals. In developing these specifications, experience with the use of [RFC5444] has been acquired, specifically with respect to how to write specifications using [RFC5444] so as to ensure forward compatibility of a protocol with future extensions, to enable the creation of efficient messages, and to enable the use of an efficient and generic parser for all protocols using [RFC5444].
自2009年[RFC5444]发布以来，已经发布了多个RFC，包括[RFC5497]、[RFC6130]、[RFC6621]、[RFC7181]、[RFC7182]、[RFC7183]、[RFC7188]、[RFC7631]和[RFC7722]，它们使用[RFC5444]的格式。ITU-T建议[G9903]还使用[RFC5444]格式对其一些控制信号进行编码。在制定这些规范时，已经获得了使用[RFC5444]的经验，特别是关于如何使用[RFC5444]编写规范，以确保协议与未来扩展的前向兼容性，从而能够创建高效消息，并且能够使用[RFC5444]为所有协议使用高效的通用解析器。
During the same time period, other suggestions have been made to use [RFC5444] in a manner that would inhibit the development of interoperable protocol extensions, that would potentially lead to inefficiencies, or that would lead to incompatibilities with generic parsers for [RFC5444]. While these uses were not all explicitly prohibited by [RFC5444], they are strongly discouraged. This document is intended to prohibit such uses, to present experiences from designing protocols using [RFC5444], and to provide these as guidelines (with their rationale) for future protocol designs using [RFC5444].
在同一时期，还提出了其他建议，即使用[RFC5444]的方式将抑制可互操作协议扩展的开发，这可能导致效率低下，或导致与[RFC5444]的通用解析器不兼容。虽然[RFC5444]并未明确禁止所有这些用途，但强烈反对使用。本文件旨在禁止此类使用，介绍使用[RFC5444]设计协议的经验，并为使用[RFC5444]的未来协议设计提供指南（及其基本原理）。
[RFC5444] performs two main functions:
[RFC5444]执行两个主要功能：
o It defines a packet/message format for use by MANET routing protocols. As far as [RFC5444] is concerned, it is up to each protocol that uses it to implement the required message parsing
o 它定义了MANET路由协议使用的数据包/消息格式。就[RFC5444]而言，由使用它来实现所需消息解析的每个协议决定
and formation. It is natural, especially when implementing more than one such protocol, to implement these processes using protocol-independent packet/message creation and parsing procedures, however, this is not required by [RFC5444]. Some comments in this document might be particularly applicable to such a case, but all that is required is that the messages passed to and from protocols are correctly formatted and that packets containing those messages are correctly formatted as described in the following point.
和形成。使用与协议无关的数据包/消息创建和解析过程来实现这些过程是很自然的，特别是在实现多个这样的协议时，但[RFC5444]并不要求这样做。本文档中的一些注释可能特别适用于这种情况，但所需的只是协议之间传递的消息的格式正确，并且包含这些消息的数据包的格式正确，如下所述。
o Appendix A of [RFC5444], combined with the intended usage described in Appendix B of [RFC5444], specifies a multiplexing and demultiplexing process whereby an entity that can be referred to as the "RFC 5444 multiplexer" manages packets that travel a single (logical) hop and contain messages that are owned by individual protocols. Note that in this document, the "RFC 5444 multiplexer" is referred to as the "multiplexer", or as the "demultiplexer" when performing that function. A packet can contain messages from more than one protocol. This process is mandated for use on the MANET UDP port and IP protocol (alternative means for the transport of packets) by [RFC5498]. The multiplexer is responsible for creating packets and for parsing Packet Headers, extracting messages, and passing them to the appropriate protocol according to their type (the first octet in the message).
o [RFC5444]的附录A结合[RFC5444]附录B中所述的预期用途，规定了一种多路复用和解多路复用过程，其中，可称为“RFC 5444多路复用器”的实体管理通过单个（逻辑）跃点传输并包含由各个协议拥有的消息的数据包。注意，在本文档中，“RFC 5444多路复用器”在执行该功能时被称为“多路复用器”或“解复用器”。一个数据包可以包含来自多个协议的消息。[RFC5498]要求在MANET UDP端口和IP协议（数据包传输的替代方式）上使用此过程。多路复用器负责创建数据包，解析数据包头，提取消息，并根据它们的类型（消息中的第一个八位组）将它们传递给适当的协议。
Among the characteristics and design objectives of the packet/message format of [RFC5444] are the following:
[RFC5444]数据包/消息格式的特点和设计目标如下：
o It is designed for carrying MANET routing protocol control signals.
o 它是为承载MANET路由协议控制信号而设计的。
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. Each message has a well-defined structure consisting of a Message Header (designed for making processing and forwarding decisions) followed by a set of Message TLVs, and a set of (address, type, value) associations using Address Blocks and their Address Block TLVs. The packet/message format from [RFC5444] then enables the use of simple and generic parsing logic for Packet Headers, Message Headers, and message content.
o 它将一个数据包定义为一个数据包头，其中包含一组数据包TLV（类型-长度-值结构），后跟一组消息。每个消息都有一个定义良好的结构，包括一个消息头（设计用于做出处理和转发决策），后跟一组消息TLV，以及一组使用地址块及其地址块TLV的（地址、类型、值）关联。[RFC5444]中的数据包/消息格式支持对数据包头、消息头和消息内容使用简单通用的解析逻辑。
A packet can include messages from different protocols, such as the Neighborhood Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State Routing Protocol version 2 (OLSRv2)
数据包可以包括来自不同协议的消息，例如邻域发现协议（NHDP）[RFC6130]和优化链路状态路由协议版本2（OLSRv2）
[RFC7181], in a single transmission. This was observed in [RFC3626] to be beneficial, especially in wireless networks where media contention can be significant.
[RFC7181]，在单个传输中。[RFC3626]中观察到这是有益的，尤其是在媒体争用可能非常严重的无线网络中。
o Its packets are designed to travel between two neighboring interfaces, which will result in a single decrement of the IPv4 TTL or IPv6 hop limit. The Packet Header and any Packet TLVs can thus convey information relevant to that link (for example, the Packet Sequence Number can be used to count transmission successes across that link). Packets are designed to be constructed for a single-hop transmission; a packet transmission following a successful packet reception is (by design) a new packet that can include all, some, or none of the received messages, plus possibly additional messages either received in separate packets or generated locally at that router. Messages can thus travel more than one hop and are designed to carry end-to-end protocol signals.
o 它的数据包被设计为在两个相邻接口之间传输，这将导致IPv4 TTL或IPv6跃点限制的单一减少。因此，分组报头和任何分组tlv可传送与该链路相关的信息（例如，分组序列号可用于计算该链路上的传输成功次数）。分组被设计成用于单跳传输；在成功的数据包接收之后的数据包传输（根据设计）是一个新的数据包，该数据包可以包括所有、部分或任何接收到的消息，还可能包括在单独的数据包中接收的或在该路由器本地生成的附加消息。因此，消息可以传输多个跃点，并被设计为传输端到端协议信号。
o It supports "internal extensibility" using TLVs; an extension can add information to an existing message without that information rendering the message unparseable or unusable by a router that does not support the extension. An extension is typically of the protocol that created the message to be extended, for example, [RFC7181] adds information to the HELLO messages created by [RFC6130]. However, an extension can also be independent of the protocol; for example, [RFC7182] can add Integrity Check Value (ICV) and timestamp information to any message (or to a packet, thus extending the multiplexer).
o 它支持使用TLV的“内部扩展性”；扩展可以将信息添加到现有消息中，而不会使不支持扩展的路由器无法解析或无法使用该消息。扩展通常是创建要扩展的消息的协议的扩展，例如，[RFC7181]向[RFC6130]创建的HELLO消息添加信息。然而，扩展也可以独立于协议；例如，[RFC7182]可以将完整性检查值（ICV）和时间戳信息添加到任何消息（或数据包，从而扩展多路复用器）。
Information, in the form of TLVs, can be added to the message as a whole (such as the integrity information specified in [RFC7182]) or can be associated with specific addresses in the message (such as the Multipoint Relay (MPR) selection and link metric information added to HELLO messages by [RFC7181]). An extension can also add addresses to a message.
TLV形式的信息可以作为一个整体添加到消息中（如[RFC7182]中指定的完整性信息），或者可以与消息中的特定地址相关联（如[RFC7181]添加到HELLO消息中的多点中继（MPR）选择和链路度量信息）。扩展还可以向消息添加地址。
o It uses address aggregation into compact Address Blocks by exploiting commonalities between addresses. In many deployments, addresses (IPv4 and IPv6) used on interfaces share a common prefix that need not be repeated. Using IPv6, several addresses (of the same interface) might have common interface identifiers that need not be repeated.
o 它利用地址之间的共性，将地址聚合成紧凑的地址块。在许多部署中，接口上使用的地址（IPv4和IPv6）共享一个不需要重复的通用前缀。使用IPv6，多个地址（同一接口）可能具有不需要重复的公共接口标识符。
o It sets up common namespaces, formats, and data structures for use by different protocols where common parsing logic can be used. For example, [RFC5497] defines a generic TLV format for representing time information (such as interval time or validity time).
o 它设置公共名称空间、格式和数据结构，以供可以使用公共解析逻辑的不同协议使用。例如，[RFC5497]定义了用于表示时间信息（如间隔时间或有效时间）的通用TLV格式。
o It contains a minimal Message Header (a maximum of five elements: type, originator, sequence number, hop count, and hop limit) that permit decisions regarding whether to locally process a message or forward a message (thus enabling MANET-wide flooding of a message) without processing the body of the message.
o 它包含一个最小的消息头（最多五个元素：类型、发起者、序列号、跃点计数和跃点限制），允许在不处理消息体的情况下决定是本地处理消息还是转发消息（从而实现消息在MANET范围内的泛洪）。
The multiplexer (and demultiplexer) is defined in Appendix A of [RFC5444]. Its purpose is to allow multiple protocols to share the same IP protocol or UDP port. That sharing was made necessary by the separation of [RFC6130] from [RFC7181] as separate protocols and by the allocation of a single IP protocol and UDP port to all MANET protocols, including those protocols following [RFC5498], which states:
复用器（和解复用器）在[RFC5444]的附录A中定义。其目的是允许多个协议共享同一IP协议或UDP端口。通过将[RFC6130]与[RFC7181]分离为单独的协议，并将单个IP协议和UDP端口分配给所有MANET协议，包括[RFC5498]之后的协议，这种共享是必要的，这些协议规定：
All interoperable protocols running on these well-known IANA allocations MUST conform to [RFC5444]. [RFC5444] provides a common format that enables one or more protocols to share the IANA allocations defined in this document unambiguously.
在这些众所周知的IANA分配上运行的所有互操作协议必须符合[RFC5444]。[RFC5444]提供了一种通用格式，使一个或多个协议能够毫不含糊地共享本文档中定义的IANA分配。
The multiplexer is the mechanism in [RFC5444] that enables that sharing.
多路复用器是[RFC5444]中实现共享的机制。
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 can be a unicast address or the "LL-MANET-Routers" link-local multicast address defined in [RFC5498].
o 接受来自MANET协议的消息，该协议还指示消息将通过哪个接口发送以及发送到哪个目标地址。后者可以是单播地址或[RFC5498]中定义的“LL MANET路由器”链路本地多播地址。
o Collect messages (possibly from multiple protocols) for the same local 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 将同一本地接口和目的地的消息（可能来自多个协议）收集到要发送一个逻辑跳的数据包中，并使用[RFC5498]中定义的MANET UDP端口或IP协议发送数据包。
o Extract messages from received packets and pass them to their owning protocols.
o 从接收到的数据包中提取消息，并将它们传递给它们所属的协议。
The multiplexer's relationship is with the protocols that own the corresponding Message Types. Where those protocols have their own relationships (for example, as extensions), this is the responsibility of the protocols. For example, OLSRv2 [RFC7181] extends the HELLO messages created by NHDP [RFC6130]. However, the multiplexer will deliver HELLO messages to NHDP and will expect to receive HELLO messages from NHDP; the relationship between NHDP and OLSRv2 is between those two protocols.
多路复用器与拥有相应消息类型的协议的关系。如果这些协议有自己的关系（例如，作为扩展），这是协议的责任。例如，OLSRv2[RFC7181]扩展了NHDP[RFC6130]创建的HELLO消息。然而，多路复用器将向NHDP发送HELLO消息，并期望从NHDP接收HELLO消息；NHDP和OLSRv2之间的关系介于这两个协议之间。
The multiplexer is also responsible for the Packet Header, including any Packet Sequence Number and Packet TLVs. It can accept some additional instructions from protocols, can pass additional information to protocols, and will follow some additional rules; see Section 4.4.
多路复用器还负责分组报头，包括任何分组序列号和分组tlv。它可以接受来自协议的一些附加指令，可以向协议传递附加信息，并且将遵循一些附加规则；见第4.4节。
This document updates [RFC5444] and is published on the Standards Track (rather than as Informational) because it specifies and mandates constraints on the use of [RFC5444] that, if not followed, make forms of extensions of those protocols impossible, impede the ability to generate efficient messages, or make desirable forms of generic parsers impossible.
本文件更新了[RFC5444]，并在标准轨道上发布（而非作为信息发布），因为本文件规定并强制执行[RFC5444]的使用限制，如果不遵守，将使这些协议的扩展形式变得不可能，妨碍生成有效消息的能力，或者使通用解析器的理想形式变得不可能。
Each use of key words from [RFC2119] (see Section 2) can be considered 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 and current uses, specifically by [RFC6130] and [RFC7181] (that might already include the requirement, particularly through [RFC7188]). That such modifying cases are an update to [RFC5444] is explicitly indicated in this specification.
每次使用[RFC2119]（见第2节）中的关键词都可以被视为对[RFC5444]的更新。在大多数情况下，这些规范编纂了明显的最佳实践，或在本规范适用的情况下限制了[RFC5444]的使用（见第3节）。在少数情况下，修改了[RFC5444]的操作。这些都是[RFC6130]和[RFC7181]在其主要用途和当前用途中未出现的情况（可能已经包括要求，特别是通过[RFC7188]）。本规范明确指出，此类修改案例是对[RFC5444]的更新。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Use of those key words applies directly to existing and future implementations of [RFC5444]. It also applies to existing and future protocols that use or update that RFC.
这些关键词的使用直接适用于[RFC5444]的现有和未来实现。它还适用于使用或更新RFC的现有和未来协议。
This document uses the terminology and notation defined in [RFC5444]; the terms "packet", "Packet Header", "message", "Message Header", "address", "Address Block", "TLV", "TLV Block", and other related terms are to be interpreted as described therein.
本文件使用[RFC5444]中定义的术语和符号；术语“分组”、“分组报头”、“消息”、“消息报头”、“地址”、“地址块”、“TLV”、“TLV块”和其他相关术语应按照其中所述进行解释。
Additionally, this document uses the following terminology:
此外，本文件使用以下术语：
Full Type (of TLV): As per [RFC5444], the 16-bit combination of the TLV Type and Type Extension is given the symbolic name <tlv-fulltype>. This document uses the term "Full Type", which is not used in [RFC5444], but is assigned (by this document) as standard terminology.
完整类型（TLV）：根据[RFC5444]，TLV类型和类型扩展的16位组合被赋予符号名<TLV fulltype>。本文件使用术语“完整类型”，该术语未在[RFC5444]中使用，但被指定为（本文件）标准术语。
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 demultiplexer inspects the Message Type of each received message and delivers each message to its corresponding "owning protocol".
拥有协议：根据[RFC5444]，对于每种消息类型，一个协议——除非另有规定，为该消息类型保留IANA的协议——被指定为该消息类型的“拥有协议”。解复用器检查每个接收到的消息的消息类型，并将每个消息传递到其相应的“拥有协议”。
This document does not specify a protocol but documents constraints on how to design protocols that use the generic packet/message format defined in [RFC5444] that, if not followed, makes forms of extensions of those protocols impossible, impedes the ability to generate efficient (small) messages, or makes desirable forms of generic parsers impossible. The use of the [RFC5444] format is mandated by [RFC5498] for all protocols running over the MANET protocol and port, defined therein. Thus, the constraints in this document apply to all protocols running over the MANET IP protocol or UDP port. The constraints are strongly recommended for other uses of [RFC5444].
本文件未指定协议，但记录了如何设计使用[RFC5444]中定义的通用数据包/消息格式的协议的约束条件，如果不遵循该格式，则无法扩展这些协议的形式，妨碍生成高效（小）消息的能力，或者使通用解析器的理想形式变得不可能。[RFC5498]规定，对于在MANET协议和端口上运行的所有协议，都必须使用[RFC5444]格式。因此，本文档中的约束适用于通过MANET IP协议或UDP端口运行的所有协议。强烈建议[RFC5444]的其他用途使用这些约束条件。
Protocols need to transmit information from one instance implementing the protocol to another.
协议需要将信息从实现协议的一个实例传输到另一个实例。
A protocol has the following choices as to where to put information for transmission:
协议具有以下关于将信息放置在何处进行传输的选择：
o in a TLV to be added to the Packet Header;
o 在要添加到分组报头的TLV中；
o in a message of a type owned by another protocol; or
o 在属于另一协议的类型的消息中；或
o in a message of a type owned by the protocol.
o 在协议拥有的类型的消息中。
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 information relates to the packet as a whole (for example, packet integrity check values and timestamps, as specified in [RFC7182]) or
第一种情况（分组TLV）只能在信息要被携带一跳时使用。仅当信息与整个数据包相关时（例如，[RFC7182]中规定的数据包完整性检查值和时间戳），或
if the information is expected to have a wider application than a single protocol. A protocol can also request that the Packet Header include Packet Sequence Numbers but does not control those numbers.
如果信息预期比单一协议有更广泛的应用。协议还可以请求分组报头包括分组序列号，但不控制这些编号。
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 protocol; for example, OLSRv2 [RFC7181] is an extension of NHDP [RFC6130].
第二种情况（在由另一协议拥有的类型的消息中）仅当添加协议是拥有协议的扩展时才可能发生；例如，OLSRv2[RFC7181]是NHDP[RFC6130]的扩展。
The third case is the normal case for a new 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 protocol (the second case). An example of the latter is that OLSRv2 [RFC7181] is a protocol that also extends the HELLO message owned by NHDP [RFC6130]; it is thus an example of both the second and third cases (the latter using the OLSRv2 owned Topology Control (TC) message). An extension to [RFC5444], such as [RFC7182], is considered to be an extension to all protocols. Protocols SHOULD be designed to enable extension by any of these means to be possible, and some of the rules in this document (in Sections 4.6 and 4.8, specifically) are to help facilitate that.
协议扩展既可以是协议的更新（第三种情况），也可以是同时更新另一个协议的新协议（第二种情况）。后者的一个例子是OLSRv2[RFC7181]是一个协议，它也扩展了NHDP[RFC6130]拥有的HELLO消息；因此，这是第二种和第三种情况的示例（后者使用OLSRv2拥有的拓扑控制（TC）消息）。[RFC5444]的扩展，如[RFC7182]，被认为是对所有协议的扩展。协议的设计应确保能够通过上述任何一种方式进行扩展，本文件中的一些规则（特别是第4.6节和第4.8节）有助于实现这一点。
Protocols SHOULD be conservative in the number of new Message Types that they require, as the total available number of allocatable Message Types is only 224. Protocol design SHOULD consider whether different functions can be implemented by differences in TLVs carried in the same Message Type rather than using multiple Message Types.
协议在所需的新消息类型数量上应该是保守的，因为可分配消息类型的总可用数量只有224。协议设计应该考虑不同的功能是否可以通过在同一消息类型中携带的TLV的差异来实现，而不是使用多个消息类型。
The TLV Type space, although greater than the Message Type space, 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 are Message Types. However, in some cases (currently LINK_METRIC 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 Types is defined (but not necessarily allocated).
TLV类型空间虽然大于消息类型空间，但也应有效使用。TLV的完整类型占用两个八位组；因此，可用的TLV完整类型比消息类型多得多。但是，在某些情况下（目前[RFC7181]中的链路度量和[RFC7182]中的ICV和时间戳都在全局TLV类型空间中），定义了一个包含256个TLV完整类型的完整集的TLV类型（但不一定分配）。
Each Message Type has an associated block of Message-Type-specific TLV Types (128 to 233, each 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.
对于地址块TLV类型和消息TLV类型，每种消息类型都有一个特定于消息类型的TLV类型的关联块（128到233，每个具有256个类型扩展名）。当TLV特定于消息时，应优先使用这些块中的TLV类型，而不是消息类型独立的消息TLV类型（0到127，每个具有256个类型扩展名）。
The Expert Review guidelines in [RFC5444] are updated accordingly, as described in Section 8.
如第8节所述，[RFC5444]中的专家评审指南也相应更新。
A message contains a Message Header and a Message Body; note that the Message TLV Block is considered part of the latter. The Message Header contains information whose primary purpose is to decide whether to process the message and whether to forward the message.
消息包含消息头和消息体；请注意，消息TLV块被视为后者的一部分。消息头包含的信息主要用于决定是否处理消息以及是否转发消息。
A protocol might need to recognize whether a message, especially a flooded message, is one that it has previously received (for example, 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 its Message Type, Originator Address, and Message Sequence Number. The inclusion of Message Type allows each protocol to manage its own Message Sequence Numbers and also allows for the possibility that different Message Types can have greatly differing transmission rates. As an example of such use, [RFC7181] contains a general purpose process for managing processing and forwarding decisions, although specifically for use with MPR flooding. (Blind flooding can be handled similarly by assuming that all other routers are MPR selectors; it is not necessary in this case to differentiate between interfaces on which a message is received.)
协议可能需要识别一条消息，尤其是淹没消息，是否是它以前接收过的消息（例如，确定是处理和/或转发它，还是丢弃它）。如果消息头中包含足够的信息，则可以将消息识别为以前见过的消息。必须通过消息类型、发起者地址和消息序列号的组合来识别消息。消息类型的包含允许每个协议管理其自己的消息序列号，还允许不同的消息类型可能具有非常不同的传输速率。作为此类使用的一个示例，[RFC7181]包含一个用于管理处理和转发决策的通用流程，尽管专门用于MPR泛洪。（通过假设所有其他路由器都是MPR选择器，可以类似地处理盲泛洪；在这种情况下，没有必要区分接收消息的接口。）
Most protocol information is thus contained in the Message Body. A model of how such information can be viewed is described in Sections 4.5 and 4.6. To use that model, addresses (for example, of neighboring or otherwise known routers) SHOULD be recorded in Address Blocks, not as data in TLVs. Recording addresses in TLV Value fields both breaks the model of addresses as identities and associated information (attributes) and also inhibits address compression. However, in some cases, alternative addresses (e.g., hardware addresses when the Address Block is recording IP addresses) can be carried as TLV Values. Note that a message contains a Message Address Length field that can be used to allow carrying alternative message sizes, but only one length of addresses can be used in a single message, in all Address Blocks and the Originator Address, and is established by the router and protocol generating the message.
因此，大多数协议信息都包含在消息体中。第4.5节和第4.6节描述了如何查看此类信息的模型。要使用该模型，地址（例如，相邻或其他已知路由器的地址）应记录在地址块中，而不是作为TLV中的数据。在TLV值字段中记录地址既打破了地址作为身份和相关信息（属性）的模型，也抑制了地址压缩。然而，在某些情况下，替代地址（例如，当地址块记录IP地址时的硬件地址）可以作为TLV值携带。请注意，消息包含一个消息地址长度字段，该字段可用于承载备选消息大小，但在单个消息、所有地址块和发起者地址中只能使用一个地址长度，并且由生成消息的路由器和协议建立。
The multiplexer has to handle message multiplexing into packets and the transmission of said packets, as well as packet reception and demultiplexing into messages. The multiplexer and the protocols that use it are subject to the following rules.
多路复用器必须处理消息多路复用成分组和所述分组的传输，以及分组接收和解复用成消息。多路复用器及其使用的协议遵循以下规则。
Packets are formed for transmission through the following steps:
通过以下步骤形成用于传输的分组：
o Outgoing messages are created by their owning protocol and MAY be modified by any extending protocols if the owning protocol permits this. Messages MAY also be forwarded by their owning protocol. It is strongly RECOMMENDED that messages are not modified in the latter case, other than updates to their hop count and hop limit fields, as described in Section 7.1.1 of [RFC5444]. Note that this includes having an identical octet representation, including not allowing a different TLV representation of the same information. This is because it enables end-to-end authentication that ignores (zeros) those two fields (only), as is done in the Message TLV ICV (Integrity Check Value) calculations in [RFC7182]. Protocols MUST document their behavior with regard to modifiability of messages.
o 传出消息由其所属协议创建，如果所属协议允许，可以由任何扩展协议修改。消息也可以通过其拥有的协议转发。强烈建议在后一种情况下不要修改消息，除非更新其跃点计数和跃点限制字段，如[RFC5444]第7.1.1节所述。注意，这包括具有相同的八位字节表示，包括不允许相同信息的不同TLV表示。这是因为它启用了忽略（仅零）这两个字段的端到端身份验证，正如[RFC7182]中的消息TLV ICV（完整性检查值）计算中所做的那样。协议必须记录它们在消息可修改性方面的行为。
o Outgoing messages are then sent to the multiplexer. The owning protocol MUST indicate which interface(s) the messages are to be sent on and their destination address. 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 然后将传出消息发送到多路复用器。拥有协议必须指明消息将在哪个接口上发送及其目标地址。请注意，数据包传输一跳；因此，目的地要么是链路本地多播地址（如果数据包是多播的），要么是数据包发送到的邻居接口的地址。
o The owning protocol MAY request that messages are kept together in a packet; the multiplexer SHOULD respect this request if at all possible. The multiplexer SHOULD combine messages that are sent on the same interface in a packet, whether from the same or different protocols, provided that in so doing the multiplexer does not cause an IP packet to exceed the current Maximum Transmission Unit (MTU). Note that the multiplexer cannot fragment messages; creating suitably sized messages that will not cause the MTU to be exceeded if sent in a single message packet is the responsibility of the protocol generating the message. If a larger message is created, then only IP fragmentation is available to allow the packet to be sent; this is generally considered undesirable, especially when transmission can be unreliable.
o 拥有协议可以请求将消息保存在一个分组中；如果可能，多路复用器应尊重此请求。多路复用器应将在同一接口上发送的消息组合成一个数据包，无论是来自相同协议还是不同协议，前提是这样做不会导致IP数据包超过当前最大传输单元（MTU）。请注意，多路复用器不能对消息进行分段；生成消息的协议负责创建适当大小的消息，如果在单个消息包中发送，则不会导致超过MTU。如果创建了更大的消息，则只有IP碎片可用于允许发送数据包；这通常被认为是不可取的，尤其是当传输可能不可靠时。
o The multiplexer MAY delay messages in order to assemble more efficient packets. It MUST respect any constraints on such delays requested by the protocol if it is practical to do so.
o 多路复用器可以延迟消息以组装更有效的分组。如果切实可行，它必须尊重议定书所要求的对这种延误的任何限制。
o If requested by a protocol, the multiplexer MUST (and otherwise MAY) include a Packet Sequence Number in the packet. Such a request MUST be respected as long as the protocol is active. Note that the errata to [RFC5444] indicates that the Packet Sequence Number SHOULD be specific to the interface on which the packet is
o 如果协议要求，多路复用器必须（或可以）在分组中包括分组序列号。只要协议处于活动状态，就必须遵守此类请求。请注意，[RFC5444]的勘误表表示数据包序列号应特定于数据包所在的接口
sent. This specification updates [RFC5444] by requiring that this sequence number MUST be specific to that interface and also that separate sequence numbers MUST be maintained for each destination to which packets are sent with included Packet Sequence Numbers. Addition of Packet Sequence Numbers MUST be consistent (i.e., for each interface and destination, the Packet Sequence Number MUST be added to all packets or to none).
发送。本规范更新了[RFC5444]，要求该序列号必须特定于该接口，并且必须为每个发送包的目的地保留单独的序列号，包括包序列号。数据包序列号的添加必须一致（即，对于每个接口和目的地，数据包序列号必须添加到所有数据包或无数据包）。
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 as also extending the corresponding protocols. For example, [RFC7182] can be used by the multiplexer to add Packet TLVs or Message TLVs, or it can be used by the protocol to add Message TLVs.
o 多路复用器的扩展可以向分组添加tlv。它还可以将TLV添加到消息中，在这种情况下，它也被视为扩展了相应的协议。例如，[RFC7182]可由多路复用器用于添加分组TLV或消息TLV，或可由协议用于添加消息TLV。
When a packet is received, the following steps are performed by the demultiplexer and by protocols:
当接收到数据包时，解复用器和协议执行以下步骤：
o The Packet Header and the organization into the messages that it contains MUST be verified by the demultiplexer.
o 数据包头及其包含的消息的组织必须由解复用器进行验证。
o The packet and/or the messages it contains MAY also be verified by an extension to the demultiplexer, such as [RFC7182].
o 数据包和/或其包含的消息也可以由解复用器的扩展来验证，例如[RFC7182]。
o Each message MUST be sent to its owning protocol or discarded if the Message Type is not recognized. The demultiplexer MUST also make available to the protocol the Packet Header and the source and destination addresses in the IP datagram that included the packet.
o 必须将每条消息发送到其所属的协议，如果消息类型无法识别，则必须将其丢弃。解复用器还必须向协议提供包头以及包含包的IP数据报中的源地址和目标地址。
o The demultiplexer MUST remove any Message TLVs that were added by an extension to the multiplexer. The message MUST be passed on to the protocol exactly as received from (another instance of) the protocol. This is, in part, an implementation detail. For example, an implementation of the multiplexer and of [RFC7182] could add a Message TLV either in the multiplexer or in the protocol and remove it in the same place on reception. An implementation MUST 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 解复用器必须删除由扩展添加到复用器的任何消息TLV。消息必须完全按照从协议（另一个实例）接收的方式传递到协议。这在某种程度上是一个实现细节。例如，多路复用器和[RFC7182]的实现可以在多路复用器或协议中添加消息TLV，并在接收时在相同的位置将其移除。实现必须确保传递到协议的消息与通过相同实现从该协议传递的消息相同，即，路由器上的组合实现是自一致的，并且多路复用器包含在分组中的消息独立于该实现细节。
o The owning protocol MUST verify each message for correctness; it MUST allow any extending protocol(s) to also contribute to this verification.
o 所属协议必须验证每条消息的正确性；它必须允许任何扩展协议也有助于此验证。
o The owning protocol MUST process each message. In some cases, which will be defined in the protocol specification, this processing will determine that the message will be ignored. Except in the latter case, the owning protocol MUST also allow any extending protocols to process the message.
o 拥有协议必须处理每条消息。在协议规范中定义的某些情况下，此处理将确定消息将被忽略。除后一种情况外，拥有协议还必须允许任何扩展协议处理消息。
o The owning protocol MUST manage 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].
o 拥有协议必须管理消息中的跃点计数和/或跃点限制。建议按照[RFC5444]附录B中的说明进行处理；如果使用跳数相关的TLV（如[RFC5497]中定义的TLV），则必须如此处理。
In addition to the messages between the multiplexer and the protocols in each direction, the following additional information (summarized from other sections in this specification) can be exchanged.
除了多路复用器和每个方向的协议之间的消息外，还可以交换以下附加信息（从本规范的其他部分总结）。
o The packet source and destination addresses MUST be sent from the demultiplexer to the protocol.
o 数据包源地址和目的地址必须从解复用器发送到协议。
o The Packet Header, including the Packet Sequence Number, MUST be sent from the (de)multiplexer to the protocol if present. (An implementation MAY choose to only do so or only report the Packet Sequence Number, on request.)
o 包头，包括包序列号，必须从（解）复用器发送到协议（如果存在）。（一个实现可以选择仅这样做，或者根据请求仅报告数据包序列号。）
o A protocol MAY require that all outgoing packets contain a Packet Sequence Number.
o 协议可能要求所有传出数据包都包含一个数据包序列号。
o The interface over which a message is to be sent and its destination address MUST be sent from protocol to multiplexer. The destination address MAY be a multicast address, in particular, the LL-MANET-Routers link-local multicast address defined in [RFC5498].
o 要在其上发送消息的接口及其目的地址必须从协议发送到多路复用器。目的地地址可以是多播地址，具体地说，LL MANET路由器链接在[RFC5498]中定义的本地多播地址。
o A request to keep messages together in one packet MAY be sent from protocol to multiplexer.
o 将消息保存在一个分组中的请求可以从协议发送到多路复用器。
o A requested maximum message delay MAY be sent from protocol to multiplexer.
o 请求的最大消息延迟可以从协议发送到多路复用器。
The protocol SHOULD also be aware of the MTU that will apply to its messages, if this is available.
协议还应了解将应用于其消息的MTU（如果可用）。
The information in a Message Body, including Message TLVs and Address Block TLVs, consists of:
消息正文中的信息，包括消息TLV和地址块TLV，包括：
o Attributes of the message, in which each attribute consists of a Full Type, a length, and a Value (of that length).
o 消息的属性，其中每个属性由完整类型、长度和（该长度的）值组成。
o A set of addresses, which are carried in one or more Address Blocks.
o 在一个或多个地址块中携带的一组地址。
o Attributes of each address, in which each attribute consists of a Full Type, a length, and a Value (of that length).
o 每个地址的属性，其中每个属性由完整类型、长度和（该长度的）值组成。
Attributes are carried in TLVs. For Message TLVs, the mapping from 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 for multiple addresses, but only one attribute per address. Attributes for different addresses can be the same or different.
属性在TLV中携带。对于消息TLV，从TLV到属性的映射是一对一的。对于地址块TLV，从TLV到属性的映射是一对多：一个TLV可以携带多个地址的属性，但每个地址只有一个属性。不同地址的属性可以相同，也可以不同。
[RFC5444] requires that when a TLV Full Type is defined, then it MUST also define how to handle the cases of multiple TLVs of the same type applying to the same information element - i.e., when more than one Packet TLV of the same TLV Full Type is included in the same Packet Header, when more than one Message TLV of the same TLV Full Type is included in the same Message TLV Block, or when more than one Address Block TLV of the same TLV Full Type applies to the same value of any address. It is RECOMMENDED that when defining a new TLV Full Type, a rule of the following form is adopted.
[RFC5444]要求定义TLV完整类型时，还必须定义如何处理应用于相同信息元素的相同类型的多个TLV的情况，即，当相同TLV完整类型的多个TLV包含在相同的数据包报头中时，当同一消息TLV块中包含多个相同TLV完整类型的消息TLV时，或当多个相同TLV完整类型的地址块TLV应用于任何地址的相同值时。建议在定义新的TLV完整类型时，采用以下形式的规则。
o If used, there MUST 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).
o 如果使用，则必须只有一个完整类型的TLV与数据包（数据包TLV）、消息（消息TLV）或任何地址的任何值（地址块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.
注意，这适用于地址值；一个地址可以在一条消息中出现多次，但将TLV与地址关联的限制包括该地址的所有副本。建议邮件中不要重复地址。
A conceptual way to view this information is described in Appendix A.
附录A中描述了查看此信息的概念方法。
It is not mandatory in [RFC5444] to associate an address with attributes using Address Block TLVs. Information about an address could thus, in principle, be carried using:
[RFC5444]中不强制要求使用地址块TLV将地址与属性关联。因此，关于地址的信息原则上可以通过以下方式传送：
o The simple presence of an address.
o 地址的简单存在。
o The ordering of addresses in an Address Block.
o 地址块中地址的顺序。
o The use of different meanings for different Address Blocks.
o 对不同的地址块使用不同的含义。
This specification, however, requires that those methods of carrying information MUST NOT be used for any protocol using [RFC5444]. Information about the meaning of an address MUST only be carried using Address Block TLVs.
然而，本规范要求，这些携带信息的方法不得用于使用[RFC5444]的任何协议。有关地址含义的信息只能使用地址块TLV进行传输。
In addition, rules for the extensibility of OLSRv2 and NHDP are described in [RFC7188]. This specification extends their applicability to other uses of [RFC5444].
此外，OLSRv2和NHDP的可扩展性规则在[RFC7188]中进行了描述。本规范将其适用范围扩展到[RFC5444]的其他用途。
These rules are:
这些规则是：
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 a Message), to the ordering of addresses in an Address Block, or to the division of addresses among Address Blocks.
o 协议不得对地址的存在或不存在（在消息中或消息中的给定地址块中）、地址块中的地址顺序或地址块之间的地址划分赋予任何意义。
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 TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
o 协议不得基于包含无法识别类型的TLV而拒绝消息。协议在处理消息时必须忽略任何此类TLV。如果要转发未更改的消息，则协议不得删除或更改任何此类TLV。
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 MUST ignore any such Values when processing the message but MUST NOT ignore recognized Values in such a TLV. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged.
o 协议不得基于在已识别类型的TLV中包含未识别值而拒绝消息。协议在处理消息时必须忽略任何此类值，但不得忽略此类TLV中的已识别值。如果要转发未更改的消息，则协议不得删除或更改任何此类TLV。
o Similar restrictions to the two preceding points apply to the demultiplexer, which also MUST NOT reject a packet based on an unrecognized message; although it will reject any such messages, it MUST deliver any other messages in the packet to their owning protocols.
o 与上述两点类似的限制适用于解复用器，其也不得拒绝基于未识别消息的数据包；尽管它将拒绝任何此类消息，但它必须将数据包中的任何其他消息传递到它们所属的协议。
The following points indicate the reasons for these rules based on considerations of extensibility and efficiency.
以下几点说明了基于可扩展性和效率考虑制定这些规则的原因。
Assigning a meaning to the presence, absence, or location of an address would reduce the extensibility of the protocol, prevent the approach to information representation described in Appendix A, and reduce the options available for message optimization described in Section 6.
为地址的存在、不存在或位置赋予意义将降低协议的可扩展性，阻止附录a中描述的信息表示方法，并减少第6节中描述的消息优化可用选项。
To consider how the simple presence of an address conveying information would have restricted the development of an extension, two examples are considered: one actual (included in the base specification, but which could have been added later) and one hypothetical.
要考虑传递信息的简单存在将如何限制扩展的发展，考虑两个例子：一个实际（包括在基础规范中，但稍后可以添加）和一个假设。
The basic function of NHDP's HELLO messages [RFC6130] is to indicate that addresses are of neighbors, using the LINK_STATUS and OTHER_NEIGHB TLVs. (The message can also indicate the router's own addresses, which could also serve as a further example.)
NHDP的HELLO messages[RFC6130]的基本功能是使用LINK_STATUS和其他_NEIGHB TLV指示地址是邻居。（该消息还可以指示路由器自己的地址，这也可以作为进一步的示例。）
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 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 TLVs to report that an address is of a router known not to be a neighbor.
NHDP的扩展可能会决定使用HELLO消息来报告一个地址是一个可以用于专门用途而不是基于NHDP的普通用途的地址。这种示例已经存在于使用链路状态和其他相邻TLV中的丢失值来报告地址是已知不是邻居的路由器的地址。
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 TLV (or a new Value of an existing TLV, see below). If no other TLVs were attached to such a blacklisted address, then an unmodified implementation of NHDP would ignore that address, as required; if any other TLVs were attached to that address, then that implementation would process that address for those TLVs. Had NHDP been designed so that just the presence of an address indicated a neighbor, this blacklist extension would not be possible, as an unmodified implementation of NHDP would treat all blacklisted addresses as neighbors.
未来的一个例子可能是指出一个地址将被添加到不使用地址的“黑名单”中。这将使用新的TLV（或现有TLV的新值，见下文）。如果没有其他TLV附加到此类黑名单地址，则NHDP的未修改实现将根据需要忽略该地址；如果任何其他TLV附加到该地址，则该实现将为这些TLV处理该地址。如果NHDP被设计成仅存在一个地址就表示邻居，那么这个黑名单扩展将不可能，因为NHDP的未修改实现将把所有黑名单地址视为邻居。
Rejecting a message because it contains an unrecognized TLV Type or an unrecognized TLV Value reduces the extensibility of the protocol.
拒绝包含无法识别的TLV类型或无法识别的TLV值的消息会降低协议的可扩展性。
For example, OLSRv2 [RFC7181] is, among other things, an extension to NHDP. It adds information to addresses in an NHDP HELLO message using a LINK_METRIC TLV. A non-OLSRv2 implementation of NHDP (for example, to support Simplified Multicast Flooding (SMF) [RFC6621]) will still process the HELLO message, ignoring the LINK_METRIC TLVs.
例如，OLSRv2[RFC7181]是NHDP的扩展。它使用链接度量TLV向NHDP HELLO消息中的地址添加信息。NHDP的非OLSRv2实现（例如，支持简化多播泛洪（SMF）[RFC6621]）仍将处理HELLO消息，忽略链路度量TLV。
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 OTHER_NEIGHB TLV (requiring an IANA allocation as described in [RFC7188]), as is already done in the LOST case.
此外，上述示例中描述的黑名单可以不使用新的TLV，而是使用链路状态或其他相邻TLV的新值（需要[RFC7188]中所述的IANA分配）发出信号，就像在丢失案例中已经做的那样。
The creation of Multi-Topology OLSRv2 (MT-OLSRv2) [RFC7722], as an extension to OLSRv2 that can interoperate with unextended instances of OLSRv2, would not have been possible without these restrictions (which were applied to NHDP and OLSRv2 by [RFC7188]).
如果没有这些限制（由[RFC7188]应用于NHDP和OLSRv2），就不可能创建多拓扑OLSRv2（MT-OLSRv2）[RFC7722]，作为OLSRv2的扩展，可以与OLSRv2的未扩展实例互操作。
These restrictions do not, however, mean that added information is completely ignored for purposes of the base protocol. Suppose that a faulty implementation of OLSRv2 (including NHDP) creates a HELLO message that assigns two different values of the same link metric to an address, something that is not permitted by [RFC7181]. A receiving OLSRv2-aware implementation of NHDP will reject such a message, even though a receiving OLSRv2-unaware implementation of NHDP will process it. This is because the OLSRv2-aware implementation has access to additional information (that the HELLO message is definitely invalid and the message is best ignored) as it is unknown what other errors it might contain.
然而，这些限制并不意味着基本协议完全忽略添加的信息。假设OLSRv2（包括NHDP）的错误实现创建了一条HELLO消息，该消息将同一链路度量的两个不同值分配给一个地址，这是[RFC7181]不允许的。NHDP的接收OLSRv2感知实现将拒绝此类消息，即使NHDP的接收OLSRv2感知实现将对其进行处理。这是因为OLSRv2感知实现可以访问其他信息（HELLO消息肯定无效，最好忽略该消息），因为不知道它可能包含哪些其他错误。
Within a message, the attributes are represented by TLVs. Particularly for Address Block TLVs, different TLVs can represent the same information. For example, using the LINK_STATUS TLV defined in [RFC6130], if some addresses have Value SYMMETRIC and some have Value HEARD, arranged in that order, then this information can be represented using two single-value TLVs or one multivalue TLV. The latter can be used even if the addresses are not so ordered.
在消息中，属性由TLV表示。特别是对于地址块TLV，不同的TLV可以表示相同的信息。例如，使用[RFC6130]中定义的链路状态TLV，如果某些地址具有值对称性，而某些地址具有按该顺序排列的值，则可以使用两个单值TLV或一个多值TLV来表示此信息。即使地址不按顺序排列，也可以使用后者。
A protocol MAY use any representation of information using TLVs that convey the required information. A protocol SHOULD use an efficient representation, but this is a quality of implementation issue. A protocol MUST recognize any permitted representation of the information; even if it chooses to, for example, only use multivalue TLVs, it MUST recognize single-value TLVs (and vice versa).
协议可以使用传递所需信息的TLV来表示信息。协议应该使用有效的表示，但这是一个实现质量问题。协议必须承认信息的任何许可表示；例如，即使它选择只使用多值TLV，它也必须识别单值TLV（反之亦然）。
A protocol defining new TLVs MUST respect the naming and organizational rules in [RFC7631]. It SHOULD follow the guidance in [RFC7188], see Section 6.3. (This specification does not, however, relax the application of [RFC7188] where it is mandated.)
定义新TLV的协议必须遵守[RFC7631]中的命名和组织规则。应遵循[RFC7188]中的指南，参见第6.3节。（但是，本规范并未放宽[RFC7188]的强制应用。）
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 of a TLV of an unrecognized type. The protocol MUST ignore any such TLVs when processing the message. The protocol MUST NOT remove or change any such TLVs if the message is to be forwarded unchanged. Such behavior may have the following consequences:
除了由于未知TLV或TLV值而不拒绝消息外，协议还不得基于包含无法识别类型的TLV而拒绝消息。协议在处理消息时必须忽略任何此类TLV。如果要转发未更改的消息，则协议不得删除或更改任何此类TLV。此类行为可能产生以下后果：
o It might disrupt the operation of an extension of which it is unaware. Note that it is the responsibility of a protocol extension to handle interoperation with unextended instances of the protocol. For example, OLSRv2 [RFC7181] adds an MPR_WILLING TLV to HELLO messages (created by NHDP [RFC6130], of which it is an extension) to recognize this case (and for other reasons).
o 它可能会中断它不知道的扩展的操作。请注意，协议扩展负责处理与未扩展的协议实例的互操作。例如，OLSRv2[RFC7181]向HELLO消息（由NHDP[RFC6130]创建，它是其中的一个扩展）添加了一个MPR_意愿TLV，以识别这种情况（以及其他原因）。
o It would prevent the operation of end-to-end message authentication using [RFC7182] or any similar mechanism. The use of immutable (apart from hop count and/or hop limit) messages by a protocol is strongly RECOMMENDED for that reason.
o 它将阻止使用[RFC7182]或任何类似机制进行端到端消息身份验证的操作。因此，强烈建议协议使用不可变（除了跃点计数和/或跃点限制）消息。
This section concerns the properties of the format defined in [RFC5444] itself, rather than the properties of protocols using it.
本节涉及[RFC5444]本身中定义的格式的属性，而不是使用它的协议的属性。
The elements defined in [RFC5444] have structures that are managed by a number of flags fields:
[RFC5444]中定义的元素具有由多个标志字段管理的结构：
o Packet flags field (4 bits, 2 used) that manages the contents of the Packet Header.
o 数据包标志字段（4位，使用2位），用于管理数据包头的内容。
o Message flags field (4 bits, 4 used) that manages the contents of the Message Header.
o 消息标志字段（4位，使用4位），用于管理消息头的内容。
o Address Block flags field (8 bits, 4 used) that manages the contents of an Address Block.
o 地址块标志字段（8位，使用4位），用于管理地址块的内容。
o TLV flags field (8 bits, 5 used) that manages the contents of a TLV.
o TLV标志字段（8位，使用5位），用于管理TLV的内容。
Note that all of these flags are structural; they specify which elements are present or absent, field lengths, or whether a field has one or multiple values in it.
请注意，所有这些标志都是结构性的；它们指定哪些元素存在或不存在，字段长度，或者字段中是否有一个或多个值。
In the current version of [RFC5444], indicated by version number 0 in the <version> field of the Packet Header, unused bits in these flags fields are stated as "are RESERVED and SHOULD each be cleared ('0')
在[RFC5444]的当前版本中，由数据包头的<version>字段中的版本号0表示，这些标志字段中未使用的位表示为“已保留且应清除（'0'）
on transmission and SHOULD be ignored on reception". For the avoidance of any compatibility issues, with regard to version number 0, this is updated to "MUST each be cleared ('0') on transmission and MUST be ignored on reception".
为避免任何兼容性问题，关于版本号0，更新为“传输时必须清除（'0'），接收时必须忽略”。
If a specification updating [RFC5444] introduces new flags in one of 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 followed:
如果规范更新[RFC5444]在数据包、地址块或TLV的标志字段之一引入新标志（消息标志字段中没有未使用的标志），则必须遵循以下规则：
o The version number contained in the <version> field of the Packet Header MUST NOT be 0.
o 数据包头的<version>字段中包含的版本号不得为0。
o The new flag(s) MUST indicate the structure of the corresponding packet, Address Block, or TLV. They MUST NOT be used to indicate any other semantics, such as message forwarding behavior.
o 新标志必须指示相应数据包、地址块或TLV的结构。它们不能用于指示任何其他语义，例如消息转发行为。
An update that would be incompatible with the current specification of [RFC5444] SHOULD NOT be created unless there is a pressing reason for it that cannot be satisfied using the current specification (e.g., by use of a suitable Message TLV or Address Block TLV).
不应创建与[RFC5444]当前规范不兼容的更新，除非存在使用当前规范无法满足的紧迫原因（例如，通过使用合适的消息TLV或地址块TLV）。
During the development of [RFC5444] (and since publication thereof), some proposals have been made to use these RESERVED flags to specify behavior rather than structure, message forwarding in particular. These proposals were, after due consideration, not accepted for a number of reasons. These reasons include that message forwarding, in particular, is protocol specific; for example, [RFC7181] forwards messages using its MPR mechanism rather than a "blind" flooding mechanism. (These proposals were made during the development of [RFC5444] when there were still unused message flags. Later addition of a 4-bit Message Address Length field later left no unused message flags, but other flags fields still have unused flags.)
在[RFC5444]的开发过程中（以及自发布以来），已经提出了一些建议，使用这些保留标志来指定行为而不是结构，尤其是消息转发。这些建议在经过适当考虑后，由于若干原因未被接受。这些原因包括，特别是消息转发是特定于协议的；例如，[RFC7181]使用其MPR机制而不是“盲”泛洪机制转发消息。（这些建议是在[RFC5444]开发期间提出的，当时仍然存在未使用的消息标志。后来添加了4位消息地址长度字段，没有留下未使用的消息标志，但其他标志字段仍然存在未使用的标志。）
The ability to organize addresses into the same or different Address Blocks and to change the order of addresses within an Address Block (as well as the flexibility of the TLV specification) enables avoiding unnecessary repetition of information and can consequently generate smaller messages. There are no algorithms for address organization, compression, or for TLV usage in [RFC5444]; any algorithms that leave the information content unchanged MAY be used when generating a message. See also Appendix B.
将地址组织到相同或不同的地址块中以及更改地址块内地址顺序的能力（以及TLV规范的灵活性）能够避免不必要的信息重复，从而生成较小的消息。[RFC5444]中没有用于地址组织、压缩或TLV使用的算法；生成消息时，可以使用任何保持信息内容不变的算法。另见附录B。
[RFC5444] allows the addresses in an Address Block to be compressed. A protocol generating a message SHOULD compress addresses as much as it can.
[RFC5444]允许压缩地址块中的地址。生成消息的协议应该尽可能地压缩地址。
Addresses in an Address Block 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. Each has a length that is greater than or equal to zero, the sum of the lengths being the address length. (The Mid length is deduced from this relationship.) Compression is possible when the Head and/or the Tail have non-zero length. An additional compression is possible when the Tail consists of all zero-valued octets. Expected use cases include IPv4 and IPv6 addresses from within the same prefix and that therefore have a common Head, IPv4 subnets with a common zero-valued Tail, and IPv6 addresses with a common Tail representing an interface identifier as well as having a possible common Head. Note that when, for example, IPv4 addresses have a common Head, their Tail will usually have length zero.
地址块中的地址由头、中间和尾组成，其中地址块中的所有地址都有相同的头和尾，但中间不同。每个地址都有一个大于或等于零的长度，长度之和就是地址长度。（中间长度由此关系推导得出。）当头部和/或尾部长度非零时，压缩是可能的。当尾部由所有零值八位组组成时，可以进行额外的压缩。预期的用例包括来自同一前缀的IPv4和IPv6地址，因此具有公共头、具有公共零值尾的IPv4子网，以及具有表示接口标识符的公共尾并具有可能的公共头的IPv6地址。请注意，例如，当IPv4地址有一个公共头时，它们的尾部的长度通常为零。
For example:
例如：
o The IPv4 addresses 192.0.2.1 and 192.0.2.2 would, for greatest efficiency, have a 3-octet Head, a 1-octet Mid, and a 0-octet Tail.
o 为了获得最大的效率，IPv4地址192.0.2.1和192.0.2.2将具有3个八位字节的头、1个八位字节的中间和0个八位字节的尾。
o The IPv6 addresses 2001:DB8:prefix1:interface and 2001:DB8:prefix2:interface that use the same interface identifier but completely different prefixes (except as noted) would, for 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 smaller Mid if the prefixes have any octets in common.)
o IPv6地址2001:DB8:prefix1:interface和2001:DB8:prefix2:interface使用相同的接口标识符，但前缀完全不同（除非另有说明），为了获得最大效率，它们将具有4个八位字节的头、4个八位字节的中间和8个八位字节的尾。（如果前缀有任何共同的八位字节，它们可以有更大的头部和/或尾部以及更小的中部。）
Putting addresses into a message efficiently also requires consideration of the following:
有效地将地址放入消息还需要考虑以下因素：
o The split of the addresses into Address Blocks.
o 将地址拆分为地址块。
o The order of the addresses within the Address Blocks.
o 地址块中地址的顺序。
This split and/or ordering is for efficiency only; it does not provide any information. The split of the addresses affects both the address compression and the TLV efficiency (see Section 6.2); the order of the addresses within an Address Block affects only the TLV efficiency. However, using more Address Blocks than needed can increase the message size due to the overhead of each Address Block and the following TLV Block, and/or if additional TLVs are now required.
此拆分和/或订购仅用于提高效率；它没有提供任何信息。地址分割会影响地址压缩和TLV效率（见第6.2节）；地址块中地址的顺序只影响TLV效率。然而，由于每个地址块和后续TLV块的开销，和/或如果现在需要额外的TLV，使用比需要更多的地址块可能会增加消息大小。
The order of addresses can be as simple as sorting the addresses, but if many addresses have the same TLV Types attached, it might be more useful to put these addresses together, either within the same Address Block as other addresses or in a separate Address Block. A separate Address Block might also improve address compression, for example, if more than one address form is used (such as from independent subnets). An example of the possible use of address ordering is a HELLO message from [RFC6130] that could be generated with local interface addresses first and neighbor addresses later. These could be in separate Address Blocks.
地址的顺序可以与对地址进行排序一样简单，但如果许多地址都附加了相同的TLV类型，则将这些地址放在一起可能更有用，可以与其他地址放在同一地址块中，也可以放在单独的地址块中。单独的地址块还可以改进地址压缩，例如，如果使用了多个地址形式（例如来自独立子网）。可能使用地址排序的一个示例是来自[RFC6130]的HELLO消息，该消息可以首先使用本地接口地址生成，然后使用邻居地址生成。这些可以在单独的地址块中。
When considering TLVs, the main opportunities for creating more efficient messages are in Address Block TLVs rather than Message TLVs. The approaches described here apply to each Address Block.
在考虑TLV时，创建更高效消息的主要机会是地址块TLV，而不是消息TLV。这里描述的方法适用于每个地址块。
An Address Block TLV provides attributes for one address or a contiguous (as stored in the Address Block) set of addresses (with a special case for when this set is of all of the addresses in the Address Block). When associated with more than one address, a TLV can be single value (associating the same attribute with each address) or multivalue (associating a separate attribute with each address).
地址块TLV提供一个地址或连续（存储在地址块中）地址集的属性（当该地址集为地址块中的所有地址时有一个特例）。当与多个地址关联时，TLV可以是单值（将同一属性与每个地址关联）或多值（将单独的属性与每个地址关联）。
The approach that is simplest to implement is to use multivalue TLVs that cover all affected addresses. However, unless care is taken to order addresses appropriately, these affected addresses might not all be contiguous. Some approaches to this are the following:
最简单的实现方法是使用覆盖所有受影响地址的多值TLV。但是，除非注意对地址进行适当的排序，否则这些受影响的地址可能并不都是连续的。实现这一点的一些方法如下：
o Reorder the addresses. It is, for example, possible (though not straightforward, and beyond the scope of this document to describe exactly how) to order all addresses in HELLO message as specified in [RFC6130] so that all TLVs used only cover contiguous addresses. This is even possible if the MPR TLV specified in OLSRv2 [RFC7181] is added; but it is not possible, in general, if the LINK_METRIC TLV specified in OLSRv2 [RFC7181] is also added.
o 重新排列地址。例如，可以按照[RFC6130]中的规定对HELLO消息中的所有地址进行排序（尽管不是很简单，也超出了本文档的范围来准确描述如何进行排序），以便使用的所有TLV仅覆盖连续地址。如果添加了OLSRv2[RFC7181]中规定的MPR TLV，这甚至是可能的；但是，如果还添加了OLSRv2[RFC7181]中指定的链路度量TLV，则通常不可能。
o Allow the TLV to span over addresses that do not need the corresponding attribute and use a Value that indicates no information; see Section 6.3.
o 允许TLV跨越不需要相应属性的地址，并使用表示无信息的值；见第6.3节。
o Use more than one TLV. Note that this can be efficient when the TLVs become single-value TLVs. In a typical case where a LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with enough addresses sorted appropriately, two single-value TLVs can be more efficient than one multivalue TLV. If only one Value is
o 使用多个TLV。请注意，当TLV变为单值TLV时，这是有效的。在典型情况下，链路状态TLV仅使用听到和对称的值，并且有足够的地址进行适当排序，两个单值TLV可能比一个多值TLV更有效。如果只有一个值是
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 used.
涉及（如NHDP处于稳定状态，链路状态在所有情况下均等于对称），则应始终使用一个单值TLV。
If, for example, an Address Block contains five addresses, the first 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 TLVs. It is, however, more efficient to do this with one multivalue LINK_STATUS TLV, assigning the third address the Value UNSPECIFIED (as defined in [RFC7188]). In general, use of UNSPECIFIED Values allows use of fewer TLVs and is thus often an efficiency gain; however, a long run of consecutive UNSPECIFIED Values (more than the overhead of a TLV) can make use of more TLVs more efficient.
例如，如果一个地址块包含五个地址，前两个和后两个需要使用链路状态TLV分配值，但第三个不需要，则可以使用两个TLV来指示。但是，使用一个多值链路状态TLV，将未指定的值分配给第三个地址（如[RFC7188]中所定义），这样做更有效。一般来说，使用未指定的值允许使用较少的TLV，因此通常是一种效率增益；但是，连续未指定值的长期运行（超过TLV的开销）可以使更多TLV的使用更有效。
Some other TLVs might need a different approach. As noted in [RFC7188], but implicitly permissible before then, the LINK_METRIC TLV (defined in [RFC7181]) has two octet Values whose first four bits 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 is thus the equivalent of an UNSPECIFIED Value.
其他一些TLV可能需要不同的方法。如[RFC7188]所述，但在此之前是隐含允许的，链路度量TLV（在[RFC7181]中定义）有两个八位组值，其前四位是指示度量是否适用于四种情况的标志；如果这些都是零，那么度量在这种情况下不适用，因此这相当于一个未指定的值。
[RFC7188] requires that protocols that extend [RFC6130] and [RFC7181] allow unspecified values in TLVs where applicable; it is here RECOMMENDED that all protocols follow that advice. In particular, it is RECOMMENDED that when defining an Address Block TLV with discrete Values, an UNSPECIFIED Value is defined with the same value (255), and a modified approach should be used where possible for other Address Block TLVs (for example, as is done for a LINK_METRIC TLV, though not necessarily using that exact approach).
[RFC7188]要求扩展[RFC6130]和[RFC7181]的协议允许TLV中的未指定值（如适用）；这里建议所有协议遵循该建议。特别是，建议在使用离散值定义地址块TLV时，使用相同的值（255）定义未指定的值，并在可能的情况下对其他地址块TLV使用修改的方法（例如，对于链路度量TLV，尽管不一定使用该确切方法）。
It might be argued that provision of an unspecified value (of any form) to allow an Address Block TLV to cover unaffected addresses is not always necessary because addresses can be reordered to avoid this. However, ordering addresses to avoid this for all TLVs that might be used is not, in general, possible.
有人可能会争辩说，提供一个未指定的值（任何形式）以允许地址块TLV覆盖未受影响的地址并不总是必要的，因为地址可以重新排序以避免这种情况。然而，对于所有可能使用的TLV，排序地址以避免这种情况通常是不可能的。
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 defined length for that TLV Type, then the following rules are adopted:
此外，[RFC7188]建议，如果TLV值（地址块TLV的每个地址）的单个长度与该TLV类型的定义长度不匹配，则采用以下规则：
o If the received single-length is greater than the expected single length, then the excess octets MUST be ignored.
o 如果接收到的单个长度大于预期的单个长度，则必须忽略多余的八位字节。
o If the received single-length is less than the expected single length, then the absent octets MUST be considered to have all bits cleared (0).
o 如果接收到的单个长度小于预期的单个长度，则必须将缺少的八位字节视为已清除所有位（0）。
This specification RECOMMENDS a similar rule for all protocols defining new TLVs.
本规范建议对定义新TLV的所有协议采用类似规则。
This document does not specify a protocol but provides rules and recommendations for how to design protocols using [RFC5444], whose security considerations apply.
本文档未指定协议，但提供了如何使用[RFC5444]设计协议的规则和建议，其安全性考虑适用。
If the recommendation from Section 4.4.1 is followed, which specifies that messages are not modified (except for hop count and hop limit) when forwarded, then the security framework for [RFC5444] (specified in [RFC7182]) can be used in full. If that recommendation is not followed, then the Packet TLVs from [RFC7182] can be used, but the Message TLVs from [RFC7182] cannot be used as intended.
如果遵循第4.4.1节的建议，其中规定转发时不修改消息（跃点计数和跃点限制除外），则[RFC5444]（在[RFC7182]中指定）的安全框架可以完全使用。如果未遵循该建议，则可以使用来自[RFC7182]的数据包TLV，但无法按预期使用来自[RFC7182]的消息TLV。
In either case, a protocol using [RFC5444] MUST document whether it is using [RFC7182] and if so, how.
在任何一种情况下，使用[RFC5444]的协议都必须记录是否使用[RFC7182]，如果是，如何使用。
The Expert Review guidelines in [RFC5444] are updated to include the general requirement that:
[RFC5444]中的专家评审指南已更新，以包括以下一般要求：
o The Designated Expert will consider the limited TLV and (especially) Message Type space when considering whether a requested allocation is allowed and whether a more efficient allocation than that requested is possible.
o 指定的专家将考虑有限的TLV和（特别是）消息类型空间，考虑是否允许请求的分配，以及是否比请求的更有效的分配是可能的。
IANA has added this document as a reference for the following Mobile Ad hoc NETwork (MANET) Parameters registries:
IANA已添加本文件作为以下移动自组织网络（MANET）参数注册表的参考：
o Message Types o Packet TLV Types o Message TLV Types o Address Block TLV Types
o 消息类型o数据包TLV类型o消息TLV类型o地址块TLV类型
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.
[RFC5444]Clausen，T.，Dearlove，C.，Dean，J.，和C.Adjih，“通用移动自组网（MANET）数据包/消息格式”，RFC 5444，DOI 10.17487/RFC54442009年2月<https://www.rfc-editor.org/info/rfc5444>.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 2009, <https://www.rfc-editor.org/info/rfc5498>.
[RFC5498]Chakeres，I.“移动自组网（MANET）协议的IANA分配”，RFC 5498，DOI 10.17487/RFC5498，2009年3月<https://www.rfc-editor.org/info/rfc5498>.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <https://www.rfc-editor.org/info/rfc7182>.
[RFC7182]Herberg，U.，Clausen，T.，和C.Dearlove，“移动自组网（MANET）的完整性检查值和时间戳TLV定义”，RFC 7182，DOI 10.17487/RFC7182，2014年4月<https://www.rfc-editor.org/info/rfc7182>.
[RFC7631] Dearlove, C. and T. Clausen, "TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format", RFC 7631, DOI 10.17487/RFC7631, September 2015, <https://www.rfc-editor.org/info/rfc7631>.
[RFC7631]Dearlove，C.和T.Clausen，“移动自组网（MANET）通用分组/消息格式中的TLV命名”，RFC 7631，DOI 10.17487/RFC76312015年9月<https://www.rfc-editor.org/info/rfc7631>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[G9903] ITU-T, "G.9903 : Narrowband orthogonal frequency division multiplexing power line communication transceivers for G3-PLC networks", ITU-T Recommendation G.9903, August 2017.
[G9903]ITU-T，“G.9903：G3-PLC网络用窄带正交频分复用电力线通信收发器”，ITU-T建议G.9903，2017年8月。
[RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, DOI 10.17487/RFC3626, October 2003, <https://www.rfc-editor.org/info/rfc3626>.
[RFC3626]Clausen，T.，Ed.和P.Jacquet，Ed.，“优化链路状态路由协议（OLSR）”，RFC 3626，DOI 10.17487/RFC3626，2003年10月<https://www.rfc-editor.org/info/rfc3626>.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009, <https://www.rfc-editor.org/info/rfc5497>.
[RFC5497]Clausen，T.和C.Dearlove，“在移动自组网（MANET）中表示多值时间”，RFC 5497，DOI 10.17487/RFC5497，2009年3月<https://www.rfc-editor.org/info/rfc5497>.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <https://www.rfc-editor.org/info/rfc6130>.
[RFC6130]Clausen，T.，Dearlove，C.，和J.Dean，“移动自组织网络（MANET）邻域发现协议（NHDP）”，RFC 6130，DOI 10.17487/RFC6130，2011年4月<https://www.rfc-editor.org/info/rfc6130>.
[RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI 10.17487/RFC6621, May 2012, <https://www.rfc-editor.org/info/rfc6621>.
[RFC6621]Macker，J.，Ed.，“简化多播转发”，RFC 6621，DOI 10.17487/RFC6621，2012年5月<https://www.rfc-editor.org/info/rfc6621>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, DOI 10.17487/RFC7181, April 2014, <https://www.rfc-editor.org/info/rfc7181>.
[RFC7181]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，RFC 7181，DOI 10.17487/RFC7181，2014年4月<https://www.rfc-editor.org/info/rfc7181>.
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, <https://www.rfc-editor.org/info/rfc7183>.
[RFC7183]Herberg，U.，Dearlove，C.，和T.Clausen，“邻域发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性保护”，RFC 7183，DOI 10.17487/RFC7183，2014年4月<https://www.rfc-editor.org/info/rfc7183>.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs", RFC 7188, DOI 10.17487/RFC7188, April 2014, <https://www.rfc-editor.org/info/rfc7188>.
[RFC7188]Dearlove，C.和T.Clausen，“优化链路状态路由协议版本2（OLSRv2）和MANET邻居发现协议（NHDP）扩展TLV”，RFC 7188，DOI 10.17487/RFC7188，2014年4月<https://www.rfc-editor.org/info/rfc7188>.
[RFC7722] Dearlove, C. and T. Clausen, "Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7722, DOI 10.17487/RFC7722, December 2015, <https://www.rfc-editor.org/info/rfc7722>.
[RFC7722]Dearlove，C.和T.Clausen，“优化链路状态路由协议版本2（OLSRv2）的多拓扑扩展”，RFC 7722，DOI 10.17487/RFC7722，2015年12月<https://www.rfc-editor.org/info/rfc7722>.
This section describes a conceptual way to consider the information in a message. It can be used as the basis of an approach to parsing a message from the information that it contains and to creating a message from the information that it is to contain. However, there is no requirement that a protocol does so. This approach can be used 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, possibly multivalued, maps:
一条消息（不包括消息头）可以由两个可能是多值的映射表示：
o Message: (Full Type) -> (length, Value)
o 消息：（完整类型）->（长度、值）
o Address: (address, Full Type) -> (length, Value)
o 地址：（地址，完整类型）->（长度，值）
These maps (plus a representation of the Message Header) can be the basis for a generic representation of information in a message. Such maps can be created by parsing the message or can be constructed using the protocol rules for creating a message and later converted into the octet form of the message specified in [RFC5444].
这些映射（加上消息头的表示）可以作为消息中信息的通用表示的基础。此类映射可以通过解析消息来创建，也可以使用创建消息的协议规则来构建，然后转换为[RFC5444]中指定的消息的八位字节形式。
While of course any implementation of software that represents software in the above form can specify an Application Programming Interface (API) for that software, such an interface is not proposed here. First, a full API would be specific to a programming language. Second, even within the above framework, there are alternative approaches to such an interface. For example, and for illustrative purposes only, consider the alternative address mappings:
当然，以上述形式表示软件的任何软件实现都可以为该软件指定应用程序编程接口（API），但这里不建议使用这种接口。首先，完整的API是特定于编程语言的。第二，即使在上述框架内，也有其他方法可以实现这种接口。例如，仅为了说明的目的，考虑替代地址映射：
o Input: address and Full Type. Output: list of (length, Value) pairs. Note that for most Full Types, it will be known in advance that this list will have a length of zero or one. The list of addresses that can be used as inputs with non-empty output would need to be provided as a separate output.
o 输入：地址和完整类型。输出：（长度、值）对的列表。请注意，对于大多数完整类型，将提前知道此列表的长度为零或一。可以用作非空输出的输入的地址列表需要作为单独的输出提供。
o Input: Full Type. Output: list of (address, length, Value) triples. As this list length can be significant, a possible output will be of one or two iterators that will allow iterating through that list. (One iterator that can detect the end of the list or a pair of iterators specifying a range.)
o 输入：完整类型。输出：三个（地址、长度、值）的列表。由于该列表长度可能很长，因此可能的输出将是一个或两个迭代器，这些迭代器将允许遍历该列表。（一个迭代器可以检测列表的结尾，或者一对迭代器指定一个范围。）
Additional differences in the interface might relate to, for example, the ordering of output lists.
接口中的其他差异可能与输出列表的顺序有关。
There is scope for creating a protocol-independent optimizer for [RFC5444] messages that performs appropriate address re-organization (ordering and Address Block separation) and TLV changes (of number, of being single value or multivalue, and use of unspecified values) to create more compact messages. The possible gain depends on the efficiency of the original message creation and the specific details of the message. Note that this process cannot be TLV Type independent; for example, a LINK_METRIC TLV has a more complicated Value structure than a LINK_STATUS TLV does if using UNSPECIFIED Values.
可以为[RFC5444]消息创建协议独立优化器，该优化器执行适当的地址重新组织（排序和地址块分离）和TLV更改（数量、单值或多值以及未指定值的使用），以创建更紧凑的消息。可能的收益取决于原始消息创建的效率和消息的具体细节。注意，此过程不能与TLV类型无关；例如，如果使用未指定的值，则链路度量TLV的值结构比链路状态TLV的值结构更复杂。
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.
这种独立于协议的优化器可由生成消息的路由器使用，但不得用于未经路由器转发的消息。
Acknowledgments
致谢
The authors thank Cedric Adjih (INRIA) and Justin Dean (NRL) for their contributions as authors of RFC 5444.
作者感谢Cedric Adjih（INRIA）和Justin Dean（NRL）作为RFC 5444的作者所做的贡献。
Authors' Addresses
作者地址
Thomas Clausen Ecole Polytechnique 91128 Palaiseau Cedex France
托马斯·克劳森理工学院91128法国塞德克斯宫
Phone: +33-6-6058-9349
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org
Phone: +33-6-6058-9349
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org
Christopher Dearlove BAE Systems Applied Intelligence Laboratories West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems应用情报实验室英国切姆斯福德大巴德西汉宁菲尔德路
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com
Ulrich Herberg
乌尔里希·赫伯格
Email: ulrich@herberg.name
URI: http://www.herberg.name
Email: ulrich@herberg.name
URI: http://www.herberg.name
Henning Rogge Fraunhofer FKIE Fraunhofer Strasse 20 53343 Wachtberg Germany
亨宁·罗格·弗劳恩霍夫FKIE弗劳恩霍夫大街20 53343德国瓦赫特堡
Email: henning.rogge@fkie.fraunhofer.de
Email: henning.rogge@fkie.fraunhofer.de