Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 6551 Cisco Systems
Category: Standards Track M. Kim, Ed.
ISSN: 2070-1721 Corporate Technology Group, KT
K. Pister
Dust Networks
N. Dejean
Elster SAS
D. Barthel
France Telecom Orange
March 2012
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 6551 Cisco Systems
Category: Standards Track M. Kim, Ed.
ISSN: 2070-1721 Corporate Technology Group, KT
K. Pister
Dust Networks
N. Dejean
Elster SAS
D. Barthel
France Telecom Orange
March 2012
Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
低功耗有损网络中用于路径计算的路由度量
Abstract
摘要
Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL).
低功耗和有损网络（LLN）与传统有线和adhoc网络相比具有独特的特性，后者需要指定新的路由度量和约束。相比之下，对于使用跳数或链路度量的典型内部网关协议（IGP）路由度量，本文档指定了一组适用于LLN的链路和节点路由度量和约束，供低功耗和有损网络（RPL）路由协议使用。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6551.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6551.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
本文件的出版。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................6
2. Object Formats ..................................................7
2.1. DAG Metric Container Format ................................7
2.2. Use of Multiple DAG Metric Containers .....................10
2.3. Metric Usage ..............................................10
3. Node Metric/Constraint Objects .................................11
3.1. Node State and Attribute Object ...........................11
3.2. Node Energy Object ........................................12
3.3. Hop Count Object ..........................................16
4. Link Metric/Constraint Objects .................................17
4.1. Throughput ................................................17
4.2. Latency ...................................................18
4.3. Link Reliability ..........................................19
4.3.1. The Link Quality Level Reliability Metric ..........19
4.3.2. The ETX Reliability Object .........................21
4.4. Link Color Object .........................................22
4.4.1. Link Color Object Description ......................22
4.4.2. Mode of Operation ..................................24
5. Computation of Dynamic Metrics and Attributes ..................24
6. IANA Considerations ............................................25
6.1. Routing Metric/Constraint Type ............................25
6.2. Routing Metric/Constraint TLVs ............................25
6.3. Routing Metric/Constraint Common Header Flag Field ........26
6.4. Routing Metric/Constraint Common Header A Field ...........26
6.5. NSA Object Flags Field ....................................26
6.6. Hop-Count Object Flags Field ..............................27
6.7. Node Type Field ...........................................27
7. Security Considerations ........................................27
8. Acknowledgements ...............................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................28
1. Introduction ....................................................3
1.1. Requirements Language ......................................6
2. Object Formats ..................................................7
2.1. DAG Metric Container Format ................................7
2.2. Use of Multiple DAG Metric Containers .....................10
2.3. Metric Usage ..............................................10
3. Node Metric/Constraint Objects .................................11
3.1. Node State and Attribute Object ...........................11
3.2. Node Energy Object ........................................12
3.3. Hop Count Object ..........................................16
4. Link Metric/Constraint Objects .................................17
4.1. Throughput ................................................17
4.2. Latency ...................................................18
4.3. Link Reliability ..........................................19
4.3.1. The Link Quality Level Reliability Metric ..........19
4.3.2. The ETX Reliability Object .........................21
4.4. Link Color Object .........................................22
4.4.1. Link Color Object Description ......................22
4.4.2. Mode of Operation ..................................24
5. Computation of Dynamic Metrics and Attributes ..................24
6. IANA Considerations ............................................25
6.1. Routing Metric/Constraint Type ............................25
6.2. Routing Metric/Constraint TLVs ............................25
6.3. Routing Metric/Constraint Common Header Flag Field ........26
6.4. Routing Metric/Constraint Common Header A Field ...........26
6.5. NSA Object Flags Field ....................................26
6.6. Hop-Count Object Flags Field ..............................27
6.7. Node Type Field ...........................................27
7. Security Considerations ........................................27
8. Acknowledgements ...............................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................28
This document makes use of the terminology defined in [ROLL-TERMS].
本文件使用了[滚动条款]中定义的术语。
Low-power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
与[RFC5548]、[RFC5673]、[RFC5826]和[RFC5867]中阐述的传统有线或自组织网络相比，低功耗和有损网络（LLN）具有特定的路由特性。
Historically, IGP, such as OSPF ([RFC2328]) and IS-IS ([RFC1195]), has used quantitative static link metrics. Other mechanisms, such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]), make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs).
历史上，诸如OSPF（[RFC2328]）和IS-IS（[RFC1195]）等IGP使用了定量静态链路度量。其他机制，如多协议标签交换（MPLS）流量工程（TE）（参见[RFC2702]和[RFC3209]），利用其他链路属性，如可用保留带宽（动态）或链路亲和力（大部分时间是静态的）来计算流量工程标签交换路径（TE LSP）的约束最短路径。
This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low-Power and Lossy Networks (RPL) specified in [RFC6550].
本文件规定了[RFC6550]中规定的低功耗和有损网络（RPL）路由协议在路径计算中使用的路由度量和约束。
One of the prime objectives of this document is to define a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint, whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints. New routing metrics and constraints could be defined in the future, as needed.
本文档的主要目标之一是定义一种灵活的机制，用于公布RPL使用的路由度量和约束。一些RPL实现可能选择采用一种非常简单的方法，该方法基于使用一个没有约束的度量，而其他实现可能使用一组更大的链路和节点路由度量和约束。该规范提供了高度的灵活性以及一组路由度量和约束。将来可以根据需要定义新的路由度量和约束。
The metrics and constraints defined in this document are carried in objects that are OPTIONAL from the point of view of a RPL implementation. This means that implementations are free to include different subsets of the functions (metric, constraint) defined in this document. Specific sets of metrics/constraints and other optional RPL parameters for use in key environments will be specified as compliance profiles in applicability profile documents produced by the ROLL working group. Note that RPL can even make use of no metric, for example, using the Objective Function defined in [RFC6552].
本文档中定义的度量和约束包含在对象中，从RPL实现的角度来看，这些对象是可选的。这意味着实现可以自由地包括本文档中定义的函数（度量、约束）的不同子集。关键环境中使用的特定度量/约束集和其他可选RPL参数将在滚动工作组编制的适用性概要文件中指定为合规性概要文件。请注意，RPL甚至可以不使用度量，例如，使用[RFC6552]中定义的目标函数。
RPL is a distance vector routing protocol variant that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG formation rules are defined in [RFC6550]:
RPL是一种距离向量路由协议变体，它基于路由度量和约束构建有向无环图（DAG）。[RFC6550]中定义了DAG形成规则：
o The Destination-Oriented Directed Acyclic Graph (DODAG) root, as defined in [RFC6550], may advertise a routing constraint used as a "filter" to prune links and nodes that do not satisfy specific properties. For example, it may be required for a path only to traverse nodes that are mains-powered or links that have at least a minimum reliability or a specific "color" reflecting a user-defined link characteristic (e.g., the link layer supports encryption).
o [RFC6550]中定义的面向目的地的有向无环图（DODAG）根可以公布用作“过滤器”的路由约束，以修剪不满足特定属性的链接和节点。例如，可能要求路径仅遍历由电源供电的节点或至少具有最低可靠性或反映用户定义的链路特性的特定“颜色”（例如，链路层支持加密）的链路。
o A routing metric is a quantitative value that is used to evaluate the path cost. Link and node metrics are usually (but not always) additive.
o 路由度量是用于评估路径成本的定量值。链接和节点度量通常（但不总是）是相加的。
The best path is the path that satisfies all supplied constraints (if any) and that has the lowest cost with respect to some specified metrics. It is also called the shortest constrained path (in the presence of constraints).
最佳路径是满足所有提供的约束（如果有的话）的路径，并且对于某些指定的度量具有最低的成本。它也称为最短约束路径（存在约束时）。
Routing metrics may be categorized according to the following characteristics:
路由度量可根据以下特征进行分类：
o Link versus node metrics
o 链接与节点度量
o Qualitative versus quantitative
o 定性与定量
o Dynamic versus static
o 动态与静态
Routing requirements documents (see [RFC5673], [RFC5826], [RFC5548], and [RFC5867]) observe that it must be possible to take into account a variety of node constraints/metrics during path computation.
路由要求文件（参见[RFC5673]、[RFC5826]、[RFC5548]和[RFC5867]）指出，在路径计算期间，必须能够考虑各种节点约束/度量。
Some link or node characteristics (e.g., link reliability, remaining energy on the node) may be used by RPL either as routing constraints or as metrics (or sometimes both). For example, the path may be computed to avoid links that do not provide a sufficient level of reliability (use as a constraint) or as the path offering most links with a specified reliability level (use as a metric). This document provides the flexibility to use link and node characteristics as constraints and/or metrics.
RPL可以将某些链路或节点特性（例如，链路可靠性、节点上的剩余能量）用作路由约束或度量（有时两者兼而有之）。例如，可计算路径以避免不提供足够可靠性水平的链路（用作约束）或作为提供具有指定可靠性水平的大多数链路的路径（用作度量）。本文档提供了将链接和节点特征用作约束和/或度量的灵活性。
The use of link and node routing metrics and constraints is not exclusive (e.g., it is possible to advertise a "hop count" both as a metric to optimize the computed path and as a constraint (e.g., "Path should not exceed n hops")).
链路和节点路由度量和约束的使用不是排他性的（例如，可以将“跃点计数”作为优化计算路径的度量和约束（例如，“路径不应超过n个跃点”））。
Links in LLN commonly have rapidly changing node and link characteristics; thus, routing metrics must be dynamic and techniques must be used to smooth out the dynamicity of these metrics so as to
LLN中的链路通常具有快速变化的节点和链路特性；因此，路由度量必须是动态的，并且必须使用技术来平滑这些度量的动态性，以便
avoid routing oscillations. For instance, in addition to the dynamic nature of some links (e.g., wireless but also Power Line Communication (PLC) links), nodes' resources, such as residual energy, are changing continuously and may have to be taken into account during the path computation.
避免路由振荡。例如，除了某些链路（例如，无线但也包括电力线通信（PLC）链路）的动态特性外，节点的资源（例如剩余能量）在不断变化，并且可能必须在路径计算期间予以考虑。
It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2 (see [Zinky1989]). The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, a lot of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non-IP) networks.
必须注意的是，动态度量的使用并不新鲜，已经在ARPANET 2中进行了实验（参见[Zinky1989]）。动态度量的使用并非微不足道，必须非常注意动态度量的使用，因为它可能导致潜在的路由不稳定性。尽管如此，多年来在使用动态路由度量方面已经积累了很多经验，这些度量已经部署在许多（非IP）网络中。
Very careful attention must be given to the pace at which routing metrics and attributes values change in order to preserve routing stability. When using a dynamic routing metric, a RPL implementation should make use of a multi-threshold scheme rather than fine granular metric updates reflecting each individual change to avoid spurious and unnecessary routing changes.
为了保持路由的稳定性，必须非常小心地注意路由度量和属性值的变化速度。当使用动态路由度量时，RPL实现应该使用多阈值方案，而不是反映每个单独更改的细粒度度量更新，以避免虚假和不必要的路由更改。
The requirements on reporting frequency may differ among metrics; thus, different reporting rates may be used for each metric.
不同指标对报告频率的要求可能不同；因此，每个指标可能使用不同的报告率。
The set of routing metrics and constraints used by a RPL deployment is signaled along the DAG that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DODAG Information Object (DIO) message specified in [RFC6550]. RPL may be used to build DAGs with different characteristics. For example, it may be desirable to build a DAG with the goal to maximize reliability by using the link reliability metric to compute the "best" path. Another example might be to use the energy node characteristic (e.g., mains-powered versus battery-operated) as a node constraint when building the DAG so as to avoid battery-powered nodes in the DAG while optimizing the link throughput.
RPL部署使用的路由度量和约束集沿着根据目标函数（控制如何构建DAG的规则）构建的DAG发出信号，路由度量和约束在[RFC6550]中指定的DODAG信息对象（DIO）消息中公布。RPL可用于构建具有不同特征的DAG。例如，可能希望通过使用链路可靠性度量来计算“最佳”路径来构建目标为最大化可靠性的DAG。另一个示例可能是在构建DAG时使用能量节点特性（例如，电源供电与电池供电）作为节点约束，以避免DAG中的电池供电节点，同时优化链路吞吐量。
The specification of Objective Functions used to compute the DAG built by RPL is out of the scope of this document. This document defines routing metrics and constraints that are decoupled from the Objective Function. So a generic Objective Function could, for example, specify the rules to select the best parents in the DAG, the number of backup parents, etc., and it could be used with any routing metrics and/or constraints such as the ones specified in this document.
用于计算RPL构建的DAG的目标函数规范不在本文件范围内。本文档定义了与目标函数解耦的路由度量和约束。因此，通用目标函数可以指定选择DAG中最佳父级的规则、备份父级的数量等，并且可以与任何路由度量和/或约束（如本文档中指定的）一起使用。
Some metrics are either aggregated or recorded. An aggregated metric is adjusted as the DIO message travels along the DAG. For example, if the metric is the number of hops, each node updates the path cost that reflects the number of traversed hops along the DAG. By contrast, for a recorded metric, each node adds a sub-object reflecting the local valuation of the metric. For example, it might be desirable to record the link quality level along a path. In this case, each visited node adds a sub-object recording the local link quality level. In order to limit the number of sub-objects, the use of a counter may be desirable (e.g., record the number of links with a certain link quality level), thus, compressing the information to reduce the message length. Upon receiving the DIO message from a set of parents, a node might decide, according to the OF and local policy, which node to choose as a parent based on the maximum number of links with a specific link reliability level, for example.
有些指标是聚合的或记录的。当DIO消息沿DAG传输时，将调整聚合度量。例如，如果度量是跳数，则每个节点都会更新路径成本，该路径成本反映沿DAG遍历的跳数。相反，对于记录的度量，每个节点添加一个子对象，反映度量的局部值。例如，可能需要沿路径记录链路质量级别。在这种情况下，每个访问的节点添加一个子对象，记录本地链路质量级别。为了限制子对象的数量，可能需要使用计数器（例如，记录具有特定链路质量级别的链路数量），从而压缩信息以减少消息长度。当从一组父节点接收到DIO消息时，节点可以根据of和本地策略，例如基于具有特定链路可靠性级别的链路的最大数目来决定选择哪个节点作为父节点。
Note that the routing metrics and constraints specified in this document are not specific to any particular link layer. An internal API between the Medium Access Control (MAC) layer and RPL may be used to accurately reflect the metrics values of the link (wireless, wired, PLC).
请注意，本文档中指定的路由度量和约束并不特定于任何特定的链路层。媒体访问控制（MAC）层和RPL之间的内部API可用于准确反映链路（无线、有线、PLC）的度量值。
Since a set of metrics and constraints will be used for links and nodes in a LLN, it is critical to ensure the use of consistent metric calculation mechanisms for all links and nodes in the network, similar to the case of inter-domain IP routing.
由于一组度量和约束将用于LLN中的链路和节点，因此确保对网络中的所有链路和节点使用一致的度量计算机制至关重要，类似于域间IP路由的情况。
There are many different permutations of options that may be appropriate in different deployments. Implementations must clearly state which options they include, and they must state which are default and which are configurable as options within the implementation. Applicability statements will be developed within the ROLL working group to clarify which options are applicable to the specific deployment scenarios indicated by [RFC5673], [RFC5826], [RFC5548], and [RFC5867].
在不同的部署中，可能有许多不同的选项排列。实现必须清楚地说明它们包括哪些选项，并且必须说明哪些是默认选项，哪些是可配置的选项。将在滚动工作组内制定适用性声明，以澄清哪些选项适用于[RFC5673]、[RFC5826]、[RFC5548]和[RFC5867]所示的特定部署场景。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Routing metrics and constraints are carried within the DAG Metric Container object defined in [RFC6550]. Should multiple metrics and/or constraints be present in the DAG Metric Container, their use to determine the "best" path can be defined by an Objective Function.
路由度量和约束包含在[RFC6550]中定义的DAG度量容器对象中。如果DAG度量容器中存在多个度量和/或约束，则可通过目标函数定义它们用于确定“最佳”路径的用途。
The Routing Metric/Constraint objects represent a metric or a constraint of a particular type. They may appear in any order in the DAG Metric Container (specified in [RFC6550]). They have a common format consisting of one or more bytes with a common header.
路由度量/约束对象表示特定类型的度量或约束。它们可以以任何顺序出现在DAG公制容器中（在[RFC6550]中指定）。它们有一个共同的格式，由一个或多个字节和一个共同的头组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Routing Metric/Constraint Object Generic Format
图1：路由度量/约束对象通用格式
The object body carries one or more sub-objects defined later in this document. Note that an object may carry a TLV, which may itself comprise other TLVs. A TLV carried within a TLV is called a TLV in this specification.
对象体包含本文档后面定义的一个或多个子对象。注意，一个物体可能携带一个TLV，它本身可能包括其他TLV。在本规范中，TLV内携带的TLV称为TLV。
Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing Metric/Constraint Type field uniquely identifies each Routing Metric/Constraint object and is managed by IANA.
路由MC类型（路由度量/约束类型-8位）：路由度量/约束类型字段唯一标识每个路由度量/约束对象，并由IANA管理。
Length (8 bits): this field defines the length of the object body, expressed in bytes. It ranges from 0 to 255.
长度（8位）：此字段定义对象体的长度，以字节表示。范围从0到255。
Res Flags field (16 bits). The Flag field of the Routing Metric/ Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志字段（16位）。路由度量/约束对象的标志字段由IANA管理。未分配的位被视为保留位。它们在传输时必须设置为零，在接收时必须忽略。
The following bits of the Routing Metric/Constraint Flag field object are currently defined:
路由度量/约束标志字段对象的以下位当前已定义：
o 'P' flag: the P field is only used for recorded metrics. When cleared, all nodes along the path successfully recorded the corresponding metric. When set, this indicates that one or several nodes along the path could not record the metric of interest (either because of lack of knowledge or because this was prevented by policy).
o “P”标志：P字段仅用于记录的指标。清除时，路径上的所有节点都成功记录了相应的度量。设置时，这表示路径上的一个或多个节点无法记录感兴趣的度量（原因可能是缺乏知识，也可能是策略阻止了这一点）。
o 'C' flag. When set, this indicates that the Routing Metric/ Constraint object refers to a routing constraint. When cleared, the routing object refers to a routing metric.
o C旗。设置后，这表示布线度量/约束对象引用布线约束。清除此选项后，路由对象将引用路由度量。
o 'O' flag: The 'O' flag is used exclusively for routing constraints ('C' flag is set). When set, this indicates that the constraint specified in the body of the object is optional. When cleared, the constraint is mandatory. If the 'C' flag is zero, the 'O' flag MUST be set to zero on transmission and ignored on reception.
o “O”标志：“O”标志专门用于路由约束（“设置了C”标志）。设置后，这表示在对象主体中指定的约束是可选的。清除该选项后，该约束是强制性的。如果“C”标志为零，“O”标志必须在传输时设置为零，在接收时忽略。
o 'R' flag: The 'R' flag is only relevant for a routing metric (C=0) and MUST be cleared for C=1. When set, this indicates that the routing metric is recorded along the path. Conversely, when cleared, the routing metric is aggregated.
o “R”标志：“R”标志仅与路由度量（C=0）相关，必须在C=1时清除。设置后，这表示沿路径记录路由度量。相反，当清除时，将聚合路由度量。
A Field (3 bits): The A field is only relevant for metrics and is used to indicate whether the aggregated routing metric is additive, is multiplicative, reports a maximum, or reports a minimum.
A字段（3位）：A字段仅与度量相关，用于指示聚合路由度量是加法、乘法、报告最大值还是报告最小值。
o A=0: The routing metric is additive
o A=0：路由度量是加法的
o A=1: The routing metric reports a maximum
o A=1：路由度量报告最大值
o A=2: The routing metric reports a minimum
o A=2：路由度量报告最小值
o A=3: The routing metric is multiplicative
o A=3：路由度量是乘法的
The A field has no meaning when the 'C' flag is set (i.e., when the Routing Metric/Constraint object refers to a routing constraint) and is only valid when the 'R' bit is cleared. Otherwise, the A field MUST be set to 0 and MUST be ignored on receipt.
当设置“C”标志时（即，当路由度量/约束对象引用路由约束时），A字段没有意义，并且仅当清除“R”位时才有效。否则，A字段必须设置为0，并且在收到时必须忽略。
Prec field (4 bits): The Prec field indicates the precedence of this Routing Metric/Constraint object relative to other objects in the container. This is useful when a DAG Metric Container contains several Routing Metric objects. Its value ranges from 0 to 15. The value 0 means the highest precedence.
Prec字段（4位）：Prec字段指示此路由度量/约束对象相对于容器中其他对象的优先级。当DAG度量容器包含多个路由度量对象时，这非常有用。其值范围为0到15。值0表示最高优先级。
Example 1: A DAG formed by RPL where all nodes must be mains-powered and the best path is the one with lower aggregated expected transmission count (ETX). In this case, the DAG Metric Container
示例1：由RPL形成的DAG，其中所有节点必须由主电源供电，最佳路径是聚合预期传输计数（ETX）较低的路径。在本例中，DAG公制容器
carries two Routing Metric/Constraint objects: one is an ETX metric object with header (C=0, O=0, A=00, R=0) and the second one is a Node Energy constraint object with header (C=1, O=0, A=00, R=0). Note that a RPL Instance may use the metric object to report a maximum (A=1) or a minimum (A=2). If, for example, the best path is characterized by the path avoiding low quality links, then the path metric reports a maximum (A=1) (the higher the ETX, the lower the link quality): when the DIO message reporting the link quality metric (ETX) is processed by a node, each node selecting the advertising node as a parent updates the value carried in the metric object by replacing it with its local link ETX value if and only if the latter is higher. As far as the constraint is concerned, the object body will carry a Node Energy constraint object defined in Section 3.1 indicating that nodes must be mains-powered: if the constraint signaled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message.
携带两个路由度量/约束对象：一个是带有标头的ETX度量对象（C=0，O=0，A=00，R=0），另一个是带有标头的节点能量约束对象（C=1，O=0，A=00，R=0）。请注意，RPL实例可以使用metric对象报告最大值（a=1）或最小值（a=2）。例如，如果最佳路径以避免低质量链路的路径为特征，则路径度量报告最大值（a=1）（ETX越高，链路质量越低）：当节点处理报告链路质量度量（ETX）的DIO消息时，选择广告节点作为父节点的每个节点更新度量对象中携带的值，方法是将其替换为本地链接ETX值（如果且仅当后者更高）。就约束而言，对象体将携带第3.1节中定义的节点能量约束对象，指示节点必须由电源供电：如果不满足DIO消息中的约束信号，则处理DIO消息的节点不会选择广告节点作为父节点。
Example 2: A DAG formed by RPL where the link metric is the link quality level (defined in Section 4) and link quality levels must be recorded along the path. In this case, the DAG Metric Container carries a Routing Metric/Constraint object: link quality level metric (C=0, O=0, A=00, R=1) containing multiple sub-objects.
示例2：由RPL形成的DAG，其中链路度量是链路质量级别（定义见第4节），必须沿路径记录链路质量级别。在这种情况下，DAG度量容器携带包含多个子对象的路由度量/约束对象：链接质量级别度量（C=0，O=0，a=00，R=1）。
A Routing Metric/Constraint object may also include one or more additional type-length-value (TLV) encoded data sets. Each Routing Metric/Constraint TLV has the same structure:
路由度量/约束对象还可以包括一个或多个附加类型长度值（TLV）编码的数据集。每个路由度量/约束TLV具有相同的结构：
Type: 1 byte Length: 1 byte Value: variable
类型：1字节长度：1字节值：变量
A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 1 byte specifying the TLV length, and a value field. The TLV length field defines the length of the value field in bytes (from 0 to 255).
路由度量/约束TLV由类型的1个字节、指定TLV长度的1个字节和一个值字段组成。TLV长度字段以字节为单位定义值字段的长度（从0到255）。
Unrecognized TLVs MUST be silently ignored while still being propagated in DIOs generated by the receiving node.
无法识别的TLV必须在接收节点生成的DIOs中传播时被静默忽略。
IANA manages the codepoints for all TLVs carried in routing constraint/metric objects.
IANA管理路由约束/度量对象中携带的所有TLV的代码点。
IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 6.
第6节描述了路由度量/约束对象标识符代码空间的IANA管理。
Since the length of RPL options is encoded using 1 octet, they cannot exceed 255 bytes, which also applies to the DAG Metric Container. In the vast majority of cases, the advertised routing metrics and constraints will not require that much space. However, there might be circumstances where larger space is required, should, for example, a set of routing metrics be recorded along a long path. In this case, in order to avoid overflow, as specified in [RFC6550], routing metrics will be carried using multiple DAG Metric Container objects.
由于RPL选项的长度是使用1个八位字节编码的，因此它们不能超过255个字节，这也适用于DAG度量容器。在绝大多数情况下，公布的路由度量和约束将不需要那么多空间。然而，在某些情况下，可能需要更大的空间，例如，应沿长路径记录一组路由度量。在这种情况下，为了避免溢出，如[RFC6550]中所述，将使用多个DAG度量容器对象来携带路由度量。
In the rest of this document, this use of multiple DAG Metric Container objects will be considered as if they were actually just one long DAG Metric Container object.
在本文档的其余部分中，使用多个DAG公制容器对象将被视为它们实际上只是一个长DAG公制容器对象。
When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitly derived from the metric type. For example, lower is better for Hop Count, Link Latency, and ETX. Conversely, for Node Energy or Throughput, higher is better.
当DAG度量容器包含单个聚合度量（标量值）时，选择最佳路径的顺序关系将隐式地从度量类型派生。例如，跳数、链路延迟和ETX越低越好。相反，对于节点能量或吞吐量，越高越好。
An example of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E_E field) defined in Section 3.2 is aggregated along paths with an explicit min function (A field), and the best path is selected through an implied Max function because the metric is Energy.
使用这种单一聚合度量的一个示例是优化节点能量的路由。第3.2节中定义的节点能量度量（E_E场）通过显式最小函数（A场）沿路径聚合，最佳路径通过隐式最大函数选择，因为该度量是能量。
When the DAG Metric Container contains several aggregated metrics, they are to be used as tiebreakers according to their precedence defined by their Prec field values.
当DAG度量容器包含多个聚合度量时，将根据其Prec字段值定义的优先级将它们用作分段符。
An example of such use of multiple aggregated metrics is the following: Hop Count as the primary criterion, Link Quality Level (LQL) as the secondary criterion, and Node Energy as the ultimate tiebreaker. In such a case, the Hop Count, LQL, and Node Energy metric objects' Prec fields should bear strictly increasing values such as 0, 1, and 2, respectively.
使用多个聚合度量的一个示例如下：跳数作为主要标准，链路质量级别（LQL）作为次要标准，节点能量作为最终的分层断路器。在这种情况下，跃点计数、LQL和节点能量度量对象的Prec字段应分别具有严格递增的值，如0、1和2。
If several aggregated metrics happen to bear the same Prec value, the behavior is implementation dependent.
如果多个聚合度量恰好具有相同的Prec值，则该行为取决于实现。
Sections 3 and 4 specify several link and node metric/constraint objects. In some cases, it is stated that there must not be more than one object of a specific type. In that case, if a RPL implementation receives more than one object of that type, the second object MUST silently be ignored.
第3节和第4节指定了几个链接和节点度量/约束对象。在某些情况下，规定特定类型的对象不得超过一个。在这种情况下，如果RPL实现接收到多个该类型的对象，则第二个对象必须以静默方式忽略。
In the presence of a constraint, a node MUST include a metric of the same type. That metric is used to check whether or not the constraint is met. In all cases, a node MUST not change the content of the constraint.
在存在约束的情况下，节点必须包含相同类型的度量。该度量用于检查是否满足约束。在所有情况下，节点都不得更改约束的内容。
The Node State and Attribute (NSA) object is used to provide information on node characteristics.
节点状态和属性（NSA）对象用于提供有关节点特征的信息。
The NSA object MAY be present in the DAG Metric Container. There MUST NOT be more than one NSA object as a constraint per DAG Metric Container, and there MUST NOT be more than one NSA object as a metric per DAG Metric Container.
NSA对象可能存在于DAG度量容器中。每个DAG度量容器不得有多个NSA对象作为约束，每个DAG度量容器不得有多个NSA对象作为度量。
The NSA object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined.
NSA对象还可以包含一组用于传递各种节点特征的tlv。当前未定义TLV。
The NSA Routing Metric/Constraint Type has been assigned value 1 by IANA.
IANA为NSA路由度量/约束类型分配了值1。
The format of the NSA object body is as follows:
NSA对象体的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 2: NSA Object Body Format
图2:NSA对象体格式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志（8位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
Flags field (8 bits). The following two bits of the NSA object are currently defined:
标志字段（8位）。NSA对象的以下两位当前已定义：
o 'A' flag: data Aggregation Attribute. Data aggregation is listed as a requirement in Section 6.2 of [RFC5548]. Some applications may make use of the aggregation node attribute in their routing
o “A”标志：数据聚合属性。[RFC5548]第6.2节将数据聚合列为一项要求。某些应用程序可能在其路由中使用聚合节点属性
decision so as to minimize the amount of traffic on the network, thus, potentially increasing its lifetime in battery operated environments. Applications where highly directional data flow is expected on a regular basis may take advantage of data aggregation supported routing. When set, this indicates that the node can act as a traffic aggregator. Further documents MAY define optional TLVs to describe the node traffic aggregator functionality.
决策，以尽量减少网络上的通信量，从而潜在地延长其在电池供电环境中的使用寿命。在应用程序中，预期定期有高度定向的数据流，可以利用数据聚合支持的路由。设置后，这表示节点可以充当流量聚合器。进一步的文档可以定义可选的TLV来描述节点流量聚合器功能。
o 'O' flag: node workload may be hard to determine and express in some scalar form. However, node workload could be a useful metric to consider during path calculation, in particular when queuing delays must be minimized for highly sensitive traffic considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory, or any other node related conditions. Using a simple 1-bit flag to characterize the node workload provides a sufficient level of granularity, similar to the "overload" bit used in routing protocols such as IS-IS. Algorithms used to set the overload bit and to compute paths to potentially avoid nodes with their overload bit set are outside the scope of this document, but it is RECOMMENDED to avoid frequent changes of this bit to avoid routing oscillations. When set, this indicates that the node is overloaded and may not be able to process traffic.
o “O”标志：节点工作负载可能很难确定并以某种标量形式表示。然而，节点工作量可能是一个有用的度量在路径计算过程中考虑，特别是当考虑到介质访问控制（MAC）层延迟时，对于高度敏感的业务必须最小化排队延迟。可以在CPU过载、内存不足或任何其他与节点相关的情况下设置节点工作负载。使用简单的1位标志来描述节点工作负载提供了足够的粒度级别，类似于IS-IS等路由协议中使用的“过载”位。用于设置过载位和计算路径以潜在避免设置过载位的节点的算法不在本文档的范围内，但建议避免频繁更改此位以避免路由振荡。设置后，这表示节点过载，可能无法处理流量。
The unspecified flag fields MUST be set to zero on transmission and MUST be ignored on receipt.
未指定的标志字段在传输时必须设置为零，在接收时必须忽略。
The Flags field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved.
NSA路由度量/约束对象的标志字段由IANA管理。未分配的位被视为保留位。
It may sometimes be desirable to avoid selecting a node with low residual energy as a router; thus, the support for constraint-based routing is needed. In such cases, the routing protocol engine may compute a longer path (constraint based) for some traffic in order to increase the network life duration.
有时可能希望避免选择具有低剩余能量的节点作为路由器；因此，需要支持基于约束的路由。在这种情况下，路由协议引擎可以为一些业务计算更长的路径（基于约束），以增加网络寿命。
Power and energy are clearly critical resources in most LLNs. As yet, there is no simple abstraction that adequately covers the broad range of power sources and energy storage devices used in existing LLN nodes. These include mains-powered, primary batteries, energy scavengers, and a variety of secondary storage mechanisms. Scavengers may provide a reliable low level of power, such as might be available from a 4-20 mA loop; a reliable but periodic stream of power, such as provided by a well-positioned solar cell; or unpredictable power, such as might be provided by a vibrational energy scavenger on an intermittently powered pump. Routes that are
电力和能源显然是大多数LLN的关键资源。到目前为止，还没有简单的抽象能够充分涵盖现有LLN节点中使用的各种电源和能量存储设备。其中包括电源供电、原电池、能量清除器和各种辅助存储机制。清除剂可提供可靠的低功率水平，例如可从4-20 mA回路获得；可靠但周期性的功率流，如由位置良好的太阳能电池提供的功率流；或不可预测的功率，例如可能由间歇动力泵上的振动能量清除器提供的功率。是的路线
viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a network.
当太阳照耀时，可能会在夜间消失。打开泵可能会连接网络中先前断开的两个部分。
Storage systems, such as rechargeable batteries, often suffer substantial degradation if regularly used to full discharge, leading to different residual energy numbers for regular versus emergency operation. A route for emergency traffic may have a different optimum than one for regular reporting.
存储系统，如可充电电池，如果经常用于完全放电，通常会发生严重退化，导致常规操作和紧急操作的剩余能量值不同。紧急交通路线可能有不同于常规报告路线的最佳路线。
Batteries used in LLNs often degrade substantially if their average current consumption exceeds a small fraction of the peak current that they can deliver. It is not uncommon for self-supporting nodes to have a combination of primary storage, energy scavenging, and secondary storage, leading to three different values for acceptable average current depending on the time frame being considered, e.g., milliseconds, seconds, and hours/years.
如果LLN中使用的电池的平均电流消耗超过其所能提供的峰值电流的一小部分，则电池通常会严重退化。自支撑节点具有主存储、能量清除和辅助存储的组合并不少见，这导致可接受平均电流的三个不同值取决于所考虑的时间范围，例如毫秒、秒和小时/年。
Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets, and lifetime estimates have no value without some higher-level constraint on the lifetime required of a device. In some cases, the path that exhausts the battery of a node on the bed table in a month may be preferable to a route that reduces the lifetime of a node in the wall to a decade.
如果不知道发送和接收数据包的能量成本，原始功率和能量值是没有意义的，如果对设备所需的寿命没有更高级别的约束，寿命估计也没有价值。在某些情况下，在一个月内耗尽床桌上节点电池的路径可能比将墙中节点的寿命缩短为十年的路径更可取。
Given the complexity of trying to address such a broad collection of constraints, this document defines two levels of fidelity in the solution.
考虑到试图解决如此广泛的约束集合的复杂性，本文档定义了解决方案中的两个保真度级别。
The simplest solution relies on a 2-bit field encoding three types of power sources: "powered", "battery", and "scavenger". This simple approach may be sufficient for many applications.
最简单的解决方案依赖于2位字段编码三种类型的电源：“有电”、“电池”和“清道夫”。对于许多应用来说，这种简单的方法可能就足够了。
The mid-complexity solution is a single parameter that can be used to encode the energetic happiness of both battery-powered and scavenging nodes. For scavenging nodes, the 8-bit quantity is the power provided by the scavenger divided by the power consumed by the application, E_E=P_in/P_out, in units of percent. Nodes that are scavenging more power than they are consuming will register above 100. A good time period for averaging power in this calculation may be related to the discharge time of the energy storage device on the node, but specifying this is out of the scope of this document. For battery-powered devices, E_E is the current expected lifetime divided by the desired minimum lifetime, in units of percent. The estimation of remaining battery energy and actual power consumption can be difficult, and the specifics of this calculation are out of scope of this document, but two examples are presented. If the node can measure its average power consumption, then E_E can be calculated as
中等复杂度解决方案是一个单一参数，可用于编码电池供电节点和清除节点的能量快乐。对于清除节点，8位数量是清除程序提供的功率除以应用程序消耗的功率，E_E=P_in/P_out，以百分比为单位。清除的电量大于消耗的电量的节点将注册超过100。此计算中平均功率的良好时间段可能与节点上能量存储设备的放电时间有关，但具体说明不在本文件范围内。对于电池供电的设备，E_E是当前预期寿命除以期望的最小寿命，单位为百分比。估计剩余电池能量和实际功耗可能很困难，此计算的具体内容超出了本文件的范围，但给出了两个示例。如果节点可以测量其平均功耗，则E_E可以计算为
the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power, E_E=P_max/P_now. Alternatively, if the energy in the battery E_bat can be estimated, and the total elapsed lifetime, t, is available, then E_E can be calculated as the total stored energy remaining versus the target energy remaining: E_E= E_bat / [E_0 (T-t)/T].
期望最大功率（初始能量E_0除以期望寿命T）与实际功率之比，E_E=P_max/P_now。或者，如果可以估计电池E_-bat中的能量，并且总经过寿命t可用，则E_-E可以计算为总剩余存储能量与目标剩余能量：E_E=E_-bat/[E_0（t-t）/t]。
An example of an optimized route is max(min(E_E)) for all battery-operated nodes along the route, subject to the constraint that E_E>=100 for all scavengers along the route.
优化路由的一个示例是沿路由的所有电池操作节点的最大值（最小值（E_E）），受沿路由的所有清道夫的E_E>=100的约束。
Note that the estimated percentage of remaining energy indicated in the E_E field may not be useful in the presence of nodes powered by battery or energy scavengers when the amount of energy accumulated by the device significantly differ. Indeed, X% of remaining energy on a node that can store a large amount of energy cannot be easily compared to the same percentage of remaining energy on a node powered by a tiny source of energy. That being said, in networks where nodes have similar energy storage, such a percentage of remaining energy is useful.
注意，当设备累积的能量量显著不同时，在存在由电池或能量清除器供电的节点的情况下，E_E字段中指示的剩余能量的估计百分比可能不有用。事实上，一个能够存储大量能量的节点上剩余能量的X%很难与一个由微小能量源供电的节点上剩余能量的相同百分比相比较。也就是说，在节点具有类似能量存储的网络中，剩余能量的百分比是有用的。
The Node Energy (NE) object is used to provide information related to node energy and may be used as a metric or as constraint.
节点能量（NE）对象用于提供与节点能量相关的信息，并且可以用作度量或约束。
The NE object MAY be present in the DAG Metric Container. There MUST NOT be more than one NE object as a constraint per DAG Metric Container, and there MUST NOT be more than one NE object as a metric per DAG Metric Container.
NE对象可能存在于DAG公制容器中。每个DAG度量容器不得有多个NE对象作为约束，每个DAG度量容器不得有多个NE对象作为度量。
The NE object Type has been assigned value 2 by IANA.
IANA为NE对象类型分配了值2。
The format of the NE object body is as follows:
网元对象体的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 3: NE Sub-Object Format
图3:NE子对象格式
The format of the NE sub-object body is as follows:
网元子对象体的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E| E_E | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E| E_E | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 4: NE Sub-Object Format
图4:NE子对象格式
The NE sub-object may also contain a set of TLVs used to convey various nodes' characteristics.
NE子对象还可以包含用于传递各种节点的特征的一组tlv。
Flags field (8 bits). The following flags are currently defined:
标志字段（8位）。当前定义了以下标志：
o I (Included): the 'I' bit is only relevant when the node type is used as a constraint. For example, the path must only traverse mains-powered nodes. Conversely, battery-operated nodes must be excluded. The 'I' bit is used to stipulate inclusion versus exclusion. When set, this indicates that nodes of the type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded.
o I（包括）：仅当节点类型用作约束时，“I”位才相关。例如，路径必须仅穿过电源供电的节点。相反，必须排除电池供电的节点。“I”位用于规定包含与排除。设置时，这表示必须包括节点类型字段中指定类型的节点。相反，如果清除此选项，则表示必须排除节点类型字段中指定类型的节点。
o T (node Type): 2-bit field indicating the node type. T=0 designates a mains-powered node, T=1 a battery-powered node, and T=2 a node powered by an energy scavenger.
o T（节点类型）：指示节点类型的2位字段。T=0表示由电源供电的节点，T=1表示由电池供电的节点，T=2表示由能量清除器供电的节点。
o E (Estimation): when the 'E' bit is set for a metric, the estimated percentage of remaining energy on the node is indicated in the E_E 8-bit field. When cleared, the estimated percentage of remaining energy is not provided. When the 'E' bit is set for a constraint, the E_E field defines a threshold for the inclusion/ exclusion: if an inclusion, nodes with values higher than the threshold are to be included; if an exclusion, nodes with values lower than the threshold are to be excluded.
o E（估计）：当为度量设置“E”位时，节点上剩余能量的估计百分比在E_E 8位字段中指示。清除后，不提供剩余能量的估计百分比。当为约束设置“E”位时，E_E字段定义包含/排除的阈值：如果包含，则包含值高于阈值的节点；如果排除，将排除值低于阈值的节点。
E_E (Estimated-Energy): 8-bit unsigned integer field indicating an estimated percentage of remaining energy. The E_E field is only relevant when the 'E' flag is set, and it MUST be set to 0 when the 'E' flag is cleared.
E_E（估计能量）：8位无符号整数字段，表示剩余能量的估计百分比。E_E字段仅在设置了“E”标志时相关，并且在清除“E”标志时必须设置为0。
If the NE object comprises several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the 'I' bit of the first sub-object: full if that 'I' bit is an exclusion, empty if that 'I' bit is an inclusion.
如果NE对象在用作约束时包含多个子对象，则在按顺序分析子对象时，每个子对象添加或减去节点子集。初始集（满或空）由第一个子对象的“I”位定义：如果“I”位是排除项，则为满；如果“I”位是包含项，则为空。
No TLV is currently defined.
当前未定义TLV。
Future documents may define more complex solutions involving TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime.
未来的文档可能会定义更复杂的解决方案，涉及表示节点的能量存储、消耗和发电能力以及所需寿命的TLV参数。
The Hop Count (HP) object is used to report the number of traversed nodes along the path.
跃点计数（HP）对象用于报告沿路径遍历的节点数。
The HP object MAY be present in the DAG Metric Container. There MUST NOT be more than one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container.
HP对象可能存在于DAG公制容器中。每个DAG度量容器不得有多个HP对象作为约束，每个DAG度量容器不得有多个HP对象作为度量。
The HP object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined.
HP对象还可以包含一组用于传递各种节点特征的TLV。当前未定义TLV。
The HP routing metric object Type has been assigned value 3 by IANA.
IANA已为HP路由度量对象类型分配了值3。
The format of the Hop Count object body is as follows:
跃点计数对象体的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 5: Hop Count Object Body Format
图5：跃点计数对象体格式
Res flags (4 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志（4位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
No Flag is currently defined. Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
当前未定义任何标志。未分配的位被认为是保留的。它们在传输时必须设置为零，在接收时必须忽略。
The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field.
HP对象可以用作约束或度量。当用作约束时，DAG根表示路径可以通过的最大跃点数。当达到该数目时，没有其他节点可以加入该路径。当用作度量时，每个访问的节点只需增加跃点计数字段。
Note that the first node along a path inserting a Hop Count metric object MUST set the Hop Count field value to 1.
请注意，插入跃点计数度量对象的路径上的第一个节点必须将跃点计数字段值设置为1。
Many LLNs support a wide range of throughputs. For some links, this may be due to variable coding. For the deeply duty-cycled links found in many LLNs, the variability comes as a result of trading power consumption for bit rate. There are several MAC layer protocols that allow for the effective bit rate of a link to vary over more than three orders of magnitude with a corresponding change in power consumption. For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput.
许多LLN支持广泛的吞吐量。对于某些链接，这可能是由于变量编码。对于在许多LLN中发现的深度占空比链路，这种可变性是以功耗换取比特率的结果。有几种MAC层协议允许链路的有效比特率随功耗的相应变化而变化超过三个数量级。为了高效运行，除了当前可用的吞吐量之外，节点还需要报告其链路可以处理的吞吐量范围。
The Throughput object MAY be present in the DAG Metric Container. There MUST NOT be more than one Throughput object as a constraint per DAG Metric Container, and there MUST NOT be more than one Throughput object as a metric per DAG Metric Container.
吞吐量对象可能存在于DAG度量容器中。每个DAG度量容器不得有多个吞吐量对象作为约束，每个DAG度量容器不得有多个吞吐量对象作为度量。
The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub-object MUST be the most recently estimated actual throughput. The actual estimation of the throughput is outside the scope of this document.
吞吐量对象由吞吐量子对象组成，并且必须至少包含一个吞吐量子对象。第一个吞吐量子对象必须是最近估计的实际吞吐量。吞吐量的实际估计超出了本文件的范围。
Each Throughput sub-object has a fixed length of 4 bytes.
每个吞吐量子对象的固定长度为4字节。
The Throughput object does not contain any additional TLVs.
吞吐量对象不包含任何其他TLV。
The Throughput object Type has been assigned value 4 by IANA.
吞吐量对象类型已由IANA分配值4。
The format of the Throughput object body is as follows:
吞吐量对象体的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Throughput Object Body Format
图6：吞吐量对象体格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Throughput Sub-Object Format
图7：吞吐量子对象格式
Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second.
吞吐量：32位。吞吐量以32位无符号整数格式编码，以字节/秒表示。
Similar to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in power consumption. Some LLN MAC link layers will allow the latency to be adjusted globally on the subnet, on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link.
与吞吐量类似，许多LLN MAC子层的延迟可以在许多数量级上变化，同样伴随着功耗的相应变化。某些LLN MAC链路层将允许在子网上逐个链路地全局调整延迟，或者根本不调整延迟。有些人会坚持认为它是固定的一个给定的链接，但允许它是可变的链接。
The Latency object MAY be present in the DAG Metric Container. There MUST NOT be more than one Latency object as a constraint per DAG Metric Container, and there MUST NOT be more than one Latency object as a metric per DAG Metric Container.
延迟对象可能存在于DAG度量容器中。每个DAG度量容器不得有多个延迟对象作为约束，每个DAG度量容器不得有多个延迟对象作为度量。
The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes.
延迟对象由延迟子对象组成，并且必须至少包含一个延迟子对象。每个延迟子对象的固定长度为4字节。
The Latency object does not contain any additional TLVs.
延迟对象不包含任何其他TLV。
The Latency object Type has been assigned value 5 by IANA.
IANA为延迟对象类型分配了值5。
The Latency object is a metric or constraint.
延迟对象是一个度量或约束。
The format of the Latency object body is as follows:
延迟对象主体的格式如下所示：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Latency Object Body Format
图8：延迟对象体格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Latency Sub-Object Format
图9：延迟子对象格式
Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds.
延迟：32位。延迟以32位无符号整数格式编码，以微秒表示。
The Latency object may be used as a constraint or a path metric. For example, one may want the latency not to exceed some value. In this case, the Latency object common header indicates that the provided value relates to a constraint. In another example, the Latency object may be used as an aggregated additive metric where the value is updated along the path to reflect the path latency.
延迟对象可用作约束或路径度量。例如，您可能希望延迟不超过某个值。在这种情况下，延迟对象公共标头指示提供的值与约束相关。在另一示例中，延迟对象可用作聚合的加法度量，其中该值沿路径更新以反映路径延迟。
In LLNs, link reliability could be degraded for a number of reasons: signal attenuation, interferences of various forms, etc. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rates can generally be measured directly, and other metrics (e.g., bit error rate, mean time between failures) are typically derived from that. Note that such variability is not specific to wireless link but also applies to PLC links.
在LLN中，链路可靠性可能因多种原因而降低：信号衰减、各种形式的干扰等。时间尺度从毫秒到几天不等，通常是周期性的，并与人类活动有关。数据包错误率通常可以直接测量，其他指标（例如，误码率、平均故障间隔时间）通常是从中得出的。注意，这种可变性并不特定于无线链路，但也适用于PLC链路。
A change in link quality can affect network connectivity; thus, link quality may be taken into account as a critical routing metric.
链路质量的变化会影响网络连通性；因此，可以将链路质量考虑为关键路由度量。
A number of link reliability metrics could be defined reflecting several reliability aspects. Two link reliability metrics are defined in this document: the Link Quality Level (LQL) and the ETX Metric.
可以定义若干链路可靠性度量，以反映多个可靠性方面。本文件定义了两个链路可靠性指标：链路质量水平（LQL）和ETX指标。
Note that a RPL deployment MAY use the LQL, the ETX, or both.
请注意，RPL部署可以使用LQL、ETX或两者。
The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7, where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document.
链路质量等级（LQL）对象用于使用离散值（从0到7）量化链路可靠性，其中0表示链路质量等级未知，1报告最高链路质量等级。用于计算LQL的机制和算法是特定于实现的，不在本文档的范围内。
The LQL can be used either as a metric or a constraint. When used as a metric, the LQL metric can only be recorded. For example, the DAG Metric object may request all traversed nodes to record the LQL of their incoming link into the LQL object. Each node can then use the LQL record to select its parent based on some user defined rules (e.g., something like "select the path with most links reporting a LQL value of 3 or less").
LQL可以用作度量或约束。当用作度量时，只能记录LQL度量。例如，DAG度量对象可以请求所有被遍历的节点将其传入链路的LQL记录到LQL对象中。然后，每个节点都可以使用LQL记录根据一些用户定义的规则选择其父节点（例如，类似于“选择大多数链接报告LQL值小于等于3的路径”）。
Counters are used to compress the information: for each encountered LQL value, only the number of matching links is reported.
计数器用于压缩信息：对于遇到的每个LQL值，只报告匹配链接的数量。
The LQL object MAY be present in the DAG Metric Container. There MUST NOT be more than one LQL object as a constraint per DAG Metric Container, and there MUST NOT be more than one LQL object as a metric per DAG Metric Container.
LQL对象可能存在于DAG度量容器中。每个DAG度量容器不得有多个LQL对象作为约束，每个DAG度量容器不得有多个LQL对象作为度量。
The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL.
LQL对象必须包含一个或多个子对象，用于报告链接数量及其LQL。
The LQL object Type has been assigned value 6 by IANA.
IANA为LQL对象类型指定了值6。
The format of the LQL object body is as follows:
LQL对象体的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 10: LQL Object Body Format
图10:LQL对象体格式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志（8位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object.
记录LQL度量时，LQL对象主体包含一个或多个LQL类型1子对象。
The format of the LQL Type 1 sub-object is as follows
LQL类型1子对象的格式如下
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+
Figure 11: LQL Type 1 Sub-Object Format
图11:LQL类型1子对象格式
Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality.
Val:LQL值从0到7，其中0表示未确定，1表示最高链接质量。
Counter: number of links with that value.
计数器：具有该值的链接数。
The ETX metric is the number of transmissions a node expects to make to a destination in order to successfully deliver a packet. In contrast with the LQL routing metric, the ETX provides a discrete value (which may not be an integer) computed according to a specific formula: for example, an implementation may use the following formula: ETX= 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value.
ETX度量是节点为成功传递数据包而期望向目的地进行的传输次数。与LQL路由度量相反，ETX提供根据特定公式计算的离散值（可能不是整数）：例如，实现可以使用以下公式：ETX=1/（Df*Dr）其中Df是邻居接收到分组的测量概率，Dr是成功接收到确认分组的测量概率。本文件不要求使用特定公式计算ETX值。
The ETX object MAY be present in the DAG Metric Container. There MUST NOT be more than one ETX object as a constraint per DAG Metric Container, and there MUST NOT be more than one ETX object as a metric per DAG Metric Container.
ETX对象可能存在于DAG公制容器中。每个DAG度量容器不得有多个ETX对象作为约束，每个DAG度量容器不得有多个ETX对象作为度量。
The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 16 bits.
ETX对象由ETX子对象组成，必须至少包含一个ETX子对象。每个ETX子对象具有16位的固定长度。
The ETX object does not contain any additional TLVs.
ETX对象不包含任何其他TLV。
The ETX object Type has been assigned value 7 by IANA.
IANA为ETX对象类型分配了值7。
The format of the ETX object body is as follows:
ETX对象体的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ETX Object Body Format
图12:ETX对象体格式
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: ETX Sub-Object Format
图13:ETX子对象格式
ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX = 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum, which is 65535.
ETX:16位。ETX*128使用16位无符号整数格式编码，四舍五入到最接近的整数。例如，如果ETX=3.569，对象值将为457。如果ETX>511.9921875，对象值将是最大值，即65535。
The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some specified value. In this case, the ETX object common header indicates that the value relates to a constraint. In another example, the ETX object may be used as an aggregated additive metric where the value is updated along the path to reflect the path quality: when a node receives the aggregated additive ETX value of the path (cumulative path ETX calculated as the sum of the link ETX of all of the traversed links from the advertising node to the DAG root), if it selects that node as its preferred parent, the node updates the path ETX by adding the ETX of the local link between itself and the preferred parent to the received path cost (path ETX) before potentially advertising itself the new path ETX.
ETX对象可用作约束或路径度量。例如，可能要求ETX不得超过某些规定值。在这种情况下，ETX对象公共标头指示该值与约束相关。在另一示例中，ETX对象可用作聚合相加度量，其中该值沿路径更新以反映路径质量：当节点接收到路径的聚合相加ETX值时（累积路径ETX计算为从广告节点到DAG根的所有遍历链路的链路ETX之和），如果选择该节点作为其首选父节点，则该节点通过将其自身和首选父节点之间的本地链路的ETX添加到接收到的路径成本（路径ETX）中来更新路径ETX，然后再潜在地为其自身发布新路径ETX。
The Link Color (LC) object is an administrative 10-bit link constraint (which may be either static or dynamically adjusted) used to avoid or attract specific links for specific traffic types.
链接颜色（LC）对象是一个管理10位链接约束（可以是静态或动态调整的），用于避免或吸引特定流量类型的特定链接。
The LC object can be used either as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. A color is defined as a specific set of bit values: in other words, that 10-bit field is a flag field, and not a scalar value. Each node can then use the LC to select the parent based on user defined rules (e.g., "select the path with the maximum number of links having their first bit set 1 (e.g., encrypted links)"). The LC object may also be used as a constraint.
LC对象可以用作度量或约束。当用作度量时，只能记录LC度量。例如，DAG可能需要记录所有遍历链接的链接颜色。颜色定义为一组特定的位值：换句话说，10位字段是标志字段，而不是标量值。然后，每个节点可以使用LC根据用户定义的规则选择父节点（例如，“选择最大链接数的路径，其第一位设置为1（例如，加密链接）”）。LC对象也可用作约束。
When used as a recorded metric, a counter is used to compress the information where the number of links for each Link Color is reported.
当用作记录的度量时，计数器用于压缩报告每个链接颜色的链接数的信息。
The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST NOT be more than one LC object as a constraint per DAG Metric Container, and there MUST NOT be more than one LC object as a metric per DAG Metric Container.
链接颜色（LC）对象可能存在于DAG公制容器中。每个DAG度量容器不得有多个LC对象作为约束，每个DAG度量容器不得有多个LC对象作为度量。
There MUST be a at least one LC sub-object per LC object.
每个LC对象必须至少有一个LC子对象。
The LC object does not contain any additional TLVs.
LC对象不包含任何其他TLV。
The LC object Type has been assigned value 8 by IANA.
IANA已为LC对象类型分配了值8。
The format of the LC object body is as follows:
LC对象体的格式如下所示：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 14: LC Object Format
图14:LC对象格式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res标志（8位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects.
当LC对象用作记录的度量时，LC对象主体包括一个或多个LC类型1子对象。
The format of the LC Type 1 sub-object body is as follows:
LC类型1子对象主体的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LC Type 1 Sub-Object Format
图15:LC类型1子对象格式
When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects.
当LC对象用作约束时，LC对象主体包含一个或多个LC类型2子对象。
The format of the LC Type 2 sub-object body is as follows:
LC类型2子对象主体的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LC Type 2 Sub-Object Format
图16:LC类型2子对象格式
Reserved (5 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（5位）：保留字段。此字段在传输时必须设置为零，在接收时必须忽略。
'I' Bit: The 'I' bit is only relevant when the Link Color is used as a constraint. When set, this indicates that links with the specified color must be included. When cleared, this indicates that links with the specified color must be excluded.
“I”位：“I”位仅在链接颜色用作约束时才相关。设置后，这表示必须包含具有指定颜色的链接。清除时，这表示必须排除具有指定颜色的链接。
It is left to the implementer to define the meaning of each bit of the 10-bit Link Color Flag field.
由实现者定义10位链接颜色标志字段的每一位的含义。
The link color may be used as a constraint or a metric.
链接颜色可用作约束或度量。
o When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path.
o 当用作约束时，LC对象可插入DAG度量容器中，以指示具有特定颜色的链接应包括在计算路径中或从计算路径中排除。
o When used as recorded metric, each node along the path may insert an LC object in the DAG Metric Container to report the color of the local link. If there is already an LC object reporting a similar color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field.
o 当用作记录的度量时，路径上的每个节点都可以在DAG度量容器中插入LC对象，以报告本地链接的颜色。如果已经有一个LC对象报告类似的颜色，则节点不得添加另一个相同的LC子对象，并且必须增加计数器字段。
As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, thus, implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales. RPL controls the reporting rate.
正如已经指出的，在LLN的许多情况下，动态计算的度量是最重要的。这主要是因为各种度量经常发生变化，因此，这意味着需要调整路由决策。也就是说，必须注意网络中报告变化的速度。属性将根据其自身的时间刻度进行更改。RPL控制报告率。
To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics is out of the scope of this document, it is RECOMMENDED to carefully design the route optimization algorithm to avoid too frequent computation of new routes upon metric values changes.
为了最小化度量更新，可以使用多阈值算法来确定何时应该发送更新。如果可行，应使用低通滤波和/或滞后，以避免这些值的快速波动。最后，尽管使用动态度量的路径计算算法的规范不在本文档的范围内，但建议仔细设计路由优化算法，以避免在度量值发生变化时计算新路由过于频繁。
Controlled adaptation of the routing metrics and rate at which paths are computed are critical to avoid undesirable routing instabilities resulting in increased latencies and packet loss because of temporary micro-loops. Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus, potentially impacting its scalability.
路由度量和路径计算速率的受控自适应对于避免因临时微环而导致延迟增加和数据包丢失的不良路由不稳定性至关重要。此外，过度的路由更改将对网络中的流量和功耗产生不利影响，从而可能影响其可扩展性。
IANA has established a new top-level registry, called "RPL Routing Metric/Constraint", to contain all Routing Metric/Constraint objects codepoints and sub-registries.
IANA建立了一个新的顶级注册表，称为“RPL路由度量/约束”，以包含所有路由度量/约束对象代码点和子注册表。
The allocation policy for each new registry is by IETF review: new values are assigned through the IETF review process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant working group if one exists).
每个新注册表的分配策略由IETF审查：通过IETF审查过程分配新值（见[RFC5226]）。具体而言，新任务通过IESG批准的RFC完成。通常情况下，IESG将寻求适当人员（例如，相关工作组，如果存在）对预期任务的投入。
New bit numbers may be allocated only by an IETF Review action. Each bit should be tracked with the following qualities:
新的位号只能由IETF审查行动分配。应按照以下质量跟踪每个位：
o Bit number
o 位号
o Capability Description
o 能力描述
o Defining RFC
o 定义RFC
IANA has created a sub-registry, called "Routing Metric/Constraint Type", for Routing Metric/Constraint object types, which range from 0 to 255. Value 0 is unassigned.
IANA为路由度量/约束对象类型创建了一个称为“路由度量/约束类型”的子注册表，其范围从0到255。值0未赋值。
Value Meaning Reference 1 Node State and Attribute This document 2 Node Energy This document 3 Hop Count This document 4 Link Throughput This document 5 Link Latency This document 6 Link Quality Level This document 7 Link ETX This document 8 Link Color This document
值含义参考1节点状态和属性此文档2节点能量此文档3跃点计数此文档4链路吞吐量此文档5链路延迟此文档6链路质量级别此文档7链路ETX此文档8链路颜色此文档
IANA has created a sub-registry, called "Routing Metric/Constraint TLVs", used for all TLVs carried within Routing Metric/Constraint objects. The Type field is an 8-bit field whose value is comprised between 0 and 255. Value 0 is unassigned. The Length field is an 8-bit field whose value ranges from 0 to 255. The Value field has value ranges depending on the Type; therefore, they are not defined here, since no Type is registered at this time.
IANA创建了一个名为“路由度量/约束TLV”的子注册表，用于路由度量/约束对象中携带的所有TLV。类型字段是一个8位字段，其值介于0和255之间。值0未赋值。长度字段是一个8位字段，其值范围为0到255。值字段根据类型具有值范围；因此，这里没有定义它们，因为此时没有注册类型。
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header Flag field", to manage the 9-bit Flag field of the Routing Metric/Constraint common header.
IANA创建了一个子注册表，称为“路由度量/约束公共头标志字段”，用于管理路由度量/约束公共头的9位标志字段。
Several bits are defined for the Routing Metric/Constraint common header Flag field in this document. The following values have been assigned:
本文档中为路由度量/约束公共头标志字段定义了若干位。已指定以下值：
Codespace of the Flag field (Routing Metric/Constraint common header)
标志字段的代码空间（路由度量/约束公共头）
Bit Description Reference
位描述参考
8 Recorded/Aggregated This document 7 Optional Constraint This document 6 Constraint/Metric This document 5 P (Partial) This document
8记录/汇总本文件7可选约束本文件6约束/度量本文件5 P（部分）本文件
Bits 0-4 are currently reserved.
位0-4当前保留。
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header A field", to manage the codespace of the A field of the Routing Metric/Constraint common header.
IANA创建了一个子注册表，称为“路由度量/约束公共头a字段”，用于管理路由度量/约束公共头a字段的代码空间。
The A field is 3 bits in length, and it has values ranging from 0 to 7.
A字段的长度为3位，其值范围为0到7。
Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference
字段的代码空间（路由度量/约束公共头）值表示引用
0 Routing metric is additive This document 1 Routing metric reports a maximum This document 2 Routing metric reports a minimum This document 3 Routing metric is multiplicative This document
0路由度量为加法此文档1路由度量报告最大值此文档2路由度量报告最小值此文档3路由度量为乘法此文档
IANA has created a sub-registry, called "NSA Object Flag field", to manage the codespace of the 8-bit Flag field of the NSA object.
IANA创建了一个名为“NSA对象标志字段”的子注册表，用于管理NSA对象的8位标志字段的代码空间。
Several bits are defined for the NSA Object Flag field in this document. The following values have been assigned:
本文档中为NSA对象标志字段定义了若干位。已指定以下值：
Codespace of the Flag field (NSA object)
标志字段的代码空间（NSA对象）
Bit Description Reference
位描述参考
6 Aggregator This document 7 Overloaded This document
6聚合器此文档7重载此文档
Bits 0-5 are reserved.
保留位0-5。
IANA has created a sub-registry, called "Hop-Count Object Flag field", to manage the codespace of the 4-bit Flag field of the Hop Count object.
IANA创建了一个名为“跃点计数对象标志字段”的子注册表，用于管理跃点计数对象的4位标志字段的代码空间。
No Flag is currently defined.
当前未定义任何标志。
IANA has created a sub-registry, called "Node Type Field", to manage the codespace of the field of the Routing Metric/Constraint common header.
IANA创建了一个名为“节点类型字段”的子注册表，用于管理路由度量/约束公共头字段的代码空间。
The T field is 2 bits in length, and it has values ranging from 0 to 3.
T字段的长度为2位，其值范围为0到3。
Codespace of the T field (Routing Metric/Constraint common header)
T字段的代码空间（路由度量/约束公共头）
Value Description Reference 0 a mains-powered node This document 1 a battery-powered node This document 2 a node powered by an energy scavenger This document
值说明参考0电源供电的节点本文档1电池供电的节点本文档2由能量清除器供电的节点本文档
Routing metrics should be handled in a secure and trustful manner. For instance, RPL should not allow a malicious node to falsely advertise that it has good metrics for routing so as to be selected as preferred next-hop router for other nodes' traffic and intercept packets. Another attack may consist of making intermittent attacks on a link in an attempt to constantly modify the link quality and consequently the associated routing metric, thus, leading to potential fluctuation in the DODAG. Thus, it is RECOMMENDED for a RPL implementation to put in place mechanisms so as to stop advertising routing metrics for highly unstable links that may be subject to attacks.
路由度量应该以安全可靠的方式处理。例如，RPL不应允许恶意节点错误地宣传其具有良好的路由度量，以便被选为其他节点流量和拦截数据包的首选下一跳路由器。另一种攻击可能包括对链路进行间歇性攻击，试图不断修改链路质量，从而修改相关的路由度量，从而导致DODAG中的潜在波动。因此，建议RPL实现采用适当的机制，以停止针对可能受到攻击的高度不稳定链路的广告路由度量。
Some routing metrics may also be used to identify some areas of weaknesses in the network (a highly unreliable link, a node running low in terms of energy, etc.). Such information may be used by a potential attacker. Thus, it is RECOMMENDED to carefully consider which metrics should be used by RPL and the level of visibility that they provide about the network state or to use appropriate the security measures as specified in [RFC6550] to protect that information.
一些路由度量还可用于确定网络中的某些弱点（高度不可靠的链路、能量不足的节点等）。此类信息可能被潜在攻击者使用。因此，建议仔细考虑RPL应该使用哪些度量和它们提供的关于网络状态的可见性水平，或者使用在[RCFC5050]中规定的适当的安全措施来保护该信息。
Since the routing metrics/constraints are carried within RPL message, the security routing mechanisms defined in [RFC6550] apply here.
由于路由度量/约束包含在RPL消息中，因此[RFC6550]中定义的安全路由机制适用于此处。
The authors would like to acknowledge the contributions of Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal, Joseph Saloway, David Culler, and Jari Arkko for their review and valuable comments. Special thanks to Adrian Farrel for his thorough review.
作者要感谢年轻的Jae Kim、Hakjin Chong、David Meyer、Misha Dohler、Anders Brandt、Philip Levis、Pascal Thubert、Richard Kelsey、Jonathan Hui、Alexandru Petrescu、Richard Kelsey、Mathilde Durvy、Phoebus Chen、Tim Winter、Yoav Ben Yehezkel、Matteo Paris、Omprakash Gnawali、Mads Westergreen、，感谢Mukul Goyal、Joseph Saloway、David Culler和Jari Arkko的评论和宝贵意见。特别感谢阿德里安·法雷尔的全面回顾。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]Dohler，M.，Watteyne，T.，Winter，T.，和D.Barthel，“城市低功率和有损网络的路由要求”，RFC 5548，2009年5月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]Pister，K.，Thubert，P.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，2009年10月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826]Brandt，A.，Buron，J.，和G.Porcu，“低功率和有损网络中的家庭自动化路由要求”，RFC 5826，2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867]Martocci，J.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
[RFC6552]Thubert，P.，Ed.“低功耗和有损网络路由协议（RPL）的目标函数零”，RFC 6552，2012年3月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ROLL-TERMS]Vasseur，JP.，“低功耗和有损网络中的术语”，正在进行的工作，2011年9月。
[Zinky1989] Zinky, J., Vichniac, G., and A. Khanna, "Performance of the Revised Routing Metric for ARPANET and MILNET", Military Communications Conference, MILCOM '89, March 1989.
[Zinky1989]Zinky，J.，Vichniac，G.，和A.Khanna，“ARPANET和MILNET的改进路由度量的性能”，军事通信会议，MILCOM'89，1989年3月。
Authors' Addresses
作者地址
JP. Vasseur (editor) Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。Vasseur（编辑）Cisco Systems 11号，法国卡米尔·德斯穆林街Issy Les Moulineaux 92782号
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
韩国首尔Seocho gu Woomyeon dong KT 17号企业技术集团Mijeom Kim（编辑）137-792
EMail: mjkim@kt.com
EMail: mjkim@kt.com
Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA
美国加利福尼亚州海沃德亨特伍德大道30695号克里斯·皮斯特灰尘网络，邮编95544
EMail: kpister@dustnetworks.com
EMail: kpister@dustnetworks.com
Nicolas Dejean Elster SAS Espace Concorde, 120 impasse JB Say Perols 34470 France
Nicolas Dejean Elster SAS Espace协和式飞机，120绝境JB赛道贝罗斯34470法国
EMail: nicolas.dejean@coronis.com
EMail: nicolas.dejean@coronis.com
Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan 38243 France
Dominique Barthel法国电信橙色28 chemin du Vieux Chene，BP 98 Meylan 38243法国
EMail: dominique.barthel@orange.com
EMail: dominique.barthel@orange.com