Network Working Group                                     M. Dohler, Ed.
Request for Comments: 5548                                          CTTC
Category: Informational                                 T. Watteyne, Ed.
                                                       BSAC, UC Berkeley
                                                          T. Winter, Ed.
                                                             Eka Systems
                                                         D. Barthel, Ed.
                                                      France Telecom R&D
                                                                May 2009
        
Network Working Group                                     M. Dohler, Ed.
Request for Comments: 5548                                          CTTC
Category: Informational                                 T. Watteyne, Ed.
                                                       BSAC, UC Berkeley
                                                          T. Winter, Ed.
                                                             Eka Systems
                                                         D. Barthel, Ed.
                                                      France Telecom R&D
                                                                May 2009
        

Routing Requirements for Urban Low-Power and Lossy Networks

城市低功耗有损网络的路由要求

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2009 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

Abstract

摘要

The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless

本文介绍了城市低功耗和有损网络(U-LLN)的应用特定路由要求。在不久的将来,传感和驱动节点将被放置在城市环境的室外,以改善人们的生活条件,并监测对日益严格的环境法律的遵守情况。这些现场节点需要测量和报告广泛的数据(例如,执行智能计量或监测气象、污染和过敏状况的应用程序所需的数据)。预计这些节点中的大多数将通过各种链路进行无线通信,如IEEE 802.15.4、低功耗IEEE 802.11或IEEE 802.15.1(蓝牙),鉴于有限的无线电范围和大量节点需要使用合适的路由协议。此类协议的设计将主要受到节点有限资源(内存、处理能力、电池等)和室外城市应用场景的特殊性的影响。因此,对于无线网络

solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.

在低功耗和有损(ROLL)网络上路由的解决方案要有用,协议应该是节能的、可扩展的和自治的。本文件旨在规定一组IPv6路由要求,以反映这些要求和进一步U-LLN的定制特征。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Terminology .....................................................3
      2.1. Requirements Language ......................................4
   3. Overview of Urban Low-Power and Lossy Networks ..................4
      3.1. Canonical Network Elements .................................4
           3.1.1. Sensors .............................................4
           3.1.2. Actuators ...........................................5
           3.1.3. Routers .............................................6
      3.2. Topology ...................................................6
      3.3. Resource Constraints .......................................7
      3.4. Link Reliability ...........................................7
   4. Urban LLN Application Scenarios .................................8
      4.1. Deployment of Nodes ........................................8
      4.2. Association and Disassociation/Disappearance of Nodes ......9
      4.3. Regular Measurement Reporting ..............................9
      4.4. Queried Measurement Reporting .............................10
      4.5. Alert Reporting ...........................................11
   5. Traffic Pattern ................................................11
   6. Requirements of Urban-LLN Applications .........................13
      6.1. Scalability ...............................................13
      6.2. Parameter-Constrained Routing .............................13
      6.3. Support of Autonomous and Alien Configuration .............14
      6.4. Support of Highly Directed Information Flows ..............15
      6.5. Support of Multicast and Anycast ..........................15
      6.6. Network Dynamicity ........................................16
      6.7. Latency ...................................................16
   7. Security Considerations ........................................16
   8. References .....................................................18
      8.1. Normative References ......................................18
      8.2. Informative References ....................................18
   Appendix A.  Acknowledgements .....................................20
   Appendix B.  Contributors .........................................20
        
   1. Introduction ....................................................3
   2. Terminology .....................................................3
      2.1. Requirements Language ......................................4
   3. Overview of Urban Low-Power and Lossy Networks ..................4
      3.1. Canonical Network Elements .................................4
           3.1.1. Sensors .............................................4
           3.1.2. Actuators ...........................................5
           3.1.3. Routers .............................................6
      3.2. Topology ...................................................6
      3.3. Resource Constraints .......................................7
      3.4. Link Reliability ...........................................7
   4. Urban LLN Application Scenarios .................................8
      4.1. Deployment of Nodes ........................................8
      4.2. Association and Disassociation/Disappearance of Nodes ......9
      4.3. Regular Measurement Reporting ..............................9
      4.4. Queried Measurement Reporting .............................10
      4.5. Alert Reporting ...........................................11
   5. Traffic Pattern ................................................11
   6. Requirements of Urban-LLN Applications .........................13
      6.1. Scalability ...............................................13
      6.2. Parameter-Constrained Routing .............................13
      6.3. Support of Autonomous and Alien Configuration .............14
      6.4. Support of Highly Directed Information Flows ..............15
      6.5. Support of Multicast and Anycast ..........................15
      6.6. Network Dynamicity ........................................16
      6.7. Latency ...................................................16
   7. Security Considerations ........................................16
   8. References .....................................................18
      8.1. Normative References ......................................18
      8.2. Informative References ....................................18
   Appendix A.  Acknowledgements .....................................20
   Appendix B.  Contributors .........................................20
        
1. Introduction
1. 介绍

This document details application-specific IPv6 routing requirements for Urban Low-Power and Lossy Networks (U-LLNs). Note that this document details the set of IPv6 routing requirements for U-LLNs in strict compliance with the layered IP architecture. U-LLN use cases and associated routing protocol requirements will be described.

本文档详细介绍了城市低功耗和有损网络(U-LLN)的特定于应用程序的IPv6路由要求。请注意,本文档详细介绍了严格遵守分层IP体系结构的U-LLN的IPv6路由要求。将描述U-LLN用例和相关路由协议要求。

Section 2 defines terminology useful in describing U-LLNs.

第2节定义了用于描述U-LLN的术语。

Section 3 provides an overview of U-LLN applications.

第3节概述了U-LLN应用程序。

Section 4 describes a few typical use cases for U-LLN applications exemplifying deployment problems and related routing issues.

第4节描述了U-LLN应用程序的几个典型用例,举例说明了部署问题和相关路由问题。

Section 5 describes traffic flows that will be typical for U-LLN applications.

第5节描述了U-LLN应用的典型流量。

Section 6 discusses the routing requirements for networks comprising such constrained devices in a U-LLN environment. These requirements may overlap with or be derived from other application-specific requirements documents [ROLL-HOME] [ROLL-INDUS] [ROLL-BUILD].

第6节讨论了U-LLN环境中包含此类受限设备的网络的路由要求。这些要求可能与其他特定于应用的要求文件[ROLL-HOME][ROLL-INDUS][ROLL-BUILD]重叠或源自这些文件。

Section 7 provides an overview of routing security considerations of U-LLN implementations.

第7节概述了U-LLN实现的路由安全注意事项。

2. Terminology
2. 术语

The terminology used in this document is consistent with and incorporates that described in "Terminology in Low power And Lossy Networks" [ROLL-TERM]. This terminology is extended in this document as follows:

本文件中使用的术语与“低功率和有损网络术语”[ROLL-TERM]中描述的术语一致,并包含其中。该术语在本文件中扩展如下:

Anycast: Addressing and Routing scheme for forwarding packets to at least one of the "nearest" interfaces from a group, as described in RFC4291 [RFC4291] and RFC1546 [RFC1546].

选播:将数据包转发到组中至少一个“最近”接口的寻址和路由方案,如RFC4291[RFC4291]和RFC1546[RFC1546]中所述。

Autonomous: Refers to the ability of a routing protocol to independently function without requiring any external influence or guidance. Includes self-configuration and self-organization capabilities.

自治:指路由协议在不需要任何外部影响或指导的情况下独立运行的能力。包括自配置和自组织功能。

DoS: Denial of Service, a class of attack that attempts to cause resource exhaustion to the detriment of a node or network.

拒绝服务(DoS):拒绝服务,一类试图导致资源耗尽而损害节点或网络的攻击。

ISM band: Industrial, Scientific, and Medical band. This is a region of radio spectrum where low-power, unlicensed devices may generally be used, with specific guidance from an applicable local radio spectrum authority.

ISM乐队:工业、科学和医学乐队。这是一个无线电频谱区域,在适用的当地无线电频谱管理局的具体指导下,通常可以使用低功率、未经许可的设备。

U-LLN: Urban Low-Power and Lossy Network.

城市低功耗有损网络。

WLAN: Wireless Local Area Network.

WLAN:无线局域网。

2.1. Requirements Language
2.1. 需求语言

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

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

3. Overview of Urban Low-Power and Lossy Networks
3. 城市低功耗有损网络综述
3.1. Canonical Network Elements
3.1. 规范网络元素

A U-LLN is understood to be a network composed of three key elements, i.e.,

U-LLN被理解为由三个关键元素组成的网络,即:。,

1. sensors,

1. 传感器,

2. actuators, and

2. 执行器,以及

3. routers

3. 路由器

that communicate wirelessly. The aim of the following sections (3.1.1, 3.1.2, and 3.1.3) is to illustrate the functional nature of a sensor, actuator, and router in this context. That said, it must be understood that these functionalities are not exclusive. A particular device may act as a simple router or may alternatively be a router equipped with a sensing functionality, in which case it will be seen as a "regular" router as far as routing is concerned.

无线通信的。以下章节(3.1.1、3.1.2和3.1.3)旨在说明传感器、致动器和路由器在这种情况下的功能性质。也就是说,必须理解,这些功能不是排他性的。特定设备可以充当简单路由器,或者可以是配备有感测功能的路由器,在这种情况下,就路由而言,它将被视为“常规”路由器。

3.1.1. Sensors
3.1.1. 传感器

Sensing nodes measure a wide gamut of physical data, including but not limited to:

传感节点测量范围广泛的物理数据,包括但不限于:

1. municipal consumption data, such as smart-metering of gas, water, electricity, waste, etc.;

1. 城市消费数据,如煤气、水、电、垃圾等智能计量。;

2. meteorological data, such as temperature, pressure, humidity, UV index, strength and direction of wind, etc.;

2. 气象数据,如温度、压力、湿度、紫外线指数、风力和风向等。;

3. pollution data, such as gases (sulfur dioxide, nitrogen oxide, carbon monoxide, ozone), heavy metals (e.g., mercury), pH, radioactivity, etc.;

3. 污染数据,如气体(二氧化硫、氮氧化物、一氧化碳、臭氧)、重金属(如汞)、pH值、放射性等。;

4. ambient data, such as levels of allergens (pollen, dust), electromagnetic pollution, noise, etc.

4. 环境数据,如过敏原水平(花粉、灰尘)、电磁污染、噪音等。

Sensor nodes run applications that typically gather the measurement data and send it to data collection and processing application(s) on other node(s) (often outside the U-LLN).

传感器节点运行的应用程序通常收集测量数据并将其发送到其他节点(通常在U-LLN之外)上的数据收集和处理应用程序。

Sensor nodes are capable of forwarding data. Sensor nodes are generally not mobile in the majority of near-future roll-outs. In many anticipated roll-outs, sensor nodes may suffer from long-term resource constraints.

传感器节点能够转发数据。在近期推出的大多数应用中,传感器节点通常不可移动。在许多预期的推出中,传感器节点可能会受到长期资源限制的影响。

A prominent example is a "smart grid" application that consists of a city-wide network of smart meters and distribution monitoring sensors. Smart meters in an urban "smart grid" application will include electric, gas, and/or water meters typically administered by one or multiple utility companies. These meters will be capable of advanced sensing functionalities such as measuring the quality of electrical service provided to a customer, providing granular interval data, or automating the detection of alarm conditions. In addition, they may be capable of advanced interactive functionalities, which may invoke an actuator component, such as remote service disconnect or remote demand reset. More advanced scenarios include demand response systems for managing peak load, and distribution automation systems to monitor the infrastructure that delivers energy throughout the urban environment. Sensor nodes capable of providing this type of functionality may sometimes be referred to as Advanced Metering Infrastructure (AMI).

一个突出的例子是“智能电网”应用程序,该应用程序由城市范围的智能电表和配电监控传感器网络组成。城市“智能电网”应用中的智能电表将包括通常由一家或多家公用事业公司管理的电、气和/或水表。这些仪表将具有先进的传感功能,如测量向客户提供的电气服务质量、提供粒度间隔数据或自动检测报警条件。此外,它们可以具有高级交互功能,可以调用执行器组件,例如远程服务断开或远程需求重置。更高级的场景包括用于管理峰值负荷的需求响应系统,以及用于监控在整个城市环境中提供能源的基础设施的配电自动化系统。能够提供这种功能的传感器节点有时被称为高级计量基础设施(AMI)。

3.1.2. Actuators
3.1.2. 执行器

Actuator nodes are capable of controlling urban devices; examples are street or traffic lights. They run applications that receive instructions from control applications on other nodes (possibly outside the U-LLN). The amount of actuator points is well below the number of sensing nodes. Some sensing nodes may include an actuator component, e.g., an electric meter node with integrated support for remote service disconnect. Actuators are capable of forwarding data. Actuators are not likely to be mobile in the majority of near-future roll-outs. Actuator nodes may also suffer from long-term resource constraints, e.g., in the case where they are battery powered.

执行器节点能够控制城市设备;例如街灯或交通灯。它们运行从其他节点(可能在U-LLN之外)上的控制应用程序接收指令的应用程序。执行器点的数量远低于传感节点的数量。一些传感节点可包括致动器组件,例如,具有远程服务断开集成支持的电表节点。执行器能够转发数据。在近期推出的大多数产品中,执行机构不太可能是移动式的。执行器节点也可能受到长期资源限制,例如,在电池供电的情况下。

3.1.3. Routers
3.1.3. 路由器

Routers generally act to close coverage and routing gaps within the interior of the U-LLN; examples of their use are:

路由器通常用于闭合U-LLN内部的覆盖范围和路由间隙;其使用示例如下:

1. prolong the U-LLN's lifetime,

1. 延长U-LLN的寿命,

2. balance nodes' energy depletion, and

2. 平衡节点的能量消耗,以及

3. build advanced sensing infrastructures.

3. 建设先进的传感基础设施。

There can be several routers supporting the same U-LLN; however, the number of routers is well below the amount of sensing nodes. The routers are generally not mobile, i.e., fixed to a random or pre-planned location. Routers may, but generally do not, suffer from any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap. Routers differ from actuator and sensing nodes in that they neither control nor sense. That being said, a sensing node or actuator may also be a router within the U-LLN.

可以有多个路由器支持同一个U-LLN;然而,路由器的数量远低于感测节点的数量。路由器通常不可移动,即固定在随机或预先计划的位置。路由器可能,但通常不会,遭受任何形式的(长期)资源约束,除非它们需要小且足够便宜。路由器不同于执行器和传感节点,因为它们既不控制也不感知。也就是说,感测节点或致动器也可以是U-LLN内的路由器。

Some routers provide access to wider infrastructures, such as the Internet, and are named Low-Power and Lossy Network Border Routers (LBRs) in that context.

一些路由器提供对更广泛基础设施的访问,如互联网,在这种情况下被称为低功耗和有损网络边界路由器(LBR)。

LBR nodes in particular may also run applications that communicate with sensor and actuator nodes (e.g., collecting and processing data from sensor applications, or sending instructions to actuator applications).

LBR节点尤其可以运行与传感器和致动器节点通信的应用程序(例如,从传感器应用程序收集和处理数据,或向致动器应用程序发送指令)。

3.2. Topology
3.2. 拓扑学

Whilst millions of sensing nodes may very well be deployed in an urban area, they are likely to be associated with more than one network. These networks may or may not communicate between one another. The number of sensing nodes deployed in the urban environment in support of some applications is expected to be in the order of 10^2 to 10^7; this is still very large and unprecedented in current roll-outs.

虽然数百万个传感节点很可能部署在城市地区,但它们可能与多个网络相关联。这些网络可以相互通信,也可以不相互通信。部署在城市环境中支持某些应用的传感节点数量预计为10^2到10^7;这在当前的推出中仍然是非常大和前所未有的。

Deployment of nodes is likely to happen in batches, e.g., boxes of hundreds to thousands of nodes arrive and are deployed. The location of the nodes is random within given topological constraints, e.g., placement along a road, river, or at individual residences.

节点的部署可能成批进行,例如,成箱成百上千的节点到达并部署。节点的位置在给定的拓扑约束内是随机的,例如,沿道路、河流或单个住宅的位置。

3.3. Resource Constraints
3.3. 资源限制

The nodes are highly resource constrained, i.e., cheap hardware, low memory, and no infinite energy source. Different node powering mechanisms are available, such as:

这些节点具有高度的资源约束,即廉价硬件、低内存和无无限能源。可以使用不同的节点供电机制,例如:

1. non-rechargeable battery;

1. 非充电电池;

2. rechargeable battery with regular recharging (e.g., sunlight);

2. 定期充电的可充电电池(如阳光);

3. rechargeable battery with irregular recharging (e.g., opportunistic energy scavenging);

3. 不定期充电的可充电电池(例如,机会主义能量清除);

4. capacitive/inductive energy provision (e.g., passive Radio Frequency IDentification (RFID));

4. 电容/感应能量供应(例如,无源射频识别(RFID));

5. always on (e.g., powered electricity meter).

5. 始终打开(例如,电动电表)。

In the case of a battery-powered sensing node, the battery shelf life is usually in the order of 10 to 15 years, rendering network lifetime maximization with battery-powered nodes beyond this lifespan useless.

在电池供电的传感节点的情况下,电池的保质期通常为10到15年,因此电池供电节点的网络寿命最大化超过该寿命是无用的。

The physical and electromagnetic distances between the three key elements, i.e., sensors, actuators, and routers, can generally be very large, i.e., from several hundreds of meters to one kilometer. Not every field node is likely to reach the LBR in a single hop, thereby requiring suitable routing protocols that manage the information flow in an energy-efficient manner.

传感器、执行器和路由器这三个关键元件之间的物理和电磁距离通常非常大,从几百米到一公里不等。并非每个现场节点都可能在单跳中到达LBR,因此需要以节能方式管理信息流的合适路由协议。

3.4. Link Reliability
3.4. 链路可靠性

The links between the network elements are volatile due to the following set of non-exclusive effects:

由于以下一组非排他性影响,网络元素之间的链路是不稳定的:

1. packet errors due to wireless channel effects;

1. 无线信道效应导致的数据包错误;

2. packet errors due to MAC (Medium Access Control) (e.g., collision);

2. MAC(媒体访问控制)导致的数据包错误(例如,冲突);

3. packet errors due to interference from other systems;

3. 由于来自其他系统的干扰而导致的数据包错误;

4. link unavailability due to network dynamicity; etc.

4. 网络动态性导致链路不可用;等

The wireless channel causes the received power to drop below a given threshold in a random fashion, thereby causing detection errors in the receiving node. The underlying effects are path loss, shadowing and fading.

无线信道导致接收功率以随机方式下降到给定阈值以下,从而导致接收节点中的检测错误。潜在的影响是路径损失、阴影和褪色。

Since the wireless medium is broadcast in nature, nodes in their communication radios require suitable medium access control protocols that are capable of resolving any arising contention. Some available protocols may not be able to prevent packets of neighboring nodes from colliding, possibly leading to a high Packet Error Rate (PER) and causing a link outage.

由于无线媒体本质上是广播的,因此其通信无线电中的节点需要能够解决任何产生的争用的合适的媒体访问控制协议。某些可用协议可能无法防止相邻节点的数据包发生冲突,可能导致高数据包错误率(PER)并导致链路中断。

Furthermore, the outdoor deployment of U-LLNs also has implications for the interference temperature and hence link reliability and range if Industrial, Scientific, and Medical (ISM) bands are to be used. For instance, if the 2.4 GHz ISM band is used to facilitate communication between U-LLN nodes, then heavily loaded Wireless Local Area Network (WLAN) hot-spots may become a detrimental performance factor, leading to high PER and jeopardizing the functioning of the U-LLN.

此外,如果要使用工业、科学和医学(ISM)频段,U-LLN的室外部署也会影响干扰温度,从而影响链路的可靠性和范围。例如,如果2.4 GHz ISM频带用于促进U-LLN节点之间的通信,则重负载无线局域网(WLAN)热点可能成为有害的性能因素,导致高PER并危及U-LLN的功能。

Finally, nodes appearing and disappearing causes dynamics in the network that can yield link outages and changes of topologies.

最后,节点的出现和消失会导致网络中的动态变化,从而导致链路中断和拓扑变化。

4. Urban LLN Application Scenarios
4. 城市LLN应用场景

Urban applications represent a special segment of LLNs with its unique set of requirements. To facilitate the requirements discussion in Section 6, this section lists a few typical but not exhaustive deployment problems and usage cases of U-LLN.

城市应用是LLN的一个特殊部分,有其独特的要求。为了便于第6节中的需求讨论,本节列出了一些典型但并非详尽的U-LLN部署问题和使用案例。

4.1. Deployment of Nodes
4.1. 节点的部署

Contrary to other LLN applications, deployment of nodes is likely to happen in batches out of a box. Typically, hundreds to thousands of nodes are being shipped by the manufacturer with pre-programmed functionalities which are then rolled-out by a service provider or subcontracted entities. Prior to or after roll-out, the network needs to be ramped-up. This initialization phase may include, among others, allocation of addresses, (possibly hierarchical) roles in the network, synchronization, determination of schedules, etc.

与其他LLN应用程序相反,节点的部署很可能是开箱即用的成批进行的。通常,制造商将数百到数千个节点与预先编程的功能一起装运,然后由服务提供商或分包实体推出这些功能。在推出之前或之后,网络需要升级。除其他外,该初始化阶段可包括地址分配(可能是分层的)网络角色、同步、时间表的确定等。

If initialization is performed prior to roll-out, all nodes are likely to be in one another's one-hop radio neighborhood. Pre-programmed Media Access Control (MAC) and routing protocols may hence fail to function properly, thereby wasting a large amount of energy. Whilst the major burden will be on resolving MAC conflicts, any proposed U-LLN routing protocol needs to cater for such a case. For instance, zero-configuration and network address allocation needs to be properly supported, etc.

如果在推出之前执行初始化,则所有节点都可能位于彼此的单跳无线电邻居中。因此,预编程媒体访问控制(MAC)和路由协议可能无法正常工作,从而浪费大量能源。虽然解决MAC冲突将是主要负担,但任何提议的U-LLN路由协议都需要满足这种情况。例如,需要正确支持零配置和网络地址分配等。

After roll-out, nodes will have a finite set of one-hop neighbors, likely of low cardinality (in the order of 5 to 10). However, some nodes may be deployed in areas where there are hundreds of neighboring devices. In the resulting topology, there may be regions where many (redundant) paths are possible through the network. Other regions may be dependent on critical links to achieve connectivity with the rest of the network. Any proposed LLN routing protocol ought to support the autonomous self-organization and self-configuration of the network at lowest possible energy cost [Lu2007], where autonomy is understood to be the ability of the network to operate without external influence. The result of such organization should be that each node or set of nodes is uniquely addressable so as to facilitate the set up of schedules, etc.

推出后,节点将有一组有限的单跳邻居,可能基数较低(顺序为5到10)。但是,有些节点可能部署在有数百个相邻设备的区域。在生成的拓扑中,可能存在通过网络的多条(冗余)路径的区域。其他区域可能依赖于关键链路来实现与网络其余部分的连接。任何提议的LLN路由协议都应该以尽可能低的能量成本支持网络的自主自组织和自配置[Lu2007],其中自主性被理解为网络在没有外部影响的情况下运行的能力。这种组织的结果应该是每个节点或节点集都是唯一可寻址的,以便于建立时间表等。

Unless exceptionally needed, broadcast forwarding schemes are not advised in urban sensor networking environments.

除非有特殊需要,否则不建议在城市传感器网络环境中使用广播转发方案。

4.2. Association and Disassociation/Disappearance of Nodes
4.2. 节点的关联和解除关联/消失

After the initialization phase and possibly some operational time, new nodes may be injected into the network as well as existing nodes removed from the network. The former might be because a removed node is replaced as part of maintenance, or new nodes are added because more sensors for denser readings/actuations are needed, or because routing protocols report connectivity problems. The latter might be because a node's battery is depleted, the node is removed for maintenance, the node is stolen or accidentally destroyed, etc.

在初始化阶段和可能的一些操作时间之后,可以将新节点注入网络以及从网络中移除的现有节点。前者可能是因为在维护过程中更换了一个已移除的节点,或者是因为需要更多用于更密集读数/驱动的传感器,或者是因为路由协议报告了连接问题而添加了新节点。后者可能是因为节点的电池耗尽、节点被移除以进行维护、节点被盗或意外损坏等。

The protocol(s) hence should be able to convey information about malfunctioning nodes that may affect or jeopardize the overall routing efficiency, so that self-organization and self-configuration capabilities of the sensor network might be solicited to facilitate the appropriate reconfiguration. This information may include, e.g., exact or relative geographical position, etc. The reconfiguration may include the change of hierarchies, routing paths, packet forwarding schedules, etc. Furthermore, to inform the LBR(s) of the node's arrival and association with the network as well as freshly associated nodes about packet forwarding schedules, roles, etc., appropriate updating mechanisms should be supported.

因此,协议应能够传送关于可能影响或危害整体路由效率的故障节点的信息,以便可请求传感器网络的自组织和自配置能力以促进适当的重新配置。该信息可包括(例如)准确或相对地理位置等。重新配置可包括层次结构、路由路径、分组转发调度等的改变。此外,将节点的到达和与网络的关联以及新关联节点的分组转发调度通知LBR,应支持适当的更新机制。

4.3. Regular Measurement Reporting
4.3. 定期测量报告

The majority of sensing nodes will be configured to report their readings on a regular basis. The frequency of data sensing and reporting may be different but is generally expected to be fairly low, i.e., in the range of once per hour, per day, etc. The ratio between data sensing and reporting frequencies will determine the memory and data aggregation capabilities of the nodes. Latency of an

大多数传感节点将配置为定期报告其读数。数据感应和报告的频率可能不同,但通常预期相当低,即在每小时一次、每天一次等范围内。数据感应和报告频率之间的比率将决定节点的内存和数据聚合能力。延迟时间

end-to-end delivery and acknowledgements of a successful data delivery may not be vital as sensing outages can be observed at data collection applications -- when, for instance, there is no reading arriving from a given sensor or cluster of sensors within a day. In this case, a query can be launched to check upon the state and availability of a sensing node or sensing cluster.

端到端交付和对成功数据交付的确认可能并不重要,因为在数据采集应用程序中可以观察到感知中断——例如,一天内没有来自给定传感器或传感器组的读数。在这种情况下,可以启动查询以检查感测节点或感测集群的状态和可用性。

It is not uncommon to gather data on a few servers located outside of the U-LLN. In such cases, a large number of highly directional unicast flows from the sensing nodes or sensing clusters are likely to transit through a LBR. Thus, the protocol(s) should be optimized to support a large number of unicast flows from the sensing nodes or sensing clusters towards a LBR, or highly directed multicast or anycast flows from the nodes towards multiple LBRs.

在位于U-LLN之外的几个服务器上收集数据并不少见。在这种情况下,来自感测节点或感测集群的大量高度定向的单播流可能通过LBR传输。因此,应优化协议以支持从感测节点或感测集群到LBR的大量单播流,或从节点到多个LBR的高度定向多播或选播流。

Route computation and selection may depend on the transmitted information, the frequency of reporting, the amount of energy remaining in the nodes, the recharging pattern of energy-scavenged nodes, etc. For instance, temperature readings could be reported every hour via one set of battery-powered nodes, whereas air quality indicators are reported only during the daytime via nodes powered by solar energy. More generally, entire routing areas may be avoided (e.g., at night) but heavily used during the day when nodes are scavenging energy from sunlight.

路由计算和选择可能取决于传输的信息、报告频率、节点中剩余的能量量、能量清除节点的充电模式等。例如,可通过一组电池供电的节点每小时报告一次温度读数,而空气质量指标仅在白天通过太阳能供电的节点报告。更一般地说,可以避免整个路由区域(例如,在夜间),但在白天节点从阳光中清除能量时会大量使用。

4.4. Queried Measurement Reporting
4.4. 查询测量报告

Occasionally, network-external data queries can be launched by one or several applications. For instance, it is desirable to know the level of pollution at a specific point or along a given road in the urban environment. The queries' rates of occurrence are not regular but rather random, where heavy-tail distributions seem appropriate to model their behavior. Queries do not necessarily need to be reported back to the same node from where the query was launched. Round-trip times, i.e., from the launch of a query from a node until the delivery of the measured data to a node, are of importance. However, they are not very stringent where latencies should simply be sufficiently smaller than typical reporting intervals; for instance, in the order of seconds or minutes. The routing protocol(s) should consider the selection of paths with appropriate (e.g., latency) metrics to support queried measurement reporting. To facilitate the query process, U-LLN devices should support unicast and multicast routing capabilities.

偶尔,一个或多个应用程序可以启动网络外部数据查询。例如,需要了解城市环境中特定点或特定道路沿线的污染水平。查询的发生率不是规则的,而是随机的,其中重尾分布似乎适合模拟它们的行为。查询不一定需要报告回发起查询的同一节点。往返时间非常重要,即从节点启动查询到将测量数据交付给节点。然而,当延迟应比典型的报告间隔小得多时,它们并不十分严格;例如,以秒或分钟为单位。路由协议(S)应考虑选择适当的路径(例如,延迟)度量来支持查询的测量报告。为了方便查询过程,U-LLN设备应支持单播和多播路由功能。

The same approach is also applicable for schedule update, provisioning of patches and upgrades, etc. In this case, however, the provision of acknowledgements and the support of unicast, multicast, and anycast are of importance.

同样的方法也适用于计划更新、提供补丁和升级等。但是,在这种情况下,提供确认和支持单播、多播和选播非常重要。

4.5. Alert Reporting
4.5. 警报报告

Rarely, the sensing nodes will measure an event that classifies as an alarm where such a classification is typically done locally within each node by means of a pre-programmed or prior-diffused threshold. Note that on approaching the alert threshold level, nodes may wish to change their sensing and reporting cycles. An alarm is likely being registered by a plurality of sensing nodes where the delivery of a single alert message with its location of origin suffices in most, but not all, cases. One example of alert reporting is if the level of toxic gases rises above a threshold; thereupon, the sensing nodes in the vicinity of this event report the danger. Another example of alert reporting is when a recycling glass container -- equipped with a sensor measuring its level of occupancy -- reports that the container is full and hence needs to be emptied.

很少情况下,传感节点将测量分类为报警的事件,其中此类分类通常通过预先编程或预先扩散的阈值在每个节点内本地完成。请注意,在接近警报阈值级别时,节点可能希望更改其感知和报告周期。警报很可能由多个感测节点注册,其中在大多数(但不是所有)情况下,具有其起源位置的单个警报消息的传递就足够了。警报报告的一个例子是,有毒气体的水平高于阈值;因此,该事件附近的传感节点报告危险。警报报告的另一个例子是,一个装有传感器的回收玻璃容器报告容器已满,因此需要清空。

Routes clearly need to be unicast (towards one LBR) or multicast (towards multiple LBRs). Delays and latencies are important; however, for a U-LLN deployed in support of a typical application, deliveries within seconds should suffice in most of the cases.

路由显然需要单播(朝向一个LBR)或多播(朝向多个LBR)。延迟和延迟很重要;然而,对于为支持典型应用而部署的U-LLN,在大多数情况下,几秒钟内交付就足够了。

5. Traffic Pattern
5. 交通模式

Unlike traditional ad hoc networks, the information flow in U-LLNs is highly directional. There are three main flows to be distinguished:

与传统的ad hoc网络不同,U-LLN中的信息流具有高度的方向性。需要区分的主要流程有三种:

1. sensed information from the sensing nodes to applications outside the U-LLN, going through one or a subset of the LBR(s);

1. 通过LBR的一个或一个子集从感测节点到U-LLN之外的应用的感测信息;

2. query requests from applications outside the U-LLN, going through the LBR(s) towards the sensing nodes;

2. 来自U-LLN之外的应用程序的查询请求,通过LBR到达感测节点;

3. control information from applications outside the U-LLN, going through the LBR(s) towards the actuators.

3. 来自U-LLN以外的应用程序的控制信息,通过LBR流向执行器。

Some of the flows may need the reverse route for delivering acknowledgements. Finally, in the future, some direct information flows between field devices without LBRs may also occur.

一些流可能需要反向路由来传递确认。最后,在未来,也可能出现没有LBR的现场设备之间的一些直接信息流。

Sensed data is likely to be highly correlated in space, time, and observed events; an example of the latter is when temperature increase and humidity decrease as the day commences. Data may be sensed and delivered at different rates with both rates being typically fairly low, i.e., in the range of minutes, hours, days, etc. Data may be delivered regularly according to a schedule or a regular query; it may also be delivered irregularly after an externally triggered query; it may also be triggered after a sudden network-internal event or alert. Schedules may be driven by, for

感测数据可能在空间、时间和观测事件上高度相关;后者的一个例子是,随着一天的开始,温度升高,湿度降低。可以以不同的速率感测和交付数据,这两种速率通常相当低,即在分钟、小时、天等范围内。可以根据时间表或定期查询定期交付数据;也可能在外部触发查询后不定期交付;它也可能在突发网络内部事件或警报后触发。时间表可能由以下因素驱动:

example, a smart-metering application where data is expected to be delivered every hour, or an environmental monitoring application where a battery-powered node is expected to report its status at a specific time once a day. Data delivery may trigger acknowledgements or maintenance traffic in the reverse direction. The network hence needs to be able to adjust to the varying activity duty cycles, as well as to periodic and sporadic traffic. Also, sensed data ought to be secured and locatable.

例如,智能计量应用程序(其中数据预计每小时传输一次)或环境监测应用程序(其中电池供电节点预计每天一次在特定时间报告其状态)。数据传递可能会触发反向确认或维护通信。因此,网络需要能够适应不同的活动占空比,以及周期性和零星的流量。此外,传感数据应该是安全的和可定位的。

Some data delivery may have tight latency requirements, for example, in a case such as a live meter reading for customer service in a smart-metering application, or in a case where a sensor reading response must arrive within a certain time in order to be useful. The network should take into consideration that different application traffic may require different priorities in the selection of a route when traversing the network, and that some traffic may be more sensitive to latency.

一些数据传送可能具有严格的延迟要求,例如,在智能计量应用程序中为客户服务进行实时抄表的情况下,或者在传感器读取响应必须在特定时间内到达以便有用的情况下。网络应考虑到,在穿越网络时,不同的应用流量在选择路由时可能需要不同的优先级,并且一些流量可能对延迟更敏感。

A U-LLN should support occasional large-scale traffic flows from sensing nodes through LBRs (to nodes outside the U-LLN), such as system-wide alerts. In the example of an AMI U-LLN, this could be in response to events such as a city-wide power outage. In this scenario, all powered devices in a large segment of the network may have lost power and be running off of a temporary "last gasp" source such as a capacitor or small battery. A node must be able to send its own alerts toward an LBR while continuing to forward traffic on behalf of other devices that are also experiencing an alert condition. The network needs to be able to manage this sudden large traffic flow.

U-LLN应支持偶尔从传感节点通过LBR(到U-LLN之外的节点)的大规模流量,例如系统范围的警报。在AMI U-LLN的示例中,这可能是对城市范围停电等事件的响应。在这种情况下,网络大部分中的所有通电设备都可能断电,并耗尽临时“最后关头”电源,如电容器或小电池。节点必须能够向LBR发送自己的警报,同时继续代表也遇到警报情况的其他设备转发流量。网络需要能够管理这种突然的大流量。

A U-LLN may also need to support efficient large-scale messaging to groups of actuators. For example, an AMI U-LLN supporting a city-wide demand response system will need to efficiently broadcast demand-response control information to a large subset of actuators in the system.

U-LLN可能还需要支持对执行器组的高效大规模消息传递。例如,支持城市范围需求响应系统的AMI U-LLN将需要有效地将需求响应控制信息广播到系统中的大部分执行器。

Some scenarios will require internetworking between the U-LLN and another network, such as a home network. For example, an AMI application that implements a demand-response system may need to forward traffic from a utility, across the U-LLN, into a home automation network. A typical use case would be to inform a customer of incentives to reduce demand during peaks, or to automatically adjust the thermostat of customers who have enrolled in such a demand management program. Subsequent traffic may be triggered to flow back through the U-LLN to the utility.

某些场景将需要U-LLN和另一个网络(如家庭网络)之间的互联。例如,实现需求响应系统的AMI应用程序可能需要通过U-LLN将来自公用事业的流量转发到家庭自动化网络。一个典型的用例是通知客户在高峰期间减少需求的激励措施,或者自动调整已加入此类需求管理计划的客户的恒温器。随后的流量可能会被触发,通过U-LLN流回公用设施。

6. Requirements of Urban-LLN Applications
6. 城市LLN应用的要求

Urban Low-Power and Lossy Network applications have a number of specific requirements related to the set of operating conditions, as exemplified in the previous sections.

城市低功率和有损网络应用有许多与操作条件相关的具体要求,如前几节所示。

6.1. Scalability
6.1. 可伸缩性

The large and diverse measurement space of U-LLN nodes -- coupled with the typically large urban areas -- will yield extremely large network sizes. Current urban roll-outs are composed of sometimes more than one hundred nodes; future roll-outs, however, may easily reach numbers in the tens of thousands to millions. One of the utmost important LLN routing protocol design criteria is hence scalability.

U-LLN节点的大而多样的测量空间——加上典型的大城市区域——将产生非常大的网络规模。目前的城市铺展有时由100多个节点组成;然而,未来的推广可能很容易达到数万到数百万的数量。因此,最重要的LLN路由协议设计标准之一是可伸缩性。

The routing protocol(s) MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each.

路由协议必须能够支持将大量感测节点组织到区域中,每个区域包含10^2到10^4个感测节点。

The routing protocol(s) MUST be scalable so as to accommodate a very large and increasing number of nodes without deteriorating selected performance parameters below configurable thresholds. The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of configurable size.

路由协议必须是可伸缩的,以适应非常大且数量不断增加的节点,而不会使选定的性能参数降低到可配置的阈值以下。路由协议应支持将大量节点组织到可配置大小的区域中。

6.2. Parameter-Constrained Routing
6.2. 参数约束布线

Batteries in some nodes may deplete quicker than in others; the existence of one node for the maintenance of a routing path may not be as important as of another node; the energy-scavenging methods may recharge the battery at regular or irregular intervals; some nodes may have a constant power source; some nodes may have a larger memory and are hence be able to store more neighborhood information; some nodes may have a stronger CPU and are hence able to perform more sophisticated data aggregation methods, etc.

某些节点中的电池可能比其他节点中的电池消耗更快;用于维护路由路径的一个节点的存在可能不如另一个节点的存在重要;能量清除方法可以定期或不定期给蓄电池充电;一些节点可能具有恒定的电源;一些节点可能具有更大的内存,因此能够存储更多的邻域信息;一些节点可能具有更强的CPU,因此能够执行更复杂的数据聚合方法等。

To this end, the routing protocol(s) MUST support parameter-constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph. In other words, the routing protocol MUST be able to advertise node capabilities that will be exclusively used by the routing protocol engine for routing decision. For the sake of example, such a capability could be related to the node capability itself (e.g., remaining power) or some application that could influence routing (e.g., capability to aggregate data).

为此目的,路由协议必须支持参数约束路由,在上一段中已经给出了此类参数(CPU、内存大小、电池电量等)的示例。换句话说,路由协议必须能够公布路由协议引擎将专门用于路由决策的节点功能。例如,这种能力可能与节点能力本身(例如,剩余功率)或可能影响路由的某个应用程序(例如,聚合数据的能力)有关。

Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select, and install different paths towards the same destination, depending on the nature of the traffic. Such functionality in support of, for example, data aggregation, may imply use of some mechanisms to mark/tag the traffic for appropriate routing decision using the IPv6 packet format (e.g., use of Diffserv Code Point (DSCP), Flow Label) based on an upper-layer marking decision. From this perspective, such nodes MAY use node capabilities (e.g., to act as an aggregator) in conjunction with the anycast endpoints and packet marking to route the traffic.

城市传感器网络内的路由应要求U-LLN节点根据流量的性质,动态计算、选择和安装通向同一目的地的不同路径。例如,支持数据聚合的这种功能性可能意味着使用一些机制来标记/标记流量,以便使用基于上层标记决策的IPv6分组格式(例如,使用Diffserv码点(DSCP)、流标签)进行适当的路由决策。从这个角度来看,这样的节点可以结合选播端点和分组标记使用节点能力(例如,充当聚合器)来路由流量。

6.3. Support of Autonomous and Alien Configuration
6.3. 支持自主和外来配置

With the large number of nodes, manually configuring and troubleshooting each node is not efficient. The scale and the large number of possible topologies that may be encountered in the U-LLN encourages the development of automated management capabilities that may (partly) rely upon self-organizing techniques. The network is expected to self-organize and self-configure according to some prior defined rules and protocols, as well as to support externally triggered configurations (for instance, through a commissioning tool that may facilitate the organization of the network at a minimum energy cost).

由于节点数量庞大,手动配置每个节点并对其进行故障排除并不高效。在U-LLN中可能遇到的规模和大量可能的拓扑结构鼓励了(部分)依赖自组织技术的自动化管理能力的发展。预计网络将根据一些先前定义的规则和协议进行自组织和自配置,并支持外部触发的配置(例如,通过调试工具,以最低的能源成本促进网络的组织)。

To this end, the routing protocol(s) MUST provide a set of features including zero-configuration at network ramp-up, (network-internal) self-organization and configuration due to topological changes, and the ability to support (network-external) patches and configuration updates. For the latter, the protocol(s) MUST support multicast and anycast addressing. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network.

为此,路由协议必须提供一组功能,包括网络爬坡时的零配置、(网络内部)拓扑变化引起的自组织和配置,以及支持(网络外部)补丁和配置更新的能力。对于后者,协议必须支持多播和选播寻址。协议还应支持网络中现场设备组的形成和识别。

The routing protocol(s) SHOULD be able to dynamically adapt, e.g., through the application of appropriate routing metrics, to ever-changing conditions of communication (possible degradation of quality of service (QoS), variable nature of the traffic (real-time versus non-real-time, sensed data versus alerts), node mobility, a combination thereof, etc.).

路由协议应能够动态地适应(例如,通过应用适当的路由度量)不断变化的通信条件(服务质量(QoS)的可能退化、流量的可变性质(实时与非实时、感测数据与警报)、节点移动性、其组合等)。

The routing protocol(s) SHOULD be able to dynamically compute, select, and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or a LBR according to the service-specific and traffic-specific QoS, traffic engineering, and routing security policies that

路由协议应当能够动态地计算、选择并可能地优化(多个)路径,该路径将由参与设备使用,以根据特定于服务和特定于流量的QoS、流量工程和路由安全策略将流量转发到执行器和/或LBR,这些策略是:

will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g., a metropolitan area composed of clusters of sensors).

必须在路由域(即,由全球唯一实体管理的一组网络设备)或该域的一个区域(例如,由传感器集群组成的城域)的范围内实施。

6.4. Support of Highly Directed Information Flows
6.4. 支持高度定向的信息流

As pointed out in Section 4.3, it is not uncommon to gather data on a few servers located outside of the U-LLN. In this case, the reporting of the data readings by a large amount of spatially dispersed nodes towards a few LBRs will lead to highly directed information flows. For instance, a suitable addressing scheme can be devised that facilitates the data flow. Also, as one gets closer to the LBR, the traffic concentration increases, which may lead to high load imbalances in node usage.

正如第4.3节所指出的,在U-LLN之外的几个服务器上收集数据并不少见。在这种情况下,大量空间分散的节点向几个lbr报告数据读数将导致高度定向的信息流。例如,可以设计适当的寻址方案来促进数据流。此外,随着人们越来越接近LBR,流量集中度会增加,这可能导致节点使用中的高负载不平衡。

To this end, the routing protocol(s) SHOULD support and utilize the large number of highly directed traffic flows to facilitate scalability and parameter-constrained routing.

为此,路由协议应支持并利用大量高度定向的业务流,以促进可伸缩性和参数约束路由。

The routing protocol MUST be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination.

路由协议必须能够通过动态计算和选择通向同一目的地的多条路径来适应流量突发。

6.5. Support of Multicast and Anycast
6.5. 支持多播和选播

Routing protocols activated in urban sensor networks MUST support unicast (traffic is sent to a single field device), multicast (traffic is sent to a set of devices that are subscribed to the same multicast group), and anycast (where multiple field devices are configured to accept traffic sent on a single IP anycast address) transmission schemes.

城市传感器网络中激活的路由协议必须支持单播(流量发送到单个现场设备)、多播(流量发送到订阅同一多播组的一组设备)和选播(其中多个现场设备配置为接受在单个IP选播地址上发送的流量)传输方案。

The support of unicast, multicast, and anycast also has an implication on the addressing scheme, but it is beyond the scope of this document that focuses on the routing requirements.

对单播、多播和选播的支持对寻址方案也有影响,但它超出了本文档重点介绍路由要求的范围。

Some urban sensing systems may require low-level addressing of a group of nodes in the same subnet, or for a node representative of a group of nodes, without any prior creation of multicast groups. Such addressing schemes, where a sender can form an addressable group of receivers, are not currently supported by IPv6, and not further discussed in this specification [ROLL-HOME].

一些城市传感系统可能需要对同一子网中的一组节点或代表一组节点的节点进行低级别寻址,而无需事先创建多播组。这种寻址方案,其中发送方可以形成一个可寻址的接收方组,目前不受IPv6支持,本规范[ROLL-HOME]中没有进一步讨论。

The network SHOULD support internetworking when identical protocols are used, while giving attention to routing security implications of interfacing, for example, a home network with a utility U-LLN. The

当使用相同的协议时,网络应支持互连,同时注意接口的路由安全影响,例如,家庭网络与公用设施U-LLN。这个

network may support the ability to interact with another network using a different protocol, for example, by supporting route redistribution.

网络可支持使用不同协议与另一网络交互的能力,例如,通过支持路由重新分配。

6.6. Network Dynamicity
6.6. 网络动态性

Although mobility is assumed to be low in urban LLNs, network dynamicity due to node association, disassociation, and disappearance, as well as long-term link perturbations is not negligible. This in turn impacts reorganization and reconfiguration convergence as well as routing protocol convergence.

虽然假设城市LLN的移动性较低,但由于节点关联、分离和消失以及长期链路扰动而导致的网络动态性不容忽视。这反过来会影响重组和重新配置的收敛性以及路由协议的收敛性。

To this end, local network dynamics SHOULD NOT impact the entire network to be reorganized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. The routing protocol(s) SHOULD support appropriate mechanisms in order to be informed of the association, disassociation, and disappearance of nodes. The routing protocol(s) SHOULD support appropriate updating mechanisms in order to be informed of changes in connectivity. The routing protocol(s) SHOULD use this information to initiate protocol-specific mechanisms for reorganization and reconfiguration as necessary to maintain overall routing efficiency. Convergence and route establishment times SHOULD be significantly lower than the smallest reporting interval.

为此,本地网络动态不应影响要重组或重新配置的整个网络;然而,网络应进行局部优化,以适应遇到的变化。路由协议应支持适当的机制,以便通知节点的关联、解除关联和消失。路由协议应支持适当的更新机制,以便通知连接的变化。路由协议应使用此信息启动特定于协议的机制,以便在必要时进行重组和重新配置,以保持总体路由效率。收敛和路线建立时间应明显低于最小报告间隔。

Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user- or node-initiated disassociation ("phased-out"), where the node has enough time to inform the network about its pending removal.

应区分节点消失(节点在未事先通知的情况下消失)和用户或节点发起的解除关联(“分阶段取消”),其中节点有足够的时间通知网络其待定的移除。

6.7. Latency
6.7. 延迟

With the exception of alert-reporting solutions and (to a certain extent) queried reporting, U-LLNs are delay tolerant as long as the information arrives within a fraction of the smallest reporting interval, e.g., a few seconds if reporting is done every 4 hours.

除警报报告解决方案和(在一定程度上)查询报告外,只要信息在最小报告间隔的一小部分内到达(例如,如果每4小时报告几秒钟),U-LLN具有延迟容忍能力。

The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could, e.g., be latency).

路由协议还应支持根据不同指标(其中之一可能是延迟)进行路由的能力。

7. Security Considerations
7. 安全考虑

As every network, U-LLNs are exposed to routing security threats that need to be addressed. The wireless and distributed nature of these networks increases the spectrum of potential routing security threats. This is further amplified by the resource constraints of the nodes, thereby preventing resource-intensive routing security

与每个网络一样,U-LLN都面临路由安全威胁,需要解决这些威胁。这些网络的无线和分布式特性增加了潜在路由安全威胁的范围。节点的资源约束进一步放大了这一点,从而防止了资源密集型路由安全

approaches from being deployed. A viable routing security approach SHOULD be sufficiently lightweight that it may be implemented across all nodes in a U-LLN. These issues require special attention during the design process, so as to facilitate a commercially attractive deployment.

避免部署的方法。一种可行的路由安全方法应该足够轻量级,可以在U-LLN中的所有节点上实现。这些问题在设计过程中需要特别注意,以便于进行具有商业吸引力的部署。

The U-LLN MUST deny any node that has not been authenticated to the U-LLN and authorized to participate to the routing decision process.

U-LLN必须拒绝任何未经U-LLN身份验证并授权参与路由决策过程的节点。

An attacker SHOULD be prevented from manipulating or disabling the routing function, for example, by compromising routing control messages. To this end, the routing protocol(s) MUST support message integrity.

应防止攻击者操纵或禁用路由功能,例如,通过泄露路由控制消息。为此,路由协议必须支持消息完整性。

Further examples of routing security issues that may arise are the abnormal behavior of nodes that exhibit an egoistic conduct, such as not obeying network rules or forwarding no or false packets. Other important issues may arise in the context of denial-of-service (DoS) attacks, malicious address space allocations, advertisement of variable addresses, a wrong neighborhood, etc. The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently cause the mechanisms of the routing protocol(s) to over-consume the limited resources of LLN nodes, e.g., by constructing forwarding loops or causing excessive routing protocol overhead traffic, etc.

可能出现的路由安全问题的进一步示例是表现出利己行为的节点的异常行为,例如不遵守网络规则或转发no或false数据包。在拒绝服务(DoS)攻击、恶意地址空间分配、可变地址广告、错误邻居等情况下可能会出现其他重要问题。路由协议应支持防御DoS攻击和其他恶意或无意导致路由协议机制的企图过度消耗LLN节点的有限资源,例如,通过构建转发环路或导致过多的路由协议开销流量等。

The properties of self-configuration and self-organization that are desirable in a U-LLN introduce additional routing security considerations. Mechanisms MUST be in place to deny any node that attempts to take malicious advantage of self-configuration and self-organization procedures. Such attacks may attempt, for example, to cause DoS, drain the energy of power-constrained devices, or to hijack the routing mechanism. A node MUST authenticate itself to a trusted node that is already associated with the U-LLN before the former can take part in self-configuration or self-organization. A node that has already authenticated and associated with the U-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer. The routing protocol(s) MUST deny service to any node that has not clearly established trust with the U-LLN.

U-LLN中需要的自配置和自组织特性引入了额外的路由安全考虑。必须有机制来拒绝任何试图恶意利用自配置和自组织过程的节点。例如,此类攻击可能试图导致拒绝服务、耗尽受电源限制设备的能量或劫持路由机制。节点必须先向已与U-LLN关联的受信任节点进行自身身份验证,然后才能参与自配置或自组织。已通过身份验证并与U-LLN关联的节点必须尽可能拒绝向任何未经身份验证的对等方分配资源。路由协议必须拒绝向未明确建立与U-LLN信任的任何节点提供服务。

Consideration SHOULD be given to cases where the U-LLN may interface with other networks such as a home network. The U-LLN SHOULD NOT interface with any external network that has not established trust. The U-LLN SHOULD be capable of limiting the resources granted in support of an external network so as not to be vulnerable to DoS.

应考虑U-LLN可能与其他网络(如家庭网络)接口的情况。U-LLN不应与任何未建立信任的外部网络连接。U-LLN应能够限制为支持外部网络而授予的资源,以免易受拒绝服务攻击。

With low computation power and scarce energy resources, U-LLNs' nodes may not be able to resist any attack from high-power malicious nodes (e.g., laptops and strong radios). However, the amount of damage generated to the whole network SHOULD be commensurate with the number of nodes physically compromised. For example, an intruder taking control over a single node SHOULD NOT be able to completely deny service to the whole network.

由于计算能力低且能源稀缺,U-LLN节点可能无法抵御来自高功率恶意节点(例如笔记本电脑和强力无线电)的任何攻击。但是,对整个网络造成的损害程度应与物理上受到损害的节点数量相称。例如,控制单个节点的入侵者不应该能够完全拒绝整个网络的服务。

In general, the routing protocol(s) SHOULD support the implementation of routing security best practices across the U-LLN. Such an implementation ought to include defense against, for example, eavesdropping, replay, message insertion, modification, and man-in-the-middle attacks.

通常,路由协议应支持在整个U-LLN中实施路由安全最佳实践。这种实现应该包括防御,例如,窃听、重播、消息插入、修改和中间人攻击。

The choice of the routing security solutions will have an impact on the routing protocol(s). To this end, routing protocol(s) proposed in the context of U-LLNs MUST support authentication and integrity measures and SHOULD support confidentiality (routing security) measures.

路由安全解决方案的选择将对路由协议产生影响。为此,在U-LLN环境中提出的路由协议必须支持身份验证和完整性措施,并应支持机密性(路由安全)措施。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

8.2. Informative References
8.2. 资料性引用

[Lu2007] Lu, JL., Valois, F., Barthel, D., and M. Dohler, "FISCO: A Fully Integrated Scheme of Self-Configuration and Self-Organization for WSN", 11-15 March 2007, pp. 3370-3375, IEEE WCNC 2007, Hong Kong, China.

[Lu2007 ]卢,JL,Valois,F,Barthel,D和M. Dohler,“FISCO:WSN自配置和自组织的完全集成方案”,2007年3月11日至15日,pp.3360-375,IEEE WCNC 2007,香港,中国。

[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.

[RFC1546]帕特里奇,C.,门德斯,T.,和W.米利肯,“主持任意广播服务”,RFC15461993年11月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291]Hinden,R.和S.Deering,“IP版本6寻址体系结构”,RFC 42912006年2月。

[ROLL-BUILD] Martocci, J., Ed., De Mil, P., Vermeylen, W., and N. Riou, "Building Automation Routing Requirements in Low Power and Lossy Networks", Work in Progress, February 2009.

[ROLL-BUILD]Martocci,J.,Ed.,De Mil,P.,Vermeylen,W.,和N.Riou,“低功率和有损网络中的楼宇自动化路由要求”,正在进行的工作,2009年2月。

[ROLL-HOME] Brandt, A. and G. Porcu, "Home Automation Routing Requirements in Low Power and Lossy Networks", Work in Progress, November 2008.

[ROLL-HOME]Brandt,A.和G.Porcu,“低功耗和有损网络中的家庭自动化路由要求”,正在进行的工作,2008年11月。

[ROLL-INDUS] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low Power and Lossy Networks", Work in Progress, April 2009.

[ROLL-INDUS]Pister,K.,Ed.,Thubert,P.,Ed.,Dwars,S.,和T.Phinney,“低功率和有损网络中的工业路由要求”,正在进行的工作,2009年4月。

[ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, October 2008.

[ROLL-TERM]Vasseur,J.,“低功率和有损网络的术语”,正在进行的工作,2008年10月。

Appendix A. Acknowledgements
附录A.确认书

The in-depth feedback of JP Vasseur, Jonathan Hui, Iain Calder, and Pasi Eronen is greatly appreciated.

非常感谢JP Vasseur、Jonathan Hui、Iain Calder和Pasi Eronen的深入反馈。

Appendix B. Contributors
附录B.贡献者

Christian Jacquenet France Telecom R&D 4 rue du Clos Courtel BP 91226 35512 Cesson Sevigne France

Christian Jacquenet法国电信研发部法国塞森塞维涅路4号英国石油91226 35512

   EMail: christian.jacquenet@orange-ftgroup.com
        
   EMail: christian.jacquenet@orange-ftgroup.com
        

Giyyarpuram Madhusudan France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France

Giyyarpuram Madhusudan法国电信研发部28 Chemin du Vieux Chene 38243 Meylan Cedex France

   EMail: giyyarpuram.madhusudan@orange-ftgroup.com
        
   EMail: giyyarpuram.madhusudan@orange-ftgroup.com
        

Gabriel Chegaray France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France

Gabriel Chegaray法国电信研发部28 Chemin du Vieux Chene 38243 Meylan Cedex France

   EMail: gabriel.chegaray@orange-ftgroup.com
        
   EMail: gabriel.chegaray@orange-ftgroup.com
        

Authors' Addresses

作者地址

Mischa Dohler (editor) CTTC Parc Mediterrani de la Tecnologia Av. Canal Olimpic S/N 08860 Castelldefels, Barcelona Spain

米沙·多勒(编辑)CTTC地中海技术研究中心。西班牙巴塞罗那卡斯特尔德费尔斯运河奥林匹克公园S/N 08860

   EMail: mischa.dohler@cttc.es
        
   EMail: mischa.dohler@cttc.es
        

Thomas Watteyne (editor) Berkeley Sensor & Actuator Center, University of California, Berkeley 497 Cory Hall #1774 Berkeley, CA 94720-1774 USA

Thomas Watteyne(编辑)伯克利传感器和执行中心,加利福尼亚大学,伯克利497 Cory Hall Cory Hall 1774伯克利,CA947 201774美国

   EMail: watteyne@eecs.berkeley.edu
        
   EMail: watteyne@eecs.berkeley.edu
        

Tim Winter (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, MD 20874 USA

蒂姆·温特(编辑)埃卡系统20201世纪大道。美国马里兰州日尔曼镇250号套房,邮编20874

   EMail: wintert@acm.org
        
   EMail: wintert@acm.org
        

Dominique Barthel (editor) France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France

Dominique Barthel(编辑)法国电信研发部28 Chemin du Vieux Chene 38243 Meylan Cedex France

   EMail: Dominique.Barthel@orange-ftgroup.com
        
   EMail: Dominique.Barthel@orange-ftgroup.com