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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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 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.
アーバン低消費電力とロッシーネットワーク（U-LLNs）のアプリケーション固有のルーティング要件は、この文書で提示されています。近い将来には、感知し、人々の生活条件を改善するためだけでなく、ますます厳しい環境法令の遵守を監視するように作動させるノードは、都市環境で屋外に配置されます。これらのフィールドノードは、測定したデータの広い色域を報告することが期待されている（例えば、スマート計量又はそのモニタ気象、汚染、及びアレルギー状態を実行するアプリケーションが必要とするデータ）。これらのノードの大部分は、IEEE 802.15.4、限られた無線範囲を与えられ、多数のノードが必要とする低電力IEEE 802.11またはIEEE 802.15.1（ブルートゥース）などのリンクの多様にわたって無線で通信することが期待されます適したルーティングプロトコルを使用します。そのようなプロトコルの設計は、主ノード（メモリ、処理能力、バッテリーなど）、屋外都市アプリケーションシナリオの特殊性の限られたリソースによって影響されるであろう。そのようなものとして、有用であるルーティングを低消費電力とロッシー（ROLL）ネットワークのための無線ソリューションは、プロトコル（単数または複数）は、エネルギー効率の高い、スケーラブルな、自律あるべきです。この文書では、これらとさらにU-LLNs'仕立ての特性を反映したIPv6ルーティング要件のセットを指定することを目指しています。
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
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-LLNs）のアプリケーション固有のIPv6ルーティングの要件。この文書は、層状IPアーキテクチャに厳密に準拠したU-LLNsのIPv6ルーティング要件のセットを詳述することに留意されたいです。 U-LLNは、ケースを使用して、関連するルーティングプロトコルの要件について説明します。
Section 2 defines terminology useful in describing U-LLNs.
セクション2は、U-LLNsを説明するための用語を定義します。
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実装のセキュリティ問題ルーティングの概要を提供します。
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].
エニーキャスト：RFC 4291に記載されているように、グループから「最も近い」インタフェースの少なくとも一つにパケットを転送するためのアドレス指定およびルーティング方式[RFC 4291]と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.
U-LLN：アーバン低消費電力とロッシーネットワーク。
WLAN: Wireless Local Area Network.
WLAN：ワイヤレスローカルエリアネットワーク。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A U-LLN is understood to be a network composed of three key elements, i.e.,
U-LLNは、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）の目的は、この文脈では、センサ、アクチュエータ、及びルータの機能的性質を示すことです。それはこれらの機能は排他的なものではないことを理解しなければならない、と述べました。特定のデバイスは、簡単なルーターとして働くことができる、または代替的には限りルーティングに関しては「通常」ルータとして見される場合に感知機能を備えたルータであってもよいです。
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.;
このような温度、圧力、湿度、UV指数、強度及び風の方向として2気象データ、等。
3. pollution data, such as gases (sulfur dioxide, nitrogen oxide, carbon monoxide, ozone), heavy metals (e.g., mercury), pH, radioactivity, etc.;
このようなガスとして前記汚染データ等（二酸化硫黄、窒素酸化物、一酸化炭素、オゾン）、重金属（例えば、水銀）、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).
顕著な例は、スマートメーター及び分配監視センサの都市全体のネットワークで構成され、「スマートグリッド」アプリケーションです。都市「スマートグリッド」アプリケーションでのスマートメーターは、通常、1つのまたは複数の公益事業会社によって管理、電気、ガス、および/または水道メーターが含まれます。これらのメーターは、このような、顧客に提供される電気サービスの品質を測定粒状間隔データを提供する、またはアラーム条件の検出を自動化などの高度なセンシング機能することができるであろう。加えて、彼らは、リモートサービスの切断またはリモート要求リセットなどのアクチュエータコンポーネントを呼び出すことができる、高度なインタラクティブ機能、可能であってもよいです。より高度なシナリオでは、都市環境全体にエネルギーを提供するインフラを監視するために、ピーク負荷を管理するための需要応答システム、および配電自動化システムが含まれます。この種類の機能を提供することが可能なセンサノードは、時々、高度計測インフラ（AMI）と呼ばれてもよいです。
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外）制御アプリケーションから命令を受け取るアプリケーションを実行します。アクチュエータポイントの量が十分にセンシングノードの数以下です。いくつかの感知ノードは、アクチュエータ構成要素、例えば、遠隔サービス切断のための統合されたサポートと電気計器ノードを含むことができます。アクチュエータは、転送データが可能です。アクチュエータは、近未来のロールアウトの大部分で、モバイルになりそうではありません。アクチュエータ・ノードはまた、彼らはバッテリ駆動である場合には、例えば、長期的な資源制約に悩まされることができます。
Routers generally act to close coverage and routing gaps within the interior of the U-LLN; examples of their use are:
ルータは、一般的にU-LLNの内部カバレッジ及びルーティングギャップを閉じるように作用します。その使用例は以下のとおりです。
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ノードは、センサ及びアクチュエータノード（例えば、収集したセンサアプリケーションからのデータを処理する、またはアプリケーションをアクチュエータに命令を送る）と通信するアプリケーションを実行してもよいです。
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 ^ 7〜10程度であると予想されます。これは、現在のロールアウトではまだ非常に大きいと前例のないです。
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.
ノードの展開は、例えば、ノードの数百〜数千の箱が到着すると展開され、バッチで起こる可能性があります。ノードの位置が所定のトポロジー制約内でランダムであり、例えば、道路、川に沿って配置、または個々の住宅で。
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:
ノードは、高度、すなわち、安価なハードウェア、低メモリ、及び無無限のエネルギー源を資源制約されています。異なるノードの電力供給機構のような、利用可能です。
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））。
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.
3つの主要な要素、すなわち、センサ、アクチュエータ、およびルータ間の物理的および電磁的距離は、一般的に数百メートルから1キロに、即ち、非常に大きくなり得ます。ていないすべてのフィールド・ノードは、それによって、エネルギー効率の高い方法で情報の流れを管理する適切なルーティングプロトコルを必要とする、単一ホップにLBRに到達する可能性があります。
The links between the network elements are volatile due to the following set of non-exclusive effects:
ネットワーク要素間のリンクは、非排他的な効果の次のセットに揮発性です。
2. packet errors due to MAC (Medium Access Control) (e.g., collision);
MAC（媒体アクセス制御）による2パケットエラー（例えば、衝突）。
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.
また、U-LLNsの屋外展開も干渉温度に影響を有し、したがって、信頼性をリンクし、産業、科学、および医療（ISM）バンドが使用される場合、範囲。 2.4GHzの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.
最後に、ノードが登場すると、リンクの停止およびトポロジの変化をもたらすことができる、ネットワーク内の原因ダイナミクスを消えます。
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.
アーバンアプリケーションは、要件の独自のセットでLLNsの特別なセグメントを表しています。第6節の要求事項の議論を容易にするために、このセクションでは、いくつかの典型的な網羅的ではない展開の問題とU-LLNの使用例一覧表示されます。
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.
初期化がアウトを展開する前に実行されている場合は、すべてのノードが互いにの1ホップラジオ地区にある可能性が高いです。予めプログラムされたメディアアクセス制御（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程度の）低カーディナリティの可能性が1ホップ隣人の有限集合を、持っています。しかし、いくつかのノードは、隣接するデバイスの数百がある領域に展開することができます。得られたトポロジでは、多くの（冗長）パスがネットワークを介して可能である領域が存在してもよいです。その他の地域は、残りのネットワークとの接続性を実現するために重要なリンクに依存することができます。任意の提案LLNルーティングプロトコルは、自律が外部の影響なしで動作するネットワークの能力であると理解されているネットワークで可能な限り低いエネルギーコスト[Lu2007]の自律的な自己組織化および自己構成をサポートするべきです。スケジュールのセットアップを容易にするように、このような組織の結果等、各ノードまたはノードの集合が一意にアドレス指定可能であることであるべきです
Unless exceptionally needed, broadcast forwarding schemes are not advised in urban sensor networking environments.
非常に必要でない限り、ブロードキャスト転送方式は、都市センサーネットワーク環境にはお勧めされていません。
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（単数または複数）を知らせるを含んでいてもよい、例えば、正確なまたは相対的な地理的位置、等を含んでいてもよいですネットワークならびに等パケット転送スケジュール、役割、約新たに関連付けられたノードは、適切な更新メカニズムがサポートされるべきです。
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.
センシングノードの大半は定期的に測定値を報告するように構成されます。データ感知及び報告の頻度も異なっていてもよいが、一般的に一日あたり、1時間に1回の範囲内、すなわち、かなり低いことが予想される、等の周波数を検出し、報告データとの間の比は、メモリおよびデータ集約機能を決定しますノードの。例えば、センサの所与のセンサ又はクラスタから到来全く読み取りがない場合、 - センシング停止は、データ収集アプリケーションで観察することができるように成功したデータ配信のエンドツーエンドの送達および肯定応答の待ち時間は重要ではないかもしれません日中。この場合、クエリは、センシングノードまたはセンシング・クラスターの状態と可用性時にチェックするために起動することができます。
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.
ルート計算および選択は、例えば、送信された情報に等報告の頻度、ノードに残っているエネルギー量、エネルギー捕捉ノードの充電パターンを、依存し得る、温度測定値は、一組を介して、時間ごとに報告することができますバッテリ駆動ノード、空気品質指標は、太陽エネルギーによって電力供給ノードを介してのみ昼間に報告されている一方。より一般的には、全体のルーティングエリアを回避することができる（例えば、夜間）であるが、高濃度のノードは、太陽光からエネルギーを捕捉している日中に使用されます。
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.
時折、ネットワークの外部データクエリは、一つまたは複数のアプリケーションによって起動することができます。例えば、特定の時点で、または都市環境における所与の道路に沿って汚染のレベルを知ることが望ましいです。発生のクエリ率が重いテール分布は、彼らの行動をモデル化することが適切と考えられる場合には、定期的にではなく、ランダムではありません。クエリは、必ずしもクエリが開始されたところから同じノードに戻って報告する必要はありません。往復時間は、すなわち、ノードへの測定データの配信までのノードからの問合せの打ち上げから、重要です。待ち時間は単に典型的な報告間隔よりも十分に小さくあるべき場所しかし、彼らは非常に厳しくありません。例えば、数秒から数分のためです。ルーティングプロトコル（単数または複数）は照会測定報告をサポートするために、適切な（例えば、レイテンシ）メトリックを持つパスを選択することを検討すべきです。クエリ処理を容易にするために、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.
同じアプローチは、この場合等スケジュール更新、パッチおよびアップグレードのプロビジョニングのためにも適用可能であるが、肯定応答を提供し、ユニキャスト、マルチキャスト、エニーキャストのサポートが重要です。
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に向かって）またはマルチキャスト（1つのLBRに向かって）ユニキャストされる必要があります。遅延やレイテンシが重要です。しかし、一般的なアプリケーションのサポートで展開U-LLNのために、数秒以内に配達はほとんどの場合で十分です。
Unlike traditional ad hoc networks, the information flow in U-LLNs is highly directional. There are three main flows to be distinguished:
伝統的な広告のアドホックネットワークとは異なり、U-LLNsにおける情報の流れは高指向性です。区別するための3つの主要な流れがあります。
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;
センシングノードに向かっLBR（S）を経由U-LLN外部アプリケーションから前記クエリ要求、。
3. control information from applications outside the U-LLN, going through the LBR(s) towards the actuators.
アクチュエータに向かっLBR（S）を経由U-LLN外部アプリケーションからの前記制御情報。
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は時々大規模なトラフィックは、システム全体のアラートとして、（U-LLN外部ノードへ）のLBRを介してセンシングノードからのフローをサポートすべきです。 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を通って流れることがトリガされてもよいです。
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.
前のセクションで例示したような都市の低消費電力とロッシーネットワークアプリケーションは、動作条件のセットに関連する特定の要件の数を持っています。
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ノードの大規模で多様な測定空間 - 典型的には、大きな都市部に結合された - は非常に大規模なネットワークサイズをもたらします。現在の都市部のロールアウトは、時には百以上のノードで構成されています。将来のロールアウトは、しかし、簡単に数百万人に数万の中の数字に達する可能性があります。最重要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.
設定可能なしきい値以下に選択された性能パラメータを低下させることなく、ノードの非常に大きく増加を収容するようにルーティングプロトコル（単数または複数）は、スケーラブルでなければなりません。ルーティングプロトコル（単数または複数）は、設定可能なサイズの領域に多数のノードの組織をサポートしなければなりません。
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.
いくつかのノードでの電池は、他よりも速く枯渇します。ルーティング経路の維持のための1つのノードの存在は、他のノードのと同じくらい重要ではないかもしれません。エネルギー捕捉方法は、規則的または不規則な間隔でバッテリーを充電することができます。いくつかのノードは、一定の電源を有していてもよいです。いくつかのノードは、より大きなメモリを有することができ、したがって、より多くの近隣情報を格納することができるされています。いくつかのノードは、より強い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ノードを必要とするべきです。例えばの支持にそのような機能、データ集約は、（例えば、Diffservのコードポイント（DSCP）の使用、フローラベル）に基づいて、IPv6パケットフォーマットを使用して適切なルーティングの決定のために/タグトラフィックをマークするために、いくつかのメカニズムを使用することを意味し得ます上層のマーキング決定。この観点から、このようなノードは、エニーキャストエンドポイントとパケットトラフィック経路にマーキングと併せて（アグリゲータとして機能するように、例えば）ノードの機能を使用するかもしれません。
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 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).
ルーティングプロトコル（単数または複数）は、動的に、計算を選択し、おそらくサービスに係るアクチュエータ及び/又はLBRに向かってトラフィックを転送するために、参加デバイスによって使用される（複数の）経路（複数可）を最適化することができるべきです固有およびトラフィック固有のQoS、トラフィック・エンジニアリング、およびルーティングドメインの規模で実施されなければならないルーティングセキュリティポリシー（つまり、グローバルに一意のエンティティによって投与ネットワーキングデバイスのセットである）、またはそのような領域ドメイン（例えば、センサのクラスタで構成される首都圏）。
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.
ルーティングプロトコルは、動的に計算し、同じ宛先に向けて複数のパスを選択することによって、トラフィックバーストに対応できなければなりません。
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 network may support the ability to interact with another network using a different protocol, for example, by supporting route redistribution.
同じプロトコルが使用されている場合、たとえば、インタフェースのセキュリティへの影響、ユーティリティU-LLNとホームネットワークのルーティングに着目しながら、ネットワークは、インターネットワーキングをサポートする必要があります。ネットワークは、ルート再配布をサポートすることによって、例えば、異なるプロトコルを使用して別のネットワークと相互作用する能力をサポートすることができます。
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.
移動度は都市LLNsに低いと想定しているが、原因ノードのアソシエーション、ディスアソシエーション、および消失、ならびに長期リンク摂動に対するネットワーク動的性は無視できません。このターンの影響の再編と再コンバージェンスなどのルーティングプロトコルのコンバージェンスインチ
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.
分化は、ノードは、ノードがその保留中の除去についてネットワークに通知するのに十分な時間を持って事前の通知、およびUSER-またはノードが開始した解離（「フェーズドアレイ・アウト」）、せずに消えノード消失、の間でなされるべきです。
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-LLNsは、遅延数秒、例えば、情報が最小レポート間隔の分数内に到着限り寛容です時間。
The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could, e.g., be latency).
ルーティングプロトコル（単数または複数）はまた、異なるメトリック（そのうちの一つ、例えば、潜時であってもよい）に応じてルーティングする能力をサポートしなければなりません。
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 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-LLNsに対処する必要があるセキュリティ上の脅威をルーティングにさらされています。これらのネットワークの無線および分散性は、潜在的なルーティングセキュリティの脅威のスペクトルを増大させます。これはさらに、それによって展開されるのリソース集中型ルーティングセキュリティアプローチを防止する、ノードのリソースの制約によって増幅されます。生存可能なルーティングセキュリティアプローチは、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.
発生する可能性のあるルーティングセキュリティ問題のさらなる例は、ネットワークルールに従うか、全く又は偽パケットを転送しないよう利己的行動を示すノード、の異常な挙動です。 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に望まれている自己構成と自己組織化の性質は、追加のルーティング、セキュリティの考慮事項を紹介します。メカニズムは、自己構成および自己組織化の手順の悪質な利点を活用しようとする任意のノードを否定する場所でなければなりません。そのような攻撃は、DoS攻撃を引き起こす電力に制約のあるデバイスのエネルギードレイン、またはルーティング機構をハイジャックするために、例えば、試みることができます。ノードは、前者が、自己構成や自己組織化に参加する前に、すでに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は、DoS攻撃に対して脆弱でないように、外部ネットワークのサポートに付与されたリソースを制限することができなければなりません。
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-LLNs'ノードは、高電力悪意のあるノード（例えば、ラップトップ、強いラジオ）から任意の攻撃に抵抗することができないかもしれません。しかしながら、ネットワーク全体に発生損傷の量は、物理的に損なわれたノードの数に見合ったものであるべきです。例えば、単一ノードの制御を取る侵入者は、完全にネットワーク全体にサービスを拒否することが可能であるべきではありません。
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横切っセキュリティのベストプラクティスのルーティングの実装をサポートしなければなりません。そのような実装は、例えば、盗聴、リプレイ、メッセージ挿入、変更、およびman-in-the-middle攻撃に対する防御を含むべきです。
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-LLNsの文脈で提案されているルーティングプロトコル（単数または複数）は、認証と完全性測定をサポートしなければならないし、機密性（ルーティングセキュリティ）対策をサポートしなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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、ヴァロワ、F.、バーセル、D.、およびM.のDohler、 "FISCO：自己構成およびWSNのための自己組織化の完全に統合スキーム"。、11-15 2007年3月、頁。 3370-3375、2007 IEEE WCNC、香港、中国。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年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.、エド。、デ・ミル、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]ブラント、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]ピスター教授、K.、エド。、Thubert、P.、エド。、Dwars、S.、およびT.フィニー、 "低消費電力とロッシーネットワークにおける産業ルーティング要件"、進歩、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、ジョナサン・ホイ、イアンカルダー、及びパシEronenの詳細なフィードバックが大幅に高く評価されています。
Appendix B. Contributors
付録B.協力者
Christian Jacquenet France Telecom R&D 4 rue du Clos Courtel BP 91226 35512 Cesson Sevigne France
クリスチャンJacquenetフランステレコムR＆D 4 RUEデュクロCourtel BP 91226 35512セッソンセビニェフランス
EMail: christian.jacquenet@orange-ftgroup.com
メールアドレス：christian.jacquenet@orange-ftgroup.com
Giyyarpuram Madhusudan France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
Giyyarpuram MadhusudanフランステレコムR＆D 28シュマン・デュ・ヴューシュヌ38243メランセデックスフランス
EMail: giyyarpuram.madhusudan@orange-ftgroup.com
メールアドレス：giyyarpuram.madhusudan@orange-ftgroup.com
Gabriel Chegaray France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
ガブリエルChegarayフランステレコムR＆D 28シュマン・デュ・ヴューシュヌ38243メランセデックスフランス
EMail: gabriel.chegaray@orange-ftgroup.com
メールアドレス：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
ミーシャのDohler（エディタ）CTTC地中海テクノロジーパークのAv。カナルオリンピックS / N 08860カステルデフェルス、スペインバルセロナ
EMail: mischa.dohler@cttc.es
メールアドレス：mischa.dohler@cttc.es
Thomas Watteyne (editor) Berkeley Sensor & Actuator Center, University of California, Berkeley 497 Cory Hall #1774 Berkeley, CA 94720-1774 USA
トーマスWatteyne（エディタ）バークレーセンサ＆アクチュエータセンター、カリフォルニア大学バークレー校497コーリー・ホール＃1774バークレー、CA 94720から1774 USA
EMail: watteyne@eecs.berkeley.edu
メールアドレス：watteyne@eecs.berkeley.edu
Tim Winter (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, MD 20874 USA
ティム・冬（エディタ）エカシステム20201センチュリーブルバードスイート250ジャーマンタウン、MD 20874 USA
EMail: wintert@acm.org
メールアドレス：wintert@acm.org
Dominique Barthel (editor) France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
ドミニク・バーセル（編集者）フランステレコムR＆D 28シュマン・デュ・ヴューシュヌ38243メランセデックスフランス
EMail: Dominique.Barthel@orange-ftgroup.com
メールアドレス：Dominique.Barthel@orange-ftgroup.com