[要約] RFC 5548は、都市型の低電力・低信頼性ネットワークにおけるルーティング要件についてのガイドラインです。このRFCの目的は、このようなネットワークでの効果的なルーティングプロトコルの設計と実装を支援することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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-LLN）のアプリケーション固有のルーティング要件が示されています。近い将来、人々の生活条件を改善したり、ますます厳格な環境法のコンプライアンスを監視するために、都市環境で屋外に屋外に配置されます。これらのフィールドノードは、幅広いデータを測定および報告することが期待されています（たとえば、スマートメタリングを実行したり、気象、汚染、アレルギーの状態を監視するアプリケーションで必要なデータ）。これらのノードの大部分は、IEEE 802.15.4、低電力IEEE 802.11、またはIEEE 802.15.1（Bluetooth）などのさまざまなリンクでワイヤレスで通信することが期待されています。適切なルーティングプロトコルの使用。このようなプロトコルの設計は、主にノードの限られたリソース（メモリ、処理能力、バッテリーなど）と屋外の都市アプリケーションシナリオの特殊性の影響を受けます。そのため、低電力と損失（ロール）ネットワークを介してルーティングするワイヤレスソリューションが役立つためには、プロトコルはエネルギー効率、スケーラブル、自律的である必要があります。このドキュメントは、これらおよびさらなる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-LLN）のアプリケーション固有のIPv6ルーティング要件を詳述しています。このドキュメントは、階層化されたIPアーキテクチャに厳密に準拠したU-LLNの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環境でこのような制約されたデバイスを構成するネットワークのルーティング要件について説明します。これらの要件は、他のアプリケーション固有の要件ドキュメント[ロールホーム] [ロールインド] [ロールビルド]と重複する、または導き出される場合があります。
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:
このドキュメントで使用される用語は、「低電力および損失ネットワークの用語」[ロールターム]と一致し、組み込まれています。この用語は、次のようにこのドキュメントに拡張されています。
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].
Anycast：RFC4291 [RFC4291]およびRFC1546 [RFC1546]に記載されているように、グループからの「最も近い」インターフェイスの少なくとも1つにパケットを転送するためのアドレス指定とルーティングスキーム。
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つの重要な要素で構成されるネットワークであると理解されています。
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）の目的は、このコンテキストでのセンサー、アクチュエータ、およびルーターの機能性を説明することです。とはいえ、これらの機能は排他的ではないことを理解する必要があります。特定のデバイスは、単純なルーターとして機能する場合があります。または、ある場合は、センシング機能を備えたルーターである場合があります。この場合、ルーティングに関する限り、「通常の」ルーターと見なされます。
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).
センサーノードは、通常、測定データを収集し、他のノード（s）（しばしば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の内部内のカバレッジとルーティングのギャップを閉鎖するように作用します。それらの使用の例は次のとおりです。
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ノードは、センサーとアクチュエータノードと通信するアプリケーションを実行する場合があります（たとえば、センサーアプリケーションからデータを収集および処理したり、アクチュエータアプリケーションに手順を送信したりします）。
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.
ノードの展開はバッチで発生する可能性があります。たとえば、数百から数千のノードの箱が到着し、展開されます。ノードの位置は、特定のトポロジカル制約、たとえば道路、川、または個々の住宅に沿った配置内でランダムです。
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.
3つの重要な要素、すなわちセンサー、アクチュエーター、およびルーターの間の物理的および電磁距離は、一般に非常に大きく、つまり数百メートルから1キロメートルまでです。すべてのフィールドノードが1回のホップでLBRに到達する可能性が高いわけではないため、エネルギー効率の高い方法で情報フローを管理する適切なルーティングプロトコルが必要です。
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.
さらに、U-LLNの屋外展開は、干渉温度にも影響を与え、したがって、産業、科学、および医療（ISM）バンドを使用する場合、信頼性と範囲をリンクします。たとえば、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.
最後に、ノードが表示され、消滅すると、ネットワーク内のダイナミクスが発生し、リンクの停止とトポロジの変更が得られます。
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のいくつかの典型的な展開の問題と使用法のケースをリストします。
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.
ロールアウト後、ノードには、おそらく低枢機inal（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回、1日に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.
ルートの計算と選択は、送信された情報、報告の頻度、ノードに残っているエネルギー量、エネルギーを拡張したノードの充電パターンなどに依存する場合があります。たとえば、温度測定値は、1セットのセットで1時間ごとに報告できます。バッテリー駆動のノード。一方、大気質指標は、太陽エネルギーを搭載したノードを介して昼間のみ報告されます。より一般的には、ルーティングエリア全体が回避される可能性があります（たとえば、夜間に）が、ノードが日光からエネルギーを除去している日中は頻繁に使用されます。
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.
場合によっては、1つまたは複数のアプリケーションによってネットワーク外部データクエリを起動できます。たとえば、特定のポイントまたは都市環境の特定の道路に沿って汚染のレベルを知ることが望ましいです。クエリの発生率は規則的ではなく、ランダムであり、重尾の分布が動作をモデル化するのに適していると思われます。クエリは、クエリが起動された場所から同じノードに戻って報告する必要はありません。ラウンドトリップ時間、つまり、ノードからのクエリの起動から、測定されたデータのノードへの配信まで、重要性があります。ただし、レイテンシが一般的な報告間隔よりも十分に小さくなる必要がある場合、それらはそれほど厳しくありません。たとえば、秒または分の順序で。ルーティングプロトコルは、クエリ測定レポートをサポートするための適切な（潜伏期）メトリックを備えたパスの選択を考慮する必要があります。クエリプロセスを容易にするために、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.
まれに、センシングノードは、そのような分類が通常、プログラムされた事前に拡散したしきい値を使用して各ノード内で局所的に行われるアラームとして分類されるイベントを測定します。アラートのしきい値レベルに近づくと、ノードはセンシングと報告サイクルを変更したい場合があることに注意してください。アラームは、すべてではありませんが、すべてではありませんが、その原点の位置を備えた単一のアラートメッセージの配信で十分なケースで十分である複数のセンシングノードによって登録されている可能性があります。アラート報告の1つの例は、有毒ガスのレベルがしきい値を超えて上昇する場合です。その後、このイベントの近くのセンシングノードは危険を報告しています。アラート報告のもう1つの例は、リサイクルガラス容器（その居住レベルを測定するセンサーを装備したガラス容器）が、容器がいっぱいであるため、空にする必要があることを報告することです。
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.
ルートは明らかにユニキャスト（1つのLBRに向かって）またはマルチキャスト（複数の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. SENSINGノードからU-LLNの外側のアプリケーションへの情報を検知し、LBRの1つまたはSUBSETを通過します。
2. query requests from applications outside the U-LLN, going through the LBR(s) towards the sensing nodes;
2. U-llnの外側のアプリケーションからのクエリリクエスト、LBR（S）をセンシングノードに向かって通過します。
3. control information from applications outside the U-LLN, going through the LBR(s) towards the actuators.
3. U-lln外のアプリケーションからの情報を制御し、LBR（S）をアクチュエーターに向けて通過します。
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.
SENSEDデータは、空間、時間、および観察されたイベントで非常に相関している可能性があります。後者の例は、日が始まると温度が上昇し、湿度が低下するときです。データは異なるレートで検知および配信される場合があり、両方のレートが通常かなり低く、つまり時間、時間、日などの範囲で、データはスケジュールまたは定期的なクエリに従って定期的に配信される場合があります。また、外部からトリガーされたクエリの後に不規則に配信される場合があります。また、突然のネットワーク内部イベントやアラートの後にトリガーされる場合があります。スケジュールは、たとえば、データが1時間ごとに配信されると予想されるスマートメタリングアプリケーション、またはバッテリー駆動のノードが特定の時間に1日1回そのステータスを報告すると予想される環境監視アプリケーションによって推進される場合があります。データ配信は、逆方向に謝辞またはメンテナンストラフィックをトリガーする場合があります。したがって、ネットワークは、さまざまなアクティビティデューティサイクル、および周期的および散発的なトラフィックに適応できる必要があります。また、Sensedデータは保護され、ロケート可能である必要があります。
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を介した[NODES]（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を通ってユーティリティに戻るようにトリガーされる場合があります。
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ノードの大規模で多様な測定スペース（通常は大きな都市部と組み合わせた）は、非常に大きなネットワークサイズを生み出します。現在の都市ロールアウトは、時には100を超えるノードで構成されています。ただし、将来のロールアウトは、数万から数百万の数に簡単に到達する可能性があります。したがって、最も重要なLLNルーティングプロトコル設計基準の1つは、スケーラビリティです。
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ノードが必要です。たとえば、データの集約をサポートするこのような機能は、IPv6パケット形式（例：Diffservコードポイント（DSCP）の使用、フローラベルの使用）を使用して適切なルーティング決定のためにトラフィックをマーク/タグ付けするためのいくつかのメカニズムを使用することを意味する場合があります。上層層マーキングの決定。この観点から、そのようなノードは、ノード機能（たとえば、アグリゲーターとして機能するために）を使用して、anycastエンドポイントとパケットマーキングと組み合わせてトラフィックをルーティングする場合があります。
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.
この目的のために、ルーティングプロトコルは、ネットワークランプアップ時のゼロ構成、トポロジカルな変化による（ネットワーク内）自己組織化と構成、およびサポート能力（ネットワーク - 外部）を含む一連の機能を提供する必要があります。）パッチと構成の更新。後者の場合、プロトコルはマルチキャストとAnycastアドレス指定をサポートする必要があります。プロトコルは、ネットワーク内のフィールドデバイスのグループの形成と識別もサポートする必要があります。
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.).
ルーティングプロトコルは、適切なルーティングメトリックの適用を通じて、絶えず変化する通信条件（サービス品質の低下（QO）、トラフィックの可変性（リアルタイム）に動的に適応できる必要があります。対非現実的な時間、検知データとアラート）、ノードモビリティ、その組み合わせなど）。
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にトラフィックを転送する（複数）パスを最適化できる必要があります。 - ルーティングドメインの規模（つまり、グローバルに一意のエンティティによって管理されているネットワーキングデバイスのセット）、またはそのような領域で実施する必要がある固有およびトラフィック固有のQO、トラフィックエンジニアリング、およびルーティングセキュリティポリシードメイン（たとえば、センサーのクラスターで構成される大都市圏）。
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.
都市センサーネットワークでアクティブ化されたルーティングプロトコルは、ユニキャスト（トラフィックが単一のフィールドデバイスに送信される）、マルチキャスト（トラフィックは同じマルチキャストグループにサブスクライブされるデバイスのセットに送信されます）、およびANYCAST（複数のフィールドデバイスが構成されている場合）をサポートする必要があります。単一のIP Anycastアドレスで送信されたトラフィックを受け入れるには）送信スキーム。
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.
Unicast、Multicast、およびAnycastのサポートもアドレス指定スキームに影響を及ぼしますが、ルーティング要件に焦点を当てたのはこのドキュメントの範囲を超えています。
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.
モビリティは都市の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.
ノードが消滅することなく、ノードが消滅することなく、ノードが消滅することなく、ユーザーまたはノードが開始した分離（「段階的」）の間で区別を行う必要があります。ノードには、保留中の削除についてネットワークに通知するのに十分な時間があります。
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.
アラートレポートソリューションと（ある程度）クエリレポートを除き、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).
ルーティングプロトコルは、異なるメトリックに従ってルーティングする機能もサポートする必要があります（そのうちの1つは、たとえば、遅延になる可能性があります）。
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-llnは対処する必要があるルーティングセキュリティの脅威にさらされます。これらのネットワークのワイヤレスで分散された性質により、潜在的なルーティングセキュリティの脅威のスペクトルが増加します。これは、ノードのリソース制約によってさらに増幅されるため、リソース集約型のルーティングセキュリティアプローチが展開されないようになります。実行可能なルーティングセキュリティアプローチは、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全体のルーティングセキュリティベストプラクティスの実装をサポートする必要があります。このような実装には、たとえば、盗聴、リプレイ、メッセージ挿入、変更、中間攻撃に対する防御を含める必要があります。
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のコンテキストで提案されたルーティングプロトコルは、認証と整合性の測定をサポートする必要があり、機密性（ルーティングセキュリティ）測定をサポートする必要があります。
[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月。
[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] Lu、Jl。、Valois、F.、Barthel、D。、およびM. Dohler、「Fisco：WSNの完全に統合された自己組織化のスキーム」、2007年3月11〜15日、pp。3370-3375、IEEE WCNC 2007、香港、中国。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「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.、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。and 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月、進行中の作業。
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の詳細なフィードバックは大歓迎です。
Christian Jacquenet France Telecom R&D 4 rue du Clos Courtel BP 91226 35512 Cesson Sevigne France
クリスチャンジャックエネットフランステレコムR＆D 4 RUE DU CLOOD COURTEL BP 91226 35512 CESSON SEVIGNE FRANCE
EMail: christian.jacquenet@orange-ftgroup.com
Giyyarpuram Madhusudan France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
Giyyarpuram Madhusudan France Telecom R＆D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
EMail: giyyarpuram.madhusudan@orange-ftgroup.com
Gabriel Chegaray France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
ガブリエルチェガレーフランステレコムR＆D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
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
Misha Dohler（編集者）CTTC Parc Mediterrani de la tecnologia av。Canal Olimpic S/N 08860 CastellDefels、バルセロナスペイン
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（編集者）Berkeley Sensor＆Actuator Center、カリフォルニア大学バークレー校497 Cory Hall＃1774 Berkeley、CA 94720-1774 USA
EMail: watteyne@eecs.berkeley.edu
Tim Winter (editor) Eka Systems 20201 Century Blvd. Suite 250 Germantown, MD 20874 USA
ティムウィンター（編集者）EKA Systems 20201 Century Blvd.Suite 250ジャーマンタウン、MD 20874 USA
EMail: wintert@acm.org
Dominique Barthel (editor) France Telecom R&D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
ドミニクバーセル（編集者）フランステレコムR＆D 28 Chemin du Vieux Chene 38243 Meylan Cedex France
EMail: Dominique.Barthel@orange-ftgroup.com