2207人阅读
Oracle Management（192）
作者同类文章X
author：skate
oracle交换分区对数据的加载提速案例
db：oracle10g
其中一个库的数据加载非常慢，如何能提高数据的加载速度呢？下面是一个小例子。
首先统计加载数据表所涉及的sql，这是做下面的基础。
使用表tabname1的sql如下几个：
SELECT COUNT(*)
& FROM (SELECT RPL.ITEMCODE, RPL.CATALOGID
&&&&&&&&& FROM tabname RPL
&&&&&&&& WHERE RPL.L3COLUMN = :1
&&&&&&&&&& and RPL.SUPPLIERID = :2
&&&&&&&&&& and RPL.STATDATE = TO_DATE(sysdate-2, 'YYYY-MM-DD')
&&&&&&&& GROUP BY (RPL.CATALOGID, RPL.ITEMCODE)) TEMP
SELECT SUM(LISTNUM) AS lSUM, SUM(CLICKNUM) AS CSUM
& FROM tabname RPL
&WHERE RPL.L3COLUMN = :1
&& and RPL.SUPPLIERID = :2
&& and RPL.STATDATE = TO_DATE(:3, 'YYYY-MM-DD')
select TMPB.*
& from (SELECT TMPA.*, ROWNUM rownum_
&&&&&&&&& FROM (SELECT TEMP.LSUM,
&&&&&&&&&&&&&&&&&&&&&& TEMP.CSUM,
&&&&&&&&&&&&&&&&&&&&&& TEMP.ITEMCODE,
&&&&&&&&&&&&&&&&&&&&&& TEMP.CATALOGID,
&&&&&&&&&&&&&&&&&&&&&& RPO.ORDERNUM,
&&&&&&&&&&&&&&&&&&&&&& RPO.ORDER_PRO_NUM,
&&&&&&&&&&&&&&&&&&&&&& TEMP.PRODUCTID
&&&&&&&&&&&&&&&&& FROM (SELECT SUM(LISTNUM) AS lSUM,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& SUM(CLICKNUM) AS CSUM,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& RPL.ITEMCODE,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& RPL.CATALOGID,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& RPL.PRODUCTID
&&&&&&&&&&&&&&&&&&&&&&&&& FROM tabname1 RPL
&&&&&&&&&&&&&&&&&&&&&&&& WHERE RPL.L3COLUMN = :1
&&&&&&&&&&&&&&&&&&&&&&&&&& and RPL.SUPPLIERID = :2
&&&&&&&&&&&&&&&&&&&&&&&&&& and (RPL.CATALOGID like '015%' or
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& RPL.CATALOGID like '15%')
&&&&&&&&&&&&&&&&&&&&&&&&&& and RPL.STATDATE = TO_DATE(:3, 'YYYY-MM-DD')
&&&&&&&&&&&&&&&&&&&&&&&& GROUP BY (RPL.CATALOGID, RPL.ITEMCODE, RPL.PRODUCTID)) TEMP
&&&&&&&&&&&&&&&&& LEFT JOIN tabname3 RPO
&&&&&&&&&&&&&&&&&&& ON TEMP.ITEMCODE = RPO.ITEMCODE
&&&&&&&&&&&&&&&&&& and RPO.STATDATE = TO_DATE(:4, 'YYYY-MM-DD')
&&&&&&&&&&&&&&&& ORDER BY LSUM DESC, TEMP.ITEMCODE) TMPA
&&&&&&&& WHERE ROWNUM &= :5) TMPB
&WHERE TMPB.rownum_ & :6
SELECT TCC.DESCRIPTION
& FROM tabname1 RPL, tabname2 TCC
&WHERE RPL.COUNTRY = TCC.COUNTRYID
&& AND RPL.L3COLUMN = :1
&& and RPL.SUPPLIERID = :2
&& and RPL.ITEMCODE = :3
&& and RPL.STATDATE = TO_DATE(:4, 'YYYY-MM-DD')
&& and ROWNUM &= :5
&ORDER BY RPL.LISTNUM DESC
通过以上sql可以看到，都是对数据某一天的统计，这些sql也是主要影响db磁盘的io的，所以建议调整tabname1的分区格式，采用rang-list组合分区；只创建分区索引，不创建全局索引。以STATDATE列创建rang分区，以L3COLUMN创建list分区
目前load数据逻辑：
1.&每天先truancate表tmp_tabname1，
2.&然后gp集群把这一天的所有数据都load到tmp_tabname1，
3.&然后再把tmp_tabname1 直接insert到表tabname1；速度主要慢在insert的过程。（可以按L3COLUMN把数据分配load到tmp_tabname1）
调整后load数据逻辑：
1.&每天先truancate表tmp_tabname1,
2.&然后gp集群把这一天的每个list（L3COLUMN）数据分别load到tmp_tabname1，也就是说gp集群把原来一次load变为1000次，或者tmp_tabname1的分区和tabname1一样，这样gp集群也是一次load
3.&利用oracle的表交换技术（eg：alter table t_temp exchange subpartition p9sublist1 with table t_temp1 update indexes）来提高数据load到tabname1的速度
我测试用表交换技术和insert的load数据对比
数据量：300m，1700万记录的测试数据
用表交换（有全局索引的），速度比insert快2倍左右
用表交换（没有有全局索引的），速度比insert快4-6倍左右
这样做的好处，因为db的io瓶颈很严重，io的utile%几乎很少低于95%的
1.&提高查询速度，sql根据STATDATE找到rang主分区，然后再根据L3COLUMN找到list分区，这样就减少了数据扫描的数据量
2.&加快了load的速度
3.&便于维护
1.gp集群到tmp_tabname1的load速度有影响
可以根据自己业务需求来选择合适实现方式，选择适合自己的就是最好的！！！
------end------
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2092003次
积分：22659
积分：22659
排名：第160名
原创：528篇
转载：49篇
评论：211条
每天进步一点一点
MySQL,Oracle,Data Architect
email/msn:
weibo :/skatexg
(3)(2)(4)(2)(7)(1)(2)(3)(1)(4)(2)(1)(2)(1)(2)(6)(4)(5)(9)(5)(1)(9)(4)(4)(13)(9)(5)(6)(8)(22)(1)(6)(1)(6)(5)(7)(5)(1)(6)(7)(1)(7)(10)(5)(12)(10)(2)(10)(23)(8)(23)(4)(1)(11)(10)(9)(10)(11)(5)(3)(11)(23)(11)(7)(1)(3)(5)(1)(2)(12)(9)(17)(5)(15)(16)(7)(6)(7)(19)(3)(3)(2)(1)(2)(6)(4)(2)(6)(4)Internet Engineering Task Force (IETF)
P. Thubert, Ed.
Request for Comments: 6552
Cisco Systems
Category: Standards Track
March 2012
Objective Function Zero for the
Routing Protocol for Low-Power and Lossy Networks (RPL)
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 O an OF is not an
algorithm.
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
It represents the consensus of the IETF community.
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG).
Further information on
Internet Standards is available in .
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors.
All rights reserved.
This document is subject to
and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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
Standards Track
RPL Objective Function Zero
March 2012
include Simplified BSD License text as described in .e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
. Introduction ....................................................
. Terminology .....................................................
. Objective Function Zero Overview ................................
. OF0 Operations ..................................................
. Computing Rank .............................................
. Parent Selection ...........................................
. Selection of the Preferred Parent ...................
. Selection of the Backup Feasible Successor ..........
. Abstract Interface to OF0 .......................................
. OF0 Operands ....................................................
. Variables ..................................................
. Configurable Parameters ...................................
. Constants .................................................
. Manageability Considerations ...................................
. Device Configuration ......................................
. Device Monitoring .........................................
. IANA Considerations ............................................
. Security Considerations ........................................
. Acknowledgements ..............................................
. References ....................................................
. Normative References .....................................
. Informative References ...................................
Introduction
The Routing Protocol for Low-Power and Lossy Networks (RPL)
specification [] 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).
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
there are a number of algorithms that can be used to satisfy
the OF, of which the well-known Dijkstra algorithm is an example.
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.
Standards Track
RPL Objective Function Zero
March 2012
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.
DODAG is periodically reconstructed as a new DODAG Version to enable
a global reoptimization of the graph.
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.
The RPL Instance uses the OF to compute a Rank for the device.
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 [].
Regardless of the
particular OF used by a node, Rank
thus, post
convergence, loop-free paths are always formed.
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 [].
The Rank of a node is obtained by adding a strictly positive,
indirectly normalized scalar, rank_increase (), to the
Rank of a selected preferred parent.
The rank_increase is based on a
step_of_rank () 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 () 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 .
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.
The RPL specification [] 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.
The RPL specification [] 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
Standards Track
RPL Objective Function Zero
March 2012
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 t
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.
Terminology
The terminology used in this document is consistent with and
incorporates that described in "Terminology in Low power And Lossy
Networks" [] and [].
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 [].
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
Objective Function Zero Overview
The RPL specification describes constraints on how nodes select
potential parents, called a parent set, from their neighbors.
parents are feasible successors for upward traffic (towards the
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.
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 [], Sections
appropriate and may involve deployment specific policies as well.
Standards Track
RPL Objective Function Zero
March 2012
Thus, for the purpose of OF0, the term "Grounded" [] means
that the DODAG root provides such connectivity.
connectivity is asserted and maintained is out of scope.
Objective Function Zero is designed to find the nearest Grounded
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.
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.
the link conditions do not let an upward packet through the preferred
parent, the packet is passed to the backup feasible successor.
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 .
OF0 Operations
Computing Rank
An OF0 implementation first computes a variable step_of_rank
() 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.
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 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 [] and discussed in [].
Rank Objective Function with Hysteresis" [] provides
guidance on how link cost can be computed and on how hysteresis can
improve Rank stability.
Standards Track
RPL Objective Function Zero
March 2012
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.
implementation may stretch the step_of_rank with at most a
configurable stretch_of_rank () of any value between 0 (no
stretch) and the fixed constant MAXIMUM_RANK_STRETCH ().
An implementation MUST maintain the stretched step_of_rank between
the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK
This range allows the reflection of a large variation
of link quality.
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 () 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.
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.
rank_factor MUST be set between the fixed constants
MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR ().
The variable rank_increase is represented in units expressed by the
variable MinHopRankIncrease, which defaults to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE ([]); with that setting, the
least significant octet in the RPL Rank field in the DIO Base Object
is not used.
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):
R(N) = R(P) + rank_increase where:
rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
Standards Track
RPL Objective Function Zero
March 2012
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.
Parent Selection
Selection of the Preferred Parent
As it scans all the candidate neighbors, OF0 keeps the parent that is
the best for the following criteria (in order):
, 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.
Prior to selecting a router as the preferred parent, an
implementation SHOULD validate the connectivity and suitability
of the router as discussed in .
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.
In most cases, a router that does not succeed in the validation
process cannot be further considered for selection as preferred
In any case, a router that succeeded in that validation
process SHOULD be preferred over one that did not succeed.
When multiple interfaces are available, a policy might be
locally configured to order them and that
that is, a router on a higher-order interface in the policy is
preferable.
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.
A router that offers connectivity to a grounded DODAG Version
SHOULD be preferred over one that does not.
Standards Track
RPL Objective Function Zero
March 2012
A router that offers connectivity to a more preferable root
SHOULD be preferred.
When comparing two parents that belong to the same DODAG, a
router that offers connectivity to the most recent DODAG Version
SHOULD be preferred.
The parent that causes the lesser resulting Rank for this node,
as specified in , SHOULD be preferred.
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.
The preferred parent that was in use already SHOULD be
preferred.
A router that has announced a DIO message more recently SHOULD
be preferred.
These rules and their order MAY be varied by an implementation
according to configured policy.
Selection of the Backup Feasible Successor
When selecting a backup feasible successor, the OF performs in order
the following checks:
The backup feasible successor MUST NOT be the preferred parent.
The backup feasible successor MUST be either in the same DODAG
Version as this node or in an subsequent DODAG Version.
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.
A router with a lesser Rank SHOULD be preferred.
A router that has been validated as usable by an implementation-
dependent validation process SHOULD be preferred.
When multiple interfaces are available, a router on a higher
order interface is preferable.
Standards Track
RPL Objective Function Zero
March 2012
The backup feasible successor that was in use already SHOULD be
preferred.
These rules and their order MAY be varied by an implementation
according to configured policy.
Abstract Interface to OF0
Objective Function Zero interacts for its management and operations
in the following ways:
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 ).
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.
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.
Triggered Updates:
The OF0 support provides events to inform it that
a change in DAG information or Parent List has occurred.
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 Operands
On top of variables and constants defined in [], this
specification introduces the following variables and constants:
OF0 uses the following variables:
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
Standards Track
RPL Objective Function Zero
March 2012
Configurable Parameters
OF0 can use the following optional configurable values that are used
as parameters to the rank_increase computation:
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.
defines RPL constants.
OF0 fixes the values
of the following constants:
DEFAULT_STEP_OF_RANK:
MINIMUM_STEP_OF_RANK:
MAXIMUM_STEP_OF_RANK:
DEFAULT_RANK_STRETCH:
MAXIMUM_RANK_STRETCH:
DEFAULT_RANK_FACTOR:
MINIMUM_RANK_FACTOR:
MAXIMUM_RANK_FACTOR:
Manageability Considerations
depicts the management of the protocol.
specification inherits from that section and its subsections, with
the exception that metrics as specified in [] are not used and
do not require management.
Standards Track
RPL Objective Function Zero
March 2012
Device Configuration
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 .
If none is
configured, a value of 0 is assumed and the step_of_rank is not
stretched.
An OF0 implementation SHOULD support the DODAG Configuration option
as specified in
and apply the parameters
contained therein.
As discussed in , 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
with a fixed value of 256.
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
the maximum stretch_of_rank is set to the fixed constant
DEFAULT_RANK_STRETCH ().
the MinHopRankIncrease is set to the fixed constant
DEFAULT_MIN_HOP_RANK_INCREASE ([]).
The values can be overridden at any time and apply at the next
Version of the DODAG.
As discussed in , this
requirement might be overridden by further guidance for certain
application scenarios.
Device Monitoring
As discussed in , 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:
Standards Track
RPL Objective Function Zero
March 2012
DAG information as specified in , 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.
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.
IANA Considerations
Per this specification, an Objective Code Point (OCP) for OF0 has
been assigned in the Objective Code Point Registry as described in
Description:
A basic Objective Function that relies only on the
objects that are defined in [].
Defining RFC:
Security Considerations
This specification makes simple extensions to RPL and so is
vulnerable to and benefits from the security issues and mechanisms
described in [] and [].
This document does not
introduce new f thus, it requires no specific
mitigation for new threats.
OF0 depends on information exchanged in the Rank and OCP protocol
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.
Acknowledgements
Specific thanks to Philip Levis and Phoebus Chen for their help in
finalizing this document.
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.
Standards Track
RPL Objective Function Zero
March 2012
References
Normative References
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", , , March 1997.
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",
, March 2012.
Informative References
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,
Gnawali, O. and P. Levis, "The Minimum Rank
Objective Function with Hysteresis", Work
in Progress, May 2011.
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",
, March 2012.
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.
Vasseur, JP., "Terminology in Low power And Lossy
Networks", Work in Progress, September 2011.
Standards Track
RPL Objective Function Zero
March 2012
Author's Address
Pascal Thubert (editor)
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis
Phone: +33 497 23 26 34
Standards Track
Html markup produced by rfcmarkup 1.115, available from}