[要約] RFC 6606は、6LoWPANルーティングにおけるIPv6の問題と要件をまとめたものです。その目的は、低電力ワイヤレスパーソナルエリアネットワークでのIPv6の効果的な利用を促進することです。
Internet Engineering Task Force (IETF) E. Kim
Request for Comments: 6606 ETRI
Category: Informational D. Kaspar
ISSN: 2070-1721 Simula Research Laboratory
C. Gomez
Universitat Politecnica de Catalunya/Fundacio i2CAT
C. Bormann
Universitaet Bremen TZI
May 2012
Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）ルーティングを介したIPv6の問題ステートメントと要件
Abstract
概要
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）上のIPv6は、IEEE 802.15.4規格と互換性のあるデバイスによって形成されます。ただし、IEEE 802.15.4規格も6LoWPANフォーマット仕様も、メッシュトポロジを取得および維持する方法を定義していません。したがって、6LoWPANの形成とマルチホップルーティングをどのようにサポートできるかを検討する必要があります。
This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG.
このドキュメントは、6LoWPANルーティングの問題ステートメントと設計スペースを提供します。デバイスとリンクの低電力およびその他の特定の特性を考慮して、6LoWPANのルーティング要件を定義します。このドキュメントの目的は、特定のソリューションを推奨することではなく、さらなる分析とプロトコル設計につながる可能性のある6LoWPANルーティングの設計について、レイヤーにとらわれない一般的なガイドラインを提供することです。このドキュメントは、IETF ROLL WGなど、6LoWPANに関連するルーティングプロトコルに取り組んでいるグループへの入力を目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6606.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6606で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Problem Statement ...............................................2
2. Terminology .....................................................5
3. Design Space ....................................................5
3.1. Reference Network Model ....................................6
4. Scenario Considerations and Parameters for 6LoWPAN Routing ......8
5. 6LoWPAN Routing Requirements ...................................13
5.1. Support of 6LoWPAN Device Properties ......................13
5.2. Support of 6LoWPAN Link Properties ........................15
5.3. Support of 6LoWPAN Characteristics ........................18
5.4. Support of Security .......................................22
5.5. Support of Mesh-Under Forwarding ..........................25
5.6. Support of Management .....................................26
6. Security Considerations ........................................27
7. Acknowledgments ................................................27
8. References .....................................................28
8.1. Normative References ......................................28
8.2. Informative References ....................................29
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard [IEEE802.15.4]. Most of the LoWPAN devices are distinguished by their low bandwidth, short range, scarce memory capacity, limited processing capability, and other attributes of inexpensive hardware. The characteristics of nodes participating in LoWPANs are assumed to be those described in the 6LoWPAN problem statement [RFC4919], and in the IPv6 over IEEE 802.15.4 document [RFC4944], which has specified how to carry IPv6 packets over IEEE 802.15.4 and similar networks. Whereas IEEE 802.15.4 distinguishes two types of devices called full-function devices (FFDs) and reduced-function devices (RFDs), this distinction is based on some features of the Medium Access Control (MAC) layer that are not always in use. Hence, the distinction is not made in this document. Nevertheless, some 6LoWPAN nodes may limit themselves to the role of hosts only, whereas other 6LoWPAN nodes may take part in routing. This host/ router distinction can correlate with the processing and storage capabilities of the device and power available in a similar way to the idea of RFDs and FFDs.
6LoWPANは、IEEE 802.15.4標準[IEEE802.15.4]と互換性のあるデバイスによって形成されます。 LoWPANデバイスのほとんどは、低帯域幅、短距離、メモリ容量の不足、処理能力の制限、および安価なハードウェアの他の属性によって区別されます。 LoWPANに参加するノードの特性は、6LoWPAN問題ステートメント[RFC4919]と、IEEE 802.15.4を介してIPv6パケットを伝送する方法を指定したIPv6 over IEEE 802.15.4ドキュメント[RFC4944]で説明されているものと想定されます。同様のネットワーク。 IEEE 802.15.4は、全機能デバイス（FFD）と機能制限デバイス（RFD）と呼ばれる2種類のデバイスを区別しますが、この区別は、常に使用されているわけではない媒体アクセス制御（MAC）レイヤーのいくつかの機能に基づいています。したがって、このドキュメントでは区別を行いません。それでも、一部の6LoWPANノードはホストの役割のみに制限される場合がありますが、他の6LoWPANノードはルーティングに参加する場合があります。このホスト/ルーターの違いは、RFDとFFDの考え方と同様に、デバイスの処理機能とストレージ機能、および利用可能な電力と相関関係があります。
IEEE 802.15.4 networks support star and mesh topologies. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification ([RFC4944]) define how mesh topologies could be obtained and maintained. Thus, 6LoWPAN formation and multi-hop routing can be supported either below the IP layer (the adaptation layer or Logical Link Control (LLC)) or the IP layer. (Note that in the IETF, the term "routing" usually, but not always [RFC5556], refers exclusively to the formation of paths and the forwarding at the IP layer. In this document, we distinguish the layer at which these services are performed by the terms "route-over" and "mesh-under". See Sections 2 and 3.) A number of IP routing protocols have been developed in various IETF working groups. However, these existing routing protocols may not satisfy the requirements of multi-hop routing in 6LoWPANs, for the following reasons:
IEEE 802.15.4ネットワークは、スタートポロジとメッシュトポロジをサポートしています。ただし、IEEE 802.15.4標準も6LoWPAN形式仕様（[RFC4944]）も、メッシュトポロジを取得および維持する方法を定義していません。したがって、6LoWPANの形成とマルチホップルーティングは、IPレイヤー（アダプテーションレイヤーまたは論理リンクコントロール（LLC））またはIPレイヤーの下でサポートできます。 （IETFでは、「ルーティング」という用語は、常にではありませんが[RFC5556]と呼ばれ、IP層でのパスの形成と転送のみを指します。このドキュメントでは、これらのサービスが実行される層を区別します「route-over」および「mesh-under」という用語で説明します（セクション2および3を参照）。さまざまなIETFワーキンググループで多数のIPルーティングプロトコルが開発されています。ただし、これらの既存のルーティングプロトコルは、次の理由により、6LoWPANのマルチホップルーティングの要件を満たさない場合があります。
o 6LoWPAN nodes have special types and roles, such as nodes drawing their power from primary batteries, power-affluent nodes, mains-powered and high-performance gateways, data aggregators, etc. 6LoWPAN routing protocols should support multiple device types and roles.
o 6LoWPANノードには特別なタイプと役割があります。たとえば、一次電池から電力を引き出すノード、電力流出ノード、商用電源と高性能ゲートウェイ、データアグリゲーターなどです。6LoWPANルーティングプロトコルは、複数のデバイスタイプと役割をサポートする必要があります。
o More stringent requirements apply to LoWPANs, as opposed to higher-performance or non-battery-operated networks. 6LoWPAN nodes are characterized by small memory sizes and low processing power, and they run on very limited power supplied by primary non-rechargeable batteries (a few KB of RAM, a few dozen KB of ROM/ flash memory, and a few MHz of CPU is typical). A node's lifetime is usually defined by the lifetime of its battery.
o LoWPANには、より高性能な、またはバッテリーで動作しないネットワークとは対照的に、より厳しい要件が適用されます。 6LoWPANノードは、メモリサイズが小さく、処理能力が低いという特徴があり、プライマリ非充電式バッテリー（数KBのRAM、数十KBのROM /フラッシュメモリ、および数MHzのCPU）から供給される非常に限られた電力で動作します典型的です）。ノードの寿命は通常、バッテリーの寿命によって定義されます。
o Handling sleeping nodes is very critical in LoWPANs, more so than in traditional ad hoc networks. LoWPAN nodes might stay in sleep mode most of the time. Taking advantage of appropriate times for transmissions is important for efficient packet forwarding.
o スリープノードの処理は、LoWPANでは非常に重要であり、従来のアドホックネットワークよりも重要です。 LoWPANノードは、ほとんどの場合、スリープモードのままになる可能性があります。送信に適切な時間を利用することは、効率的なパケット転送にとって重要です。
o Routing in 6LoWPANs might possibly translate to a simpler problem than routing in higher-performance networks. LoWPANs might be either transit networks or stub networks. Under the assumption that LoWPANs are never transit networks (as implied by [RFC4944]), routing protocols may be drastically simplified. This document will focus on the requirements for stub networks. Additional requirements may apply to transit networks.
o 6LoWPANでのルーティングは、高性能ネットワークでのルーティングよりも単純な問題につながる可能性があります。 LoWPANは、トランジットネットワークまたはスタブネットワークのいずれかです。 （[RFC4944]で暗示されているように）LoWPANはトランジットネットワークではないという仮定の下で、ルーティングプロトコルは大幅に簡素化される可能性があります。このドキュメントでは、スタブネットワークの要件に焦点を当てます。トランジットネットワークには追加の要件が適用される場合があります。
o Routing in LoWPANs might possibly translate to a harder problem than routing in higher-performance networks. Routing in LoWPANs requires power optimization, stable operation in lossy environments, etc. These requirements are not easily satisfiable all at once [ROLL-PROTOCOLS].
o LoWPANでのルーティングは、高性能ネットワークでのルーティングよりも難しい問題に変換される可能性があります。 LoWPANでのルーティングには、電力の最適化、損失の多い環境での安定した動作などが必要です。これらの要件を一度にすべて満たすことは簡単ではありません[ROLL-PROTOCOLS]。
These properties create new challenges for the design of routing within LoWPANs.
これらのプロパティは、LoWPAN内のルーティングの設計に新たな課題をもたらします。
The 6LoWPAN problem statement [RFC4919] briefly mentions four requirements for routing protocols:
6LoWPAN問題ステートメント[RFC4919]では、ルーティングプロトコルの4つの要件について簡単に説明しています。
(a) low overhead on data packets
（a）データパケットのオーバーヘッドが少ない
(b) low routing overhead
（b）ルーティングのオーバーヘッドが少ない
(c) minimal memory and computation requirements
（c）最小限のメモリと計算要件
(d) support for sleeping nodes (consideration of battery savings)
（d）スリープ状態のノードのサポート（バッテリー節約の考慮）
These four high-level requirements describe the basic requirements for 6LoWPAN routing. Based on the fundamental features of 6LoWPANs, more detailed routing requirements, which can lead to further analysis and protocol design, are presented in this document.
これら4つの高レベルの要件は、6LoWPANルーティングの基本要件を説明しています。このドキュメントでは、6LoWPANの基本機能に基づいて、さらなる分析とプロトコル設計につながる、より詳細なルーティング要件について説明します。
Considering the problems above, detailed 6LoWPAN routing requirements must be defined. Application-specific features affect the design of 6LoWPAN routing requirements and corresponding solutions. However, various applications can be profiled by similar technical characteristics, although the related detailed requirements might differ (e.g., a few dozen nodes in a home lighting system need appropriate scalability for the system's applications, while millions of nodes for a highway infrastructure system also need appropriate scalability).
上記の問題を考慮して、詳細な6LoWPANルーティング要件を定義する必要があります。アプリケーション固有の機能は、6LoWPANルーティング要件の設計と対応するソリューションに影響します。ただし、関連する詳細な要件は異なる可能性がありますが、さまざまなアプリケーションを同様の技術特性でプロファイリングできます（たとえば、家庭用照明システムの数十のノードにはシステムのアプリケーションに適切なスケーラビリティが必要ですが、高速道路インフラストラクチャシステムには数百万のノードも必要です適切なスケーラビリティ）。
This routing requirements document states the routing requirements of 6LoWPAN applications in general, providing examples for different cases of routing. It does not imply that a single routing solution will be favorable for all 6LoWPAN applications, and there is no requirement for different routing protocols to run simultaneously.
このルーティング要件ドキュメントは、6LoWPANアプリケーションのルーティング要件を一般的に示し、ルーティングのさまざまなケースの例を提供します。単一のルーティングソリューションがすべての6LoWPANアプリケーションに適しているという意味ではなく、異なるルーティングプロトコルを同時に実行する必要はありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
読者は、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」[RFC4919]および「Transmission of IPv6 Packets over」で説明されているすべての用語と概念に精通している必要があります。 IEEE 802.15.4 Networks」[RFC4944]。
This specification makes use of the terminology defined in [6LoWPAN-ND].
この仕様では、[6LoWPAN-ND]で定義されている用語を使用しています。
Apart from a wide variety of conceivable routing algorithms for 6LoWPANs, it is possible to perform routing in the IP layer (using a route-over approach) or below IP, as defined by the 6LoWPAN format document [RFC4944] (using the mesh-under approach). See Figure 1.
6LoWPANのさまざまな考えられるルーティングアルゴリズムとは別に、6LoWPAN形式のドキュメント[RFC4944]（メッシュアンダーを使用）で定義されているように、IPレイヤー（ルートオーバーアプローチを使用）またはIPの下でルーティングを実行できます。アプローチ）。図1を参照してください。
The route-over approach relies on IP routing and therefore supports routing over possibly various types of interconnected links. Note: The ROLL WG is now working on route-over approaches for Low-power and Lossy Networks (LLNs), not specifically for 6LoWPANs. This document focuses on 6LoWPAN-specific requirements; it may be used in conjunction with the more application-oriented requirements defined by the ROLL WG.
ルートオーバーアプローチはIPルーティングに依存しているため、さまざまなタイプの相互接続されたリンクを介したルーティングをサポートします。注：ROLL WGは現在、特に6LoWPANではなく、低電力および損失の多いネットワーク（LLN）のルートオーバーアプローチに取り組んでいます。このドキュメントでは、6LoWPAN固有の要件に焦点を当てています。 ROLL WGによって定義された、よりアプリケーション指向の要件と組み合わせて使用できます。
The mesh-under approach performs the multi-hop communication below the IP link. The most significant consequence of the mesh-under mechanism is that the characteristics of IEEE 802.15.4 directly affect the 6LoWPAN routing mechanisms, including the use of 64-bit (or 16-bit short) link-layer addresses instead of IP addresses. A 6LoWPAN would therefore be seen as a single IP link.
メッシュアンダーアプローチは、IPリンクの下でマルチホップ通信を実行します。メッシュアンダーメカニズムの最も重要な結果は、IEEE 802.15.4の特性が6LoWPANルーティングメカニズムに直接影響することです。これには、IPアドレスではなく64ビット（または16ビットショート）リンク層アドレスの使用が含まれます。したがって、6LoWPANは単一のIPリンクと見なされます。
Most statements in this document consider both the route-over and mesh-under cases.
このドキュメントのほとんどのステートメントは、ルートオーバーとメッシュアンダーの両方のケースを考慮しています。
Figure 1 shows the place of 6LoWPAN routing in the entire network stack.
図1は、ネットワークスタック全体における6LoWPANルーティングの場所を示しています。
+---------------------------+ +-----------------------------+
| Application Layer | | Application Layer |
+---------------------------+ +-----------------------------+
| Transport Layer (TCP/UDP) | | Transport Layer (TCP/UDP) |
+---------------------------+ +-----------------------------+
| Network Layer (IPv6) | | Network +---------+ |
+---------------------------+ | Layer | Routing | |
| 6LoWPAN | | (IPv6) +---------+ |
| Adaptation | +-----------------------------+
| Layer +----------+ | | 6LoWPAN Adaptation Layer |
+--------------| Routing* |-+ +-----------------------------+
| 802.15.4 MAC +----------+ | | 802.15.4 MAC |
+---------------------------+ +-----------------------------+
| 802.15.4 PHY | | 802.15.4 PHY |
+---------------------------+ +-----------------------------+
* Here, "Routing" is not equivalent to IP routing,
but includes the functionalities of path computation and
forwarding under the IP layer.
The term "Routing" is used in the figure in order to
illustrate which layer handles path computation and
packet forwarding in mesh-under as compared to route-over.
Figure 1: Mesh-Under Routing (Left) and Route-Over Routing (Right)
図1：メッシュアンダールーティング（左）とルートオーバールーティング（右）
In order to avoid packet fragmentation and the overhead for reassembly, routing packets should fit into a single IEEE 802.15.4 physical frame, and application data should not be expanded to an extent that they no longer fit.
パケットの断片化と再構成のオーバーヘッドを回避するために、ルーティングパケットは単一のIEEE 802.15.4物理フレームに収まる必要があり、アプリケーションデータが収まらない程度に拡張されるべきではありません。
For multi-hop communication in 6LoWPANs, when a route-over mechanism is in use, all routers (i.e., 6LoWPAN Border Routers (6LBRs) and 6LoWPAN Routers (6LRs)) perform IP routing within the stub network (see Figure 2). In this case, the link-local scope covers the set of nodes within symmetric radio range of a node.
6LoWPANでのマルチホップ通信では、ルートオーバーメカニズムが使用されている場合、すべてのルーター（6LoWPANボーダールーター（6LBR）と6LoWPANルーター（6LR））がスタブネットワーク内でIPルーティングを実行します（図2を参照）。この場合、リンクローカルスコープは、ノードの対称無線範囲内のノードのセットをカバーします。
When a LoWPAN follows the mesh-under configuration, the 6LBR is the only IPv6 router in the LoWPAN (see Figure 3). This means that the IPv6 link-local scope includes all nodes in the LoWPAN. For this, a mesh-under mechanism MUST be provided to support multi-hop transmission.
LoWPANがメッシュアンダー構成に従う場合、6LBRはLoWPAN内の唯一のIPv6ルーターです（図3を参照）。つまり、IPv6リンクローカルスコープには、LoWPAN内のすべてのノードが含まれます。このため、マルチホップ伝送をサポートするために、メッシュアンダーメカニズムを提供する必要があります。
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR -- 6LR --- 6LR --- h 6LR: 6LoWPAN Router
/ \ h: Host
h 6LR --- h
|
/ \
6LR - 6LR -- h
Figure 2: An Example of a Route-Over LoWPAN
図2：ルートオーバーLoWPANの例
h h
/ | 6LBR: 6LoWPAN Border Router
6LBR --- m --- m --- h m: mesh-under forwarder
/ \ h: Host
h m --- h
|
/ \
m - m -- h
Figure 3: An Example of a Mesh-Under LoWPAN
図3：Mesh-Under LoWPANの例
Note than in both mesh-under and route-over networks, there is no expectation of topologically based address assignment in the 6LoWPAN. Instead, addresses are typically assigned based on the EUI-64 addresses assigned at manufacturing time to nodes, or based on a (from a topological point of view) more or less random process assigning 16-bit MAC addresses to individual nodes. Within a 6LoWPAN, there is therefore no opportunity for aggregation or summarization of IPv6 addresses beyond the sharing of (one or more) common prefixes.
メッシュアンダーネットワークとルートオーバーネットワークの両方で、6LoWPANにトポロジベースのアドレス割り当てが期待されていないことに注意してください。代わりに、アドレスは通常、製造時にノードに割り当てられたEUI-64アドレスに基づいて、または（トポロジーの観点から）個別のノードに16ビットMACアドレスを割り当てる多少ランダムなプロセスに基づいて割り当てられます。したがって、6LoWPAN内では、（1つ以上の）共通のプレフィックスを共有する以外に、IPv6アドレスを集約または要約する機会はありません。
Not all devices that are within radio range of each other need to be part of the same LoWPAN. When multiple LoWPANs are formed with globally unique IPv6 addresses in the 6LoWPANs, and device (a) of LoWPAN [A] wants to communicate with device (b) of LoWPAN [B], the normal IPv6 mechanisms will be employed. For route-over, the IPv6 address of (b) is set as the destination of the packets, and the devices perform IP routing to the 6LBR for these outgoing packets. For mesh-under, there is one IP hop from device (a) to the 6LBR of [A], no matter how many radio hops they are apart from each other. This, of course, assumes the existence of a mesh-under routing protocol in order to reach the 6LBR. Note that a default route to the 6LBR could be inserted into the 6LoWPAN routing system for both route-over and mesh-under.
互いに無線範囲内にあるすべてのデバイスが同じLoWPANの一部である必要はありません。 6LoWPANでグローバルに一意のIPv6アドレスで複数のLoWPANが形成され、LoWPAN [A]のデバイス（a）がLoWPAN [B]のデバイス（b）と通信する場合、通常のIPv6メカニズムが使用されます。ルートオーバーの場合、（b）のIPv6アドレスがパケットの宛先として設定され、デバイスはこれらの発信パケットに対して6LBRへのIPルーティングを実行します。メッシュアンダーの場合、互いに離れている無線ホップの数に関係なく、デバイス（a）から[A]の6LBRへのIPホップは1つです。もちろん、これは、6LBRに到達するためにメッシュアンダールーティングプロトコルが存在することを前提としています。 6LBRへのデフォルトルートは、ルートオーバーとメッシュアンダーの両方の6LoWPANルーティングシステムに挿入できることに注意してください。
IP-based LoWPAN technology is still in its early stage of development, but the range of conceivable usage scenarios is tremendous. The numerous possible applications of sensor networks make it obvious that mesh topologies will be prevalent in LoWPAN environments and robust routing will be a necessity for expedient communication. Research efforts in the area of sensor networking have put forth a large variety of multi-hop routing algorithms [Bulusu]. Most related work focuses on optimizing routing for specific application scenarios, which can be realized using several modes of communication, including the following [Watteyne]:
IPベースのLoWPAN技術はまだ開発の初期段階にありますが、考えられる使用シナリオの範囲は途方もないものです。センサーネットワークの多数の可能なアプリケーションにより、LoWPAN環境ではメッシュトポロジが普及し、適切な通信には堅牢なルーティングが必要であることは明らかです。センサーネットワーキングの分野での研究努力により、多種多様なマルチホップルーティングアルゴリズムが提供されています[Bulusu]。ほとんどの関連作業は、特定のアプリケーションシナリオのルーティングの最適化に焦点を当てています。これは、次の[Watteyne]を含むいくつかの通信モードを使用して実現できます。
o Flooding (in very small networks)
o フラッディング（非常に小規模なネットワーク）
o Hierarchical routing
o 階層型ルーティング
o Geographic routing
o 地理的ルーティング
o Self-organizing coordinate routing
o 自己組織化座標ルーティング
Depending on the topology of a LoWPAN and the application(s) running over it, different types of routing may be used. However, this document abstracts from application-specific communication and describes general routing requirements valid for overall routing in LoWPANs.
LoWPANとその上で実行されているアプリケーションのトポロジーに応じて、異なるタイプのルーティングが使用される場合があります。ただし、このドキュメントでは、アプリケーション固有の通信を抽象化し、LoWPANでの全体的なルーティングに有効な一般的なルーティング要件について説明します。
The following parameters can be used to describe specific scenarios in which the candidate routing protocols could be evaluated.
次のパラメータを使用して、候補ルーティングプロトコルを評価できる特定のシナリオを説明できます。
a. Network Properties:
a. ネットワークのプロパティ：
* Number of Devices, Density, and Network Diameter: These parameters usually affect the routing state directly (e.g., the number of entries in a routing table or neighbor list). Especially in large and dense networks, policies must be applied for discarding "low-quality" and stale routing entries in order to prevent memory overflow.
* デバイス数、密度、およびネットワーク直径：これらのパラメーターは通常、ルーティング状態に直接影響します（たとえば、ルーティングテーブルまたはネイバーリスト内のエントリ数）。特に大規模で高密度のネットワークでは、メモリのオーバーフローを防ぐために、「低品質」で古いルーティングエントリを破棄するポリシーを適用する必要があります。
* Connectivity: Due to external factors or programmed disconnections, a LoWPAN can be in several states of connectivity -- anything in the range from "always connected" to "rarely connected". This poses great challenges to the dynamic discovery of routes across a LoWPAN.
* 接続性：外部要因またはプログラムされた切断により、LoWPANは、「常時接続」から「ほとんど接続されていない」までの範囲の接続のいくつかの状態になる可能性があります。これは、LoWPAN全体のルートの動的な発見に大きな課題をもたらします。
* Dynamicity (including mobility): Location changes can be induced by unpredictable external factors or by controlled motion, which may in turn cause route changes. Also, nodes may dynamically be introduced into a LoWPAN and removed from it later. The routing state and the volume of control messages may heavily depend on the number of moving nodes in a LoWPAN and their speed, as well as how quickly and frequently environmental characteristics influencing radio propagation change.
* 動的性（移動性を含む）：場所の変更は、予測できない外部要因または制御された動きによって引き起こされ、ルートの変更を引き起こす可能性があります。また、ノードは動的にLoWPANに導入され、後でそこから削除されます。ルーティング状態と制御メッセージの量は、LoWPAN内の移動ノードの数とその速度、および無線伝搬の変化に影響を与える環境特性の速度と頻度に大きく依存します。
* Deployment: In a LoWPAN, it is possible for nodes to be scattered randomly or to be deployed in an organized manner. The deployment can occur at once, or as an iterative process, which may also affect the routing state.
* 展開：LoWPANでは、ノードがランダムに分散したり、組織的に展開されたりする可能性があります。展開は一度に、または反復プロセスとして行うことができ、ルーティング状態にも影響を与える可能性があります。
* Spatial Distribution of Nodes and Gateways: Network connectivity depends on the spatial distribution of the nodes and on other factors, such as device number, density, and transmission range. For instance, nodes can be placed on a grid, or randomly located in an area (as can be modeled by a two-dimensional Poisson distribution), etc. Assuming a random spatial distribution, an average of 7 neighbors per node are required for approximately 95% network connectivity (10 neighbors per node are needed for 99% connectivity) [Kuhn]. In addition, if the LoWPAN is connected to other networks through infrastructure nodes called gateways, the number and spatial distribution of these gateways affect network congestion and available data rate, among other things.
* ノードとゲートウェイの空間分布：ネットワーク接続は、ノードの空間分布と、デバイス数、密度、伝送範囲などの他の要因に依存します。たとえば、ノードはグリッド上に配置したり、エリアにランダムに配置したりできます（2次元ポアソン分布でモデル化できます）など。ランダムな空間分布を仮定すると、ノードごとに平均7つのネイバーが必要です。 95％のネットワーク接続（99％の接続にはノードあたり10個のネイバーが必要です）[Kuhn]。さらに、LoWPANがゲートウェイと呼ばれるインフラストラクチャノードを介して他のネットワークに接続されている場合、これらのゲートウェイの数と空間分布は、とりわけネットワークの輻輳と使用可能なデータレートに影響します。
* Traffic Patterns, Topology, and Applications: The design of a LoWPAN and the requirements for its application have a big impact on the network topology and the most efficient routing type to be used. For different traffic patterns (point-to-point, multipoint-to-point, point-to-multipoint) and network architectures, various routing mechanisms have been developed, such as data-centric, event-driven, address-centric, and geographic routing.
* トラフィックパターン、トポロジ、およびアプリケーション：LoWPANの設計とそのアプリケーションの要件は、ネットワークトポロジと使用する最も効率的なルーティングタイプに大きな影響を与えます。さまざまなトラフィックパターン（ポイントツーポイント、マルチポイントツーポイント、ポイントツーマルチポイント）およびネットワークアーキテクチャのために、データ中心、イベント駆動、アドレス中心、地理的など、さまざまなルーティングメカニズムが開発されていますルーティング。
* Classes of Service: For mixing applications of different criticality on one LoWPAN, support of multiple classes of service may be required in resource-constrained LoWPANs and may require a new routing protocol functionality.
* サービスクラス：1つのLoWPANで異なる重要度のアプリケーションを混在させるには、リソースが制限されたLoWPANで複数のサービスクラスのサポートが必要になる場合があり、新しいルーティングプロトコル機能が必要になる場合があります。
* Security: LoWPANs may carry sensitive information and require a high level of security support where the availability, integrity, and confidentiality of data are of prime relevance. Secured messages cause overhead and affect the power consumption of LoWPAN routing protocols.
* セキュリティ：LoWPANは機密情報を運ぶ可能性があり、データの可用性、整合性、および機密性が最も重要である高レベルのセキュリティサポートを必要とします。保護されたメッセージはオーバーヘッドを引き起こし、LoWPANルーティングプロトコルの電力消費に影響します。
b. Node Parameters:
b. ので ぱらめてｒｓ：
* Processing Speed and Memory Size: These basic parameters define the maximum size of the routing state and the maximum complexity of its processing. LoWPAN nodes may have different performance characteristics, queuing strategies, and queue buffer sizes.
* 処理速度とメモリサイズ：これらの基本的なパラメータは、ルーティング状態の最大サイズとその処理の最大の複雑さを定義します。 LoWPANノードには、さまざまなパフォーマンス特性、キューイング戦略、およびキューバッファーサイズがある場合があります。
* Power Consumption and Power Source: The number of battery- and mains-powered nodes and their positions in the topology created by them in a LoWPAN affect routing protocols in their selection of paths that optimize network lifetime.
* 消費電力と電源：バッテリーと主電源のノードの数と、LoWPANでそれらによって作成されたトポロジー内のノードの位置は、ネットワークの寿命を最適化するパスの選択におけるルーティングプロトコルに影響します。
* Transmission Range: This parameter affects routing. For example, a high transmission range may cause a dense network, which in turn results in more direct neighbors of a node, higher connectivity, and a larger routing state.
* 伝送範囲：このパラメーターはルーティングに影響します。たとえば、伝送範囲が広いと、ネットワークが密になり、ノードの隣接ノードがより直接的になり、接続性が高くなり、ルーティング状態が大きくなります。
* Traffic Pattern: This parameter affects routing, since highly loaded nodes (either because they are the source of packets to be transmitted or due to forwarding) may contribute to higher delivery delays and may consume more energy than lightly loaded nodes. This applies to both data packets and routing control messages.
* トラフィックパターン：このパラメータはルーティングに影響します。高負荷のノード（送信されるパケットのソースであるか、転送のため）は、配信遅延が大きくなり、負荷の軽いノードよりも多くのエネルギーを消費する可能性があるためです。これは、データパケットとルーティング制御メッセージの両方に適用されます。
c. Link Parameters: This section discusses link parameters that apply to IEEE 802.15.4 legacy mode (i.e., not making use of improved modulation schemes).
c. リンクパラメータ：このセクションでは、IEEE 802.15.4レガシーモードに適用されるリンクパラメータについて説明します（つまり、改良された変調方式を利用していません）。
* Throughput: The maximum user data throughput of a bulk data transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows [Latre]:
* スループット：理想的な条件でのスロット化されていないIEEE 802.15.4 2.4 GHzチャネルを介した単一の送信者と単一の受信者間のバルクデータ伝送の最大ユーザーデータスループットは、次のとおりです[Latre]：
+ 16-bit MAC addresses, unreliable mode: 151.6 kbit/s
+ 16-bit MAC addresses, reliable mode: 139.0 kbit/s
+ 64-bit MAC addresses, unreliable mode: 135.6 kbit/s
+ 64-bit MAC addresses, reliable mode: 124.4 kbit/s
Throughput for the 915 MHz band is as follows:
915 MHz帯域のスループットは次のとおりです。
+ 16-bit MAC addresses, unreliable mode: 31.1 kbit/s
+ 16-bit MAC addresses, reliable mode: 28.6 kbit/s
+ 64-bit MAC addresses, unreliable mode: 27.8 kbit/s
+ 64-bit MAC addresses, reliable mode: 25.6 kbit/s
Throughput for the 868 MHz band is as follows:
868 MHz帯域のスループットは次のとおりです。
+ 16-bit MAC addresses, unreliable mode: 15.5 kbit/s
+ 16-bit MAC addresses, reliable mode: 14.3 kbit/s
+ 64-bit MAC addresses, unreliable mode: 13.9 kbit/s
+ 64-bit MAC addresses, reliable mode: 12.8 kbit/s
* Latency: Latency ranges -- depending on payload size -- of a frame transmission between a single sender and a single receiver through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions are as shown below [Latre]. For unreliable mode, the actual latency is provided. For reliable mode, the round-trip time, including transmission of a Layer-2 acknowledgment, is provided:
* レイテンシ：ペイロードサイズに応じて、理想的な条件でのスロット化されていないIEEE 802.15.4 2.4 GHzチャネルを介した単一の送信者と単一の受信者の間のフレーム伝送のレイテンシの範囲は、以下のとおりです[Latre]。信頼性の低いモードでは、実際のレイテンシが提供されます。高信頼性モードでは、レイヤー2確認応答の送信を含む往復時間が提供されます。
+ 16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms]
+ 16ビットMACアドレス、信頼性の低いモード：[1.92 ms、6.02 ms]
+ 16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms]
+ 16ビットMACアドレス、高信頼性モード：[2.46 ms、6.56 ms]
+ 64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms]
+ 64ビットMACアドレス、信頼できないモード：[2.75ミリ秒、6.02ミリ秒]
+ 64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms]
+ 64ビットMACアドレス、高信頼性モード：[3.30 ms、6.56 ms]
Latency ranges for the 915 MHz band are as follows:
915 MHz帯域の遅延範囲は次のとおりです。
+ 16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms]
+ 16ビットMACアドレス、信頼できないモード：[5.85 ms、29.35 ms]
+ 16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms]
+ 16ビットMACアドレス、高信頼性モード：[8.35 ms、31.85 ms]
+ 64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms]
+ 64ビットMACアドレス、信頼できないモード：[8.95 ms、29.35 ms]
+ 64-bit MAC addresses, reliable mode: [11.45 ms, 31.82 ms]
+ 64ビットMACアドレス、高信頼性モード：[11.45 ms、31.82 ms]
Latency ranges for the 868 MHz band are as follows:
868 MHz帯域の遅延範囲は次のとおりです。
+ 16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms]
+ 16ビットMACアドレス、信頼できないモード：[11.7 ms、58.7 ms]
+ 16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms]
+ 16ビットMACアドレス、高信頼性モード：[16.7 ms、63.7 ms]
+ 64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms]
+ 64ビットMACアドレス、信頼性の低いモード：[17.9ミリ秒、58.7ミリ秒]
+ 64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms]
+ 64ビットMACアドレス、高信頼性モード：[22.9 ms、63.7 ms]
Note that some of the parameters presented in this section may be used as link or node evaluation metrics. However, multi-criteria routing may be too expensive for 6LoWPAN nodes. Rather, various single-criteria metrics are available and can be selected to suit the environment or application.
このセクションに示されているパラメータの一部は、リンクまたはノードの評価指標として使用される場合があることに注意してください。ただし、複数基準のルーティングは、6LoWPANノードにとって高すぎる可能性があります。むしろ、さまざまな単一基準メトリックが使用可能であり、環境またはアプリケーションに合わせて選択できます。
This section defines a list of requirements for 6LoWPAN routing. An important design property specific to low-power networks is that LoWPANs have to support multiple device types and roles, such as
このセクションでは、6LoWPANルーティングの要件のリストを定義します。低電力ネットワークに固有の重要な設計プロパティは、LoWPANが次のような複数のデバイスタイプと役割をサポートする必要があることです。
o host nodes drawing their power from primary batteries or using energy harvesting (sometimes called "power-constrained nodes")
o 一次電池から、またはエナジーハーベストを使用して電力を引き出すホストノード（「電力制限ノード」と呼ばれることもあります）
o mains-powered host nodes (an example of what we call "power-affluent nodes")
o 主電源式のホストノード（「電力影響ノード」と呼ばれるものの例）
o power-affluent (but not necessarily mains-powered) high-performance gateway(s)
o 電力消費量の多い（ただし、必ずしも主電源ではない）高性能ゲートウェイ
o nodes with various functionality (data aggregators, relays, local manager/coordinators, etc.)
o さまざまな機能を持つノード（データアグリゲーター、リレー、ローカルマネージャー/コーディネーターなど）
Due to these different device types and roles, LoWPANs need to consider the following two primary attributes:
これらの異なるデバイスタイプと役割のために、LoWPANは次の2つの主要な属性を考慮する必要があります。
o Power conservation: some devices are mains-powered, but many are battery-operated and need to last several months to a few years with a single AA battery. Many devices are mains-powered most of the time but still need to function on batteries for possibly extended periods (e.g., on a construction site before building power is switched on for the first time).
o 省電力：一部のデバイスは主電源で動作しますが、多くは電池式であり、単三電池1本で数か月から数年持続する必要があります。多くのデバイスは、ほとんどの場合、主電源で動作しますが、バッテリで機能する必要がある可能性がありますが、長期間（たとえば、建設現場で初めて電源を入れる前に）機能する必要があります。
o Low performance: tiny devices, small memory sizes, low-performance processors, low bandwidth, high loss rates, etc.
o 低パフォーマンス：小さなデバイス、小さなメモリサイズ、低パフォーマンスプロセッサ、低帯域幅、高損失率など
These fundamental attributes of LoWPANs affect the design of routing solutions. Whether existing routing specifications are simplified and modified, or new solutions are introduced in order to fit the low-power requirements of LoWPANs, they need to meet the requirements described below.
LoWPANのこれらの基本的な属性は、ルーティングソリューションの設計に影響を与えます。 LoWPANの低電力要件に適合するために、既存のルーティング仕様が簡略化および変更されているか、新しいソリューションが導入されているかにかかわらず、それらは以下に説明する要件を満たす必要があります。
The general objectives listed in this section should be met by 6LoWPAN routing protocols. The importance of each requirement is dependent on what node type the protocol is running on and what the role of the node is. The following requirements consider the presence of battery-powered nodes in LoWPANs.
このセクションにリストされている一般的な目的は、6LoWPANルーティングプロトコルによって満たされる必要があります。各要件の重要性は、プロトコルが実行されているノードのタイプとノードの役割に依存します。次の要件は、LoWPAN内のバッテリー駆動ノードの存在を考慮しています。
[R01] 6LoWPAN routing protocols SHOULD allow implementation with small code size and require low routing state to fit the typical 6LoWPAN node capacity. Generally speaking, the code size is bounded by available flash memory size, and the routing table is bounded by RAM size, possibly limiting it to less than 32 entries.
[R01] 6LoWPANルーティングプロトコルは、小さなコードサイズでの実装を可能にし、典型的な6LoWPANノード容量に適合するために低いルーティング状態を必要とします（SHOULD）。一般的に言って、コードサイズは利用可能なフラッシュメモリサイズによって制限され、ルーティングテーブルはRAMサイズによって制限され、32エントリ未満に制限される可能性があります。
The RAM size of LoWPAN nodes often ranges between 4 KB and 10 KB (2 KB minimum), and program flash memory normally consists of 48 KB to 128 KB. (For example, in the current market, MICAz has 128 KB program flash, 4 KB EEPROM, and 512 KB external flash ROM; TIP700CM has 48 KB program flash, 10 KB RAM, and 1 MB external flash ROM.)
LoWPANノードのRAMサイズは、多くの場合4 KBから10 KB（最小2 KB）の範囲で、プログラムフラッシュメモリは通常48 KBから128 KBで構成されます。 （たとえば、現在の市場では、MICAzには128 KBのプログラムフラッシュ、4 KBのEEPROM、および512 KBの外部フラッシュROMがあり、TIP700CMには48 KBのプログラムフラッシュ、10 KBのRAM、および1 MBの外部フラッシュROMがあります。）
Due to these hardware restrictions, code SHOULD fit within a small memory size -- no more than 48 KB to 128 KB of flash memory, including at least a few tens of KB of application code size. (As a general observation, a routing protocol of low complexity may help achieve the goal of reducing power consumption, improves robustness, requires lower routing state, is easier to analyze, and may be less prone to security attacks.)
これらのハードウェアの制限により、コードは小さなメモリサイズ内に収まる必要があります-少なくとも数十KBのアプリケーションコードサイズを含む、48 KBから128 KB以下のフラッシュメモリ。 （一般的な観察として、複雑度の低いルーティングプロトコルは、電力消費の削減、堅牢性の向上、低いルーティング状態の要求、分析の容易さ、およびセキュリティ攻撃を受けにくい可能性があるという目標の達成に役立ちます。）
In addition, operation with limited amounts of routing state (such as routing tables and neighbor lists) SHOULD be maintained, since some typical memory sizes preclude storing state of a large number of nodes. For instance, industrial monitoring applications may need to support a maximum of 20 hops [RFC5673]. Small networks can be designed to support a smaller number of hops. While the need for this is highly dependent on the network architecture, there should be at least one mode of operation that can function with 32 forwarding entries or less.
さらに、いくつかの一般的なメモリサイズでは多数のノードの状態を保存できないため、ルーティング状態の制限された操作（ルーティングテーブルやネイバーリストなど）を維持する必要があります。たとえば、産業用監視アプリケーションは最大20ホップをサポートする必要がある場合があります[RFC5673]。小規模なネットワークは、より少ない数のホップをサポートするように設計できます。これの必要性はネットワークアーキテクチャに大きく依存しますが、32以下の転送エントリで機能できる動作モードが少なくとも1つ必要です。
[R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by efficiently using control packets (e.g., minimizing expensive IP multicast, which causes link broadcast to the entire LoWPAN) and by efficiently routing data packets.
6LoWPANルーティングプロトコルは、制御パケットを効率的に使用して（たとえば、LoWPAN全体へのリンクブロードキャストを引き起こす高価なIPマルチキャストを最小限に抑える）、データパケットを効率的にルーティングすることにより、最小限の電力消費を引き起こす必要があります（SHOULD）。
One way of optimizing battery lifetime is by achieving a minimal control message overhead. Compared to such functions as computational operations or taking sensor samples, radio communication is by far the dominant factor of power consumption [Doherty]. Power consumption of transmission and/or reception depends linearly on the length of data units and on the frequency of transmission and reception of the data units [Shih].
バッテリー寿命を最適化する1つの方法は、制御メッセージのオーバーヘッドを最小限に抑えることです。計算操作やセンサーサンプルの取得などの機能と比較して、無線通信は電力消費の主な要因です[Doherty]。送信および/または受信の電力消費は、データユニットの長さとデータユニットの送信および受信の頻度に線形に依存します[Shih]。
The energy consumption of two example radio frequency (RF) controllers for low-power nodes is shown in [Hill]. The TR1000 radio consumes 21 mW when transmitting at 0.75 mW, and 15 mW during reception (with a receiver sensitivity of -85 dBm). The CC1000 consumes 31.6 mW when transmitting at 0.75 mW, and 20 mW during reception (with a receiver sensitivity of -105 dBm). Power endurance under the concept of an idealized power source is explained in [Hill]. Based on the energy of an idealized AA battery, the CC1000 can transmit for approximately 4 days straight or receive for 9 consecutive days. Note that availability for reception consumes power as well.
低電力ノード用の2つの無線周波数（RF）コントローラーの例のエネルギー消費量を[ヒル]に示します。 TR1000無線は、0.75 mWで送信するときに21 mWを消費し、受信中に15 mWを消費します（受信感度は-85 dBm）。 CC1000は、0.75 mWで送信する場合は31.6 mWを消費し、受信中は20 mWを消費します（受信感度は-105 dBm）。理想的な電源のコンセプトの下での電力耐久性は、[ヒル]で説明されています。理想的な単三電池のエネルギーに基づいて、CC1000は約4日間連続して送信することも、9日間連続して受信することもできます。受信の可用性も電力を消費することに注意してください。
As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing protocol SHOULD minimize the control cost by multicasting routing packets.
マルチキャストはLoWPANでフラッディングを引き起こす可能性があるため、6LoWPANルーティングプロトコルは、ルーティングパケットをマルチキャストすることにより、制御コストを最小化する必要があります（SHOULD）。
Control cost of routing protocols in low-power and lossy networks is discussed in more detail in [ROLL-PROTOCOLS].
低電力で損失の多いネットワークにおけるルーティングプロトコルの制御コストについては、[ROLL-PROTOCOLS]で詳しく説明しています。
6LoWPAN links have the characteristics of low data rate and possibly high loss rates. The routing requirements described in this section are derived from the link properties.
6LoWPANリンクには、データレートが低く、損失率が高いという特徴があります。このセクションで説明するルーティング要件は、リンクプロパティから派生しています。
[R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a single IEEE 802.15.4 frame size, in order to avoid packet fragmentation and the overhead for reassembly.
[R03] 6LoWPANルーティングプロトコル制御メッセージは、パケットの断片化と再構成のオーバーヘッドを回避するために、単一のIEEE 802.15.4フレームサイズを超えてはなりません。
In order to save energy, routing overhead should be minimized to prevent fragmentation of frames. Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE 802.15.4 frame size. This reduces the energy required for transmission, avoids unnecessary waste of bandwidth, and prevents the need for packet reassembly. The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding about 80 octets of actual MAC payload with security enabled, some of which is taken for the (typically compressed) IP header [RFC6282]. Avoiding fragmentation at the adaptation layer may imply the use of semantic fragmentation and/or algorithms that can work on small increments of routing information.
エネルギーを節約するために、ルーティングのオーバーヘッドを最小限に抑えて、フレームの断片化を防止する必要があります。したがって、6LoWPANルーティングにより、パケットがIEEE 802.15.4フレームサイズを超えることはありません。これにより、送信に必要なエネルギーが削減され、帯域幅の不要な浪費が回避され、パケットの再構成が不要になります。 [IEEE802.15.4]規格では127バイトのMTUが指定されており、セキュリティが有効になっている実際のMACペイロードは約80オクテットであり、その一部は（通常は圧縮された）IPヘッダー[RFC6282]に使用されます。アダプテーション層での断片化を回避することは、セマンティックフラグメンテーションやルーティング情報の小さな増分で機能するアルゴリズムの使用を意味する場合があります。
[R04] The design of routing protocols for LoWPANs must consider the fact that packets are to be delivered with sufficient probability according to application requirements.
[R04] LoWPANのルーティングプロトコルの設計では、アプリケーションの要件に従ってパケットが十分な確率で配信されることを考慮する必要があります。
Requirements for a successful end-to-end packet delivery ratio (where delivery may be bounded within certain latency levels) vary, depending on the application. In industrial applications, some non-critical monitoring applications may tolerate a successful delivery ratio of less than 90% with hours of latency;
エンドツーエンドのパケット配信率（配信が特定のレイテンシレベル内で制限される場合がある）を成功させるための要件は、アプリケーションによって異なります。産業用アプリケーションでは、重要でない監視アプリケーションの中には、数時間のレイテンシで90％未満の配信率を許容できるものがあります。
in some other cases, a delivery ratio of 99.9% is required [RFC5673]. In building automation applications, application-layer errors must be below 0.01% [RFC5867].
他のいくつかのケースでは、99.9％の配信率が必要です[RFC5673]。ビルディングオートメーションアプリケーションでは、アプリケーション層のエラーは0.01％未満でなければなりません[RFC5867]。
Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh depends on the quality of the path selected by the routing protocol and on the ability of the routing protocol to cope with short-term and long-term quality variation. The metric of the routing protocol strongly influences performance of the routing protocol in terms of delivery ratio.
IEEE 802.15.4メッシュでのパケットのエンドツーエンド配信が成功するかどうかは、ルーティングプロトコルによって選択されたパスの品質と、短期的および長期的な品質変動に対処するルーティングプロトコルの能力に依存します。ルーティングプロトコルのメトリックは、配信率に関してルーティングプロトコルのパフォーマンスに強く影響します。
The quality of a given path depends on the individual qualities of the links (including the devices) that compose that path. IEEE 802.15.4 settings affect the quality perceived at upper layers. In particular, in IEEE 802.15.4 reliable mode, if an acknowledgment frame is not received after a given period, the originator retries frame transmission up to a maximum number of times. If an acknowledgment frame is still not received by the sender after performing the maximum number of transmission attempts, the MAC layer assumes that the transmission has failed and notifies the next higher layer of the failure. Note that excessive retransmissions may be detrimental; see RFC 3819 [RFC3819].
特定のパスの品質は、そのパスを構成するリンク（デバイスを含む）の個々の品質に依存します。 IEEE 802.15.4設定は、上位層で知覚される品質に影響を与えます。特に、IEEE 802.15.4の信頼性の高いモードでは、所定の期間が経過しても確認応答フレームが受信されない場合、発信者は最大回数までフレーム送信を再試行します。最大数の送信試行を行った後も確認応答フレームが送信者によって受信されない場合、MAC層は送信が失敗したと見なし、次の上位層に通知します。過度の再送信は有害な場合があることに注意してください。 RFC 3819 [RFC3819]を参照してください。
[R05] The design of routing protocols for LoWPANs must consider the latency requirements of applications and IEEE 802.15.4 link latency characteristics.
[R05] LoWPANのルーティングプロトコルの設計では、アプリケーションの遅延要件とIEEE 802.15.4リンク遅延特性を考慮する必要があります。
Latency requirements may differ -- e.g., from a few hundred milliseconds to minutes -- depending on the type of application. Real-time building automation applications usually need response times below 500 ms between egress and ingress, while forced-entry security alerts must be routed to one or more fixed or mobile user devices within 5 seconds [RFC5867]. Non-critical closed-loop applications for industrial automation have latency requirements that can be as low as 100 ms, but many control loops are tolerant of latencies above 1 s [RFC5673]. In contrast, urban monitoring applications allow latencies smaller than the typical intervals used for reporting sensed information -- for instance, on the order of seconds to minutes [RFC5548].
レイテンシー要件は、アプリケーションのタイプによって異なります（たとえば、数百ミリ秒から数分）。リアルタイムのビルディングオートメーションアプリケーションでは、通常、下りと上りの間で500ミリ秒未満の応答時間が必要ですが、強制エントリーセキュリティアラートは、5秒以内に1つ以上の固定またはモバイルユーザーデバイスにルーティングする必要があります[RFC5867]。産業オートメーション向けの重要ではないクローズドループアプリケーションには、100ミリ秒までのレイテンシ要件がありますが、多くの制御ループは1秒を超えるレイテンシを許容します[RFC5673]。対照的に、都市の監視アプリケーションでは、感知された情報を報告するために使用される通常の間隔よりも短い待機時間を許可します。たとえば、数秒から数分です[RFC5548]。
The range of latencies of a frame transmission between a single sender and a single receiver through an ideal unslotted IEEE 802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms with 64-bit MAC addresses in unreliable mode, and between 2.20 ms and 6.56 ms with 64-bit MAC addresses in reliable mode. The range of latencies of the 868 MHz band is from 11.7 ms to 63.7 ms, depending on the address type and mode used (reliable or unreliable). Note that the latencies may be larger than that, depending on channel load, the MAC-layer settings, and the choice of reliable or unreliable mode. Note that MAC approaches other than legacy 802.15.4 may be used (e.g., TDMA). Duty cycling may further affect latency (see [R08]). Depending on the routing path chosen and the network diameter, multiple hops may contribute to the end-to-end latency that an application may experience.
スロットなしの理想的なIEEE 802.15.4 2.4 GHzチャネルを介した単一の送信者と単一の受信者の間のフレーム伝送の遅延の範囲は、信頼性の低いモードの64ビットMACアドレスで2.46 msと6.02 msの間であり、2.20 msと6.56の間です。信頼性の高いモードで64ビットのMACアドレスを使用したms。 868 MHz帯域のレイテンシの範囲は、使用されるアドレスの種類とモード（信頼できるかどうか）に応じて、11.7ミリ秒から63.7ミリ秒です。チャネルの負荷、MAC層の設定、および信頼性のあるモードと信頼性のないモードの選択に応じて、待ち時間がそれよりも長くなる可能性があることに注意してください。レガシー802.15.4以外のMACアプローチが使用される場合があることに注意してください（TDMAなど）。デューティサイクルはレイテンシにさらに影響を与える可能性があります（[R08]を参照）。選択したルーティングパスとネットワークの直径に応じて、複数のホップが、アプリケーションで発生する可能性のあるエンドツーエンドのレイテンシに影響する場合があります。
Note that a tradeoff exists between [R05] and [R04].
[R05]と[R04]の間にはトレードオフが存在することに注意してください。
[R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss caused by link failure or device unavailability either in the short term (approx. 30 ms) -- due to Received Signal Strength Indication (RSSI) variation, interference variation, noise, and asynchrony -- or in the long term, due to a depleted power source, hardware breakdown, operating system misbehavior, etc.
[R06] 6LoWPANルーティングプロトコルは、短期間（約30 ms）でのリンク障害またはデバイスの使用不可によって引き起こされる動的な損失に対して堅牢である必要があります-受信信号強度表示（RSSI）の変動、干渉の変動、ノイズ、および非同期による-または長期的には、電源の枯渇、ハードウェアの故障、オペレーティングシステムの誤動作などが原因です。
An important trait of 6LoWPAN devices is their unreliability, which can be due to limited system capabilities and possibly being closely coupled to the physical world with all its unpredictable variations. In harsh environments, LoWPANs easily suffer from link failure. Collisions or link failures easily increase send and receive queues and can lead to queue overflow and packet losses.
6LoWPANデバイスの重要な特性は、信頼性が低いことです。これは、システム機能が制限されていたり、予測不可能なすべてのバリエーションで物理世界に密接に結合している可能性があります。厳しい環境では、LoWPANは簡単にリンク障害に悩まされます。衝突やリンク障害は送信キューと受信キューを簡単に増やし、キューのオーバーフローとパケット損失につながる可能性があります。
For home applications, where users expect feedback after carrying out certain actions (such as handling a remote control while moving around), routing protocols must converge within 2 seconds if the destination node of the packet has moved and must converge within 0.5 seconds if only the sender has moved [RFC5826]. The tolerance of the recovery time can vary, depending on the application; however, the routing protocol must provide the detection of short-term unavailability and long-term disappearance. The routing protocol has to exploit network resources (e.g., path redundancy) to offer good network behavior despite node failure.
ユーザーが特定のアクション（移動中のリモートコントロールの処理など）を実行した後にフィードバックを期待するホームアプリケーションの場合、ルーティングプロトコルは、パケットの宛先ノードが移動した場合は2秒以内に収束し、パケットのみの場合は0.5秒以内に収束する必要があります。送信者は[RFC5826]を移動しました。リカバリ時間の許容範囲は、アプリケーションによって異なります。ただし、ルーティングプロトコルは、短期的な利用不可と長期的な消失の検出を提供する必要があります。ルーティングプロトコルは、ノード障害が発生しても良好なネットワーク動作を提供するために、ネットワークリソース（パスの冗長性など）を利用する必要があります。
Different routing protocols may exhibit different scaling characteristics with respect to the recovery/convergence time and the computational resources to achieve recovery after a convergence; see also [R01] and [R10].
異なるルーティングプロトコルは、コンバージェンス後のリカバリを実現するために、リカバリ/コンバージェンス時間と計算リソースに関して異なるスケーリング特性を示す場合があります。 [R01]と[R10]も参照してください。
[R07] 6LoWPAN routing protocols SHOULD be designed to correctly operate in the presence of link asymmetry.
[R07] 6LoWPANルーティングプロトコルは、リンク非対称の存在下で正しく動作するように設計する必要があります（SHOULD）。
Link asymmetry occurs when the probability of successful transmission between two nodes is significantly higher in one direction than in the other. This phenomenon has been reported in a large number of experimental studies, and it is expected that 6LoWPANs will exhibit link asymmetry.
リンクの非対称性は、2つのノード間の送信が成功する確率が、一方向の方が他の方向よりも大幅に高い場合に発生します。この現象は多くの実験的研究で報告されており、6LoWPANはリンクの非対称性を示すことが予想されます。
6LoWPANs can be deployed in different sizes and topologies, adhere to various models of mobility, be exposed to various levels of interference, etc. In any case, LoWPANs must maintain low energy consumption. The requirements described in this subsection are derived from the network attributes of 6LoWPANs.
6LoWPANは、さまざまなサイズとトポロジで展開したり、さまざまなモビリティモデルに準拠したり、さまざまなレベルの干渉にさらしたりすることができます。いずれの場合も、LoWPANは低エネルギー消費を維持する必要があります。このサブセクションで説明する要件は、6LoWPANのネットワーク属性から派生しています。
[R08] The design of 6LoWPAN routing protocols SHOULD take into account that some nodes may be unresponsive during certain time intervals, due to periodic hibernation.
[R08] 6LoWPANルーティングプロトコルの設計では、定期的な休止状態のために、一部のノードが特定の時間間隔中に応答しない場合があることを考慮してください。
Many nodes in LoWPAN environments might periodically hibernate (i.e., disable their transceiver activity) in order to save energy. Therefore, routing protocols must ensure robust packet delivery despite nodes frequently shutting off their radio transmission interface. Feedback from the lower IEEE 802.15.4 layer may be considered to enhance the power awareness of 6LoWPAN routing protocols.
LoWPAN環境の多くのノードは、エネルギーを節約するために、定期的に休止（つまり、トランシーバーアクティビティを無効にする）する場合があります。したがって、ルーティングプロトコルは、ノードが無線伝送インターフェイスを頻繁に遮断しても、堅牢なパケット配信を保証する必要があります。下位のIEEE 802.15.4レイヤーからのフィードバックは、6LoWPANルーティングプロトコルの電力認識を強化すると考えられます。
CC1000-based nodes must operate at a duty cycle of approximately 2% to survive for one year from an idealized AA battery power source [Hill]. For home automation purposes, it is suggested that the devices have to maximize the sleep phase with a duty cycle lower than 1% [RFC5826], while in building automation applications, batteries must be operational for at least 5 years when the sensing devices are transmitting data (e.g., 64 bytes) once per minute [RFC5867].
CC1000ベースのノードは、理想的なAAバッテリー電源[Hill]から1年間存続するには、約2％のデューティサイクルで動作する必要があります。ホームオートメーションの目的では、デバイスが1％未満のデューティサイクルでスリープフェーズを最大化する必要があることをお勧めします[RFC5826]。ビルディングオートメーションアプリケーションでは、センサーデバイスが送信しているとき、バッテリーが少なくとも5年間動作している必要があります。データ（64バイトなど）が1分間に1回[RFC5867]。
Depending on the application in use, packet rates may range from one per second to one per day, or beyond. Routing protocols may take advantage of knowledge about the packet transmission rate and utilize this information in calculating routing paths. In many IEEE 802.15.4 deployments, and in other wireless low-power technologies, forwarders are mains-powered devices (and hence do not need to sleep). However, it cannot be assumed that all forwarders are mains-powered. A routing protocol that addresses this case SHOULD provide a mode in which power consumption is a metric. In addition, using nodes in power-saving modes for forwarding may increase delay and reduce the probability of packet delivery, which in this case also should be available as an input into the path computation.
使用しているアプリケーションに応じて、パケットレートは1秒あたり1〜1日あたりの範囲、またはそれ以上になります。ルーティングプロトコルは、パケットの伝送速度に関する知識を利用し、この情報をルーティングパスの計算に利用できます。多くのIEEE 802.15.4展開、およびその他のワイヤレス低電力テクノロジーでは、フォワーダーは主電源のデバイスです（したがって、スリープする必要はありません）。ただし、すべてのフォワーダーが商用電源であるとは限りません。このケースに対処するルーティングプロトコルは、消費電力がメトリックであるモードを提供する必要があります（SHOULD）。さらに、転送のために節電モードでノードを使用すると、遅延が増加し、パケット配信の確率が低下する可能性があります。この場合、パス計算への入力としても使用できるはずです。
[R09] The metric used by 6LoWPAN routing protocols SHOULD provide some flexibility with respect to the inputs provided by the lower layers and other measures to optimize path selection, considering energy balance and link qualities.
[R09] 6LoWPANルーティングプロトコルで使用されるメトリックは、エネルギーバランスとリンク品質を考慮して、パス選択を最適化するために、下位層と他の手段によって提供される入力に関してある程度の柔軟性を提供する必要があります。
In homes, buildings, or infrastructure, some nodes will be installed with mains power. Such power-installed nodes MUST be considered as relay points for a prominent role in packet delivery. 6LoWPAN routing protocols MUST know the power constraints of the nodes.
家、建物、またはインフラストラクチャでは、一部のノードは主電源でインストールされます。このような電源がインストールされたノードは、パケット配信における重要な役割の中継ポイントと見なす必要があります。 6LoWPANルーティングプロトコルは、ノードの電力制約を認識している必要があります。
Simple hop-count-only mechanisms may be inefficient in 6LoWPANs. There is a Link Quality Indication (LQI) and/or RSSI from IEEE 802.15.4 that may be taken into account for better metrics. The metric to be used (and its goal) may depend on applications and requirements.
単純なホップカウントのみのメカニズムは、6LoWPANでは非効率的です。より良いメトリックのために考慮される可能性のあるIEEE 802.15.4からのリンク品質表示（LQI）および/またはRSSIがあります。使用するメトリック（およびその目標）は、アプリケーションと要件によって異なります。
The numbers in Figure 4 represent the Link Delivery Ratio (LDR) of each pair of nodes. There are studies that show a piecewise linear dependence between the LQI and the LDR [Chen].
図4の数値は、ノードの各ペアのリンク配信率（LDR）を表しています。 LQIとLDRの間の区分的線形依存性を示す研究があります[陳]。
0.6
A-------C
\ /
0.9 \ / 0.9
\ /
B
Figure 4: An Example Network
図4：ネットワークの例
In this simple example, there are two options in routing from node A to node C, with the following features:
この単純な例では、ノードAからノードCへのルーティングに2つのオプションがあり、次の機能があります。
A. Path AC:
A.パスAC：
+ (1/0.6) = 1.67 avg. transmissions needed for each packet (confirmed link-layer delivery with retransmissions and negligible ACK loss have been assumed)
+ （1 / 0.6）= 1.67平均各パケットに必要な送信（再送信および無視できるACK損失を伴う確認済みのリンク層配信が想定されています）
+ one-hop path
+ ワンホップパス
+ good energy consumption and end-to-end latency of data packets, poor delivery ratio (0.6)
+ データパケットのエネルギー消費とエンドツーエンドのレイテンシが良好で、配信率が低い（0.6）
+ poor probability of route reconfigurations
+ ルート再構成の確率が低い
B. Path ABC:
B.パスABC：
+ (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each
packet (under the same assumptions as above)
+ two-hop path
+ 2ホップパス
+ poor energy consumption and end-to-end latency of data packets, good delivery ratio (0.81)
+ データパケットのエネルギー消費とエンドツーエンドのレイテンシが低く、配信率が高い（0.81）
If energy consumption of the network must be minimized, path AC is the best (this path would be chosen based on a hop-count metric). However, if the delivery ratio in that case is not sufficient, the best path is ABC (it would be chosen by an LQI-based metric). Combinations of both metrics can be used.
ネットワークのエネルギー消費を最小限に抑える必要がある場合は、パスACが最適です（このパスはホップカウントメトリックに基づいて選択されます）。ただし、その場合の配信率が十分でない場合、最適なパスはABCです（LQIベースのメトリックによって選択されます）。両方のメトリックの組み合わせを使用できます。
The metric also affects the probability of route reconfiguration. Route reconfiguration, which may be triggered by packet losses, may require transmission of routing protocol messages. It is possible to use a metric aimed at selecting the path with a low route reconfiguration rate by using the LQI as an input to the metric. Such a path has good properties, including stability and low control message overhead.
メトリックは、ルートの再構成の確率にも影響します。パケット損失によってトリガーされる可能性があるルート再構成では、ルーティングプロトコルメッセージの送信が必要になる場合があります。 LQIをメトリックへの入力として使用することにより、ルート再構成率の低いパスを選択することを目的としたメトリックを使用することが可能です。このようなパスには、安定性や制御メッセージのオーバーヘッドが低いなど、優れた特性があります。
Note that a tradeoff exists between [R09] and [R01].
[R09]と[R01]の間にはトレードオフが存在することに注意してください。
[R10] 6LoWPAN routing protocols SHOULD be designed to achieve both scalability -- from a few nodes to maybe millions of nodes -- and minimal use of system resources.
[R10] 6LoWPANルーティングプロトコルは、スケーラビリティ（数ノードから数百万ノードまで）とシステムリソースの最小限の使用の両方を実現するように設計する必要があります（SHOULD）。
A LoWPAN may consist of just a couple of nodes (for instance, in a body-area network), but may also contain much higher numbers of devices (e.g., monitoring of a city infrastructure or a highway). For home automation applications, it is envisioned that the routing protocol must support 250 devices in the network [RFC5826], while routing protocols for metropolitan-scale sensor networks must be capable of clustering a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each [RFC5548]. It is therefore necessary that routing mechanisms are designed to be scalable for operation in networks of various sizes. However, due to a lack of memory size and computational power, 6LoWPAN routing might limit forwarding entries to a small number, such as a maximum of 32 routing table entries. Particularly in large networks, the routing mechanism MUST be designed in such a way that the number of routers is smaller than the number of hosts.
LoWPANは、（たとえば、ボディエリアネットワーク内の）いくつかのノードだけで構成されている場合がありますが、はるかに多くのデバイス（都市インフラや高速道路の監視など）を含む場合もあります。ホームオートメーションアプリケーションの場合、ルーティングプロトコルはネットワーク[RFC5826]で250デバイスをサポートする必要があると想定されていますが、大都市規模のセンサーネットワークのルーティングプロトコルは、多数のセンシングノードを次の順序で含む領域にクラスター化できる必要があります。それぞれ10 ^ 2〜10 ^ 4のセンシングノード[RFC5548]。したがって、ルーティングメカニズムは、さまざまなサイズのネットワークで動作するようにスケーラブルに設計されている必要があります。ただし、メモリサイズと計算能力が不足しているため、6LoWPANルーティングでは、転送エントリを、最大32のルーティングテーブルエントリなど、少数に制限する場合があります。特に大規模なネットワークでは、ルーターの数がホストの数よりも少なくなるようにルーティングメカニズムを設計する必要があります。
[R11] The procedure of route repair and related control messages SHOULD NOT harm overall energy consumption from the routing protocols.
[R11]ルート修復と関連する制御メッセージの手順は、ルーティングプロトコルからの全体的なエネルギー消費に害を及ぼさないでください。
Local repair improves throughput and end-to-end latency, especially in large networks. Since routes are repaired quickly, fewer data packets are dropped, and a smaller number of routing protocol packet transmissions are needed, since routes can be repaired without source-initiated route discovery [Lee]. One important consideration here may be to avoid premature energy depletion, even if that impairs other requirements.
ローカル修復により、特に大規模ネットワークにおいて、スループットとエンドツーエンドのレイテンシが向上します。ルートはソースによって開始されたルートディスカバリなしで修復できるため、ルートは迅速に修復され、ドロップされるデータパケットは少なくなり、ルーティングプロトコルパケット送信の数も少なくなります[Lee]。ここで重要な考慮事項の1つは、他の要件を損なう場合であっても、時期尚早のエネルギー枯渇を回避することです。
[R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive topologies and mobile nodes. When supporting dynamic topologies and mobile nodes, route maintenance should keep in mind the goal of a minimal routing state and routing protocol message overhead.
[R12] 6LoWPANルーティングプロトコルは、動的に適応するトポロジとモバイルノードを許可する必要があります（SHOULD）。動的トポロジとモバイルノードをサポートする場合、ルートメンテナンスでは、ルーティング状態とルーティングプロトコルメッセージのオーバーヘッドを最小限に抑えるという目標に留意する必要があります。
Topological node mobility may be the result of physical movement and/or a changing radio environment, making it very likely that mobility needs to be handled even in a network with physically static nodes. 6LoWPANs do not make use of a separate protocol to maintain connectivity to moving nodes but expects the routing protocol to handle it.
トポロジーノードモビリティは、物理的な移動や無線環境の変化の結果である可能性があり、物理的に静的なノードがあるネットワークでもモビリティを処理する必要がある可能性が高くなります。 6LoWPANは、移動するノードへの接続を維持するために別個のプロトコルを使用しませんが、ルーティングプロトコルがそれを処理することを期待しています。
In addition, some nodes may move from one 6LoWPAN to another and are expected to become functional members of the latter 6LoWPAN in a limited amount of time.
さらに、一部のノードは1つの6LoWPANから別の6LoWPANに移動する可能性があり、限られた時間内に後者の6LoWPANの機能メンバーになることが期待されます。
Building monitoring applications, for instance, have a number of requirements with respect to recovery and settling time for mobility that range between 5 and 20 seconds (Section 5.3.1 of [RFC5867]). For more interactive applications such as those used in home automation systems, where users provide input and expect instant feedback, mobility requirements are also stricter and, for moves within a network, a convergence time below 0.5 seconds is commonly required (Section 3.2 of [RFC5826]). In industrial environments, where mobile equipment (e.g., cranes) moves around, the routing protocol needs to support vehicular speeds of up to 35 km/h [RFC5673]. Currently, 6LoWPANs are not normally being used for such fast mobility, but dynamic association and disassociation MUST be supported in 6LoWPANs.
たとえば、建物監視アプリケーションには、モビリティの回復時間と整定時間に関して、5〜20秒の範囲の要件がいくつかあります（[RFC5867]のセクション5.3.1）。ホームオートメーションシステムで使用されるようなよりインタラクティブなアプリケーションでは、ユーザーが入力を提供し、即時フィードバックを期待するため、モビリティ要件もより厳しく、ネットワーク内の移動では、通常0.5秒未満の収束時間が必要です（[RFC5826のセクション3.2 ]）。モバイル機器（クレーンなど）が動き回る産業環境では、ルーティングプロトコルは最大35 km / hの車両速度をサポートする必要があります[RFC5673]。現在、6LoWPANは通常、このような高速モビリティに使用されていませんが、動的な関連付けと関連付け解除は6LoWPANでサポートされている必要があります。
There are several challenges that should be addressed by a 6LoWPAN routing protocol in order to create robust routing in dynamic environments:
動的環境で堅牢なルーティングを作成するには、6LoWPANルーティングプロトコルで対処する必要があるいくつかの課題があります。
* Mobile Nodes Changing Their Location inside a LoWPAN: If the nodes' movement pattern is unknown, mobility cannot easily be detected or distinguished by the routing protocols. Mobile nodes can be treated as nodes that disappear and reappear in another place. The tracking of movement patterns increases complexity and can be avoided by handling moving nodes using reactive route updates.
* LoWPAN内でのモバイルノードの場所の変更：ノードの移動パターンが不明な場合、ルーティングプロトコルではモビリティを簡単に検出または識別できません。モバイルノードは、消えて別の場所に再び現れるノードとして扱うことができます。移動パターンの追跡は複雑さを増し、リアクティブなルート更新を使用して移動ノードを処理することで回避できます。
* Movement of a LoWPAN with Respect to Other (Inter)Connected LoWPANs: Within each stub network, (one or more) relatively powerful gateway nodes (6LBRs) need to be configured to handle moving LoWPANs.
* 他の（相互）接続されたLoWPANに関するLoWPANの移動：各スタブネットワーク内で、（1つ以上の）比較的強力なゲートウェイノード（6LBR）を、移動するLoWPANを処理するように構成する必要があります。
* Nodes Permanently Joining or Leaving the LoWPAN: In order to ease routing table updates, reduce the size of these updates, and minimize error control messages, nodes leaving the network may announce their disassociation to the closest edge router or to a specific node (if any) that takes charge of local association and disassociation.
* LoWPANに恒久的に参加または離脱するノード：ルーティングテーブルの更新を容易にし、これらの更新のサイズを縮小し、エラー制御メッセージを最小限に抑えるために、ネットワークを離脱するノードは、最も近いエッジルーターまたは特定のノード（存在する場合）への関連付け解除を通知する）これは、地域の協会と団体の分離を担当します。
[R13] A 6LoWPAN routing protocol SHOULD support various traffic patterns -- point-to-point, point-to-multipoint, and multipoint-to-point -- while avoiding excessive multicast traffic in a LoWPAN.
[R13] 6LoWPANルーティングプロトコルは、LoWPANでの過剰なマルチキャストトラフィックを回避しながら、さまざまなトラフィックパターン（ポイントツーポイント、ポイントツーマルチポイント、マルチポイントツーポイント）をサポートする必要があります（SHOULD）。
6LoWPANs often have point-to-multipoint or multipoint-to-point traffic patterns. Many emerging applications include point-to-point communication as well. 6LoWPAN routing protocols should be designed with the consideration of forwarding packets from/to multiple sources/destinations. Current documents of the ROLL WG explain that the workload or traffic pattern of use cases for LoWPANs tends to be highly structured, unlike the any-to-any data transfers that dominate typical client and server workloads. In many cases, exploiting such structure may simplify difficult problems arising from resource constraints or variation in connectivity.
6LoWPANには、多くの場合、ポイントツーマルチポイントまたはマルチポイントツーポイントのトラフィックパターンがあります。多くの新しいアプリケーションには、ポイントツーポイント通信も含まれています。 6LoWPANルーティングプロトコルは、複数のソース/宛先との間のパケット転送を考慮して設計する必要があります。 ROLL WGの現在のドキュメントでは、LoWPANの使用例のワークロードまたはトラフィックパターンは、一般的なクライアントおよびサーバーのワークロードを支配する多対多のデータ転送とは異なり、高度に構造化される傾向があると説明しています。多くの場合、このような構造を利用すると、リソースの制約や接続のばらつきから生じる困難な問題を単純化できます。
The routing requirement described in this subsection allows secure transmission of routing messages. As in traditional networks, routing mechanisms in 6LoWPANs present another window from which an attacker might disrupt and significantly degrade the overall performance of the 6LoWPAN. Attacks against non-secure routing aim mainly to contaminate WPANs with false routing information, resulting in routing inconsistencies. A malicious node can also snoop packets and then launch replay attacks on the 6LoWPAN nodes. These attacks can cause harm, especially when the attacker is a high-power device, such as a laptop. It can also easily drain the batteries of 6LoWPAN devices by sending broadcast messages, redirecting routes, etc.
このサブセクションで説明するルーティング要件により、ルーティングメッセージを安全に送信できます。従来のネットワークと同様に、6LoWPANのルーティングメカニズムは、攻撃者が6LoWPANの全体的なパフォーマンスを混乱させ、大幅に低下させる可能性がある別のウィンドウを提示します。非セキュアルーティングに対する攻撃は、主にWPANを誤ったルーティング情報で汚染し、ルーティングの不整合を引き起こすことを目的としています。悪意のあるノードは、パケットをスヌープし、6LoWPANノードでリプレイ攻撃を開始することもできます。これらの攻撃は、特に攻撃者がラップトップなどの高出力デバイスである場合、害を及ぼす可能性があります。また、ブロードキャストメッセージを送信したり、ルートをリダイレクトしたりすることで、6LoWPANデバイスのバッテリーを簡単に消耗させることもできます。
[R14] 6LoWPAN routing protocols MUST support confidentiality, authentication, and integrity services as required for secure delivery of control messages.
[R14] 6LoWPANルーティングプロトコルは、制御メッセージの安全な配信に必要な、機密性、認証、および完全性サービスをサポートする必要があります。
A general set of requirements that may apply to these services can be found in [KARP-THREATS].
これらのサービスに適用される可能性のある一般的な要件のセットは、[KARP-THREATS]にあります。
Security is very important for designing robust routing protocols, but it should not cause significant transmission overhead. The security aspect, however, seems to be a bit of a tradeoff in a 6LoWPAN, since security is always a costly function. A 6LoWPAN poses unique challenges to which traditional security techniques cannot be applied directly. For example, public key cryptography primitives are typically avoided (as being too expensive), as are relatively heavyweight conventional encryption methods.
セキュリティは、堅牢なルーティングプロトコルを設計する上で非常に重要ですが、重大な伝送オーバーヘッドを引き起こすことはありません。ただし、セキュリティは常にコストのかかる機能であるため、セキュリティの側面は6LoWPANのトレードオフのようです。 6LoWPANは、従来のセキュリティ技術を直接適用することができない独特の課題を提起します。たとえば、公開キー暗号化プリミティブは、通常は比較的高価な従来の暗号化方法と同様に、（高すぎるため）回避されます。
Consequently, it becomes questionable whether the 6LoWPAN devices can support IPsec as it is. While [RFC6434] makes support of the IPsec architecture a SHOULD for all IPv6 nodes, considering the power constraints and limited processing capabilities of IEEE 802.15.4-capable devices, IPsec is computationally expensive. Internet Key Exchange (IKEv2) messaging as described in RFC 5996 [RFC5996] will not work well in 6LoWPANs, as we want to minimize the amount of signaling in these networks. IPsec supports the Authentication Header (AH) for authenticating the IP header and the Encapsulating Security Payload (ESP) for authenticating and encrypting the payload. The main issues of using IPsec are two-fold: (1) processing power and (2) key management. Since these tiny 6LoWPAN devices do not process huge amounts of data or communicate with many different nodes, whether complete implementation of a Security Association Database (SAD), policy database, and dynamic key-management protocol are appropriate for these small battery-powered devices or not is not well understood.
その結果、6LoWPANデバイスがIPsecをそのままサポートできるかどうかが疑問になります。 [RFC6434]は、IPsecアーキテクチャのサポートをすべてのIPv6ノードのSHOULDにしますが、IEEE 802.15.4対応デバイスの電力制限と制限された処理機能を考慮すると、IPsecは計算コストが高くなります。 RFC 5996 [RFC5996]で説明されているインターネットキーエクスチェンジ（IKEv2）メッセージングは、これらのネットワークでのシグナリングの量を最小限に抑えたいため、6LoWPANではうまく機能しません。 IPsecは、IPヘッダーを認証するための認証ヘッダー（AH）と、ペイロードを認証および暗号化するためのカプセル化セキュリティペイロード（ESP）をサポートしています。 IPsecを使用する場合の主な問題は、（1）処理能力と（2）キー管理の2つです。これらの小さな6LoWPANデバイスは大量のデータを処理したり、多くの異なるノードと通信したりしないため、セキュリティアソシエーションデータベース（SAD）、ポリシーデータベース、および動的キー管理プロトコルの完全な実装がこれらの小型バッテリー駆動デバイスまたはよく理解されていません。
Bandwidth is a very scarce resource in 6LoWPAN environments. The fact that IPsec additionally requires another header (AH or ESP) in every packet makes its use problematic in 6LoWPAN environments. IPsec requires two communicating peers to share a secret key that is typically established dynamically with IKEv2. Thus, it has an additional packet overhead incurred by the exchange of IKEv2 packets.
帯域幅は、6LoWPAN環境では非常に少ないリソースです。 IPsecがすべてのパケットに別のヘッダー（AHまたはESP）を追加で必要とするという事実により、6LoWPAN環境ではその使用が問題になります。 IPsecでは、通常、IKEv2で動的に確立される秘密鍵を共有するために、2つの通信するピアが必要です。したがって、IKEv2パケットの交換によって発生する追加のパケットオーバーヘッドがあります。
Given existing constraints in 6LoWPAN environments, IPsec may not be suitable for use in such environments, especially since a 6LoWPAN node may not be capable of operating all IPsec algorithms on its own. Thus, a 6LoWPAN may need to define its own keying management method(s) that require minimum overhead in packet size and in the number of signaling messages that are exchanged. IPsec will provide authentication and confidentiality between end-nodes and across multiple LoWPAN links, and may be useful only when two nodes want to apply security to all exchanged messages. However, in most cases, the security may be requested at the application layer as needed, while other messages can flow in the network without security overhead.
6LoWPAN環境に既存の制約がある場合、特に6LoWPANノードがすべてのIPsecアルゴリズムを単独で動作させることができない場合があるため、IPsecはそのような環境での使用に適さない場合があります。したがって、6LoWPANは、パケットサイズと交換されるシグナリングメッセージの数で最小限のオーバーヘッドを必要とする独自のキーイング管理方法を定義する必要がある場合があります。 IPsecは、エンドノード間および複数のLoWPANリンク間で認証と機密性を提供し、2つのノードがすべての交換されたメッセージにセキュリティを適用したい場合にのみ役立つ場合があります。ただし、ほとんどの場合、必要に応じてアプリケーション層でセキュリティを要求できますが、他のメッセージはセキュリティオーバーヘッドなしでネットワークを流れることができます。
Security threats within LoWPANs may be different from existing threat models in ad hoc network environments. If IEEE 802.15.4 security is not used, Neighbor Discovery (ND) in IEEE 802.15.4 links is susceptible to threats. These include Neighbor Solicitation/Neighbor Advertisement (NS/NA) spoofing, a malicious router, a default router that is "killed", a good router that goes bad, a spoofed redirect, replay attacks, and remote ND DoS [RFC3756]. However, if IEEE 802.15.4 security is used, no other protection is needed for ND, as long as none of the nodes become compromised, because the Corporate Intranet Model of RFC 3756 can be assumed [6LoWPAN-ND].
LoWPAN内のセキュリティの脅威は、アドホックネットワーク環境の既存の脅威モデルとは異なる場合があります。 IEEE 802.15.4セキュリティが使用されていない場合、IEEE 802.15.4リンクの近隣探索（ND）は脅威の影響を受けやすくなります。これには、近隣要請/近隣アドバタイズ（NS / NA）スプーフィング、悪意のあるルーター、「強制終了」されたデフォルトルーター、不正になった良好なルーター、偽装されたリダイレクト、リプレイ攻撃、リモートND DoS [RFC3756]が含まれます。ただし、IEEE 802.15.4セキュリティを使用する場合、RFC 3756の企業イントラネットモデル[6LoWPAN-ND]を想定できるため、どのノードも危険にさらされない限り、NDに他の保護は必要ありません。
Bootstrapping may also impose additional threats. For example, a malicious node can obtain initial configuration information in order to appear as a legitimate node and then carry out various types of attacks. Such a node can also keep legitimate nodes busy by broadcasting authentication/join requests. One option for mitigating such threats is the use of mutual authentication schemes based on the use of pre-shared keys [Ikram].
ブートストラップは、追加の脅威を課すこともあります。たとえば、悪意のあるノードは、正当なノードとして表示されるために初期構成情報を取得し、さまざまな種類の攻撃を実行できます。このようなノードは、認証/参加要求をブロードキャストすることにより、正当なノードをビジー状態に保つこともできます。このような脅威を軽減する1つのオプションは、事前共有キーの使用に基づく相互認証スキームの使用です[Ikram]。
The IEEE 802.15.4 MAC provides an AES-based security mechanism. Routing protocols may define how this mechanism (in conjunction with IPsec whenever available) can be used to obtain the intended security, either for the routing protocol alone or in conjunction with the security used for the data. Byte overhead of the mechanism, which depends on the security services selected, must be considered. In the worst case in terms of overhead, the mechanism consumes 21 bytes of MAC payload.
IEEE 802.15.4 MACは、AESベースのセキュリティメカニズムを提供します。ルーティングプロトコルは、このメカニズムを（可能な場合は常にIPsecと組み合わせて）使用して、ルーティングプロトコルのみの場合、またはデータに使用されているセキュリティと組み合わせて、目的のセキュリティを取得する方法を定義できます。選択したセキュリティサービスに依存するメカニズムのバイトオーバーヘッドを考慮する必要があります。オーバーヘッドの点で最悪の場合、メカニズムは21バイトのMACペイロードを消費します。
The IEEE 802.15.4 MAC security is typically supported by crypto hardware, even in very simple chips that will be used in a 6LoWPAN. Even if the IEEE 802.15.4 MAC security mechanisms are not used, this crypto hardware is usually available for use by application code running on these chips. A security protocol outside IEEE 802.15.4 MAC security SHOULD therefore provide a mode of operation that is covered by this crypto hardware.
6LoWPANで使用される非常に単純なチップであっても、IEEE 802.15.4 MACセキュリティは通常、暗号化ハードウェアによってサポートされます。 IEEE 802.15.4 MACセキュリティメカニズムが使用されていない場合でも、この暗号化ハードウェアは通常、これらのチップで実行されているアプリケーションコードで使用できます。したがって、IEEE 802.15.4 MACセキュリティ外のセキュリティプロトコルは、この暗号化ハードウェアでカバーされる動作モードを提供する必要があります（SHOULD）。
IEEE 802.15.4 does not specify protection for acknowledgment frames. Since the sequence numbers of data frames are sent in the clear, an adversary can forge an acknowledgment for each data frame. Exploitation of this weakness can be combined with targeted jamming to prevent delivery of selected packets. Consequently, IEEE 802.15.4 acknowledgments cannot be relied upon. In applications that require high security, the routing protocol must not exploit feedback from acknowledgments (e.g., to keep track of neighbor connectivity, see [R16]).
IEEE 802.15.4は、確認応答フレームの保護を指定していません。データフレームのシーケンス番号は平文で送信されるため、攻撃者は各データフレームの確認応答を偽造できます。この弱点の悪用は、選択されたパケットの配信を防ぐために、標的を絞った妨害と組み合わせることができます。したがって、IEEE 802.15.4確認応答は信頼できません。高度なセキュリティを必要とするアプリケーションでは、ルーティングプロトコルは確認応答からのフィードバックを利用してはなりません（たとえば、ネイバー接続を追跡するために、[R16]を参照してください）。
One LoWPAN may be built as one IPv6 link. In this case, mesh-under forwarding mechanisms must be supported. While this document provides general, layer-agnostic guidelines about the design of 6LoWPAN routing, the requirements in this section are specifically related to Layer 2. These requirements are directed to bodies that might consider working on mesh-under routing, such as the IEEE. The requirements described in this subsection allow optimization and correct operation of routing solutions, taking into account the specific features of the mesh-under configuration.
1つのLoWPANを1つのIPv6リンクとして構築できます。この場合、メッシュアンダー転送メカニズムがサポートされている必要があります。このドキュメントでは、6LoWPANルーティングの設計に関するレイヤーにとらわれない一般的なガイドラインを提供していますが、このセクションの要件は特にレイヤー2に関連しています。これらの要件は、IEEEなどのメッシュアンダールーティングでの作業を検討する可能性のある団体を対象としています。このサブセクションで説明する要件により、メッシュアンダー構成の特定の機能を考慮して、ルーティングソリューションの最適化と正しい操作が可能になります。
[R15] Mesh-under requires the development of a routing protocol operating below IP. This protocol MUST support 16-bit short and 64-bit extended MAC addresses.
[R15] Mesh-underでは、IPの下で動作するルーティングプロトコルの開発が必要です。このプロトコルは、16ビットの短いMACアドレスと64ビットの拡張MACアドレスをサポートする必要があります。
[R16] In order to perform discovery and maintenance of neighbors (i.e., neighborhood discovery as opposed to ND-style neighbor discovery), LoWPAN nodes SHOULD avoid sending separate "Hello" messages. Instead, link-layer mechanisms (such as acknowledgments) MAY be utilized to keep track of active neighbors.
[R16]ネイバーのディスカバリーとメンテナンス（NDスタイルのネイバーディスカバリではなく、ネイバーフッドディスカバリー）を実行するために、LoWPANノードは個別の「ハロー」メッセージの送信を回避する必要があります（SHOULD）。代わりに、リンク層メカニズム（確認など）を使用して、アクティブなネイバーを追跡できます。
Reception of an acknowledgment after a frame transmission may render unnecessary the transmission of explicit Hello messages, for example. In a more general view, any frame received by a node may be used as an input to evaluate the connectivity between the sender and receiver of that frame.
フレーム送信後に確認応答を受信すると、たとえば明示的なHelloメッセージの送信が不要になる場合があります。より一般的な見方では、ノードによって受信された任意のフレームは、そのフレームの送信側と受信側の間の接続を評価するための入力として使用されます。
[R17] If the routing protocol functionality includes enabling IP multicast, then it MAY employ structure in the network for efficient distribution in order to minimize link-layer broadcast.
[R17]ルーティングプロトコル機能にIPマルチキャストの有効化が含まれている場合、リンク層のブロードキャストを最小限に抑えるために、ネットワークに構造を採用して効率的な配信を行うことができます。
When a new protocol is designed, the operational environment and manageability of the protocol should be considered from the start [RFC5706]. This subsection provides a requirement for the manageability of 6LoWPAN routing protocols.
新しいプロトコルを設計するときは、プロトコルの運用環境と管理性を最初から検討する必要があります[RFC5706]。このサブセクションでは、6LoWPANルーティングプロトコルの管理性の要件について説明します。
[R18] A 6LoWPAN routing protocol SHOULD be designed according to the guidelines for operations and management stated in [RFC5706].
[R18] 6LoWPANルーティングプロトコルは、[RFC5706]に記載されている運用と管理のガイドラインに従って設計する必要があります（SHOULD）。
The management operations that a 6LoWPAN routing protocol implementation can support depend on the memory and processing capabilities of the 6LoWPAN devices used, which are typically constrained. However, 6LoWPANs may benefit significantly from supporting such 6LoWPAN routing protocol management operations as configuration and performance monitoring.
6LoWPANルーティングプロトコルの実装でサポートできる管理操作は、使用される6LoWPANデバイスのメモリと処理機能によって異なります。これらの機能は通常、制限されています。ただし、6LoWPANは、構成やパフォーマンスの監視などの6LoWPANルーティングプロトコル管理操作をサポートすることで、大きなメリットを得ることができます。
The design of 6LoWPAN routing protocols should take into account that, according to "Architectural Principles of the Internet" [RFC1958], "options and parameters should be configured or negotiated dynamically rather than manually". This is especially important for 6LoWPANs, which can be composed of a large number of devices (and, in addition, these devices may not have an appropriate user interface). Therefore, parameter autoconfiguration is a desirable property for a 6LoWPAN routing protocol, although some subset of routing protocol parameters may allow other forms of configuration as well.
6LoWPANルーティングプロトコルの設計では、「インターネットのアーキテクチャ原則」[RFC1958]に従って、「オプションとパラメータは手動ではなく動的に構成またはネゴシエートする必要がある」ことを考慮に入れる必要があります。これは、多数のデバイスで構成できる6LoWPANで特に重要です（さらに、これらのデバイスには適切なユーザーインターフェイスがない場合があります）。したがって、パラメーターの自動構成は6LoWPANルーティングプロトコルにとって望ましいプロパティですが、ルーティングプロトコルパラメーターの一部のサブセットでは、他の形式の構成も可能になる場合があります。
In order to verify the correct operation of the 6LoWPAN routing protocol and the network itself, a 6LoWPAN routing protocol should allow monitoring of the status and/or value of 6LoWPAN routing protocol parameters and data structures such as routing table entries. In order to enable fault management, further monitoring of the 6LoWPAN routing protocol operation is needed. For this, faults can be reported via error log messages. These messages may contain information such as the number of times a packet could not be sent to a valid next hop, the duration of each period without connectivity, memory overflow and its causes, etc.
6LoWPANルーティングプロトコルとネットワーク自体の正しい動作を確認するために、6LoWPANルーティングプロトコルは、6LoWPANルーティングプロトコルのパラメータとデータ構造（ルーティングテーブルエントリなど）のステータスや値を監視できる必要があります。障害管理を有効にするには、6LoWPANルーティングプロトコルの動作をさらに監視する必要があります。このため、エラーログメッセージを介して障害を報告できます。これらのメッセージには、有効なネクストホップにパケットを送信できなかった回数、接続のない各期間の持続時間、メモリオーバーフローとその原因などの情報が含まれる場合があります。
[RFC5706] -- in particular its Section 3 -- provides a comprehensive guide to properly designing the management solution for a 6LoWPAN routing protocol.
[RFC5706]-特にそのセクション3-は、6LoWPANルーティングプロトコルの管理ソリューションを適切に設計するための包括的なガイドを提供します。
Security issues are described in Section 5.4. The security considerations in RFC 4919 [RFC4919], RFC 4944 [RFC4944], and RFC 4593 [RFC4593] apply as well.
セキュリティの問題については、セクション5.4で説明します。 RFC 4919 [RFC4919]、RFC 4944 [RFC4944]、およびRFC 4593 [RFC4593]のセキュリティに関する考慮事項も適用されます。
The use of wireless links renders a 6LoWPAN susceptible to attacks like any other wireless network. In outdoor 6LoWPANs, the physical exposure of the nodes allows an adversary to capture, clone, or tamper with these devices. In ad hoc 6LoWPANs that are dynamic in both their topology and node memberships, a static security configuration does not suffice. Spoofed, altered, or replayed routing information might occur, while multihopping could delay the detection and treatment of attacks.
ワイヤレスリンクを使用すると、6LoWPANが他のワイヤレスネットワークと同様に攻撃を受けやすくなります。屋外の6LoWPANでは、ノードが物理的に露出しているため、攻撃者はこれらのデバイスをキャプチャ、複製、または改ざんできます。トポロジとノードメンバーシップの両方が動的なアドホック6LoWPANでは、静的なセキュリティ構成では不十分です。ルーティング情報がスプーフィング、変更、または再生される可能性がありますが、マルチホッピングは攻撃の検出と処理を遅らせる可能性があります。
This specification expects that the link layer is sufficiently protected, either by means of physical or IP security for the backbone link, or with MAC-sublayer cryptography. However, link-layer encryption and authentication may not be sufficient to provide confidentiality, authentication, integrity, and freshness to both data and routing protocol packets. Time synchronization, self-organization, and secure localization for multi-hop routing are also critical to support.
この仕様は、バックボーンリンクの物理的またはIPセキュリティによって、またはMACサブレイヤー暗号化によって、リンクレイヤーが十分に保護されることを期待しています。ただし、リンク層の暗号化と認証は、データとルーティングプロトコルパケットの両方に機密性、認証、整合性、および鮮度を提供するには十分でない場合があります。マルチホップルーティングの時刻同期、自己組織化、および安全なローカリゼーションもサポートに不可欠です。
For secure routing protocol operation, it may be necessary to consider authenticated broadcast (and multicast) and bidirectional link verification. On the other hand, secure end-to-end data delivery can be assisted by the routing protocol. For example, multi-path routing could be considered for increasing security to prevent selective forwarding. However, the challenge is that 6LoWPANs already have high resource constraints, so that 6LBR and LoWPAN nodes may require different security solutions.
安全なルーティングプロトコル操作のために、認証されたブロードキャスト（およびマルチキャスト）と双方向リンクの検証を考慮する必要がある場合があります。一方、ルーティングプロトコルによって、エンドツーエンドの安全なデータ配信を支援できます。たとえば、マルチパスルーティングは、選択的な転送を防ぐためにセキュリティを強化するために検討できます。ただし、6LoWPANにはすでに高いリソース制約があるため、6LBRノードとLoWPANノードには異なるセキュリティソリューションが必要になる場合があります。
The authors of this document highly appreciate the authors of "IPv6 over Low Power WPAN Security Analysis" [6LoWPAN-SEC]. Although their security analysis work is not ongoing at the time of this writing, the valuable information and text in that document are used in Section 5.4 of this document, per advice received during IESG review procedures. Thanks to their work, Section 5.4 is much improved. The authors also thank S. Chakrabarti, who gave valuable comments regarding mesh-under requirements, and A. Petrescu for significant review.
このドキュメントの作成者は、「IPv6 over Low Power WPAN Security Analysis」[6LoWPAN-SEC]の作成者を高く評価しています。この記事の執筆時点ではセキュリティ分析作業は行われていませんが、そのドキュメントの重要な情報とテキストは、このドキュメントのセクション5.4で、IESGレビュー手順中に受け取ったアドバイスに従って使用されています。彼らの仕事のおかげで、セクション5.4は大幅に改善されました。また、メッシュアンダー要件に関して貴重なコメントを提供してくれたS. Chakrabartiと、重要なレビューをしてくれたA. Petrescuにも感謝します。
Carles Gomez has been supported in part by FEDER and by the Spanish Government through projects TIC2006-04504 and TEC2009-11453.
Carles Gomezは、プロジェクトTIC2006-04504およびTEC2009-11453を通じて、FEDERおよびスペイン政府によって部分的にサポートされています。
[IEEE802.15.4] IEEE Computer Society, "IEEE Standard for Local and Metropolitan Area Networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE Std. 802.15.4-2011, September 2011.
[IEEE802.15.4] IEEE Computer Society、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）」、IEEE Std。 802.15.4-2011、2011年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P。、編、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]カーン、P。、編、ボーマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、2004年7月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919] Kushalnagar、N.、Montenegro、G。、およびC. Schumacher、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、RFC 4919、2007年8月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、2007年9月。
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548] Dohler、M。、編、Watteyne、T。、編、Winter、T。、編、およびD. Barthel、編、「都市の低電力および損失の多いネットワークのルーティング要件」、RFC 5548 、2009年5月。
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673] Pister、K.、Ed。、Thubert、P.、Ed。、Dwars、S.、T。Phinney、「Industrial Routing Requirements in Low-Power and Lossy Networks」、RFC 5673、2009年10月。
[6LoWPAN-ND] Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, October 2011.
[6LoWPAN-ND] Shelby、Z.、Ed。、Chakrabarti、S。、およびE. Nordmark、「Neighbor Discovery Optimization for Low Power and Lossy Networks（6LoWPAN）」、Work in Progress、2011年10月。
[6LoWPAN-SEC] Park, S., Kim, K., Haddad, W., Ed., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Work in Progress, March 2011.
[6LoWPAN-SEC] Park、S.、Kim、K.、Haddad、W.、Ed。、Chakrabarti、S。、およびJ. Laganier、「IPv6 over Low Power WPAN Security Analysis」、Work in Progress、2011年3月。
[Bulusu] Bulusu, N., Ed., and S. Jha, Ed., "Wireless Sensor Networks: A Systems Perspective", Artech House, ISBN 9781580538671, July 2005.
[ブルス]ブルス、n。、編、およびs。 Zha、Ed。、「Wireless Sense Networks：A Systems Perspective」、Artch House、Lisbon 2010、2009年7月。
[Chen] Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc Multicast Routing on Resource-Limited Sensor Nodes", Proc. 2nd International Workshop on Multi-hop Ad Hoc Networks, May 2006.
[陳]陳、B.、Muniswamy-Reddy、K。、およびM. Welsh、「リソースが限られたセンサーノードでのアドホックマルチキャストルーティング」、Proc。 2006年5月、マルチホップアドホックネットワークに関する第2回国際ワークショップ。
[Doherty] Doherty, L., Warneke, B., Boser, B., and K. Pister, "Energy and Performance Considerations for Smart Dust", International Journal of Parallel and Distributed Systems and Networks, Vol. 4, No. 3, 2001.
[Doherty] Doherty、L.、Warneke、B.、Boser、B.、およびK. Pister、「Smart Dustのエネルギーとパフォーマンスに関する考慮事項」、International Journal of Parallel and Distributed Systems and Networks、Vol。 4、No。3、2001。
[Hill] Hill, J., "System Architecture for Wireless Sensor Networks", Ph.D. Thesis, UC Berkeley, 2003.
[ヒル]ヒル、J。、「ワイヤレスセンサーネットワークのシステムアーキテクチャ」、Ph.D。論文、カリフォルニア大学バークレー校、2003年。
[Ikram] Ikram, M., Chowdhury, A., Zafar, B., Cha, H., Kim, K., Yoo, S., and D. Kim, "A Simple Lightweight Authentic Bootstrapping Protocol for IPv6-based Low Rate Wireless Personal Area Networks (6LoWPANs)", Proc. International Conference on Wireless Communications and Mobile Computing, June 2009.
[Ikram] Ikram、M.、Chowdhury、A.、Zafar、B.、Cha、H.、Kim、K.、Yoo、S。、およびD. Kim、「IPv6ベースの単純な軽量オーセンティックブートストラッププロトコルワイヤレスパーソナルエリアネットワーク（6LoWPAN）の評価」、Proc。ワイヤレス通信とモバイルコンピューティングに関する国際会議、2009年6月。
[KARP-THREATS] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", Work in Progress, May 2012.
[KARP-THREATS] Lebovitz、G.およびM. Bhatia、「ルーティングプロトコルのキーイングと認証（KARP）の概要、脅威、および要件」、作業中、2012年5月。
[Kuhn] Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case Optimal and Average-Case Efficient Ad-Hoc Geometric Routing", MobiHoc '03: Proceedings of the 4th ACM International Symposium on Mobile Ad Hoc Networking and Computing, June 2003.
[クーン]クーン、F。、ワッテンホーファー、R。、およびA.ゾリンジャー、「ワーストケースの最適および平均ケースの効率的なアドホックジオメトリックルーティング」、MobiHoc '03：モバイルアドホックに関する第4回ACM国際シンポジウムの議事録ネットワーキングとコンピューティング、2003年6月。
[Latre] Latre, B., De Mil, P., Moerman, I., Dhoedt, B., and P. Demeester, "Throughput and Delay Analysis of Unslotted IEEE 802.15.4", Journal of Networks, Vol. 1, No. 1, May 2006.
[Latre] Latre、B.、De Mil、P.、Moerman、I.、Dhoedt、B。、およびP. Demeester、「Throughput and Delay Analysis of Unslotted IEEE 802.15.4」、Journal of Networks、Vol。 1、No。1、2006年5月。
[Lee] Lee, S., Belding-Royer, E., and C. Perkins, "Scalability Study of the Ad Hoc On-Demand Distance-Vector Routing Protocol", International Journal of Network Management, Vol. 13, pp. 97-114, March 2003.
[リー] Lee、S.、Belding-Royer、E。、およびC. Perkins、「アドホックオンデマンド距離ベクトルルーティングプロトコルのスケーラビリティ調査」、International Journal of Network Management、Vol。 13、97-114ページ、2003年3月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、1996年6月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]タッチ、J。およびR.パールマン、「多数のリンクの透過的な相互接続（TRILL）：問題と適用性に関する声明」、RFC 5556、2009年5月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントンD.、「新しいプロトコルとプロトコル拡張の操作と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」、RFC 5826、2010年4月。
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867] Martocci、J.、Ed。、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、2010年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[RFC6282] Hui、J.、Ed。、およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、2011年9月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[ROLL-PROTOCOLS] Levis, P., Tavakoli, A., and S. Dawson-Haggerty, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Work in Progress, April 2009.
[ロールプロトコル] Levis、P.、Tavakoli、A。、およびS. Dawson-Haggerty、「Overview of Existing Routing Protocols for Low Power and Lossy Networks」、Work in Progress、2009年4月。
[Shih] Shih, E., Cho, S., Ickes, N., Min, R., Sinha, A., Wang, A., and A. Chandrakasan, "Physical Layer Driven Protocols and Algorithm Design for Energy-Efficient Wireless Sensor Networks", MobiCom '01: Proceedings of the 7th ACM Annual International Conference on Mobile Computing and Networking, July 2001.
[Shih] Shih、E.、Cho、S.、Ickes、N.、Min、R.、Sinha、A.、Wang、A。、およびA. Chandrakasan、「エネルギー効率に優れた物理層駆動プロトコルとアルゴリズム設計ワイヤレスセンサーネットワーク」、MobiCom '01：Proceedings of the 7th ACM Annual International Conference on Mobile Computing and Networking、2001年7月。
[Watteyne] Watteyne, T., Molinaro, A., Richichi, M., and M. Dohler, "From MANET To IETF ROLL Standardization: A Paradigm Shift in WSN Routing Protocols", IEEE Communications Surveys and Tutorials, Vol. 13, Issue 4, pp. 688-707, 2011, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=5581105>.
[Watteyne] Watteyne、T.、Molinaro、A.、Richichi、M。、およびM. Dohler、「MANETからIETF ROLL標準化：WSNルーティングプロトコルのパラダイムシフト」、IEEE Communications Surveys and Tutorials、Vol。 13、Issue 4、pp。688-707、2011、<http://ieeexplore.ieee.org/xpl/ articleDetails.jsp？arnumber = 5581105>。
Authors' Addresses
著者のアドレス
Eunsook Eunah Kim ETRI 161 Gajeong-dong Yuseong-gu Daejeon 305-700 Korea
Eunsook Eunah Kim ETRI 161 Gajeong-dong Yuseong-gu Daejeon 305-700 Korea
Phone: +82-42-860-6124
EMail: eunah.ietf@gmail.com
Dominik Kaspar Simula Research Laboratory Martin Linges v 17 Fornebu 1364 Norway
ドミニクカスパーシミュラ研究所マーティンリンゲスv 17フォルネブ1364ノルウェー
Phone: +47-6782-8223
EMail: dokaspar.ietf@gmail.com
Carles Gomez Universitat Politecnica de Catalunya/Fundacio i2CAT Escola d'Enginyeria de Telecomunicacio i Aeroespacial de Castelldefels C/Esteve Terradas, 7 Castelldefels 08860 Spain
Carles Gomez Universitat Politecnica de Catalunya / i2CAT Foundation Castelldefels School of Telecommunications and Aerospace Engineering C / Esteve Terradas、7 Castelldefels 08860 Spain
Phone: +34-93-413-7206
EMail: carlesgo@entel.upc.edu
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
EMail: cabo@tzi.org