RFC 6550：IPv6低功耗网络路由协议(RPL)标准

6550

路由协议

需积分: 10 140 浏览量更新于2024-07-16 收藏 220KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

RFC 6550, "IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)", 是由Internet Engineering Task Force (IETF)于2012年3月发布的标准跟踪文档。该文档主要关注的是在低功耗和易失性网络（Low-Power and Lossy Networks, LLNs）中设计和实现的路由协议，这是物联网（IoT）领域的一个关键组成部分。LLNs的特点是路由器及其连接设备受到严格的性能限制，包括有限的处理能力、内存和能源（通常是电池供电）。这些网络的通信特性表现为高丢包率、低数据速率和不稳定性，网络规模可能从几十到数千个路由器不等。 RPL的设计目标是为了适应LLN环境，提供一种节能且高效的路由机制。它支持三种主要的流量模式：点对点通信（设备间直接通信），点对多点通信（从中心控制点到网络中的部分设备），以及多点对点通信（设备向中心控制点的方向）。RPL协议特别注重在资源受限的环境中保持网络的连通性和稳定性，这对于部署在远程传感器网络、智能家居、智能城市基础设施等场景中的设备至关重要。 RPL采用自组织和逐跳路由的方式，允许节点根据其位置和网络拓扑进行动态路径选择，减少了对集中式控制的需求。此外，它还包含了一套机制来处理节点的加入和离开，以及处理网络拓扑变化带来的影响。为了优化能量消耗，RPL强调了最小化节点间的控制消息交互，并通过使用目标导向的路由策略，如DODAG（Destination-Oriented Directed Acyclic Graph）结构，确保数据沿着最短或最优路径传输。文档详细描述了RPL的工作原理、协议架构、操作模式、控制消息流程以及安全考虑。它还提供了实施和部署RPL时的建议，包括如何配置和维护网络，以及如何与其他IPv6协议栈组件协同工作。对于任何在LLN环境中设计和管理网络的工程师和技术人员来说，RFC 6550是不可或缺的技术参考文献，它为了解决物联网中的路由挑战提供了全面而深入的指导。

资源详情

资源推荐

RFC 6550 RPL March 2012

+----------------------------------------------------------------+

| |

| +--------------+ |

| | | |

| | (R1) | (R2) (R3) |

| | / \ | /| \ / | \ |

| | / \ | / | \ / | \ |

| | (A) (B) | (C) | (D) ... (F) (G) (H) |

| | /|\ |\ | / | / |\ |\ | | |

| | : : : : : | : (E) : : : ‘: : |

| | | / \ |

| +--------------+ : : |

| DODAG |

| |

+----------------------------------------------------------------+

RPL Instance

Figure 1: RPL Instance

+----------------+ +----------------+

| | | |

| (R1) | | (R1) |

| / \ | | / |

| (A) (B) | \ | (A) |

| /|\ / |\ | ------\ | /|\ |

| : : (C) : : | \ | : : (C) |

| | / | \ |

| | ------/ | \ |

| | / | (B) |

| | | |\ |

| | | : : |

| | | |

+----------------+ +----------------+

Version N Version N+1

Figure 2: DODAG Version

3.2. Upward Routes and DODAG Construction

RPL provisions routes Up towards DODAG roots, forming a DODAG

optimized according to an Objective Function (OF). RPL nodes

construct and maintain these DODAGs through DODAG Information Object

(DIO) messages.

Winter, et al. Standards Track [Page 16]

RFC 6550 RPL March 2012

3.2.1. Objective Function (OF)

The Objective Function (OF) defines how RPL nodes select and optimize

routes within a RPL Instance. The OF is identified by an Objective

Code Point (OCP) within the DIO Configuration option. An OF defines

how nodes translate one or more metrics and constraints, which are

themselves defined in [RFC6551], into a value called Rank, which

approximates the node’s distance from a DODAG root. An OF also

defines how nodes select parents. Further details may be found in

Section 14, [RFC6551], [RFC6552], and related companion

specifications.

3.2.2. DODAG Repair

A DODAG root institutes a global repair operation by incrementing the

DODAGVersionNumber. This initiates a new DODAG Version. Nodes in

the new DODAG Version can choose a new position whose Rank is not

constrained by their Rank within the old DODAG Version.

RPL also supports mechanisms that may be used for local repair within

the DODAG Version. The DIO message specifies the necessary

parameters as configured from and controlled by policy at the DODAG

root.

3.2.3. Security

RPL supports message confidentiality and integrity. It is designed

such that link-layer mechanisms can be used when available and

appropriate; yet, in their absence, RPL can use its own mechanisms.

RPL has three basic security modes.

In the first, called "unsecured", RPL control messages are sent

without any additional security mechanisms. Unsecured mode does not

imply that the RPL network is unsecure: it could be using other

present security primitives (e.g., link-layer security) to meet

application security requirements.

In the second, called "preinstalled", nodes joining a RPL Instance

have preinstalled keys that enable them to process and generate

secured RPL messages.

The third mode is called "authenticated". In authenticated mode,

nodes have preinstalled keys as in preinstalled mode, but the

preinstalled key may only be used to join a RPL Instance as a leaf.

Joining an authenticated RPL Instance as a router requires obtaining

a key from an authentication authority. The process by which this

key is obtained is out of scope for this specification. Note that

this specification alone does not provide sufficient detail for a RPL

Winter, et al. Standards Track [Page 17]

RFC 6550 RPL March 2012

implementation to securely operate in authenticated mode. For a RPL

implementation to operate securely in authenticated mode, it is

necessary for a future companion specification to detail the

mechanisms by which a node obtains/requests the authentication

material (e.g., key, certificate) and to determine from where that

material should be obtained. See also Section 10.3.

3.2.4. Grounded and Floating DODAGs

DODAGs can be grounded or floating: the DODAG root advertises which

is the case. A grounded DODAG offers connectivity to hosts that are

required for satisfying the application-defined goal. A floating

DODAG is not expected to satisfy the goal; in most cases, it only

provides routes to nodes within the DODAG. Floating DODAGs may be

used, for example, to preserve interconnectivity during repair.

3.2.5. Local DODAGs

RPL nodes can optimize routes to a destination within an LLN by

forming a Local DODAG whose DODAG root is the desired destination.

Unlike global DAGs, which can consist of multiple DODAGs, local DAGs

have one and only one DODAG and therefore one DODAG root. Local

DODAGs can be constructed on demand.

3.2.6. Administrative Preference

An implementation/deployment may specify that some DODAG roots should

be used over others through an administrative preference.

Administrative preference offers a way to control traffic and

engineer DODAG formation in order to better support application

requirements or needs.

3.2.7. Data-Path Validation and Loop Detection

The low-power and lossy nature of LLNs motivates RPL’s use of on-

demand loop detection using data packets. Because data traffic can

be infrequent, maintaining a routing topology that is constantly up

to date with the physical topology can waste energy. Typical LLNs

exhibit variations in physical connectivity that are transient and

innocuous to traffic, but that would be costly to track closely from

the control plane. Transient and infrequent changes in connectivity

need not be addressed by RPL until there is data to send. This

aspect of RPL’s design draws from existing, highly used LLN protocols

as well as extensive experimental and deployment evidence on its

efficacy.

Winter, et al. Standards Track [Page 18]

RFC 6550 RPL March 2012

The RPL Packet Information that is transported with data packets

includes the Rank of the transmitter. An inconsistency between the

routing decision for a packet (Upward or Downward) and the Rank

relationship between the two nodes indicates a possible loop. On

receiving such a packet, a node institutes a local repair operation.

For example, if a node receives a packet flagged as moving in the

Upward direction, and if that packet records that the transmitter is

of a lower (lesser) Rank than the receiving node, then the receiving

node is able to conclude that the packet has not progressed in the

Upward direction and that the DODAG is inconsistent.

3.2.8. Distributed Algorithm Operation

A high-level overview of the distributed algorithm, which constructs

the DODAG, is as follows:

o Some nodes are configured to be DODAG roots, with associated DODAG

configurations.

o Nodes advertise their presence, affiliation with a DODAG, routing

cost, and related metrics by sending link-local multicast DIO

messages to all-RPL-nodes.

o Nodes listen for DIOs and use their information to join a new

DODAG (thus, selecting DODAG parents), or to maintain an existing

DODAG, according to the specified Objective Function and Rank of

their neighbors.

o Nodes provision routing table entries, for the destinations

specified by the DIO message, via their DODAG parents in the DODAG

Version. Nodes that decide to join a DODAG can provision one or

more DODAG parents as the next hop for the default route and a

number of other external routes for the associated instance.

3.3. Downward Routes and Destination Advertisement

RPL uses Destination Advertisement Object (DAO) messages to establish

Downward routes. DAO messages are an optional feature for

applications that require point-to-multipoint (P2MP) or point-to-

point (P2P) traffic. RPL supports two modes of Downward traffic:

Storing (fully stateful) or Non-Storing (fully source routed); see

Section 9. Any given RPL Instance is either storing or non-storing.

In both cases, P2P packets travel Up toward a DODAG root then Down to

the final destination (unless the destination is on the Upward

route). In the Non-Storing case, the packet will travel all the way

to a DODAG root before traveling Down. In the Storing case, the

Winter, et al. Standards Track [Page 19]

RFC 6550 RPL March 2012

packet may be directed Down towards the destination by a common

ancestor of the source and the destination prior to reaching a DODAG

root.

As of the writing of this specification, no implementation is

expected to support both Storing and Non-Storing modes of operation.

Most implementations are expected to support either no Downward

routes, Non-Storing mode only, or Storing mode only. Other modes of

operation, such as a hybrid mix of Storing and Non-Storing mode, are

out of scope for this specification and may be described in other

companion specifications.

This specification describes a basic mode of operation in support of

P2P traffic. Note that more optimized P2P solutions may be described

in companion specifications.

3.4. Local DODAGs Route Discovery

Optionally, a RPL network can support on-demand discovery of DODAGs

to specific destinations within an LLN. Such Local DODAGs behave

slightly differently than Global DODAGs: they are uniquely defined by

the combination of DODAGID and RPLInstanceID. The RPLInstanceID

denotes whether a DODAG is a Local DODAG.

3.5. Rank Properties

The Rank of a node is a scalar representation of the location of that

node within a DODAG Version. The Rank is used to avoid and detect

loops and, as such, must demonstrate certain properties. The exact

calculation of the Rank is left to the Objective Function. Even

though the specific computation of the Rank is left to the Objective

Function, the Rank must implement generic properties regardless of

the Objective Function.

In particular, the Rank of the nodes must monotonically decrease as

the DODAG Version is followed towards the DODAG destination. In that

regard, the Rank can be considered a scalar representation of the

location or radius of a node within a DODAG Version.

The details of how the Objective Function computes Rank are out of

scope for this specification, although that computation may depend,

for example, on parents, link metrics, node metrics, and the node

configuration and policies. See Section 14 for more information.

The Rank is not a path cost, although its value can be derived from

and influenced by path metrics. The Rank has properties of its own

that are not necessarily those of all metrics:

Winter, et al. Standards Track [Page 20]

剩余157页未读，继续阅读

zangchang

粉丝: 4
资源: 23

RFC 6550：IPv6低功耗网络路由协议(RPL)标准

无线传感器网络的RPL路由协议的RFC6550

RFC6550(中文)RPL低功耗有损网络的IPv6路由协议

RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

rfc2327_sdp.pdf

rfc8446 中文 pdf

rfc3261中文版 pdf 下载

rfc2822 中文 pdf

confd rfc中文pdf

sap abap开发技术详解 实例篇.pdf

rfc3261中文版 pdf csdn

rfc2326中文版pdf

python的0.18.1版本的pyHanko库的全部功能及示例

tcp发展 rfc pdf

rfc 文档大全 下载

rfc全部文档离线下载rfc1-rfc8505

rfc2326 pdf

关于MIME和S-MIME的信息资源

rfc8446中文版下载

opus数据帧格式的参考资料有哪些

python从邮件下载附件PDF

最新资源

sap abap开发技术详解实例篇.pdf

rfc 文档大全下载