Internet Engineering Task Force (IETF) E. Kim
Request for Comments: 6606 ETRI
Category: Informational D. Kaspar
ISSN: 2070-1721 Simula Research Laboratory
C. Gomez
Universitat Politecnica de Catalunya/Fundacio i2CAT
C. Bormann
Universitaet Bremen TZI
May 2012
Internet Engineering Task Force (IETF) E. Kim
Request for Comments: 6606 ETRI
Category: Informational D. Kaspar
ISSN: 2070-1721 Simula Research Laboratory
C. Gomez
Universitat Politecnica de Catalunya/Fundacio i2CAT
C. Bormann
Universitaet Bremen TZI
May 2012
Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
IPv6低功耗无线个人区域网（6LoWPAN）路由的问题陈述和要求
Abstract
摘要
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
低功耗无线个人区域网络（6LoWPANs）上的IPv6由与IEEE 802.15.4标准兼容的设备组成。然而，IEEE 802.15.4标准和6LoWPAN格式规范都没有定义如何获得和维护网状拓扑。因此，应考虑如何支持6LoWPAN形成和多跳路由。
This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG.
本文档提供6LoWPAN布线的问题说明和设计空间。考虑到设备和链路的低功耗和其他特殊特性，它定义了6LoWPANs的布线要求。本文档的目的不是推荐具体的解决方案，而是提供有关6LoWPAN路由设计的一般性、不分层的指导原则，以便进行进一步的分析和协议设计。本文件旨在作为与6LoWPANs相关的路由协议工作组的输入，如IETF ROLL WG。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6606.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6606.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Problem Statement ...............................................2
2. Terminology .....................................................5
3. Design Space ....................................................5
3.1. Reference Network Model ....................................6
4. Scenario Considerations and Parameters for 6LoWPAN Routing ......8
5. 6LoWPAN Routing Requirements ...................................13
5.1. Support of 6LoWPAN Device Properties ......................13
5.2. Support of 6LoWPAN Link Properties ........................15
5.3. Support of 6LoWPAN Characteristics ........................18
5.4. Support of Security .......................................22
5.5. Support of Mesh-Under Forwarding ..........................25
5.6. Support of Management .....................................26
6. Security Considerations ........................................27
7. Acknowledgments ................................................27
8. References .....................................................28
8.1. Normative References ......................................28
8.2. Informative References ....................................29
1. Problem Statement ...............................................2
2. Terminology .....................................................5
3. Design Space ....................................................5
3.1. Reference Network Model ....................................6
4. Scenario Considerations and Parameters for 6LoWPAN Routing ......8
5. 6LoWPAN Routing Requirements ...................................13
5.1. Support of 6LoWPAN Device Properties ......................13
5.2. Support of 6LoWPAN Link Properties ........................15
5.3. Support of 6LoWPAN Characteristics ........................18
5.4. Support of Security .......................................22
5.5. Support of Mesh-Under Forwarding ..........................25
5.6. Support of Management .....................................26
6. Security Considerations ........................................27
7. Acknowledgments ................................................27
8. References .....................................................28
8.1. Normative References ......................................28
8.2. Informative References ....................................29
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard [IEEE802.15.4]. Most of the LoWPAN devices are distinguished by their low bandwidth, short range, scarce memory capacity, limited processing capability, and other attributes of inexpensive hardware. The characteristics of nodes participating in LoWPANs are assumed to be those described in the 6LoWPAN problem statement [RFC4919], and in the IPv6 over IEEE 802.15.4 document [RFC4944], which has specified how to carry IPv6 packets over IEEE 802.15.4 and similar networks. Whereas IEEE 802.15.4 distinguishes two types of devices called full-function devices (FFDs) and reduced-function devices (RFDs), this distinction is based
6LoWPANs由与IEEE 802.15.4标准[IEEE802.15.4]兼容的设备构成。大多数低功耗设备的特点是带宽低、距离短、内存容量少、处理能力有限以及其他廉价硬件的特性。参与LoWPANs的节点的特征被假定为6LoWPAN问题陈述[RFC4919]和IPv6 over IEEE 802.15.4文档[RFC4944]中描述的特征，该文档规定了如何在IEEE 802.15.4和类似网络上承载IPv6数据包。尽管IEEE 802.15.4区分了两种类型的设备，即全功能设备（FFD）和简化功能设备（RFD），但这种区别是基于
on some features of the Medium Access Control (MAC) layer that are not always in use. Hence, the distinction is not made in this document. Nevertheless, some 6LoWPAN nodes may limit themselves to the role of hosts only, whereas other 6LoWPAN nodes may take part in routing. This host/ router distinction can correlate with the processing and storage capabilities of the device and power available in a similar way to the idea of RFDs and FFDs.
媒体访问控制（MAC）层的某些功能并不总是在使用。因此，本文件不作区分。然而，一些6LoWPAN节点可能仅限于主机角色，而其他6LoWPAN节点可能参与路由。这种主机/路由器的区别可以与设备的处理和存储能力以及可用电源相关联，其方式类似于RFD和FFD。
IEEE 802.15.4 networks support star and mesh topologies. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification ([RFC4944]) define how mesh topologies could be obtained and maintained. Thus, 6LoWPAN formation and multi-hop routing can be supported either below the IP layer (the adaptation layer or Logical Link Control (LLC)) or the IP layer. (Note that in the IETF, the term "routing" usually, but not always [RFC5556], refers exclusively to the formation of paths and the forwarding at the IP layer. In this document, we distinguish the layer at which these services are performed by the terms "route-over" and "mesh-under". See Sections 2 and 3.) A number of IP routing protocols have been developed in various IETF working groups. However, these existing routing protocols may not satisfy the requirements of multi-hop routing in 6LoWPANs, for the following reasons:
IEEE 802.15.4网络支持星形和网状拓扑。然而，IEEE 802.15.4标准和6LoWPAN格式规范（[RFC4944]）都没有定义如何获得和维护网状拓扑。因此，可以在IP层（适配层或逻辑链路控制（LLC））或IP层下支持6LoWPAN形成和多跳路由。（请注意，在IETF中，术语“路由”通常（但不总是[RFC5556]）仅指IP层的路径形成和转发。在本文档中，我们通过术语“路由覆盖”和“网格覆盖”来区分执行这些服务的层。参见第2节和第3节。）许多IP路由协议已经在各个IETF工作组中开发。然而，这些现有的路由协议可能无法满足6LoWPANs中多跳路由的要求，原因如下：
o 6LoWPAN nodes have special types and roles, such as nodes drawing their power from primary batteries, power-affluent nodes, mains-powered and high-performance gateways, data aggregators, etc. 6LoWPAN routing protocols should support multiple device types and roles.
o 6LoWPAN节点具有特殊的类型和角色，例如从主电池中提取能量的节点、功率充足的节点、主电源供电的高性能网关、数据聚合器等。6LoWPAN路由协议应支持多种设备类型和角色。
o More stringent requirements apply to LoWPANs, as opposed to higher-performance or non-battery-operated networks. 6LoWPAN nodes are characterized by small memory sizes and low processing power, and they run on very limited power supplied by primary non-rechargeable batteries (a few KB of RAM, a few dozen KB of ROM/ flash memory, and a few MHz of CPU is typical). A node's lifetime is usually defined by the lifetime of its battery.
o 与更高性能或非电池供电网络相比，LoWPANs需要更严格的要求。6LoWPAN节点的特点是内存大小小，处理能力低，并且它们运行在由主要非充电电池提供的非常有限的电源上（通常只有几KB的RAM、几十KB的ROM/闪存和几MHz的CPU）。节点的生存期通常由其电池的生存期来定义。
o Handling sleeping nodes is very critical in LoWPANs, more so than in traditional ad hoc networks. LoWPAN nodes might stay in sleep mode most of the time. Taking advantage of appropriate times for transmissions is important for efficient packet forwarding.
o 处理休眠节点在LoWPANs中非常关键，比传统的ad hoc网络更为关键。LoWPAN节点可能大部分时间处于睡眠模式。利用适当的传输时间对于高效的数据包转发非常重要。
o Routing in 6LoWPANs might possibly translate to a simpler problem than routing in higher-performance networks. LoWPANs might be either transit networks or stub networks. Under the assumption that LoWPANs are never transit networks (as implied by [RFC4944]),
o 6LoWPANs中的路由可能转化为比高性能网络中的路由更简单的问题。低端网络可能是公交网络或存根网络。假设LoWPANs从来都不是公交网络（如[RFC4944]所示），
routing protocols may be drastically simplified. This document will focus on the requirements for stub networks. Additional requirements may apply to transit networks.
路由协议可以大大简化。本文件将重点介绍存根网络的要求。其他要求可能适用于公交网络。
o Routing in LoWPANs might possibly translate to a harder problem than routing in higher-performance networks. Routing in LoWPANs requires power optimization, stable operation in lossy environments, etc. These requirements are not easily satisfiable all at once [ROLL-PROTOCOLS].
o 低性能网络中的路由可能会转化为比高性能网络中的路由更难的问题。LoWPANs中的路由需要功率优化、在有损环境中稳定运行等。这些要求不容易一次满足[ROLL-PROTOCOLS]。
These properties create new challenges for the design of routing within LoWPANs.
这些特性为低面板内的布线设计带来了新的挑战。
The 6LoWPAN problem statement [RFC4919] briefly mentions four requirements for routing protocols:
6LoWPAN问题陈述[RFC4919]简要介绍了路由协议的四个要求：
(a) low overhead on data packets
(a) 数据包的低开销
(b) low routing overhead
(b) 低路由开销
(c) minimal memory and computation requirements
(c) 最小内存和计算需求
(d) support for sleeping nodes (consideration of battery savings)
(d) 支持休眠节点（考虑电池节省）
These four high-level requirements describe the basic requirements for 6LoWPAN routing. Based on the fundamental features of 6LoWPANs, more detailed routing requirements, which can lead to further analysis and protocol design, are presented in this document.
这四个高级要求描述了6LoWPAN布线的基本要求。基于6LoWPANs的基本特性，本文给出了更详细的路由需求，可用于进一步的分析和协议设计。
Considering the problems above, detailed 6LoWPAN routing requirements must be defined. Application-specific features affect the design of 6LoWPAN routing requirements and corresponding solutions. However, various applications can be profiled by similar technical characteristics, although the related detailed requirements might differ (e.g., a few dozen nodes in a home lighting system need appropriate scalability for the system's applications, while millions of nodes for a highway infrastructure system also need appropriate scalability).
考虑到上述问题，必须定义详细的6LoWPAN布线要求。特定于应用程序的功能会影响6LoWPAN布线要求和相应解决方案的设计。然而，尽管相关的详细要求可能不同，但可以通过类似的技术特征分析各种应用（例如，家庭照明系统中的几十个节点需要系统应用的适当可伸缩性，而高速公路基础设施系统中的数百万个节点也需要适当的可伸缩性）。
This routing requirements document states the routing requirements of 6LoWPAN applications in general, providing examples for different cases of routing. It does not imply that a single routing solution will be favorable for all 6LoWPAN applications, and there is no requirement for different routing protocols to run simultaneously.
本布线要求文件概述了6LoWPAN应用的布线要求，并提供了不同布线情况的示例。这并不意味着单一的路由解决方案将有利于所有6LoWPAN应用程序，也不要求不同的路由协议同时运行。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
读者应熟悉“低功耗无线个人区域网络上的IPv6：概述、假设、问题陈述和目标”[RFC4919]和“通过IEEE 802.15.4网络传输IPv6数据包”[RFC4944]中讨论的所有术语和概念。
This specification makes use of the terminology defined in [6LoWPAN-ND].
本规范使用了[6LoWPAN ND]中定义的术语。
Apart from a wide variety of conceivable routing algorithms for 6LoWPANs, it is possible to perform routing in the IP layer (using a route-over approach) or below IP, as defined by the 6LoWPAN format document [RFC4944] (using the mesh-under approach). See Figure 1.
除了6LoWPAN的各种可想象的路由算法外，还可以在IP层（使用路由覆盖方法）或IP以下执行路由，如6LoWPAN格式文档[RFC4944]所定义（使用网格覆盖方法）。参见图1。
The route-over approach relies on IP routing and therefore supports routing over possibly various types of interconnected links. Note: The ROLL WG is now working on route-over approaches for Low-power and Lossy Networks (LLNs), not specifically for 6LoWPANs. This document focuses on 6LoWPAN-specific requirements; it may be used in conjunction with the more application-oriented requirements defined by the ROLL WG.
路由方式依赖于IP路由，因此支持通过可能不同类型的互连链路进行路由。注：滚动工作组目前正在研究低功率和有损网络（LLN）的路由覆盖方法，而不是专门针对6LoWPANs。本文件重点介绍6LoWPAN的具体要求；它可以与ROLL WG定义的更面向应用的需求结合使用。
The mesh-under approach performs the multi-hop communication below the IP link. The most significant consequence of the mesh-under mechanism is that the characteristics of IEEE 802.15.4 directly affect the 6LoWPAN routing mechanisms, including the use of 64-bit (or 16-bit short) link-layer addresses instead of IP addresses. A 6LoWPAN would therefore be seen as a single IP link.
该方法在IP链路下执行多跳通信。mesh-under机制最重要的结果是IEEE 802.15.4的特性直接影响6LoWPAN路由机制，包括使用64位（或16位短）链路层地址而不是IP地址。因此，6LoWPAN将被视为单个IP链路。
Most statements in this document consider both the route-over and mesh-under cases.
本文档中的大多数语句都考虑了在案例中的遍历和网格。
Figure 1 shows the place of 6LoWPAN routing in the entire network stack.
图1显示了6LoWPAN路由在整个网络堆栈中的位置。
+---------------------------+ +-----------------------------+
| Application Layer | | Application Layer |
+---------------------------+ +-----------------------------+
| Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) |
+---------------------------+ +-----------------------------+
| Network Layer (IPv6) | | Network +---------+ |
+---------------------------+ | Layer | Routing | |
| 6LoWPAN | | (IPv6) +---------+ |
| Adaptation | +-----------------------------+
| Layer +----------+ | | 6LoWPAN Adaptation Layer |
+--------------| Routing* |-+ +-----------------------------+
| 802.15.4 MAC +----------+ | | 802.15.4 MAC |
+---------------------------+ +-----------------------------+
| 802.15.4 PHY | | 802.15.4 PHY |
+---------------------------+ +-----------------------------+
* Here, "Routing" is not equivalent to IP routing,
but includes the functionalities of path computation and
forwarding under the IP layer.
The term "Routing" is used in the figure in order to
illustrate which layer handles path computation and
packet forwarding in mesh-under as compared to route-over.
+---------------------------+ +-----------------------------+
| Application Layer | | Application Layer |
+---------------------------+ +-----------------------------+
| Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) |
+---------------------------+ +-----------------------------+
| Network Layer (IPv6) | | Network +---------+ |
+---------------------------+ | Layer | Routing | |
| 6LoWPAN | | (IPv6) +---------+ |
| Adaptation | +-----------------------------+
| Layer +----------+ | | 6LoWPAN Adaptation Layer |
+--------------| Routing* |-+ +-----------------------------+
| 802.15.4 MAC +----------+ | | 802.15.4 MAC |
+---------------------------+ +-----------------------------+
| 802.15.4 PHY | | 802.15.4 PHY |
+---------------------------+ +-----------------------------+
* Here, "Routing" is not equivalent to IP routing,
but includes the functionalities of path computation and
forwarding under the IP layer.
The term "Routing" is used in the figure in order to
illustrate which layer handles path computation and
packet forwarding in mesh-under as compared to route-over.
Figure 1: Mesh-Under Routing (Left) and Route-Over Routing (Right)
图1：布线下的网格（左）和布线上的网格（右）
In order to avoid packet fragmentation and the overhead for reassembly, routing packets should fit into a single IEEE 802.15.4 physical frame, and application data should not be expanded to an extent that they no longer fit.
为了避免数据包碎片和重新组装的开销，路由数据包应适合单个IEEE 802.15.4物理帧，并且应用程序数据不应扩展到不再适合的程度。
For multi-hop communication in 6LoWPANs, when a route-over mechanism is in use, all routers (i.e., 6LoWPAN Border Routers (6LBRs) and 6LoWPAN Routers (6LRs)) perform IP routing within the stub network (see Figure 2). In this case, the link-local scope covers the set of nodes within symmetric radio range of a node.
对于6LoWPANs中的多跳通信，当使用路由切换机制时，所有路由器（即6LoWPAN边界路由器（6LBR）和6LoWPAN路由器（6LR））在存根网络内执行IP路由（见图2）。在这种情况下，链路本地作用域覆盖节点的对称无线电范围内的节点集。
When a LoWPAN follows the mesh-under configuration, the 6LBR is the only IPv6 router in the LoWPAN (see Figure 3). This means that the IPv6 link-local scope includes all nodes in the LoWPAN. For this, a mesh-under mechanism MUST be provided to support multi-hop transmission.
当LoWPAN跟随配置下的mesh时，6LBR是LoWPAN中唯一的IPv6路由器（见图3）。这意味着IPv6链路本地作用域包括LoWPAN中的所有节点。为此，必须提供mesh-under机制以支持多跳传输。
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR -- 6LR --- 6LR --- h 6LR: 6LoWPAN Router
/ \ h: Host
h 6LR --- h
|
/ \
6LR - 6LR -- h
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR -- 6LR --- 6LR --- h 6LR: 6LoWPAN Router
/ \ h: Host
h 6LR --- h
|
/ \
6LR - 6LR -- h
Figure 2: An Example of a Route-Over LoWPAN
图2:LoWPAN上的路线示例
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR --- m --- m --- h m: mesh-under forwarder
/ \ h: Host
h m --- h
|
/ \
m - m -- h
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR --- m --- m --- h m: mesh-under forwarder
/ \ h: Host
h m --- h
|
/ \
m - m -- h
Figure 3: An Example of a Mesh-Under LoWPAN
图3:LoWPAN下的网格示例
Note than in both mesh-under and route-over networks, there is no expectation of topologically based address assignment in the 6LoWPAN. Instead, addresses are typically assigned based on the EUI-64 addresses assigned at manufacturing time to nodes, or based on a (from a topological point of view) more or less random process assigning 16-bit MAC addresses to individual nodes. Within a 6LoWPAN, there is therefore no opportunity for aggregation or summarization of IPv6 addresses beyond the sharing of (one or more) common prefixes.
注意：与网络下的网状和网络上的路由相比，6LoWPAN中不需要基于拓扑的地址分配。相反，地址通常基于在制造时分配给节点的EUI-64地址，或基于（从拓扑角度看）或多或少地随机过程分配给单个节点的16位MAC地址来分配。因此，在6LoWPAN中，除了共享（一个或多个）公共前缀之外，没有机会聚合或汇总IPv6地址。
Not all devices that are within radio range of each other need to be part of the same LoWPAN. When multiple LoWPANs are formed with globally unique IPv6 addresses in the 6LoWPANs, and device (a) of LoWPAN [A] wants to communicate with device (b) of LoWPAN [B], the normal IPv6 mechanisms will be employed. For route-over, the IPv6 address of (b) is set as the destination of the packets, and the devices perform IP routing to the 6LBR for these outgoing packets. For mesh-under, there is one IP hop from device (a) to the 6LBR of [A], no matter how many radio hops they are apart from each other. This, of course, assumes the existence of a mesh-under routing protocol in order to reach the 6LBR. Note that a default route to the 6LBR could be inserted into the 6LoWPAN routing system for both route-over and mesh-under.
并非所有在彼此无线电范围内的设备都需要是同一低量程的一部分。当多个LoWPAN在6个LoWPAN中使用全局唯一的IPv6地址形成时，LoWPAN[a]的设备（a）希望与LoWPAN[b]的设备（b）通信，将采用正常的IPv6机制。对于route over，IPv6地址（b）被设置为数据包的目的地，设备为这些传出数据包执行到6LBR的IP路由。对于下的mesh，从设备（a）到[a]的6LBR有一个IP跃点，无论它们彼此之间有多少个无线电跃点。当然，这假设在路由协议下存在网状网，以达到6LBR。请注意，可以将到6LBR的默认路线插入6LoWPAN路线系统，用于路线上方和网格下方。
IP-based LoWPAN technology is still in its early stage of development, but the range of conceivable usage scenarios is tremendous. The numerous possible applications of sensor networks make it obvious that mesh topologies will be prevalent in LoWPAN environments and robust routing will be a necessity for expedient communication. Research efforts in the area of sensor networking have put forth a large variety of multi-hop routing algorithms [Bulusu]. Most related work focuses on optimizing routing for specific application scenarios, which can be realized using several modes of communication, including the following [Watteyne]:
基于IP的LoWPAN技术仍处于开发的早期阶段，但可想象的使用场景范围非常广泛。传感器网络的众多可能应用表明，网状拓扑结构在低泛度环境中将非常普遍，而可靠的路由对于方便的通信来说是必不可少的。传感器网络领域的研究工作已经提出了各种各样的多跳路由算法[Bulusu]。大多数相关工作侧重于优化特定应用场景的路由，这可以使用多种通信模式实现，包括以下[Watteyne]：
o Flooding (in very small networks)
o 泛洪（在非常小的网络中）
o Hierarchical routing
o 分层路由
o Geographic routing
o 地理路由
o Self-organizing coordinate routing
o 自组织坐标布线
Depending on the topology of a LoWPAN and the application(s) running over it, different types of routing may be used. However, this document abstracts from application-specific communication and describes general routing requirements valid for overall routing in LoWPANs.
根据LoWPAN的拓扑和在其上运行的应用程序，可以使用不同类型的路由。然而，本文档从特定于应用程序的通信中抽象出来，并描述了对LoWPANs中的总体路由有效的一般路由要求。
The following parameters can be used to describe specific scenarios in which the candidate routing protocols could be evaluated.
以下参数可用于描述评估候选路由协议的特定场景。
a. Network Properties:
a. 网络属性：
* Number of Devices, Density, and Network Diameter: These parameters usually affect the routing state directly (e.g., the number of entries in a routing table or neighbor list). Especially in large and dense networks, policies must be applied for discarding "low-quality" and stale routing entries in order to prevent memory overflow.
* 设备数量、密度和网络直径：这些参数通常直接影响路由状态（例如，路由表或邻居列表中的条目数）。特别是在大型密集网络中，必须应用策略来丢弃“低质量”和过时的路由条目，以防止内存溢出。
* Connectivity: Due to external factors or programmed disconnections, a LoWPAN can be in several states of connectivity -- anything in the range from "always connected" to "rarely connected". This poses great challenges to the dynamic discovery of routes across a LoWPAN.
* 连接性：由于外部因素或编程断开，LoWPAN可能处于几种连接性状态——从“始终连接”到“很少连接”的任何状态。这对跨越低跨度的路线的动态发现提出了巨大挑战。
* Dynamicity (including mobility): Location changes can be induced by unpredictable external factors or by controlled motion, which may in turn cause route changes. Also, nodes may dynamically be introduced into a LoWPAN and removed from it later. The routing state and the volume of control messages may heavily depend on the number of moving nodes in a LoWPAN and their speed, as well as how quickly and frequently environmental characteristics influencing radio propagation change.
* 动态性（包括机动性）：位置变化可能由不可预测的外部因素或受控运动引起，这反过来可能导致路线变化。此外，节点可以动态地引入LoWPAN并在以后从中移除。路由状态和控制消息的数量在很大程度上取决于低范围内移动节点的数量及其速度，以及影响无线传播的环境特征变化的速度和频率。
* Deployment: In a LoWPAN, it is possible for nodes to be scattered randomly or to be deployed in an organized manner. The deployment can occur at once, or as an iterative process, which may also affect the routing state.
* 部署：在低范围内，节点可以随机分散或以有组织的方式部署。部署可以立即进行，也可以作为迭代过程进行，这也可能会影响路由状态。
* Spatial Distribution of Nodes and Gateways: Network connectivity depends on the spatial distribution of the nodes and on other factors, such as device number, density, and transmission range. For instance, nodes can be placed on a grid, or randomly located in an area (as can be modeled by a two-dimensional Poisson distribution), etc. Assuming a random spatial distribution, an average of 7 neighbors per node are required for approximately 95% network connectivity (10 neighbors per node are needed for 99% connectivity) [Kuhn]. In addition, if the LoWPAN is connected to other networks through infrastructure nodes called gateways, the number and spatial distribution of these gateways affect network congestion and available data rate, among other things.
* 节点和网关的空间分布：网络连通性取决于节点的空间分布以及其他因素，如设备数量、密度和传输范围。例如，节点可以放置在网格上，也可以随机放置在区域中（可以用二维泊松分布建模），等等。假设随机空间分布，大约95%的网络连接平均需要每个节点7个邻居（99%的连接需要每个节点10个邻居）[Kuhn]。此外，如果LoWPAN通过称为网关的基础设施节点连接到其他网络，则这些网关的数量和空间分布会影响网络拥塞和可用数据速率等。
* Traffic Patterns, Topology, and Applications: The design of a LoWPAN and the requirements for its application have a big impact on the network topology and the most efficient routing type to be used. For different traffic patterns (point-to-point, multipoint-to-point, point-to-multipoint) and network architectures, various routing mechanisms have been developed, such as data-centric, event-driven, address-centric, and geographic routing.
* 流量模式、拓扑结构和应用程序：LoWPAN的设计及其应用程序的要求对网络拓扑结构和要使用的最有效路由类型有很大影响。对于不同的流量模式（点对点、多点对点、点对多点）和网络架构，已经开发了各种路由机制，例如以数据为中心、事件驱动、以地址为中心和地理路由。
* Classes of Service: For mixing applications of different criticality on one LoWPAN, support of multiple classes of service may be required in resource-constrained LoWPANs and may require a new routing protocol functionality.
* 服务类别：对于在一个LoWPAN上混合不同关键性的应用程序，在资源受限的LoWPAN中可能需要支持多个服务类别，并且可能需要新的路由协议功能。
* Security: LoWPANs may carry sensitive information and require a high level of security support where the availability, integrity, and confidentiality of data are of prime relevance. Secured messages cause overhead and affect the power consumption of LoWPAN routing protocols.
* 安全性：LoWPANs可能携带敏感信息，并且在数据的可用性、完整性和机密性至关重要的情况下，需要高级别的安全支持。安全消息会导致开销，并影响低泛路由协议的功耗。
b. Node Parameters:
b. 节点参数：
* Processing Speed and Memory Size: These basic parameters define the maximum size of the routing state and the maximum complexity of its processing. LoWPAN nodes may have different performance characteristics, queuing strategies, and queue buffer sizes.
* 处理速度和内存大小：这些基本参数定义路由状态的最大大小及其处理的最大复杂性。LoWPAN节点可能具有不同的性能特征、排队策略和队列缓冲区大小。
* Power Consumption and Power Source: The number of battery- and mains-powered nodes and their positions in the topology created by them in a LoWPAN affect routing protocols in their selection of paths that optimize network lifetime.
* 功耗和电源：电池和电源供电节点的数量及其在拓扑中的位置以较低的范围影响路由协议选择路径，从而优化网络寿命。
* Transmission Range: This parameter affects routing. For example, a high transmission range may cause a dense network, which in turn results in more direct neighbors of a node, higher connectivity, and a larger routing state.
* 传输范围：此参数影响路由。例如，高传输范围可能导致密集网络，这反过来导致节点的更直接邻居、更高的连接性和更大的路由状态。
* Traffic Pattern: This parameter affects routing, since highly loaded nodes (either because they are the source of packets to be transmitted or due to forwarding) may contribute to higher delivery delays and may consume more energy than lightly loaded nodes. This applies to both data packets and routing control messages.
* 流量模式：此参数影响路由，因为高负载节点（因为它们是要传输的数据包的来源或由于转发）可能导致更高的传递延迟，并且可能比低负载节点消耗更多的能量。这适用于数据包和路由控制消息。
c. Link Parameters: This section discusses link parameters that apply to IEEE 802.15.4 legacy mode (i.e., not making use of improved modulation schemes).
c. 链路参数：本节讨论适用于IEEE 802.15.4传统模式的链路参数（即，不使用改进的调制方案）。
* Throughput: The maximum user data throughput of a bulk data transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows [Latre]:
* 吞吐量：在理想条件下，通过非时隙IEEE 802.15.4 2.4 GHz信道在单个发送方和单个接收方之间进行批量数据传输的最大用户数据吞吐量如下[Latre]：
+ 16-bit MAC addresses, unreliable mode: 151.6 kbit/s
+ 16-bit MAC addresses, unreliable mode: 151.6 kbit/s
+ 16-bit MAC addresses, reliable mode: 139.0 kbit/s
+ 16-bit MAC addresses, reliable mode: 139.0 kbit/s
+ 64-bit MAC addresses, unreliable mode: 135.6 kbit/s
+ 64-bit MAC addresses, unreliable mode: 135.6 kbit/s
+ 64-bit MAC addresses, reliable mode: 124.4 kbit/s
+ 64-bit MAC addresses, reliable mode: 124.4 kbit/s
Throughput for the 915 MHz band is as follows:
915 MHz频段的吞吐量如下所示：
+ 16-bit MAC addresses, unreliable mode: 31.1 kbit/s
+ 16-bit MAC addresses, unreliable mode: 31.1 kbit/s
+ 16-bit MAC addresses, reliable mode: 28.6 kbit/s
+ 16-bit MAC addresses, reliable mode: 28.6 kbit/s
+ 64-bit MAC addresses, unreliable mode: 27.8 kbit/s
+ 64-bit MAC addresses, unreliable mode: 27.8 kbit/s
+ 64-bit MAC addresses, reliable mode: 25.6 kbit/s
+ 64-bit MAC addresses, reliable mode: 25.6 kbit/s
Throughput for the 868 MHz band is as follows:
868 MHz频段的吞吐量如下所示：
+ 16-bit MAC addresses, unreliable mode: 15.5 kbit/s
+ 16-bit MAC addresses, unreliable mode: 15.5 kbit/s
+ 16-bit MAC addresses, reliable mode: 14.3 kbit/s
+ 16-bit MAC addresses, reliable mode: 14.3 kbit/s
+ 64-bit MAC addresses, unreliable mode: 13.9 kbit/s
+ 64-bit MAC addresses, unreliable mode: 13.9 kbit/s
+ 64-bit MAC addresses, reliable mode: 12.8 kbit/s
+ 64-bit MAC addresses, reliable mode: 12.8 kbit/s
* Latency: Latency ranges -- depending on payload size -- of a frame transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions are as shown below [Latre]. For unreliable mode, the actual latency is provided. For reliable mode, the round-trip time, including transmission of a Layer-2 acknowledgment, is provided:
* 延迟：在理想条件下，单个发送方和单个接收方之间通过未开槽IEEE 802.15.4 2.4 GHz信道的帧传输的延迟范围（取决于有效负载大小）如下所示[Latre]。对于不可靠模式，将提供实际延迟。对于可靠模式，提供往返时间，包括传输第2层确认：
+ 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms]
+ 16位MAC地址，不可靠模式：[1.92毫秒，6.02毫秒]
+ 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms]
+ 16位MAC地址，可靠模式：[2.46毫秒，6.56毫秒]
+ 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms]
+ 64位MAC地址，不可靠模式：[2.75毫秒，6.02毫秒]
+ 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms]
+ 64位MAC地址，可靠模式：[3.30毫秒，6.56毫秒]
Latency ranges for the 915 MHz band are as follows:
915 MHz频段的延迟范围如下所示：
+ 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms]
+ 16位MAC地址，不可靠模式：[5.85毫秒，29.35毫秒]
+ 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms]
+ 16位MAC地址，可靠模式：[8.35毫秒，31.85毫秒]
+ 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms]
+ 64位MAC地址，不可靠模式：[8.95毫秒，29.35毫秒]
+ 64-bit MAC addresses, reliable mode: [11.45 ms, 31.82 ms]
+ 64位MAC地址，可靠模式：[11.45毫秒，31.82毫秒]
Latency ranges for the 868 MHz band are as follows:
868 MHz频段的延迟范围如下：
+ 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms]
+ 16位MAC地址，不可靠模式：[11.7毫秒，58.7毫秒]
+ 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms]
+ 16位MAC地址，可靠模式：[16.7毫秒，63.7毫秒]
+ 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms]
+ 64位MAC地址，不可靠模式：[17.9毫秒，58.7毫秒]
+ 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms]
+ 64位MAC地址，可靠模式：[22.9毫秒，63.7毫秒]
Note that some of the parameters presented in this section may be used as link or node evaluation metrics. However, multi-criteria routing may be too expensive for 6LoWPAN nodes. Rather, various single-criteria metrics are available and can be selected to suit the environment or application.
请注意，本节中提供的一些参数可用作链路或节点评估指标。但是，对于6LoWPAN节点而言，多标准路由可能过于昂贵。相反，各种单一标准度量是可用的，并且可以根据环境或应用程序进行选择。
This section defines a list of requirements for 6LoWPAN routing. An important design property specific to low-power networks is that LoWPANs have to support multiple device types and roles, such as
本节定义了6LoWPAN布线的要求列表。低功耗网络特有的一个重要设计特性是低功耗网络必须支持多种设备类型和角色，例如
o host nodes drawing their power from primary batteries or using energy harvesting (sometimes called "power-constrained nodes")
o 主机节点从主电池获取电力或使用能量收集（有时称为“功率受限节点”）
o mains-powered host nodes (an example of what we call "power-affluent nodes")
o 主电源供电的主机节点（我们称之为“电源充足节点”的示例）
o power-affluent (but not necessarily mains-powered) high-performance gateway(s)
o 功率充足（但不一定由电源供电）的高性能网关
o nodes with various functionality (data aggregators, relays, local manager/coordinators, etc.)
o 具有各种功能的节点（数据聚合器、中继、本地管理器/协调器等）
Due to these different device types and roles, LoWPANs need to consider the following two primary attributes:
由于这些不同的设备类型和角色，LoWPAN需要考虑以下两个主要属性：
o Power conservation: some devices are mains-powered, but many are battery-operated and need to last several months to a few years with a single AA battery. Many devices are mains-powered most of the time but still need to function on batteries for possibly extended periods (e.g., on a construction site before building power is switched on for the first time).
o 节能：有些设备是由电源供电的，但许多设备是由电池供电的，使用一节AA电池需要使用几个月到几年。许多设备大部分时间由电源供电，但仍需要使用电池长时间工作（例如，在首次打开建筑电源之前的施工现场）。
o Low performance: tiny devices, small memory sizes, low-performance processors, low bandwidth, high loss rates, etc.
o 低性能：小型设备、小内存、低性能处理器、低带宽、高丢失率等。
These fundamental attributes of LoWPANs affect the design of routing solutions. Whether existing routing specifications are simplified and modified, or new solutions are introduced in order to fit the low-power requirements of LoWPANs, they need to meet the requirements described below.
LoWPANs的这些基本属性影响路由解决方案的设计。无论是简化和修改现有的布线规范，还是引入新的解决方案以满足LoWPANs的低功耗要求，它们都需要满足下述要求。
The general objectives listed in this section should be met by 6LoWPAN routing protocols. The importance of each requirement is dependent on what node type the protocol is running on and what the role of the node is. The following requirements consider the presence of battery-powered nodes in LoWPANs.
6LoWPAN路由协议应满足本节列出的一般目标。每个需求的重要性取决于协议运行的节点类型和节点的角色。以下要求考虑LoWPANs电池供电节点的存在。
[R01] 6LoWPAN routing protocols SHOULD allow implementation with small code size and require low routing state to fit the typical 6LoWPAN node capacity. Generally speaking, the code size is bounded by available flash memory size, and the routing table is bounded by RAM size, possibly limiting it to less than 32 entries.
[R01]6LoWPAN路由协议应允许以较小的代码大小实现，并要求较低的路由状态以适应典型的6LoWPAN节点容量。一般来说，代码大小受可用闪存大小的限制，路由表受RAM大小的限制，可能限制在32个条目以下。
The RAM size of LoWPAN nodes often ranges between 4 KB and 10 KB (2 KB minimum), and program flash memory normally consists of 48 KB to 128 KB. (For example, in the current market, MICAz has 128 KB program flash, 4 KB EEPROM, and 512 KB external flash ROM; TIP700CM has 48 KB program flash, 10 KB RAM, and 1 MB external flash ROM.)
LoWPAN节点的RAM大小通常在4 KB到10 KB之间（最小2 KB），程序闪存通常由48 KB到128 KB组成。（例如，在当前市场上，MICAz有128 KB程序闪存、4 KB EEPROM和512 KB外部闪存ROM；TIP700CM有48 KB程序闪存、10 KB RAM和1 MB外部闪存ROM。）
Due to these hardware restrictions, code SHOULD fit within a small memory size -- no more than 48 KB to 128 KB of flash memory, including at least a few tens of KB of application code size. (As a general observation, a routing protocol of low complexity may help achieve the goal of reducing power consumption, improves robustness, requires lower routing state, is easier to analyze, and may be less prone to security attacks.)
由于这些硬件限制，代码应该适合较小的内存大小——不超过48 KB到128 KB的闪存，包括至少几十KB的应用程序代码大小。（一般来说，低复杂度的路由协议可能有助于实现降低功耗、提高鲁棒性、要求较低的路由状态、更易于分析以及不易受到安全攻击的目标。）
In addition, operation with limited amounts of routing state (such as routing tables and neighbor lists) SHOULD be maintained, since some typical memory sizes preclude storing state of a large number of nodes. For instance, industrial monitoring applications may need to support a maximum of 20 hops [RFC5673]. Small networks can be designed to support a smaller number of hops. While the need for this is highly dependent on the network architecture, there should be at least one mode of operation that can function with 32 forwarding entries or less.
此外，由于一些典型的内存大小排除了存储大量节点的状态，因此应保持具有有限数量路由状态（例如路由表和邻居列表）的操作。例如，工业监控应用程序可能需要支持最多20跳[RFC5673]。小型网络可以设计为支持较少的跳数。虽然这种需求高度依赖于网络体系结构，但至少应该有一种操作模式可以在32个或更少的转发条目下运行。
[R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by efficiently using control packets (e.g., minimizing expensive IP multicast, which causes link broadcast to the entire LoWPAN) and by efficiently routing data packets.
[R02]6LoWPAN路由协议应通过有效地使用控制数据包（例如，最小化昂贵的IP多播，这会导致链路广播到整个LoWPAN）和有效地路由数据包来实现最低功耗。
One way of optimizing battery lifetime is by achieving a minimal control message overhead. Compared to such functions as computational operations or taking sensor samples, radio communication is by far the dominant factor of power consumption [Doherty]. Power consumption of transmission and/or reception depends linearly on the length of data units and on the frequency of transmission and reception of the data units [Shih].
优化电池寿命的一种方法是实现最小的控制消息开销。与计算操作或采集传感器样本等功能相比，无线通信是功耗的主要因素[Doherty]。传输和/或接收的功耗线性地取决于数据单元的长度以及数据单元的传输和接收频率[Shih]。
The energy consumption of two example radio frequency (RF) controllers for low-power nodes is shown in [Hill]. The TR1000 radio consumes 21 mW when transmitting at 0.75 mW, and 15 mW during reception (with a receiver sensitivity of -85 dBm). The
用于低功率节点的两个示例射频（RF）控制器的能量消耗如[Hill]所示。TR1000无线电在0.75兆瓦的发射功率下消耗21兆瓦，在接收功率下消耗15兆瓦（接收器灵敏度为-85 dBm）。这个
CC1000 consumes 31.6 mW when transmitting at 0.75 mW, and 20 mW during reception (with a receiver sensitivity of -105 dBm). Power endurance under the concept of an idealized power source is explained in [Hill]. Based on the energy of an idealized AA battery, the CC1000 can transmit for approximately 4 days straight or receive for 9 consecutive days. Note that availability for reception consumes power as well.
CC1000在0.75 mW的发射功率下消耗31.6 mW，在接收功率下消耗20 mW（接收器灵敏度为-105 dBm）。理想电源概念下的功率耐久性在[Hill]中进行了解释。基于理想AA电池的能量，CC1000可连续发射约4天或连续接收9天。请注意，接收的可用性也会消耗电力。
As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing protocol SHOULD minimize the control cost by multicasting routing packets.
由于多播可能会导致LoWPAN中的泛洪，6LoWPAN路由协议应该通过多播路由数据包来最小化控制成本。
Control cost of routing protocols in low-power and lossy networks is discussed in more detail in [ROLL-PROTOCOLS].
低功耗和有损网络中路由协议的控制成本在[ROLL-protocols]中有更详细的讨论。
6LoWPAN links have the characteristics of low data rate and possibly high loss rates. The routing requirements described in this section are derived from the link properties.
6LoWPAN链路具有低数据速率和可能高丢失率的特点。本节中描述的路由要求源自链路属性。
[R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a single IEEE 802.15.4 frame size, in order to avoid packet fragmentation and the overhead for reassembly.
[R03]6LoWPAN路由协议控制消息不应超过单个IEEE 802.15.4帧大小，以避免数据包碎片和重新组装的开销。
In order to save energy, routing overhead should be minimized to prevent fragmentation of frames. Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE 802.15.4 frame size. This reduces the energy required for transmission, avoids unnecessary waste of bandwidth, and prevents the need for packet reassembly. The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding about 80 octets of actual MAC payload with security enabled, some of which is taken for the (typically compressed) IP header [RFC6282]. Avoiding fragmentation at the adaptation layer may imply the use of semantic fragmentation and/or algorithms that can work on small increments of routing information.
为了节省能源，应尽量减少路由开销，以防止帧碎片。因此，6LoWPAN路由不应导致数据包超过IEEE 802.15.4帧大小。这减少了传输所需的能量，避免了不必要的带宽浪费，并防止了分组重组的需要。[IEEE802.15.4]标准规定了127字节的MTU，在启用安全性的情况下产生大约80个八位字节的实际MAC负载，其中一些用于（通常压缩的）IP报头[RFC6282]。在适配层避免分段可能意味着使用语义分段和/或算法，这些算法可以处理路由信息的小增量。
[R04] The design of routing protocols for LoWPANs must consider the fact that packets are to be delivered with sufficient probability according to application requirements.
[R04] LoopPANS的路由协议的设计必须考虑到根据应用需求，数据包要以足够的概率递送的事实。
Requirements for a successful end-to-end packet delivery ratio (where delivery may be bounded within certain latency levels) vary, depending on the application. In industrial applications, some non-critical monitoring applications may tolerate a successful delivery ratio of less than 90% with hours of latency;
成功的端到端数据包交付比率（交付可能限制在某些延迟级别内）的要求因应用程序而异。在工业应用中，一些非关键的监控应用程序可以容忍小于90%的成功交付率和数小时的延迟；
in some other cases, a delivery ratio of 99.9% is required [RFC5673]. In building automation applications, application-layer errors must be below 0.01% [RFC5867].
在其他一些情况下，需要99.9%的交付率[RFC5673]。在楼宇自动化应用中，应用层错误必须低于0.01%[RFC5867]。
Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh depends on the quality of the path selected by the routing protocol and on the ability of the routing protocol to cope with short-term and long-term quality variation. The metric of the routing protocol strongly influences performance of the routing protocol in terms of delivery ratio.
在IEEE 802.15.4网状网中成功地端到端传送数据包取决于路由协议选择的路径的质量以及路由协议处理短期和长期质量变化的能力。路由协议的度量在传递率方面强烈影响路由协议的性能。
The quality of a given path depends on the individual qualities of the links (including the devices) that compose that path. IEEE 802.15.4 settings affect the quality perceived at upper layers. In particular, in IEEE 802.15.4 reliable mode, if an acknowledgment frame is not received after a given period, the originator retries frame transmission up to a maximum number of times. If an acknowledgment frame is still not received by the sender after performing the maximum number of transmission attempts, the MAC layer assumes that the transmission has failed and notifies the next higher layer of the failure. Note that excessive retransmissions may be detrimental; see RFC 3819 [RFC3819].
给定路径的质量取决于构成该路径的链路（包括设备）的各个质量。IEEE 802.15.4设置会影响上层感知的质量。特别是，在IEEE 802.15.4可靠模式中，如果在给定时间段后未接收到确认帧，则发起者重试帧传输的次数最多可达最大次数。如果在执行最大数量的传输尝试后，发送方仍未收到确认帧，则MAC层假定传输失败，并将失败通知下一个更高的层。注意，过多的重传可能是有害的；参见RFC 3819[RFC3819]。
[R05] The design of routing protocols for LoWPANs must consider the latency requirements of applications and IEEE 802.15.4 link latency characteristics.
[R05]低端路由协议的设计必须考虑应用的延迟要求和IEEE 802.15.4链路延迟特性。
Latency requirements may differ -- e.g., from a few hundred milliseconds to minutes -- depending on the type of application. Real-time building automation applications usually need response times below 500 ms between egress and ingress, while forced-entry security alerts must be routed to one or more fixed or mobile user devices within 5 seconds [RFC5867]. Non-critical closed-loop applications for industrial automation have latency requirements that can be as low as 100 ms, but many control loops are tolerant of latencies above 1 s [RFC5673]. In contrast, urban monitoring applications allow latencies smaller than the typical intervals used for reporting sensed information -- for instance, on the order of seconds to minutes [RFC5548].
根据应用程序的类型，延迟要求可能有所不同，例如从几百毫秒到几分钟不等。实时楼宇自动化应用程序通常需要在进出之间的响应时间低于500 ms，而强制进入安全警报必须在5秒内发送到一个或多个固定或移动用户设备[RFC5867]。工业自动化的非关键闭环应用对延迟的要求可低至100ms，但许多控制回路对1s以上的延迟具有耐受性[RFC5673]。相比之下，城市监控应用程序允许的延迟小于用于报告感测信息的典型间隔，例如秒到分钟[RFC5548]。
The range of latencies of a frame transmission between a single sender and a single receiver through an ideal unslotted IEEE 802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms with 64-bit MAC addresses in unreliable mode, and between 2.20 ms and 6.56 ms with 64-bit MAC addresses in reliable mode. The range of latencies of the 868 MHz band is from 11.7 ms to 63.7 ms, depending on the address type and mode used (reliable or
通过理想的非时隙IEEE 802.15.4 2.4 GHz信道，单个发送器和单个接收器之间的帧传输的延迟范围在64位MAC地址处于不可靠模式时介于2.46 ms和6.02 ms之间，在64位MAC地址处于可靠模式时介于2.20 ms和6.56 ms之间。868 MHz频段的延迟范围为11.7 ms至63.7 ms，具体取决于所使用的地址类型和模式（可靠或不可靠）
unreliable). Note that the latencies may be larger than that, depending on channel load, the MAC-layer settings, and the choice of reliable or unreliable mode. Note that MAC approaches other than legacy 802.15.4 may be used (e.g., TDMA). Duty cycling may further affect latency (see [R08]). Depending on the routing path chosen and the network diameter, multiple hops may contribute to the end-to-end latency that an application may experience.
不可靠）。注意，延迟可能大于该值，这取决于信道负载、MAC层设置以及可靠或不可靠模式的选择。注意，可以使用传统802.15.4以外的MAC方法（例如，TDMA）。工作循环可能进一步影响延迟（参见[R08]）。根据选择的路由路径和网络直径，多跳可能会导致应用程序可能经历的端到端延迟。
Note that a tradeoff exists between [R05] and [R04].
注意，[R05]和[R04]之间存在折衷。
[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss caused by link failure or device unavailability either in the short term (approx. 30 ms) -- due to Received Signal Strength Indication (RSSI) variation, interference variation, noise, and asynchrony -- or in the long term, due to a depleted power source, hardware breakdown, operating system misbehavior, etc.
[R06]6LoWPAN路由协议应能在短期（约30 ms）内（由于接收信号强度指示（RSSI）变化、干扰变化、噪声和异步）或长期（由于电源耗尽、硬件故障、，操作系统错误行为等。
An important trait of 6LoWPAN devices is their unreliability, which can be due to limited system capabilities and possibly being closely coupled to the physical world with all its unpredictable variations. In harsh environments, LoWPANs easily suffer from link failure. Collisions or link failures easily increase send and receive queues and can lead to queue overflow and packet losses.
6LoWPAN设备的一个重要特点是其不可靠性，这可能是由于系统能力有限，并且可能与物理世界及其所有不可预测的变化紧密耦合。在恶劣的环境中，低端盘容易遭受链路故障。冲突或链路故障很容易增加发送和接收队列，并可能导致队列溢出和数据包丢失。
For home applications, where users expect feedback after carrying out certain actions (such as handling a remote control while moving around), routing protocols must converge within 2 seconds if the destination node of the packet has moved and must converge within 0.5 seconds if only the sender has moved [RFC5826]. The tolerance of the recovery time can vary, depending on the application; however, the routing protocol must provide the detection of short-term unavailability and long-term disappearance. The routing protocol has to exploit network resources (e.g., path redundancy) to offer good network behavior despite node failure.
对于家庭应用程序，如果用户在执行某些操作（例如移动时处理遥控器）后需要反馈，则如果数据包的目标节点已移动，则路由协议必须在2秒内收敛，如果只有发送方已移动，则路由协议必须在0.5秒内收敛[RFC5826]。根据应用情况，恢复时间的公差可能有所不同；然而，路由协议必须提供短期不可用和长期消失的检测。路由协议必须利用网络资源（例如，路径冗余），以便在节点出现故障时提供良好的网络行为。
Different routing protocols may exhibit different scaling characteristics with respect to the recovery/convergence time and the computational resources to achieve recovery after a convergence; see also [R01] and [R10].
不同的路由协议可能在恢复/收敛时间和计算资源方面表现出不同的缩放特性，以在收敛后实现恢复；另见[R01]和[R10]。
[R07] 6LoWPAN routing protocols SHOULD be designed to correctly operate in the presence of link asymmetry.
[R07]6 LowPan路由协议应设计为在存在链路不对称的情况下正确运行。
Link asymmetry occurs when the probability of successful transmission between two nodes is significantly higher in one direction than in the other. This phenomenon has been reported in a large number of experimental studies, and it is expected that 6LoWPANs will exhibit link asymmetry.
当两个节点之间的成功传输概率在一个方向显著高于另一个方向时，就会发生链路不对称。这一现象已在大量实验研究中得到报道，预计6LoWPANs将表现出链接不对称性。
6LoWPANs can be deployed in different sizes and topologies, adhere to various models of mobility, be exposed to various levels of interference, etc. In any case, LoWPANs must maintain low energy consumption. The requirements described in this subsection are derived from the network attributes of 6LoWPANs.
6 LoWPANs可以部署在不同的尺寸和拓扑中，支持不同的机动性模型，暴露于不同程度的干扰等。在任何情况下，LoWPANs必须保持低能耗。本小节中描述的要求源自6LoWPANs的网络属性。
[R08] The design of 6LoWPAN routing protocols SHOULD take into account that some nodes may be unresponsive during certain time intervals, due to periodic hibernation.
[R08]6LoWPAN路由协议的设计应考虑到由于周期性休眠，某些节点可能在特定时间间隔内没有响应。
Many nodes in LoWPAN environments might periodically hibernate (i.e., disable their transceiver activity) in order to save energy. Therefore, routing protocols must ensure robust packet delivery despite nodes frequently shutting off their radio transmission interface. Feedback from the lower IEEE 802.15.4 layer may be considered to enhance the power awareness of 6LoWPAN routing protocols.
低泛环境中的许多节点可能会定期休眠（即禁用其收发器活动），以节省能源。因此，尽管节点经常关闭其无线传输接口，路由协议必须确保健壮的数据包交付。可以考虑来自较低IEEE 802.15.4层的反馈，以增强6LoWPAN路由协议的功率感知。
CC1000-based nodes must operate at a duty cycle of approximately 2% to survive for one year from an idealized AA battery power source [Hill]. For home automation purposes, it is suggested that the devices have to maximize the sleep phase with a duty cycle lower than 1% [RFC5826], while in building automation applications, batteries must be operational for at least 5 years when the sensing devices are transmitting data (e.g., 64 bytes) once per minute [RFC5867].
基于CC1000的节点必须以约2%的占空比运行，才能在理想的AA电池电源下生存一年[Hill]。出于家庭自动化的目的，建议设备必须在占空比低于1%的情况下最大化睡眠阶段[RFC5826]，而在楼宇自动化应用中，当传感设备每分钟传输一次数据（例如64字节）时，电池必须至少运行5年[RFC5867]。
Depending on the application in use, packet rates may range from one per second to one per day, or beyond. Routing protocols may take advantage of knowledge about the packet transmission rate and utilize this information in calculating routing paths. In many IEEE 802.15.4 deployments, and in other wireless low-power technologies, forwarders are mains-powered devices (and hence do not need to sleep). However, it cannot be assumed that all forwarders are mains-powered. A routing protocol that addresses this case SHOULD provide a mode in which power consumption is a metric. In addition, using nodes in power-saving modes for
根据所使用的应用程序，数据包速率可能在每秒一个到每天一个之间，甚至更高。路由协议可以利用关于分组传输速率的知识，并在计算路由路径时利用该信息。在许多IEEE 802.15.4部署和其他无线低功耗技术中，转发器是由电源供电的设备（因此不需要睡眠）。然而，不能假设所有的货运代理都由电源供电。解决这种情况的路由协议应该提供一种模式，其中功耗是一个度量。此外，在节能模式下使用节点
forwarding may increase delay and reduce the probability of packet delivery, which in this case also should be available as an input into the path computation.
转发可增加延迟并降低分组传送的概率，在这种情况下，分组传送也应作为路径计算的输入。
[R09] The metric used by 6LoWPAN routing protocols SHOULD provide some flexibility with respect to the inputs provided by the lower layers and other measures to optimize path selection, considering energy balance and link qualities.
[R09]考虑到能量平衡和链路质量，6LoWPAN路由协议所使用的度量应在较低层提供的输入和其他优化路径选择的措施方面提供一定的灵活性。
In homes, buildings, or infrastructure, some nodes will be installed with mains power. Such power-installed nodes MUST be considered as relay points for a prominent role in packet delivery. 6LoWPAN routing protocols MUST know the power constraints of the nodes.
在家庭、建筑物或基础设施中，一些节点将安装主电源。这种电力安装节点必须被视为中继点，以便在数据包交付中发挥重要作用。6LoWPAN路由协议必须知道节点的功率约束。
Simple hop-count-only mechanisms may be inefficient in 6LoWPANs. There is a Link Quality Indication (LQI) and/or RSSI from IEEE 802.15.4 that may be taken into account for better metrics. The metric to be used (and its goal) may depend on applications and requirements.
在6LoWPANs中，简单的单跳计数机制可能效率低下。IEEE 802.15.4中有一个链路质量指示（LQI）和/或RSSI，可将其考虑在内以获得更好的度量。要使用的度量（及其目标）可能取决于应用程序和需求。
The numbers in Figure 4 represent the Link Delivery Ratio (LDR) of each pair of nodes. There are studies that show a piecewise linear dependence between the LQI and the LDR [Chen].
图4中的数字表示每对节点的链路交付率（LDR）。有研究表明，LQI和LDR之间存在分段线性相关性[Chen]。
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
Figure 4: An Example Network
图4：一个示例网络
In this simple example, there are two options in routing from node A to node C, with the following features:
在这个简单的示例中，从节点A到节点C的路由有两个选项，具有以下特性：
A. Path AC:
A.路径AC：
+ (1/0.6) = 1.67 avg. transmissions needed for each packet (confirmed link-layer delivery with retransmissions and negligible ACK loss have been assumed)
+ （1/0.6）=每个数据包所需的平均传输量为1.67（已假设具有重传和可忽略ACK丢失的确认链路层交付）
+ one-hop path
+ 单跳路径
+ good energy consumption and end-to-end latency of data packets, poor delivery ratio (0.6)
+ 数据包的能耗和端到端延迟好，传递率差（0.6）
+ poor probability of route reconfigurations
+ 路由重新配置的低概率
B. Path ABC:
B.路径ABC：
+ (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each
packet (under the same assumptions as above)
+ (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each
packet (under the same assumptions as above)
+ two-hop path
+ 两跳路径
+ poor energy consumption and end-to-end latency of data packets, good delivery ratio (0.81)
+ 数据包的能耗和端到端延迟差，交付率好（0.81）
If energy consumption of the network must be minimized, path AC is the best (this path would be chosen based on a hop-count metric). However, if the delivery ratio in that case is not sufficient, the best path is ABC (it would be chosen by an LQI-based metric). Combinations of both metrics can be used.
如果必须最小化网络的能量消耗，路径AC是最佳的（该路径将根据跳数度量选择）。但是，如果这种情况下的交付率不够，那么最好的路径是ABC（它将由基于LQI的指标选择）。可以使用这两个指标的组合。
The metric also affects the probability of route reconfiguration. Route reconfiguration, which may be triggered by packet losses, may require transmission of routing protocol messages. It is possible to use a metric aimed at selecting the path with a low route reconfiguration rate by using the LQI as an input to the metric. Such a path has good properties, including stability and low control message overhead.
该度量还影响路由重新配置的概率。可能由数据包丢失触发的路由重新配置可能需要传输路由协议消息。通过使用LQI作为度量的输入，可以使用旨在选择具有低路由重新配置率的路径的度量。这种路径具有良好的特性，包括稳定性和较低的控制消息开销。
Note that a tradeoff exists between [R09] and [R01].
注意，[R09]和[R01]之间存在折衷。
[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both scalability -- from a few nodes to maybe millions of nodes -- and minimal use of system resources.
[R10]6LoWPAN路由协议的设计应实现可扩展性（从几个节点到数百万个节点）和最小化系统资源的使用。
A LoWPAN may consist of just a couple of nodes (for instance, in a body-area network), but may also contain much higher numbers of devices (e.g., monitoring of a city infrastructure or a highway). For home automation applications, it is envisioned that the routing protocol must support 250 devices in the network [RFC5826], while routing protocols for metropolitan-scale sensor networks must be capable of clustering a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each [RFC5548]. It is therefore necessary that routing mechanisms are designed to be scalable for operation in networks of various sizes. However, due to a lack of memory size and computational power, 6LoWPAN routing might limit forwarding entries to a small number, such as a maximum of 32 routing table
LoWPAN可能仅由几个节点组成（例如，在身体区域网络中），但也可能包含更多的设备（例如，监测城市基础设施或高速公路）。对于家庭自动化应用，预计路由协议必须支持网络中的250个设备[RFC5826]，而大都市规模传感器网络的路由协议必须能够将大量传感节点群集到每个区域包含10^2到10^4个传感节点[RFC5548]。因此，有必要将路由机制设计为可伸缩的，以便在各种规模的网络中运行。但是，由于缺乏内存大小和计算能力，6LoWPAN路由可能会将转发条目限制为一个小数目，例如最多32个路由表
entries. Particularly in large networks, the routing mechanism MUST be designed in such a way that the number of routers is smaller than the number of hosts.
条目。特别是在大型网络中，路由机制的设计必须使路由器的数量小于主机的数量。
[R11] The procedure of route repair and related control messages SHOULD NOT harm overall energy consumption from the routing protocols.
[R11]路由修复过程和相关控制消息不应损害路由协议的总体能耗。
Local repair improves throughput and end-to-end latency, especially in large networks. Since routes are repaired quickly, fewer data packets are dropped, and a smaller number of routing protocol packet transmissions are needed, since routes can be repaired without source-initiated route discovery [Lee]. One important consideration here may be to avoid premature energy depletion, even if that impairs other requirements.
本地修复可提高吞吐量和端到端延迟，特别是在大型网络中。由于路由被快速修复，因此丢弃的数据包更少，并且需要更少数量的路由协议包传输，因为路由可以在没有源发起的路由发现的情况下被修复[Lee]。这里一个重要的考虑因素可能是避免过早消耗能源，即使这会影响其他需求。
[R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive topologies and mobile nodes. When supporting dynamic topologies and mobile nodes, route maintenance should keep in mind the goal of a minimal routing state and routing protocol message overhead.
[R12]6LoWPAN路由协议应允许动态自适应拓扑和移动节点。在支持动态拓扑和移动节点时，路由维护应牢记最小化路由状态和路由协议消息开销的目标。
Topological node mobility may be the result of physical movement and/or a changing radio environment, making it very likely that mobility needs to be handled even in a network with physically static nodes. 6LoWPANs do not make use of a separate protocol to maintain connectivity to moving nodes but expects the routing protocol to handle it.
拓扑节点移动性可能是物理移动和/或变化的无线电环境的结果，这使得即使在具有物理静态节点的网络中也很可能需要处理移动性。6LoWPANs不使用单独的协议来保持与移动节点的连接，但期望路由协议来处理它。
In addition, some nodes may move from one 6LoWPAN to another and are expected to become functional members of the latter 6LoWPAN in a limited amount of time.
此外，一些节点可能会从一个6LoWPAN移动到另一个6LoWPAN，并有望在有限的时间内成为后一个6LoWPAN的功能成员。
Building monitoring applications, for instance, have a number of requirements with respect to recovery and settling time for mobility that range between 5 and 20 seconds (Section 5.3.1 of [RFC5867]). For more interactive applications such as those used in home automation systems, where users provide input and expect instant feedback, mobility requirements are also stricter and, for moves within a network, a convergence time below 0.5 seconds is commonly required (Section 3.2 of [RFC5826]). In industrial environments, where mobile equipment (e.g., cranes) moves around, the routing protocol needs to support vehicular speeds of up to 35 km/h [RFC5673]. Currently, 6LoWPANs are not normally being used for such fast mobility, but dynamic association and disassociation MUST be supported in 6LoWPANs.
例如，楼宇监控应用程序对移动性的恢复和稳定时间有许多要求，范围在5到20秒之间（RFC5867第5.3.1节）。对于更多交互应用，如家庭自动化系统中使用的应用，用户提供输入并期望即时反馈，移动性要求也更严格，对于网络中的移动，通常需要小于0.5秒的收敛时间（RFC5826第3.2节）。在移动设备（如起重机）移动的工业环境中，路由协议需要支持高达35 km/h的车辆速度[RFC5673]。目前，6LoWPANs通常不用于这种快速移动，但6LoWPANs必须支持动态关联和解除关联。
There are several challenges that should be addressed by a 6LoWPAN routing protocol in order to create robust routing in dynamic environments:
为了在动态环境中创建健壮的路由，6LoWPAN路由协议应该解决几个难题：
* Mobile Nodes Changing Their Location inside a LoWPAN: If the nodes' movement pattern is unknown, mobility cannot easily be detected or distinguished by the routing protocols. Mobile nodes can be treated as nodes that disappear and reappear in another place. The tracking of movement patterns increases complexity and can be avoided by handling moving nodes using reactive route updates.
* 移动节点在低范围内改变其位置：如果节点的移动模式未知，则无法通过路由协议轻松检测或区分移动。移动节点可以被视为在另一个地方消失和重新出现的节点。移动模式的跟踪增加了复杂性，可以通过使用反应式路由更新处理移动节点来避免。
* Movement of a LoWPAN with Respect to Other (Inter)Connected LoWPANs: Within each stub network, (one or more) relatively powerful gateway nodes (6LBRs) need to be configured to handle moving LoWPANs.
* 相对于其他（内部）连接的低盘移动低盘：在每个存根网络中，需要配置（一个或多个）相对强大的网关节点（6LBR）来处理移动的低盘。
* Nodes Permanently Joining or Leaving the LoWPAN: In order to ease routing table updates, reduce the size of these updates, and minimize error control messages, nodes leaving the network may announce their disassociation to the closest edge router or to a specific node (if any) that takes charge of local association and disassociation.
* 永久加入或离开LoWPAN的节点：为了简化路由表更新，减少这些更新的大小，并最小化错误控制消息，离开网络的节点可以宣布其与最近的边缘路由器或负责本地关联和解除关联的特定节点（如果有）的解除关联。
[R13] A 6LoWPAN routing protocol SHOULD support various traffic patterns -- point-to-point, point-to-multipoint, and multipoint-to-point -- while avoiding excessive multicast traffic in a LoWPAN.
[R13]6LoWPAN路由协议应支持各种流量模式——点对点、点对多点和多点对点——同时避免在LoWPAN中出现过多的多播流量。
6LoWPANs often have point-to-multipoint or multipoint-to-point traffic patterns. Many emerging applications include point-to-point communication as well. 6LoWPAN routing protocols should be designed with the consideration of forwarding packets from/to multiple sources/destinations. Current documents of the ROLL WG explain that the workload or traffic pattern of use cases for LoWPANs tends to be highly structured, unlike the any-to-any data transfers that dominate typical client and server workloads. In many cases, exploiting such structure may simplify difficult problems arising from resource constraints or variation in connectivity.
6停车场通常具有点对多点或多点对点交通模式。许多新兴应用还包括点对点通信。6LoWPAN路由协议的设计应考虑将数据包从/转发到多个源/目的地。ROLL WG的当前文档解释说，LoWPANs用例的工作负载或流量模式倾向于高度结构化，这与主导典型客户机和服务器工作负载的任意对任意数据传输不同。在许多情况下，利用这种结构可以简化由资源限制或连通性变化引起的难题。
The routing requirement described in this subsection allows secure transmission of routing messages. As in traditional networks, routing mechanisms in 6LoWPANs present another window from which an attacker might disrupt and significantly degrade the overall performance of the 6LoWPAN. Attacks against non-secure routing aim
本小节中描述的路由要求允许路由消息的安全传输。与传统网络一样，6LoWPANs中的路由机制提供了另一个窗口，攻击者可能会从该窗口中断6LoWPAN并显著降低6LoWPAN的整体性能。针对非安全路由目标的攻击
mainly to contaminate WPANs with false routing information, resulting in routing inconsistencies. A malicious node can also snoop packets and then launch replay attacks on the 6LoWPAN nodes. These attacks can cause harm, especially when the attacker is a high-power device, such as a laptop. It can also easily drain the batteries of 6LoWPAN devices by sending broadcast messages, redirecting routes, etc.
主要是用错误的路由信息污染WPAN，导致路由不一致。恶意节点还可以窥探数据包，然后对6LoWPAN节点发起重播攻击。这些攻击会造成伤害，尤其是当攻击者是高功率设备（如笔记本电脑）时。它还可以通过发送广播消息、重定向路由等方式轻松耗尽6LoWPAN设备的电池电量。
[R14] 6LoWPAN routing protocols MUST support confidentiality, authentication, and integrity services as required for secure delivery of control messages.
[R14]6LoWPAN路由协议必须支持安全传递控制消息所需的保密性、身份验证和完整性服务。
A general set of requirements that may apply to these services can be found in [KARP-THREATS].
可能适用于这些服务的一系列一般要求可在[KARP-THREADS]中找到。
Security is very important for designing robust routing protocols, but it should not cause significant transmission overhead. The security aspect, however, seems to be a bit of a tradeoff in a 6LoWPAN, since security is always a costly function. A 6LoWPAN poses unique challenges to which traditional security techniques cannot be applied directly. For example, public key cryptography primitives are typically avoided (as being too expensive), as are relatively heavyweight conventional encryption methods.
安全性对于设计健壮的路由协议非常重要，但它不应造成显著的传输开销。然而，安全方面似乎是6LoWPAN中的一个折衷方案，因为安全性总是一个代价高昂的功能。6LoWPAN带来了传统安全技术无法直接应用的独特挑战。例如，通常避免使用公钥加密原语（因为过于昂贵），相对较重的传统加密方法也是如此。
Consequently, it becomes questionable whether the 6LoWPAN devices can support IPsec as it is. While [RFC6434] makes support of the IPsec architecture a SHOULD for all IPv6 nodes, considering the power constraints and limited processing capabilities of IEEE 802.15.4-capable devices, IPsec is computationally expensive. Internet Key Exchange (IKEv2) messaging as described in RFC 5996 [RFC5996] will not work well in 6LoWPANs, as we want to minimize the amount of signaling in these networks. IPsec supports the Authentication Header (AH) for authenticating the IP header and the Encapsulating Security Payload (ESP) for authenticating and encrypting the payload. The main issues of using IPsec are two-fold: (1) processing power and (2) key management. Since these tiny 6LoWPAN devices do not process huge amounts of data or communicate with many different nodes, whether complete implementation of a Security Association Database (SAD), policy database, and dynamic key-management protocol are appropriate for these small battery-powered devices or not is not well understood.
因此，6LoWPAN设备是否能够支持IPsec就成了问题。考虑到支持IEEE 802.15.4的设备的功率限制和有限的处理能力，虽然[RFC6434]认为所有IPv6节点都应该支持IPsec体系结构，但IPsec的计算成本很高。RFC 5996[RFC5996]中描述的Internet密钥交换（IKEv2）消息在6LoWPANs中无法正常工作，因为我们希望将这些网络中的信令量降至最低。IPsec支持用于对IP报头进行身份验证的身份验证报头（AH）和用于对有效负载进行身份验证和加密的封装安全有效负载（ESP）。使用IPsec的主要问题有两个：（1）处理能力和（2）密钥管理。由于这些微型6LoWPAN设备不会处理大量数据或与许多不同的节点通信，因此不清楚安全关联数据库（SAD）、策略数据库和动态密钥管理协议的完整实现是否适合这些小型电池供电设备。
Bandwidth is a very scarce resource in 6LoWPAN environments. The fact that IPsec additionally requires another header (AH or ESP) in every packet makes its use problematic in 6LoWPAN environments. IPsec requires two communicating peers to share a secret key that is typically established dynamically with IKEv2. Thus, it has an additional packet overhead incurred by the exchange of IKEv2 packets.
带宽在6LoWPAN环境中是一种非常稀缺的资源。IPsec在每个数据包中还需要另一个报头（AH或ESP），这使得它在6LoWPAN环境中的使用存在问题。IPsec要求两个通信对等方共享一个密钥，该密钥通常是通过IKEv2动态建立的。因此，它具有因交换IKEv2分组而产生的额外分组开销。
Given existing constraints in 6LoWPAN environments, IPsec may not be suitable for use in such environments, especially since a 6LoWPAN node may not be capable of operating all IPsec algorithms on its own. Thus, a 6LoWPAN may need to define its own keying management method(s) that require minimum overhead in packet size and in the number of signaling messages that are exchanged. IPsec will provide authentication and confidentiality between end-nodes and across multiple LoWPAN links, and may be useful only when two nodes want to apply security to all exchanged messages. However, in most cases, the security may be requested at the application layer as needed, while other messages can flow in the network without security overhead.
鉴于6LoWPAN环境中的现有限制，IPsec可能不适合在此类环境中使用，特别是因为6LoWPAN节点可能无法单独操作所有IPsec算法。因此，6LoWPAN可能需要定义其自己的密钥管理方法，该方法在数据包大小和交换的信令消息数量方面需要最小的开销。IPsec将在终端节点之间以及跨多个LoWPAN链路提供身份验证和机密性，并且可能仅在两个节点希望对所有交换的消息应用安全性时才有用。然而，在大多数情况下，可以根据需要在应用层请求安全性，而其他消息可以在网络中流动，而不会产生安全开销。
Security threats within LoWPANs may be different from existing threat models in ad hoc network environments. If IEEE 802.15.4 security is not used, Neighbor Discovery (ND) in IEEE 802.15.4 links is susceptible to threats. These include Neighbor Solicitation/Neighbor Advertisement (NS/NA) spoofing, a malicious router, a default router that is "killed", a good router that goes bad, a spoofed redirect, replay attacks, and remote ND DoS [RFC3756]. However, if IEEE 802.15.4 security is used, no other protection is needed for ND, as long as none of the nodes become compromised, because the Corporate Intranet Model of RFC 3756 can be assumed [6LoWPAN-ND].
LoWPANs中的安全威胁可能不同于ad hoc网络环境中的现有威胁模型。如果不使用IEEE 802.15.4安全性，则IEEE 802.15.4链路中的邻居发现（ND）容易受到威胁。其中包括邻居请求/邻居广告（NS/NA）欺骗、恶意路由器、被“杀死”的默认路由器、坏掉的好路由器、欺骗重定向、重播攻击和远程ND DoS[RFC3756]。但是，如果使用IEEE 802.15.4安全性，则ND不需要其他保护，只要没有任何节点受到危害，因为可以假定RFC 3756的公司内部网模型[6LoWPAN ND]。
Bootstrapping may also impose additional threats. For example, a malicious node can obtain initial configuration information in order to appear as a legitimate node and then carry out various types of attacks. Such a node can also keep legitimate nodes busy by broadcasting authentication/join requests. One option for mitigating such threats is the use of mutual authentication schemes based on the use of pre-shared keys [Ikram].
引导也可能带来额外的威胁。例如，恶意节点可以获取初始配置信息，以显示为合法节点，然后执行各种类型的攻击。这样的节点还可以通过广播认证/加入请求使合法节点保持忙碌。缓解此类威胁的一个选择是使用基于预共享密钥[Ikram]的相互认证方案。
The IEEE 802.15.4 MAC provides an AES-based security mechanism. Routing protocols may define how this mechanism (in conjunction with IPsec whenever available) can be used to obtain the intended security, either for the routing protocol alone or in conjunction with the security used for the data. Byte overhead of the mechanism, which depends on the security services selected, must be considered. In the worst case in terms of overhead, the mechanism consumes 21 bytes of MAC payload.
IEEE 802.15.4 MAC提供了基于AES的安全机制。路由协议可以定义如何使用该机制（在可用时与IPsec结合使用）来获得预期的安全性，无论是单独用于路由协议还是与用于数据的安全性结合使用。必须考虑机制的字节开销，这取决于所选的安全服务。在开销方面最糟糕的情况下，该机制消耗21字节的MAC有效负载。
The IEEE 802.15.4 MAC security is typically supported by crypto hardware, even in very simple chips that will be used in a 6LoWPAN. Even if the IEEE 802.15.4 MAC security mechanisms are not used, this crypto hardware is usually available for use by
IEEE 802.15.4 MAC安全性通常由加密硬件支持，即使在用于6LoWPAN的非常简单的芯片中也是如此。即使不使用IEEE 802.15.4 MAC安全机制，该加密硬件通常也可供用户使用
application code running on these chips. A security protocol outside IEEE 802.15.4 MAC security SHOULD therefore provide a mode of operation that is covered by this crypto hardware.
在这些芯片上运行的应用程序代码。因此，IEEE 802.15.4 MAC安全之外的安全协议应提供此加密硬件所涵盖的操作模式。
IEEE 802.15.4 does not specify protection for acknowledgment frames. Since the sequence numbers of data frames are sent in the clear, an adversary can forge an acknowledgment for each data frame. Exploitation of this weakness can be combined with targeted jamming to prevent delivery of selected packets. Consequently, IEEE 802.15.4 acknowledgments cannot be relied upon. In applications that require high security, the routing protocol must not exploit feedback from acknowledgments (e.g., to keep track of neighbor connectivity, see [R16]).
IEEE 802.15.4未规定对确认帧的保护。由于数据帧的序列号以明文形式发送，因此对手可以伪造每个数据帧的确认。利用这一弱点可以与有针对性的干扰相结合，以防止所选数据包的传送。因此，不能依赖IEEE 802.15.4确认。在需要高安全性的应用程序中，路由协议不得利用来自确认的反馈（例如，为了跟踪邻居连接，请参见[R16]）。
One LoWPAN may be built as one IPv6 link. In this case, mesh-under forwarding mechanisms must be supported. While this document provides general, layer-agnostic guidelines about the design of 6LoWPAN routing, the requirements in this section are specifically related to Layer 2. These requirements are directed to bodies that might consider working on mesh-under routing, such as the IEEE. The requirements described in this subsection allow optimization and correct operation of routing solutions, taking into account the specific features of the mesh-under configuration.
一个LoWPAN可以构建为一个IPv6链路。在这种情况下，必须支持转发机制下的网格。虽然本文件提供了有关6LoWPAN布线设计的一般性、图层无关的指南，但本节中的要求与图层2具体相关。这些要求针对可能考虑在路由下工作的网格，例如IEEE。本小节中描述的要求允许优化和正确操作布线解决方案，同时考虑配置下网格的特定功能。
[R15] Mesh-under requires the development of a routing protocol operating below IP. This protocol MUST support 16-bit short and 64-bit extended MAC addresses.
[R15]下的Mesh需要开发在IP下运行的路由协议。此协议必须支持16位短MAC地址和64位扩展MAC地址。
[R16] In order to perform discovery and maintenance of neighbors (i.e., neighborhood discovery as opposed to ND-style neighbor discovery), LoWPAN nodes SHOULD avoid sending separate "Hello" messages. Instead, link-layer mechanisms (such as acknowledgments) MAY be utilized to keep track of active neighbors.
[R16]为了执行邻居的发现和维护（即邻居发现而不是ND式邻居发现），LoWPAN节点应避免发送单独的“Hello”消息。相反，链路层机制（例如确认）可用于跟踪活动邻居。
Reception of an acknowledgment after a frame transmission may render unnecessary the transmission of explicit Hello messages, for example. In a more general view, any frame received by a node may be used as an input to evaluate the connectivity between the sender and receiver of that frame.
例如，在帧传输之后接收确认可能使得显式Hello消息的传输变得不必要。在更一般的视图中，节点接收的任何帧可以用作输入，以评估该帧的发送方和接收方之间的连接性。
[R17] If the routing protocol functionality includes enabling IP multicast, then it MAY employ structure in the network for efficient distribution in order to minimize link-layer broadcast.
[R17]如果路由协议功能包括启用IP多播，则它可以利用网络中的结构进行有效分发，以最小化链路层广播。
When a new protocol is designed, the operational environment and manageability of the protocol should be considered from the start [RFC5706]. This subsection provides a requirement for the manageability of 6LoWPAN routing protocols.
设计新协议时，应从一开始就应考虑协议的操作环境和可管理性[RFC5706]。本小节对6LoWPAN路由协议的可管理性提出了要求。
[R18] A 6LoWPAN routing protocol SHOULD be designed according to the guidelines for operations and management stated in [RFC5706].
[R18]应根据[RFC5706]中规定的操作和管理指南设计6LoWPAN路由协议。
The management operations that a 6LoWPAN routing protocol implementation can support depend on the memory and processing capabilities of the 6LoWPAN devices used, which are typically constrained. However, 6LoWPANs may benefit significantly from supporting such 6LoWPAN routing protocol management operations as configuration and performance monitoring.
6LoWPAN路由协议实现可支持的管理操作取决于所用6LoWPAN设备的内存和处理能力，这些能力通常受到限制。但是，6LoWPANs可能会从支持6LoWPAN路由协议管理操作（如配置和性能监视）中获益匪浅。
The design of 6LoWPAN routing protocols should take into account that, according to "Architectural Principles of the Internet" [RFC1958], "options and parameters should be configured or negotiated dynamically rather than manually". This is especially important for 6LoWPANs, which can be composed of a large number of devices (and, in addition, these devices may not have an appropriate user interface). Therefore, parameter autoconfiguration is a desirable property for a 6LoWPAN routing protocol, although some subset of routing protocol parameters may allow other forms of configuration as well.
6LoWPAN路由协议的设计应考虑到，根据“互联网架构原则”[RFC1958]，“选项和参数应动态配置或协商，而不是手动”。这对于6LoWPANs尤其重要，6LoWPANs可以由大量设备组成（此外，这些设备可能没有合适的用户界面）。因此，参数自动配置是6LoWPAN路由协议的理想属性，尽管路由协议参数的某些子集也可能允许其他形式的配置。
In order to verify the correct operation of the 6LoWPAN routing protocol and the network itself, a 6LoWPAN routing protocol should allow monitoring of the status and/or value of 6LoWPAN routing protocol parameters and data structures such as routing table entries. In order to enable fault management, further monitoring of the 6LoWPAN routing protocol operation is needed. For this, faults can be reported via error log messages. These messages may contain information such as the number of times a packet could not be sent to a valid next hop, the duration of each period without connectivity, memory overflow and its causes, etc.
为了验证6LoWPAN路由协议和网络本身的正确运行，6LoWPAN路由协议应允许监控6LoWPAN路由协议参数和数据结构（如路由表条目）的状态和/或值。为了实现故障管理，需要进一步监控6LoWPAN路由协议的操作。为此，可以通过错误日志消息报告故障。这些消息可能包含诸如数据包无法发送到有效下一跳的次数、没有连接的每个时段的持续时间、内存溢出及其原因等信息。
[RFC5706] -- in particular its Section 3 -- provides a comprehensive guide to properly designing the management solution for a 6LoWPAN routing protocol.
[RFC5706]——特别是其第3节——提供了正确设计6LoWPAN路由协议管理解决方案的全面指南。
Security issues are described in Section 5.4. The security considerations in RFC 4919 [RFC4919], RFC 4944 [RFC4944], and RFC 4593 [RFC4593] apply as well.
第5.4节描述了安全问题。RFC 4919[RFC4919]、RFC 4944[RFC4944]和RFC 4593[RFC4593]中的安全注意事项也适用。
The use of wireless links renders a 6LoWPAN susceptible to attacks like any other wireless network. In outdoor 6LoWPANs, the physical exposure of the nodes allows an adversary to capture, clone, or tamper with these devices. In ad hoc 6LoWPANs that are dynamic in both their topology and node memberships, a static security configuration does not suffice. Spoofed, altered, or replayed routing information might occur, while multihopping could delay the detection and treatment of attacks.
无线链路的使用使得6LoWPAN像任何其他无线网络一样容易受到攻击。在户外6LoWPANs中，节点的物理暴露允许对手捕获、克隆或篡改这些设备。在拓扑结构和节点成员身份都是动态的ad hoc 6LoWPANs中，静态安全配置是不够的。可能会出现伪造、更改或重播路由信息的情况，而多跳可能会延迟攻击的检测和处理。
This specification expects that the link layer is sufficiently protected, either by means of physical or IP security for the backbone link, or with MAC-sublayer cryptography. However, link-layer encryption and authentication may not be sufficient to provide confidentiality, authentication, integrity, and freshness to both data and routing protocol packets. Time synchronization, self-organization, and secure localization for multi-hop routing are also critical to support.
本规范期望通过骨干链路的物理或IP安全性，或通过MAC子层加密，充分保护链路层。然而，链路层加密和身份验证可能不足以为数据和路由协议包提供机密性、身份验证、完整性和新鲜性。多跳路由的时间同步、自组织和安全定位也是支持的关键。
For secure routing protocol operation, it may be necessary to consider authenticated broadcast (and multicast) and bidirectional link verification. On the other hand, secure end-to-end data delivery can be assisted by the routing protocol. For example, multi-path routing could be considered for increasing security to prevent selective forwarding. However, the challenge is that 6LoWPANs already have high resource constraints, so that 6LBR and LoWPAN nodes may require different security solutions.
对于安全路由协议操作，可能需要考虑认证广播（和多播）和双向链路验证。另一方面，路由协议可以辅助安全的端到端数据传输。例如，可以考虑使用多路径路由来提高安全性，以防止选择性转发。然而，挑战在于6LoWPANs已经有很高的资源约束，因此6LBR和LoWPAN节点可能需要不同的安全解决方案。
The authors of this document highly appreciate the authors of "IPv6 over Low Power WPAN Security Analysis" [6LoWPAN-SEC]. Although their security analysis work is not ongoing at the time of this writing, the valuable information and text in that document are used in Section 5.4 of this document, per advice received during IESG review procedures. Thanks to their work, Section 5.4 is much improved. The authors also thank S. Chakrabarti, who gave valuable comments regarding mesh-under requirements, and A. Petrescu for significant review.
本文档的作者高度赞赏“低功耗WPAN上的IPv6安全分析”[6LoWPAN SEC]的作者。尽管他们的安全分析工作在撰写本文时尚未进行，但根据IESG审查程序期间收到的建议，本文件第5.4节使用了该文件中的宝贵信息和文本。由于他们的工作，第5.4节有了很大的改进。作者还感谢S.Chakrabarti和A.Petrescu的重要评论，S.Chakrabarti根据需求对mesh提出了宝贵的意见。
Carles Gomez has been supported in part by FEDER and by the Spanish Government through projects TIC2006-04504 and TEC2009-11453.
卡尔斯·戈麦斯通过TIC2006-04504和TEC2009-11453项目得到了费德和西班牙政府的部分支持。
[IEEE802.15.4] IEEE Computer Society, "IEEE Standard for Local and Metropolitan Area Networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE Std. 802.15.4-2011, September 2011.
[IEEE802.15.4]IEEE计算机协会，“局域网和城域网的IEEE标准——第15.4部分：低速无线个人区域网（LR WPAN）”，IEEE标准802.15.4-2011，2011年9月。
[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月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Ed.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Ed.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919]Kushalnagar，N.，黑山，G.，和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，2007年8月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]Dohler，M.，Ed.，Watteyne，T.，Ed.，Winter，T.，Ed.，和D.Barthel，Ed.，“城市低功率和有损网络的路由要求”，RFC 5548，2009年5月。
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]Pister，K.，Ed.，Thubert，P.，Ed.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，2009年10月。
[6LoWPAN-ND] Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, October 2011.
[6LoWPAN ND]Shelby，Z.，Ed.，Chakrabarti，S.，和E.Nordmark，“低功耗和有损网络的邻居发现优化（6LoWPAN）”，正在进行的工作，2011年10月。
[6LoWPAN-SEC] Park, S., Kim, K., Haddad, W., Ed., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Work in Progress, March 2011.
[6 Lowpan SEC]Park，S.，Kim，K.，Haddad，W.，Ed.，Chakrabarti，S.，和J.Laganier，“低功耗WPAN上的IPv6安全分析”，正在进行的工作，2011年3月。
[Bulusu] Bulusu, N., Ed., and S. Jha, Ed., "Wireless Sensor Networks: A Systems Perspective", Artech House, ISBN 9781580538671, July 2005.
[Bulusu]Bulusu，N.，Ed.，和S.Jha，Ed.，“无线传感器网络：系统视角”，Artech House，ISBN 9781580538671，2005年7月。
[Chen] Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc Multicast Routing on Resource-Limited Sensor Nodes", Proc. 2nd International Workshop on Multi-hop Ad Hoc Networks, May 2006.
[Chen]Chen，B.，Muniswamy Reddy，K.，和M.Welsh，“资源有限传感器节点上的自组织多播路由”，Proc。第二届多跳特设网络国际研讨会，2006年5月。
[Doherty] Doherty, L., Warneke, B., Boser, B., and K. Pister, "Energy and Performance Considerations for Smart Dust", International Journal of Parallel and Distributed Systems and Networks, Vol. 4, No. 3, 2001.
[Doherty]Doherty，L.，Warneke，B.，Boser，B.，和K.Pister，“智能尘埃的能源和性能考虑”，国际并行和分布式系统与网络杂志，第4卷，第3期，2001年。
[Hill] Hill, J., "System Architecture for Wireless Sensor Networks", Ph.D. Thesis, UC Berkeley, 2003.
[Hill]Hill，J.，“无线传感器网络的系统架构”，博士。论文，加州大学伯克利分校，2003年。
[Ikram] Ikram, M., Chowdhury, A., Zafar, B., Cha, H., Kim, K., Yoo, S., and D. Kim, "A Simple Lightweight Authentic Bootstrapping Protocol for IPv6-based Low Rate Wireless Personal Area Networks (6LoWPANs)", Proc. International Conference on Wireless Communications and Mobile Computing, June 2009.
[Ikram]Ikram，M.，Chowdhury，A.，Zafar，B.，Cha，H.，Kim，K.，Yoo，S.，和D.Kim，“基于IPv6的低速无线个人区域网络（6LoWPANs）的简单轻量级真实引导协议”，Proc。无线通信和移动计算国际会议，2009年6月。
[KARP-THREATS] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", Work in Progress, May 2012.
[KARP-THREATS]Lebovitz，G.和M.Bhatia，“路由协议的密钥和认证（KARP）概述、威胁和要求”，正在进行的工作，2012年5月。
[Kuhn] Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case Optimal and Average-Case Efficient Ad-Hoc Geometric Routing", MobiHoc '03: Proceedings of the 4th ACM International Symposium on Mobile Ad Hoc Networking and Computing, June 2003.
[Kuhn]Kuhn，F.，Wattenhofer，R.，和A.Zollinger，“最坏情况下的最优和平均情况效率的adhoc几何路由”，MobiHoc'03：第四届ACM移动adhoc网络和计算国际研讨会论文集，2003年6月。
[Latre] Latre, B., De Mil, P., Moerman, I., Dhoedt, B., and P. Demeester, "Throughput and Delay Analysis of Unslotted IEEE 802.15.4", Journal of Networks, Vol. 1, No. 1, May 2006.
[Latre]Latre，B.，De Mil，P.，Moerman，I.，Dhoedt，B.，和P.Demester，“未分段IEEE 802.15.4的吞吐量和延迟分析”，网络杂志，第一卷，第1期，2006年5月。
[Lee] Lee, S., Belding-Royer, E., and C. Perkins, "Scalability Study of the Ad Hoc On-Demand Distance-Vector Routing Protocol", International Journal of Network Management, Vol. 13, pp. 97-114, March 2003.
[Lee]Lee，S.，Belding Royer，E.和C.Perkins，“特设按需距离向量路由协议的可扩展性研究”，国际网络管理杂志，第13卷，第97-114页，2003年3月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]Touch，J.和R.Perlman，“大量链路的透明互连（TRILL）：问题和适用性声明”，RFC 5556，2009年5月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[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., Ed., 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.，Ed.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[RFC6282]Hui，J.，Ed.，和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，2011年9月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
[ROLL-PROTOCOLS] Levis, P., Tavakoli, A., and S. Dawson-Haggerty, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Work in Progress, April 2009.
[ROLL-PROTOCOLS]Levis，P.，Tavakoli，A.，和S.Dawson Haggerty，“低功耗和有损网络的现有路由协议概述”，正在进行的工作，2009年4月。
[Shih] Shih, E., Cho, S., Ickes, N., Min, R., Sinha, A., Wang, A., and A. Chandrakasan, "Physical Layer Driven Protocols and Algorithm Design for Energy-Efficient Wireless Sensor Networks", MobiCom '01: Proceedings of the 7th ACM Annual International Conference on Mobile Computing and Networking, July 2001.
[Shih]Shih，E.，Cho，S.，Ickes，N.，Min，R.，Sinha，A.，Wang，A.，和A.Chandrakasan，“节能无线传感器网络的物理层驱动协议和算法设计”，MobiCom'01：第七届ACM移动计算和网络国际年会论文集，2001年7月。
[Watteyne] Watteyne, T., Molinaro, A., Richichi, M., and M. Dohler, "From MANET To IETF ROLL Standardization: A Paradigm Shift in WSN Routing Protocols", IEEE Communications Surveys and Tutorials, Vol. 13, Issue 4, pp. 688-707, 2011, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=5581105>.
[Watteyne]Watteyne，T.，Molinaro，A.，Richichi，M.，和M.Dohler，“从MANET到IETF滚动标准化：无线传感器网络路由协议的范式转变”，IEEE通信调查和教程，第13卷，第4期，第688-707页，2011年<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber=5581105>。
Authors' Addresses
作者地址
Eunsook Eunah Kim ETRI 161 Gajeong-dong Yuseong-gu Daejeon 305-700 Korea
Eunsook Eunah Kim ETRI 161 Gajeong dong Yuseong gu Daejeon 305-700韩国
Phone: +82-42-860-6124
EMail: eunah.ietf@gmail.com
Phone: +82-42-860-6124
EMail: eunah.ietf@gmail.com
Dominik Kaspar Simula Research Laboratory Martin Linges v 17 Fornebu 1364 Norway
多米尼克卡斯帕Simula研究实验室Martin Linges v 17，挪威内布1364
Phone: +47-6782-8223
EMail: dokaspar.ietf@gmail.com
Phone: +47-6782-8223
EMail: dokaspar.ietf@gmail.com
Carles Gomez Universitat Politecnica de Catalunya/Fundacio i2CAT Escola d'Enginyeria de Telecomunicacio i Aeroespacial de Castelldefels C/Esteve Terradas, 7 Castelldefels 08860 Spain
卡莱斯戈麦斯加泰罗尼亚理工大学/电信工程基金会/卡斯特尔德费尔斯航空航天中心，7卡斯特尔德费尔斯08860西班牙
Phone: +34-93-413-7206
EMail: carlesgo@entel.upc.edu
Phone: +34-93-413-7206
EMail: carlesgo@entel.upc.edu
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63921
EMail: cabo@tzi.org
Phone: +49-421-218-63921
EMail: cabo@tzi.org