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
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)
用于资源定位和发现（重新加载）的受限应用程序协议（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.
本文档定义了资源定位和发现（重新加载）的受限应用程序协议（CoAP）使用。CoAP的使用提供了以对等方式联合无线传感器网络（WSN）的功能。重新加载的CoAP使用允许CoAP节点在重新加载对等覆盖中存储资源，提供查找服务，并允许使用重新加载覆盖作为传感器数据的缓存。此功能在重新加载覆盖本身中实现，无需使用集中式服务器。重新加载AppAttach方法用于在节点之间建立直接连接，通过该连接交换CoAP消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
资源定位和发现（重新加载）的受限应用程序协议（CoAP）使用允许CoAP节点在重新加载对等覆盖中存储资源，提供查找服务，并允许使用重新加载覆盖作为传感器数据的缓存。此功能在重新加载覆盖本身中实现，无需使用集中式服务器。
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）的情况。这些无线传感器网络将通过配备远程模块（如2G、3G、4G）和短程模块（如XBee、ZigBee、蓝牙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]。它实现了最受约束节点（如传感器和执行器）的代表性状态转移（REST）体系结构。CoAP不仅可以在同一受约束网络上的节点之间使用，还可以在受约束节点和Internet上的节点之间使用。后者是可能的，因为CoAP可以转换为超文本传输协议（HTTP），以便与web集成。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]所述，重新加载基本上是一个覆盖网络。它提供了一个具有可插入应用程序层的分层体系结构，可以使用底层转发、存储和查找功能。图1说明了CoAP使用在重新加载体系结构中的位置。
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 |
+-------+ +-------+
+-------+
| 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的使用涉及三个基本功能：
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.
注册：可以使用重新加载数据存储功能的CoAP节点可以在覆盖中存储从其CoAP URI到其节点ID的映射。它们还可以检索其他节点的节点ID。不支持重新加载的节点可以在其本地网络中使用其他机制，例如[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，它就可以使用重新加载消息路由系统来建立可用于交换CoAP消息的连接。与注册类似，不支持重新加载的节点可以将CoAP消息与重新加载节点（RN）一起使用，该节点将依次在覆盖中执行查找。
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资源的信息。这对于功率受限的节点尤其有用，这些节点可以在睡眠模式下使其数据在覆盖提供的缓存中可用。
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节）可以在其URI（例如）下注册其节点ID（例如“9996172”）和传感器列表（例如“/sensors/temp-1；/sensors/temp-2；/sensors/light，/sensors/湿度”）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及其关联传感器的列表。然后，请求节点可以使用重新加载覆盖与代理建立直接连接并读取传感器值。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
在本文档中，我们广泛使用重新加载基本协议[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.
代理节点设备具有足够的资源以作为客户端或对等机运行重载。这些设备位于传感器网络的边缘，如果是无线传感器网络（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:
物理设备可以具有一个或多个以前的功能角色。根据每个节点中存在的功能，它们可以是：
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不是重新加载覆盖的一部分，因此它不能充当客户机、对等机或代理。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.
重新加载节点重新加载节点（RN）必须在覆盖中实现客户端功能。此外，该节点通常是完全重新加载对等节点。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将短程无线网络连接到广域网或Internet。代理节点履行“代理节点”角色，如前面在体系结构中所述。
+------+
| |
+--------+ RN +---------+
| | | |
+---+--+ +------+ +--+---+
| | | |
| RN | | RN |
| | | | +------------+
+---+--+ +--+---+ | WSN |
| RELOAD | | +----+ |
| OVERLAY | | +---+ CN | |
+---+--+ +--+---+ | | +----+ |
| | | +-----+ |
| RN | | PN | | |
| | | +-----+ |
+---+--+ +------+ +--+---+ | | +----+ |
| | | | | +---+ CN | |
+--------+ PN +---------+ | +----+ |
| | +------------+
+-+--+-+
| |
+--------|--|--------+
| +--+ +--+ |
| | | |
| +--+-+ +-+--+ |
| | CN | | CN | |
| +----+ +----+ |
| WSN |
+--------------------+
+------+
| |
+--------+ 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解析。当在重新加载环境中需要CoAP时，URI解析由覆盖作为一个整体提供。对等方不注册URI，而是在其自己的URI的散列下存储协同分发结构。这使用CoAP注册种类ID，该ID在第8.1节中正式定义，并使用字典数据模型。
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:
在本例中，位于overlay-1.com中的CoAP代理使用节点ID“9996172”希望将四个不同的传感器注册到URI”coap://overlay-1.com/proxy-1/.well-known/". 我们将使用[RFC6690]中指定的链接格式在覆盖中存储以下映射：
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) KEY = 9996172,
资源ID=h(coap://overlay-1.com/proxy-1/.well-known/)键=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"
]
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.
请注意，存储在覆盖中的资源ID是作为URI上的散列计算的，即--h（URI），在重载中通常是SHA-1。
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代理-1的节点ID值为“9996172”。此外，该映射提供了有关传感器（CNs）数量以及使用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.
重新加载覆盖支持可用于查找其他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的RN上服务的资源coap://overlay-1.com/proxy-1/，它在覆盖中执行提取。此提取中使用的资源ID是URI上的SHA-1哈希“coap://overlay-1.com/proxy-1/.well-known/".
After this fetch request, the overlay will return the following result:
在此提取请求之后，覆盖将返回以下结果：
Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) KEY = 9996172,
资源ID=h(coap://overlay-1.com/proxy-1/.well-known/)键=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"
]
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.
获得的密钥是负责该密钥/值对的RN的节点ID。该值是从与RN相关联的CNs读取数据所需的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.
使用重新加载字典模型允许多个节点对相同的资源ID执行存储。例如，这可以用于存储相同类型或具有类似特征的资源。执行查找后，此功能允许获取承载同一类CNs的多个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/ 温度/.well/”，获得以下结果：
Resource-ID = h(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 = 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"
]
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（例如，节点A）获得覆盖中的节点（例如，代理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可以使用查找期间获得的信息访问代理1处的CNs值。按照第5节中的示例，根据[RFC6690]，在proxy-1上访问CNs的请求为：
REQ: GET /sensors/temp-1
REQ: GET /sensors/temp-2
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 |<--------------+|
|<------------------------+| |
| | |
+-----+ +---------+ +-----+ +---+
| 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协议本身支持传感器信息的缓存，以减少未来等效请求的响应时间和网络带宽消耗。[RFC7252]第5节规定了CoAP缓存。它包括在新请求到达时重用存储的响应。这种类型的存储是在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.
CoAP对重新加载的使用提出了一种额外的缓存机制，用于将传感器信息直接存储在覆盖中。为此，必须定义数据的存储方式。这种缓存机制主要用于具有传感器功能的CNs，而不是RN传感器。这是由于中枢神经系统的电池限制，迫使它们长时间处于睡眠模式。
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醒来时，它会将其传感器的最新数据发送到其代理（PN），该代理使用[RFC6940]第6节中定义的重新加载存储数据结构将数据存储在覆盖中。我们使用[RFC6940]第6.2节中定义的StoredDataValue结构，特别是使用SingleValue格式类型将缓存的值存储在覆盖中。从结构长度来看，存储时间、生存期和签名的使用方式是相同的。唯一的区别是DataValue，在我们的例子中，DataValue可以是ProxyCache或SensorCache：
enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) }
CoAPCachingType;
struct {
CoAPCachingType coap_caching_type;
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 */
select(coap_caching_type) {
case proxy_cache: ProxyCache proxy_cache_entry;
case sensor_cache: SensorCache sensor_cache_entry;
/* extensions */
}
} CoAPCaching;
}
} 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仅用于存储一个传感器的信息和缓存值（CoAP URI不是必需的，因为它与用于生成与该SensorCache项关联的资源ID的URI相同）。
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;
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;
长度结构其余部分的长度；
Sensor-Entry List of sensors in the form of SensorEntry types;
传感器条目类型形式的传感器条目列表；
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;
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;
传感器信息包含相关的传感器信息；
length The length of the rest of the structure;
长度结构其余部分的长度；
sensor_value contains a list of values stored by the sensor;
传感器_值包含传感器存储的值列表；
SensorCache: contains the information related to one sensor.
SensorCache：包含与一个传感器相关的信息。
struct {
Node-ID Node_ID;
SensorInfo sensor_info;
uint32 length;
SensorValue sensor_value[count];
} SensorCache;
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;
传感器信息包含相关的传感器信息；
length The length of the rest of the structure;
长度结构其余部分的长度；
sensor_value contains a list of values stored by the sensor;
传感器_值包含传感器存储的值列表；
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;
struct {
opaque dev_info;
/* extensions */
/* 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包含测量时间、寿命和测量值。
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
struct {
uint32 measurement_time;
uint32 lifetime;
opaque value;
/* extensions */
/* extensions */
} 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.
测量时间表示进行测量的时刻，表示为自1970年1月1日UTC午夜以来经过的毫秒数，不包括闰秒。
lifetime indicates the validity time of that measured value in milliseconds since measurement_time.
lifetime表示自测量时间起该测量值的有效时间（以毫秒为单位）。
value indicates the actual value measured. It can be of different types (integer, long, string); therefore, opaque has been used.
值表示实际测量的值。它可以是不同的类型（整数、长、字符串）；因此，使用了不透明。
This section defines the CoAP-REGISTRATION and CoAP-CACHING Kinds.
本节定义了CoAP注册和CoAP缓存类型。
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.
种类ID CoAP注册种类ID的资源名称是CoAP URI。存储的数据是一个CoAPRegistration，其中包含一组coapuri。
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注册种类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 URI中删除“coap:”前缀。
Data stored under the COAP-REGISTRATION Kind is of type CoAPRegistration, defined below.
COAP-REGISTRATION类型下存储的数据类型为CoapPregistration，定义如下。
struct {
Node-ID Node_ID;
uint16 coap_uris_length;
opaque coap_uris (0..2^16-1);
} 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.
种类ID CoAP缓存种类ID的资源名称是CoAP URI。存储的数据是一个共缓存，其中包含一个缓存值。
Data Model The data model for the CoAP-CACHING Kind-ID is single value.
数据模型CoAP缓存种类ID的数据模型为单值。
Access Control URI-MATCH. The "coap:" prefix needs to be removed from the COAP URI before matching.
访问控制URI-MATCH。匹配之前，需要从coap URI中删除“coap:”前缀。
Data stored under the CoAP-CACHING Kind is of type CoAPCaching, defined in Section 7.
CoAP缓存类型下存储的数据属于第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.
重新加载的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
本文档定义了两种访问控制策略，称为URI-MATCH和URI-NODE-MATCH。在URI-MATCH策略中，当且仅当签名者的证书在subjectAltName扩展[RFC5280]中包含uniformResourceIdentifier条目时，必须写入和覆盖给定值，该条目以规范化形式散列到资源的资源ID。如[RFC7252]第6.3节所述，“coap”和“coap”方案符合通用URI，因此它们以通用形式规范化，如中所述
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.
[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是签名身份值cert_哈希中指示的节点ID。
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.
重新加载[RFC6940]和CoAP[RFC7252]的安全注意事项适用于本规范。RELOAD的安全模型基于公钥证书，用于对消息和存储对象进行签名。在连接级别，重载可以使用TLS或DTL。在CoAP的情况下，定义了几种安全模式。本规范的实施必须遵循重新加载[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.
此外，在重新加载中，覆盖中可存储的每种类型都必须与访问控制策略相关联。本文件规定了第9节中规定的两种新的访问控制策略。这些策略涵盖了最典型的部署场景。
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.
在注册和查找阶段，将应用与重新加载相关的安全注意事项。通过这种机制宣布其存在的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中已经完成的缓存的补充。访问控制由重载覆盖处理，其中存储数据的对等方负责验证所存储数据上的签名。
This document introduces a data Kind-ID to the "RELOAD Data Kind-ID" registry:
本文档将数据种类ID引入“重新加载数据种类ID”注册表：
+-------------------+------------+----------+
| Kind | Kind-ID | RFC |
+-------------------+------------+----------+
| CoAP-REGISTRATION | 0x105 | RFC 7650 |
+-------------------+------------+----------+
+-------------------+------------+----------+
| 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:
本文档向“重新加载数据种类ID”注册表引入了另一个数据种类ID：
+--------------+------------+----------+
| Kind | Kind-ID | RFC |
+--------------+------------+----------+
| CoAP-CACHING | 0x106 | RFC 7650 |
+--------------+------------+----------+
+--------------+------------+----------+
| Kind | Kind-ID | RFC |
+--------------+------------+----------+
| CoAP-CACHING | 0x106 | RFC 7650 |
+--------------+------------+----------+
This Kind-ID was defined in Section 8.2.
第8.2节定义了此类ID。
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已创建“重新加载访问控制策略的CoAP使用”注册表。此注册表已添加到现有的重新加载注册表中。此注册表中的条目是表示访问控制策略的字符串，如第9节所述。此注册表中的新条目将按照[RFC5226]中规定的政策进行注册。此注册表的初始内容包括：
+-----------------+----------+
| Access Policy | RFC |
+-----------------+----------+
| URI-NODE-MATCH | RFC 7650 |
| URI-MATCH | RFC 7650 |
+-----------------+----------+
+-----------------+----------+
| 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，“统一资源标识符（URI）：通用语法”，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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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.“受限RESTful环境（核心）链接格式”，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，“资源定位和发现（重新加载）基础协议”，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，“受限应用协议（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，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-042015年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]Bryan，D.，Matthews，P.，Shim，E.，Willis，D.，和S.Dawkins，“对等SIP的概念和术语”，正在进行的工作，草案-ietf-P2PSIP-Concepts-07，2015年5月。
[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，“在RFCs中编写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.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
Authors' Addresses
作者地址
Jaime Jimenez Ericsson Hirsalantie 11 Jorvas 02420 Finland
芬兰海梅·希门尼斯爱立信Hirsalantie 11 Jorvas 02420
Email: jaime.jimenez@ericsson.com
Email: jaime.jimenez@ericsson.com
Jose M. Lopez-Vega University of Granada CITIC UGR Periodista Rafael Gomez Montero 2 Granada 18071 Spain
若泽M洛佩兹Vega格拉纳达大学中信UGR PieloDista拉斐尔戈麦斯蒙特罗2格拉纳达18071西班牙
Email: jmlvega@ugr.es
Email: jmlvega@ugr.es
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jouni Maenpaa Ericsson Hirsalantie 11 Jorvas 02420芬兰
Email: jouni.maenpaa@ericsson.com
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
Email: gonzalo.camarillo@ericsson.com