[要約] RFC 6574は、スマートオブジェクトワークショップの報告書であり、スマートオブジェクトの利用と展開に関する洞察と提案を提供しています。このRFCの目的は、スマートオブジェクトの技術的な課題と潜在的な利点を理解し、インターネット上でのスマートオブジェクトの普及を促進することです。
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 6574 J. Arkko
Category: Informational April 2012
ISSN: 2070-1721
Report from the Smart Object Workshop
スマートオブジェクトワークショップからのレポート
Abstract
概要
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
このドキュメントでは、インターネットアーキテクチャボード（IAB）が開催する「スマートオブジェクトとインターネットの相互接続」に関するワークショップの概要について説明します。ワークショップは2011年3月25日にプラハで開催されました。ワークショップの主な目的は、IETFプロトコルを制約された環境に展開した経験について、幅広いコミュニティからフィードバックを求めることでした。このレポートは、議論を要約し、インターネット技術特別調査委員会（IETF）コミュニティへの結論と推奨事項を示しています。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6574.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6574で入手できます。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 5
3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 6
3.1.2. Domain-Specific Stacks and Profiles . . . . . . . . . 8
3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 9
3.2. Sleeping Nodes . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 25
Appendix B. Workshop Materials . . . . . . . . . . . . . . . . . 25
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 25
Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 30
Appendix E. IAB Members at the Time of Approval . . . . . . . . . 32
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。 IABのこの長期計画機能は、インターネットエンジニアリングステアリンググループ（IESG）と地域のディレクターのリーダーシップの下で、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループによって実行されているエンジニアリングの取り組みを補完します。
Today's Internet is experienced by users as a set of applications, such as email, instant messaging, and services on the Web. While these applications do not require users to be present at the time of service execution, in many cases they are. There are also substantial differences in performance among the various end devices, but in general end devices participating in the Internet are considered to have high performance.
今日のインターネットは、電子メール、インスタントメッセージング、Web上のサービスなどの一連のアプリケーションとしてユーザーに体験されています。これらのアプリケーションでは、サービスの実行時にユーザーが存在する必要はありませんが、多くの場合は存在します。また、さまざまなエンドデバイスのパフォーマンスには大きな違いがありますが、一般に、インターネットに参加しているエンドデバイスは高いパフォーマンスを持つと見なされています。
There are, however, a large number of deployed embedded devices, and there is substantial value in interconnecting them with the Internet. The term "Internet of Things" denotes a trend where a large number of devices employ communication services offered by the Internet protocols. Many of these devices are not directly operated by humans, but exist as components in buildings or vehicles, or are spread out in the environment. There is a large variation in the computing power, available memory, (electrical) power, and communications bandwidth between different types of devices.
ただし、導入された組み込みデバイスは多数あり、それらをインターネットと相互接続することには大きな価値があります。 「モノのインターネット」という用語は、多数のデバイスがインターネットプロトコルによって提供される通信サービスを採用する傾向を示しています。これらのデバイスの多くは、人間が直接操作するのではなく、建物や車両のコンポーネントとして存在するか、環境中に広がっています。異なるタイプのデバイス間では、計算能力、使用可能なメモリ、（電力）電力、および通信帯域幅に大きな変動があります。
Many of these devices offer a range of new possibilities or provide additional value for previously unconnected devices. Some devices have been connected using proprietary communication networks in the past but are now migrating to the use of the Internet Protocol suite in order to share the same communication network between all applications and to enable rich communications services.
これらのデバイスの多くは、さまざまな新しい可能性を提供するか、以前接続されていなかったデバイスに付加価値を提供します。一部のデバイスは過去に独自の通信ネットワークを使用して接続されていましたが、現在、すべてのアプリケーション間で同じ通信ネットワークを共有し、豊富な通信サービスを可能にするために、インターネットプロトコルスイートの使用に移行しています。
Much of this development can simply run on existing Internet protocols. For instance, home entertainment and monitoring systems often offer a Web interface to the end user. In many cases the new, constrained environments can benefit from additional protocols and protocol extensions that help optimize the communications and lower the computational requirements. Examples of currently ongoing standardization efforts targeted for these environments include the Constrained RESTful Environments (CoRE), IPv6 over Low power WPAN (6LoWPAN), Routing Over Low power and Lossy networks (ROLL), and the Light-Weight Implementation Guidance (LWIG) working groups of the IETF.
この開発の多くは、単に既存のインターネットプロトコルで実行できます。たとえば、ホームエンターテインメントおよび監視システムは、多くの場合、エンドユーザーにWebインターフェイスを提供します。多くの場合、制約のある新しい環境は、通信の最適化と計算要件の軽減に役立つ追加のプロトコルとプロトコル拡張の恩恵を受けることができます。これらの環境を対象とした現在進行中の標準化の取り組みの例には、制約付きRESTful環境（CoRE）、低電力WPANを介したIPv6（6LoWPAN）、低電力および損失の多いネットワークを介したルーティング（ROLL）、および軽量実装ガイダンス（LWIG）の動作が含まれますIETFのグループ。
This workshop explored the experiences of researchers and developers when considering the characteristics of constrained devices. Engineers know that many design considerations need to be taken into account when developing protocols and architecture. Balancing between the conflicting goals of code size, economic incentives, power consumption, usability, and security is often difficult, as illustrated by Clark et al. in "Tussle in Cyberspace: Defining Tomorrow's Internet" [Tussle].
このワークショップでは、制約のあるデバイスの特性を検討する際に、研究者と開発者の経験を調査しました。エンジニアは、プロトコルとアーキテクチャを開発するときに、多くの設計上の考慮事項を考慮する必要があることを知っています。コードサイズ、経済的インセンティブ、電力消費、使いやすさ、およびセキュリティの相反する目標の間でバランスを取ることは、Clark et al。 「サイバースペースの闘い：明日のインターネットを定義する」[Tussle]。
Participants at the workshop discussed the experience and approaches taken when designing protocols and architectures for interconnecting smart objects to the Internet. The scope of the investigations included constrained nodes as well as constrained networks.
ワークショップの参加者は、スマートオブジェクトをインターネットに相互接続するためのプロトコルとアーキテクチャを設計する際の経験とアプローチについて話し合いました。調査の範囲には、制約付きノードと制約付きネットワークが含まれていました。
The call for position papers suggested investigating the area of integration with the Internet in the following categories:
ポジションペーパーの募集では、次のカテゴリでインターネットとの統合の領域を調査することを提案しました。
o Scalability
o スケーラビリティ
o Power efficiency
o 電力効率
o Interworking between different technologies and network domains
o 異なるテクノロジーとネットワークドメイン間の相互作用
o Usability and manageability
o 使いやすさと管理性
o Security and privacy
o セキュリティとプライバシー
The goals of the workshop can be summarized as follows:
ワークショップの目的は次のように要約できます。
As many deployed smart objects demonstrate, running protocols like the Internet Protocol Version 4 [RFC0791] and Version 6 [RFC2460], the User Datagram Protocol (UDP) [RFC0768], the Transmission Control Protocol (TCP) [RFC0793], the Hypertext Transfer Protocol (HTTP) [RFC2616], etc., on constrained devices is clearly possible. Still, protocol designers, system architects, and developers have to keep various limitations in mind. The organizers were interested to discuss the experience with deploying IETF protocols in different constrained environments.
デプロイされた多くのスマートオブジェクトが示すように、インターネットプロトコルバージョン4 [RFC0791]やバージョン6 [RFC2460]、ユーザーデータグラムプロトコル（UDP）[RFC0768]、伝送制御プロトコル（TCP）[RFC0793]、ハイパーテキスト転送などの実行プロトコル制約のあるデバイスでのプロトコル（HTTP）[RFC2616]などは明らかに可能です。それでも、プロトコル設計者、システムアーキテクト、および開発者は、さまざまな制限に留意する必要があります。主催者は、さまざまな制約のある環境でIETFプロトコルを展開した経験について話し合うことに興味を持っていました。
Furthermore, the organizers were seeking to identify issues either where current implementers do not yet have solutions or where researchers predict potential issues.
さらに、主催者は、現在の実装者がまだ解決策を持っていない場合、または研究者が潜在的な問題を予測している場合のいずれかに問題を特定することを求めていました。
The workshop served as a venue to identify problems and to discover common interests that may turn into new work or into changes in direction of already ongoing work at the IETF and or the Internet Research Task Force (IRTF).
ワークショップは、問題を特定し、IETFやInternet Research Task Force（IRTF）ですでに進行中の作業の方向性の変化や新しい作業に変わる可能性のある共通の関心事を発見する場として機能しました。
The workshop was spurred by the increasing presence of constrained devices on the network. It is quite natural to ask how these limitations impact the design of the affected nodes. Note that not all nodes suffer from the same set of limitations.
ワークショップは、ネットワーク上の制約されたデバイスの存在の増加に拍車がかかりました。これらの制限が影響を受けるノードの設計にどのように影響するかを尋ねることは非常に自然です。すべてのノードが同じ制限のセットの影響を受けるわけではないことに注意してください。
Energy constraints:
エネルギーの制約：
Since wireless communication can be a large portion of the power budget for wireless devices, reducing unnecessary communication can significantly increase the battery life of a low-end device. The choice of low-power radio can also significantly impact the overall energy consumption, as can sleeping periodically, when the device is not in use. In some cases, these nodes will only wake periodically to handle needed communications. This constraint is quite in contrast to the "always on" paradigm found in regular Internet hosts. Even in the case of non-battery operated devices, power is a constraint with respect to energy efficiency goals.
ワイヤレス通信はワイヤレスデバイスの電力バジェットの大部分を占める可能性があるため、不要な通信を削減することで、ローエンドデバイスのバッテリ寿命を大幅に延ばすことができます。低電力無線の選択は、デバイスが使用されていないときに定期的にスリープする場合と同様に、全体的なエネルギー消費にも大きな影響を与える可能性があります。場合によっては、これらのノードは必要な通信を処理するために定期的に起動するだけです。この制約は、通常のインターネットホストで見られる「常にオン」のパラダイムとはかなり対照的です。バッテリーで動作しないデバイスの場合でも、電力はエネルギー効率の目標に関する制約です。
Bandwidth constraints:
帯域幅の制約：
Various low-power radio networks offer only limited bandwidth, and show high packet loss as well as high link quality variability. The data transmission rates vary from 20 to 900 kilobits per second (e.g., in the case of IEEE 802.15.4). Nodes may be used in usually highly unstable radio environments. The physical-layer packet size may be limited (~100 bytes).
さまざまな低電力無線ネットワークは限られた帯域幅しか提供せず、高いパケット損失と高いリンク品質の変動性を示します。データ伝送速度は、毎秒20〜900キロビットです（IEEE 802.15.4の場合など）。ノードは通常、非常に不安定な無線環境で使用できます。物理層のパケットサイズは制限される場合があります（約100バイト）。
Memory constraints:
メモリの制約：
The amount of volatile and persistent storage impacts the program execution and has important implications for the functionality of the protocol stack. The Arduino UNO board, for example, provides a developer with 2 KB RAM and 32 KB flash memory (without any extensions, such as microSD cards).
揮発性で永続的なストレージの量はプログラムの実行に影響し、プロトコルスタックの機能に重要な影響を与えます。たとえば、Arduino UNOボードは、2 KBのRAMと32 KBのフラッシュメモリを（microSDカードなどの拡張機能なしで）開発者に提供します。
A system designer also needs to consider CPU constraints, which often relate to energy constraints: a processor with lower performance consumes less energy. As described later in this document, the design of the mainboard may allow certain components to be put to sleep to further lower energy consumption. In general, embedded systems are often purpose built with only the hardware components needed for the given task, while general-purpose personal computers are less constrained with regard to their mainboard layout and typically offer a huge number of optional plug-in peripherals to be connected. A factor that also has to be taken into consideration is the intended usage environment. For example, a humidity sensor deployed outside a building may need to deal with temperatures from -50 degrees C to +85 degrees C. There are often physical size limitations for smart objects. While traditional mainboards are rather large, such as the Advanced Technology eXtended (ATX) design with a board size of 305 x 244 mm available in many PCs or the mini-ITX design typically found in home theater PCs with 170 x 170 mm, mainboard layouts for embedded systems are typically much smaller, such as the CoreExpress layout with 58 x 65 mm, or even smaller. In addition to the plain mainboard, additional sensors, peripherals, a power adapter/battery, and a case have to be taken into consideration. Finally, there are cost restrictions as well.
システム設計者は、CPUの制約も考慮する必要があります。CPUの制約は、多くの場合エネルギーの制約に関連しています。パフォーマンスの低いプロセッサは、消費するエネルギーが少なくなります。このドキュメントの後半で説明するように、メインボードの設計により、特定のコンポーネントをスリープ状態にして、さらにエネルギー消費を抑えることができます。一般に、組み込みシステムは、特定のタスクに必要なハードウェアコンポーネントのみを使用して専用に構築されることがよくありますが、汎用のパーソナルコンピューターは、メインボードレイアウトの制約が少なく、接続できるオプションのプラグイン周辺機器が多数あります。 。また、考慮すべき要素は、使用目的の環境です。たとえば、建物の外に配置された湿度センサーは、-50℃〜+85℃の温度に対応する必要がある場合があります。スマートオブジェクトの物理的なサイズには制限があることがよくあります。多くのPCで利用可能な305 x 244 mmのボードサイズのAdvanced Technology eXtended（ATX）デザインや、170 x 170 mmのメインボードレイアウトのホームシアターPCで一般的に見られるmini-ITXデザインなど、従来のメインボードはかなり大きい組み込みシステムの場合、58 x 65 mmのCoreExpressレイアウトなど、通常ははるかに小さいか、さらに小さくなります。プレーンなメインボードに加えて、追加のセンサー、周辺機器、電源アダプター/バッテリー、およびケースを考慮する必要があります。最後に、コストの制限もあります。
The situation becomes more challenging when not only the hosts are constrained but also the network nodes themselves.
ホストだけでなくネットワークノード自体も制約されている場合、状況はより困難になります。
While there are constantly improvements being made, Moore's law tends to be less effective in the embedded system space than in personal computing devices: gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power.
常に改善が行われていますが、ムーアの法則は、組み込みシステム空間ではパーソナルコンピューティングデバイスよりも効果が低くなる傾向があります。トランジスタ数と密度の増加によって得られる利益は、コストと電力要件の削減に投資される可能性が高くなります。計算能力の継続的な増加に。
With the ongoing work on connecting smart objects to the Internet, there are many challenges the workshop participants raised in more than 70 accepted position papers. With a single workshop day, discussions had to be focused, and priority was given to those topics that had been raised by many authors. A summary of the identified issues are captured in the subsections below.
スマートオブジェクトをインターネットに接続する作業が進行中のため、ワークショップの参加者が70以上の承認されたポジションペーパーで提起した多くの課題があります。ワークショップの1日で、ディスカッションに集中する必要があり、多くの著者によって提起されたトピックが優先されました。識別された問題の概要は、以下のサブセクションに記載されています。
A number of architectural questions were brought up in the workshop. This is natural, as the architectural choices affect the required technical solutions and the need for standards. At this workshop, questions regarding the separation of traffic, the need for profiling for application-specific domains, the demand for data-model-specific standardization, as well as the design choices regarding the layer at which functionality should be put were discussed and are briefly summarized below.
ワークショップでは、いくつかの建築上の質問が取り上げられました。アーキテクチャの選択は、必要な技術ソリューションと標準の必要性に影響を与えるため、これは自然なことです。このワークショップでは、トラフィックの分離、アプリケーション固有のドメインのプロファイリングの必要性、データモデル固有の標準化の要求、および機能を配置するレイヤーに関する設計の選択に関する質問が議論され、以下に簡単に要約します。
Devices that used to be in proprietary or application-specific networks are today migrating to IP networks. There is, however, the question of whether these smart objects are now on the same IP network as any other application. Controlled applications, like the fountains in front of the Bellagio hotel in Las Vegas that are operated as a distributed control system [Dolin], probably are not exchanging their control messages over the same network that is also used by hotel guests for their Internet traffic. The same had been argued for smart grids, which are described as follows in [SmartGrid]:
独自のネットワークまたはアプリケーション固有のネットワークに使用されていたデバイスは、今日IPネットワークに移行しています。ただし、これらのスマートオブジェクトが他のアプリケーションと同じIPネットワーク上にあるかどうかという問題があります。分散制御システム[Dolin]として運用されているラスベガスのベラージオホテルの前にある噴水のような制御されたアプリケーションは、おそらくホテルのゲストがインターネットトラフィックに使用しているのと同じネットワークを介して制御メッセージを交換していません。 [SmartGrid]で次のように説明されているスマートグリッドについても同じことが議論されていました。
A smart grid is a digitally enabled electrical grid that gathers, distributes, and acts on information about the behavior of all participants (suppliers and consumers) in order to improve the efficiency, reliability, economics, and sustainability of electricity services.
スマートグリッドとは、電力サービスの効率、信頼性、経済性、持続可能性を向上させるために、すべての参加者（サプライヤとコンシューマ）の行動に関する情報を収集、配信、および操作するデジタル対応の電気グリッドです。
The question that was raised during the workshop is, therefore, in what sense are we talking about one Internet or about using IP technology for a separate, "walled garden" network that is independent of the Internet?
したがって、ワークショップ中に出された質問は、ある意味で、あるインターネットについて話しているのか、それとも、インターネットとは独立した別の「ウォールドガーデン」ネットワークにIPテクノロジーを使用しているのかということです。
Cullen Jennings compared the current state of smart object deployment with the evolution of Voice over IP (VoIP): "Initially, many vendors recommended to run VoIP over a separate VLAN or a separate infrastructure. Nobody could imagine how to make the type of real-time guarantees, how to debug it, and how to get it to work because the Internet is not ideally suited for making any types of guarantees for real-time systems. As time went on, people got better at making voice work across that type of IP network. They suddenly noticed that having voice running on a separate virtual network than their other applications was a disaster. They couldn't decide if a PC was running a softphone and whether it went on a voice or a data network. At that point, people realized that they needed a converged network and all moved to one. I wouldn't be surprised to see the same happen here. Initially, we will see very separated networks. Then, those will be running over the same hardware to take advantage of the cost benefits of not having to deploy multiple sets of wires around buildings. Over time, there will be strong needs to directly communicate with each other. We need to be designing the system for the long run. Assume everything will end up on the same network even if you initially plan to run it in separate networks."
Cullen Jenningsは、スマートオブジェクトの展開の現在の状態を、Voice over IP（VoIP）の進化と比較しました。「当初、多くのベンダーは、別のVLANまたは別のインフラストラクチャ上でVoIPを実行することを推奨していました。時間の保証、それをデバッグする方法、そしてそれをどのように機能させるかということです。インターネットはリアルタイムシステムのあらゆるタイプの保証を行うのに理想的ではありません。 IPネットワーク。音声が他のアプリケーションとは別の仮想ネットワークで実行されていることは惨事であることに突然気づきました。PCがソフトフォンを実行しているかどうか、および音声ネットワークとデータネットワークのどちらで実行されたかを判断できませんでした。その時点で、人々は統合型ネットワークが必要であることに気づき、すべてが1つに移行しました。ここで同じことが起こるのは驚くことではありません。最初は、非常に分離されたネットワークが表示されます。次に、それらは同じハードウェアで実行されて利用されます。建物の周りに複数のワイヤーセットを配置する必要がないことの費用便益の。時間が経つにつれて、互いに直接通信する強いニーズがあります。長期的にはシステムを設計する必要があります。最初は別のネットワークで実行することを計画していたとしても、すべてが同じネットワーク上で終了すると想定してください。」
It is clearly possible to let sensors in a building communicate through the wireless access points and through the same infrastructure used for Internet access, if you want to. Those who want separation at the physical layer can do so as well. What is important is to make sure that these different deployment philosophies do not force loss of interoperability.
必要に応じて、建物内のセンサーがワイヤレスアクセスポイントを介して、またインターネットアクセスに使用されるのと同じインフラストラクチャを介して通信できるようにすることが明らかに可能です。物理層での分離が必要な場合も同様です。重要なことは、これらの異なる展開の哲学が相互運用性の損失を強制しないことを確認することです。
The level of interoperability that IP accomplished fostered innovation at the application layer. Ralph Droms reinforced this message by saying: "Bright people will take a phone, build an application and connect it, with the appropriate security controls in place, to the things in my house in ways we have never thought about before. Otherwise, we are just building another telephone network."
IPが達成した相互運用性のレベルは、アプリケーション層でイノベーションを促進しました。 Ralph Dromsはこのメッセージをさらに強化しました。「明るい人は電話を取り、アプリケーションを作成し、適切なセキュリティコントロールを適用して、これまで考えたこともない方法で家の中に接続します。それ以外の場合は、別の電話網を構築するだけです。」
Imagine a building network scenario where a new light bulb is installed that should, out of the box without further configuration, interoperate with the already present light switch from a different vendor in the room. For many, this is the desired level of interoperability in the area of smart object design. To accomplish this level of interoperability, it is not sufficient to provide interoperability only at the network layer. Even running the same transport protocol and application-layer protocol (e.g., HTTP) is insufficient since both devices need to understand the semantics of the payloads for "Turn the light on" as well.
新しい電球がインストールされ、追加の設定なしで箱から出して、部屋にある別のベンダーの既存のライトスイッチと相互運用する建物ネットワークシナリオを想像してください。多くの場合、これはスマートオブジェクト設計の領域で望ましい相互運用性のレベルです。このレベルの相互運用性を実現するには、ネットワーク層でのみ相互運用性を提供するだけでは不十分です。同じトランスポートプロトコルとアプリケーションレイヤープロトコル（HTTPなど）を実行するだけでは不十分です。両方のデバイスが「ライトをオンにする」ためのペイロードのセマンティクスも理解する必要があるためです。
Standardizing the entire protocol stack for this specific "light switch / light bulb" scenario is possible. A possible stack would, for example, use IPv6 with a specific address configuration mechanism (such as stateless address autoconfiguration), a network access authentication security mechanism such as Protocol for carrying Authentication for Network Access (PANA) [RFC5191], a service discovery mechanism (e.g., multicast DNS with DNS-Based Service Discovery [DNS-SD]), an application-layer protocol, for example, Constrained Application Protocol (CoAP) [CoAP] (which uses UDP), and the syntax and semantic for the light on/off functionality.
この特定の「ライトスイッチ/電球」シナリオ用にプロトコルスタック全体を標準化することが可能です。可能なスタックは、たとえば、特定のアドレス構成メカニズム（ステートレスアドレス自動構成など）、ネットワークアクセス認証セキュリティメカニズム（ネットワークアクセスの認証を運ぶためのプロトコル（PANA）[RFC5191]）、サービス検出メカニズムなどのIPv6を使用します。 （たとえば、DNSベースのサービスディスカバリ[DNS-SD]を使用したマルチキャストDNS）、アプリケーション層プロトコル、たとえば、制約付きアプリケーションプロトコル（CoAP）[CoAP]（UDPを使用）、およびライトの構文とセマンティックオン/オフ機能。
As this list shows, there is already some amount of protocol functionality that has to be agreed on by various stakeholders to make this scenario work seamlessly. As we approach more complex protocol interactions, the functionality quickly becomes more complex: IPv4 and IPv6 on the network layer, various options at the transport layer (such as UDP, TCP, the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]), and there are plenty of choices at the application layer with respect to communication protocols, data formats and data models. Different requirements have led to the development of a variety of communication protocols: client-server protocols in the style of the original HTTP, publish-subscribe protocols (like the Session Initiation Protocol (SIP) [RFC3261] or Extensible Messaging and Presence Protocol (XMPP) [RFC6121]), and store-and-forward messaging (borrowed from the delay tolerant networking community). Along with the different application-layer communication protocols come various identity and security mechanisms.
このリストが示すように、このシナリオをシームレスに機能させるには、さまざまな利害関係者が合意する必要のあるプロトコル機能がすでにいくつかあります。より複雑なプロトコルの相互作用に取り組むと、機能はすぐに複雑になります。ネットワーク層のIPv4とIPv6、トランスポート層のさまざまなオプション（UDP、TCP、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、およびデータグラム輻輳制御プロトコル（DCCP）[RFC4340]）。アプリケーション層には、通信プロトコル、データ形式、およびデータモデルに関して多くの選択肢があります。さまざまな要件がさまざまな通信プロトコルの開発につながっています。元のHTTPのスタイルのクライアントサーバープロトコル、パブリッシュサブスクライブプロトコル（Session Initiation Protocol（SIP）[RFC3261]またはExtensible Messaging and Presence Protocol（XMPPなど） ）[RFC6121]）、およびストアアンドフォワードメッセージング（遅延耐性のあるネットワーキングコミュニティから借用）。さまざまなアプリケーション層の通信プロトコルに加えて、さまざまなIDおよびセキュリティメカニズムがあります。
With the smart object constraints, it feels natural to develop these stacks since each application domain (e.g., healthcare, smart grids, building networking) will have their unique requirements and their own community involved in the design process. How likely are these profiles going to be the right match for the future, specifically for the new innovations that will come? How many of these stacks are we going to have? Will the differences in the profiles purely be the result of different requirements coming from the individual application domains or will these mismatches reflect the spirit, understanding, and preferences of the community designing them? How many stacks will multipurpose devices have to implement?
スマートオブジェクトの制約により、各アプリケーションドメイン（ヘルスケア、スマートグリッド、ネットワークの構築など）には固有の要件と独自のコミュニティが設計プロセスに関与するため、これらのスタックを開発するのは自然なことです。これらのプロファイルは、将来の、特に今後の新しい革新にとって、適切な組み合わせになる可能性はどのくらいありますか？これらのスタックはいくつありますか？プロファイルの違いは、純粋に個々のアプリケーションドメインからのさまざまな要件の結果によるものですか、それともこれらの不一致は、それらを設計するコミュニティの精神、理解、および好みを反映していますか？多目的デバイスはいくつのスタックを実装する必要がありますか？
Standardizing profiles independently for each application is not the only option. Another option is to let many different applications utilize a common foundation, i.e., a protocol stack that is implemented and utilized by every device. This, however, requires various application domains to be analyzed for their common characteristics and to identify requirements that are common across all of them. The level of difficulty for finding an agreement of how such a foundation stack should look depends on how many layers it covers and how lightweight it has to be.
アプリケーションごとに個別にプロファイルを標準化することだけが選択肢ではありません。別のオプションは、多くの異なるアプリケーションが共通の基盤、つまり、すべてのデバイスによって実装および利用されるプロトコルスタックを利用できるようにすることです。ただし、これには、さまざまなアプリケーションドメインの共通の特性を分析し、それらすべてに共通の要件を特定する必要があります。そのような基礎スタックがどのように見えるべきかについて合意を見つけることの難しさのレベルは、それがカバーする層の数とそれがどれほど軽量でなければならないかによって異なります。
From the discussions at the workshop, it was clear that the available options are not ideal and further discussions are needed.
ワークショップでの議論から、利用可能なオプションは理想的ではなく、さらなる議論が必要であることは明らかでした。
The end-to-end principle states that functionality should be put into the end points instead of into the networks. An additional recommendation, which is equally important, is to put functionality higher up in the protocol stack. While it is useful to make common functionality available as building blocks to higher layers, the wide range of requirements by different applications led to a model where lower layers provide only very basic functionality and more sophisticated features were made available by various applications. Still, there has been the desire to put application-layer functionality into the lower layers of the networking stack. A common belief is that performance benefits can be gained if functionality is placed at the lower layers of the protocol stack. This new functionality may be offered in the form of a gateway, which bridges different communication technologies, acts on behalf of other nodes, and offers more generic functionality (such as name-based routing and caching).
エンドツーエンドの原則では、機能はネットワークではなくエンドポイントに配置する必要があると述べています。同様に重要な追加の推奨事項は、プロトコルスタックの上位に機能を配置することです。共通機能を上位層のビルディングブロックとして利用できるようにすることは有用ですが、さまざまなアプリケーションによる幅広い要件により、下位層が非常に基本的な機能のみを提供し、さまざまなアプリケーションがより高度な機能を利用できるモデルが生まれました。それでも、アプリケーション層の機能をネットワーキングスタックの下位層に入れたいという要望がありました。共通の信念は、機能がプロトコルスタックの下位層に配置されている場合、パフォーマンスの利点が得られるということです。この新しい機能は、さまざまな通信技術をブリッジし、他のノードに代わって動作し、より一般的な機能（名前ベースのルーティングやキャッシングなど）を提供するゲートウェイの形で提供される場合があります。
Two examples of functionality offered at the network layer and discussed during the workshops were location and name-based routing:
ネットワーク層で提供され、ワークショップ中に議論された機能の2つの例は、ロケーションと名前ベースのルーティングでした。
Location:
ロケーション：
The notion of location gives each network node the understanding of proximity (e.g., 'I am a light bulb and in the same room as the light switch.'). Today, a router may provide information as to whether other nodes belong to the same subnet or they may provide location information (for example, in the form of GPS-based coordinates). However, providing a sense of the specific environment (e.g., a room, building, campus, etc.) is not possible without manual configuration. While it has been a desirable feature for many ubiquitous computing applications to know this type of information and to use it for richer application-layer interactions, widespread deployment has not happened yet.
ロケーションの概念は、各ネットワークノードに近接性を理解させる（たとえば、「私は電球であり、ライトスイッチと同じ部屋にいる」）。今日、ルーターは、他のノードが同じサブネットに属しているかどうかに関する情報を提供する場合や、位置情報を提供する場合があります（たとえば、GPSベースの座標の形式で）。ただし、特定の環境の感覚（たとえば、部屋、建物、キャンパスなど）を提供することは、手動の構成なしでは不可能です。多くのユビキタスコンピューティングアプリケーションがこのタイプの情報を知り、それをより豊富なアプリケーションレイヤーの相互作用に使用することは望ましい機能ですが、広範な展開はまだ行われていません。
Name-Based Routing:
名前ベースのルーティング：
With the work on recent "clean slate" architecture proposals, such as named data networking, flexible naming concepts are being researched to allow application developers to express their application-layer concepts in a way that they can be used natively by the underlying networking stack without translation. For example, Jeff Burke provided the example of his work in a theater with a distributed control system of technical equipment (such as projectors, dimmers, and light systems). Application developers name their equipment with human-readable identifiers, which may change after the end of a rehearsal, and address them using these names. These naming concepts based on variable-length strings raise questions regarding scalability.
名前付きデータネットワーキングなど、最近の「白紙の」アーキテクチャの提案に関する作業により、アプリケーション開発者がアプリケーションレイヤーの概念を、基盤となるネットワーキングスタックでネイティブに使用できる方法で表現できるように、柔軟な命名概念が研究されています翻訳。たとえば、ジェフバークは、技術機器（プロジェクター、調光器、照明システムなど）の分散制御システムを備えた劇場での彼の作品の例を提供しました。アプリケーション開発者は、リハーサルの終了後に変更される可能性のある人間が読み取れる識別子を使用して機器に名前を付け、これらの名前を使用してそれらに対処します。可変長文字列に基づくこれらの命名概念は、スケーラビリティに関する問題を提起します。
The workshop participants were not able to come to an agreement about what functionality should be moved from the application layer to the network layer.
ワークショップの参加者は、アプリケーション層からネットワーク層に移動する必要がある機能について合意に達することができませんでした。
One limitation of smart objects is their available energy. To extend battery life, for example, of a watch battery or single AAA battery for months, these low-power devices have to sleep 99% to 99.5% of their time. For example, a light sensor may only wake up to check whether it is nighttime to turn on light bulbs. Most parts of the system, particularly communication components, are put into a sleeping state (e.g., WLAN radio interface) and selected components, such as sensors, periodically check for relevant events and, if necessary, turn on other hardware modules. Every bit is precious, as is every round trip and every millisecond of radio activity.
スマートオブジェクトの1つの制限は、それらの利用可能なエネルギーです。たとえば、時計の電池や単4単電池の電池寿命を数か月延長するには、これらの低電力デバイスは、時間の99％から99.5％スリープする必要があります。たとえば、光センサーは、電球をオンにするのが夜間かどうかを確認するためだけに起動する場合があります。システムのほとんどの部分、特に通信コンポーネントはスリープ状態（WLAN無線インターフェースなど）になり、センサーなどの選択されたコンポーネントは定期的に関連イベントをチェックし、必要に応じて他のハードウェアモジュールをオンにします。すべてのビットは貴重であり、すべてのラウンドトリップおよびミリ秒ごとの無線アクティビティも同様です。
Many IETF protocols are implicitly designed to be always on, i.e., the protocol implementation waits for and reacts to incoming messages, and may maintain session state (at various layers of the stack). These protocols work well when energy consumption is not a concern and when receiving and sending messages happen at a low cost. It should be understood that energy is consumed both in transmitting messages (and often more importantly) in keeping the receiver awake. Allowing devices to sleep most of the time preserves energy but creates challenges for protocol designs.
多くのIETFプロトコルは、常にオンになるように暗黙的に設計されています。つまり、プロトコル実装は、着信メッセージを待機してそれに応答し、（スタックのさまざまな層で）セッション状態を維持できます。これらのプロトコルは、エネルギー消費が問題ではなく、メッセージの送受信が低コストで発生する場合に適しています。エネルギーは、メッセージを送信する際にも（多くの場合より重要なこととして）受信機を起動状態に保つためにも消費されます。デバイスがほとんどの時間スリープできるようにすると、エネルギーは節約されますが、プロトコル設計に課題が生じます。
The inherent issue encountered by a stationary node resuming from sleep is that another node may have chosen the same address while the node was asleep. A number of steps have to be taken before sending a packet. A new address may have to be obtained, for example using the Dynamic Host Configuration Protocol (DHCP) or stateless address autoconfiguration. Optionally, Detecting Network Attachment (DNA) procedures (see [RFC4436] and [RFC6059]) can be used to shorten the setup time by noticing that the node is using the same default gateway.
静止ノードがスリープから再開する際に発生する固有の問題は、ノードがスリープしている間に別のノードが同じアドレスを選択した可能性があることです。パケットを送信する前に、いくつかの手順を実行する必要があります。たとえば動的ホスト構成プロトコル（DHCP）またはステートレスアドレス自動構成を使用して、新しいアドレスを取得する必要がある場合があります。オプションで、Detecting Network Attachment（DNA）手順（[RFC4436]および[RFC6059]を参照）を使用して、ノードが同じデフォルトゲートウェイを使用していることを通知することにより、セットアップ時間を短縮できます。
The issue with a mobile node that is sleeping is that the node may have been moved to another network (e.g., a sleeping laptop being transported to a new environment) where on resumption it may discover that its address has become invalid.
スリープ状態のモバイルノードの問題は、ノードが別のネットワーク（たとえば、スリープ状態のラップトップが新しい環境に転送されている）に移動された可能性があり、再開時にアドレスが無効になったことが判明する可能性があります。
The following design considerations should be taken into account when energy efficiency is a concern:
エネルギー効率が懸念される場合は、次の設計上の考慮事項を考慮する必要があります。
1. Rethink the Always-On Assumption
1. 常にオンの仮定を再考する
When designing a protocol that assumes that the nodes are always on, alternatives need to be considered. This could involve eliminating functionality (e.g., not implementing DNA or duplicate address detection) or considering the use of a sleep proxy. While sleep proxies (e.g., proxZzzy(TM) [proxZzzy]) enable periodic messages to be sent on behalf of sleeping nodes, this approach assumes that energy management constraints do not apply to the sleep proxy, which may not always be the case (e.g., if the entire network is deployed in the field without access to power). Yet another option is for devices to explicitly communicate sleep cycles so that they can only check for messages periodically (be it measured in milliseconds, seconds, or hours).
ノードが常にオンであることを前提とするプロトコルを設計するときは、代替案を検討する必要があります。これには、機能の削除（DNAや重複アドレス検出を実装しないなど）や、スリーププロキシの使用を検討することが含まれます。スリーププロキシ（たとえば、proxZzzy（TM）[proxZzzy]）は、スリープ状態のノードに代わって定期的なメッセージを送信できるようにしますが、このアプローチでは、エネルギー管理の制約がスリーププロキシに適用されないことを想定しています。 、ネットワーク全体が電源にアクセスせずにフィールドに展開されている場合）。さらに別のオプションは、デバイスがスリープサイクルを明示的に通信して、メッセージを定期的に（ミリ秒、秒、または時間単位で）確認することのみができるようにすることです。
This is the approach taken in IEEE 802.11, which supports multiple energy conservation mechanisms designed to enable a station to spend a large fraction of the time sleeping.
これは、IEEE 802.11で採用されているアプローチであり、ステーションが睡眠時間の大部分を費やすように設計された複数のエネルギー節約メカニズムをサポートしています。
2. Reduce Network Attachment Costs
2. ネットワーク接続コストを削減
As noted above, the procedures for obtaining an address and assuring its uniqueness can be costly. In a network where nodes spend a large fraction of the time sleeping, but are not necessarily mobile, are all of these procedures really necessary?
上記のように、アドレスを取得してその一意性を保証するための手順はコストがかかる可能性があります。ノードがスリープ時間の大部分を費やしているが、必ずしもモバイルである必要がないネットワークでは、これらの手順のすべてが本当に必要ですか？
Can we find ways to reduce the number of protocol interactions without sacrificing correctness? The main focus of past investigations has been on IPv6 and ND, but other protocols do also deserve a deeper investigation, such as DNS and DHCP.
正確さを犠牲にすることなくプロトコルの相互作用の数を減らす方法を見つけることができますか？過去の調査の主な焦点はIPv6とNDでしたが、DNSやDHCPなどの他のプロトコルもさらに調査する価値があります。
3. Avoid Verbose Protocols
3. 冗長プロトコルを避ける
Protocols involving multiple roundtrips and/or lengthy messages with verbose encodings (e.g., XML) are not always well-suited for constrained environments. Low-power nodes utilizing verbose protocols have to use more energy in sending messages and have to stay powered on for a longer period of time as they wait for the multi-roundtrip protocol exchanges to complete.
複数のラウンドトリップや冗長なエンコーディング（XMLなど）を含む長いメッセージを含むプロトコルは、制約された環境に必ずしも適しているとは限りません。詳細なプロトコルを使用する低電力ノードは、メッセージの送信により多くのエネルギーを使用し、マルチラウンドトリッププロトコルの交換が完了するのを待機するため、長時間電源をオンにしておく必要があります。
The best way to address these problems is to ensure that the simplest possible protocol exchanges are used when the protocols in question are designed. In some cases, alternative encoding formats and compression may also help.
これらの問題に対処する最良の方法は、問題のプロトコルが設計されているときに、可能な限り単純なプロトコル交換が使用されるようにすることです。場合によっては、別のエンコード形式と圧縮も役立つことがあります。
4. Think about System-Wide Efficiency
4. システム全体の効率について考える
While energy efficiency is critical for low-power devices running on batteries, it is also beneficial for other devices as well, including notebook computers, desktop computers, and smartphones. However, if the goal is energy efficiency as opposed to battery life extension for low-power devices, then it is important to consider the total energy consumption of all the elements of the system.
バッテリーで動作する低電力デバイスにはエネルギー効率が重要ですが、ノートブックコンピューター、デスクトップコンピューター、スマートフォンなどの他のデバイスにもエネルギー効率は役立ちます。ただし、目標が低電力デバイスのバッテリー寿命延長ではなくエネルギー効率である場合、システムのすべての要素の総エネルギー消費量を考慮することが重要です。
For example, consider energy consumption in a home environment. In these scenarios it is important to evaluate the energy usage of the entire system. A light bulb utilizing Internet technology described in this document may use less power but there is also the device that controls the bulb that may consume a lot of energy. If the goal is to reduce overall energy usage, then it is important to consider these two devices (and potentially many others) together.
たとえば、家庭環境でのエネルギー消費について考えます。これらのシナリオでは、システム全体のエネルギー使用量を評価することが重要です。このドキュメントで説明されているインターネットテクノロジーを利用した電球は、消費電力が少ない可能性がありますが、大量のエネルギーを消費する可能性がある電球を制御するデバイスもあります。全体的なエネルギー使用量を削減することを目標とする場合は、これら2つのデバイス（および場合によっては他の多くのデバイス）を一緒に検討することが重要です。
In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552] and RFC 4101 [RFC4101], apply also to the smart object space.
スマートオブジェクトアプリケーションの開発では、他のプロトコルアプリケーションソリューションと同様に、設計プロセスの早い段階でセキュリティを考慮する必要があります。そのため、RFC 3552 [RFC3552]やRFC 4101 [RFC4101]などのIETFプロトコルアーキテクトに現在提供されている推奨事項は、スマートオブジェクトスペースにも適用されます。
While there are additional constraints, as described in Section 2, security has to be a mandatory part of the solution. The hope is that this will lead to implementations that provide security features, deployments that utilize them, and finally use of better security mechanisms. It is important to point out that the lack of direct user interaction will place hard requirements on deployment models, configuration mechanisms, and software upgrade / crypto-agility mechanisms.
セクション2で説明するように、追加の制約がありますが、セキュリティはソリューションの必須の部分でなければなりません。これにより、セキュリティ機能を提供する実装、それらを利用する展開、そして最終的にはより優れたセキュリティメカニズムの使用につながることが期待されます。直接的なユーザー操作の欠如により、導入モデル、構成メカニズム、ソフトウェアのアップグレード/暗号化アジリティメカニズムに厳しい要件が課されることを指摘することが重要です。
Since many of the security mechanisms allow for customization, particularly with regard to the cryptographic primitives utilized, many believe that IETF security solutions are usable without modifications in a large part of the smart object domain. Others call for new work on cryptographic primitives that make use of a single primitive (such as the Advanced Encryption Standard (AES) [AES]) as a building block for all cryptographic functions. The benefit would be a smaller footprint of the overall solution, specifically with respect to hardware limitations (e.g., the hardware architecture of certain embedded devices prevents pipelining from being used). In the excitement for new work on optimizations of cryptographic primitives, other factors have to be taken into consideration that influence successful deployment, such as widespread support in libraries, as well as intellectual property rights (IPR). As an example of the latter aspect, the struggle of Elliptic Curve Cryptography (ECC)-based cryptographic algorithms [ECC] to find deployment can partially be attributed to its IPR situation. The reuse of libraries providing cryptographic functions is clearly an important way to use available memory resources in a more efficient way. To deal with the performance and footprint concerns, investigations into offloading certain resource-hungry functions to parties that possess more cryptographic power have been considered. For example, the ability to delegate certificate validation to servers has been standardized in the IETF before, for the support of the Online Certificate Status Protocol (OCSP) in the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Layer Security (TLS); see [RFC4806] and [RFC5246], respectively.
多くのセキュリティメカニズムは、特に利用される暗号化プリミティブに関してカスタマイズを可能にするため、IETFセキュリティソリューションは、スマートオブジェクトドメインの大部分を変更せずに使用できると信じています。また、すべての暗号化機能のビルディングブロックとして単一のプリミティブ（Advanced Encryption Standard（AES）[AES]など）を使用する暗号化プリミティブに関する新しい作業を要求する人もいます。利点は、特にハードウェアの制限に関して、ソリューション全体のフットプリントが小さくなることです（たとえば、特定の組み込みデバイスのハードウェアアーキテクチャにより、パイプラインを使用できなくなります）。暗号化プリミティブの最適化に関する新しい取り組みの興奮のなかで、ライブラリの広範なサポートや知的財産権（IPR）など、展開の成功に影響を与える他の要因を考慮する必要があります。後者の側面の例として、展開を見つけるための楕円曲線暗号（ECC）ベースの暗号化アルゴリズム[ECC]の苦労は、そのIPR状況に部分的に起因する可能性があります。暗号化機能を提供するライブラリの再利用は、利用可能なメモリリソースをより効率的に使用するための重要な方法であることは明らかです。パフォーマンスとフットプリントの問題に対処するために、より多くの暗号化能力を持つ当事者に特定のリソースを大量に消費する機能をオフロードする調査が検討されています。たとえば、インターネットキー交換プロトコルバージョン2（IKEv2）およびトランスポート層セキュリティ（TLS）でのオンライン証明書ステータスプロトコル（OCSP）のサポートのために、証明書の検証をサーバーに委任する機能は、以前にIETFで標準化されています。 ; [RFC4806]と[RFC5246]をそれぞれ参照してください。
Focusing only on the cryptographic primitives would be shortsighted; many would argue that this is the easy part of a smart object security solution. Key management and credential enrollment, however, are considered a big challenge by many, particularly when usability requirements have to be taken into account. Another group of challenges concern privacy; with smart grids, for example, some have voiced concerns regarding the ability of third parties to keep track of an individual's energy consumption (and draw associated conclusions). As another example, it is easy to see how a scale that is connected to the Internet for uploading weight information to a social network could lead to privacy concerns. While security mechanisms that are used to offer protection of the communication between different parties also provide a certain degree of privacy protection, they are clearly not enough to address all concerns. Even with the best communication security and access control mechanisms in place, one still needs additional safeguards against the concerns mentioned in the examples.
暗号化プリミティブのみに焦点を合わせるのは近視眼的です。多くの人は、これがスマートオブジェクトセキュリティソリューションの簡単な部分であると主張します。ただし、特にユーザビリティの要件を考慮する必要がある場合、キー管理と資格情報の登録は多くの人にとって大きな課題と見なされます。もう1つの課題はプライバシーに関するものです。たとえば、スマートグリッドでは、第三者が個人のエネルギー消費を追跡する（および関連する結論を引き出す）能力について懸念を表明する人もいます。別の例として、体重情報をソーシャルネットワークにアップロードするためにインターネットに接続されている体重計がプライバシーの懸念にどのようにつながるかを簡単に確認できます。異なる当事者間の通信を保護するために使用されるセキュリティメカニズムは、ある程度のプライバシー保護も提供しますが、すべての懸念に対処するには十分ではありません。最高の通信セキュリティとアクセス制御メカニズムが導入されていても、例で言及されている懸念事項に対する追加の保護手段が必要です。
While better deployment of security protocols on the entire Internet would be very desirable, practical considerations regarding usability and the incentives of the stakeholders involved have often lead to slower adoption.
インターネット全体にセキュリティプロトコルをより適切に導入することは非常に望ましいことですが、ユーザビリティに関する実用的な考慮事項と関係する利害関係者のインセンティブは、採用の遅れにつながることがよくあります。
A smart object network environment may also employ routers under similar constraints as the end devices. Currently two approaches to routing in these low-power and lossy networks are under consideration -- namely, mesh-under and route-over. The so-called "mesh-under" approach places routing functions at the link layer, and consequently all devices appear as immediate neighbors at the network layer. With the "route-over" approach, routing is done in the IP layer and not at all in the link layer. Each physical hop appears as a single IP hop (ignoring devices that just extend the physical range of signaling, such as repeaters). Routing in this context means running a routing protocol. The IPv6 Routing Protocol for Low-power and Lossy Networks (RPL) [RPL], for example, belongs to the route-over category.
スマートオブジェクトネットワーク環境でも、エンドデバイスと同様の制約の下でルーターを使用できます。現在、これらの低電力で損失の多いネットワークでルーティングを行う2つのアプローチ、つまりメッシュアンダーとルートオーバーが検討されています。いわゆる「メッシュアンダー」アプローチでは、ルーティング機能がリンク層に配置され、その結果、すべてのデバイスがネットワーク層のすぐ隣に表示されます。 「ルートオーバー」アプローチでは、ルーティングはリンク層ではなくIP層で行われます。各物理ホップは、単一のIPホップとして表示されます（リピーターなど、シグナリングの物理範囲を拡張するだけのデバイスは無視されます）。このコンテキストでのルーティングとは、ルーティングプロトコルを実行することを意味します。たとえば、低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル（RPL）[RPL]は、route-overカテゴリに属します。
From an architectural point of view there are several questions that arise from where routing is provided, for example:
アーキテクチャの観点から、ルーティングが提供される場所から生じるいくつかの質問があります。たとえば、
o Protocols often assume that link characteristics are predictable when communicating with any device attached to the same link. Latency, throughput, and reliability may vary considerably between different devices that are multiple link-layer hops away. What timeout should be used? What happens if a device is unreachable? In case of default router selection, two advertised routers may be a different number of hops away. Should a device have visibility into the path to make a decision, and what path characteristics would be useful to have?
o 多くの場合、プロトコルは、同じリンクに接続された任意のデバイスと通信するときにリンクの特性が予測可能であると想定しています。レイテンシ、スループット、信頼性は、複数のリンクレイヤーホップ離れたデバイスによって大きく異なる場合があります。どのタイムアウトを使用する必要がありますか？デバイスに到達できない場合はどうなりますか？デフォルトのルーター選択の場合、2つのアドバタイズされたルーターが異なるホップ数である可能性があります。デバイスは、決定を行うためにパスを可視化する必要がありますか。また、どのようなパス特性が役立つと思いますか？
o Scoped message delivery to a neighboring IP hop (via link-local addressing) allows certain types of IP protocols to communicate with their immediate neighbors and to therefore scope their recipients. A link-local multicast message will be received by all nodes in the same IP link-local realm unless some special optimizations are provided by the link layer.
o （リンクローカルアドレッシングを介した）隣接するIPホップへのスコープ付きメッセージ配信により、特定の種類のIPプロトコルが直接のネイバーと通信し、したがって受信者をスコープすることができます。リンクローカルマルチキャストメッセージは、リンク層によって特別な最適化が行われていない限り、同じIPリンクローカルレルム内のすべてのノードによって受信されます。
o When path computations are done at the link layer as well as on the network layer, then what coordination needs to take place?
o パス計算がリンクレイヤーとネットワークレイヤーで行われる場合、どのような調整が必要ですか？
When multiple different link-layer technologies are involved in a network design, routing at layer 3 has to be provided in any case. [IoT-ARCH] talks about these tradeoffs between route-over and mesh-under in detail. Furthermore, those who decide about the deployment have to determine how to connect smart objects to the Internet infrastructure, and a number of wired and wireless technologies may be suitable for a specific deployment. Depending on the chosen technologies the above-mentioned mesh-under vs. route-over approach will have to be decided, and further decisions will have to be made about the choice of a specific routing protocol.
複数の異なるリンク層テクノロジーがネットワーク設計に含まれている場合は、レイヤー3でルーティングを行う必要があります。 [IoT-ARCH]は、ルートオーバーとメッシュアンダーの間のこれらのトレードオフについて詳しく説明しています。さらに、展開について決定する人は、スマートオブジェクトをインターネットインフラストラクチャに接続する方法を決定する必要があり、多くの有線および無線テクノロジが特定の展開に適している場合があります。選択したテクノロジーに応じて、上記のメッシュアンダーとルートオーバーのアプローチを決定する必要があり、特定のルーティングプロトコルの選択に関してさらに決定を下す必要があります。
In 2008, the IETF formed the Routing Over Low power and Lossy networks (ROLL) working group to specify a routing solution for smart object environments. During its first year of existence, the working group studied routing requirements in detail (see [RFC5867], [RFC5826], [RFC5673], and [RFC5548]), and it worked on a protocol survey comparing a number of existing routing protocols, including Ad hoc On-Demand Distance Vector (AODV)-style protocols [RFC3561], against the identified requirements. The protocol survey [PROT-SURVEY] was inconclusive and abandoned without giving rise to publication of an RFC.
2008年、IETFは、Routing Over Low Power and Lossy Networks（ROLL）ワーキンググループを結成し、スマートオブジェクト環境向けのルーティングソリューションを特定しました。ワーキンググループは最初の1年間、ルーティング要件を詳細に調査し（[RFC5867]、[RFC5826]、[RFC5673]、および[RFC5548]を参照）、既存のルーティングプロトコルの数を比較するプロトコル調査に取り組みました。特定された要件に反するアドホックオンデマンド距離ベクトル（AODV）スタイルのプロトコル[RFC3561]を含みます。プロトコル調査[PROT-SURVEY]は決定的ではなく、RFCの発行を引き起こすことなく放棄されました。
The ROLL WG concluded that a new routing protocol satisfying the documented requirements has to be developed and the work on RPL was started as the IETF routing protocol for smart object networks. Nevertheless, controversial discussions at the workshop about which routing protocols is best in a given environment are still ongoing. Thomas Clausen, for example, argued for using an AODV-like routing protocol in [Clausen].
ROLL WGは、文書化された要件を満たす新しいルーティングプロトコルを開発する必要があると結論付け、RPLに関する作業は、スマートオブジェクトネットワーク用のIETFルーティングプロトコルとして開始されました。それにもかかわらず、どのルーティングプロトコルが特定の環境に最適であるかについてのワークショップでの議論の余地のある議論はまだ進行中です。たとえば、Thomas Clausenは、[Clausen]でAODVのようなルーティングプロトコルを使用することを主張しました。
The workshop allowed the participants to be exposed to interesting applications and their requirements (buildings, fountains, theater, etc.), to have discussions about radically different architectures and their issues (e.g., information centric networking), to look at existing technology from a new angle (sleeping nodes, energy consumption), to focus on some details of the protocol stack (neighbor discovery, security, routing) and to learn about implementation experience.
ワークショップにより、参加者は興味深いアプリケーションとその要件（建物、噴水、劇場など）に触れることができ、根本的に異なるアーキテクチャとその問題（たとえば、情報中心のネットワーキング）について話し合い、既存のテクノロジーを新しい角度（スリーピングノード、エネルギー消費）。プロトコルスタック（ネイバー探索、セキュリティ、ルーティング）の詳細に焦点を当て、実装の経験について学習します。
One goal of the workshop was to identify areas that require further investigation. The list below reflects the thoughts of the workshop participants as expressed on the day of the workshop. Note that the suggested items concern potential work by the IETF and the IRTF, and the order does not imply a particular preference.
ワークショップの目的の1つは、さらに調査が必要な領域を特定することでした。以下のリストは、ワークショップ当日に表明されたワークショップ参加者の考えを反映しています。提案された項目はIETFとIRTFによる潜在的な作業に関するものであり、順序は特定の優先順位を意味するものではないことに注意してください。
Security:
セキュリティ：
A discussion of security is provided in Section 3.3. In general, security-related protocol exchanges and the required amount of computational resource requirements can contribute significantly to the overall processing. Therefore, it remains a challenge to accomplish performance improvements without sacrificing the overall security level, taking the usability of the entire system into consideration.
セキュリティについては、セクション3.3で説明します。一般に、セキュリティ関連のプロトコル交換と必要な計算リソース要件は、全体的な処理に大きく貢献します。したがって、システム全体のユーザビリティを考慮して、全体的なセキュリティレベルを犠牲にすることなく、パフォーマンスの向上を達成することは依然として困難です。
Another challenge is how to balance the security and performance needs of smart objects with the interoperability requirements of hosts on the Internet since different suites of algorithms tend to be chosen for these different environments. This involves trade-offs between performance on the smart objects versus end-to-end security. Solutions that mandate a "trusted" middlebox whose only role is to terminate security associations tend to be frowned upon from the security perspective, especially since end users of challenged devices (where those exist) are unlikely to understand the security consequences of such middleboxes.
別の課題は、スマートオブジェクトのセキュリティとパフォーマンスのニーズと、インターネット上のホストの相互運用性要件とのバランスをどのようにとるかです。これらの異なる環境には、異なるアルゴリズムスイートが選択される傾向があるためです。これには、スマートオブジェクトのパフォーマンスとエンドツーエンドのセキュリティのトレードオフが含まれます。セキュリティアソシエーションを終了することのみが役割である「信頼できる」ミドルボックスを義務付けるソリューションは、特に、問題のあるデバイス（存在する場合）のエンドユーザーがそのようなミドルボックスのセキュリティ結果を理解する可能性が低いため、セキュリティの観点から不満を抱く傾向があります。
The discussion concluded with the following recommendations:
議論は以下の勧告で締めくくられました：
* Investigate usability in cryptographic protocol design with regard to credential management. As an example, the Bluetooth pairing mechanism was mentioned as a simple and yet reasonably secure method of introducing devices into a new environment. In fact, the IETF working group Credential and Provisioning (ENROLL) was established years ago to deal with residential networks but was terminated prematurely due to lack of progress. The email archive still exists and is available [ENROLL] and may provide useful historical information.
*資格情報の管理に関して、暗号化プロトコル設計の有用性を調査します。例として、Bluetoothペアリングメカニズムは、新しい環境にデバイスを導入するためのシンプルでありながら安全な方法として言及されました。実際、IETFワーキンググループのCredential and Provisioning（ENROLL）は、数年前に住宅用ネットワークを扱うために設立されましたが、進展がなかったために時期尚早に終了しました。電子メールアーカイブはまだ存在し、利用可能[ENROLL]であり、有用な履歴情報を提供する場合があります。
* Standardized authentication and key exchange mechanisms should be surveyed for suitability in smart object environments with respect to message size, computational performance, number of messages, code size, and main memory requirements. A starting point of such an investigation (in the case of IKEv2) was provided by Tero Kivinen with [MINIMAL-IKEv2], and a suitable venue for discussion could be the recently established Light-Weight Implementation Guidance (LWIG) working group [LWIG].
* メッセージサイズ、計算パフォーマンス、メッセージ数、コードサイズ、メインメモリの要件に関して、スマートオブジェクト環境での適合性について、標準化された認証および鍵交換メカニズムを調査する必要があります。そのような調査の開始点（IKEv2の場合）は、Tero Kivinenによって[MINIMAL-IKEv2]とともに提供され、議論のための適切な場は、最近確立された軽量実装ガイダンス（LWIG）ワーキンググループ[LWIG]である可能性があります。
* Research has to be done in the area of lightweight cryptographic primitives -- namely, block ciphers, stream ciphers, and cryptographic hash functions. It's worthwhile to mention the early work with the National Institute of Standards and Technology (NIST) new cryptographic hash algorithm 'SHA-3' competition [SHA3]. A suitable forum for discussion is the IRTF Crypto Forum Research Group (CFRG) [CFRG].
* 軽量の暗号プリミティブ、つまりブロック暗号、ストリーム暗号、暗号ハッシュ関数の領域で研究を行う必要があります。国立標準技術研究所（NIST）の新しい暗号化ハッシュアルゴリズム「SHA-3」競争[SHA3]の初期の取り組みについて言及することは価値があります。議論に適したフォーラムは、IRTF暗号フォーラム研究グループ（CFRG）[CFRG]です。
The difficulty and impact of choosing specialized algorithms for smart objects should not be underestimated. Issues that arise include the additional specification complexity (e.g., TLS already has hundreds of ciphersuites defined, most of which are unused in practice), the long latency in terms of roll out (many hosts are still using deprecated algorithms 5-10 years after those algorithms were deprecated), and the barriers that IPR-encumbered schemes present to widespread deployment. While research on this topic within CFRG and the cryptographic research community is a very worthwhile goal, any such algorithms will likely have to offer very significant benefits before they will be broadly adopted. 20% less CPU usage is unlikely to be a winning argument no matter what an algorithm inventor believes.
スマートオブジェクトに特化したアルゴリズムを選択することの難しさと影響を過小評価しないでください。発生する問題には、追加の仕様の複雑さ（たとえば、TLSにはすでに数百の暗号スイートが定義されており、そのほとんどは実際には使用されていません）、ロールアウトの観点からの長いレイテンシ（多くのホストは、非推奨のアルゴリズムを5〜10年使用しています）アルゴリズムは非推奨になりました）、そしてIPRに制約されたスキームが広範な展開に提示する障壁。 CFRGおよび暗号研究コミュニティ内でのこのトピックに関する研究は非常に価値のある目標ですが、そのようなアルゴリズムは、広く採用される前に非常に大きなメリットを提供する必要があります。アルゴリズムの発明者が何を信じていようと、CPU使用率が20％減少しても、勝者となることはまずありません。
Energy Design Considerations:
エネルギー設計に関する考慮事項：
One part of the workshop was focused on the discussion of energy implications for IETF protocol design with proposals being made about how to extend protocols to better support nodes that are mostly sleeping. Discussions are encouraged to take place on the RECIPE mailing list [RECIPE]. The workshop position paper [Wasserman] by Margaret Wasserman provides a good starting point for further investigations.
ワークショップの一部は、IETFプロトコル設計のエネルギーへの影響の議論に焦点が当てられ、ほとんどがスリープ状態にあるノードをより適切にサポートするためにプロトコルを拡張する方法について提案が行われました。 RECIPEメーリングリスト[レシピ]で議論することをお勧めします。マーガレットワッサーマンによるワークショップポジションペーパー[ワッサーマン]は、さらなる調査の出発点として最適です。
Information-/Content-Centric Networking:
情報/コンテンツ中心のネットワーキング：
Information/Content Centric Networking is about accessing named content, and a number of research projects have emerged around this theme. At this point in time, the work is not yet ready for standardization in the IETF. Instead, the formation of an IRTF research group has been proposed, and more details are available on the IRTF DISCUSS mailing list [irtf-discuss].
情報/コンテンツセントリックネットワーキングは名前付きコンテンツへのアクセスに関するものであり、このテーマを中心に多くの研究プロジェクトが登場しています。現時点では、IETFでの標準化の準備はまだ整っていません。代わりに、IRTF研究グループの編成が提案されており、詳細はIRTF DISCUSSメーリングリスト[irtf-discuss]で入手できます。
Architectural Guidelines:
建築ガイドライン：
Participants suggested developing an architectural write-up about what can be done with the IETF protocols we have today and how these different elements may be combined to offer an explanation for the broader community. This would be a task for the IAB. An example of prior work that serves as input is [RFC6272].
参加者は、今日のIETFプロトコルで何ができるか、およびこれらのさまざまな要素を組み合わせてより広いコミュニティに説明を提供する方法について、アーキテクチャの記述を作成することを提案しました。これはIABのタスクです。入力として機能する以前の作業の例は[RFC6272]です。
Network Management:
ネットワーク管理：
While this topic did not make it onto the workshop agenda, it was considered useful to start a discussion about how to implement network management protocols, such as Network Configuration Protocol (NETCONF) [RFC6241], on smart objects. The following position papers may be useful as a starting point for further discussions: [Ersue] and [Schoenwaelder]. An IETF draft document is also available: [SNMP-OPT].
このトピックはワークショップの議題にはなりませんでしたが、ネットワーク構成プロトコル（NETCONF）[RFC6241]などのネットワーク管理プロトコルをスマートオブジェクトに実装する方法についての議論を始めることは有用であると考えられました。次のポジションペーパーは、[Ersue]および[Schoenwaelder]のように、今後のディスカッションの出発点として役立ちます。 IETFドラフトドキュメントも利用できます：[SNMP-OPT]。
Congestion Control:
輻輳制御：
When smart objects transmit sensor readings to some server on the Internet, these protocol interactions often carry a small amount of data and happen infrequently, although regularly. With the work on new application protocols, like CoAP [CoAP], the question of whether a congestion control mechanism should be used at the underlying transport protocol or by the application protocol itself arises. [CoAP-CC] is a starting point for CoAP, but further work is needed.
スマートオブジェクトがセンサーの読み取り値をインターネット上のサーバーに送信するとき、これらのプロトコルの相互作用は、少量のデータを運ぶことが多く、定期的ではありますがまれにしか発生しません。 CoAP [CoAP]のような新しいアプリケーションプロトコルの作業に伴い、輻輳制御メカニズムを基礎となるトランスポートプロトコルで使用すべきか、それともアプリケーションプロトコル自体で使用すべきかという疑問が生じます。 [CoAP-CC]はCoAPの開始点ですが、さらに作業が必要です。
Data Models:
データモデル：
Standardization of application-layer protocols is important but does not ensure that, for example, a light switch and a light bulb are able to interact with each other. One area where participants saw the need for further work was in the area of data models. While prior IETF standardization work on, for example, location [GEOPRIV] can be reused, the question was raised where the IETF
アプリケーション層プロトコルの標準化は重要ですが、たとえば、ライトスイッチと電球が相互に対話できることを保証するものではありません。参加者がさらなる作業の必要性を見た1つの分野は、データモデルの分野でした。たとえば、場所[GEOPRIV]に関する以前のIETF標準化作業は再利用できますが、IETFが
should focus its standardization efforts since domain expertise in each area will be needed. As a potential example, energy pricing was discussed, with an example provided by [ENERGY-PRICING].
各分野の専門知識が必要になるため、標準化の取り組みに集中する必要があります。潜在的な例として、[ENERGY-PRICING]が提供する例を使用して、エネルギー価格設定が議論されました。
Building Networking:
ネットワーキングの構築：
Network architectures in residential as well as commercial buildings should take the presence of smart objects and dedicated subnetworks focusing on smart objects into account. A new working group, Home Networking (HOMENET) [HOMENET], was created after the workshop to look at this topic.
住宅および商業ビルのネットワークアーキテクチャでは、スマートオブジェクトと、スマートオブジェクトに焦点を当てた専用サブネットワークの存在を考慮に入れる必要があります。ワークショップの後に、このトピックを検討するために、新しいワーキンググループであるホームネットワーク（HOMENET）[HOMENET]が作成されました。
Discovery:
発見：
Additional extensions to developed discovery protocols, such as multicast DNS (mDNS), may be needed for the smart object environment. For instance, the HOMENET working group wants to extend current discovery protocols to work across multiple subnets. Smart object networks are often organized in separate subnets, so these extensions may be useful in that environment as well.
スマートオブジェクト環境では、マルチキャストDNS（mDNS）など、開発された検出プロトコルに対する追加の拡張機能が必要になる場合があります。たとえば、HOMENETワーキンググループは、現在の検出プロトコルを拡張して、複数のサブネット間で機能するようにしたいと考えています。多くの場合、スマートオブジェクトネットワークは個別のサブネットに編成されているため、これらの拡張機能はその環境でも役立つ場合があります。
Routing:
ルーティング：
Changing radio conditions and link fluctuation may lead to the need for renumbering. Workshop participants argued that work should be started on the multi-link subnetworks to mitigate this problem, i.e., to extend the notion of a subnet to be able to span multiple links. With the publication of RFC 4903 [RFC4903], the Internet Architecture Board had looked into this topic already and provided pros and cons.
無線の状態とリンクの変動を変更すると、番号を付け直す必要が生じる場合があります。ワークショップの参加者は、この問題を軽減するために、つまり、複数のリンクにまたがることができるようにサブネットの概念を拡張するために、マルチリンクサブネットワークで作業を開始する必要があると主張しました。 RFC 4903 [RFC4903]の公開により、インターネットアーキテクチャボードはこのトピックをすでに調査し、長所と短所を提供していました。
The applicability of specific routing protocols designed for smart object networks needs further investigation. The ROLL working group is chartered with the task of constructing an applicability document for RPL, for instance.
スマートオブジェクトネットワーク用に設計された特定のルーティングプロトコルの適用性については、さらに調査が必要です。たとえば、ROLLワーキンググループは、RPLの適用性ドキュメントを作成するタスクをチャーターします。
The workshop discussions covered a range of potential engineering activities, each with its own security considerations. As the IETF community begins to pursue specific avenues arising out of this workshop, addressing relevant security requirements will be crucial.
ワークショップのディスカッションでは、潜在的なエンジニアリング活動の範囲をカバーし、それぞれ独自のセキュリティに関する考慮事項がありました。 IETFコミュニティがこのワークショップから生じる特定の手段を追求し始めているので、関連するセキュリティ要件に対処することが重要になります。
As described in this report, part of the agenda was focused on the discussion of security; see Section 3.3.
このレポートで説明されているように、議題の一部はセキュリティの議論に焦点が当てられていました。セクション3.3を参照してください。
We would like to thank all the participants for their position papers. The authors of the accepted position papers were invited to the workshop.
すべての参加者のポジションペーパーに感謝します。承認されたポジションペーパーの著者がワークショップに招待されました。
Big thanks to Elwyn Davies for helping us to fix language bugs. We would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, and Henning Schulzrinne for their review comments.
言語バグの修正を手伝ってくれたElwyn Daviesに感謝します。 Andrei Robachevsky、Ulrich Herberg、Thomas Clausen、Bruce Nordman、Alissa Cooper、Dave Thaler、Bernard Aboba、Henning Schulzrinneのレビューコメントにも感謝します。
Additionally, we would like to thank Ericsson and Nokia Siemens Networks for their financial support.
さらに、EricssonとNokia Siemens Networksの経済的支援に感謝します。
[AES] Wikipedia, "Advanced Encryption Standard", December 2011, <http://en.wikipedia.org/w/ index.php?title=Advanced_Encryption_Standard& oldid=481153988>.
[AES] Wikipedia、「Advanced Encryption Standard」、2011年12月、<http://en.wikipedia.org/w/ index.php？title = Advanced_Encryption_Standard＆oldid = 481153988>。
[CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group (CFRG)", June 2011, <http://irtf.org/cfrg>.
[CFRG] McGrew（議長）、D。、「IRTF暗号フォーラム研究グループ（CFRG）」、2011年6月、<http://irtf.org/cfrg>。
[Clausen] Clausen, T. and U. Herberg, "Some Considerations on Routing in Particular and Lossy Environments", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/wp-content/IAB-uploads/ 2011/03/Herberg.pdf>.
[Clausen] Clausen、T.およびU. Herberg、「特定の損失の多い環境でのルーティングに関するいくつかの考慮事項」、IAB Interconnecting Smart Objects with the Internet Workshop、プラハ、チェコ共和国、2011年3月、<http：//www.iab。 org / wp-content / IAB-uploads / 2011/03 / Herberg.pdf>。
[CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, October 2011.
[CoAP] Shelby、Z.、Hartke、K.、Bormann、C.、およびB. Frank、「Constrained Application Protocol（CoAP）」、Work in Progress、2011年10月。
[CoAP-CC] Eggert, L., "Congestion Control for the Constrained Application Protocol (CoAP)", Work in Progress, January 2011.
[CoAP-CC] Eggert、L。、「Constrained Application Protocol（CoAP）の輻輳制御」、Work in Progress、2011年1月。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, December 2011.
[DNS-SD] Cheshire、S.およびM. Krochmal、「DNS-based Service Discovery」、Work in Progress、2011年12月。
[Dolin] Dolin, B., "Application Communications Requirements for 'The Internet of Things'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/ wp-content/IAB-uploads/2011/03/Dolin.pdf>.
[Dolin] Dolin、B。、「「Internet of Things」のアプリケーション通信要件」、スマートオブジェクトとインターネットワークショップを相互接続するIAB、プラハ、チェコ共和国、2011年3月、<http://www.iab.org/ wp -content / IAB-uploads / 2011/03 / Dolin.pdf>。
[ECC] Wikipedia, "Elliptic Curve Cryptography", December 2011, <http://en.wikipedia.org/w/ index.php?title=Elliptic_curve_cryptography& oldid=480053167>.
[ECC] Wikipedia、「Elliptic Curve Cryptography」、2011年12月、<http://en.wikipedia.org/w/ index.php？title = Elliptic_curve_cryptography＆oldid = 480053167>。
[ENERGY-PRICING] Jennings, C. and B. Nordman, "Communication of Energy Price Information", Work in Progress, July 2011.
[ENERGY-PRICING] Jennings、C。およびB. Nordman、「Communication of Energy Price Information」、Work in Progress、2011年7月。
[ENROLL] "The ietf-enroll Archives", <http://mailman.mit.edu/pipermail/ietf-enroll/>.
[ENROLL]「ietf-enroll Archives」、<http://mailman.mit.edu/pipermail/ietf-enroll/>。
[Ersue] Ersue, M. and J. Korhonen, "Position Paper on 'Interconnecting Smart Objects with the Internet'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, February 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Ersue.pdf>.
[Ersue] Ersue、M。、およびJ. Korhonen、「「インターネットとスマートオブジェクトの相互接続」に関するポジションペーパー」、IABスマートオブジェクトとインターネットワークショップの相互接続ワークショップ、プラハ、チェコ共和国、2011年2月、<http：// www。 iab.org/wp-content/IAB-uploads/2011/03/ Ersue.pdf>。
[GEOPRIV] IETF, "Geographic Location/Privacy (geopriv) Working Group", <http://datatracker.ietf.org/wg/geopriv/>.
[GEOPRIV] IETF、「地理的位置/プライバシー（geopriv）ワーキンググループ」、<http://datatracker.ietf.org/wg/geopriv/>。
[HOMENET] "Home Networking (homenet) Working Group", <http://datatracker.ietf.org/wg/homenet>.
[HOMENET]「ホームネットワーキング（homenet）ワーキンググループ」、<http://datatracker.ietf.org/wg/homenet>。
[IoT-ARCH] Hui, J. and J. Vasseur, "Routing Architecture in Low-Power and Lossy Networks (LLNs)", Work in Progress, March 2011.
[IoT-ARCH] Hui、J。およびJ. Vasseur、「低電力および損失の多いネットワーク（LLN）におけるルーティングアーキテクチャ」、進行中の作業、2011年3月。
[LWIG] IETF, "Light-Weight Implementation Guidance (lwig) Working Group", June 2011, <http://datatracker.ietf.org/wg/lwig/charter/>.
[LWIG] IETF、「軽量実装ガイダンス（lwig）ワーキンググループ」、2011年6月、<http://datatracker.ietf.org/wg/lwig/charter/>。
[MINIMAL-IKEv2] Kivinen, T., "Minimal IKEv2", Work in Progress, February 2011.
[MINIMAL-IKEv2] Kivinen、T。、「Minimal IKEv2」、Work in Progress、2011年2月。
[PROT-SURVEY] Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Work in Progress, April 2009.
[PROT-SURVEY] Tavakoli、A.、Dawson-Haggerty、S。、およびP. Levis、「Overview of Existing Routing Protocols for Low Power and Lossy Networks」、Work in Progress、2009年4月。
[RECIPE] "Reducing Energy Consumption with Internet Protocols Exploration (RECIPE) Mailing List", <https://www.ietf.org/mailman/listinfo/recipe>.
[レシピ]「インターネットプロトコル調査（RECIPE）メーリングリストによるエネルギー消費の削減」、<https://www.ietf.org/mailman/listinfo/recipe>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561] Perkins、C.、Belding-Royer、E。、およびS. Das、「Ad hoc On-Demand Distance Vector（AODV）Routing」、RFC 3561、2003年7月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101] Rescorla、E。およびIAB、「Writing Protocol Models」、RFC 4101、2005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「Detecting Network Attachment in IPv4（DNAv4）」、RFC 4436、2006年3月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806] Myers、M。およびH. Tschofenig、「IKEv2へのオンライン証明書ステータスプロトコル（OCSP）拡張」、RFC 4806、2007年2月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]ターラー、D。、「マルチリンクサブネットの問題」、RFC 4903、2007年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）」、RFC 5191、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548] Dohler、M.、Wattyne、T.、Winter、T。、およびD. Barthel、「Urban Low-Power and Lossy Networksのルーティング要件」、RFC 5548、2009年5月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673] Pister、K.、Thubert、P.、Dwars、S.、T。Phinney、「Industrial Routing Requirements in Low-Power and Lossy Networks」、RFC 5673、2009年10月。
[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., 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.、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、2010年6月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059] Krishnan、S.およびG. Daley、「Simple Procedures Detecting Network Attachment in IPv6」、RFC 6059、2010年11月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、2011年3月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011.
[RFC6272]ベイカー、F。およびD.マイヤー、「スマートグリッドのためのインターネットプロトコル」、RFC 6272、2011年6月。
[RPL] Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. Winter, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", Work in Progress, March 2011.
[RPL] Brandt、A.、Vasseur、J.、Hui、J.、Pister、K.、Thubert、P.、Levis、P.、Struik、R.、Kelsey、R.、Clauseen、T.、T 。Winter、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、進行中の作業、2011年3月。
[SHA3] NIST, "Cryptographic Hash Algorithm Competition", December 2010, <http://csrc.nist.gov/groups/ST/ hash/sha-3/index.html>.
[SHA3] NIST、「Cryptographic Hash Algorithm Competition」、2010年12月、<http://csrc.nist.gov/groups/ST/ hash / sha-3 / index.html>。
[SNMP-OPT] Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP Optimizations for Constrained Devices", Work in Progress, October 2010.
[SNMP-OPT] Schoenwaelder、J.、Mukhtar、H.、Joo、S。、およびK. Kim、「SNMPデバイスの最適化」、Work in Progress、2010年10月。
[Schoenwaelder] Schoenwaelder, J., Tsou, T., and B. Sarikaya, "Protocol Profiles for Constrained Devices", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, February 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Schoenwaelder.pdf>.
[Schoenwaelder] Schoenwaelder、J.、Tsou、T。、およびB. Sarikaya、「制約付きデバイスのプロトコルプロファイル」、IABスマートオブジェクトとインターネットワークショップの相互接続、プラハ、チェコ共和国、2011年2月、<http：// www。 iab.org/wp-content/IAB-uploads/2011/03/ Schoenwaelder.pdf>。
[SmartGrid] Wikipedia, "Smart Grid", December 2011, <http://en.wikipedia.org/w/ index.php?title=Smart_grid&oldid=479750548>.
[SmartGrid] Wikipedia、「Smart Grid」、2011年12月、<http://en.wikipedia.org/w/ index.php？title = Smart_grid＆oldid = 479750548>。
[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", In Proc. ACM SIGCOMM, 2002, <http://conferences.sigcomm.org/sigcomm/2002/ papers/tussle.html>.
[タスル]クラークD.、ブロツラフJ.、ソリンズK.、およびR.ブレーデン、「サイバースペースにおけるタスル：明日のインターネットの定義」、Proc。 ACM SIGCOMM、2002、<http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.html>。
[Wasserman] Wasserman, M., "It's Not Easy Being 'Green'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Wasserman.pdf>.
[ワッサーマン] Wasserman、M.、「「グリーン」になるのは簡単ではない」、IABスマートオブジェクトとインターネットワークショップの相互接続、プラハ、チェコ共和国、2011年3月、<http://www.iab.org/wp-content/ IAB-uploads / 2011/03 / Wasserman.pdf>。
[irtf-discuss] Ohlman, B., "Draft ICN RG Charter", message to IRTF DISCUSS Mailing List, May 2011, <http://www.ietf.org/mail-archive/web/irtf-discuss/ current/msg00041.html>.
[irtf-discuss] Ohlman、B.、「ドラフトICN RGチャーター」、IRTF DISCUSSメーリングリストへのメッセージ、2011年5月、<http://www.ietf.org/mail-archive/web/irtf-discuss/ current / msg00041.html>。
[proxZzzy] ECMA, "proxZzzy(TM) for sleeping hosts", Standard ECMA-393, February 2010, <http://www.ecma-international.org/publications/ standards/Ecma-393.htm>.
[proxZzzy] ECMA、「スリープ状態のホスト用のproxZzzy（TM）」、標準ECMA-393、2010年2月、<http://www.ecma-international.org/publications/standards/Ecma-393.htm>。
The following persons are responsible for the organization of the associated workshop and are responsible also for this event: Jari Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David Culler, Lars Eggert, JP. Vasseur, Stewart Bryant, Adrian Farrel, Ralph Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Jennings, Manfred Hauswirth, and Lukas Kencl.
関連するワークショップの組織とこのイベントの責任者は、Jari Arkko、Hannes Tschofenig、Bernard Aboba、Carsten Bormann、David Culler、Lars Eggert、JPです。ヴァッサー、スチュワートブライアント、エイドリアンファレル、ラルフドロムス、ジェフリーマリガン、アレクセイメルニコフ、ピーターサンタンドレ、マルセロバグロ、ザックシェルビー、イシドロバレステロスラソ、フレッドベイカー、カレンジェニングス、マンフレッドハウスワース、ルーカスケンクル。
Main page:
http://www.iab.org/about/workshops/smartobjects/
Position papers:
http://www.iab.org/about/workshops/smartobjects/papers/
Slides:
http://www.iab.org/about/workshops/smartobjects/agenda/
Minutes:
http://www.iab.org/activities/workshops/smartobjects/
smartobjectworkshopmeetingminutes/
1. Deployment Experience with Low Power Lossy Wireless Sensor Networks" by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. Philipp, and G. Wittenburg
1. C. Adjih、E。Baccelli、P。Jacquet、P。Minet、M。Philipp、およびG. Wittenburgによる低電力損失ワイヤレスセンサーネットワークの導入経験」
2. CoAP improvements to meet embedded device hardware constraints" by Davide Barbieri
2. 組み込みデバイスのハードウェア制約を満たすためのCoAPの改善」Davide Barbieri著
3. "Unified Device Networking Protocols for Smart Objects" by Daniel Barisic and Anton Pfefferseder
3. 「スマートオブジェクト用の統合デバイスネットワーキングプロトコル」（ダニエルバリシックとアントンフェファーゼダー）
4. "Simplified neighbour cache implementation in RPL/6LoWPAN" by Dominique Barthel
4. Dominique Barthelによる「RPL / 6LoWPANでのネイバーキャッシュの実装の簡素化」
5. "Home Control in a consumer's perspective" by Anders Brandt
5. Anders Brandtによる「消費者の視点でのホームコントロール」
6. "Authoring Place-based Experiences with an Internet of Things: Tussles of Expressive, Operational, and Participatory Goals" by Jeff Burke
6. ジェフ・バークによる「モノのインターネットによる場所ベースのエクスペリエンスの作成：表現力豊か、運用、参加型の目標の闘い」
7. "A Dynamic Distributed Federated Approach for the Internet of Things" by Diego Casado Mansilla, Juan Ramon Velasco Perez, and Mario Lopez-Ramos
7. 「モノのインターネットのための動的分散型フェデレーテッドアプローチ」Diego Casado Mansilla、Juan Ramon Velasco Perez、Mario Lopez-Ramos
8. "Quickly interoperable Internet of Things using simple transparent gateways" by Angelo P. Castellani, Salvatore Loreto, Nicola Bui, and Michele Zorzi
8. Angelo P. Castellani、Salvatore Loreto、Nicola Bui、Michele Zorziによる「シンプルで透過的なゲートウェイを使用した、迅速に相互運用可能なモノのインターネット」
9. "Position Paper of the Brno University of Technology Department of Telecommunications" by Vladimir Cervenka, Lubomir Mraz, Milan Simek, and Karel Pavlata
9. 「ブルノ工科大学通信学科のポジションペーパー」ウラジミール・セルヴェンカ、ルボミール・ムラーズ、ミラン・シメック、カレル・パヴラタ
10. "Secure Access to IOT Network: An Application-based Group Key Approach" by Samita Chakrabarti and Wassim Haddad
10. Samita ChakrabartiとWassim Haddadによる「IOTネットワークへの安全なアクセス：アプリケーションベースのグループキーアプローチ」
11. "Domain-Insulated Autonomous Network Architecture (DIANA)" by W. Chun
11. W. Chunによる「ドメイン分離自律ネットワークアーキテクチャ（DIANA）」
12. "Yet Another Definition on Name, Address, ID, and Locator (YANAIL)" by W. Chun
12. W.チュンによる「名前、住所、ID、およびロケーターに関する別の定義（YANAIL）」
13. "The Challenge of Mobility in Low Power Networks" by E. Davies
13. E. Daviesによる「低電力ネットワークにおけるモビリティの課題」
14. "If the routing protocol is so smart, why should neighbour discovery be so dumb?" by Nicolas Dejean
14. 「もしルーティングプロトコルがとても賢いなら、なぜネイバーディスカバリーはそんなに馬鹿げているのでしょうか？」ニコラ・デジャン
15. "Making Smart Objects IPv6 Ready: Where are we?" by M. Durvy and M. Valente
15. 「IPv6対応のスマートオブジェクトの作成：どこにいるの？」 M.ダービーとM.ヴァレンテ
16. "Position Paper on 'Interconnecting Smart Objects with the Internet'" by Mehmet Ersue and Jouni Korhonen
16. 「インターネットとスマートオブジェクトを相互接続することに関するポジションペーパー」Mehmet ErsueおよびJouni Korhonen
17. "The Real-time Enterprise: IoT-enabled Business Processes" by Stephan Haller and Carsten Magerkurth
17. Stephan HallerとCarsten Magerkurthによる「The Real-time Enterprise：IoT-enabled Business Processs」
18. "Making Internet-Connected Objects readily useful" by Manfred Hauswirth, Dennis Pfisterer, and Stefan Decker
18. Manfred Hauswirth、Dennis Pfisterer、Stefan Deckerによる「インターネットに接続されたオブジェクトをすぐに使えるようにする」
19. "Some Considerations on Routing in Particular and Lossy Environments" by Thomas Clausen and Ulrich Herberg
19. 「特定の損失の多い環境でのルーティングに関するいくつかの考慮事項」Thomas ClausenおよびUlrich Herberg著
20. "A Security Protocol Adaptation Layer for the IP-based Internet of Things" by Rene Hummen, Tobias Heer, and Klaus Wehrle
20. 「IPベースのモノのインターネットのためのセキュリティプロトコル適応レイヤー」Rene Hummen、Tobias Heer、Klaus Wehrle
21. "Simplified SIP Approach for the Smart Object" by Ryota Ishibashi, Takumi Ohba, Arata Koike, and Akira Kurokawa
21. ”しｍｐぃふぃえｄ しＰ あっｐろあｃｈ ふぉｒ てぇ Ｓまｒｔ おｂじぇｃｔ” ｂｙ りょた いしばし、 たくみ おｈば、 あらた こいけ、 あんｄ あきら くろかわ
22. "Mobility support for the small and smart Future Internet devices" by Antonio J. Jara and Antonio F. G. Skarmeta
22. Antonio J. JaraとAntonio F. G. Skarmetaによる「小さくてスマートな将来のインターネットデバイスのモビリティサポート」
23. "The Need for Efficient Reliable Multicast in Smart Grid Networks" by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk
23. 「スマートグリッドネットワークにおける効率的な信頼性の高いマルチキャストの必要性」J. Jetcheva、D。Popa、M.G。スチューバー、H。ヴァンウィック
24. "Lightweight Cryptography for the Internet of Things" by Masanobu Katagi and Shiho Moriai
24. 「モノのインターネットのための軽量暗号」片木政信、森居志穂
25. "Thoughts on Reliability in the Internet of Things" by James Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli
25. ジェームズケンプ、ジャリアラコ、今日のベヘシティ、およびキランエダバリによる「モノのインターネットの信頼性に関する考え」
26. "IKEv2 and Smart Objects" by Tero Kivinen
26. Tero Kivinenによる「IKEv2とスマートオブジェクト」
27. "Position Paper on Thing Name Service (TNS) for the Internet of Things (IoT)" by Ning Kong and Shuo Shen
27. Ning KongとShuo Shenによる「モノのインターネット（IoT）向けのThing Name Service（TNS）に関するポジションペーパー」
28. "Connecting Smart Objects to Wireless WANs" by Suresh Krishnan
28. 「スマートオブジェクトをワイヤレスWANに接続する」Suresh Krishnan著
29. "Towards an Information-Centric Internet with more Things" by D. Kutscher and S. Farrell
29. D. KutscherおよびS. Farrellによる「より多くの情報を備えた情報中心のインターネットに向けて」
30. "Application of 6LoWPAN for the Real-Time Positioning of Manufacturing Assets" by Jaacan Martinez and Jose L. M. Lastra
30. Jaacan MartinezおよびJose L. M. Lastraによる「製造資産のリアルタイムポジショニングへの6LoWPANの適用」
31. "Lighting interface to wireless network" by Jaroslav Meduna
31. Jaroslav Medunaによる「ワイヤレスネットワークへの照明インターフェース」
32. "Social-driven Internet of Connected Objects" by Paulo Mendes
32. パウロメンデスによる「接続されたオブジェクトの社会主導型インターネット」
33. "Protocols should go forward that are required by non IP based protocols" by Tsuyoshi Momose
33. 百瀬剛による「非IPベースのプロトコルに必要なプロトコルは前進すべき」
34. "Web services for Wireless Sensor and Actuator Networks" by Guido Moritz
34. Guido Moritzによる「ワイヤレスセンサーおよびアクチュエータネットワーク用のWebサービス」
35. "Connecting BT-LE sensors to the Internet using Ipv6" by Markus Isomaki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, and Zach Shelby
35. Markus Isomaki、Kanji Kerai、Jari Mutikainen、Johanna Nieminen、Basavaraj Patil、Teemu Savolainen、Zach Shelbyによる「IPv6を使用したBT-LEセンサーのインターネットへの接続」
36. "Building Networks" by Bruce Nordman
36. ブルース・ノードマンによる「ネットワークの構築」
37. "Issues and Challenges in Provisioning Keys to Smart Objects" by Yoshihiro Ohba and Subir Das
37. 「スマートオブジェクトのキーをプロビジョニングする際の問題と課題」Ohba Yoshihiro and Subir Das
38. "Challenges and Solutions of Secure Smart Environments" by Eila Ovaska and Antti Evesti
38. Eila OvaskaとAntti Evestiによる「安全なスマート環境の課題とソリューション」
39. "Research Experiences about Internetworking Mechanisms to Integrate Embedded Wireless Networks into Traditional Networks" by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar
39. 「組み込み無線ネットワークを従来のネットワークに統合するためのインターネットワーキングメカニズムに関する研究経験」Jose F. Martinez、Ivan Corredor、およびMiguel S. Familiar
40. "Scalable Video Coding in Networked Environment" by Naeem Ramzan, Tomas Piatrik, and Ebroul Izquierdo
40. Naeem Ramzan、Tomas Piatrik、およびEbroul Izquierdoによる「ネットワーク環境でのスケーラブルビデオコーディング」
41. "Challenges in Opportunistic Networking" by Mikko Pitkaenen and Teemu Kaerkkaeinen
41. Mikko PitepoolenとTeemu Kaerkkaeinenによる「日和見ネットワーキングの課題」
42. "Position Statement" by Neeli R. Prasad and Sateesh Addepalli
42. Blue R.による「ポジションステートメント」プラサードとサティッシュ
43. "A Gateway Architecture for Interconnecting Smart Objects to the Internet" by Akbar Rahman, Dorothy Gellert, Dale Seed
43. 「スマートオブジェクトをインターネットに相互接続するためのゲートウェイアーキテクチャ」Akbar Rahman、Dorothy Gellert、Dale Seed
44. "Routing Challenges and Directions for Smart Objects in Future Internet of Things" by T. A. Ramrekha, E. Panaousis, and C. Politis
44. T. A. Ramrekha、E。Panaousis、およびC. Politisによる「将来のモノのインターネットにおけるスマートオブジェクトのルーティングの課題と方向性」
45. "6LoWPAN Extension for IPsec" by Shahid Raza, Thiemo Voigt, and Utz Roedig
45. Shahid Raza、Thiemo Voigt、およびUtz Roedigによる「IPsecの6LoWPAN拡張機能」
46. "Connected Vehicle as Smart Object(s)" by Ryuji Wakikawa
46. 脇川隆二「スマートオブジェクトとしてのコネクティッドカー」
47. "Problem and possible approach of development and operation of Smart Objects" by Shoichi Sakane
47. 坂根翔一著「スマートオブジェクトの開発と運用の課題と可能性」
48. "Connecting Passive RFID Tags to the Internet of Things" by Sandra Dominikus and Joern-Marc Schmidt
48. Sandra DominikusとJoern-Marc Schmidtによる「パッシブRFIDタグのモノのインターネットへの接続」
49. "Protocol Profiles for Constrained Devices" by Juergen Schoenwaelde, Tina Tsou, and Behcet Sarikaya
49. Juergen Schoenwaelde、Tina Tsou、およびBehcet Sarikayaによる「制約付きデバイスのプロトコルプロファイル」
50. "Multihoming for Sensor Networks" by J. Soininen
50. J. Soininenによる「センサーネットワークのマルチホーミング」
51. "Internet Objects for Building Control" by Peter van der Stok and Nicolas Riou
51. 「制御を構築するためのインターネットオブジェクト」、Peter van der StokおよびNicolas Riou著
52. "Optimal information placement for Smart Objects" by Shigeya Suzuki
52. 鈴木重也による「スマートオブジェクトの最適な情報配置」
53. "Multi-National Initiative for Cloud Computing in Health Care (MUNICH)" by Christoph Thuemmler
53. Christoph Thuemmlerによる「医療におけるクラウドコンピューティングのための多国籍イニシアチブ（MUNICH）」
54. "The time of the hourglass has elapsed" by Laurent Toutain, Nicolas Montavont, and Dominique Barthel
54. 「砂時計の時が過ぎた」ローラン・トゥテイン、ニコラ・モンタボン、ドミニク・バルテル
55. "Sensor and Actuator Resource Architecture" by Vlasios Tsiatsis, Jan Hoeller, and Richard Gold
55. Vlasios Tsiatsis、Jan Hoeller、およびRichard Goldによる「センサーおよびアクチュエータリソースアーキテクチャ」
56. "IT'S NOT EASY BEING 'GREEN'" by Margaret Wasserman
56. 「IT'S NOT EASY BEING 'GREEN'」マーガレットワッサーマン
57. "Trustworthy Wireless Industrial Sensor Networks" by Markus Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis Olivereau, and Oualha Nouha
57. Markus Wehner、Thomas Bartzsch、Dirk Burggraf、Sven Zeisberg、Alexis Olivereau、Oualha Nouhaによる「信頼できるワイヤレス産業用センサーネットワーク」
58. "Interconnecting smart objects through an overlay networking architecture" by Anastasios Zafeiropoulos, Athanassios Liakopoulos and Panagiotis Gouvas
58. Anastasios Zafeiropoulos、Athanassios Liakopoulos、Panagiotis Gouvasによる「オーバーレイネットワークアーキテクチャによるスマートオブジェクトの相互接続」
59. "Building trust among Virtual Interconnecting Smart Objects in the Future Internet" by Theodore Zahariadic, Helen C. Leligou, Panagiotis Trakadas, and Mischa Dohler
59. 「将来のインターネットにおける仮想相互接続スマートオブジェクト間の信頼関係の構築」、Theodore Zahariadic、Helen C. Leligou、Panagiotis Trakadas、Mischa Dohler
60. "Experience and Challenges of Integrating Smart Devices with the Mobile Internet" by Zhen Cao and Hui Deng
60. Zhen CaoおよびHui Dengによる「スマートデバイスとモバイルインターネットの統合の経験と課題」
61. "The 'mesh-under' versus 'route over' debate in IP Smart Objects Networks" by JP. Vasseur and Jonathan Hui
61. 「IPスマートオブジェクトネットワークにおける「メッシュアンダー」と「ルートオーバー」の論争」JPによる。ヴァッサーとジョナサン・フイ
62. "Identification and Authentication of IoT Devices" by Alper Yegin
62. Alper Yeginによる「IoTデバイスの識別と認証」
63. "Security Challenges For the Internet of Things" by Tim Polk and Sean Turner
63. ティム・ポークとショーン・ターナーによる「モノのインターネットのためのセキュリティの課題」
64. "Application Communications Requirements for 'The Internet of Things'" by Bob Dolin
64. 「「モノのインターネット」のアプリケーション通信要件」（Bob Dolin著）
65. "Interoperability Concerns in the Internet of Things" by Jari Arkko
65. 「モノのインターネットにおける相互運用性の問題」Jari Arkko著
66. "Privacy in Ubiquitous Computing" by Ivan Gudymenko and Katrin Borcea-Pfitzmann
66. 「ユビキタスコンピューティングにおけるプライバシー」、Ivan GudymenkoとKatrin Borcea-Pfitzmannによる
67. "The 10 Laws of Smart Object Security Design" by Hannes Tschofenig and Bernard Aboba
67. Hannes TschofenigおよびBernard Abobaによる「スマートオブジェクトセキュリティ設計の10の法則」
68. "Position Paper on 'In-Network Object Cloud' Architecture and Design Goals" by Alex Galis and Stuart Clayman
68. アレックスガリスとスチュアートクレイマンによる「「ネットワークオブジェクトクラウド」のアーキテクチャと設計目標に関するポジションペーパー」
69. "Temptations and Difficulties of Protocols for Smart Objects and the Internet" by Alexandru Petrescu
69. 「スマートオブジェクトとインターネットのためのプロトコルの誘惑と困難」アレクサンドル・ペトレスクによる
70. "The Internet of Things - Challenge for a New Architecture from Problems" by Gyu Myoung Lee and Noel Crespi
70. 「モノのインターネット-問題からの新しいアーキテクチャへの挑戦」Gyu Myoung LeeとNoel Crespi
71. "Garrulity and Fluff" by Carsten Bormann and Klaus Hartke
71. Carsten BormannとKlaus Hartkeによる「Garrity and Fluff」
We would like to than the following workshop participants for attending the workshop:
ワークショップへの参加には、以下のワークショップ参加者よりもお願いします。
Adrian Farrel Akbar Rahman Alissa Cooper Alper Yegin Anastasios Zafeiropoulos Anders Brandt Angelo P. Castellani Antonio F. G. Skarmeta Antonio Jara Arvind Ramrekha Behcet Sarikaya Bernard Aboba Bruce Nordman Carsten Bormann Cullen Jennings Daniel Barisic Dave Thaler Davide Barbieri Diego Casado Mansilla Dirk Kutscher Dominique Barthel Dorothy Gellert Elwyn Davis Emmanuel Baccelli Fred Baker Guido Moritz Gyu Myoung Lee Hannes Tschofenig Hui Deng Ivan Gudymenko Jaacan Martinez Jari Arkko Jaroslav Meduna Jeff Burke Johanna Nieminen Jonathan Hui Jonne Soininen Jouni Korhonen JP. Vasseur Karel Pavlata Klaus Hartke Lars Eggert Laura Gheorghe Laurent Toutain Lukas Kencl Marcelo Bagnulo Marco Valente Margaret Wasserman Markus Isomaki Markus Wehner Masanobu Katagi Mathilde Durvy Mehmet Ersue Mikko Pitkaenen Milan Simek Neeli R. Prasad Nicolas Dejean Ning Kong Pascal Thubert Paulo Mendes Pete Resnick Peter van der Stok Ralph Droms Rene Hummen Ross Callon Ruediger Martin Russ Housley Ryota Ishibashi Ryuji Wakikawa Samita Chakrabarti Sandra Dominikus Sean Shen Sean Turner Shahid Raza Shoichi Sakane Spencer Dawkins Stephan Haller Stephen Farrell Stewart Bryant Subir Das Suresh Krishnan Tea Sang Choi Tero Kivinen Theodore Zahariadis Thomas Clausen Tim Polk Tina Tsou Tsuyoshi Momose Vladimir Cervenka Wassim Haddad Woojik Chun Zach Shelby
エイドリアン・ファレルアクバーラフマンアリッサクーパーアルパーイェージンアナスタシオスザフェイロポウロスアンダースブラントアンジェロP.カステラーニアントニオFGスカルメタアントニオジャラアーヴィンドラムレカベーチェットサリカヤバーナードアボバブルースノードマンカルステンボルマンカレンジェニングスダニエルバリジックデイブターラーディラカービエディカービエディカービエディエマニュエルバチェッリフレッドベイカーグイドモリッツギュミョンリーハンネスショフェニグフイデンイヴァングディメンコジャカンマルティネスジャリアルコジャロスラフメドゥナジェフバークジョアンナニエミネンジョナサンホイジョンゾイニネンジョーニコロネンJP。ヴァスールカレルパヴラタクラウスハートケラースエガートローラゲオルグローレントトゥルーテンルーカスケンクルマルセロバグロマルコヴァレンテマーガレットワッサーマンマーカスイソマキマーカスウェナーカタギマタノブカタギマティルドダービーメフメットエルスエメスミラノ出身サイメックニーリ・コンカルデ・カルサニコラス・パサーフニコラスStok Ralph Droms Rene Hummen Ross Callon Ruediger Martin Russ Housley Ryota Ishibashi Ryuji Wakikawa Samita Chakrabarti Sandra Dominikus Sean Shen Sean Turner Shahid Raza Shokane Sakane Spencer Dawkins Stephan Haller Stephen Farrell Stewart Bryant Subir Das Suresh Kティナ・ツォウ・モモセ・ウラジミール・セルヴェンカ・ワッシム・ハダッド・ウージク・チュン・ザック・シェルビー
Bernard Aboba Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
バーナードアボバロスカロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーデビッドケセンオラフコルクマンダニーマクファーソンジョンピーターソンアンドレイロバチェフスキーデイブターラーハネスショーネ
Authors' Addresses
著者のアドレス
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Internet Architecture Board
インターネットアーキテクチャボード
EMail: iab@iab.org