Network Working Group                                     K. Pister, Ed.
Request for Comments: 5673                                 Dust Networks
Category: Informational                                  P. Thubert, Ed.
                                                           Cisco Systems
                                                                S. Dwars
                                                                   Shell
                                                              T. Phinney
                                                              Consultant
                                                            October 2009
        
    Industrial Routing Requirements in Low-Power and Lossy Networks
        

Abstract

抽象

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices.

プラント運転に関する利用可能な設定情報を拡張することで、工場労働者の効率を高めながら低コストのワイヤレスデバイスの幅広い展開が大幅に工場の生産性と安全性を向上します。この文書の目的は、フィールドデバイスの工業用低電力およびロッシーネットワーク(LLNs)で使用されるルーティングプロトコルのための機能要件を分析することです。

Status of This Memo

このメモのステータス

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

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Applications and Traffic Patterns  . . . . . . . . . . . .  5
     3.2.  Network Topology of Industrial Applications  . . . . . . .  9
       3.2.1.  The Physical Topology  . . . . . . . . . . . . . . . . 10
       3.2.2.  Logical Topologies . . . . . . . . . . . . . . . . . . 12
   4.  Requirements Related to Traffic Characteristics  . . . . . . . 13
     4.1.  Service Requirements . . . . . . . . . . . . . . . . . . . 14
     4.2.  Configurable Application Requirement . . . . . . . . . . . 15
     4.3.  Different Routes for Different Flows . . . . . . . . . . . 15
   5.  Reliability Requirements . . . . . . . . . . . . . . . . . . . 16
   6.  Device-Aware Routing Requirements  . . . . . . . . . . . . . . 18
   7.  Broadcast/Multicast Requirements . . . . . . . . . . . . . . . 19
   8.  Protocol Performance Requirements  . . . . . . . . . . . . . . 20
   9.  Mobility Requirements  . . . . . . . . . . . . . . . . . . . . 21
   10. Manageability Requirements . . . . . . . . . . . . . . . . . . 21
   11. Antagonistic Requirements  . . . . . . . . . . . . . . . . . . 22
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     14.2. Informative References . . . . . . . . . . . . . . . . . . 25
        
1. Introduction
1. はじめに

Information Technology (IT) is already, and increasingly will be applied to industrial Control Technology (CT) in application areas where those IT technologies can be constrained sufficiently by Service Level Agreements (SLA) or other modest changes that they are able to meet the operational needs of industrial CT. When that happens, the CT benefits from the large intellectual, experiential, and training investment that has already occurred in those IT precursors. One can conclude that future reuse of additional IT protocols for industrial CT will continue to occur due to the significant intellectual, experiential, and training economies that result from that reuse.

情報技術(IT)すでに、ますますこれらのIT技術は、サービス・レベル・アグリーメント(SLA)、または、それらが動作を満たすことができます他のささやかな変化によって十分に制約することができるアプリケーション分野での産業制御技術(CT)に適用されます産業用CTのニーズ。これが発生すると、持っている大規模な知的、体験、およびトレーニングへの投資からCTの利点は、すでにこれらのIT前駆体で発生しました。一つは産業用CTのための追加的なITプロトコルの将来の再利用は、その再利用に起因する重大な知的、体験、およびトレーニングの経済のために発生し続けるだろうと結論付けることができます。

Following that logic, many vendors are already extending or replacing their local fieldbus [IEC61158] technology with Ethernet and IP-based solutions. Examples of this evolution include Common Industrial Protocol (CIP) EtherNet/IP, Modbus/TCP, Fieldbus Foundation High Speed Ethernet (HSE), PROFInet, and Invensys/Foxboro FOXnet. At the same time, wireless, low-power field devices are being introduced that facilitate a significant increase in the amount of information that industrial users can collect and the number of control points that can be remotely managed.

そのロジックに続いて、多くのベンダーがすでにイーサネットおよびIPベースのソリューションで、地元のフィールドバス[IEC61158]技術を拡張または交換されています。この進化の例としては、一般的な工業用プロトコル(CIP)のEtherNet / IP、Modbusの/ TCP、フィールドバス協会高速イーサネット(HSE)、のPROFInet、およびインベンシス/フォックスボロFOXnetが含まれます。同時に、無線、低電力のフィールドデバイスは、産業ユーザが収集できる情報の量の有意な増加とリモートで管理することができる制御点の数を容易に導入されています。

IPv6 appears as a core technology at the conjunction of both trends, as illustrated by the current [ISA100.11a] industrial Wireless Sensor Networking specification, where technologies for layers 1-4 that were developed for purposes other than industrial CT -- [IEEE802.15.4] PHY and MAC, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4919], and UDP -- are adapted to industrial CT use. But due to the lack of open standards for routing in Low-power and Lossy Networks (LLNs), even ISA100.11a leaves the routing operation to proprietary methods.

層1-4のための技術は工業CT以外の目的のために開発された現在[ISA100.11aの】工業用ワイヤレスセンサネットワークの仕様によって示されるようにIPv6が、両方の傾向の組み合わせでコア技術として現れる - [IEEE802。 15.4] PHYとMAC、IPv6の低電力無線パーソナルエリアネットワーク経由(6LoWPANs)[RFC4919]、およびUDPは - 産業用CTの使用に適合されています。しかしによる低消費電力とロッシーネットワーク(LLNs)にルーティングするためのオープン標準の欠如にもISA100.11aのは、独自のメソッドにルーティング操作を去ります。

The aim of this document is to analyze the requirements from the industrial environment for a routing protocol in Low power and Lossy Networks (LLNs) based on IPv6 to power the next generation of Control Technology.

このドキュメントの目的は、制御技術の次世代電力を供給するためのIPv6に基づく低消費電力とロッシーネットワークにおけるルーティングプロトコル(LLNs)のための産業環境からの要求を分析することです。

1.1. Requirements Language
1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. Terminology
2.用語

This document employs terminology defined in the ROLL (Routing Over Low-power and Lossy networks) terminology document [ROLL-TERM]. This document also refers to industrial standards:

この文書は、ロール(ルーティングを低消費電力とロッシーネットワーク)用語ドキュメント[ROLL-TERM]で定義された用語を使用します。この文書はまた、工業規格を参照します。

HART: Highway Addressable Remote Transducer, a group of specifications for industrial process and control devices administered by the HART Communication Foundation (see [HART]). The latest version for the specifications is HART7, which includes the additions for WirelessHART [IEC62591].

HART:高速アドレスリモートトランスデューサ、HARTコミュニケーション財団が管理産業用プロセス制御およびデバイスの仕様のグループ([HART]を参照)。仕様の最新バージョンは、のWirelessHART [IEC62591]のための追加が含まれHART7、です。

ISA: International Society of Automation, an ANSI-accredited standards-making society. ISA100 is an ISA committee whose charter includes defining a family of standards for industrial automation. [ISA100.11a] is a working group within ISA100 that is working on a standard for monitoring and non-critical process control applications.

ISA:オートメーションの国際協会、ANSI認定基準作り社会。 ISA100は、その憲章産業オートメーションのための規格のファミリーを定義することを含むISA委員会です。 【ISA100.11aの】監視および非クリティカルプロセス制御アプリケーションのための標準に取り組んでISA100内のワーキンググループです。

3. Overview
3.概要

Wireless, low-power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers. IPv6 is perceived as a key technology to provide the scalability and interoperability that are required in that space, and it is more and more present in standards and products under development and early deployments.

無線は、低電力のフィールドデバイスが大幅収集された情報の量及びリモート管理することができる制御点の数を増加させるために産業ユーザーを可能にします。工場労働者の効率を高めながら、これらの無線デバイスの展開が大幅に植物の生産性と安全性を向上します。 IPv6がその空間に必要とされる拡張性と相互運用性を提供するためのキーテクノロジーとして認識され、それは、開発と早期展開の下での規格や製品に、より多く存在しています。

Cable is perceived as a more proven, safer technology, and existing, operational deployments are very stable in time. For these reasons, it is not expected that wireless will replace wire in any foreseeable future; the consensus in the industrial space is rather that wireless will tremendously augment the scope and benefits of automation by enabling the control of devices that were not connected in the past for reasons of cost and/or deployment complexities. But for LLNs to be adopted in the industrial environment, the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The routing protocol used for LLNs is important to fulfilling these goals.

ケーブルは、より多くの実績のある、より安全な技術として認識され、既存の、業務の展開は、時間的に非常に安定しています。これらの理由から、無線が任意の予見可能な将来にワイヤーを交換することが期待されていません。ワイヤレスが途方もなく、コストおよび/または展開の複雑さの理由のため、過去に接続されていなかったデバイスの制御を可能にすることにより、自動化の範囲とメリットを強化しますむしろ産業空間でのコンセンサスがあります。低消費電力、高信頼性、および容易なインストールとメンテナンス:しかし、産業環境で採用されるLLNsのために、無線ネットワークは、3つの資質を持っている必要があります。 LLNsのために使用されるルーティングプロトコルは、これらの目標を満たすために重要です。

Industrial automation is segmented into two distinct application spaces, known as "process" or "process control" and "discrete manufacturing" or "factory automation". In industrial process control, the product is typically a fluid (oil, gas, chemicals, etc.). In factory automation or discrete manufacturing, the products are individual elements (screws, cars, dolls). While there is some overlap of products and systems between these two segments, they are surprisingly separate communities. The specifications targeting industrial process control tend to have more tolerance for network latency than what is needed for factory automation.

産業オートメーションは、「処理」または「プロセスコントロール」および「離散製造」または「工場自動化」として知られている2つの別個のアプリケーション・スペースに分割されます。工業用プロセス制御では、製品は、典型的には、流体(等油、ガス、化学物質、)です。ファクトリオートメーションまたはディスクリート製造では、製品は、個々の要素(ねじ、自動車、人形)です。これら2つのセグメント間の製品及びシステムのいくつかの重複があるが、それらは驚くべき別のコミュニティです。工業用プロセス制御をターゲット仕様は、工場の自動化のために必要とされるものよりもネットワークの遅延のためのより多くの耐性を持っている傾向があります。

Irrespective of this different 'process' and 'discrete' plant nature, both plant types will have similar needs for automating the collection of data that used to be collected manually, or was not collected before. Examples are wireless sensors that report the state of a fuse, report the state of a luminary, HVAC status, report vibration levels on pumps, report man-down, and so on.

かかわらず、この異なる「プロセス」と「個別の」植物の性質のために、両方の植物の種類を手動で収集するために使用される、または以前に収集されていなかったデータの収集を自動化するための同様のニーズを持つことになります。例としては、これに、ヒューズの状態を報告する発光体、HVAC状態、ポンプのレポート振動レベル、レポートマンダウンの状態を報告し、無線センサです。

Other novel application arenas that equally apply to both 'process' and 'discrete' involve mobile sensors that roam in and out of plants, such as active sensor tags on containers or vehicles.

同等に「プロセス」と「離散」の両方に適用される他の新規アプリケーション・アリーナは、このような容器または媒体上のアクティブセンサタグなどの植物の中と外にローミングするモバイルセンサーを含みます。

Some if not all of these applications will need to be served by the same low-power and lossy wireless network technology. This may mean several disconnected, autonomous LLNs connecting to multiple hosts, but sharing the same ether. Interconnecting such networks, if only to supervise channel and priority allocations, or to fully synchronize, or to share path capacity within a set of physical network components may be desired, or may not be desired for practical reasons, such as e.g., cyber security concerns in relation to plant safety and integrity.

いくつかのすべてではないが、これらのアプリケーションのは、同じ低消費電力と損失の多い無線ネットワーク技術によって提供される必要があります。これは、いくつかの切断された、自律LLNs複数のホストに接続し、同じエーテルを共有することを意味してもよいです。チャネルおよび優先順位割り当てを監督する、または完全に同期させるために、または所望され得る物理的なネットワーク構成要素のセット内のパス能力を共有するために、又は、例えば、サイバーセキュリティ上の懸念として実用的な理由のために所望されないかもしれない場合にのみ、そのようなネットワークを相互接続プラントの安全性と完全性との関係インチ

All application spaces desire battery-operated networks of hundreds of sensors and actuators communicating with LLN access points. In an oil refinery, the total number of devices might exceed one million, but the devices will be clustered into smaller networks that in most cases interconnect and report to an existing plant network infrastructure.

すべてのアプリケーションスペースはLLNアクセスポイントと通信するセンサとアクチュエータの数百のバッテリ駆動ネットワークを望みます。石油精製所では、デバイスの総数は百万を超える場合がありますが、デバイスは、ほとんどの場合、相互接続で、既存工場のネットワークインフラストラクチャに報告小さなネットワークにクラスタ化されます。

Existing wired sensor networks in this space typically use communication protocols with low data rates, from 1200 baud (e.g., wired HART) to the 100-200 kbps range for most of the others. The existing protocols are often master/slave with command/response.

この空間内の既存の有線センサネットワークは、典型的には、他のほとんどの範囲は100〜200 kbpsに1200ボー(例えば、有線HART)から、低いデータレートで通信プロトコルを使用します。既存のプロトコルは、多くの場合、コマンド/レスポンスとのマスタ/スレーブです。

3.1. Applications and Traffic Patterns
3.1. アプリケーショントラフィックパターン

The industrial market classifies process applications into three broad categories and six classes.

産業市場は大きく3つのカテゴリーと6つのクラスにプロセス・アプリケーションを分類します。

o Safety

お さふぇty

* Class 0: Emergency action - Always a critical function

*クラス0:緊急アクション - 常に重要な機能

o Control

コントロール

* Class 1: Closed-loop regulatory control - Often a critical function

*クラス1:クローズドループ制御調節 - 多くの重要な機能

* Class 2: Closed-loop supervisory control - Usually a non-critical function

*クラス2:クローズド・ループ監視制御 - 通常非クリティカル機能

* Class 3: Open-loop control - Operator takes action and controls the actuator (human in the loop)

*クラス3:オープンループ制御 - オペレータが行動を取り、アクチュエータ(ループにおけるヒト)を制御します

o Monitoring

Oの監視

* Class 4: Alerting - Short-term operational effect (for example, event-based maintenance)

*クラス4:アラート - 短期作用効果(例えば、イベントベースのメンテナンス)

* Class 5: Logging and downloading / uploading - No immediate operational consequence (e.g., history collection, sequence-of-events, preventive maintenance)

*クラス5:ロギングとダウンロード/アップロード - 即時運用結果(例えば、履歴収集、シーケンス・オブ・イベント、予防保守)

Safety-critical functions effect the basic safety integrity of the plant. These normally dormant functions kick in only when process control systems, or their operators, have failed. By design and by regular interval inspection, they have a well-understood probability of failure on demand in the range of typically once per 10-1000 years.

安全上重要な機能は、プラントの基本的な安全性の整合性に影響を与えます。これらは通常休止状態機能は、プロセス制御システム、またはその事業者は、失敗したときにのみに蹴ります。設計により、定期的な間隔検査によって、彼らは通常、一度10-1000年あたりの範囲内のオンデマンド故障のよく理解確率を持っています。

In-time deliveries of messages become more relevant as the class number decreases.

では、時間のメッセージの配達は、クラス数が減少するにつれて、より関連するようになります。

Note that for a control application, the jitter is just as important as latency and has a potential of destabilizing control algorithms.

制御アプリケーションのために、ジッタは、レイテンシと同様に重要であると不安定化制御アルゴリズムの可能性を秘めていることに注意してください。

Industrial users are interested in deploying wireless networks for the monitoring classes 4 and 5, and in the non-critical portions of classes 2 through 3.

産業ユーザは、監視クラス4および5のための、およびクラス3を介して2の非クリティカル部分に無線ネットワークを展開することに興味があります。

Classes 4 and 5 also include asset monitoring and tracking, which include equipment monitoring and are essentially separate from process monitoring. An example of equipment monitoring is the recording of motor vibrations to detect bearing wear. However, similar sensors detecting excessive vibration levels could be used as safeguarding loops that immediately initiate a trip, and thus end up being class 0.

クラス4および5はまた、機器の監視を含み、本質的プロセス監視から分離された資産監視および追跡を含みます。機器監視の例では、軸受の摩耗を検出するためのモータ振動の記録です。しかし、過度の振動レベルを検出する同様のセンサは直ちに旅行を開始し、従って、クラス0になってしまうループの保護として使用することができます。

In the near future, most LLN systems in industrial automation environments will be for low-frequency data collection. Packets containing samples will be generated continuously, and 90% of the market is covered by packet rates of between 1/second and 1/hour, with the average under 1/minute. In industrial process, these sensors include temperature, pressure, fluid flow, tank level, and corrosion. Some sensors are bursty, such as vibration monitors that may generate and transmit tens of kilobytes (hundreds to thousands of packets) of time-series data at reporting rates of minutes to days.

近い将来には、産業用オートメーション環境の中で最もLLNシステムは、低周波数データ収集のためになります。サンプルを含むパケットが連続的に生成され、市場の90%が1 /分の下に平均で、1 /秒及び1 /時間の間のパケットレートで覆われています。工業プロセスでは、これらのセンサは、温度、圧力、流体流量、タンクレベル、及び腐食を含みます。いくつかのセンサは、日分の速度を報告における時系列データのキロバイト数十を生成して送信することができる振動モニタ(パケットの数百〜数千)のように、バースト的です。

Almost all of these sensors will have built-in microprocessors that may detect alarm conditions. Time-critical alarm packets are expected to be granted a lower latency than periodic sensor data streams.

ほとんどこれらのセンサの全ては、アラーム状態を検出することができる内蔵のマイクロプロセッサを持つことになります。タイムクリティカルアラームパケットが定期的にセンサ・データ・ストリームより低いレイテンシーを付与されることが期待されます。

Some devices will transmit a log file every day, again with typically tens of kilobytes of data. For these applications, there is very little "downstream" traffic coming from the LLN access point and traveling to particular sensors. During diagnostics, however, a technician may be investigating a fault from a control room and expect to have "low" latency (human tolerable) in a command/response mode.

一部のデバイスは、データのキロバイト一般的に数十再び、毎日ログファイルを送信します。これらのアプリケーションでは、非常に小さな「下流」交通LLNアクセスポイントから来ると、特定のセンサーに旅行があります。診断時には、しかし、技術者が制御室からの障害を調査して、コマンド/応答モードでは、「低」のレイテンシ(人間許容)を持つことを期待することができます。

Low-rate control, often with a "human in the loop" (also referred to as "open loop"), is implemented via communication to a control room because that's where the human in the loop will be. The sensor data makes its way through the LLN access point to the centralized controller where it is processed, the operator sees the information and takes action, and the control information is then sent out to the actuator node in the network.

ループ内の人間がされるところだから低レート制御は、しばしば(また、「オープンループ」と呼ばれる)「ループにおけるヒト」と、制御室へ通信を介して実施されます。センサデータは、それが処理される集中型コントローラへLLNアクセスポイントを介して、その方法は、操作者が情報を見て、アクションを実行し、制御情報は、ネットワーク内のアクチュエータ・ノードに送出されることができます。

In the future, it is envisioned that some open-loop processes will be automated (closed loop) and packets will flow over local loops and not involve the LLN access point. These closed-loop controls for non-critical applications will be implemented on LLNs. Non-critical closed-loop applications have a latency requirement that can be as low as 100 milliseconds but many control loops are tolerant of latencies above 1 second.

将来的には、一部開ループプロセスが自動化されることが想定される(閉ループ)とパケットがローカル・ループ上を流れるとLLNアクセスポイントを伴わないであろう。非クリティカルなアプリケーションのためのこれらの閉ループ制御はLLNsに実装されます。非クリティカル閉ループアプリケーションは、100ミリ秒ほど低くすることができるレイテンシ要件を有するが、多くの制御ループは、1秒以上の待ち時間は許容されます。

More likely though is that loops will be closed in the field entirely, and in such a case, having wireless links within the control loop does not usually present actual value. Most control loops have sensors and actuators within such proximity that a wire between them remains the most sensible option from an economic point of view. This 'control in the field' architecture is already common practice with wired fieldbusses. An 'upstream' wireless link would only be used to influence the in-field controller settings and to occasionally capture diagnostics. Even though the link back to a control room might be wireless, this architecture reduces the tight latency and availability requirements for the wireless links.

可能性が高いもののループは完全フィールドに閉鎖されることであり、このような場合には、制御ループ内の無線リンクを有する通常実際の値を示しません。ほとんどの制御ループは、それらの間のワイヤが経済的な観点から、最も賢明なオプションままであるように近接内のセンサやアクチュエータを持っています。この「制御フィールドの」アーキテクチャは、有線フィールドバスですでに一般的です。 '上流のワイヤレスリンクは、フィールドでのコントローラの設定に影響を与えるために、時折診断をキャプチャするために使用されるだろう。制御室へのバックリンクは無線であるかもしれないにもかかわらず、このアーキテクチャは、無線リンクのためのタイトな待ち時間と可用性の要件を低減します。

Closing loops in the field:

フィールド内のループを閉じます:

o does not prevent the same loop from being closed through a remote multivariable controller during some modes of operation, while being closed directly in the field during other modes of operation (e.g., fallback, or when timing is more critical)

他の動作モード中にフィールドに直接閉鎖された状態でoは、いくつかの動作モードの間、リモート多変数コントローラを介して閉鎖されるのと同じループを妨げない(例えば、フォールバック、またはタイミングがより重要である場合)

o does not imply that the loop will be closed with a wired connection, or that the wired connection is more energy efficient even when it exists as an alternate to the wireless connection.

Oは、ループは、有線接続で閉鎖されることを意味するものではない、又は有線接続は、無線接続の代替として存在する場合であってもより多くのエネルギー効率的であること。

A realistic future scenario is for a field device with a battery or ultra-capacitor power storage to have both wireless and unpowered wired communications capability (e.g., galvanically isolated RS-485), where the wireless communication is more flexible and, for local loop operation, more energy efficient. The wired communication capability serves as a backup interconnect among the loop elements, but without a wired connection back to the operations center blockhouse. In other words, the loop elements are interconnected through wiring to a nearby junction box, but the 2 km home-run link from the junction box to the control center does not exist.

現実的な将来のシナリオは両方無線および非給電有線通信能力を有する電池又はウルトラキャパシタの電力貯蔵とフィールドデバイスのためのものである(例えば、ガルバニック絶縁RS-485)、無線通信ローカルループ動作のために、より柔軟です、より多くのエネルギー効率の良いです。有線通信機能は、ループ要素間の相互バックアップとして機能するが、バックオペレーションセンタ要塞への有線接続せず。言い換えれば、ループ要素は、近くのジャンクションボックスに配線を介して相互に接続されているが、コントロールセンターへのジャンクションボックスから2キロホームランリンクが存在しません。

When wireless communication conditions are good, devices use wireless for loop interconnect, and either one wireless device reports alarms and other status to the control center for all elements of the loop, or each element reports independently. When wireless communications are sporadic, the loop interconnect uses the self-powered galvanically isolated RS-485 link and one of the devices with good wireless communications to the control center serves as a router for those devices that are unable to contact the control center directly.

無線通信状態が良好である場合、デバイスはループ相互接続のための無線を使用し、いずれか一方の無線デバイスは、独立して、ループのすべての要素、または各要素レポートのコントロールセンターにアラームおよび他の状態を報告します。無線通信が散発的である場合、ループ配線、コントロールセンターに自己給電式ガルバニック絶縁RS-485リンクおよび良好な無線通信を備えたデバイスの1つを使用する直接制御センターに連絡することができないそれらのデバイスのためのルータとして機能します。

The above approach is particularly attractive for large storage tanks in tank farms, where devices may not all have good wireless visibility of the control center, and where a home-run cable from the tank to the control center is undesirable due to the electro-potential differences between the tank location and the distant control center that arise during lightning storms.

上記のアプローチは、デバイスは、すべてのコントロールセンターの良い無線視認性を有していてもよく、ここで、コントロールセンターへのタンクからホームランケーブルによる電気ポテンシャルに望ましくないタンクファームに大きな貯蔵タンクのために特に魅力的ですタンクの位置と雷の中に発生遠いコントロールセンターとの違い。

In fast control, tens of milliseconds of latency is typical. In many of these systems, if a packet does not arrive within the specified interval, the system enters an emergency shutdown state, often with substantial financial repercussions. For a one-second control loop in a system with a target of 30 years for the mean time between shutdowns, the latency requirement implies nine 9s of reliability (aka 99.9999999% reliability). Given such exposure, given the intrinsic vulnerability of wireless link availability, and given the emergence of control in the field architectures, most users tend not to aim for fast closed-loop control with wireless links within that fast loop.

高速制御では、レイテンシーの数十ミリ秒が典型的です。これらのシステムの多くでは、パケットが指定した間隔内に到着しない場合、システムは、多くの場合、かなりの財政影響で、緊急停止状態になります。シャットダウンの間の平均時間は30年間の目標を有するシステムにおける1秒の制御ループのために、待ち時間要件は、信頼性の9 9S(またの名99.9999999%信頼性)を意味します。ような暴露を考えると、無線リンクの可用性の固有の脆弱性を与え、そしてフィールド・アーキテクチャにおける制御の出現を与え、ほとんどのユーザーは、その高速ループ内の無線リンクでの高速閉ループ制御を目指していない傾向があります。

3.2. Network Topology of Industrial Applications
3.2. 産業用アプリケーションのネットワークトポロジ

Although network topology is difficult to generalize, the majority of existing applications can be met by networks of 10 to 200 field devices and a maximum number of hops of 20. It is assumed that the field devices themselves will provide routing capability for the network, and additional repeaters/routers will not be required in most cases.

ネットワークトポロジが一般化することは困難であるが、既存のアプリケーションの大部分は、10〜200のフィールドデバイスのネットワークによって満たすことができると20のホップの最大数は、フィールド装置自体がネットワークのルーティング機能を提供することが想定され、そして追加の中継器/ルーターは、ほとんどの場合、必要とされることはありません。

For the vast majority of industrial applications, the traffic is mostly composed of real-time publish/subscribe sensor data also referred to as buffered, from the field devices over an LLN towards one or more sinks. Increasingly over time, these sinks will be a part of a backbone, but today they are often fragmented and isolated.

産業用アプリケーションの大多数のため、トラフィックはほとんどリアルタイムパブリッシュ/サブスクライブのセンサーデータで構成され、バッファとしても、一台の以上のシンクに向けたLLN以上のフィールドデバイスから、参照。ますます時間をかけて、これらのシンクは、骨格の一部になりますが、今日では、多くの場合、断片化し、孤立しています。

The wireless sensor network (WSN) is an LLN of field devices for which two logical roles are defined, the field routers and the non-routing devices. It is acceptable and even probable that the repartition of the roles across the field devices changes over time to balance the cost of the forwarding operation amongst the nodes.

無線センサネットワーク(WSN)は、二つの論理ロールが定義されているフィールド装置、フィールドルータおよび非ルーティングデバイスのLLNあります。フィールド機器間での役割の配分は、ノード間転送操作のコストのバランスを取るために時間をかけて変化すること許容できるとさえ考えられます。

In order to scale a control network in terms of density, one possible architecture is to deploy a backbone as a canopy that aggregates multiple smaller LLNs. The backbone is a high-speed infrastructure network that may interconnect multiple WSNs through backbone routers. Infrastructure devices can be connected to the backbone. A gateway/ manager that interconnects the backbone to the plant network of the corporate network can be viewed as collapsing the backbone and the infrastructure devices into a single device that operates all the required logical roles. The backbone is likely to become an option in the industrial network.

密度の点で制御ネットワークを拡張するために、一つの可能​​なアーキテクチャは、複数のより小さなLLNsを集約天蓋としてバックボーンを配備することです。バックボーンは、バックボーンルータを通じて複数のWSNを相互接続することができる高速インフラストラクチャネットワークです。インフラストラクチャデバイスは、バックボーンに接続することができます。企業ネットワークのプラントネットワークにバックボーンを相互接続するゲートウェイ/管理者は、すべての必要な論理ロールを操作単一のデバイスにバックボーンとインフラストラクチャデバイスを崩壊とみなすことができます。バックボーンは、産業用ネットワーク内のオプションになる可能性があります。

Typically, such backbones interconnect to the 'legacy' wired plant infrastructure, which is known as the plant network or Process Control Domain (PCD). These plant automation networks are segregated domain-wise from the office network or office domain (OD), which in itself is typically segregated from the Internet.

プラントネットワークまたはプロセス制御ドメイン(PCD)としても知られている「レガシー」有線植物インフラ、典型的には、そのようなバックボーン相互接続。これらのプラント・オートメーション・ネットワークは、それ自体では通常、インターネットから分離されたオフィスネットワークやオフィスのドメイン(OD)から、ドメインごとに分離されています。

Sinks for LLN sensor data reside on the plant network (the PCD), the business network (the OD), and on the Internet. Applications close to existing plant automation, such as wired process control and monitoring systems running on fieldbusses, that require high availability and low latencies, and that are managed by 'Control and Automation' departments typically reside on the PCD. Other applications such as automated corrosion monitoring, cathodic protection voltage verification, or machine condition (vibration) monitoring where one sample per week is considered over-sampling, would more likely deliver their sensor readings in the OD. Such applications are 'owned' by, e.g., maintenance departments.

LLNセンサデータのためのシンクは、プラントネットワーク(PCD)、ビジネスネットワーク(OD)上、およびインターネット上に存在します。高可用性と低レイテンシを必要とし、有線プロセス制御およびフィールドバス上で実行しているシステムの監視などの既存工場の自動化に近いアプリケーションは、によって管理されている「制御およびオートメーション」部門は通常、PCD上に存在します。このような自動化された腐食モニタリング、陰極保護電圧の確認、または週ごとに1つのサンプルは、オーバーサンプリングとみなされているマシンの状態(振動)モニタリングなどの他のアプリケーションは、より多くの可能性が高いODで自分のセンサーの測定値を提供します。このようなアプリケーションは、例えば、メンテナンス部門、によって「所有」されています。

Yet other applications like third-party-maintained luminaries, or vendor-managed inventory systems, where a supplier of chemicals needs access to tank level readings at his customer's site, will be best served with direct Internet connectivity all the way to its sensor at his customer's site. Temporary 'babysitting sensors' deployed for just a few days, say during startup or troubleshooting or for ad hoc measurement campaigns for research and development purposes, are other examples where Internet would be the domain where wireless sensor data would land, and other domains such as the OD and PCD should preferably be circumvented if quick deployment without potentially impacting plant safety integrity is required.

しかし、化学物質の供給者が彼の顧客のサイトでタンクレベルの測定値へのアクセスを必要とするサードパーティ・維持著名、またはベンダー管理在庫管理システム、などの他のアプリケーションは、最高の状態でそのセンサに直接インターネットに接続してすべての方法を提供することになる彼のお客様のサイト。わずか数日のために展開され、一時的な「ベビーシッターセンサーは」、起動時やトラブルシューティング時や研究開発の目的のために臨時の測定キャンペーンのために言って、インターネットは無線センサデータが上陸うドメインになり、他の例であり、そのように他のドメイン潜在的に衝突プラントの安全性の整合性のない迅速な展開が必要な場合は、ODとPCDは、好ましくは回避されなければなりません。

This multiple-domain multiple-application connectivity creates a significant challenge. Many different applications will all share the same medium, the ether, within the fence, preferably sharing the same frequency bands, and preferably sharing the same protocols, preferably synchronized to optimize coexistence challenges, yet logically segregated to avoid creation of intolerable shortcuts between existing wired domains.

この複数ドメインの複数のアプリケーションの接続が重要な課題を作成します。多くの異なるアプリケーションはすべて、好ましくは、同じ周波数帯域を共有し、そして好ましくは、同じプロトコルを共有し、フェンス内で、同じ培地、エーテルを共有し、好ましくは共存問題を最適化するために、同期、まだ論理有線既存の間の許容できないショートカットの作成を避けるために偏析ドメイン。

Given this challenge, LLNs are best to be treated as all sitting on yet another segregated domain, segregated from all other wired domains where conventional security is organized by perimeter. Moving away from the traditional perimeter-security mindset means moving towards stronger end-device identity authentication, so that LLN access points can split the various wireless data streams and interconnect back to the appropriate domain (pending the gateways' establishment of the message originators' identity and trust).

この課題を考えると、LLNsは、さらに別の隔離領域の上に座って、すべてとして扱われるのがベストです、従来のセキュリティが境界で編成されている他のすべての有線のドメインから分離しました。伝統的な境界セキュリティの考え方から離れるはLLNアクセスポイントが同一のゲートウェイメッセージ発信の確立ペンディング適切なドメイン(に戻って様々な無線データ・ストリームおよび相互接続を分割することができるように、強力なエンドデバイスの識別認証に向かって移動手段そして、信頼)。

Similar considerations are to be given to how multiple applications may or may not be allowed to share routing devices and their potentially redundant bandwidth within the network. Challenges here are to balance available capacity, required latencies, expected priorities, and (last but not least) available (battery) energy within the routing devices.

同様の考察は、ネットワーク内のルーティング・デバイスとその潜在的に冗長な帯域幅を共有することを許可してもしなくてもよい方法を複数のアプリケーションに付与されます。ここでの課題は、利用可能な容量、必要な待機時間、期待優先順位、およびルーティングデバイス内の(少なくとも最後のではなく)利用可能(バッテリー)のエネルギーのバランスをとることです。

3.2.1. The Physical Topology
3.2.1. 物理トポロジー

There is no specific physical topology for an industrial process control network.

工業用プロセス制御ネットワークのための特定の物理トポロジーはありません。

One extreme example is a multi-square-kilometer refinery where isolated tanks, some of them with power but most with no backbone connectivity, compose a farm that spans over of the surface of the plant. A few hundred field devices are deployed to ensure the global coverage using a wireless self-forming self-healing mesh network that might be 5 to 10 hops across. Local feedback loops and mobile workers tend to be only 1 or 2 hops. The backbone is in the refinery proper, many hops away. Even there, powered infrastructure is also typically several hops away. In that case, hopping to/from the powered infrastructure may often be more costly than the direct route.

一つの極端な例では、単離されたタンクは、それらのいくつかのパワーを有するがないバックボーン接続とほとんどは、植物の表面の上にまたがるファームを構成するマルチ平方キロ製油所です。数百のフィールドデバイスは、全体で5〜10ホップであるかもしれない無線自己形成自己修復メッシュネットワークを使用してグローバルカバレッジを確保するために配備されています。ローカルフィードバックループとモバイルワーカーはわずか1または2ホップになりがち。バックボーンは、適切な、多くのホップ離れの製油所です。でもそこに、電力が供給インフラは、典型的には、いくつかのホップ離れもあります。その場合にホッピング/電動インフラからしばしば直接経路よりも高価であってもよいです。

In the opposite extreme case, the backbone network spans all the nodes and most nodes are in direct sight of one or more backbone routers. Most communication between field devices and infrastructure devices, as well as field device to field device, occurs across the backbone. From afar, this model resembles the WiFi ESS (Extended Service Set). But from a layer-3 (L3) perspective, the issues are the default (backbone) router selection and the routing inside the backbone, whereas the radio hop towards the field device is in fact a simple local delivery.

逆の極端な場合では、バックボーンネットワークは、すべてのノードにまたがり、ほとんどのノードは、一つ以上のバックボーンルータの直接視界にあります。フィールドデバイスへのほとんどのフィールド機器およびインフラストラクチャデバイス間の通信だけでなく、フィールドデバイスは、バックボーン全体で発生します。遠くから、このモデルは、WiFi ESS(拡張サービスセット)が似ています。フィールドデバイスに向けて無線ホップは、実際には単純な局所送達であるのに対し、しかし、レイヤ3(L3)の観点から、問題は、デフォルト(バックボーン)ルータの選択及び骨格内部ルーティングです。

            ---------+----------------------------
                     |          Plant Network
                     |
                  +-----+
                  |     | Gateway             M : Mobile device
                  |     |                     o : Field device
                  +-----+
                     |
                     |      Backbone
               +--------------------+------------------+
               |                    |                  |
            +-----+             +-----+             +-----+
            |     | Backbone    |     | Backbone    |     | Backbone
            |     | router      |     | router      |     | router
            +-----+             +-----+             +-----+
               o    o   o    o     o   o  o   o   o   o  o   o o
           o o   o  o   o  o  o o   o  o  o   o   o   o  o  o  o o
          o  o o  o o    o   o   o  o  o  o    M    o  o  o o o
          o   o  M o  o  o     o  o    o  o  o    o  o   o  o   o
            o   o o       o        o  o         o        o o
                    o           o          o             o     o
                           LLN
        

Figure 1: Backbone-Based Physical Topology

図1:バックボーンベースの物理トポロジー

An intermediate case is illustrated in Figure 1 with a backbone that spans the Wireless Sensor Network in such a fashion that any WSN node is only a few wireless hops away from the nearest backbone router. WSN nodes are expected to organize into self-forming, self-healing, self-optimizing logical topologies that enable leveraging the backbone when it is most efficient to do so.

中間ケースは、任意のWSNノードが離れて最寄りのバックボーンルータからわずか数の無線ホップであるようなやり方で無線センサネットワークにまたがる骨格と、図1に示されています。 WSNノードは、そうするのが最も効率的であるとき、バックボーンを活用可能に自己形成、自己修復、自己最適化論理トポロジに整理することが期待されています。

It must be noted that the routing function is expected to be so simple that any field device could assume the role of a router, depending on the self-discovery of the topology and the power status of the neighbors. On the other hand, only devices equipped with the appropriate hardware and software combination could assume the role of an endpoint for a given purpose, such as sensor or actuator.

ルーティング機能は、任意のフィールドデバイスは、トポロジの自己発見や近所の電源状態に応じて、ルータの役割を担うことができるようにシンプルであることが予想されていることに留意しなければなりません。一方、適切なハードウェアおよびソフトウェアの組み合わせを備えた唯一の装置は、センサ又はアクチュエータとして、所与の目的のエンドポイントの役割を担う可能性があります。

3.2.2. Logical Topologies
3.2.2. 論理トポロジ

Most of the traffic over the LLN is publish/subscribe of sensor data from the field device towards a sink that can be a backbone router, a gateway, or a controller/manager. The destination of the sensor data is an infrastructure device that sits on the backbone and is reachable via one or more backbone routers.

LLN上のトラフィックのほとんどは、バックボーンルータ、ゲートウェイ、または制御/管理することができるシンクに向かってフィールド装置からのセンサデータのパブリッシュ/サブスクライブあります。センサデータの送信先は、主鎖上にあり、一つ以上のバックボーンルータを介して到達可能なインフラストラクチャデバイスです。

For security, reliability, availability, or serviceability reasons, it is often required that the logical topologies are not physically congruent over the radio network; that is, they form logical partitions of the LLN. For instance, a routing topology that is set up for control should be isolated from a topology that reports the temperature and the status of the vents, if that second topology has lesser constraints for the security policy. This isolation might be implemented as Virtual LANs and Virtual Routing Tables in shared nodes in the backbone, but correspond effectively to physical nodes in the wireless network.

セキュリティ、信頼性、可用性、または保守上の理由から、多くの場合、論理トポロジは、無線ネットワークを介して物理的に合同でないことが必要です。つまり、彼らはLLNの論理パーティションを形成します。例えば、制御用に設定されたルーティングトポロジは、第2のトポロジは、セキュリティポリシーのために、より少ない制約を有する場合、温度と通気孔の状態を報告トポロジーから単離されなければなりません。この分離は、主鎖に共有ノードにおける仮想LANと仮想ルーティングテーブルとして実装するが、無線ネットワーク内の物理ノードに効果的に対応するかもしれません。

Since publishing the data is the raison d'etre for most of the sensors, in some cases it makes sense to build proactively a set of routes between the sensors and one or more backbone routers and maintain those routes at all time. Also, because of the lossy nature of the network, the routing in place should attempt to propose multiple paths in the form of Directed Acyclic Graphs oriented towards the destination.

データを公開することは、センサのほとんどの存在意義であるので、いくつかのケースでは、全ての時点でそれらのルートを積極的にセンサーと1つ以上のバックボーンルータ間のルートのセットを構築し、維持するために理にかなっています。また、ネットワークの損失のある性質のため、代わりに、ルーティングは、宛先に向かって配向有向非循環グラフの形で複数のパスを提案しようとすべきです。

In contrast with the general requirement of maintaining default routes towards the sinks, the need for field device to field device (FD-to-FD) connectivity is very specific and rare, though the traffic associated might be of foremost importance. FD-to-FD routes are often the most critical, optimized, and well-maintained routes. A class 0 safeguarding loop requires guaranteed delivery and extremely tight response times. Both the respect of criteria in the route computation and the quality of the maintenance of the route are critical for the field devices' operation. Typically, a control loop will be using a dedicated direct wire that has very different capabilities, cost, and constraints than the wireless medium, with the need to use a wireless path as a backup route only in case of loss of the wired path.

関連するトラフィックは、何よりも重要なのかもしれませんがシンクに向けてのデフォルトルートを維持するための一般的な要件とは対照的に、フィールドデバイスフィールドデバイスへ(FD-に-FD)接続の必要性は、非常に具体的かつまれです。 FD-へ-FDのルートは、多くの場合、最適化され、最も重要な、そして手入れの行き届いたルートです。クラス0安全防護ループが保証された配信と非常にタイトな応答時間を必要とします。どちらのルート計算における基準の尊重とルートのメンテナンスの品質は、フィールドデバイスの動作のために重要です。典型的には、制御ループは、有線経路の損失の場合に、バックアップルートとして無線パスを使用する必要性と、無線媒体よりも非常に異なる能力、コスト、および制約を有する専用の直接ワイヤを使用します。

Considering that each FD-to-FD route computation has specific constraints in terms of latency and availability, it can be expected that the shortest path possible will often be selected and that this path will be routed inside the LLN as opposed to via the backbone. It can also be noted that the lifetimes of the routes might range from minutes for a mobile worker to tens of years for a command and control closed loop. Finally, time-varying user requirements for latency and bandwidth will change the constraints on the routes, which might either trigger a constrained route recomputation, a reprovisioning of the underlying L2 protocols, or both in that order. For instance, a wireless worker may initiate a bulk transfer to configure or diagnose a field device. A level sensor device may need to perform a calibration and send a bulk file to a plant.

各FDツーFDルート計算は、待ち時間および可用性の観点から特定の制約を有していることを考慮すると、最短経路がしばしば選択されることとバックボーンを介してとは対照的に、この経路はLLN内部ルーティングされることが期待できます。また、ルートの寿命は、コマンドおよび制御のための数十年にモバイルワーカーのための分の範囲ループを閉じた可能性があることに注意することができます。最後に、待ち時間および帯域幅のために時間的に変化するユーザの要件は、その順序に制約された経路の再計算、基礎をなすL2プロトコルの再プロビジョニング、またはその両方をトリガー可能性があるいずれかのルートの制約を変更します。例えば、無線作業者は、フィールドデバイスを構成または診断するバルク転送を開始することができます。レベルセンサデバイスは、キャリブレーションを実行し、プラントにバルクファイルを送信する必要があるかもしれません。

4. Requirements Related to Traffic Characteristics
トラフィックの特性に関連する4要件

[ISA100.11a] selected IPv6 as its network layer for a number of reasons, including the huge address space and the large potential size of a subnet, which can range up to 10K nodes in a plant deployment. In the ISA100 model, industrial applications fall into four large service categories:

【ISA100.11aの】植物配備における10Kノードまでの範囲であることができる巨大なアドレス空間とサブネットの大きい電位サイズを含むいくつかの理由、のためにネットワーク層としてIPv6を選択しました。 ISA100のモデルでは、産業用アプリケーションには、4大規模なサービスのカテゴリに分類されます。

1. Periodic data (aka buffered). Data that is generated periodically and has a well understood data bandwidth requirement, both deterministic and predictable. Timely delivery of such data is often the core function of a wireless sensor network and permanent resources are assigned to ensure that the required bandwidth stays available. Buffered data usually exhibits a short time to live, and the newer reading obsoletes the previous. In some cases, alarms are low-priority information that gets repeated over and over. The end-to-end latency of this data is not as important as the regularity with which the data is presented to the plant application.

1.定期的なデータ(別名バッファリング)。 、決定論的かつ予測の両方を定期的に生成し、よく理解データ帯域幅要件を有するデータ。このようなデータのタイムリーな配信は、多くの場合、無線センサネットワークのコア機能であり、永続的なリソースが必要な帯域幅が利用可能にとどまることを確実にするために割り当てられています。バッファされたデータは、通常、生きるために短い時間を示し、新しい読書は前を廃止します。いくつかのケースでは、アラームが何度も繰り返されます、優先度の低い情報です。このデータのエンドツーエンドの待ち時間は、データを植物アプリケーションに提示している規則と同じくらい重要ではありません。

2. Event data. This category includes alarms and aperiodic data reports with bursty data bandwidth requirements. In certain cases, alarms are critical and require a priority service from the network.

2.イベントデータ。このカテゴリにはアラームやバースト的なデータ帯域幅要件と非周期的なデータのレポートが含まれています。特定の例では、アラームは重要であり、ネットワークからの優先順位のサービスを必要とします。

3. Client/Server. Many industrial applications are based on a client/server model and implement a command response protocol. The data bandwidth required is often bursty. The acceptable round-trip latency for some legacy systems was based on the time to send tens of bytes over a 1200 baud link. Hundreds of milliseconds is typical. This type of request is statistically multiplexed over the LLN and cost-based, fair-share, best-effort service is usually expected.

3.クライアント/サーバー。多くの産業用アプリケーションは、クライアント/サーバモデルに基づいており、コマンド応答プロトコルを実装しています。必要なデータ帯域幅は、多くの場合、バースト性です。一部のレガシーシステムの許容ラウンドトリップ遅延は、1200ボーリンク上でのバイトの数十を送信するために、時間に基づいていました。数百ミリ秒が典型的です。このタイプのリクエストは、統計学的にLLN上で多重化され、コストベース、フェアシェア、ベストエフォート型のサービスは通常期待されています。

4. Bulk transfer. Bulk transfers involve the transmission of blocks of data in multiple packets where temporary resources are assigned to meet a transaction time constraint. Transient resources are assigned for a limited time (related to file size and data rate) to meet the bulk transfers service requirements.

4.バルク転送。バルク転送は、一時的なリソースがトランザクション時間制約を満たすために割り当てられた複数のパケット内のデータブロックの送信を伴います。過渡リソースは、バルク転送サービスの要件を満たすために(サイズおよびデータレートをファイルに関連)、限られた時間のために割り当てられています。

4.1. Service Requirements
4.1. サービスの要件

The following service parameters can affect routing decisions in a resource-constrained network:

次のサービスパラメータは、リソースに制約のあるネットワークでのルーティングの決定に影響を与えることができます。

o Data bandwidth - the bandwidth might be allocated permanently or for a period of time to a specific flow that usually exhibits well-defined properties of burstiness and throughput. Some bandwidth will also be statistically shared between flows in a best-effort fashion.

Oデータ帯域幅 - 帯域幅は、永久的に又は通常バーストとスループットの明確に定義された特性を示す特定のフローへの時間の期間に割り当てられるかもしれません。いくつかの帯域幅も統計学的にベストエフォート方式でフロー間で共有されます。

o Latency - the time taken for the data to transit the network from the source to the destination. This may be expressed in terms of a deadline for delivery. Most monitoring latencies will be in seconds to minutes.

Oレイテンシ - ソースから宛先に遷移するデータのためのネットワークを要した時間。これは、送達のための期限で表現されてもよいです。ほとんどの監視の待ち時間は数秒から数分になります。

o Transmission phase - process applications can be synchronized to wall clock time and require coordinated transmissions. A common coordination frequency is 4 Hz (250 ms).

O伝送フェーズは - プロセスアプリケーションは、クロック時間を壁に同期して協調伝送を必要とすることができます。共通コーディネーション周波数は4ヘルツ(250ミリ秒)です。

o Service contract type - revocation priority. LLNs have limited network resources that can vary with time. This means the system can become fully subscribed or even over-subscribed. System policies determine how resources are allocated when resources are over-subscribed. The choices are blocking and graceful degradation.

Oサービスの契約タイプ - 失効優先。 LLNsは、時間とともに変化することができ、ネットワークリソースが限られています。これは、システムが完全にサブスクライブ、あるいはオーバーサブスクライブになることを意味します。システムポリシーは、リソースがオーバーサブスクライブしている時にリソースが割り当てられている方法を決定します。選択肢は、ブロッキングと優雅な劣化しています。

o Transmission priority - the means by which limited resources within field devices are allocated across multiple services. For transmissions, a device has to select which packet in its queue will be sent at the next transmission opportunity. Packet priority is used as one criterion for selecting the next packet. For reception, a device has to decide how to store a received packet. The field devices are memory-constrained and receive buffers may become full. Packet priority is used to select which packets are stored or discarded.

O送信優先 - フィールドデバイス内の限られたリソースは、複数のサービス間で割り当てされる手段。送信では、デバイスは、次の送信機会に送信されます、キュー内のどのパケットを選択する必要があります。パケットの優先度は次のパケットを選択するための一つの基準として使用されます。受信の場合、デバイスは、受信したパケットを格納する方法を決定する必要があります。フィールドデバイスは、メモリに制約され、バッファがいっぱいになる可能性受けます。パケットの優先度が格納または破棄されたパケットを選択するために使用されます。

The routing protocol MUST also support different metric types for each link used to compute the path according to some objective function (e.g., minimize latency) depending on the nature of the traffic.

ルーティングプロトコルは、トラフィックの性質に応じて(例えば、レイテンシを最小化する)、いくつかの目的関数に応じてパスを計算するために使用された各リンクのための異なるメトリック・タイプをサポートしなければなりません。

For these reasons, the ROLL routing infrastructure is REQUIRED to compute and update constrained routes on demand, and it can be expected that this model will become more prevalent for FD-to-FD connectivity as well as for some FD-to-infrastructure-device connectivity over time.

これらの理由のために、ルーティングインフラストラクチャロールを計算するために必要であり、更新は、制約オンデマンド経路を、そしてこのモデルはFD-に-FD接続のためだけでなく、いくつかのFD・ツー・インフラ装置用のより一般的になるであろうことが期待できます時間をかけて接続。

Industrial application data flows between field devices are not necessarily symmetric. In particular, asymmetrical cost and unidirectional routes are common for published data and alerts, which represent the most part of the sensor traffic. The routing protocol MUST be able to compute a set of unidirectional routes with potentially different costs that are composed of one or more non-congruent paths.

フィールドデバイスとの間の産業アプリケーションデータフローは必ずしも対称ではありません。具体的には、非対称のコストと一方向のルートはセンサー、トラフィックの大部分を表して公開されたデータとアラート、共通です。ルーティングプロトコルは、1つ以上の非合同パスから構成されている潜在的に異なるコストで一方向ルートのセットを計算することができなければなりません。

As multiple paths are set up and a variety of flows traverse the network towards a same destination (for instance, a node acting as a sink for the LLN), the use of an additional marking/tagging mechanism based on upper-layer information will be REQUIRED for intermediate routers to discriminate the flows and perform the appropriate routing decision using only the content of the IPv6 packet (e.g., use of DSCP, Flow Label).

複数のパスが設定され、フローの様々な(例えば、LLNのためのシンクとして作用するノード)が同じ宛先に向けてネットワークを横断し、上位レイヤ情報に基づいて付加的なマーキング/タグ付け機構を使用することになりますように(例えば、DSCP、フローラベルの使用)IPv6パケットのコンテンツのみを使用して適切なルーティング決定をフローを識別し、実行するために中間ルータに必要です。

4.2. Configurable Application Requirement
4.2. 設定可能なアプリケーション要件

Time-varying user requirements for latency and bandwidth may require changes in the provisioning of the underlying L2 protocols. A technician may initiate a query/response session or bulk transfer to diagnose or configure a field device. A level sensor device may need to perform a calibration and send a bulk file to a plant. The routing protocol MUST support the ability to recompute paths based on network-layer abstractions of the underlying link attributes/metrics that may change dynamically.

待ち時間および帯域幅のために時間的に変化するユーザの要件は、基礎となるL2プロトコルのプロビジョニングの変更を必要とするかもしれません。技術者は、フィールドデバイスの診断または構成するクエリ/応答セッションまたはバルク転送を開始することができます。レベルセンサデバイスは、キャリブレーションを実行し、プラントにバルクファイルを送信する必要があるかもしれません。ルーティングプロトコルは、動的に変更される可能性があり、基礎となるリンク属性/メトリクスのネットワーク層の抽象化に基づいて経路を再計算する能力をサポートしなければなりません。

4.3. Different Routes for Different Flows
4.3. 異なるフローのための異なる経路

Because different services categories have different service requirements, it is often desirable to have different routes for different data flows between the same two endpoints. For example, alarm or periodic data from A to Z may require path diversity with specific latency and reliability. A file transfer between A and Z may not need path diversity. The routing algorithm MUST be able to generate different routes with different characteristics (e.g., optimized according to different costs, etc.).

異なるサービスカテゴリは異なるサービス要件を持っているので、同じ2つのエンドポイント間で異なるデータフローのための異なる経路を持つことが望ましいことが多いです。例えば、AからZまでのアラームまたは周期的なデータは、特定の待ち時間と信頼性パスダイバーシティを必要とし得ます。 AとZの間のファイル転送は、パスの多様性を必要としない場合があります。ルーティングアルゴリズムは、異なる特性を有する異なる経路を生成できなければならない(例えば、異なるコスト等に応じて最適化)。

Dynamic or configured states of links and nodes influence the capability of a given path to fulfill operational requirements such as stability, battery cost, or latency. Constraints such as battery lifetime derive from the application itself, and because industrial applications data flows are typically well-defined and well-controlled, it is usually possible to estimate the battery consumption of a router for a given topology.

リンクとノードの動的または構成された状態は、このような安定性、バッテリーのコスト、あるいは、待ち時間などの運用要件を満たすために与えられたパスの性能に影響を与えます。このような電池寿命などの制約は、アプリケーション自体に由来し、および産業用アプリケーションのデータフローは、典型的に明確に定義され、よく制御されているので、所定のトポロジにルータのバッテリー消費量を推定することが通常可能です。

The routing protocol MUST support the ability to (re)compute paths based on network-layer abstractions of upper-layer constraints to maintain the level of operation within required parameters. Such information MAY be advertised by the routing protocol as metrics that enable routing algorithms to establish appropriate paths that fit the upper-layer constraints.

ルーティングプロトコルは、(再)に必要なパラメータ内で動作のレベルを維持するために、上層の制約のネットワーク層の抽象化に基づいて経路を計算する能力をサポートしなければなりません。そのような情報は、上位レイヤの制約に合う適切なパスを確立するために、ルーティングアルゴリズムを有効にするメトリクスとしてルーティングプロトコルによってアドバタイズされるかもしれません。

The handling of an IPv6 packet by the network layer operates on the standard properties and the settings of the IPv6 packet header fields. These fields include the 3-tuple of the Flow Label and the Source and Destination Address that can be used to identify a flow and the Traffic Class octet that can be used to influence the Per Hop Behavior in intermediate routers.

ネットワーク層によってIPv6パケットの処理は、標準的な特性とIPv6パケットヘッダーフィールドの設定で動作します。これらのフィールドは、フローラベルと流れと中間ルータでのパーホップの動作に影響を与えるために使用することができますトラフィッククラスオクテットを識別するために使用することができ、送信元アドレスおよび宛先アドレスの3組が含まれます。

An application MAY choose how to set those fields for each packet or for streams of packets, and the routing protocol specification SHOULD state how different field settings will be handled to perform different routing decisions.

アプリケーションは、各パケットまたはパケットのストリームにこれらのフィールドを設定する方法を選択することができ、ルーティングプロトコル仕様は異なるルーティング決定を実行するために処理する方法の異なるフィールド設定明記してください。

5. Reliability Requirements
5.信頼性の要件

LLN reliability constitutes several unrelated aspects:

LLNの信頼性は、いくつかの無関係な側面を構成しています。

1) Availability of source-to-destination connectivity when the application needs it, expressed in number of successes divided by number of attempts.

1)アプリケーションがそれを必要とするソース - 宛先接続の可用性は、試行回数で割った成功の数で表さ。

2) Availability of source-to-destination connectivity when the application might need it, expressed in number of potential failures / available bandwidth,

2)アプリケーションは、それを必要とするかもしれないソースから宛先接続の可用性は、潜在的な障害/利用可能な帯域幅の数で表現しました

3) Ability, expressed in number of successes divided by number of attempts to get data delivered from source to destination within a capped time,

3)能力、キャップされた時間内に、ソースから宛先に配信されたデータを取得しようとする試みの数で割った成功回数で発現

4) How well a network (serving many applications) achieves end-to-end delivery of packets within a bounded latency,

4)どのように、多くのアプリケーションにサービスを提供するネットワーク()は有界待ち時間内のパケットのエンドツーエンド配信を実現します、

5) Trustworthiness of data that is delivered to the sinks,

シンクに配信されるデータの5)信頼と、

6) and others depending on the specific case.

6)など、特定の場合に応じ。

This makes quantifying reliability the equivalent of plotting it on a three (or more) dimensional graph. Different applications have different requirements, and expressing reliability as a one dimensional parameter, like 'reliability on my wireless network is 99.9%' often creates more confusion than clarity.

これは、信頼性の3つ(またはそれ以上)の上にプロットした等価次元グラフを定量化することができます。 「私のワイヤレスネットワーク上の信頼性は、99.9%は」しばしば明瞭以上の混乱を作成するように異なるアプリケーションは、異なる要件を持ち、1次元のパラメータとしての信頼性を表現します。

The impact of not receiving sensor data due to sporadic network outages can be devastating if this happens unnoticed. However, if destinations that expect periodic sensor data or alarm status updates fail to get them, then automatically these systems can take appropriate actions that prevent dangerous situations. Pending the wireless application, appropriate action ranges from initiating a shutdown within 100 ms, to using a last known good value for as much as N successive samples, to sending out an operator into the plant to collect monthly data in the conventional way, i.e., some portable sensor, or paper and a clipboard.

これは気付か発生した場合散発ネットワーク障害に起因するセンサデータを受信して​​いないの影響は壊滅的であることができます。定期的なセンサーデータやアラームステータスの更新を期待して宛先がそれらを得るために失敗する場合は、自動的にこれらのシステムは、危険な状況を防ぐために適切な行動をとることができます。無線アプリケーションを保留し、適切な処置は、すなわち、従来の方法で毎月のデータを収集するために植物にオペレータを送信し、N個の連続サンプル限りのために最後の既知の良好な値を使用して、100ミリ秒以内にシャットダウンを開始する範囲であります一部のポータブルセンサー、または紙とクリップボード。

The impact of receiving corrupted data, and not being able to detect that received data is corrupt, is often more dangerous. Data corruption can either come from random bit errors due to white noise, or from occasional bursty interference sources like thunderstorms or leaky microwave ovens, but also from conscious attacks by adversaries.

破損したデータを受信し、その受信したデータを検出することができないの影響は、破損していることが多い、より危険です。データ破損が原因の白色雑音、又は雷雨又は漏洩電子レンジのような時折バースト干渉源からだけでなく、敵によって意識的攻撃からランダムビットエラーから来ることができます。

Another critical aspect for the routing is the capability to ensure maximum disruption time and route maintenance. The maximum disruption time is the time it takes at most for a specific path to be restored when broken. Route maintenance ensures that a path is monitored cannot stay disrupted for more than the maximum disruption time. Maintenance should also ensure that a path continues to provide the service for which it was established, for instance, in terms of bandwidth, jitter, and latency.

ルーティングのための別の重要な局面は、最大中断時間および経路維持を確実にする能力です。最大中断時間は、それが壊れた場合に復元する特定のパスに最もに要する時間です。経路維持パスが監視されることを確実に最大の破壊時間以上中断滞在することはできません。メンテナンスもパスがそれは、帯域幅、ジッタ、および遅延の観点から、例えば、確立されたためにサービスを提供し続けていることを確認する必要があります。

In industrial applications, availability is usually defined with respect to end-to-end delivery of packets within a bounded latency. Availability requirements vary over many orders of magnitude. Some non-critical monitoring applications may tolerate an availability of less than 90% with hours of latency. Most industrial standards, such as HART7 [IEC62591], have set user availability expectations at 99.9%. Regulatory requirements are a driver for some industrial applications. Regulatory monitoring requires high data integrity because lost data is assumed to be out of compliance and subject to fines. This can drive up either availability or trustworthiness requirements.

産業用途では、可用性は通常有界待ち時間内のパケットのエンドツーエンド配信に対して定義されています。可用性の要件は何桁にわたって変動します。いくつかの非クリティカルなモニタリングアプリケーションは、待ち時間の時間で90%未満の利用可能性を許容します。このようHART7 [IEC62591]など、ほとんどの工業規格は、99.9%で、ユーザーの可用性の期待を設定しています。規制要件は、いくつかの産業用アプリケーションのためのドライバです。失われたデータは、罰金を遵守し、対象外であると仮定されているため、規制の監視は、高いデータの整合性が必要です。これは、可用性や信頼性の要件のいずれかを駆動することができます。

Because LLN link stability is often low, path diversity is critical. Hop-by-hop link diversity is used to improve latency-bounded reliability by sending data over diverse paths.

LLNリンク安定性が低いことが多いので、パスの多様性が重要です。ホップバイホップリンクの多様性は、多様な経路を介してデータを送信することにより、レイテンシ囲まれた信頼性を改善するために使用されます。

Because data from field devices are aggregated and funneled at the LLN access point before they are routed to plant applications, LLN access point redundancy is an important factor in overall availability. A route that connects a field device to a plant application may have multiple paths that go through more than one LLN access point. The routing protocol MUST be able to compute paths of not-necessarily-equal cost toward a given destination so as to enable load-balancing across a variety of paths. The availability of each path in a multipath route can change over time. Hence, it is important to measure the availability on a per-path basis and select a path (or paths) according to the availability requirements.

彼らは植物アプリケーションにルーティングされる前に、フィールド機器からのデータが集約され、LLNのアクセスポイントに注ぎ込まれているので、LLNアクセスポイントの冗長性は、全体的な可用性における重要な要因です。プラントアプリケーションにフィールドデバイスを接続する経路は、複数のLLNアクセスポイントを経由する複数のパスを有していてもよいです。ルーティングプロトコルは、経路の様々な間で負荷分散を可能にするように指定された宛先に向かって、必ずしも等しくないコストの経路を計算することができなければなりません。マルチパスルートの各パスの利用可能性は、時間の経過とともに変化することができます。したがって、可用性の要件に応じてパス単位で可用性を測定し、パス(又はパス)を選択することが重要です。

6. Device-Aware Routing Requirements
6.デバイス・アウェアルーティングの要件

Wireless LLN nodes in industrial environments are powered by a variety of sources. Battery-operated devices with lifetime requirements of at least five years are the most common. Battery operated devices have a cap on their total energy, and typically can report an estimate of remaining energy, and typically do not have constraints on the short-term average power consumption. Energy-scavenging devices are more complex. These systems contain both a power-scavenging device (such as solar, vibration, or temperature difference) and an energy storage device, such as a rechargeable battery or a capacitor. These systems, therefore, have limits on both long-term average power consumption (which cannot exceed the average scavenged power over the same interval) as well as the short-term limits imposed by the energy storage requirements. For solar-powered systems, the energy storage system is generally designed to provide days of power in the absence of sunlight. Many industrial sensors run off of a 4-20 mA current loop, and can scavenge on the order of milliwatts from that source. Vibration monitoring systems are a natural choice for vibration scavenging, which typically only provides tens or hundreds of microwatts. Due to industrial temperature ranges and desired lifetimes, the choices of energy storage devices can be limited, and the resulting stored energy is often comparable to the energy cost of sending or receiving a packet rather than the energy of operating the node for several days. And of course, some nodes will be line-powered.

産業環境における無線LLNノードは、さまざまなソースによって供給されます。少なくとも5年以上の寿命が要求されるバッテリ駆動デバイスは、最も一般的です。バッテリーは、デバイスがその総エネルギーのキャップを持っており、通常、残りのエネルギーの推定値を報告することができ、そして一般的に短期平均消費電力に制約を持っていない操作しました。エネルギー捕捉デバイスは、より複雑です。これらのシステムは、パワー捕捉装置(例えば太陽のような、振動、または温度差)と、このような二次電池やキャパシタなどのエネルギー貯蔵装置の両方を含みます。これらのシステムは、従って、(平均は同じ間隔にわたって電力を掃気超えることができない)の長期平均電力消費量ならびにエネルギー貯蔵要件によって課される短期の制限の両方に限界があります。ソーラーシステムの場合、エネルギー貯蔵システムは、一般的に、太陽光の非存在下で電力の日を提供するように設計されます。多くの工業用センサ4-20 mAの電流ループの流出、およびそのソースからミリワットのオーダーで捕捉することができます。振動監視システムは、典型的にのみマイクロワットの数十又は数百を提供する振動捕捉のための自然な選択です。工業用温度範囲および所望の寿命に起因して、エネルギー蓄積装置の選択が制限されることができ、得られた蓄積されたエネルギーは、多くの場合、送信または数日間ノードを動作させるエネルギーではなく、パケットを受信したエネルギーコストに匹敵します。そしてもちろん、いくつかのノードは、回線給電されます。

Example 1: solar panel, lead-acid battery sized for two weeks of rain.

実施例1:太陽電池パネル、鉛蓄電池は、雨の二週間のための大きさ。

Example 2: vibration scavenger, 1 mF tantalum capacitor.

実施例2:振動スカベンジャー、1個のmFでのタンタルコンデンサ。

Field devices have limited resources. Low-power, low-cost devices have limited memory for storing route information. Typical field devices will have a finite number of routes they can support for their embedded sensor/actuator application and for forwarding other devices packets in a mesh network slotted-link.

フィールドデバイスは、リソースが限られています。低消費電力、低コストのデバイスは、ルート情報を記憶するためのメモリが限られています。典型的なフィールド装置は、彼らが彼らの埋め込みセンサ/アクチュエータ・アプリケーションのためにサポートすることができる経路の有限数を有し、メッシュネットワーク内の他のデバイスにパケットを転送するためのスロット付きリンクをあろう。

Users may strongly prefer that the same device have different lifetime requirements in different locations. A sensor monitoring a non-critical parameter in an easily accessed location may have a lifetime requirement that is shorter and may tolerate more statistical variation than a mission-critical sensor in a hard-to-reach place that requires a plant shutdown in order to replace.

ユーザーが強く、同じデバイスが異なる場所で異なる寿命の要件を持っていることを好むかもしれません。簡単にアクセス場所に非重要なパラメータを監視センサーは短い生涯の要件を有することができ、交換するために、プラント停止を必要と手の届きにくい場所でミッションクリティカルなセンサーよりも統計的変動を許容します。

The routing algorithm MUST support node-constrained routing (e.g., taking into account the existing energy state as a node constraint). Node constraints include power and memory, as well as constraints placed on the device by the user, such as battery life.

ルーティングアルゴリズムは、ノード制約ルーティングをサポートしなければならない(例えば、ノードの制約として考慮既存のエネルギー状態を取ります)。ノード上の制約は、電力及びメモリ、並びにバッテリ寿命としてユーザがデバイス上に配置された制約を含みます。

7. Broadcast/Multicast Requirements
7.ブロードキャスト/マルチキャストの要件

Some existing industrial plant applications do not use broadcast or multicast addressing to communicate to field devices. Unicast address support is sufficient for them.

いくつかの既存の工業プラントアプリケーションは、フィールドデバイスと通信するためのアドレス指定ブロードキャストやマルチキャストを使用しないでください。ユニキャストアドレスのサポートは、彼らのために十分です。

In some other industrial process automation environments, multicast over IP is used to deliver to multiple nodes that may be functionally similar or not. Example usages are:

いくつかの他の工業プロセスの自動化環境では、IP上のマルチキャストは、機能的に類似であってもなくてもよい複数のノードに送達するために使用されます。例の使用法は以下のとおりです。

1) Delivery of alerts to multiple similar servers in an automation control room. Alerts are multicast to a group address based on the part of the automation process where the alerts arose (e.g., the multicast address "all-nodes-interested-in-alerts-for-process-unit-X"). This is always a restricted-scope multicast, not a broadcast.

1)自動化制御室で複数の類似のサーバーへのアラートの配信を。警告は、警告(例えば、マルチキャストアドレス「全ノード・興味・イン・アラート・用プロセスユニット-X」)を生じた自動化プロセスの一部に基づいて、グループアドレスにマルチキャストされます。これは、常に制限スコープのマルチキャスト、ブロードキャストではないです。

2) Delivery of common packets to multiple routers over a backbone, where the packets result in each receiving router initiating multicast (sometimes as a full broadcast) within the LLN. For instance, this can be a byproduct of having potentially physically separated backbone routers that can inject messages into different portions of the same larger LLN.

パケットがLLN以内、時には完全な放送として各受信ルータ開始マルチキャスト()をもたらすバックボーン上に複数のルータに共通のパケット2)配達。例えば、これは、同じ大きなLLNの異なる部分にメッセージを注入することができ、潜在的に、物理的に分離されたバックボーンルータを有する副生成物であることができます。

3) Publication of measurement data to more than one subscriber. This feature is useful in some peer-to-peer control applications. For example, level position may be useful to a controller that operates the flow valve and also to the overfill alarm indicator. Both controller and alarm indicator would receive the same publication sent as a multicast by the level gauge.

複数の加入者への測定データの3)出版。この機能は、一部のピア・ツー・ピア・制御アプリケーションに有用です。例えば、レベルの位置は、オーバーフィルアラームインジケータにも流れ弁を操作して、制御装置に有用であり得ます。両方のコントローラとアラームインジケータは、レベルゲージによってマルチキャストとして送信された同一の文書を受け取ることになります。

All of these uses require an 1:N security mechanism as well; they aren't of any use if the end-to-end security is only point-to-point.

これらの用途の全ては1が必要です:だけでなくNのセキュリティメカニズムを、エンドツーエンドのセキュリティは、ポイントツーポイントのみである場合、彼らは、任意の使用ではありません。

It is quite possible that first-generation wireless automation field networks can be adequately useful without either of these capabilities, but in the near future, wireless field devices with communication controllers and protocol stacks will require control and configuration, such as firmware downloading, that may benefit from broadcast or multicast addressing.

ことが、そのようなファームウェアのダウンロードとして、第一世代の無線自動化フィールドネットワークは、これらの機能のいずれかせずに十分に有用であり得ることはかなり可能であるが、近い将来、通信コントローラとプロトコルスタックとの間で無線フィールド機器は制御および構成を必要としますブロードキャストまたはマルチキャストアドレッシングの恩恵を受ける。

The routing protocol SHOULD support multicast addressing.

ルーティングプロトコルは、マルチキャストアドレッシングをサポートしなければなりません。

8. Protocol Performance Requirements
8.プロトコルのパフォーマンス要件

The routing protocol MUST converge after the addition of a new device within several minutes, and SHOULD converge within tens of seconds such that a device is able to establish connectivity to any other point in the network or determine that there is a connectivity issue. Any routing algorithm used to determine how to route packets in the network, MUST be capable of routing packets to and from a newly added device within several minutes of its addition, and SHOULD be able to perform this function within tens of seconds.

ルーティングプロトコルは、数分以内に、新たな装置の追加後に収束しなければならない、デバイスがネットワーク内の他のポイントへの接続を確立するか、接続の問題があると判断することができるように、数十秒以内に収束するべきです。任意のルーティング・アルゴリズムは、ネットワークに、その添加の数分以内に新たに追加されたデバイスからのパケットをルーティングすることができなければなりませんどのようにルーティングパケットを決定するために使用され、数十秒以内にこの機能を実行することができるべきです。

The routing protocol MUST distribute sufficient information about link failures to enable traffic to be routed such that all service requirements (especially latency) continue to be met. This places a requirement on the speed of distribution and convergence of this information as well as the responsiveness of any routing algorithms used to determine how to route packets. This requirement only applies at normal link failure rates (see Section 5) and MAY degrade during failure storms.

ルーティングプロトコルは、(特に、待ち時間)すべてのサービス要件が満たされ続けるようにルーティングされるトラフィックを有効にするために、リンク障害に関する十分な情報を配布する必要があります。これは、この情報の分布と収束の速度に要件ならびにどのルートパケットに決定するために使用される任意のルーティングアルゴリズムの応答を置きます。この要件は、通常のリンク故障率で適用されます(セクション5を参照)、故障の嵐の間に低下することがあります。

Any algorithm that computes routes for packets in the network MUST be able to perform route computations in advance of needing to use the route. Since such algorithms are required to react to link failures, link usage information, and other dynamic link properties as the information is distributed by the routing protocol, the algorithms SHOULD recompute route based on the receipt of new information.

ネットワークにおけるパケットのルートを計算する任意のアルゴリズムは、ルートを使用する必要の事前にルート計算を実行できなければなりません。情報は、ルーティングプロトコルによって分配されるようなアルゴリズムは、リンク障害、リンク利用情報、および他のダイナミックリンク特性に反応するために必要とされるので、アルゴリズムは、新たな情報の受領に基づいてルートを再計算すべきです。

9. Mobility Requirements
9.モビリティの要件

Various economic factors have contributed to a reduction of trained workers in the industrial plant. A very common problem is that of the "wireless worker". Carrying a PDA or something similar, this worker will be able to accomplish more work in less time than the older, better-trained workers that he or she replaces. Whether the premise is valid, the use case is commonly presented: the worker will be wirelessly connected to the plant IT system to download documentation, instructions, etc., and will need to be able to connect "directly" to the sensors and control points in or near the equipment on which he or she is working. It is possible that this "direct" connection could come via the normal LLNs data collection network. This connection is likely to require higher bandwidth and lower latency than the normal data collection operation.

様々な経済的要因は、産業プラントで訓練を受けた労働者の削減に貢献してきました。非常に一般的な問題は、「無線従事者」のことです。 PDAまたは類似のものを運ぶ、この作業員は彼または彼女が置き換えられていること、古い、よりよく訓練された労働者よりも短い時間でより多くの仕事を達成することができるようになります。労働者は、ワイヤレスなどのドキュメント、命令をダウンロードするには、プラントのITシステムに接続され、センサーと制御点に「直接」接続できるようにする必要があります。前提が有効かどうか、ユースケースは、一般的に提示されます彼または彼女が作業している機器または周辺。この「直接」接続が正常LLNsデータ収集ネットワークを経由して来る可能性があります。この接続は、通常のデータ収集時よりも高い帯域幅と低遅延を必要とする可能性が高いです。

PDAs are typically used as the user interfaces for plant historians, asset management systems, and the like. It is undecided if these PDAs will use the LLN directly to talk to field sensors, or if they will rather use other wireless connectivity that proxies back into the field or to anywhere else.

PDAのは、典型的には、プラントヒストリアン、資産管理システム、等のユーザインターフェイスとして使用されます。彼らはむしろバックフィールドにまたはどこか他のプロキシ他のワイヤレス接続を使用する場合は、これらのPDAは、または、フィールドセンサーに話を直接LLNを使用する場合は未定です。

The routing protocol SHOULD support the wireless worker with fast network connection times of a few of seconds, and low command and response latencies to the plant behind the LLN access points, to applications, and to field devices. The routing protocol SHOULD also support the bandwidth allocation for bulk transfers between the field device and the handheld device of the wireless worker. The routing protocol SHOULD support walking speeds for maintaining network connectivity as the handheld device changes position in the wireless network.

ルーティングプロトコルは、アプリケーションに、LLNアクセスポイントの背後にある工場に秒数の高速ネットワーク接続時間との無線従事者、および低コマンドと応答レイテンシをサポートする必要があり、デバイスをフィールドします。ルーティングプロトコルは、フィールド装置と無線作業者の携帯デバイスとの間のバルク転送のための帯域幅割り当てをサポートしなければなりません。ルーティングプロトコルは、ハンドヘルドデバイス、無線ネットワーク内の位置を変更するようにネットワーク接続を維持するための歩行速度をサポートしなければなりません。

Some field devices will be mobile. These devices may be located on moving parts such as rotating components, or they may be located on vehicles such as cranes or fork lifts. The routing protocol SHOULD support vehicular speeds of up to 35 kmph.

いくつかのフィールドデバイスは、モバイルになります。これらのデバイスは、そのような構成要素を回転させるような可動部品上に配置することができる、またはそれらは、クレーンやフォークリフト等の車両上に配置することができます。ルーティングプロトコルは、最大35 kmphの車両速度をサポートしなければなりません。

10. Manageability Requirements
10.管理性の要件

The process and control industry is manpower constrained. The aging demographics of plant personnel are causing a looming manpower problem for industry across many markets. The goal for the industrial networks is to have the installation process not require any new skills for the plant personnel. The person would install the wireless sensor or wireless actuator the same way the wired sensor or wired actuator is installed, except the step to connect wire is eliminated.

プロセスおよびコントロール業界は人材制約があります。プラント要員の高齢化人口は多くの市場での業界のために迫り来るマンパワーの問題を引き起こしています。産業用ネットワークのための目標は、インストールプロセスがプラント要員のための新たなスキルを必要としないことです。ワイヤを接続する工程が排除される以外の人は、有線センサまたは有線アクチュエータが取り付けられているのと同じ方法、無線センサー又は無線アクチュエータを取り付けることになります。

Most users in fact demand even much further simplified provisioning methods, a plug and play operation that would be fully transparent to the user. This requires availability of open and untrusted side channels for new joiners, and it requires strong and automated authentication so that networks can automatically accept or reject new joiners. Ideally, for a user, adding new routing devices should be as easy as dragging and dropping an icon from a pool of authenticated new joiners into a pool for the wired domain that this new sensor should connect to. Under the hood, invisible to the user, auditable security mechanisms should take care of new device authentication, and secret join key distribution. These more sophisticated 'over the air' secure provisioning methods should eliminate the use of traditional configuration tools for setting up devices prior to being ready to securely join an LLN access point.

実際の需要のほとんどのユーザーも、更に多くの簡略化、プロビジョニングの方法、ユーザーに対して完全に透過的になり、プラグアンドプレイ操作。これは、新しいジョイナのためのオープンで信頼されていない側のチャンネルの可用性を必要とし、ネットワークは自動的に新しいジョイナを受け入れるか拒否することができるように、それは強く、自動化された認証が必要です。理想的には、ユーザのために、新たなルーティング・デバイスを追加すると、この新しいセンサが接続することが有線ドメインのプールに認証された新たなジョイナーのプールからアイコンをドラッグアンドドロップと同じくらい簡単であるべきです。ボンネットの下に、ユーザーには見えない、監査可能なセキュリティメカニズムは、新しいデバイス認証の世話をし、秘密鍵の配布に参加する必要があります。 「空中」これらのより洗練された、安全なプロビジョニング方法はしっかりLLNアクセスポイントに参加する準備ができている前にデバイスを設定するための伝統的なコンフィギュレーション・ツールの使用を排除する必要があります。

The routing protocol SHOULD be fully configurable over the air as part of the joining process of a new routing device.

ルーティングプロトコルは、新しいルーティングデバイスの接合プロセスの一部として、空気にわたって完全に構成可能であるべきです。

There will be many new applications where even without any human intervention at the plant, devices that have never been on site before, should be allowed, based on their credentials and cryptographic capabilities, to connect anyway. Examples are third-party road tankers, rail cargo containers with overfill protection sensors, or consumer cars that need to be refueled with hydrogen by robots at future fueling stations.

とにかく接続するには、さえ工場のいずれかの人間の介入なしに、前のサイトに行ったことがないデバイスは、自分の資格情報と暗号化機能に基づいて、許可されなければならない多くの新たな用途があります。例としては、サードパーティの道路タンカー、過充填防止センサを備えた鉄道貨物コンテナ、または将来給油ステーションでロボットが水素で燃料補給する必要がある消費者の自動車です。

The routing protocol for LLNs is expected to be easy to deploy and manage. Because the number of field devices in a network is large, provisioning the devices manually may not make sense. The proper operation of the routing protocol MAY require that the node be commissioned with information about itself, like identity, security tokens, radio standards and frequencies, etc.

LLNsのためのルーティングプロトコルは、導入と管理が容易なことが期待されます。ネットワーク内のフィールドデバイスの数が多いため、デバイスを手動でプロビジョニングすることは意味を持たないかもしれません。ルーティングプロトコルの適切な動作は、ノードがなどのアイデンティティ、セキュリティトークン、無線規格と周波数のように、自身に関する情報を委託することを要求することができます

The routing protocol SHOULD NOT require to preprovision information about the environment where the node will be deployed. The routing protocol MUST enable the full discovery and setup of the environment (available links, selected peers, reachable network). The protocol MUST enable the distribution of its own configuration to be performed by some external mechanism from a centralized management controller.

ルーティングプロトコルは、ノードが展開される環境に関する情報を事前にプロビジョニングする必要はありません。ルーティングプロトコルは、環境(使用可能なリンク、選択されたピア、到達可能なネットワーク)の完全な検出と設定を有効にする必要があります。プロトコルは、集中管理コントローラからの何らかの外部機構によって実行される独自の構成の配布を有効にする必要があります。

11. Antagonistic Requirements
11.拮抗要件

This document contains a number of strongly required constraints on the ROLL routing protocol. Some of those strong requirements might appear antagonistic and, as such, impossible to fulfill at the same time.

この文書では、ROLLのルーティングプロトコルに強く要求された制約の数が含まれています。これらの強力な要件のいくつかは、同時に満たすことが拮抗して、など、不可能表示される場合があります。

For instance, the strong requirement of power economy applies on general routing but is variant since it is reasonable to spend more energy on ensuring the availability of a short emergency closed-loop path than it is to maintain an alert path that is used for regular updates on the operating status of the device. In the same fashion, the strong requirement on easy provisioning does not match easily the strong security requirements that can be needed to implement a factory policy. Then again, a non-default non-trivial setup can be acceptable as long as the default configuration enables a device to join with some degree of security.

それは定期的に更新するために使用されているアラートのパスを維持するよりも、短い緊急閉ループパスの可用性を確保する上でより多くのエネルギーを費やすことが妥当であるため、例えば、電源経済の強力な要件は、一般的なルーティングに適用されるが、変異体であり、デバイスの動作状態に。同じ方法で、簡単にプロビジョニングに強い要件は、簡単に工場出荷時のポリシーを実装するために必要なことができる、強力なセキュリティ要件と一致していません。その後、再び、デフォルト以外の非自明なセットアップがいる限り、デフォルトの設定では、セキュリティのいくつかの学位を取得して参加するデバイスを可能として許容することができます。

Convergence time and network size are also antagonistic. The values expressed in Section 8 ("Protocol Performance Requirements") apply to an average network with tens of devices. The use of a backbone can maintain that level of performance and still enable to grow the network to thousands of node. In any case, it is acceptable to grow reasonably the convergence time with the network size.

収束時間とネットワークサイズも拮抗しています。セクション8において発現値(「プロトコル性能要件」)は、デバイスの数十と平均ネットワークに適用されます。バックボーンを使用すると、パフォーマンスのレベルを維持し、まだノードの数千人にネットワークを成長させる有効にすることができます。いずれにせよ、ネットワークサイズで合理的に収束時間を成長させることが可能です。

12. Security Considerations
12.セキュリティの考慮事項

Given that wireless sensor networks in industrial automation operate in systems that have substantial financial and human safety implications, security is of considerable concern. Levels of security violation that are tolerated as a "cost of doing business" in the banking industry are not acceptable when in some cases literally thousands of lives may be at risk.

産業オートメーションにおける無線センサネットワークが実質的な金融・人間安全意味合いを持つシステムで動作していることを考えると、セキュリティはかなりの懸念です。いくつかのケースでは命の文字通り何千人が危険にさらされる可能性があるとき、銀行業界では「事業を行うためのコスト」として容認されているセキュリティ違反のレベルは許容できません。

Security is easily confused with guarantee for availability. When discussing wireless security, it's important to distinguish clearly between the risks of temporarily losing connectivity, say due to a thunderstorm, and the risks associated with knowledgeable adversaries attacking a wireless system. The conscious attacks need to be split between 1) attacks on the actual application served by the wireless devices and 2) attacks that exploit the presence of a wireless access point that may provide connectivity onto legacy wired plant networks, so these are attacks that have little to do with the wireless devices in the LLNs. In the second type of attack, access points that might be wireless backdoors that allow an attacker outside the fence to access typically non-secured process control and/or office networks are typically the ones that do create exposures where lives are at risk. This implies that the LLN access point on its own must possess functionality that guarantees domain segregation, and thus prohibits many types of traffic further upstream.

セキュリティを簡単に利用できるための保証と混同されます。ワイヤレスセキュリティを議論するとき、それは、一時的な接続を失うことのリスクとの間で明確に区別することが重要だ雷雨のために言うと、無線システムを攻撃する知識豊富な敵に伴うリスク。意識のある攻撃は、無線デバイスとレガシー有線植物ネットワークに接続性を提供することができる無線アクセスポイントの存在を利用2)攻撃によってサービス実際のアプリケーションに対する攻撃)1の間で分割する必要があるので、これらはほとんどない攻撃でありますLLNsの無線デバイスとすることができません。攻撃の第二のタイプでは、フェンスの外の攻撃者は、典型的には、非セキュアなプロセス制御および/またはオフィスのネットワークにアクセスすることを可能にする無線バックドアであるかもしれないアクセスポイントは、通常の命が危険にさらされているエクスポージャーを作成するのですものです。これは、自分自身でLLNアクセスポイントは、ドメイン分離を保証し、したがって、さらに上流のトラフィックの多くの種類を禁止機能を持っていなければならないことを意味します。

The current generation of industrial wireless device manufacturers is specifying security at the MAC (Media Access Control) layer and the transport layer. A shared key is used to authenticate messages at the MAC layer. At the transport layer, commands are encrypted with statistically unique randomly generated end-to-end session keys. HART7 [IEC62591] and ISA100.11a are examples of security systems for industrial wireless networks.

産業用無線機器メーカーの現在の世代は、MAC(Media Access Control)層とトランスポート層でセキュリティを指定しています。共有キーは、MACレイヤでメッセージを認証するために使用されます。トランスポート層では、コマンドは、統計的にユニークなランダムに生成されたエンドツーエンドのセッション鍵で暗号化されています。 HART7 [IEC62591]及びISA100.11aのは、工業用無線ネットワークのためのセキュリティシステムの例です。

Although such symmetric key encryption and authentication mechanisms at MAC and transport layers may protect reasonably well during the lifecycle, the initial network boot (provisioning) step in many cases requires more sophisticated steps to securely land the initial secret keys in field devices. Also, it is vital that during these steps, the ease of deployment and the freedom of mixing and matching products from different suppliers does not complicate life for those that deploy and commission. Given the average skill levels in the field and the serious resource constraints in the market, investing a little bit more in sensor-node hardware and software so that new devices automatically can be deemed trustworthy, and thus automatically join the domains that they should join, with just one drag-and-drop action for those in charge of deploying, will yield faster adoption and proliferation of the LLN technology.

MAC層とトランスポート層では、このような対称鍵暗号化および認証メカニズムは、ライフサイクルの間に合理的に保護するかもしれないが、多くの場合、最初のネットワークブート(プロビジョニング)のステップは、安全フィールドデバイスに初期秘密鍵を着陸させるより洗練された手順が必要です。また、これらの工程の間に、導入のしやすさと異なるサプライヤーからの製品を混合し、マッチングの自由が展開するものと、委員会のために人生を複雑にしないことが重要です。新しいデバイスを自動的に信頼できると考えることができるように、複数のセンサノードのハードウェアとソフトウェアで少し投資し、市場でのフィールドでの平均的なスキルレベルと深刻な資源の制約を考えると、これにより自動的に、彼らが参加すべきドメインに参加し、展開の担当者のためのちょうど1ドラッグ・アンド・ドロップ操作で、より高速な採用とLLN技術の普及を得られます。

Industrial plants may not maintain the same level of physical security for field devices that is associated with traditional network sites such as locked IT centers. In industrial plants, it must be assumed that the field devices have marginal physical security and might be compromised. The routing protocol SHOULD limit the risk incurred by one node being compromised, for instance by proposing a non-congruent path for a given route and balancing the traffic across the network.

工業用植物は、このようなITを中心にロックのような伝統的なネットワークサイトに関連付けられているフィールドデバイスのための物理的なセキュリティの同じレベルを維持しない場合があります。産業プラントでは、フィールド機器が限界物理的なセキュリティを持っていると危険にさらされるかもしれないと仮定しなければなりません。ルーティングプロトコルは、所定のルートの非合同経路を提案し、ネットワーク全体のトラフィックのバランスをとることによって、例えば、危険にさらされている一つのノードが被るリスクを制限する必要があります。

The routing protocol SHOULD compartmentalize the trust placed in field devices so that a compromised field device does not destroy the security of the whole network. The routing MUST be configured and managed using secure messages and protocols that prevent outsider attacks and limit insider attacks from field devices installed in insecure locations in the plant.

ルーティングプロトコルは、標的のフィールド装置は、ネットワーク全体のセキュリティを破壊しないように、フィールド機器の信頼を区分すべきです。ルーティングが設定され、工場内の安全でない場所に設置フィールド機器から部外者攻撃やリミットインサイダー攻撃を防ぐ安全なメッセージとプロトコルを使用して管理しなければなりません。

The wireless environment typically forces the abandonment of classical 'by perimeter' thinking when trying to secure network domains. Wireless nodes in LLN networks should thus be regarded as little islands with trusted kernels, situated in an ocean of untrusted connectivity, an ocean that might be full of pirate ships. Consequently, confidence in node identity and ability to challenge authenticity of source node credentials gets more relevant. Cryptographic boundaries inside devices that clearly demark the border between trusted and untrusted areas need to be drawn. Protection against compromise of the cryptographic boundaries inside the hardware of devices is outside of the scope of this document.

ネットワークドメインを確保しようとすると、無線環境は、一般的な思考「の周囲で」古典の放棄を強制します。 LLNネットワークの無線ノードは、このように信頼できない接続、海賊船の完全であるかもしれない海の海に位置し、信頼できるカーネルではほとんどの島、とみなされるべきです。その結果、ソースノードの資格情報の信憑性に挑戦するノードのアイデンティティと能力に自信がより適切な取得します。明確に信頼できると信頼されていない領域の境界をデマーク方式の装置内部の暗号境界を描画する必要があります。デバイスのハードウェア内部の暗号境界の妥協に対する保護は、この文書の範囲外です。

Note that because nodes are usually expected to be capable of routing, the end-node security requirements are usually a superset of the router requirements, in order to prevent a end node from being used to inject forged information into the network that could alter the plant operations.

ノードは通常、ルーティングすることができると予想されるので、エンドノードのセキュリティ要件は、プラントを変えることができ、ネットワークに偽造情報を注入するために使用されるのエンドノードを防止するために、通常、ルータ要件のスーパーセットであることに注意してくださいオペレーション。

Additional details of security across all application scenarios are provided in the ROLL security framework [ROLL-SEC-FMWK]. Implications of these security requirements for the routing protocol itself are a topic for future work.

すべてのアプリケーション・シナリオ全体でセキュリティの追加の詳細は、ROLLのセキュリティフレームワーク[ROLL-SEC-FMWK]で提供されています。ルーティングプロトコル自体のこれらのセキュリティ要件の意味は、将来の仕事のためのトピックです。

13. Acknowledgements
13.謝辞

Many thanks to Rick Enns, Alexander Chernoguzov, and Chol Su Kang for their contributions.

彼らの貢献のためのリック・エンス、アレクサンダーChernoguzov、およびCholで蘇カンに感謝します。

14. References
14.参考文献
14.1. Normative References
14.1. 引用規格

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

14.2. Informative References
14.2. 参考文献

[HART] HART (Highway Addressable Remote Transducer) Communication Foundation, "HART Communication Protocol and Foundation - Home Page", <http://www.hartcomm.org>.

[HART] HART(ハイウェイアドレス可能リモートトランスデューサ)コミュニケーション財団、 "HART通信プロトコルと基礎 - ホームページ"、<http://www.hartcomm.org>。

[IEC61158] IEC, "Industrial communication networks - Fieldbus specifications", IEC 61158 series.

【IEC61158] IEC、 "工業通信ネットワーク - フィールドバス仕様"、IEC 61158シリーズ。

[IEC62591] IEC, "Industrial communication networks - Wireless communication network and communication profiles - WirelessHART", IEC 62591.

【IEC62591] IEC、 "工業通信ネットワーク - 無線通信ネットワークと通信プロファイル - たWirelessHART"、IEC 62591。

[IEEE802.15.4] IEEE, "Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE 802.15.4, 2006.

[IEEE802.15.4] IEEE、「電気通信及びシステム間情報交換 - 特定の要件パート15.4 - 地方とメトロポリタンエリアネットワーク:低レートの無線パーソナルエリアネットワークのための無線媒体アクセス制御(MAC)および物理層(PHY)の仕様(WPANは)」、IEEE 802.15.4、2006。

[ISA100.11a] ISA, "Wireless systems for industrial automation: Process control and related applications", ISA 100.11a, May 2008, <http://www.isa.org/ Community/SP100WirelessSystemsforAutomation>.

[ISA100.11aの] ISA、 "産業オートメーション用無線システム:プロセス制御および関連アプリケーション"、ISAの100.11a、2008年5月、<http://www.isa.org/コミュニティ/ SP100WirelessSystemsforAutomation>。

[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]クシャルナガル、N.、モンテネグロ、G.、およびC.シューマッハ、 "低消費電力無線パーソナルエリアネットワーク(6LoWPANs)以上のIPv6:概要、仮定、問題文、および目標"、RFC 4919、2007年8月。

[ROLL-SEC-FMWK] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", Work in Progress, September 2009.

[ROLL-SEC-FMWK] Tsaoさん、T.、アレクサンダー、R.、のDohler、M.、ダサ、V.、およびA.ロサノ、進行中で働いて "低消費電力とロッシーネットワーク経由のルーティングのためのセキュリティフレームワーク"、 2009年9月。

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

[ROLL-TERM] Vasseur、JP。、 "低消費電力、ロッシーネットワークにおける用語"、進歩、2009年10月に作業。

Authors' Addresses

著者のアドレス

Kris Pister (editor) Dust Networks 30695 Huntwood Ave. Hayward, CA 94544 USA

クリスピスター教授(エディタ)ダストネットワークス30695 Huntwoodアベニュー。ヘイワード、CA 94544 USA

EMail: kpister@dustnetworks.com

メールアドレス:kpister@dustnetworks.com

Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE

Thubertパスカル(編集者)、シスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3ビオ - ソフィアアンティポリス06410 FRANCE

Phone: +33 497 23 26 34 EMail: pthubert@cisco.com

電話:+33 497 23 26 34 Eメール:pthubert@cisco.com

Sicco Dwars Shell Global Solutions International B.V. Sir Winston Churchilllaan 299 Rijswijk 2288 DC Netherlands

Siccoクロスシェル・グローバル・ソリューションズ・インターナショナルBVウィンストン・チャーチル卿アベニュー299 2288 DCライスワイク、オランダ

Phone: +31 70 447 2660 EMail: sicco.dwars@shell.com

電話:+31 70 447 2660 Eメール:sicco.dwars@shell.com

Tom Phinney Consultant 5012 W. Torrey Pines Circle Glendale, AZ 85308-3221 USA

トム・フィニーコンサルタント5012 W.トーリーパインズサークルグレンデール、アリゾナ州85308から3221 USA

Phone: +1 602 938 3163 EMail: tom.phinney@cox.net

電話:+1 602 938 3163 Eメール:tom.phinney@cox.net