Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 6552                                 Cisco Systems
Category: Standards Track                                     March 2012
ISSN: 2070-1721
        
Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 6552                                 Cisco Systems
Category: Standards Track                                     March 2012
ISSN: 2070-1721
        

Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)

低功耗有损网络(RPL)路由协议的目标函数零

Abstract

摘要

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.

低功耗和有损网络路由协议(RPL)规范定义了一种通用的距离向量协议,该协议通过应用特定的目标函数(OFs)来适应各种网络类型。RPL节点用于基于可用信息对象在RPL实例内选择和优化路由的过程的结果的列表;OF不是一个算法。

This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions.

本文档指定了一个基本目标函数,该函数仅依赖于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/rfc6552.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6552.

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 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

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须

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 ....................................................2
   2. Terminology .....................................................4
   3. Objective Function Zero Overview ................................4
   4. OF0 Operations ..................................................5
      4.1. Computing Rank .............................................5
      4.2. Parent Selection ...........................................7
           4.2.1. Selection of the Preferred Parent ...................7
           4.2.2. Selection of the Backup Feasible Successor ..........8
   5. Abstract Interface to OF0 .......................................9
   6. OF0 Operands ....................................................9
      6.1. Variables ..................................................9
      6.2. Configurable Parameters ...................................10
      6.3. Constants .................................................10
   7. Manageability Considerations ...................................10
      7.1. Device Configuration ......................................11
      7.2. Device Monitoring .........................................11
   8. IANA Considerations ............................................12
   9. Security Considerations ........................................12
   10. Acknowledgements ..............................................12
   11. References ....................................................13
      11.1. Normative References .....................................13
      11.2. Informative References ...................................13
        
   1. Introduction ....................................................2
   2. Terminology .....................................................4
   3. Objective Function Zero Overview ................................4
   4. OF0 Operations ..................................................5
      4.1. Computing Rank .............................................5
      4.2. Parent Selection ...........................................7
           4.2.1. Selection of the Preferred Parent ...................7
           4.2.2. Selection of the Backup Feasible Successor ..........8
   5. Abstract Interface to OF0 .......................................9
   6. OF0 Operands ....................................................9
      6.1. Variables ..................................................9
      6.2. Configurable Parameters ...................................10
      6.3. Constants .................................................10
   7. Manageability Considerations ...................................10
      7.1. Device Configuration ......................................11
      7.2. Device Monitoring .........................................11
   8. IANA Considerations ............................................12
   9. Security Considerations ........................................12
   10. Acknowledgements ..............................................12
   11. References ....................................................13
      11.1. Normative References .....................................13
      11.2. Informative References ...................................13
        
1. Introduction
1. 介绍

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification [RFC6550] defines a generic Distance Vector protocol that is adapted to a variety of Low-Power and Lossy Network (LLN) types by the application of specific Objective Functions (OFs).

低功耗和有损网络路由协议(RPL)规范[RFC6550]定义了一种通用距离向量协议,该协议通过应用特定目标函数(OFs)适用于各种低功耗和有损网络(LLN)。

A RPL OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available. As a general concept, an OF is not an algorithm. For example, outside RPL, "shortest path first" is an OF where the least cost path between two points is derived as an outcome; there are a number of algorithms that can be used to satisfy the OF, of which the well-known Dijkstra algorithm is an example.

RPL表示RPL节点用于根据可用信息对象选择和优化RPL实例中的路由的过程的结果。作为一般概念,OF不是算法。例如,在RPL之外,“最短路径优先”是一种将两点之间的最小成本路径作为结果导出的方法;有许多算法可以用来满足of,其中著名的Dijkstra算法就是一个例子。

The separation of OFs from the core protocol specification allows RPL to be adapted to meet the different optimization criteria required by the wide range of deployments, applications, and network designs.

OFs与核心协议规范的分离允许RPL进行调整,以满足各种部署、应用和网络设计所需的不同优化标准。

RPL forms Directed Acyclic Graphs (DAGs) as collections of Destination-Oriented DAGs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed as a new DODAG Version to enable a global reoptimization of the graph.

RPL将有向无环图(DAG)形成为协议实例中面向目标的DAG(DODAG)的集合。每个实例都与一个专门的目标函数相关联。DODAG被周期性地重构为新的DODAG版本,以实现图形的全局再优化。

An instance of RPL running on a device uses an Objective Function to help it determine which DODAG and which Version of that DODAG it should join. The OF is also used by the RPL Instance to select a number of routers within the DODAG current and subsequent Versions to serve as parents or as feasible successors.

在设备上运行的RPL实例使用目标函数帮助它确定应该加入哪个DODAG以及该DODAG的哪个版本。RPL实例还使用OF来选择DODAG当前版本和后续版本中的多个路由器,作为父路由器或可行的后续路由器。

The RPL Instance uses the OF to compute a Rank for the device. This value represents an abstract distance to the root of the DODAG within the DODAG Version. The Rank is exchanged between nodes using RPL and allows other RPL nodes to avoid loops and verify forward progression toward the destination, as specified in [RFC6550]. Regardless of the particular OF used by a node, Rank will always increase; thus, post convergence, loop-free paths are always formed.

RPL实例使用OF来计算设备的秩。此值表示在DODAG版本中到DODAG根的抽象距离。按照[RFC6550]中的规定,使用RPL在节点之间交换秩,并允许其他RPL节点避免循环并验证向目的地的前进。不管一个节点使用的是什么,排名总是会增加;因此,在收敛后,总是形成无环路径。

The Objective Function Zero (OF0) operates on parameters that are obtained from provisioning, the RPL DODAG Configuration option and the RPL DODAG Information Object (DIO) base container [RFC6550].

目标函数0(OF0)对从供应、RPL DODAG配置选项和RPL DODAG信息对象(DIO)基本容器[RFC6550]获得的参数进行操作。

The Rank of a node is obtained by adding a strictly positive, indirectly normalized scalar, rank_increase (Section 6.1), to the Rank of a selected preferred parent. The rank_increase is based on a step_of_rank (Section 6.1) normalized scalar that can vary with a ratio from 1 (excellent) to 9 (worst acceptable) to represent the link properties. The step_of_rank can be multiplied by a configurable factor called rank_factor (Section 6.2) that amplifies the rank_increase to reflect the relative preferences between different link types that would be used in the same RPL Instance. The rank_increase can be further adapted as detailed in Section 4.1. By default, OF0 encodes the 2-octet Rank in units of 256, and the default settings allow for the encoding of a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops.

节点的秩是通过向选定首选父节点的秩添加严格正的、间接规范化的标量,即秩_增加(第6.1节)来获得的。秩增加基于秩(第6.1节)归一化标量的阶跃,该阶跃可以在1(优秀)到9(可接受的最差)之间变化,以表示链路属性。_秩的步长_可乘以一个称为秩_因子的可配置因子(第6.2节),该因子放大秩_的增加,以反映将在同一RPL实例中使用的不同链路类型之间的相对偏好。如第4.1节所述,可进一步调整秩_的增加。默认情况下,OF0以256为单位对2-octet列进行编码,默认设置允许编码最小28(可接受的最差)跳,最大255(最佳)跳。

The RPL specification [RFC6550] requires the use of a common OF by all nodes in a network. The possible use of multiple OFs with a single network is for further study.

RPL规范[RFC6550]要求网络中的所有节点都使用公共of。在单个网络中使用多个OFs的可能性有待进一步研究。

The RPL specification [RFC6550] does not include any OF definitions. This is left for other documents specific to different deployments and application environments. Since there is no default OF or metric container in the RPL main specification, it might happen that, unless

RPL规范[RFC6550]不包括任何定义。这将留给特定于不同部署和应用程序环境的其他文档使用。由于RPL主规范中没有默认的或度量容器,因此可能会发生以下情况,除非

two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate.

对于特定的问题或环境,两个给定的实现遵循相同的指导,这些实现将不支持它们可以互操作的公共。

OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. This is why OF0 does not specify how the link properties are transformed into a rank_increase and leaves that responsibility to the implementation; rather, OF0 enforces the values for the rank_increase by normalizing the step_of_rank for a normal link and its acceptable range, as opposed to formulating the details of the step_of_rank computation. This is also why OF0 ignores metric containers.

OF0被设计为默认的,它将允许在广泛的用例中实现之间的互操作。这就是为什么OF0没有指定如何将链接属性转换为秩增加,并将该责任留给实现;相反,OF0通过规范化正常链路的秩的步长及其可接受范围来强制秩的值,而不是制定秩的步长计算的细节。这也是OF0忽略度量容器的原因。

2. Terminology
2. 术语

The terminology used in this document is consistent with and incorporates that described in "Terminology in Low power And Lossy Networks" [ROLL-TERMS] and [RFC6550].

本文件中使用的术语与“低功率和有损网络术语”[ROLL-TERMS]和[RFC6550]中所述的术语一致,并结合了这些术语。

The term "feasible successor" is used to refer to a neighbor that can possibly be used as a next hop for Upward traffic following the loop avoidance and forwarding rules that the nodes implement and that are defined in the RPL specification [RFC6550].

术语“可行后继者”用于指可以用作上行业务的下一跳的邻居,其遵循节点实现的并且在RPL规范[RFC6550]中定义的环路避免和转发规则。

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 RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。

3. Objective Function Zero Overview
3. 目标函数零点概述

The RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors. All parents are feasible successors for upward traffic (towards the root). Additionally, RPL allows the use of parents in a subsequent Version of a same DODAG as feasible successors, in which case this node acts as a leaf in the subsequent DODAG Version.

RPL规范描述了节点如何从其邻居选择潜在父节点(称为父集)的约束。所有父代都是上行通信(向根方向)的可行继承者。此外,RPL允许在同一DODAG的后续版本中使用父节点作为可行的后续节点,在这种情况下,该节点充当后续DODAG版本中的叶节点。

The Goal of the OF0 is for a node to join a DODAG Version that offers good enough connectivity to a specific set of nodes or to a larger routing infrastructure though there is no guarantee that the path will be optimized according to a specific metric. This validation process for the connectivity is implementation and link type dependent and is out of scope. The validation involves but is not limited to application of [RFC6550], Sections 3.2.3 and 13, as appropriate and may involve deployment specific policies as well.

OF0的目标是让节点加入DODAG版本,该版本提供足够好的连接到特定节点集或更大的路由基础设施,尽管无法保证路径将根据特定指标进行优化。此连接验证过程取决于实现和链接类型,超出范围。验证涉及但不限于[RFC6550]第3.2.3节和第13节(视情况而定)的应用,也可能涉及特定于部署的政策。

Thus, for the purpose of OF0, the term "Grounded" [RFC6550] means that the DODAG root provides such connectivity. How that connectivity is asserted and maintained is out of scope.

因此,出于OF0的目的,术语“接地”[RFC6550]意味着DODAG根提供这种连接。如何断言和维护这种连接超出了范围。

Objective Function Zero is designed to find the nearest Grounded root. This can be achieved if the Rank of a node is very close to an abstract function of its distance to the root. This need is balanced with the other need of maintaining some path diversity, which may be achieved by increasing the Rank. In the absence of a Grounded root, inner connectivity within the LLN is still desirable and floating DAGs will form, rooted at the nodes with the highest administrative preference.

目标函数零点用于寻找最近的根。如果节点的秩非常接近其到根的距离的抽象函数,则可以实现这一点。这一需求与保持一些路径多样性的其他需求相平衡,这可以通过增加秩来实现。在没有固定根的情况下,仍然需要LLN内的内部连接,并且将形成浮动DAG,根在具有最高管理首选项的节点上。

OF0 selects a preferred parent and a backup feasible successor if one is available. All the upward traffic is normally routed via the preferred parent with no attempt to perform any load balancing. When the link conditions do not let an upward packet through the preferred parent, the packet is passed to the backup feasible successor.

OF0选择首选父项和备份可行的后续项(如果有)。所有上行流量通常通过首选父级路由,而不尝试执行任何负载平衡。当链路条件不允许上行数据包通过首选父级时,该数据包被传递给备份的后续数据包。

A RPL node monitors links to a number of neighbor nodes and can use OF0 to assign a rank_increase to each link. Though the exact method for computing the rank_increase is implementation dependent, the computation must follow the rules that are specified in Section 4.1.

RPL节点监视到多个相邻节点的链路,并可以使用OF0为每个链路分配一个秩增加。尽管计算秩_增加的精确方法取决于实现,但计算必须遵循第4.1节中规定的规则。

4. OF0 Operations
4. OF0操作
4.1. Computing Rank
4.1. 计算秩

An OF0 implementation first computes a variable step_of_rank (Section 6.1) associated with a given parent from relevant link properties and metrics. The step_of_rank is used to compute the amount by which to increase the rank along a particular link, as explained later in this section.

OF0实现首先根据相关链接属性和度量计算与给定父级相关联的变量step_of_rank(第6.1节)。_秩的步骤_用于计算沿特定链路增加秩的量,如本节后面所述。

Computing a step_of_rank based on a static metric such as an administrative cost implies that the OF0 implementation only considers parents with good enough connectivity, and results in a Rank that is analogous to hop-count. In most LLNs, this favors paths with fewer but longer hops of poorer connectivity; it is thus RECOMMENDED to base the computation of the step_of_rank on dynamic link properties such as the expected transmission count (ETX) metric as introduced in [DeCouto03] and discussed in [RFC6551]. "Minimum Rank Objective Function with Hysteresis" [HYSTERESIS] provides guidance on how link cost can be computed and on how hysteresis can improve Rank stability.

基于静态度量(如管理成本)计算步骤_of_秩意味着OF0实现只考虑具有足够好的连接性的父级,并产生类似于跳数的秩。在大多数LLN中,这有利于具有较少但较长跳数且连通性较差的路径;因此,建议根据动态链路特性(如[DeCouto03]中介绍并在[RFC6551]中讨论的预期传输计数(ETX)度量)计算_秩的步长_。“滞后最小秩目标函数”【滞后】提供了如何计算链路成本以及滞后如何提高秩稳定性的指导。

OF0 allows an implementation to stretch the step_of_rank in order to enable the selection of at least one feasible successor and thus maintain path diversity. Stretching the step_of_rank is NOT RECOMMENDED, because it augments the apparent distance from the node to the root, distorts the DODAG from the optimal shape and may cause instabilities due to greedy behaviors whereby depending nodes augment their Ranks to use each other as parents in a loop. Still, an implementation may stretch the step_of_rank with at most a configurable stretch_of_rank (Section 6.2) of any value between 0 (no stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).

OF0允许实现扩展_秩的步骤_,以便能够选择至少一个可行的后继者,从而保持路径多样性。不建议拉伸_秩的阶跃_,因为它增加了从节点到根的视距离,使DODAG偏离最佳形状,并可能由于贪婪行为而导致不稳定性,依赖节点通过贪婪行为增加其秩以将彼此用作循环中的父节点。尽管如此,一个实现可以用0(无延伸)和固定常数最大延伸(第6.3节)之间的任意值的至多一个可配置延伸延伸延伸延伸(第6.2节)延伸阶梯延伸延伸延伸延伸延伸延伸延伸延伸延伸延伸延伸延伸延伸延伸。

An implementation MUST maintain the stretched step_of_rank between the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK (Section 6.3). This range allows the reflection of a large variation of link quality.

一个实现必须将扩展步数保持在固定常数最小步数和最大步数之间(第6.3节)。该范围允许反映链路质量的巨大变化。

The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or high-speed (wired) over lower-speed (wireless) links, within the same DAG. An implementation SHOULD allow the operator to configure a factor called rank_factor (Section 6.2) and to apply the factor on all links and peers to multiply the effect of the stretched step_of_rank in the rank_increase computation as further detailed below.

在任何情况下,秩的最小阶跃_和秩的最大_伸展之间的间隙可能不足以强烈区分不同类型或类别的链路,以便在同一DAG内支持(例如)通过电池供电或通过低速(无线)链路的高速(有线)链路。实现应允许操作员配置一个称为秩因子(第6.2节)的因子,并将该因子应用于所有链路和对等方,以乘以秩增加计算中秩的延伸步长的影响,详情如下。

Additionally, an implementation MAY recognize categories of peers and links, such as different link types, in which case it SHOULD be able to configure a more specific rank_factor to those categories. The rank_factor MUST be set between the fixed constants MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3).

此外,实现可以识别对等点和链路的类别,例如不同的链路类型,在这种情况下,它应该能够为这些类别配置更具体的秩因子。秩因子必须设置在固定常数最小秩因子和最大秩因子之间(第6.3节)。

The variable rank_increase is represented in units expressed by the variable MinHopRankIncrease, which defaults to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]); with that setting, the least significant octet in the RPL Rank field in the DIO Base Object is not used.

变量秩增加以变量MinHopRankIncrease表示的单位表示,该变量默认为固定常量默认值秩增加([RFC6550]);使用该设置时,不使用DIO Base对象中RPL Rank字段中的最低有效八位字节。

The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then possibly stretched by a term Sr that is less than or equal to the configured stretch_of_rank. The resulting rank_increase is added to the Rank of preferred parent R(P) to obtain that of this node R(N):

为该链路计算的_秩Sp的步长_乘以秩因子Rf,然后可能被小于或等于配置的_秩拉伸_的项Sr拉伸。将得到的秩u增加添加到首选父级R(P)的秩,以获得该节点R(N)的秩:

R(N) = R(P) + rank_increase where:

R(N)=R(P)+秩u增加,其中:

   rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
        
   rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
        

Optionally, the administrative preference of a root MAY be configured to supersede the goal to join a Grounded DODAG. In that case, nodes will associate with the root with the highest preference available, regardless of whether or not that root is Grounded. Compared to a deployment with a multitude of Grounded roots that would result in the same multitude of DODAGs, such a configuration may result in possibly less but larger DODAGs, as many as roots configured with the highest priority in the reachable vicinity.

或者,根用户的管理首选项可以配置为取代加入固定DODAG的目标。在这种情况下,节点将与具有最高可用首选项的根关联,而不管该根是否固定。与具有多个接地根的部署相比,这种配置可能会导致相同数量的DoDAG,可能会导致更少但更大的DoDAG,与在可到达附近配置具有最高优先级的根一样多。

4.2. Parent Selection
4.2. 父选择
4.2.1. Selection of the Preferred Parent
4.2.1. 选择首选父母

As it scans all the candidate neighbors, OF0 keeps the parent that is the best for the following criteria (in order):

当它扫描所有候选邻居时,OF0将保留符合以下条件的最佳父对象(按顺序):

1. [RFC6550], Section 8, spells out the generic rules for a node to re-parent and in particular the boundaries to augment its Rank within a DODAG Version. A candidate that would not satisfy those rules MUST NOT be considered.

1. [RFC6550]第8节阐述了节点重新设置父节点的一般规则,特别是在DODAG版本中增加其排名的边界。不符合这些规则的候选人不得被考虑。

2. Prior to selecting a router as the preferred parent, an implementation SHOULD validate the connectivity and suitability of the router as discussed in Section 3. This validation involves checking the Layer 2 connectivity to the router, the Layer 3 connectivity offered by the router, and may involve examination of other factors such as locally or globally configured policies.

2. 在选择路由器作为首选父级之前,实施应验证路由器的连接性和适用性,如第3节所述。此验证包括检查与路由器的第2层连接、路由器提供的第3层连接,还可能包括检查其他因素,如本地或全局配置的策略。

In most cases, a router that does not succeed in the validation process cannot be further considered for selection as preferred parent. In any case, a router that succeeded in that validation process SHOULD be preferred over one that did not succeed.

在大多数情况下,验证过程中未成功的路由器不能被进一步考虑作为首选父路由器。在任何情况下,在验证过程中成功的路由器都应该优先于未成功的路由器。

3. When multiple interfaces are available, a policy might be locally configured to order them and that policy applies first; that is, a router on a higher-order interface in the policy is preferable.

3. 当多个接口可用时,可能会在本地配置一个策略来对其进行排序,并且该策略首先应用;也就是说,策略中的高阶接口上的路由器是优选的。

4. If the administrative preference of the root is configured to supersede the goal to join a Grounded DODAG, a router that offers connectivity to a more preferable root SHOULD be preferred.

4. 如果根目录的管理首选项配置为取代加入固定DODAG的目标,则应首选提供到更首选根目录的连接的路由器。

5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not.

5. 与不提供连接的路由器相比,应首选提供与接地DODAG版本连接的路由器。

6. A router that offers connectivity to a more preferable root SHOULD be preferred.

6. 应首选提供到更可取根的连接的路由器。

7. When comparing two parents that belong to the same DODAG, a router that offers connectivity to the most recent DODAG Version SHOULD be preferred.

7. 当比较属于同一DODAG的两个双亲时,应首选提供与最新DODAG版本连接的路由器。

8. The parent that causes the lesser resulting Rank for this node, as specified in Section 4.1, SHOULD be preferred.

8. 如第4.1节所述,应首选导致该节点产生较小秩的父节点。

9. A DODAG Version for which there is an alternate parent SHOULD be preferred. This check is OPTIONAL. It is performed by computing the backup feasible successor while assuming that the router that is currently examined is finally selected as preferred parent.

9. 应首选具有备用父级的DODAG版本。此支票是可选的。它是通过计算备份可行的后继者来执行的,同时假设当前检查的路由器最终被选为首选父路由器。

10. The preferred parent that was in use already SHOULD be preferred.

10. 应首选已在使用的首选父级。

11. A router that has announced a DIO message more recently SHOULD be preferred.

11. 应该首选最近发布了DIO消息的路由器。

These rules and their order MAY be varied by an implementation according to configured policy.

根据配置的策略,这些规则及其顺序可能因实现而异。

4.2.2. Selection of the Backup Feasible Successor
4.2.2. 选择可行的后继备份

When selecting a backup feasible successor, the OF performs in order the following checks:

选择备份可行的后继对象时,OF将按顺序执行以下检查:

1. The backup feasible successor MUST NOT be the preferred parent.

1. 备份继承者不能是首选父级。

2. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent DODAG Version.

2. 备份副本必须与此节点位于同一DODAG版本中,或者位于后续DODAG版本中。

3. Along with RPL rules, a Router in the same DODAG Version as this node and with a Rank that is higher than the Rank computed for this node MUST NOT be selected as a feasible successor.

3. 与RPL规则一样,不得选择与此节点具有相同DODAG版本且等级高于为此节点计算的等级的路由器作为可行的后续路由器。

4. A router with a lesser Rank SHOULD be preferred.

4. 应首选等级较低的路由器。

5. A router that has been validated as usable by an implementation-dependent validation process SHOULD be preferred.

5. 应首选通过依赖于实现的验证过程验证为可用的路由器。

6. When multiple interfaces are available, a router on a higher order interface is preferable.

6. 当多个接口可用时,最好在高阶接口上安装路由器。

7. The backup feasible successor that was in use already SHOULD be preferred.

7. 应首选已在使用的备份。

These rules and their order MAY be varied by an implementation according to configured policy.

根据配置的策略,这些规则及其顺序可能因实现而异。

5. Abstract Interface to OF0
5. OF0的抽象接口

Objective Function Zero interacts for its management and operations in the following ways:

目标函数Zero通过以下方式对其管理和操作进行交互:

Processing DIO: When a new DIO is received, the OF that corresponds to the Objective Code Point (OCP) in the DIO is triggered with the content of the DIO. OF0 is identified by OCP 0 (see Section 8).

处理DIO:当接收到新的DIO时,与DIO中的目标代码点(OCP)对应的OF将与DIO的内容一起触发。OF0由OCP 0标识(见第8节)。

Providing DAG Information: The OF0 support provides an interface that returns information about a given instance. This includes material from the DIO base header, the role (router, leaf), and the Rank of this node.

提供DAG信息:OF0支持提供了一个接口,返回关于给定实例的信息。这包括来自DIO基本标题的材料、角色(路由器、叶)和该节点的等级。

Providing a Parent List: The OF0 support provides an interface that returns the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry.

提供父列表:OF0支持提供了一个接口,该接口将给定实例的父级和可行继承者的有序列表返回给RPL核心。这包括每个条目的运输选项中包含的物料。

Triggered Updates: The OF0 support provides events to inform it that a change in DAG information or Parent List has occurred. This can be caused by an interaction with another system component such as configuration, timers, and device drivers, and the change may cause the RPL core to fire a new DIO or reset Trickle timers.

触发更新:OF0支持提供事件来通知它DAG信息或父列表发生了更改。这可能是由于与另一个系统组件(如配置、计时器和设备驱动程序)的交互造成的,该更改可能会导致RPL内核触发新的DIO或重置涓流计时器。

6. OF0 Operands
6. 0操作数

On top of variables and constants defined in [RFC6550], this specification introduces the following variables and constants:

除[RFC6550]中定义的变量和常量外,本规范还引入了以下变量和常量:

6.1. Variables
6.1. 变量

OF0 uses the following variables:

OF0使用以下变量:

step_of_rank (strictly positive integer): an intermediate computation based on the link properties with a certain neighbor.

_秩的第_步(严格正整数):基于与某个邻居的链接属性的中间计算。

rank_increase (strictly positive integer): delta between the Rank of the preferred parent and self

秩_增加(严格正整数):首选父级和自身秩之间的增量

6.2. Configurable Parameters
6.2. 可配置参数

OF0 can use the following optional configurable values that are used as parameters to the rank_increase computation:

OF0可以使用以下可选的可配置值作为秩_增加计算的参数:

stretch_of_rank (unsigned integer): the maximum augmentation to the step_of_rank of a preferred parent to allow the selection of an additional feasible successor. If none is configured to the device, then the step_of_rank is not stretched.

_秩的延伸(无符号整数):对首选父级的_秩的步长_的最大扩充,以允许选择其他可行的后续项。如果没有为设备配置任何,则不会拉伸_秩的步骤_。

rank_factor (strictly positive integer): A configurable factor that is used to multiply the effect of the link properties in the rank_increase computation. If none is configured, then a rank_factor of 1 is used.

秩因子(严格正整数):一个可配置因子,用于在秩因子增加计算中乘以链接属性的影响。如果未配置,则使用秩系数1。

6.3. Constants
6.3. 常数

Section 17 of [RFC6550] defines RPL constants. OF0 fixes the values of the following constants:

[RFC6550]第17节定义了RPL常数。OF0修复以下常量的值:

DEFAULT_STEP_OF_RANK: 3

等级的默认步骤:3

MINIMUM_STEP_OF_RANK: 1

秩的最小步长:1

MAXIMUM_STEP_OF_RANK: 9

_秩的最大_步数:9

DEFAULT_RANK_STRETCH: 0

默认等级拉伸:0

MAXIMUM_RANK_STRETCH: 5

最大秩长:5

DEFAULT_RANK_FACTOR: 1

默认排名系数:1

MINIMUM_RANK_FACTOR: 1

最低秩系数:1

MAXIMUM_RANK_FACTOR: 4

最大秩系数:4

7. Manageability Considerations
7. 可管理性考虑

Section 18 of [RFC6550] depicts the management of the protocol. This specification inherits from that section and its subsections, with the exception that metrics as specified in [RFC6551] are not used and do not require management.

[RFC6550]第18节描述了协议的管理。本规范继承了该部分及其子部分,但[RFC6551]中规定的指标未使用且不需要管理。

7.1. Device Configuration
7.1. 设备配置

An implementation SHOULD allows the configuration of at least a global rank_factor that applies to all links. Additionally, the implementation may allow the grouping of interfaces, links, and/or neighbors and configure a more specific rank_factor to such groups.

一个实现应该允许配置至少一个适用于所有链接的全局排名因子。此外,该实现可允许对接口、链路和/或邻居进行分组,并为这些组配置更具体的秩因子。

An implementation MAY allow the configuration of a maximum stretch_of_rank that MUST be less than or equal to MAXIMUM_RANK_STRETCH as discussed in Section 4.1. If none is configured, a value of 0 is assumed and the step_of_rank is not stretched.

如第4.1节所述,实现可能允许配置必须小于或等于最大秩拉伸的秩拉伸的最大拉伸。如果未配置任何值,则假定值为0,且不拉伸_秩的步长_。

An OF0 implementation SHOULD support the DODAG Configuration option as specified in Section 6.7.6 of [RFC6550] and apply the parameters contained therein. As discussed in Section 16 of [RFC6550], this requirement might be overridden by further guidance for certain application scenarios. When the option is used, the parameters are configured to the nodes that may become DODAG roots, and the nodes are configured to redistribute the information using the DODAG Configuration option. In particular, the value of MinHopRankIncrease can be distributed with that option and override the fixed constant of DEFAULT_MIN_HOP_RANK_INCREASE that is defined in Section 17 of [RFC6550] with a fixed value of 256.

OF0实现应支持[RFC6550]第6.7.6节中规定的DODAG配置选项,并应用其中包含的参数。如[RFC6550]第16节所述,该要求可能会被某些应用场景的进一步指导所覆盖。使用该选项时,将参数配置为可能成为DODAG根的节点,并将节点配置为使用DODAG配置选项重新分发信息。特别是,MinHopRankIncrease的值可以使用该选项分布,并用256的固定值覆盖[RFC6550]第17节中定义的默认值_MIN_HOP_RANK_INCREASE的固定常数。

Out of the box, that is at initial factory time, the default constant values SHOULD be used, that is:

开箱即用,即在初始出厂时间,应使用默认常量值,即:

the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR (Section 6.3).

秩因子设置为固定常数默认秩因子(第6.3节)。

the maximum stretch_of_rank is set to the fixed constant DEFAULT_RANK_STRETCH (Section 6.3).

_秩的最大拉伸设置为固定不变的默认_秩拉伸(第6.3节)。

the MinHopRankIncrease is set to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]).

MinHopRankIncrease设置为固定常量默认值\u MIN\u HOP\u RANK\u INCREASE([RFC6550])。

The values can be overridden at any time and apply at the next Version of the DODAG. As discussed in Section 16 of [RFC6550], this requirement might be overridden by further guidance for certain application scenarios.

这些值可以在任何时候被覆盖,并应用于DODAG的下一个版本。如[RFC6550]第16节所述,该要求可能会被某些应用场景的进一步指导所覆盖。

7.2. Device Monitoring
7.2. 设备监控

As discussed in Section 5, the OF support must be able to provide information about its operations and trigger events when that information changes. At a minimum, the information should include:

如第5节所述,支持部门必须能够提供有关其操作的信息,并在信息发生变化时触发事件。信息至少应包括:

DAG information as specified in Section 6.3.1 of [RFC6550], and including the DODAGID, the RPLInstanceID, the Mode of Operation, the Rank of this node, the current Version Number, and the value of the Grounded flag.

[RFC6550]第6.3.1节中规定的DAG信息,包括DODAGID、RPLInstanceID、操作模式、该节点的等级、当前版本号和固定标志的值。

A list of neighbors indicating the preferred parent and an alternate feasible if available. For each neighbor, the Rank, the current Version Number, and the value of the Grounded flag should be indicated.

邻居列表,指示首选父级和备用可行的(如果可用)。对于每个邻居,应指示等级、当前版本号和接地标志的值。

8. IANA Considerations
8. IANA考虑

Per this specification, an Objective Code Point (OCP) for OF0 has been assigned in the Objective Code Point Registry as described in Section 20.5 of [RFC6550].

根据本规范,OF0的目标代码点(OCP)已在目标代码点注册表中分配,如[RFC6550]第20.5节所述。

OCP code: 0

OCP代码:0

Description: A basic Objective Function that relies only on the objects that are defined in [RFC6550].

描述:仅依赖于[RFC6550]中定义的对象的基本目标函数。

Defining RFC: RFC 6552

定义RFC:RFC 6552

9. Security Considerations
9. 安全考虑

This specification makes simple extensions to RPL and so is vulnerable to and benefits from the security issues and mechanisms described in [RFC6550] and [ROLL-SECURITY]. This document does not introduce new flows or new messages; thus, it requires no specific mitigation for new threats.

本规范对RPL进行了简单的扩展,因此容易受到[RFC6550]和[ROLL-security]中描述的安全问题和机制的影响,并从中获益。本文件不引入新流程或新消息;因此,它不需要针对新威胁采取具体的缓解措施。

OF0 depends on information exchanged in the Rank and OCP protocol elements. If those elements were compromised, then an implementation of OF0 might generate the wrong path for a packet, resulting in it being misrouted. Therefore, deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that routing information might be modified or spoofed.

OF0取决于Rank和OCP协议元素中交换的信息。如果这些元素被破坏,那么OF0的实现可能会为数据包生成错误的路径,从而导致数据包被错误路由。因此,如果存在路由信息可能被修改或欺骗的风险,建议部署使用RPL安全机制。

10. Acknowledgements
10. 致谢

Specific thanks to Philip Levis and Phoebus Chen for their help in finalizing this document.

特别感谢Philip Levis和Phoebus Chen帮助完成本文件。

Many thanks also to Adrian Farrel, Tim Winter, JP. Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal, Meral Shirazipour, and Henning Rogge for in-depth review and first-hand implementers' feedback.

非常感谢Adrian Farrel,Tim Winter,JP。Vasseur、Julien Abeille、Mathilde Durvy、Teco Boot、Navneet Agarwal、Meral Shirazipour和Henning Rogge进行深入审查,并提供第一手实施者反馈。

11. References
11. 工具书类
11.1. Normative References
11.1. 规范性引用文件

[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月。

[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月。

11.2. Informative References
11.2. 资料性引用

[DeCouto03] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03, The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California, 2003, <http://pdos.csail.mit.edu/papers/grid:mobicom03/ paper.pdf>.

[DeCouto03]De Couto,D.,Aguayo,D.,Bicket,J.,和R.Morris,“多跳无线路由的高吞吐量路径度量”,MobiCom'03,第九届ACM移动计算和网络国际会议,加利福尼亚州圣地亚哥,2003年<http://pdos.csail.mit.edu/papers/grid:mobicom03/ paper.pdf>。

[HYSTERESIS] Gnawali, O. and P. Levis, "The Minimum Rank Objective Function with Hysteresis", Work in Progress, May 2011.

[滞后]Gnawali,O.和P.Levis,“具有滞后的最小秩目标函数”,正在进行的工作,2011年5月。

[RFC6551] Vasseur, J., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.

[RFC6551]Vasseur,J.,Ed.,Kim,M.,Ed.,Pister,K.,Dejean,N.,和D.Barthel,“低功率和有损网络中用于路径计算的路由度量”,RFC 65512012年3月。

[ROLL-SECURITY] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", Work in Progress, March 2012.

[ROLL-SECURITY]Tsao,T.,Alexander,R.,Dohler,M.,Daza,V.,和A.Lozano,“低功耗和有损网络路由的安全框架”,正在进行的工作,2012年3月。

[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.

[ROLL-TERMS]Vasseur,JP.,“低功耗和有损网络中的术语”,正在进行的工作,2011年9月。

Author's Address

作者地址

Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE

Pascal Thubert(编辑)Cisco Systems Village d'Enterprises Green Side 400,Roumanille大道Batitment T3 Biot-Sophia Antipolis 06410法国

   Phone: +33 497 23 26 34
   EMail: pthubert@cisco.com
        
   Phone: +33 497 23 26 34
   EMail: pthubert@cisco.com