您的位置:首页 > 移动开发 > Objective-C

RFC6552中文版: Objective Function Zero for RPL

2016-02-23 14:14 661 查看
RFC 6552:低功耗网络路由协议(RPL)的目标函数Zero

OF:陈述了一个RPL节点在RPL实例中基于可用信息对象选择和优化路由这一过程的结果。

一个目标函数并不是一个算法。例如,在RPL之外,“最短路径优先”是一个目标函数,即一个结果源于两点之间具有最低成本的路径;存在大量的算法可以满足这个OF,最著名的迪杰斯特拉算法就是一个例子。

把OFs从核心协议规范中分离出来,这样允许RPL适应不同的优化标准,这些标准被部署、应用和网络设计这些广泛的范围所需要。

每个实例被分配一个特定的目标函数。一个DODAG周期性的重构成一个新的DODAG Version,实现该图的全局性再优化。

运行在某一设备上的RPL实例使用一个目标函数来决定自身应当加入到哪一个DODAG和DODAG的哪个版本。RPL实例也使用OF选择路由器作为父节点或是可用的继任者

RPL实例使用OF计算某一设备的Rank

ObjectiveFunction Zero基于RPL DODAGConfiguration选项和DIO base中的参数进行操作

RPL规范RFC6550中要求一个网络中的所有节点使用一个共同的OF。在单一网络中使用多个OFs的可能性研究是下一步的计划。(注:这里的单一网络应该是指一个RPL实例,一个LLN网络可以包括多个RPL实例)

RFC6550中不包括任何OF的定义。这留给其他文档实现,特定于不同的部署和应用环境。由于在RPL主要规范中没有默认的OF或是度量容器,所以这是可能发生,除非两个给定的实现遵循某一特定问题或环境的相同指导,这些实现不支持能够互操作的一个共同的OF。

OF0被设计作为默认OF,允许在一个广泛的用例实现之间的互操作。这就是为什么OF0没有定义如何将链路属性转化成Rank_increase,而是留给了实现;当然,OF0通过规范step_of_rank来实施rank_increase值,这与形成step_of_rank计算的细节相对。这也是为什么OF0忽略度量容器的原因。

3 目标函数Zero综述

RPL规范中描述了节点如何从邻居中选择被称之为父代集的潜在父节点的约束。所有的父节点是上行链路的可用继任者。

OF0的目标是让一个节点加入一个DODAG Version,其可以提供到一组特定节点或是一个更大路由基础设施的足够好的连通性,尽管无法保证该路径依据某一特定度量将被优化。连通性的验证过程有赖于实现和链路类型,也超出了本文档范围。该验证涉及但并不局限于RFC6550中3.2.3和3.2.13中的应用,适当的也可能涉及部署的特定策略。

所以,对于OF0的目的,RFC6550中的术语“Grounded”意味着DODAG根提供这样的连通性。至于连通性如何被宣称和维护则不在本文档的范围。

OF0被设计来发现最近的Grounded root。这是做到的,如果一个节点的Rank非常接近于它到该根的距离的抽象函数。这需要和其他一些需要维持路径多样性而增加Rank的动作达成平衡。在缺少Grounded root的情况下,LLN的内部连通性仍是可取的,将形成浮动DAG,最高行政优先的节点成为根。

OF0选择一个优先父节点,如果存在,还会选择一个后备继任者。所有上行流量通过优先父节点路由,优先父节点并不去尝试执行任何的负载平衡。当链路条件不能让某一上行数据包通过优先父节点,该包将通过可有备选父节点传输。

一个RPL节点监视器链接到大量的邻居节点,可以使用OF0为每一个链路分配一个rank_increase。尽管rank_increase确切的计算方法依赖于实现,但计算必须遵从4.1中定义的规则。

4 OF0 Operations

4.1 计算rank

由于基于静态度量如成本来计算step_of_rank意味着OF0实现只考虑足够好连通性的父节点进而导致Rank趋同于hop-count。在大部分LLN中,这趋于产生具有连通性较差的更少但更长的跳的路径;所以建议给予动态链路属性如ETX来计算step_of_rank。MROFH对如何计算成本以及磁滞如何提高Rank稳定性提供了指导。

OF0允许实现拉伸step_of_rank,进而保证至少有一个可用继承者和维持路径多样性。但并不推荐这种用法,这会导致不稳定。尽管如此,6.2节的stretch_of_rank可以配置0到MAXIMUM_RANK_STRETCH之间的任何值对step_of_rank参数进行拉伸。

4.2 选取父代

4.2.1选择优先父节点

扫描所有的候选邻居节点,OF0遵循下面的标准选取父节点。

十条规则

4.2.2选择备用父节点

5 OF0的抽象端口

OF0的管理和操作遵循下面的规则:

处理DIO:当接收到一个新DIO,与DIO中OCP相符合的OF被触发。OF0被定义为OCP 0。

提供DAGInformation:OF0支持提供一个端口,该端口返回有关给定实例的信息。这包括该节点的DIO基础头部,角色(路由、叶子)和Rank。

提供父节点列表:父节点列表和可用继任者。这些被包括在每个条目的Transit 选项中

触发更新:OF0支持提供事件来通知DAG信息或是父代列表发生改变。这可能是由系统的其他组成引起,如配置,定时器和设备驱动,这些改变可能引起RPL核心去发出一个新DIO或是重置Trickle定时器。

6 OF0 操作数

6.1 变量

OF0用到如下变量:

Step_of_rank(正整数):基于某一邻居的链路属性的一个中间计算。

rank_increase(正整数):优先父代和自身之间Rank的增量。

6.2 可配置参数

OF0能够使用下面的可选配置值,被用作参数计算rank_increase值:

stretch_of_rank(无符号整数):一个优先父代的step_of_rank的最大增强,以允许选取一个额外的可用继任者。如果设备没有配置,step_of_rank不被延伸。

Rank_factor(正整数):一个可配置因素,在rank_increase计算中用来倍乘链路属性的影响。如果没有配置,rank_factor被当作1使用。

6.3 常量

在rfc6550中定义了RPL常量,OF0确定了下列常量的值:

DEFAULT_STEP_OF_RANK: 3

MINIMUM_STEP_OF_RANK: 1

MAXIMUM_STEP_OF_RANK: 9

DEFAULT_RANK_STRETCH: 0

MAXIMUM_RANK_STRETCH: 5

DEFAULT_RANK_FACTOR: 1

MINIMUM_RANK_FACTOR: 1

MAXIMUM_RANK_FACTOR: 4

7 客观理性的考虑

RFC6550的18节描述了该协议的管理。本规范继承该章,只是没有使用定义在6551中的度量,也不需要管理。

7.1 设备配置

一个实现应当允许配置至少一个用于所有链路的全局rank_factor。另外,实现也应当允许端口、链路或是邻居进行分组,对这些分组配置特定rank_factor。

一个实现可能允许配置一个最大stretch_of_rank,该值必须不超过4.1中定义的MAXIMUM_RANK_STRETCH。如果没有配置该值,默认为0,即step_of_rank没有被延伸。

一个OF0实现应当支持DODAG 配置选项,同时应用其中的参数。当该选项被使用,参数被配置到可能成为DODAG根的节点,给节点被配置使用DODAGConfiguration选项去分发信息。特别的,MinHopRankIncrease的值可能跟随该选项分发,重写定义在RFC6550中固定值为256的固定常量DEFAULT_MIN_HOP_RANK_INCREASE。

在初始化的时候,适当使用默认常量值:rank_factor,DEFAULT_RANK_FACTOR;stretch_of_rank,DEFAULT_RANK_STRETCH;MinHopRankIncrease,DEFAULT_MIN_HOP_RANK_INCREASE。

这些值可以随时被重载,在下一个Version中使用。

7.2device monitoring

OF支持必须能够提供有关它操作的信息,在信息改变的时候能够触发事件。至少,信息应当包括:RFC6550中定义的DAG信息即DIO Base,包括DODAGID、RPLInstanceID、MOP、Rank、Version Number和Grounded flag。

一个邻居列表,指示优先父代,如果能够提供,还包括一个备选父代。对于每一个邻居,应当标明它的Rank,当前Version Number和Grounded flag。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: