[要約] RFC 7650は、RELOADのためのCoAPの使用方法を定義しており、リソースの場所と検出に関するプロトコルを提供します。目的は、制約のある環境でのリソースの効率的な管理と検出を可能にすることです。
Internet Engineering Task Force (IETF) J. Jimenez
Request for Comments: 7650 Ericsson
Category: Standards Track J. Lopez-Vega
ISSN: 2070-1721 University of Granada
J. Maenpaa
G. Camarillo
Ericsson
September 2015
A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
REsource LOcation And Discovery（RELOAD）の制約付きアプリケーションプロトコル（CoAP）の使用法
Abstract
概要
This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.
このドキュメントでは、リソースの位置特定と検出（RELOAD）のための制約付きアプリケーションプロトコル（CoAP）の使用法を定義します。 CoAP Usageは、ワイヤレスセンサーネットワーク（WSN）をピアツーピア方式で統合する機能を提供します。 RELOADのCoAPの使用により、CoAPノードはリソースをRELOADピアツーピアオーバーレイに格納し、ルックアップサービスを提供し、センサーデータのキャッシュとしてRELOADオーバーレイを使用できるようになります。この機能は、集中型サーバーを使用せずに、RELOADオーバーレイ自体に実装されています。 RELOAD AppAttachメソッドは、CoAPメッセージが交換されるノード間の直接接続を確立するために使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7650.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7650で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 7
5. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Forming a Direct Connection and Reading Data . . . . . . . . 9
7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 11
7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 13
8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 14
8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . 14
8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 15
9. Access Control Rules . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11.1. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . 17
11.2. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . 17
11.3. Access Control Policies . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers.
REsource LOcation And Discovery（RELOAD）のConstrained Application Protocol（CoAP）Usageにより、CoAPノードはリソースをRELOADピアツーピアオーバーレイに格納し、検索サービスを提供し、センサーデータのキャッシュとしてRELOADオーバーレイを使用できるようになります。この機能は、集中型サーバーを使用せずに、RELOADオーバーレイ自体に実装されています。
This usage is intended for interconnected devices over a wide-area geographical coverage, such as in cases where multiple Wireless Sensor Networks (WSNs) need to be federated over some wider-area network. These WSNs would interconnect by means of nodes that are equipped with long range modules (e.g., 2G, 3G, 4G) as well as short range ones (e.g., XBee, ZigBee, Bluetooth LE).
この使用法は、複数のワイヤレスセンサーネットワーク（WSN）をいくつかの広域ネットワーク上でフェデレーションする必要がある場合など、広域の地理的範囲にわたる相互接続されたデバイスを対象としています。これらのWSNは、長距離モジュール（2G、3G、4Gなど）と短距離モジュール（XBee、ZigBee、Bluetooth LEなど）を備えたノードによって相互接続します。
Constrained devices are likely to be heterogeneous when it comes to their radio layer; however, we expect them to use a common application-layer protocol -- CoAP, which is a specialized web transfer protocol [RFC7252]. It realizes the Representational State Transfer (REST) architecture for the most constrained nodes, such as sensors and actuators. CoAP can be used not only between nodes on the same constrained network but also between constrained nodes and nodes on the Internet. The latter is possible since CoAP can be translated to Hypertext Transfer Protocol (HTTP) for integration with the web. Application areas of CoAP include different forms of machine-to-machine (M2M) communication, such as home automation, construction, health care or transportation. Areas with heavy use of sensor and actuator devices that monitor and interact with the surrounding environment.
無線レイヤーに関しては、制約のあるデバイスは異種である可能性があります。ただし、一般的なアプリケーション層プロトコルであるCoAPを使用することを期待しています。これは、特殊なWeb転送プロトコルです[RFC7252]。これは、センサーやアクチュエーターなどの最も制約の多いノードに対して、Representational State Transfer（REST）アーキテクチャーを実現します。 CoAPは、同じ制約付きネットワーク上のノード間だけでなく、制約付きノードとインターネット上のノード間でも使用できます。 CoAPはWebと統合するためにハイパーテキスト転送プロトコル（HTTP）に変換できるため、後者が可能です。 CoAPのアプリケーション領域には、ホームオートメーション、建設、ヘルスケア、輸送など、マシンツーマシン（M2M）通信のさまざまな形式が含まれます。周辺環境を監視および操作するセンサーおよびアクチュエーターデバイスが頻繁に使用される領域。
As specified in [RFC6940], RELOAD is fundamentally an overlay network. It provides a layered architecture with pluggable application layers that can use the underlaying forwarding, storage, and lookup functionalities. Figure 1 illustrates where the CoAP Usage is placed within the RELOAD architecture.
[RFC6940]で指定されているように、RELOADは基本的にオーバーレイネットワークです。これは、基礎となる転送、ストレージ、およびルックアップ機能を使用できるプラグイン可能なアプリケーション層を備えた階層化アーキテクチャを提供します。図1は、CoAP UsageがRELOADアーキテクチャ内のどこに配置されるかを示しています。
Application
応用
+-------+
| CoAP | ...
| Usage |
+-------+
------------------------------------ Messaging Service
+------------------+ +---------+
| Message |<--->| Storage |
| Transport | +---------+
+------------------+ ^
^ ^ |
| v v
| +-------------------+
| | Topology |
| | Plug-in |
| +-------------------+
| ^
v v
+------------------+
| Forwarding & |
| Link Management |
+------------------+
------------------------------------ Overlay Link Service
+-------+ +-------+
|TLS | |DTLS | ...
|Overlay| |Overlay|
|Link | |Link |
+-------+ +-------+
Figure 1: Architecture
図1：アーキテクチャ
The CoAP Usage involves three basic functions:
CoAPの使用には、3つの基本機能が含まれます。
Registration: CoAP nodes that can use the RELOAD data storage functionality, can store a mapping from their CoAP URI to their Node-ID in the overlay. They can also retrieve the Node-IDs of other nodes. Nodes that are not RELOAD aware can use other mechanisms, for example [CORERESDIR] in their local network.
登録：RELOADデータストレージ機能を使用できるCoAPノードは、CoAP URIからNode-IDへのマッピングをオーバーレイに保存できます。また、他のノードのノードIDを取得することもできます。 RELOAD対応ではないノードは、ローカルネットワークの[CORERESDIR]などの他のメカニズムを使用できます。
Lookup: Once a CoAP node has identified the Node-ID for an URI it wishes to retrieve, it can use the RELOAD message routing system to set up a connection that can be used to exchange CoAP messages. Similarly as with the registration, nodes that are not RELOAD aware can use CoAP messages with a RELOAD Node (RN) that will in turn perform the lookup in the overlay.
ルックアップ：CoAPノードは、取得したいURIのノードIDを特定すると、RELOADメッセージルーティングシステムを使用して、CoAPメッセージの交換に使用できる接続を設定できます。登録の場合と同様に、RELOAD対応でないノードは、オーバーレイでルックアップを実行するRELOADノード（RN）を使用してCoAPメッセージを使用できます。
Caching: Nodes can use the RELOAD overlay as a caching mechanism for information about what CoAP resources are available on the node. This is especially useful for power-constrained nodes that can make their data available in the cache provided by the overlay while in sleep mode.
キャッシング：ノードは、ノードで使用可能なCoAPリソースに関する情報のキャッシングメカニズムとしてRELOADオーバーレイを使用できます。これは、スリープモードのときにオーバーレイによって提供されるキャッシュでデータを使用できるようにする、電力に制約のあるノードで特に役立ちます。
For instance, a CoAP proxy (See Section 3) could register its Node-ID (e.g. "9996172") and a list of sensors (e.g. "/sensors/temp-1; /sensors/temp-2; /sensors/light, /sensors/humidity") under its URI (e.g. "coap://overlay-1.com/proxy-1/").
たとえば、CoAPプロキシ（セクション3を参照）は、そのノードID（「9996172」など）とセンサーのリスト（「/ sensors / temp-1; / sensors / temp-2; / sensors / light、 / sensors / humidity "）をそのURIで（例：" coap：//overlay-1.com/proxy-1/ "）
When a node wants to discover the values associated with that URI, it queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back the Node-ID of the proxy and the list of its associated sensors. The requesting node can then use the RELOAD overlay to establish a direct connection with the proxy and to read sensor values.
ノードがそのURIに関連付けられた値を検出する場合、「coap：//overlay-1.com/proxy-1/」のオーバーレイをクエリし、プロキシのノードIDとその関連リストを取得しますセンサー。要求側ノードは、RELOADオーバーレイを使用して、プロキシとの直接接続を確立し、センサー値を読み取ることができます。
Moreover, the CoAP proxy can store the sensor information in the overlay. In this way, information can be retrieved directly from the overlay without performing a direct connection to the storing proxy.
さらに、CoAPプロキシはセンサー情報をオーバーレイに保存できます。このようにして、格納プロキシへの直接接続を実行することなく、情報をオーバーレイから直接取得できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
We use the terminology and definitions from the RELOAD Base Protocol [RFC6940] extensively in this document. Some of those concepts are further described in the "Concepts and Terminology for Peer to Peer SIP" [P2PSIP] document.
このドキュメントでは、RELOADベースプロトコル[RFC6940]の用語と定義を広く使用しています。これらの概念の一部は、「ピアツーピアSIPの概念と用語」[P2PSIP]ドキュメントでさらに説明されています。
In our architecture we extend the different nodes present in RELOAD (Peer, Client) and add support for sensor devices or other constrained devices. Figure 2 illustrates the overlay topology. The different nodes, according to their functionality, are:
私たちのアーキテクチャでは、RELOAD（ピア、クライアント）に存在するさまざまなノードを拡張し、センサーデバイスまたは他の制約されたデバイスのサポートを追加します。図2は、オーバーレイトポロジを示しています。機能に応じたさまざまなノードは次のとおりです。
Client As specified in [RFC6940], clients are nodes that do not have routing or storage responsibilities in the Overlay.
クライアント[RFC6940]で指定されているように、クライアントはオーバーレイでルーティングまたはストレージの責任を持たないノードです。
Peer As specified in [RFC6940], peers are nodes in the overlay that can route messages for nodes other than those to which it is directly connected.
ピア[RFC6940]で指定されているように、ピアは、直接接続されているノード以外のノードにメッセージをルーティングできるオーバーレイのノードです。
Sensor Devices capable of measuring a physical quantity. Sensors usually acquire quantifiable information about their surrounding environment such as: temperature, humidity, electric current, moisture, radiation, and so on.
物理量を測定できるセンサーデバイス。センサーは通常、周囲の環境に関する定量化可能な情報（温度、湿度、電流、湿気、放射線など）を取得します。
Actuator Devices capable of interacting and affecting their environment such as: electrical motors, pneumatic actuators, electric switches, and so on.
電気モーター、空気圧アクチュエータ、電気スイッチなど、環境と相互作用して影響を与えることができるアクチュエータデバイス。
Proxy Node Devices having sufficient resources to run RELOAD either as client or peer. These devices are located at the edge of the sensor network and, in case of Wireless Sensor Networks (WSN), act as coordinators of the network.
クライアントまたはピアとしてRELOADを実行するのに十分なリソースを持つプロキシノードデバイス。これらのデバイスはセンサーネットワークのエッジにあり、ワイヤレスセンサーネットワーク（WSN）の場合、ネットワークのコーディネーターとして機能します。
Physical devices can have one or several of the previous functional roles. According to the functionalities that are present in each of the nodes, they can be:
物理デバイスは、以前の機能上の役割の1つまたはいくつかを持つことができます。各ノードに存在する機能に従って、それらは次のいずれかになります。
Constrained Node A Constrained Node (CN) is a node with limited computational capabilities. CN devices belong to classes of at least C1 and C2 devices as defined in [RFC7228], their main constraint being the implementation of the CoAP protocol. If the CN is wireless, then it will be part of a Low-Rate Wireless Personal Area Network (LR-WPAN), also termed Low-Power and Lossy Network (LLN). Lastly, devices will usually be in sleep mode in order to prevent battery drain, and will not communicate during those periods. A CN is NOT part of the RELOAD overlay, therefore it cannot act as a client, peer, nor proxy. A CN is always either a Sensor or an Actuator. In the latter case, the node is often connected to a continuous energy power supply.
制約付きノード制約付きノード（CN）は、計算機能が制限されたノードです。 CNデバイスは、[RFC7228]で定義されているように、少なくともC1およびC2デバイスのクラスに属し、その主な制約はCoAPプロトコルの実装です。 CNがワイヤレスの場合、それは低レートワイヤレスパーソナルエリアネットワーク（LR-WPAN）の一部となり、低電力および損失の多いネットワーク（LLN）とも呼ばれます。最後に、デバイスは通常、バッテリーの消耗を防ぐためにスリープモードになり、その間は通信しません。 CNはRELOADオーバーレイの一部ではないため、クライアント、ピア、プロキシとして機能できません。 CNは常にセンサーまたはアクチュエータのいずれかです。後者の場合、ノードは多くの場合、連続エネルギー電源に接続されます。
RELOAD Node A RELOAD Node (RN) MUST implement the client functionality in the Overlay. Additionally, the node will often be a full RELOAD peer. An RN may also be sensor or actuator since it can have those devices connected to it.
RELOADノードRELOADノード（RN）は、オーバーレイにクライアント機能を実装する必要があります。さらに、ノードは多くの場合、完全なRELOADピアになります。 RNは、それらのデバイスを接続できるため、センサーまたはアクチュエーターになることもあります。
Proxy Node A Proxy Node (PN) MUST implement the RN functionality and act as a sink for the LR-WPAN network. The PN connects the short range Wireless Network to the Wide Area Network or the Internet. A Proxy Node fulfills the "Proxy Node" role as described previously in the Architecture.
プロキシノードプロキシノード（PN）は、RN機能を実装し、LR-WPANネットワークのシンクとして機能する必要があります。 PNは、短距離無線ネットワークを広域ネットワークまたはインターネットに接続します。プロキシノードは、「アーキテクチャ」で前述したように、「プロキシノード」の役割を果たします。
+------+
| |
+--------+ RN +---------+
| | | |
+---+--+ +------+ +--+---+
| | | |
| RN | | RN |
| | | | +------------+
+---+--+ +--+---+ | WSN |
| RELOAD | | +----+ |
| OVERLAY | | +---+ CN | |
+---+--+ +--+---+ | | +----+ |
| | | +-----+ |
| RN | | PN | | |
| | | +-----+ |
+---+--+ +------+ +--+---+ | | +----+ |
| | | | | +---+ CN | |
+--------+ PN +---------+ | +----+ |
| | +------------+
+-+--+-+
| |
+--------|--|--------+
| +--+ +--+ |
| | | |
| +--+-+ +-+--+ |
| | CN | | CN | |
| +----+ +----+ |
| WSN |
+--------------------+
Figure 2: Overlay Topology
図2：オーバーレイトポロジ
CoAP URIs are typically resolved using a DNS. When CoAP is needed in a RELOAD environment, URI resolution is provided by the overlay as a whole. Instead of registering a URI, a peer stores a CoAPRegistration structure under a hash of its own URI. This uses the CoAP REGISTRATION Kind-ID, which is formally defined in Section 8.1 and uses a DICTIONARY data model.
CoAP URIは通常、DNSを使用して解決されます。 RELOAD環境でCoAPが必要な場合、URI解決は全体としてオーバーレイによって提供されます。ピアは、URIを登録する代わりに、独自のURIのハッシュの下にCoAPRegistration構造を格納します。これは、8.1節で正式に定義され、DICTIONARYデータモデルを使用するCoAP REGISTRATION Kind-IDを使用します。
In this example, a CoAP proxy that is located in an overlay overlay-1.com using a Node-ID "9996172" wants to register four different sensors to the URI "coap://overlay-1.com/proxy-1/.well-known/". We will be using the link format specified in [RFC6690] to store the following mapping in the overlay:
この例では、ノードID「9996172」を使用してオーバーレイoverlay-1.comにあるCoAPプロキシが、4つの異なるセンサーをURI「coap：//overlay-1.com/proxy-1/」に登録しようとしています。 .well-known / "。 [RFC6690]で指定されているリンク形式を使用して、オーバーレイに次のマッピングを保存します。
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) KEY = 9996172,
Resource-ID = h（coap：//overlay-1.com/proxy-1/.well-known/）KEY = 9996172、
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
</sensors/humidity>;rt="humidity-p";if="sensor"
]
Note that the Resource-ID stored in the overlay is calculated as hash over the URI, that is -- h(URI), which in RELOAD is usually SHA-1.
オーバーレイに格納されているResource-IDは、URIのハッシュとして計算されることに注意してください。つまり、RELOADでは通常SHA-1であるh（URI）です。
This would inform any other node performing a lookup for the previous URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value for proxy-1 is "9996172". In addition, this mapping provides relevant information as to the number of sensors (CNs) and the URI path to connect to them using CoAP.
これにより、前のURI "coap：//overlay-1.com/proxy-1/.well-known"のルックアップを実行する他のノードに、proxy-1のノードID値が "9996172"であることが通知されます。さらに、このマッピングは、センサー（CN）の数と、CoAPを使用してセンサーに接続するためのURIパスに関する関連情報を提供します。
The RELOAD overlay supports a rendezvous system that can be used for the lookup of other CoAP nodes. This is done by fetching mapping information between CoAP URIs and Node-IDs.
RELOADオーバーレイは、他のCoAPノードのルックアップに使用できるランデブーシステムをサポートしています。これは、CoAP URIとノードID間のマッピング情報をフェッチすることによって行われます。
As an example, if a node RN located in the overlay overlay-1.com wishes to read which resources are served at an RN with URI coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. The Resource-ID used in this fetch is a SHA-1 hash over the URI "coap://overlay-1.com/proxy-1/.well-known/".
例として、オーバーレイoverlay-1.comにあるノードRNが、URIがcoap：//overlay-1.com/proxy-1/のRNで提供されているリソースを読み取る場合は、次の場所でフェッチを実行します。オーバーレイ。このフェッチで使用されるResource-IDは、URI "coap：//overlay-1.com/proxy-1/.well-known/"に対するSHA-1ハッシュです。
After this fetch request, the overlay will return the following result:
このフェッチ要求の後、オーバーレイは次の結果を返します。
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) KEY = 9996172,
Resource-ID = h（coap：//overlay-1.com/proxy-1/.well-known/）KEY = 9996172、
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
</sensors/light>;rt="light-lux";if="sensor",
</sensors/humidity>;rt="humidity-p";if="sensor"
]
The obtained KEY is the Node-ID of the RN responsible of this KEY/ VALUE pair. The VALUE is the set of URIs necessary to read data from the CNs associated with the RN.
取得されたKEYは、このKEY / VALUEペアを担当するRNのノードIDです。 VALUEは、RNに関連付けられたCNからデータを読み取るために必要なURIのセットです。
Using the RELOAD DICTIONARY model allows for multiple nodes to perform a store to the same Resource-ID. This can be used, for example, to perform a store of resources of the same type or with similar characteristics. After performing a lookup, this feature allows the fetching of those multiple RNs that host CNs of the same class.
RELOAD DICTIONARYモデルを使用すると、複数のノードが同じResource-IDへのストアを実行できます。これは、たとえば、同じタイプまたは同様の特性を持つリソースのストアを実行するために使用できます。ルックアップを実行した後、この機能により、同じクラスのCNをホストする複数のRNを取得できます。
As an example, provided that the previous peer (9996172) and another peer (9996173) have stored the links to their respective temperature resources in this same Resource-ID (temperature), an RN (e.g., node-A) can do a fetch to the URI "coap://overlay-1.com/ temperature/.well-known/", obtaining the following results:
例として、前のピア（9996172）と別のピア（9996173）がそれぞれの温度リソースへのリンクをこの同じリソースID（温度）に保存している場合、RN（ノードAなど）はフェッチを実行できます。 URI「coap：//overlay-1.com/ temperature / .well-known /」に次の結果を取得します。
Resource-ID = h(coap://overlay-1.com/temperature/.well-known/)
KEY = 9996172,
VALUE = [
</sensors/temp-1>;rt="temperature-c";if="sensor",
</sensors/temp-2>;rt="temperature-c";if="sensor",
]
KEY = 9996173,
VALUE = [
</sensors/temp-a>;rt="temperature-c";if="sensor",
</sensors/temp-b>;rt="temperature-c";if="sensor"
]
Once an RN (e.g., node-A) has obtained the lookup information for a node in the overlay (e.g., proxy-1), it can directly connect to that node. This is performed by sending an AppAttach request to the Node-ID obtained during the lookup process.
RN（たとえば、node-A）がオーバーレイ（たとえば、proxy-1）内のノードのルックアップ情報を取得すると、そのノードに直接接続できます。これは、ルックアッププロセス中に取得されたノードIDにAppAttachリクエストを送信することで実行されます。
After the AppAttach negotiation, node-A can access the values of the CNs at proxy-1 using the information obtained during the lookup. Following the example in Section 5, and according to [RFC6690], the requests for accessing the CNs at proxy-1 would be:
AppAttachネゴシエーションの後、ノードAは、ルックアップ中に取得した情報を使用して、proxy-1のCNの値にアクセスできます。セクション5の例に従い、[RFC6690]によれば、proxy-1でCNにアクセスするための要求は次のようになります。
REQ: GET /sensors/temp-1
REQ: GET /sensors/temp-2
Figure 3 shows a sample of a node reading temperature data.
図3は、温度データを読み取るノードのサンプルを示しています。
+-----+ +---------+ +-----+ +---+
| PNA | | OVERLAY | | PNB | |CNB|
+-----+ +---------+ +-----+ +---+
| | | |
| | | |
| 1.RELOAD | | |
| FetchReq | | |
|+----------->| | |
| | | |
| 2.RELOAD | | |
| FetchAns | | |
|<-----------+| | |
| | | |
| 3.RELOAD | | |
| AppAttach | | |
|+----------->| | |
| | 4.RELOAD | |
| | AppAttach | |
| |+---------->| |
| | | |
| | 5.RELOAD | |
| 6.RELOAD |AppAttachAns| |
|AppAttachAns |<----------+| |
|<-----------+| | |
| | | |
| | |
| --------------------- | |
| / 7.ICE \| |
| \ connectivity checks /| |
| --------------------- | |
| | |
| 8.CoAP CON | |
| GET /sensors/temp-1 | |
|+------------------------>| |
| | 9.CoAP GET |
| |/sensors/temp-1 |
| |+-------------->|
| | 10.CoAP |
| 11.CoAP | ACK 200 |
| ACK 200 |<--------------+|
|<------------------------+| |
| | |
Figure 3: An Example of a Message Sequence
図3：メッセージシーケンスの例
The CoAP protocol itself supports the caching of sensor information in order to reduce the response time and network bandwidth consumption of future, equivalent requests. CoAP caching is specified in Section 5 of [RFC7252]. It consists of reusing stored responses when new requests arrive. This type of storage is done in CoAP proxies.
CoAPプロトコル自体は、将来の同等の要求の応答時間とネットワーク帯域幅の消費を削減するために、センサー情報のキャッシュをサポートしています。 CoAPキャッシングは、[RFC7252]のセクション5で指定されています。これは、新しい要求が到着したときに格納された応答を再利用することで構成されます。このタイプのストレージはCoAPプロキシで行われます。
This CoAP usage for RELOAD proposes an additional caching mechanism for storing sensor information directly in the overlay. In order to do so, it is necessary to define how the data should be stored. Such caching mechanism is primarily intended for CNs with sensor capabilities, not for RN sensors. This is due to the battery constraints of CNs, forcing them to stay in sleep mode for long periods of time.
このRELOADのCoAPの使用法は、センサー情報をオーバーレイに直接格納するための追加のキャッシュメカニズムを提案します。そのためには、データの保存方法を定義する必要があります。このようなキャッシングメカニズムは、主にRNセンサーではなく、センサー機能を持つCNを対象としています。これは、CNのバッテリーの制約が原因で、CNが長時間スリープモードに留まることを強制するためです。
Whenever a CN wakes up, it sends the most recent data from its sensors to its proxy (PN), which stores the data in the overlay using a RELOAD StoredData structure defined in Section 6 of [RFC6940]. We use the StoredDataValue structure defined in Section 6.2 of [RFC6940], in particular we use the SingleValue format type to store the cached values in the overlay. From that structure length, storage_time, lifetime and Signature are used in the same way. The only difference is DataValue, which in our case can be either a ProxyCache or a SensorCache:
CNがウェイクアップするたびに、CNはセンサーからの最新データをプロキシ（PN）に送信します。PNは、[RFC6940]のセクション6で定義されているRELOAD StoredData構造を使用して、オーバーレイにデータを保存します。 [RFC6940]のセクション6.2で定義されたStoredDataValue構造を使用します。特に、SingleValue形式タイプを使用して、キャッシュされた値をオーバーレイに保存します。その構造の長さから、storage_time、lifetime、Signatureが同じ方法で使用されます。唯一の違いはDataValueです。この場合、ProxyCacheまたはSensorCacheになります。
enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) }
CoAPCachingType;
struct {
CoAPCachingType coap_caching_type;
select(coap_caching_type) {
case proxy_cache: ProxyCache proxy_cache_entry;
case sensor_cache: SensorCache sensor_cache_entry;
/* extensions */
}
} CoAPCaching;
ProxyCache is meant to store values and sensor information (e.g., inactivity time) for all the sensors associated with a certain proxy, as well as their CoAP URIs. SensorCache, on the other hand, is used for storing the information and cached value of only one sensor (CoAP URI is not necessary, as it is the same as the one used for generating the Resource-ID associated to that SensorCache entry).
ProxyCacheは、特定のプロキシに関連付けられたすべてのセンサーの値とセンサー情報（非アクティブ時間など）とそれらのCoAP URIを格納するためのものです。一方、SensorCacheは、1つのセンサーのみの情報とキャッシュ値を格納するために使用されます（CoAP URIは、そのSensorCacheエントリに関連付けられたResource-IDの生成に使用されるものと同じであるため、必要ありません）。
ProxyCache contains the Node-ID, length, and a series of SensorEntry types.
ProxyCacheには、ノードID、長さ、および一連のSensorEntryタイプが含まれています。
struct {
Node-ID Node_ID;
uint32 length;
SensorEntry sensors[count];
} ProxyCache;
Node-ID The Node-ID of the Proxy Node (PN) responsible for different sensor devices;
ノードIDさまざまなセンサーデバイスを担当するプロキシノード（PN）のノードID。
length The length of the rest of the structure;
length構造の残りの長さ。
Sensor-Entry List of sensors in the form of SensorEntry types;
Sensor-Entryタイプの形式のセンサーのリスト。
SensorEntry contains the coap_uri, sensor_info, and a series of SensorValue types.
SensorEntryには、coap_uri、sensor_info、および一連のSensorValueタイプが含まれています。
struct {
opaque coap_uri;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[count];
} SensorEntry;
coap_uri CoAP name of the sensor device in question;
coap_uri問題のセンサーデバイスのCoAP名。
sensor_info contains relevant sensor information;
sensor_infoには、関連するセンサー情報が含まれています。
length The length of the rest of the structure;
length構造の残りの長さ。
sensor_value contains a list of values stored by the sensor;
sensor_valueには、センサーによって保存された値のリストが含まれます。
SensorCache: contains the information related to one sensor.
SensorCache：1つのセンサーに関連する情報が含まれます。
struct {
Node-ID Node_ID;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[count];
} SensorCache;
Node_ID identifies the Node-ID of the Proxy Node responsible for the sensor;
Node_IDは、センサーを担当するプロキシノードのノードIDを識別します。
sensor_info contains relevant sensor information;
sensor_infoには、関連するセンサー情報が含まれています。
length The length of the rest of the structure;
length構造の残りの長さ。
sensor_value contains a list of values stored by the sensor;
sensor_valueには、センサーによって保存された値のリストが含まれます。
SensorInfo contains relevant sensor information that is dependent on the use case. As an example, we use the sensor manufacturer as relevant information.
SensorInfoには、ユースケースに依存する関連センサー情報が含まれています。例として、関連する情報としてセンサーの製造元を使用します。
struct {
opaque dev_info;
/* extensions */
} SensorInfo;
} SensorInfo;
dev_info Contains specific device information as defined in [RFC6690] -- for example, temperature, luminosity, etc. It can also represent other semantic information about the device.
dev_info [RFC6690]で定義されている特定のデバイス情報（たとえば、温度、光度など）が含まれています。これは、デバイスに関する他のセマンティック情報を表すこともできます。
SensorValue contains the measurement_time, lifetime, and value of the measurement.
SensorValueには、測定のtime_time、寿命、および値が含まれます。
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
/* extensions */
} SensorValue;
} SensorValue;
measurement_time indicates the moment when the measure was taken, represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC not counting leap seconds.
Measurement_timeは、測定が行われた瞬間を示し、うるう秒をカウントしないUTC 1970年1月1日0時から経過したミリ秒数として表されます。
lifetime indicates the validity time of that measured value in milliseconds since measurement_time.
ライフタイムは、measurement_timeからのミリ秒単位の測定値の有効期間を示します。
value indicates the actual value measured. It can be of different types (integer, long, string); therefore, opaque has been used.
valueは、測定された実際の値を示します。さまざまなタイプ（整数、ロング、ストリング）にすることができます。したがって、不透明が使用されています。
This section defines the CoAP-REGISTRATION and CoAP-CACHING Kinds.
このセクションでは、CoAP-REGISTRATIONおよびCoAP-CACHINGの種類を定義します。
Kind-IDs The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP URI. The data stored is a CoAPRegistration, which contains a set of CoAP URIs.
Kind-IDs CoAP-REGISTRATION Kind-IDのリソース名はCoAP URIです。格納されるデータは、CoAP URIのセットを含むCoAPRegistrationです。
Data Model The data model for the CoAP-REGISTRATION Kind-ID is dictionary. The dictionary key is the Node-ID of the storing RN. This allows each RN to store a single mapping.
データモデルCoAP-REGISTRATION Kind-IDのデータモデルはディクショナリです。辞書キーは、格納するRNのノードIDです。これにより、各RNは単一のマッピングを保存できます。
Access Control URI-NODE-MATCH. The "coap:" prefix needs to be removed from the COAP URI before matching.
アクセス制御URI-NODE-MATCH。 「coap：」プレフィックスは、一致する前にCOAP URIから削除する必要があります。
Data stored under the COAP-REGISTRATION Kind is of type CoAPRegistration, defined below.
COAP-REGISTRATION Kindの下に保存されるデータは、以下で定義されるタイプCoAPRegistrationです。
struct {
Node-ID Node_ID;
uint16 coap_uris_length;
opaque coap_uris (0..2^16-1);
} CoAPRegistration;
Kind-IDs The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. The data stored is a CoAPCaching, which contains a cached value.
Kind-IDs CoAP-CACHING Kind-IDのリソース名はCoAP URIです。保存されるデータは、キャッシュされた値を含むCoAPCachingです。
Data Model The data model for the CoAP-CACHING Kind-ID is single value.
データモデルCoAP-CACHING Kind-IDのデータモデルは単一の値です。
Access Control URI-MATCH. The "coap:" prefix needs to be removed from the COAP URI before matching.
アクセス制御URI-MATCH。 「coap：」プレフィックスは、一致する前にCOAP URIから削除する必要があります。
Data stored under the CoAP-CACHING Kind is of type CoAPCaching, defined in Section 7.
CoAP-CACHINGの種類で保存されるデータは、セクション7で定義されているタイプCoAPCachingです。
As specified in RELOAD Base [RFC6940], every Kind that is storable in an overlay must be associated with an access control policy. This policy defines whether a request from a given node to operate on a given value should succeed or fail. Usages can define any access control rules they choose, including publicly writable values.
RELOAD Base [RFC6940]で指定されているように、オーバーレイに格納できるすべての種類は、アクセス制御ポリシーに関連付けられている必要があります。このポリシーは、特定のノードから特定の値を操作する要求が成功するか失敗するかを定義します。使用法では、パブリックに書き込み可能な値を含め、選択したアクセス制御ルールを定義できます。
CoAP Usage for RELOAD requires an access control policy that allows multiple nodes in the overlay read and write access. This access is for registering and caching information using CoAP URIs as identifiers. Therefore, none of the access control policies specified in RELOAD Base [RFC6940] are sufficient.
RELOADのCoAP使用には、オーバーレイの読み取りおよび書き込みアクセスで複数のノードを許可するアクセス制御ポリシーが必要です。このアクセスは、CoAP URIを識別子として使用して情報を登録およびキャッシュするためのものです。したがって、RELOAD Base [RFC6940]で指定されているアクセス制御ポリシーはどれも十分ではありません。
This document defines two access control policies, called URI-MATCH and URI-NODE-MATCH. In the URI-MATCH policy, a given value MUST be written and overwritten if and only if the signer's certificate contains an uniformResourceIdentifier entry in the subjectAltName Extension [RFC5280] that in canonicalized form hashes to the Resource-ID for the resource. As explained in Section 6.3 of [RFC7252] the "coap" and "coaps" schemes conform to the generic URI, thus they are normalized in the generic form as explained in Section 6 of [RFC3986]. The hash function used is specified in Section 10.2 of [RFC6940]. The certificate can be generated as specified in Section 9 of [RFC7252], using Certificate mode.
このドキュメントでは、URI-MATCHとURI-NODE-MATCHと呼ばれる2つのアクセス制御ポリシーを定義しています。 URI-MATCHポリシーでは、署名者の証明書に、サブジェクトAltName拡張[RFC5280]のuniformResourceIdentifierエントリが含まれ、正規化された形式でリソースのResource-IDにハッシュされる場合にのみ、指定された値を書き込んで上書きする必要があります。 [RFC7252]のセクション6.3で説明されているように、「coap」および「coaps」スキームは汎用URIに準拠しているため、[RFC3986]のセクション6で説明されているように、それらは汎用形式で正規化されます。使用されるハッシュ関数は、[RFC6940]のセクション10.2で指定されています。証明書は、[RFC7252]のセクション9で指定されているように、証明書モードを使用して生成できます。
In the URI-NODE-MATCH policy, a given value MUST be written and overwritten if and only if the condition for URI-MATCH is met and, in addition, the dictionary key is equal to the Node-ID in the certificate and that Node-ID is the one indicated in the SignerIdentity value cert_hash.
URI-NODE-MATCHポリシーでは、URI-MATCHの条件が満たされ、さらにディクショナリキーが証明書とそのノードのノードIDに等しい場合にのみ、指定された値を書き込んで上書きする必要があります-IDは、SignerIdentity値cert_hashで示されているものです。
These Access Control Policies are specified for IANA in Section 11.3.
これらのアクセス制御ポリシーは、セクション11.3でIANAに指定されています。
The security considerations of RELOAD [RFC6940] and CoAP [RFC7252] apply to this specification. RELOAD's security model is based on public key certificates, which are used for signing messages and stored objects. At the connection level, RELOAD can use either TLS or DTLS. In the case of CoAP, several security modes have been defined. Implementations of this specification MUST follow all the security-related rules specified in the RELOAD [RFC6940] and CoAP [RFC7252] specifications.
RELOAD [RFC6940]およびCoAP [RFC7252]のセキュリティに関する考慮事項は、この仕様に適用されます。 RELOADのセキュリティモデルは、メッセージおよび格納されたオブジェクトの署名に使用される公開鍵証明書に基づいています。接続レベルでは、RELOADはTLSまたはDTLSを使用できます。 CoAPの場合、いくつかのセキュリティモードが定義されています。この仕様の実装は、RELOAD [RFC6940]およびCoAP [RFC7252]仕様で指定されているすべてのセキュリティ関連の規則に従う必要があります。
Additionally, in RELOAD every Kind that is storable in an overlay must be associated with an access control policy. This document specifies two new access control policies, which are specified in Section 9. These policies cover the most typical deployment scenarios.
さらに、RELOADでは、オーバーレイに保存できるすべての種類をアクセス制御ポリシーに関連付ける必要があります。このドキュメントでは、セクション9で指定されている2つの新しいアクセス制御ポリシーを指定します。これらのポリシーは、最も一般的な展開シナリオをカバーしています。
During the phase of registration and lookup, security considerations relevant to RELOAD apply. A CoAP node that advertises its existence via this mechanism, is more likely to be attacked, compared to a node (especially a sleepy node) that does not advertise its existence. Section 11 of [RFC7252] and Section 13 of [RFC6940] have more information about the kinds of attack and mitigation possible.
登録と検索のフェーズでは、RELOADに関連するセキュリティの考慮事項が適用されます。このメカニズムを介してその存在をアドバタイズするCoAPノードは、その存在をアドバタイズしないノード（特にスリープ状態のノード）と比較して、攻撃される可能性が高くなります。 [RFC7252]のセクション11と[RFC6940]のセクション13には、可能な攻撃と緩和策の種類に関する詳細が記載されています。
The caching mechanism specified in this document is additional to the caching already done in CoAP. Access control is handled by the RELOAD overlay, where the peer storing the data is responsible for validating the signature on the data being stored.
このドキュメントで指定されているキャッシングメカニズムは、CoAPですでに行われているキャッシングに追加されます。アクセス制御はRELOADオーバーレイによって処理されます。データを格納するピアは、格納されるデータの署名を検証する責任があります。
This document introduces a data Kind-ID to the "RELOAD Data Kind-ID" registry:
このドキュメントでは、「RELOAD Data Kind-ID」レジストリにデータの種類IDを紹介します。
+-------------------+------------+----------+
| Kind | Kind-ID | RFC |
+-------------------+------------+----------+
| CoAP-REGISTRATION | 0x105 | RFC 7650 |
+-------------------+------------+----------+
This Kind-ID was defined in Section 8.1.
この種類IDはセクション8.1で定義されています。
This document introduces another data Kind-ID to the "RELOAD Data Kind-ID" registry:
このドキュメントでは、「RELOAD Data Kind-ID」レジストリに別のデータKind-IDを紹介しています。
+--------------+------------+----------+
| Kind | Kind-ID | RFC |
+--------------+------------+----------+
| CoAP-CACHING | 0x106 | RFC 7650 |
+--------------+------------+----------+
This Kind-ID was defined in Section 8.2.
この種類IDはセクション8.2で定義されています。
IANA has created a "CoAP Usage for RELOAD Access Control Policy" registry. This registry has been added to the existing RELOAD registry. Entries in this registry are strings denoting access control policies, as described in Section 9. New entries in this registry are to be registered per the Specification Required policy in [RFC5226]. The initial contents of this registry are:
IANAは、「RELOADアクセス制御ポリシーのCoAP使用」レジストリを作成しました。このレジストリは、既存のRELOADレジストリに追加されました。このレジストリのエントリは、セクション9で説明されているように、アクセス制御ポリシーを示す文字列です。このレジストリの新しいエントリは、[RFC5226]の仕様必須ポリシーに従って登録されます。このレジストリの初期内容は次のとおりです。
+-----------------+----------+
| Access Policy | RFC |
+-----------------+----------+
| URI-NODE-MATCH | RFC 7650 |
| URI-MATCH | RFC 7650 |
+-----------------+----------+
This access control policy was described in Section 9.
このアクセス制御ポリシーについては、セクション9で説明しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<http://www.rfc-editor.org/info/rfc6690>。
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、RFC 6940、DOI 10.17487 / RFC6940 、2014年1月、<http://www.rfc-editor.org/info/rfc6940>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[CORERESDIR] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-04, July 2015.
[CORERESDIR] Shelby、Z.、Koster、M.、Bormann、C。、およびP. Stok、「CoRE Resource Directory」、Work in Progress、draft-ietf-core-resource-directory-04、2015年7月。
[P2PSIP] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer to Peer SIP", Work in Progress, draft-ietf-p2psip-concepts-07, May 2015.
[P2PSIP]ブライアン、D。、マシューズ、P。、シム、E。、ウィリス、D。、およびS.ドーキンス、「ピアツーピアSIPの概念と用語」、作業中、draft-ietf-p2psip-concepts -2015年5月7日。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
Authors' Addresses
著者のアドレス
Jaime Jimenez Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jaime Jimenez Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: jaime.jimenez@ericsson.com
Jose M. Lopez-Vega University of Granada CITIC UGR Periodista Rafael Gomez Montero 2 Granada 18071 Spain
ホセ・M・ロペス・ベガグラナダ大学CITIC UGRジャーナリストラファエルゴメスモンテロ2グラナダ18071スペイン
Email: jmlvega@ugr.es
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: jouni.maenpaa@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: gonzalo.camarillo@ericsson.com