Internet Engineering Task Force (IETF) A. Rahman, Ed.
Request for Comments: 7390 InterDigital Communications, LLC
Category: Experimental E. Dijk, Ed.
ISSN: 2070-1721 Philips Research
October 2014
Internet Engineering Task Force (IETF) A. Rahman, Ed.
Request for Comments: 7390 InterDigital Communications, LLC
Category: Experimental E. Dijk, Ed.
ISSN: 2070-1721 Philips Research
October 2014
Group Communication for the Constrained Application Protocol (CoAP)
受约束应用程序协议（CoAP）的组通信
Abstract
摘要
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.
受限应用程序协议（CoAP）是一种用于受限设备和受限网络的专用web传输协议。预计受约束的设备通常会自然分组运行（例如，在楼宇自动化场景中，给定房间中的所有灯可能需要作为一个组打开/关闭）。本规范定义了如何在组通信上下文中使用CoAP。基于现有的CoAP功能以及本规范中引入的新特性，详细介绍了在IP多播之上使用CoAP的方法。此外，还提供了各种用例和相应的协议流来说明重要的概念。最后，为在各种网络拓扑中的部署提供了指导。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7390.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7390.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5
2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6
2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7
2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 9
2.5. Request and Response Model . . . . . . . . . . . . . . . 9
2.6. Membership Configuration . . . . . . . . . . . . . . . . 10
2.6.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.6.2. Membership Configuration RESTful Interface . . . . . 11
2.7. Request Acceptance and Response Suppression Rules . . . . 17
2.8. Congestion Control . . . . . . . . . . . . . . . . . . . 19
2.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 20
2.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 21
3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 22
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Network Configuration . . . . . . . . . . . . . . . . . . 22
3.3. Discovery of Resource Directory . . . . . . . . . . . . . 25
3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 26
3.5. Lighting Control in MLD-Enabled Network . . . . . . . . . 30
3.6. Commissioning the Network Based on Resource Directory . . 31
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 32
4.1. Target Network Topologies . . . . . . . . . . . . . . . . 32
4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 33
4.3. Networks Using RPL Multicast without MLD . . . . . . . . 33
4.4. Networks Using MPL Forwarding without MLD . . . . . . . . 34
4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
5.1. Security Configuration . . . . . . . . . . . . . . . . . 35
5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5
2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6
2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7
2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 9
2.5. Request and Response Model . . . . . . . . . . . . . . . 9
2.6. Membership Configuration . . . . . . . . . . . . . . . . 10
2.6.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.6.2. Membership Configuration RESTful Interface . . . . . 11
2.7. Request Acceptance and Response Suppression Rules . . . . 17
2.8. Congestion Control . . . . . . . . . . . . . . . . . . . 19
2.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 20
2.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 21
3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 22
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Network Configuration . . . . . . . . . . . . . . . . . . 22
3.3. Discovery of Resource Directory . . . . . . . . . . . . . 25
3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 26
3.5. Lighting Control in MLD-Enabled Network . . . . . . . . . 30
3.6. Commissioning the Network Based on Resource Directory . . 31
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 32
4.1. Target Network Topologies . . . . . . . . . . . . . . . . 32
4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 33
4.3. Networks Using RPL Multicast without MLD . . . . . . . . 33
4.4. Networks Using MPL Forwarding without MLD . . . . . . . . 34
4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
5.1. Security Configuration . . . . . . . . . . . . . . . . . 35
5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 36
5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 37
5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 37
5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 37
5.4. Monitoring Considerations . . . . . . . . . . . . . . . . 38
5.4.1. General Monitoring . . . . . . . . . . . . . . . . . 38
5.4.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 39
6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 39
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 36
5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 37
5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 37
5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 37
5.4. Monitoring Considerations . . . . . . . . . . . . . . . . 38
5.4.1. General Monitoring . . . . . . . . . . . . . . . . . 38
5.4.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 39
6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 39
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
CoAP is a web transfer protocol based on Representational State Transfer (REST) for resource constrained devices operating in an IP network [RFC7252]. CoAP has many similarities to HTTP [RFC7230] but also some key differences. Constrained devices can be large in numbers but are often related to each other in function or by location. For example, all the light switches in a building may belong to one group, and all the thermostats may belong to another group. Groups may be preconfigured before deployment or dynamically formed during operation. If information needs to be sent to or received from a group of devices, group communication mechanisms can improve efficiency and latency of communication and reduce bandwidth requirements for a given application. HTTP does not support any equivalent functionality to CoAP group communication.
CoAP是一种基于代表性状态传输（REST）的web传输协议，用于在IP网络中运行的资源受限设备[RFC7252]。CoAP与HTTP[RFC7230]有许多相似之处，但也有一些关键区别。受约束的设备数量可能很大，但通常在功能或位置上相互关联。例如，建筑物中的所有电灯开关可能属于一个组，而所有恒温器可能属于另一个组。组可以在部署前预配置，也可以在操作期间动态形成。如果需要向一组设备发送信息或从一组设备接收信息，则组通信机制可以提高通信的效率和延迟，并降低给定应用程序的带宽要求。HTTP不支持任何与CoAP组通信等效的功能。
Group communication involves a one-to-many relationship between CoAP endpoints. Specifically, a single CoAP client can simultaneously get (or set) resources from multiple CoAP servers using CoAP over IP multicast. An example would be a CoAP light switch turning on/off multiple lights in a room with a single CoAP group communication PUT request and handling the potential multitude of (unicast) responses.
组通信涉及CoAP端点之间的一对多关系。具体而言，单个CoAP客户端可以使用CoAP over IP多播同时从多个CoAP服务器获取（或设置）资源。例如，一个CoAP灯开关通过单个CoAP组通信PUT请求打开/关闭房间中的多个灯，并处理潜在的多个（单播）响应。
The base protocol aspects of sending CoAP requests on top of IP multicast and processing the (unicast IP) responses are given in Section 8 of [RFC7252]. To provide a more complete CoAP group communication functionality, this specification introduces new CoAP
[RFC7252]第8节给出了在IP多播之上发送CoAP请求和处理（单播IP）响应的基本协议方面。为了提供更完整的CoAP组通信功能，本规范引入了新的CoAP
processing functionality (e.g., new rules for reuse of Token values, request suppression, and proxy operation) and a new management interface for RESTful group membership configuration.
处理功能（例如，重新使用令牌值、请求抑制和代理操作的新规则）和用于RESTful组成员身份配置的新管理接口。
CoAP group communication will run in the Any Source Multicast (ASM) mode [RFC5110] of IP multicast operation. This means that there is no restriction on the source node that sends (originates) the CoAP messages to the IP multicast group. For example, the source node may or may not be part of the IP multicast group. Also, there is no restriction on the number of source nodes.
CoAP组通信将在IP多播操作的任意源多播（ASM）模式[RFC5110]下运行。这意味着向IP多播组发送（发起）CoAP消息的源节点没有限制。例如，源节点可能是也可能不是IP多播组的一部分。此外，对源节点的数量没有限制。
While Section 9.1 of [RFC7252] supports various modes of security based on Datagram Transport Layer Security (DTLS) for CoAP over unicast IP, it does not specify any security modes for CoAP over IP multicast. That is, it is assumed per [RFC7252] that CoAP over IP multicast is not encrypted, nor authenticated, nor access controlled. This document assumes the same security model (see Section 5.1). However, there are several promising security approaches being developed that should be considered in the future for protecting CoAP group communications (see Section 5.3.3).
虽然[RFC7252]的第9.1节支持基于单播IP上的CoAP的数据报传输层安全性（DTLS）的各种安全模式，但它没有为CoAP-over-IP多播指定任何安全模式。也就是说，根据[RFC7252]，假定CoAP over IP多播未加密、未验证或未控制访问。本文件采用相同的安全模型（见第5.1节）。然而，有几种有希望的安全方法正在开发中，未来应考虑用于保护CoAP组通信（见第5.3.3节）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings and are not to be interpreted as [RFC2119] key words.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。当这些词不在所有大写字母中时（如“应该”或“应该”），它们具有通常的英语含义，不应解释为[RFC2119]关键词。
Note that this document refers back to other RFCs, and especially [RFC7252], to help explain overall CoAP group communication features. However, use of [RFC2119] key words is reserved for new CoAP functionality introduced by this specification.
请注意，本文档引用了其他RFC，尤其是[RFC7252]，以帮助解释CoAP组的整体通信功能。然而，[RFC2119]关键字的使用保留用于本规范引入的新CoAP功能。
This document assumes readers are familiar with the terms and concepts that are used in [RFC7252]. In addition, this document defines the following terminology:
本文档假设读者熟悉[RFC7252]中使用的术语和概念。此外，本文件定义了以下术语：
Group Communication: A source node sends a single application-layer (e.g., CoAP) message that is delivered to multiple destination nodes, where all destinations are identified to belong to a specific group. The source node itself may be part of the group. The underlying mechanisms for CoAP group communication are UDP/IP multicast for
组通信：源节点发送单个应用层（例如，CoAP）消息，该消息被传递到多个目标节点，其中所有目标都被标识为属于特定组。源节点本身可能是组的一部分。CoAP组通信的底层机制是UDP/IP多播
the requests and unicast UDP/IP for the responses. The network involved may be a constrained network such as a low-power, lossy network.
响应的请求和单播UDP/IP。所涉及的网络可以是受限网络，例如低功率、有损网络。
Reliable Group Communication: A special case of group communication where for each destination node, it is guaranteed that the node either 1) eventually receives the message sent by the source node or 2) does not receive the message and the source node is notified of the non-reception event. An example of a reliable group communication protocol is [RFC5740].
可靠的组通信：组通信的一种特殊情况，其中对于每个目的地节点，保证节点1）最终接收到源节点发送的消息，或2）未接收到消息，且源节点收到未接收事件的通知。可靠组通信协议的一个示例是[RFC5740]。
Multicast: Sending a message to multiple destination nodes with one network invocation. There are various options to implement multicast, including layer 2 (Media Access Control) and layer 3 (IP) mechanisms.
多播：通过一次网络调用向多个目标节点发送消息。实现多播有多种选择，包括第2层（媒体访问控制）和第3层（IP）机制。
IP Multicast: A specific multicast approach based on the use of IP multicast addresses as defined in "IANA Guidelines for IPv4 Multicast Address Assignments" [RFC5771] and "IP Version 6 Addressing Architecture" [RFC4291]. A complete IP multicast solution may include support for managing group memberships and IP multicast routing/forwarding (see Section 2.1).
IP多播：一种基于IP多播地址使用的特定多播方法，定义见“IPv4多播地址分配IANA指南”[RFC5771]和“IP版本6寻址体系结构”[RFC4291]。完整的IP多播解决方案可能包括对管理组成员身份和IP多播路由/转发的支持（参见第2.1节）。
Low-Power and Lossy Network (LLN): A type of constrained IP network where devices are interconnected by low-power and lossy links. The links may be composed of one or more technologies such as IEEE 802.15.4, Bluetooth Low Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), and IEEE P1901.2 power-line communication.
低功耗有损网络（LLN）：一种受限IP网络，设备通过低功耗有损链路互连。链路可以由一种或多种技术组成，例如IEEE 802.15.4、蓝牙低能（BLE）、数字增强无绳通信（DECT）和IEEE P1901.2电力线通信。
IP multicast protocols have been evolving for decades, resulting in standards such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]. IP multicast is very popular in specific deployments such as in enterprise networks (e.g., for video conferencing), smart home networks (e.g., Universal Plug and Play (UPnP)), and carrier IPTV deployments. The packet economy and minimal host complexity of IP multicast make it attractive for group communication in constrained environments.
IP多播协议已经发展了几十年，产生了协议独立多播稀疏模式（PIM-SM）[RFC4601]等标准。IP多播在特定部署中非常流行，例如在企业网络（例如，视频会议）、智能家庭网络（例如，通用即插即用（UPnP））和运营商IPTV部署中。IP组播的数据包经济性和最小的主机复杂度使得它在受限环境下的组通信中具有吸引力。
To achieve IP multicast beyond link-local (LL) scope, an IP multicast routing or forwarding protocol needs to be active on IP routers. An example of a routing protocol specifically for LLNs is the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 of [RFC6550]), and an example of a forwarding protocol for LLNs is the Multicast Protocol for Low-Power and Lossy Networks (MPL) [MCAST-MPL]. RPL and MPL do not depend on each other; each can be used in isolation, and both can be used in combination in a network. Finally, PIM-SM [RFC4601] is often used for multicast routing in traditional IP networks (i.e., networks that are not constrained).
为了实现链路本地（LL）范围之外的IP多播，需要在IP路由器上激活IP多播路由或转发协议。专门用于LLN的路由协议的一个示例是用于低功率和有损网络的IPv6路由协议（RPL）（RFC6550第12节），用于LLN的转发协议的一个示例是用于低功率和有损网络的多播协议（MPL）[MCAST-MPL]。RPL和MPL互不依赖；每一个都可以单独使用，也可以在网络中组合使用。最后，PIM-SM[RFC4601]通常用于传统IP网络（即不受约束的网络）中的多播路由。
IP multicast can also be run in an LL scope. This means that there is no routing involved, and an IP multicast message is only received over the link on which it was sent.
IP多播也可以在LL作用域中运行。这意味着不涉及路由，IP多播消息只通过发送它的链路接收。
For a complete IP multicast solution, in addition to a routing/ forwarding protocol, a "listener" protocol may be needed for the devices to subscribe to groups (see Section 4.2). Also, a multicast forwarding proxy node [RFC4605] may be required.
对于完整的IP多播解决方案，除了路由/转发协议外，设备可能还需要“侦听器”协议来订阅组（参见第4.2节）。此外，可能需要多播转发代理节点[RFC4605]。
IP multicast is generally classified as an unreliable service in that packets are not guaranteed to be delivered to each and every member of the group. In other words, it cannot be directly used as a basis for "reliable group communication" as defined in Section 1.3. However, the level of reliability can be increased by employing a multicast protocol that performs periodic retransmissions as is done, for example, in MPL.
IP多播通常被归类为一种不可靠的服务，因为不能保证将数据包发送给组中的每个成员。换句话说，它不能直接用作第1.3节中定义的“可靠群组通信”的基础。然而，可通过采用多播协议来提高可靠性水平，该多播协议执行例如在MPL中所做的周期性重传。
A CoAP group is defined as a set of CoAP endpoints, where each endpoint is configured to receive CoAP group communication requests that are sent to the group's associated IP multicast address. The individual response by each endpoint receiver to a CoAP group communication request is always sent back as unicast. An endpoint may be a member of multiple groups. Group membership of an endpoint may dynamically change over time.
CoAP组定义为一组CoAP端点，其中每个端点配置为接收发送到组的相关IP多播地址的CoAP组通信请求。每个端点接收器对CoAP组通信请求的单独响应始终作为单播发送回。端点可以是多个组的成员。端点的组成员资格可能会随时间动态变化。
All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast group (Section 12.8 of [RFC7252]) by default to enable CoAP discovery. For IPv4, the address is 224.0.1.187, and for IPv6, a server node joins at least both the link-local scoped address ff02::fd and the site-local scoped address ff05::fd. IPv6 addresses of other scopes MAY be enabled.
默认情况下，所有CoAP服务器节点应加入“所有CoAP节点”多播组（RFC7252第12.8节），以启用CoAP发现。对于IPv4，地址为224.0.1.187；对于IPv6，服务器节点至少连接链路本地作用域地址ff02:：fd和站点本地作用域地址ff05:：fd。可以启用其他作用域的IPv6地址。
A CoAP group URI has the scheme 'coap' and includes in the authority part either a group IP multicast address or a hostname (e.g., Group Fully Qualified Domain Name (FQDN)) that can be resolved to the group
CoAP组URI具有方案“CoAP”，并在授权部分中包括可解析为组的组IP多播地址或主机名（例如，组完全限定域名（FQDN））
IP multicast address. A group URI also contains an optional CoAP port number in the authority part. Group URIs follow the regular CoAP URI syntax (Section 6 of [RFC7252]).
IP多播地址。组URI在授权部分还包含可选的CoAP端口号。组URI遵循常规的CoAP URI语法（参见[RFC7252]第6节）。
Note: A group URI is needed to initiate CoAP group communications. For CoAP client implementations, it is recommended to use the URI decomposition method of Section 6.4 of [RFC7252] in such a way that, from a group URI, a CoAP group communication request is generated.
注意：启动CoAP组通信需要一个组URI。对于CoAP客户端实现，建议使用[RFC7252]第6.4节的URI分解方法，以便从组URI生成CoAP组通信请求。
For sending nodes, it is recommended to use the IP multicast address literal in a group URI. (This is because DNS infrastructure may not be deployed in many constrained network deployments.) However, in case a group hostname is used, it can be uniquely mapped to an IP multicast address via DNS resolution (if supported). Some examples of hierarchical group FQDN naming (and scoping) for a building control application are shown below:
对于发送节点，建议在组URI中使用IP多播地址文字。（这是因为DNS基础设施可能不会部署在许多受约束的网络部署中。）但是，如果使用组主机名，则可以通过DNS解析（如果支持）将其唯一映射到IP多播地址。建筑控制应用程序的分层组FQDN命名（和范围）的一些示例如下所示：
URI authority Targeted group of nodes
--------------------------------------- --------------------------
all.bldg6.example.com "all nodes in building 6"
all.west.bldg6.example.com "all nodes in west wing,
building 6"
all.floor1.west.bldg6.example.com "all nodes in floor 1,
west wing, building 6"
all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036,
floor 1, west wing,
building 6"
URI authority Targeted group of nodes
--------------------------------------- --------------------------
all.bldg6.example.com "all nodes in building 6"
all.west.bldg6.example.com "all nodes in west wing,
building 6"
all.floor1.west.bldg6.example.com "all nodes in floor 1,
west wing, building 6"
all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036,
floor 1, west wing,
building 6"
Similarly, if supported, reverse mapping (from IP multicast address to Group FQDN) is possible using the reverse DNS resolution technique ([RFC1033]). Reverse mapping is important, for example, in troubleshooting to translate IP multicast addresses back to human-readable hostnames to show in a diagnostics user interface.
类似地，如果支持，可以使用反向DNS解析技术（[RFC1033]）进行反向映射（从IP多播地址到组FQDN）。反向映射很重要，例如，在故障排除过程中，将IP多播地址转换回人类可读的主机名以显示在诊断用户界面中。
A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683. If the group uses a specified non-default UDP port, be careful to ensure that all group members are configured to use that same port.
作为组成员的CoAP服务器在组的IP多播地址（通常在CoAP默认UDP端口5683上）上侦听CoAP消息。如果组使用指定的非默认UDP端口，请小心确保所有组成员都配置为使用该端口。
Different ports for the same IP multicast address are preferably not used to specify different CoAP groups. If disjoint groups share the same IP multicast address, then all the devices interested in one group will accept IP traffic also for the other disjoint groups, only to ultimately discard the traffic higher in their IP stack (based on UDP port discrimination).
同一IP多播地址的不同端口最好不用于指定不同的CoAP组。如果不相交的组共享相同的IP多播地址，则对一个组感兴趣的所有设备也将接受其他不相交组的IP流量，最终只会丢弃其IP堆栈中较高的流量（基于UDP端口区分）。
CoAP group communication will not work if there is diversity in the authority port (e.g., different dynamic port addresses across the group) or if other parts of the group URI such as the path, or the query, differ on different endpoints. Therefore, some measures must be present to ensure uniformity in port number and resource names/ locations within a group. All CoAP group communication requests MUST be sent using a port number according to one of the below options:
如果授权端口存在多样性（例如，组中不同的动态端口地址），或者组URI的其他部分（如路径或查询）在不同端点上不同，则CoAP组通信将不起作用。因此，必须采取一些措施，以确保组内端口号和资源名称/位置的一致性。必须根据以下选项之一使用端口号发送所有CoAP组通信请求：
1. A preconfigured port number.
1. 预配置的端口号。
2. If the client is configured to use service discovery including URI and port discovery, it uses the port number obtained via a service discovery lookup operation for the targeted CoAP group.
2. 如果客户端配置为使用服务发现（包括URI和端口发现），则它将使用通过目标CoAP组的服务发现查找操作获得的端口号。
3. Use the default CoAP UDP port (5683).
3. 使用默认的CoAP UDP端口（5683）。
For a CoAP server node that supports resource discovery, the default port 5683 must be supported (Section 7.1 of [RFC7252]) for the "All CoAP Nodes" group. Regardless of the method of selecting the port number, the same port MUST be used across all CoAP servers in a group and across all CoAP clients performing the group requests.
对于支持资源发现的CoAP服务器节点，“所有CoAP节点”组必须支持默认端口5683（RFC7252第7.1节）。无论选择端口号的方法如何，组中的所有CoAP服务器和执行组请求的所有CoAP客户端都必须使用相同的端口。
All CoAP group communication requests SHOULD operate on group URI paths in one of the following ways:
所有CoAP组通信请求应通过以下方式之一在组URI路径上运行：
1. Preconfigured group URI paths, if available. Implementers are free to define the paths as they see fit. However, note that [RFC7320] prescribes that a specification must not constrain or define the structure or semantics for any path component. So for this reason, a predefined URI path is not specified in this document and also must not be provided in other specifications.
1. 预配置的组URI路径（如果可用）。实现者可以自由地定义他们认为合适的路径。但是，请注意，[RFC7320]规定规范不得约束或定义任何路径组件的结构或语义。因此，由于这个原因，本文档中没有指定预定义的URI路径，其他规范中也不能提供该路径。
2. If the client is configured to use default Constrained RESTful Environments (CoRE) resource discovery, it uses URI paths retrieved from a "/.well-known/core" lookup on a group member. The URI paths the client will use MUST be known to be available also in all other endpoints in the group. The URI path configuration mechanism on servers MUST ensure that these URIs (identified as being supported by the group) are configured on all group endpoints.
2. 如果客户机配置为使用默认的受约束RESTful环境（CoRE）资源发现，则它将使用从组成员的“/.well-known/CoRE”查找中检索的URI路径。必须知道客户端将使用的URI路径在组中的所有其他端点中也可用。服务器上的URI路径配置机制必须确保在所有组端点上配置这些URI（标识为受组支持）。
3. If the client is configured to use another form of service discovery, it uses group URI paths from an equivalent service discovery lookup that returns the resources supported by all group members.
3. 如果客户端配置为使用另一种形式的服务发现，则它将使用来自等效服务发现查找的组URI路径，该查找返回所有组成员支持的资源。
4. If the client has received a group URI through a previous RESTful interaction with a trusted server, it can use this URI in a CoAP group communication request. For example, a commissioning tool may instruct a sensor device in this way to which target group (group URI) it should report sensor events.
4. 如果客户机通过以前与受信任服务器的RESTful交互收到了组URI，那么它可以在CoAP组通信请求中使用此URI。例如，调试工具可以通过这种方式指示传感器设备向哪个目标组（组URI）报告传感器事件。
However, when the URI path is selected, the same path MUST be used across all CoAP servers in a group and all CoAP clients performing the group requests.
但是，当选择URI路径时，组中的所有CoAP服务器和执行组请求的所有CoAP客户端必须使用相同的路径。
Group communication most often uses the idempotent CoAP methods GET and PUT. The idempotent method DELETE can also be used. The non-idempotent CoAP method POST may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. For example, a client may resend a multicast POST request for additional reliability. Some servers will receive the request two times while others may receive it only once. For idempotent methods, all these servers will be in the same state while for POST, this is not guaranteed; so, the resource POST operation must be specifically designed to take message loss into account.
组通信通常使用幂等CoAP方法GET和PUT。还可以使用幂等方法DELETE。非幂等CoAP方法POST仅可用于组通信，前提是发送到的资源被设计为处理IP多播的不可靠和有损性质。例如，客户端可以重新发送多播POST请求以获得额外的可靠性。某些服务器将接收两次请求，而其他服务器可能只接收一次。对于幂等方法，所有这些服务器将处于相同的状态，而对于POST，这是不保证的；因此，必须专门设计资源POST操作，以考虑消息丢失。
All CoAP requests that are sent via IP multicast must be Non-confirmable (Section 8.1 of [RFC7252]). The Message ID in an IP multicast CoAP message is used for optional message deduplication as detailed in Section 4.5 of [RFC7252].
通过IP多播发送的所有CoAP请求必须是不可确认的（RFC7252第8.1节）。IP多播CoAP消息中的消息ID用于可选的消息重复数据消除，详见[RFC7252]第4.5节。
A server optionally sends back a unicast response to the CoAP group communication request (e.g., response "2.05 Content" to a group GET request). The unicast responses received by the CoAP client may be a mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found) codes depending on the individual server processing results. Detailed processing rules for IP multicast request acceptance and unicast response suppression are given in Section 2.7.
服务器可选地向CoAP组通信请求发回单播响应（例如，对组GET请求的响应“2.05内容”）。CoAP客户端接收到的单播响应可能是成功（例如，2.05内容）和失败（例如，4.04未找到）代码的混合，这取决于单个服务器的处理结果。第2.7节给出了IP多播请求接受和单播响应抑制的详细处理规则。
A CoAP request sent over IP multicast and any unicast response it causes must take into account the congestion control rules defined in Section 2.8.
通过IP多播发送的CoAP请求及其引起的任何单播响应必须考虑第2.8节中定义的拥塞控制规则。
The CoAP client can distinguish the origin of multiple server responses by the source IP address of the UDP message containing the CoAP response or any other available unique identifier (e.g.,
CoAP客户端可以通过包含CoAP响应的UDP消息的源IP地址或任何其他可用唯一标识符（例如。，
contained in the CoAP payload). In case a CoAP client sent multiple group requests, the responses are as usual matched to a request using the CoAP Token.
包含在CoAP有效载荷中）。如果一个CoAP客户端发送了多个组请求，则响应通常与使用CoAP令牌的请求相匹配。
For multicast CoAP requests, there are additional constraints on the reuse of Token values, compared to the unicast case. In the unicast case, receiving a response effectively frees up its Token value for reuse since no more responses will follow. However, for multicast CoAP, the number of responses is not bounded a priori. Therefore, the reception of a response cannot be used as a trigger to "free up" a Token value for reuse. Reusing a Token value too early could lead to incorrect response/request matching in the client and would be a protocol error. Therefore, the time between reuse of Token values used in multicast requests MUST be greater than:
对于多播CoAP请求，与单播情况相比，在令牌值的重用方面存在额外的限制。在单播情况下，接收响应可以有效地释放其令牌值以供重用，因为随后不会有更多响应。然而，对于多播CoAP，响应的数量不是先验的有界的。因此，响应的接收不能用作“释放”令牌值以供重用的触发器。过早重用令牌值可能会导致客户端中的响应/请求匹配不正确，这将是一个协议错误。因此，复用多播请求中使用的令牌值之间的时间间隔必须大于：
NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY
非生命周期+最大延迟+最大服务器响应延迟
where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of [RFC7252]. MAX_SERVER_RESPONSE_DELAY is defined here as the expected maximum response delay over all servers that the client can send a multicast request to. This delay includes the maximum Leisure time period as defined in Section 8.2 of [RFC7252]. CoAP does not define a time limit for the server response delay. Using the default CoAP parameters, the Token reuse time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. A preferred solution to meet this requirement is to generate a new unique Token for every multicast request, such that a Token value is never reused. If a client has to reuse Token values for some reason, and also MAX_SERVER_RESPONSE_DELAY is unknown, then using MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. The time between Token reuses is in that case set to a value greater than 500 seconds.
其中[RFC7252]第4.8节定义了非_寿命和最大_延迟。MAX_SERVER_RESPONSE_DELAY在此定义为客户端可以向其发送多播请求的所有服务器上的预期最大响应延迟。该延迟包括[RFC7252]第8.2节中定义的最大空闲时间。CoAP没有为服务器响应延迟定义时间限制。使用默认CoAP参数，令牌重用时间必须大于250秒加上最大服务器响应延迟。满足此要求的首选解决方案是为每个多播请求生成一个新的唯一令牌，这样令牌值就永远不会被重用。如果客户端出于某种原因必须重用令牌值，并且MAX_SERVER_RESPONSE_DELAY未知，那么使用MAX_SERVER_RESPONSE_DELAY=250秒是一个合理的指导原则。在这种情况下，令牌重用之间的时间设置为大于500秒的值。
CoAP groups, and the membership of these groups, can be discovered via the lookup interfaces in the Resource Directory (RD) defined in [CoRE-RD]. This discovery interface is not required to invoke CoAP group communications. However, it is a potential complementary interface useful for overall management of CoAP groups. Other methods to discover groups (e.g., proprietary management systems) can also be used. An example of doing some of the RD-based lookups is given in Section 3.6.
CoAP组以及这些组的成员资格可以通过[CoRE RD]中定义的资源目录（RD）中的查找接口来发现。调用CoAP组通信不需要此发现接口。然而，它是一个潜在的补充接口，有助于全面管理CoAP小组。也可以使用其他方法来发现组（例如，专有管理系统）。第3.6节给出了执行一些基于RD的查找的示例。
The group membership of a CoAP endpoint may be configured in one of the following ways. First, the group membership may be preconfigured before node deployment. Second, a node may be programmed to discover (query) its group membership using a specific service discovery means. Third, it may be configured by another node (e.g., a commissioning device).
CoAP端点的组成员资格可以通过以下方式之一进行配置。首先，可以在部署节点之前预先配置组成员资格。第二，节点可以被编程为使用特定的服务发现手段来发现（查询）其组成员资格。第三，它可以由另一个节点（例如，调试设备）配置。
In the first case, the preconfigured group information may be either an IP multicast address or a hostname (FQDN) that is resolved later (during operation) to an IP multicast address by the endpoint using DNS (if supported).
在第一种情况下，预配置的组信息可以是IP多播地址或主机名（FQDN），该主机名稍后（在操作期间）由端点使用DNS解析为IP多播地址（如果支持）。
For the second case, a CoAP endpoint may look up its group membership using techniques such as DNS-based Service Discovery (DNS-SD) and RD [CoRE-RD].
对于第二种情况，CoAP端点可以使用诸如基于DNS的服务发现（DNS-SD）和RD[核心RD]等技术来查找其组成员资格。
In the third case, typical in scenarios such as building control, a dynamic commissioning tool determines to which group(s) a sensor or actuator node belongs, and writes this information to the node, which can subsequently join the correct IP multicast group(s) on its network interface. The information written per group may again be an IP multicast address or a hostname.
在第三种情况下，动态调试工具确定传感器或执行器节点所属的组，并将此信息写入节点，该节点随后可以在其网络接口上加入正确的IP多播组，这在建筑控制等场景中是典型的。每个组写入的信息也可以是IP多播地址或主机名。
To achieve better interoperability between endpoints from different manufacturers, an OPTIONAL CoAP membership configuration RESTful interface for configuring endpoints with relevant group information is described here. This interface provides a solution for the third case mentioned above. To access this interface, a client will use unicast CoAP methods (GET/PUT/POST/DELETE). This interface is a method of configuring group information in individual endpoints.
为了在不同制造商的端点之间实现更好的互操作性，这里描述了一个可选的CoAP成员配置RESTful接口，用于使用相关组信息配置端点。此接口为上述第三种情况提供了解决方案。要访问此接口，客户端将使用单播CoAP方法（GET/PUT/POST/DELETE）。此接口是一种在各个端点中配置组信息的方法。
Also, a form of authorization (preferably making use of unicast DTLS-secured CoAP per Section 9.1 of [RFC7252]) should be used such that only authorized controllers are allowed by an endpoint to configure its group membership.
此外，还应使用一种授权形式（根据[RFC7252]第9.1节，最好使用单播DTLS安全CoAP），以便端点仅允许授权控制器配置其组成员资格。
It is important to note that other approaches may be used to configure CoAP endpoints with relevant group information. These alternative approaches may support a subset or superset of the membership configuration RESTful interface described in this document. For example, a simple interface to just read the endpoint group information may be implemented via a classical Management Information Base (MIB) approach (e.g., following the approach of [RFC3433]).
需要注意的是，可以使用其他方法来配置具有相关组信息的CoAP端点。这些替代方法可能支持本文档中描述的成员资格配置RESTful接口的子集或超集。例如，可通过经典管理信息库（MIB）方法（例如，遵循[RFC3433]的方法）实现仅读取端点组信息的简单接口。
CoAP endpoints implementing the membership configuration RESTful interface MUST support the CoAP group configuration Internet Media Type "application/coap-group+json" (Section 6.2).
实现成员资格配置RESTful接口的CoAP端点必须支持CoAP组配置Internet媒体类型“应用程序/CoAP组+json”（第6.2节）。
A resource offering this representation can be annotated for direct discovery [RFC6690] using the Resource Type (rt=) Link Target Attribute "core.gp", where "gp" is shorthand for "group" (Section 6.1). An authorized client uses this media type to query/ manage group membership of a CoAP endpoint as defined in the following subsections.
提供此表示的资源可以使用资源类型（rt=）链接目标属性“core.gp”为直接发现[RFC6690]添加注释，其中“gp”是“组”的缩写（第6.1节）。授权客户端使用此媒体类型查询/管理CoAP端点的组成员资格，如以下小节所定义。
The Group Configuration resource and its sub-resources have a content format based on JavaScript Object Notation (JSON) (as indicated by the "application/coap-group+json" media type). The resource includes zero or more group membership JSON objects [RFC7159] in a format as defined in Section 2.6.2.4. A group membership JSON object contains one or more key/value pairs as defined below, and represents a single IP multicast group membership for the CoAP endpoint. Each key/value pair is encoded as a member of the JSON object, where the key is the member name and the value is the member's value.
组配置资源及其子资源具有基于JavaScript对象表示法（JSON）的内容格式（如“application/coap Group+JSON”媒体类型所示）。该资源包括零个或多个组成员JSON对象[RFC7159]，格式如第2.6.2.4节所定义。group membership JSON对象包含一个或多个键/值对，定义如下，表示CoAP端点的单个IP多播组成员身份。每个键/值对都被编码为JSON对象的一个成员，其中键是成员名称，值是成员的值。
Examples of four different group membership objects are as follows:
以下是四个不同的组成员资格对象的示例：
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
{ "n": "sensors.floor2.east.bldg6.example.com" }
{ "n": "sensors.floor2.east.bldg6.example.com" }
{ "n": "coap-test",
"a": "224.0.1.187:56789" }
{ "n": "coap-test",
"a": "224.0.1.187:56789" }
{ "a": "[ff15::c0a7:15:c001]" }
{ "a": "[ff15::c0a7:15:c001]" }
The OPTIONAL "n" key/value pair stands for "name" and identifies the group with a hostname (and optionally the port number), for example, an FQDN. The OPTIONAL "a" key/value pair specifies the IP multicast address (and optionally the port number) of the group. It contains an IPv4 address (in dotted-decimal notation) or an IPv6 address. The following ABNF rule can be used for parsing the address, referring to the definitions in Section 3.2.2 of [RFC3986] that are also used in the base CoAP (Section 6 of [RFC7252].
可选的“n”键/值对代表“name”，并使用主机名（可选端口号）标识组，例如FQDN。可选的“a”键/值对指定组的IP多播地址（可选端口号）。它包含IPv4地址（以点十进制表示法）或IPv6地址。以下ABNF规则可用于解析地址，参考[RFC3986]第3.2.2节中的定义，这些定义也用于基本CoAP（RFC7252第6节）。
group-address = IPv4address [ ":" port ]
/ "[" IPv6address "]" [":" port ]
group-address = IPv4address [ ":" port ]
/ "[" IPv6address "]" [":" port ]
In any group membership object, if the IP address is known when the object is created, it is included in the "a" key/value pair. If the "a" value cannot be provided, the "n" value MUST be included, containing a valid hostname with an optional port number that can be translated to an IP multicast address via DNS.
在任何组成员身份对象中，如果在创建对象时知道IP地址，则它将包含在“a”键/值对中。如果无法提供“a”值，则必须包含“n”值，其中包含一个有效主机名，该主机名具有可选端口号，可通过DNS转换为IP多播地址。
group-name = host [ ":" port ]
组名=主机[“：”端口]
If the port number is not provided, then the endpoint will attempt to look up the port number from DNS if it supports a method to do this. The possible DNS methods include DNS SRV [RFC2782] or DNS-SD [RFC6763]. If port lookup is not supported or not provided by DNS, the default CoAP port (5683) is assumed.
如果未提供端口号，那么端点将尝试从DNS查找端口号（如果它支持这样做的方法）。可能的DNS方法包括DNS SRV[RFC2782]或DNS-SD[RFC6763]。如果DNS不支持或不提供端口查找，则假定默认CoAP端口（5683）。
After any change on a Group Configuration resource, the endpoint MUST effect registration/deregistration from the corresponding IP multicast group(s) by making use of APIs such as IPV6_RECVPKTINFO [RFC3542].
在对组配置资源进行任何更改后，端点必须通过使用诸如IPV6_RECVPKTINFO[RFC3542]之类的API从相应的IP多播组进行注册/注销。
Method: POST
URI Template: /{+gp}
Location-URI Template: /{+gp}/{index}
URI Template Variables:
gp - Group Configuration Function Set path (mandatory).
index - Group index. Index MUST be a string of maximum two (2)
alphanumeric ASCII characters (case insensitive). It MUST be
locally unique to the endpoint server. It indexes the particular
endpoint's list of group memberships.
Method: POST
URI Template: /{+gp}
Location-URI Template: /{+gp}/{index}
URI Template Variables:
gp - Group Configuration Function Set path (mandatory).
index - Group index. Index MUST be a string of maximum two (2)
alphanumeric ASCII characters (case insensitive). It MUST be
locally unique to the endpoint server. It indexes the particular
endpoint's list of group memberships.
Example:
Req: POST /coap-group
Content-Format: application/coap-group+json
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
Res: 2.01 Created
Location-Path: /coap-group/12
Example:
Req: POST /coap-group
Content-Format: application/coap-group+json
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
Res: 2.01 Created
Location-Path: /coap-group/12
For the 'gp' variable, it is recommended to use the path "coap-group" by default. The "a" key/value pair is always used if it is given. The "n" pair is only used when there is no "a" pair. If only the "n" pair is given, the CoAP endpoint performs DNS resolution to obtain the IP multicast address from the hostname in the "n" pair. If DNS resolution is not successful, then the endpoint does not attempt joining or listening to any multicast group for this case since the IP multicast address is unknown.
对于“gp”变量，建议默认情况下使用路径“coap group”。如果给定“a”键/值对，则始终使用它。“n”对仅在没有“a”对时使用。如果只给出了“n”对，CoAP端点将执行DNS解析以从“n”对中的主机名获取IP多播地址。如果DNS解析未成功，则端点不会尝试加入或侦听此情况下的任何多播组，因为IP多播地址未知。
After any change on a Group Configuration resource, the endpoint MUST effect registration/deregistration from the corresponding IP multicast group(s) by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. When a POST payload contains an "a", an IP multicast address to which the endpoint is already subscribed, no change to that subscription is needed.
在对组配置资源进行任何更改后，端点必须通过使用诸如IPV6_RECVPKTINFO[RFC3542]之类的API从相应的IP多播组进行注册/注销。当POST有效负载包含一个“a”（端点已订阅的IP多播地址）时，不需要更改该订阅。
Method: DELETE URI Template: {+location} URI Template Variables: location - The Location-Path returned by the CoAP server as a result of a successful group creation.
方法：删除URI模板：{+location}URI模板变量：location-CoAP服务器在成功创建组后返回的位置路径。
Example:
Req: DELETE /coap-group/12
Res: 2.02 Deleted
Example:
Req: DELETE /coap-group/12
Res: 2.02 Deleted
A (unicast) GET on the CoAP-group resource returns a JSON object containing multiple keys and values. The keys (member names) are group indices, and the values (member values) are the corresponding group membership objects. Each group membership object describes one IP multicast group membership. If no group memberships are configured, then an empty JSON object is returned.
CoAP组资源上的（单播）GET返回一个包含多个键和值的JSON对象。键（成员名称）是组索引，值（成员值）是相应的组成员资格对象。每个组成员身份对象描述一个IP多播组成员身份。如果未配置组成员身份，则返回空的JSON对象。
Method: GET
方法：获取
URI Template: /{+gp}
URI Template: /{+gp}
URI Template Variables:
URI模板变量：
gp - see Section 2.6.2.2
总成-见第2.6.2.2节
Example:
Req: GET /coap-group
Res: 2.05 Content
Content-Format: application/coap-group+json
{ "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" },
"11":{ "n": "sensors.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:25cb]" },
"12":{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
}
Example:
Req: GET /coap-group
Res: 2.05 Content
Content-Format: application/coap-group+json
{ "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" },
"11":{ "n": "sensors.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:25cb]" },
"12":{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
}
Note: the returned IPv6 address string will represent the same IPv6 address that was originally submitted in group membership creation, though it might be a different string because of different choices in IPv6 string representation formatting that may be allowed for the same address (see [RFC5952]).
注意：返回的IPv6地址字符串将表示最初在组成员身份创建中提交的相同IPv6地址，但可能是不同的字符串，因为同一地址可能允许使用不同的IPv6字符串表示格式（请参见[RFC5952]）。
Similar to Section 2.6.2.4, but only a single group membership is read. If the requested group index does not exist, then a 4.04 Not Found response is returned.
与第2.6.2.4节类似，但仅读取单个组成员资格。如果请求的组索引不存在，则返回4.04 not Found响应。
Method: GET
方法：获取
URI Template 1: {+location}
URI Template 1: {+location}
URI Template 2: /{+gp}/{index}
URI Template 2: /{+gp}/{index}
URI Template Variables:
URI模板变量：
location - see Section 2.6.2.3
位置-见第2.6.2.3节
gp, index - see Section 2.6.2.2
总成，索引-见第2.6.2.2节
Example:
Req: GET /coap-group/12
Res: 2.05 Content
Content-Format: application/coap-group+json
{"n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567"}
Example:
Req: GET /coap-group/12
Res: 2.05 Content
Content-Format: application/coap-group+json
{"n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567"}
A (unicast) PUT with a group configuration media type as payload will replace all current group memberships in the endpoint with the new ones defined in the PUT request. This operation MUST only be used to delete or update group membership objects for which the CoAP client, invoking this operation, is responsible. The responsibility is based on application-level knowledge. For example, a commissioning tool will be responsible for any group membership objects that it created.
组配置媒体类型为有效负载的（单播）PUT将用PUT请求中定义的新组成员身份替换端点中的所有当前组成员身份。此操作只能用于删除或更新由调用此操作的CoAP客户端负责的组成员身份对象。职责基于应用程序级知识。例如，调试工具将负责其创建的任何组成员资格对象。
Method: PUT
方法：将
URI Template: /{+gp}
URI Template: /{+gp}
URI Template Variables:
URI模板变量：
gp - see Section 2.6.2.2
总成-见第2.6.2.2节
Example: (replacing all existing group memberships with two new
group memberships)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{ "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" },
"2":{ "a": "[ff15::4200:f7fe:ed37:5678]" }
}
Res: 2.04 Changed
Example: (replacing all existing group memberships with two new
group memberships)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{ "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" },
"2":{ "a": "[ff15::4200:f7fe:ed37:5678]" }
}
Res: 2.04 Changed
Example: (clearing all group memberships at once)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{}
Res: 2.04 Changed
Example: (clearing all group memberships at once)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{}
Res: 2.04 Changed
After a successful PUT on the Group Configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and deregistration from any previous IP multicast group(s), i.e., not any more present in the new memberships. An API such as IPV6_RECVPKTINFO [RFC3542] should be used for this purpose. Also, it MUST take into account the group indices present in the new resource during the generation of any new unique group indices in the future.
成功放置组配置资源后，端点必须注册到任何新的IP多播组，并从任何以前的IP多播组注销，即不再存在于新成员身份中。为此，应使用诸如IPV6_RECVPKTINFO[RFC3542]之类的API。此外，在将来生成任何新的唯一组指数时，必须考虑新资源中存在的组指数。
A (unicast) PUT with a group membership JSON object will replace an existing group membership in the endpoint with the new one defined in the PUT request. This can be used to update the group membership.
具有组成员身份JSON对象的（单播）PUT将用PUT请求中定义的新组成员身份替换端点中的现有组成员身份。这可用于更新组成员资格。
Method: PUT
方法：将
URI Template 1: {+location}
URI Template 1: {+location}
URI Template 2: /{+gp}/{index}
URI Template 2: /{+gp}/{index}
URI Template Variables:
URI模板变量：
location - see Section 2.6.2.3
位置-见第2.6.2.3节
gp, index - see Section 2.6.2.2
总成，索引-见第2.6.2.2节
Example: (group name and IP multicast port change)
Req: PUT /coap-group/12
Content-Format: application/coap-group+json
{"n": "All-My-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]"}
Res: 2.04 Changed
Example: (group name and IP multicast port change)
Req: PUT /coap-group/12
Content-Format: application/coap-group+json
{"n": "All-My-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]"}
Res: 2.04 Changed
After a successful PUT on the Group Configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and deregistration from any previous IP multicast group(s), i.e., not any more present in the new membership. An API such as IPV6_RECVPKTINFO [RFC3542] should be used for this purpose.
成功放置组配置资源后，端点必须注册到任何新的IP多播组，并从任何以前的IP多播组取消注册，即不再存在于新成员身份中。为此，应使用诸如IPV6_RECVPKTINFO[RFC3542]之类的API。
CoRE Link Format [RFC6690] and Section 8 of CoAP [RFC7252] define behaviors for the following:
核心链接格式[RFC6690]和CoAP[RFC7252]第8节定义了以下行为：
1. IP multicast request acceptance -- in which cases a CoAP request is accepted and executed, and when it is not.
1. IP多播请求接受——在这种情况下，接受并执行CoAP请求，但实际情况并非如此。
2. IP multicast response suppression -- in which cases the CoAP response to an already executed request is returned to the requesting endpoint, and when it is not.
2. IP多播响应抑制——在这种情况下，对已经执行的请求的CoAP响应将返回到请求端点，而不是。
A CoAP response differs from a CoAP ACK; ACKs are never sent by servers in response to an IP multicast CoAP request. This section first summarizes these behaviors and then presents additional guidelines for response suppression. Also, a number of IP multicast example applications are given to illustrate the overall approach.
CoAP响应不同于CoAP ACK；服务器永远不会发送ACK来响应IP多播CoAP请求。本节首先总结了这些行为，然后介绍了反应抑制的其他指南。此外，本文还给出了一些IP多播示例应用来说明整个方法。
To apply any rules for request and/or response suppression, a CoAP server must be aware that an incoming request arrived via IP multicast by making use of APIs such as IPV6_RECVPKTINFO [RFC3542].
要应用任何请求和/或响应抑制规则，CoAP服务器必须知道，通过使用IPV6_RECVPKTINFO[RFC3542]等API，通过IP多播到达传入请求。
For IP multicast request acceptance, the behaviors are as follows:
对于IP组播请求接受，行为如下：
o A server should not accept an IP multicast request that cannot be "authenticated" in some way (i.e, cryptographically or by some multicast boundary limiting the potential sources); see Section 11.3 of [RFC7252]. See Section 5.3 for examples of multicast boundary limiting methods.
o 服务器不应接受无法以某种方式（即，加密方式或限制潜在源的某个多播边界）进行“身份验证”的IP多播请求；见[RFC7252]第11.3节。有关多播边界限制方法的示例，请参见第5.3节。
o A server should not accept an IP multicast discovery request with a query string (as defined in CoRE Link Format [RFC6690]) if filtering [RFC6690] is not supported by the server.
o 如果服务器不支持筛选[RFC6690]，则服务器不应接受带有查询字符串（如核心链路格式[RFC6690]中定义的）的IP多播发现请求。
o A server should not accept an IP multicast request that acts on a specific resource for which IP multicast support is not required. (Note that for the resource "/.well-known/core", IP multicast support is required if "multicast resource discovery" is supported as specified in Section 1.2.1 of [RFC6690].) Implementers are advised to disable IP multicast support by default on any other resource, until explicitly enabled by an application or by configuration.
o 服务器不应接受作用于不需要IP多播支持的特定资源的IP多播请求。（请注意，对于资源“/.well-known/core”，如果[RFC6690]第1.2.1节规定支持“多播资源发现”，则需要IP多播支持）。建议实施者在默认情况下禁用任何其他资源上的IP多播支持，直到应用程序或配置显式启用。
o Otherwise, accept the IP multicast request.
o 否则，接受IP多播请求。
For IP multicast response suppression, the behaviors are as follows:
对于IP多播响应抑制，行为如下：
o A server should not respond to an IP multicast discovery request if the filter specified by the request's query string does not match.
o 如果请求的查询字符串指定的筛选器不匹配，则服务器不应响应IP多播发现请求。
o A server may choose not to respond to an IP multicast request if there's nothing useful to respond back (e.g., error or empty response).
o 如果没有任何有用的响应（例如错误或空响应），服务器可能会选择不响应IP多播请求。
The above response suppression behaviors are complemented by the following guidelines. CoAP servers should implement configurable response suppression, enabling at least the following options per resource that supports IP multicast requests:
以下指南补充了上述反应抑制行为。CoAP服务器应实现可配置的响应抑制，对支持IP多播请求的每个资源至少启用以下选项：
o Suppression of all 2.xx success responses;
o 抑制所有2.xx成功响应；
o Suppression of all 4.xx client errors;
o 抑制所有4.xx客户端错误；
o Suppression of all 5.xx server errors; and
o 抑制所有5.xx服务器错误；和
o Suppression of all 2.05 responses with empty payload.
o 使用空有效负载抑制所有2.05响应。
A number of CoAP group communication example applications are given below to illustrate how to make use of response suppression:
下面给出了许多CoAP组通信示例应用程序，以说明如何使用响应抑制：
o CoAP resource discovery: Suppress 2.05 responses with empty payload and all 4.xx and 5.xx errors.
o CoAP资源发现：使用空负载和所有4.xx和5.xx错误抑制2.05响应。
o Lighting control: Suppress all 2.xx responses after a lighting change command.
o 照明控制：在照明更改命令后抑制所有2.xx响应。
o Update configuration data in a group of devices using group communication PUT: No suppression at all. The client uses collected responses to identify which group members did not receive the new configuration and then attempts using CoAP CON unicast to update those specific group members. Note that in this case, the client implements a "reliable group communication" (as defined in Section 1.3) function using additional, non-standardized functions above the CoAP layer.
o 使用组通信PUT更新一组设备中的配置数据：无任何抑制。客户端使用收集的响应来确定哪些组成员未收到新配置，然后尝试使用CoAP CON unicast更新这些特定组成员。请注意，在这种情况下，客户机使用CoAP层上方的其他非标准化功能实现“可靠的组通信”（如第1.3节所定义）功能。
o IP multicast firmware update by sending blocks of data: Suppress all 2.xx and 5.xx responses. After having sent all IP multicast blocks, the client checks each endpoint by unicast to identify which data blocks are still missing in each endpoint.
o 通过发送数据块更新IP多播固件：抑制所有2.xx和5.xx响应。发送所有IP多播块后，客户端通过单播检查每个端点，以确定每个端点中仍缺少哪些数据块。
o Conditional reporting for a group (e.g., sensors) based on a group URI query: Suppress all 2.05 responses with empty payload (i.e., if a query produces no matching results).
o 基于组URI查询的组（例如，传感器）的条件报告：使用空负载抑制所有2.05响应（即，如果查询不产生匹配结果）。
CoAP group communication requests may result in a multitude of responses from different nodes, potentially causing congestion. Therefore, both the sending of IP multicast requests and the sending of the unicast CoAP responses to these multicast requests should be conservatively controlled.
CoAP组通信请求可能导致来自不同节点的大量响应，从而可能导致拥塞。因此，IP多播请求的发送和对这些多播请求的单播CoAP响应的发送都应该受到保守控制。
CoAP [RFC7252] reduces IP multicast-specific congestion risks through the following measures:
CoAP[RFC7252]通过以下措施降低IP多播特定的拥塞风险：
o A server may choose not to respond to an IP multicast request if there's nothing useful to respond to (e.g., error or empty response); see Section 8.2 of [RFC7252]. See Section 2.7 for more detailed guidelines on response suppression.
o 如果没有有用的响应（例如，错误或空响应），服务器可以选择不响应IP多播请求；见[RFC7252]第8.2节。有关响应抑制的更多详细指南，请参见第2.7节。
o A server should limit the support for IP multicast requests to specific resources where multicast operation is required (Section 11.3 of [RFC7252]).
o 服务器应将对IP多播请求的支持限制为需要多播操作的特定资源（RFC7252第11.3节）。
o An IP multicast request must be Non-confirmable (Section 8.1 of [RFC7252]).
o IP多播请求必须是不可确认的（RFC7252第8.1节）。
o A response to an IP multicast request should be Non-confirmable (Section 5.2.3 of [RFC7252]).
o 对IP多播请求的响应应该是不可确认的（RFC7252第5.2.3节）。
o A server does not respond immediately to an IP multicast request and should first wait for a time that is randomly picked within a predetermined time interval called the Leisure (Section 8.2 of [RFC7252]).
o 服务器不会立即响应IP多播请求，应首先等待在称为空闲的预定时间间隔内随机选取的时间（RFC7252第8.2节）。
Additional guidelines to reduce congestion risks defined in this document are as follows:
本文件中定义的减少拥堵风险的其他指南如下：
o A server in an LLN should only support group communication GET for resources that are small. For example, the payload of the response is limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size, so it fits into a single link-layer frame in case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see Section 4 of [RFC4944]) is used.
o LLN中的服务器应仅支持小型资源的组通信GET。例如，响应的有效载荷限制在IP最大传输单元（MTU）大小的5%左右，因此在使用低功率无线个人区域网络（6LoWPAN）上的IPv6（参见[RFC4944]第4节）的情况下，它适合于单个链路层帧。
o A server can minimize the payload length in response to a group communication GET on "/.well-known/core" by using hierarchy in arranging link descriptions for the response. An example of this is given in Section 5 of [RFC6690].
o 通过使用层次结构来安排响应的链接描述，服务器可以最小化对组通信GET on“/.well-known/core”的有效负载长度。[RFC6690]第5节给出了一个例子。
o A server can also minimize the payload length of a response to a group communication GET (e.g., on "/.well-known/core") using CoAP blockwise transfers [BLOCKWISE-CoAP], returning only a first block of the CoRE Link Format description. For this reason, a CoAP client sending an IP multicast CoAP request to "/.well-known/core" should support core-block.
o 服务器还可以使用CoAP分块传输[分块CoAP]最小化对组通信GET（例如，在“/.well-known/core”）的响应的有效负载长度，仅返回核心链路格式描述的第一个块。因此，向“/.well-known/core”发送IP多播CoAP请求的CoAP客户端应该支持核心块。
o A client should use CoAP group communication with the smallest possible IP multicast scope that fulfills the application needs. As an example, site-local scope is always preferred over global scope IP multicast if this fulfills the application needs. Similarly, realm-local scope is always preferred over site-local scope if this fulfills the application needs.
o 客户机应使用CoAP组通信，以尽可能小的IP多播范围满足应用程序的需要。例如，如果满足应用程序的需要，站点本地作用域总是优先于全局作用域IP多播。类似地，如果满足应用程序的需要，领域本地范围总是优先于站点本地范围。
More guidelines specific to the use of CoAP in 6LoWPAN networks [RFC4919] are given in Section 4.5 of this document.
本文件第4.5节中给出了有关在6LoWPAN网络[RFC4919]中使用CoAP的更多具体指南。
CoAP (Section 5.7.2 of [RFC7252]) allows a client to request a forward-proxy to process its CoAP request. For this purpose, the client specifies either the request group URI as a string in the Proxy-URI option or the Proxy-Scheme option with the group URI constructed from the usual Uri-* options. This approach works well for unicast requests. However, there are certain issues and limitations of processing the (unicast) responses to a CoAP group communication request made in this manner through a proxy.
CoAP（RFC7252第5.7.2节）允许客户请求转发代理来处理其CoAP请求。为此，客户机在Proxy URI选项中将请求组URI指定为字符串，或者在Proxy Scheme选项中将组URI指定为从常用URI-*选项构造的字符串。这种方法适用于单播请求。然而，处理通过代理以这种方式发出的CoAP组通信请求的（单播）响应存在某些问题和限制。
A proxy may buffer all the individual (unicast) responses to a CoAP group communication request and then send back only a single (aggregated) response to the client. However, there are some issues with this aggregation approach:
代理可以缓冲对CoAP组通信请求的所有单个（单播）响应，然后仅向客户端发送单个（聚合）响应。但是，这种聚合方法存在一些问题：
o Aggregation of (unicast) responses to a CoAP group communication request in a proxy is difficult. This is because the proxy does not know how many members there are in the group or how many group members will actually respond. Also, the proxy does not know how long to wait before deciding to send back the aggregated response to the client.
o 很难在代理中聚合对CoAP组通信请求的（单播）响应。这是因为代理不知道组中有多少成员，也不知道有多少组成员将实际响应。此外，代理不知道在决定将聚合响应发送回客户端之前需要等待多长时间。
o There is no default format defined in CoAP for aggregation of multiple responses into a single response.
o CoAP中没有定义将多个响应聚合为单个响应的默认格式。
Alternatively, if a proxy follows directly the specification for a CoAP Proxy (Section 5.7.2 of [RFC7252]), the proxy would simply forward all the individual (unicast) responses to a CoAP group communication request to the client (i.e., no aggregation). There are also issues with this approach:
或者，如果代理直接遵循CoAP代理规范（RFC7252的第5.7.2节），则代理只需将对CoAP组通信请求的所有单独（单播）响应转发给客户端（即，无聚合）。这种方法也存在一些问题：
o The client may be confused as it may not have known that the Proxy-URI contained a group URI target. That is, the client may be expecting only one (unicast) response but instead receives multiple (unicast) responses, potentially leading to fault conditions in the application.
o 客户端可能会感到困惑，因为它可能不知道代理URI包含组URI目标。也就是说，客户端可能只期望一个（单播）响应，但却接收多个（单播）响应，这可能导致应用程序出现故障。
o Each individual CoAP response will appear to originate (IP source address) from the CoAP Proxy, and not from the server that produced the response. This makes it impossible for the client to identify the server that produced each response.
o 每个单独的CoAP响应似乎来自CoAP代理，而不是产生响应的服务器（IP源地址）。这使得客户端无法识别产生每个响应的服务器。
Due to the above issues, a CoAP Proxy SHOULD NOT support processing an IP multicast CoAP request but rather return a 501 (Not Implemented) response in such case. The exception case here (i.e., to process it) is allowed if all the following conditions are met:
由于上述问题，CoAP代理不应支持处理IP多播CoAP请求，而是在这种情况下返回501（未实现）响应。如果满足以下所有条件，则允许此处的例外情况（即处理它）：
o The CoAP Proxy MUST be explicitly configured (whitelist) to allow proxied IP multicast requests by a specific client(s).
o 必须明确配置CoAP代理（白名单），以允许特定客户端代理IP多播请求。
o The proxy SHOULD return individual (unicast) CoAP responses to the client (i.e., not aggregated). The exception case here occurs when a (future) standardized aggregation format is being used.
o 代理应向客户端返回单个（单播）CoAP响应（即，不聚合）。这里的例外情况发生在使用（未来）标准化聚合格式时。
o It MUST be known to the person/entity doing the configuration of the proxy, or otherwise verified in some way, that the client configured in the whitelist supports receiving multiple responses to a proxied unicast CoAP request.
o 进行代理配置的人员/实体必须知道，或者以某种方式验证，在白名单中配置的客户端支持接收对代理单播CoAP请求的多个响应。
CoAP group communication using IP multicast offers improved network efficiency and latency among other benefits. However, group communication may not always be implementable in a given network. The primary reason for this will be that IP multicast is not (fully) supported in the network.
使用IP多播的CoAP组通信提供了改进的网络效率和延迟等好处。然而，在给定的网络中，组通信可能并不总是可以实现的。主要原因是网络中不（完全）支持IP多播。
For example, if only RPL [RFC6550] is used in a network with its optional multicast support disabled, there will be no IP multicast routing at all. The only multicast that works in this case is link-local IPv6 multicast. This implies that any CoAP group communication request will be delivered to nodes on the local link only, regardless of the scope value used in the IPv6 destination address.
例如，如果在禁用可选多播支持的网络中仅使用RPL[RFC6550]，则将根本不存在IP多播路由。在这种情况下，唯一有效的多播是链路本地IPv6多播。这意味着，无论IPv6目标地址中使用的作用域值如何，任何CoAP组通信请求都将仅发送到本地链路上的节点。
CoAP Observe [OBSERVE-CoAP] is a feature for a client to "observe" resources (i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time). CoAP Observe does not support a group communication mode. CoAP Observe only supports a unicast mode of operation.
CoAP Observe[观察CoAP]是客户端“观察”资源（即检索资源的表示并在一段时间内保持此表示由服务器更新）的功能。CoAP观察不支持组通信模式。CoAP观察仅支持单播操作模式。
The use of CoAP group communication is shown in the context of the following two use cases and corresponding protocol flows:
在以下两个用例和相应的协议流的上下文中显示了CoAP组通信的使用：
o Discovery of RD [CoRE-RD]: discovering the local CoAP RD, which contains links to resources stored on other CoAP servers [RFC6690].
o 发现RD[核心RD]：发现本地CoAP RD，其中包含指向存储在其他CoAP服务器上的资源的链接[RFC6690]。
o Lighting Control: synchronous operation of a group of IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights).
o 照明控制：一组连接IPv6的灯（例如6LoWPAN[RFC4944]灯）的同步操作。
To illustrate the use cases, we define two IPv6 network configurations. Both are based on the topology as shown in Figure 1. The two configurations using this topology are as follows:
为了说明用例，我们定义了两种IPv6网络配置。两者都基于如图1所示的拓扑。使用此拓扑的两种配置如下所示：
1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 6LoWPAN Border Routers (6LBRs) [RFC6775].
1. 子网是6LoWPAN网络；路由器Rtr-1和Rtr-2是6LoWPAN边界路由器（6LBR）[RFC6775]。
2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are multicast-capable Ethernet routers.
2. 子网是以太网链路；路由器Rtr-1和Rtr-2是支持多播的以太网路由器。
Both configurations are further specified by the following:
这两种配置由以下内容进一步规定：
o A large room (Room-A) with three lights (Light-1, Light-2, Light-3) controlled by a light switch (Light Switch). The devices are organized into two subnets. In reality, there could be more lights (up to several hundreds) but, for clarity, only three are shown.
o 有三盏灯（灯-1、灯-2、灯-3）的大房间（房间-A），由灯开关（灯开关）控制。这些设备被组织成两个子网。实际上，可能会有更多的灯光（多达数百个），但为了清晰起见，只显示了三个。
o Light-1 and the light switch are connected to a router (Rtr-1).
o 灯-1和灯开关连接到路由器（Rtr-1）。
o Light-2 and Light-3 are connected to another router (Rtr-2).
o Light-2和Light-3连接到另一个路由器（Rtr-2）。
o The routers are connected to an IPv6 network backbone (Network Backbone) that is also multicast enabled. In the general case, this means the network backbone and Rtr-1/Rtr-2 support a PIM-based multicast routing protocol and Multicast Listener Discovery (MLD) for forming groups.
o 路由器连接到同时启用多播的IPv6网络主干（网络主干）。在一般情况下，这意味着网络主干和Rtr-1/Rtr-2支持基于PIM的多播路由协议和多播侦听器发现（MLD）以形成组。
o A CoAP RD is connected to the network backbone.
o 同轴电缆连接到网络主干。
o The DNS server (DNS Server) is optional. If the server is there (connected to the network backbone), then certain DNS-based features are available (e.g., DNS resolution of the hostname to the IP multicast address). If the DNS server is not there, then different provisioning of the network is required (e.g., IP multicast addresses are hard-coded into devices, or manually configured, or obtained via a service discovery method).
o DNS服务器（DNS服务器）是可选的。如果服务器在那里（连接到网络主干），则某些基于DNS的功能可用（例如，主机名到IP多播地址的DNS解析）。如果DNS服务器不存在，则需要不同的网络配置（例如，IP多播地址硬编码到设备中，或手动配置，或通过服务发现方法获得）。
o A controller (CoAP client) is connected to the backbone, which is able to control various building functions including lighting.
o 一个控制器（CoAP客户端）连接到主干网，该主干网能够控制各种建筑功能，包括照明。
################################################
# ********************** Room-A #
# ** Subnet-1 ** # Network
# * ** # Backbone
# * +----------+ * # |
# * | Light |-------+ * # |
# * | Switch | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-1 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-1 |--------+ * # |
# * +----------+ * # |
# ** ** # |
# ************************** # |
# # |
# ********************** # +------------+ |
# ** Subnet-2 ** # | DNS Server | |
# * ** # | (Optional) |--+
# * +----------+ * # +------------+ |
# * | Light-2 |-------+ * # |
# * | | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-2 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-3 |--------+ * # |
# * +----------+ * # +------------+ |
# ** ** # | Controller |--+
# ************************** # | Client | |
################################################ +------------+ |
+------------+ |
| CoAP | |
| Resource |-----------------+
| Directory |
+------------+
################################################
# ********************** Room-A #
# ** Subnet-1 ** # Network
# * ** # Backbone
# * +----------+ * # |
# * | Light |-------+ * # |
# * | Switch | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-1 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-1 |--------+ * # |
# * +----------+ * # |
# ** ** # |
# ************************** # |
# # |
# ********************** # +------------+ |
# ** Subnet-2 ** # | DNS Server | |
# * ** # | (Optional) |--+
# * +----------+ * # +------------+ |
# * | Light-2 |-------+ * # |
# * | | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-2 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-3 |--------+ * # |
# * +----------+ * # +------------+ |
# ** ** # | Controller |--+
# ************************** # | Client | |
################################################ +------------+ |
+------------+ |
| CoAP | |
| Resource |-----------------+
| Directory |
+------------+
Figure 1: Network Topology of a Large Room (Room-A)
图1：大型房间（a房间）的网络拓扑
The protocol flow for discovery of the CoAP RD for the given network (of Figure 1) is shown in Figure 2:
用于发现给定网络（图1）的CoAP RD的协议流如图2所示：
o Light-2 is installed and powered on for the first time.
o Light-2已安装并首次通电。
o Light-2 will then search for the local CoAP RD by sending out a group communication GET request (with the "/.well-known/ core?rt=core.rd" request URI) to the site-local "All CoAP Nodes" multicast address (ff05:::fd).
o Light-2随后将通过向站点本地“所有CoAP节点”多播地址（ff05:：：fd）发送组通信GET请求（带有“/.well-known/core？rt=core.RD”请求URI）来搜索本地CoAP RD。
o This multicast message will then go to each node in Subnet-2. Rtr-2 will then forward it into the network backbone where it will be received by the CoAP RD. All other nodes in Subnet-2 will ignore the group communication GET request because it is qualified by the query string "?rt=core.rd" (which indicates it should only be processed by the endpoint if it contains a resource of type "core.rd").
o 然后，此多播消息将发送到子网2中的每个节点。然后，Rtr-2将其转发到网络主干网中，由CoAP RD接收。子网2中的所有其他节点将忽略组通信GET请求，因为它是由查询字符串“？rt=core.RD”限定的（这表示只有当它包含“core.RD”类型的资源时，才应由端点处理）。
o The CoAP RD will then send back a unicast response containing the requested content, which is a CoRE Link Format representation of a resource of type "core.rd".
o 然后，CoAP RD将发回包含请求内容的单播响应，该内容是“CoRE.RD”类型资源的核心链接格式表示。
o Note that the flow is shown only for Light-2 for clarity. Similar flows will happen for Light-1, Light-3, and light switch when they are first installed.
o 请注意，为清晰起见，仅针对Light-2显示流量。首次安装Light-1、Light-3和Light switch时，也会出现类似的流程。
The CoAP RD may also be discovered by other means such as by assuming a default location (e.g., on a 6LBR), using DHCP, anycast address, etc. However, these approaches do not invoke CoAP group communication so are not further discussed here. (See [CoRE-RD] for more details.)
还可以通过其他方式发现CoAP RD，例如通过使用DHCP、选播地址等假设默认位置（例如，在6LBR上）。然而，这些方法不调用CoAP组通信，因此这里不再进一步讨论。（有关更多详细信息，请参见[核心研发]。）
For other discovery use cases such as discovering local CoAP servers, services, or resources, CoAP group communication can be used in a similar fashion as in the above use case. For example, link-local, realm-local, admin-local, or site-local scoped discovery can be done this way.
对于其他发现用例，例如发现本地CoAP服务器、服务或资源，可以以与上述用例中类似的方式使用CoAP组通信。例如，链接本地、领域本地、管理本地或站点本地范围的发现可以通过这种方式完成。
Light CoAP
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD
| | | | | | |
| | | | | | |
********************************** | | |
* Light-2 is installed * | | |
* and powers on for first time * | | |
********************************** | | |
| | | | | | |
| | | | | | |
| | COAP NON Mcast(GET | |
| | /.well-known/core?rt=core.rd) | |
| |--------->-------------------------------->| |
| | | | | |--------->|
| | | | | | |
| | | | | | |
| | COAP NON (2.05 Content | |
| | </rd>;rt="core.rd";ins="Primary") |<---------|
| |<------------------------------------------| |
| | | | | | |
Light CoAP
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD
| | | | | | |
| | | | | | |
********************************** | | |
* Light-2 is installed * | | |
* and powers on for first time * | | |
********************************** | | |
| | | | | | |
| | | | | | |
| | COAP NON Mcast(GET | |
| | /.well-known/core?rt=core.rd) | |
| |--------->-------------------------------->| |
| | | | | |--------->|
| | | | | | |
| | | | | | |
| | COAP NON (2.05 Content | |
| | </rd>;rt="core.rd";ins="Primary") |<---------|
| |<------------------------------------------| |
| | | | | | |
Figure 2: Resource Directory Discovery via Multicast Request
图2：通过多播请求发现资源目录
The protocol flow for a building automation lighting control scenario for the network (Figure 1) is shown in Figure 3. The network is assumed to be in a 6LoWPAN configuration. Also, it is assumed that the CoAP servers in each light are configured to suppress CoAP responses for any IP multicast CoAP requests related to lighting control. (See Section 2.7 for more details on response suppression by a server.)
网络楼宇自动化照明控制场景的协议流程（图1）如图3所示。假设该网络处于6LoWPAN配置中。此外，假设每个灯中的CoAP服务器被配置为抑制与照明控制相关的任何IP多播CoAP请求的CoAP响应。（有关服务器响应抑制的更多详细信息，请参见第2.7节。）
In addition, Figure 4 shows a protocol flow example for the case that servers do respond to a lighting control IP multicast request with (unicast) CoAP NON responses. There are two success responses and one 5.00 error response. In this particular case, the light switch does not check that all lights in the group received the IP multicast request by examining the responses. This is because the light switch is not configured with an exhaustive list of the IP addresses of all lights belonging to the group. However, based on received error responses, it could take additional action such as logging a fault or alerting the user via its LCD display. In case a CoAP message is delivered multiple times to a light, the subsequent CoAP messages can be filtered out as duplicates, based on the CoAP Message ID.
此外，图4显示了服务器使用（单播）CoAP非响应响应照明控制IP多播请求的情况下的协议流示例。有两个成功响应和一个5.00错误响应。在此特定情况下，灯光开关不会通过检查响应来检查组中的所有灯光是否接收到IP多播请求。这是因为照明开关未配置属于该组的所有照明的IP地址的详尽列表。但是，根据收到的错误响应，它可以采取其他措施，如记录故障或通过其LCD显示屏提醒用户。如果CoAP消息多次发送到灯，则可以根据CoAP消息ID将后续CoAP消息作为重复消息过滤掉。
Reliability of IP multicast is not guaranteed. Therefore, one or more lights in the group may not have received the CoAP control request due to packet loss. In this use case, there is no detection nor correction of such situations: the application layer expects that the IP multicast forwarding/routing will be of sufficient quality to provide on average a very high probability of packet delivery to all CoAP endpoints in an IP multicast group. An example protocol to accomplish this using randomized retransmission is the MPL forwarding protocol for LLNs [MCAST-MPL].
IP多播的可靠性无法保证。因此，由于分组丢失，组中的一个或多个灯可能没有收到CoAP控制请求。在这种情况下，不会检测或纠正这种情况：应用层期望IP多播转发/路由将具有足够的质量，以向IP多播组中的所有CoAP端点平均提供非常高的分组交付概率。使用随机重传实现这一点的一个示例协议是LLN的MPL转发协议[MCAST-MPL]。
We assume the following steps have already occurred before the illustrated flows:
我们假设在演示流程之前已经发生了以下步骤：
1) Startup phase: 6LoWPANs are formed. IPv6 addresses are assigned to all devices. The CoAP network is formed.
1) 启动阶段：形成6个焊盘。IPv6地址分配给所有设备。形成了CoAP网络。
2) Network configuration (application independent): 6LBRs are configured with IP multicast addresses, or address blocks, to filter out or to pass through to/from the 6LoWPAN.
2) 网络配置（独立于应用程序）：6LBR配置有IP多播地址或地址块，用于过滤或通过6LoWPAN。
3a) Commissioning phase (application related): The IP multicast address of the group (Room-A-Lights) has been configured in all the lights and in the light switch.
3a）调试阶段（与应用相关）：已在所有灯和灯开关中配置组（Room-A-Lights）的IP多播地址。
3b) As an alternative to the previous step, when a DNS server is available, the light switch and/or the lights have been configured with a group hostname that each node resolves to the above IP multicast address of the group.
3b）作为上一步的替代方案，当DNS服务器可用时，灯开关和/或灯已配置有组主机名，每个节点解析为组的上述IP多播地址。
Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software stack supports sending unicast, multicast, or proxied unicast CoAP requests, including processing of the multiple responses that may be generated by an IP multicast CoAP request.
调试阶段注意：交换机的6LoWPAN/CoAP软件堆栈支持发送单播、多播或代理单播CoAP请求，包括处理IP多播CoAP请求生成的多个响应。
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | *********************** | |
| | * User flips on * | |
| | * light switch to * | |
| | * turn on all the * | |
| | * lights in Room-A * | |
| | *********************** | |
| | | | | | |
| | | | | | |
| | | COAP NON Mcast(PUT, | |
| | | Payload=lights ON) | |
|<-------------------------------+--------->| | |
ON | | | |-------------------->|
| | | | | |<---------|
| |<---------|<-------------------------------| |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | *********************** | |
| | * User flips on * | |
| | * light switch to * | |
| | * turn on all the * | |
| | * lights in Room-A * | |
| | *********************** | |
| | | | | | |
| | | | | | |
| | | COAP NON Mcast(PUT, | |
| | | Payload=lights ON) | |
|<-------------------------------+--------->| | |
ON | | | |-------------------->|
| | | | | |<---------|
| |<---------|<-------------------------------| |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
Figure 3: Light Switch Sends Multicast Control Message
图3：灯光开关发送多播控制消息
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|------------------------------->| | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | |
| |------------------------------------------>| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
| | COAP NON (5.00 Internal Server Error) |
| | |------------------------------->| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|------------------------------->| | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | |
| |------------------------------------------>| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
| | COAP NON (5.00 Internal Server Error) |
| | |------------------------------->| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
Figure 4: Lights (Optionally) Respond to Multicast CoAP Request
图4:Lights（可选）响应多播CoAP请求
Another, but similar, lighting control use case is shown in Figure 5. In this case, a controller connected to the network backbone sends a CoAP group communication request to turn on all lights in Room-A. Every light sends back a CoAP response to the controller after being turned on.
另一个类似的照明控制用例如图5所示。在这种情况下，连接到网络主干的控制器发送CoAP组通信请求以打开房间a中的所有灯。每个灯在打开后都向控制器发送CoAP响应。
Network
Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller
| | | | | | |
| | | | | COAP NON Mcast(PUT,
| | | | | Payload=lights ON)
| | | | | |<-------|
| | | |<----------<---------| |
|<--------------------------------| | | |
ON | | | | | |
| |<----------<---------------------| | |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|-------------------------------->| | | |
| | | |-------------------->| |
| | COAP NON (2.04 Changed) | |------->|
| |-------------------------------->| | |
| | | | |--------->| |
| | | COAP NON (2.04 Changed) |------->|
| | |--------------------->| | |
| | | | |--------->| |
| | | | | |------->|
| | | | | | |
Network
Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller
| | | | | | |
| | | | | COAP NON Mcast(PUT,
| | | | | Payload=lights ON)
| | | | | |<-------|
| | | |<----------<---------| |
|<--------------------------------| | | |
ON | | | | | |
| |<----------<---------------------| | |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|-------------------------------->| | | |
| | | |-------------------->| |
| | COAP NON (2.04 Changed) | |------->|
| |-------------------------------->| | |
| | | | |--------->| |
| | | COAP NON (2.04 Changed) |------->|
| | |--------------------->| | |
| | | | |--------->| |
| | | | | |------->|
| | | | | | |
Figure 5: Controller on Backbone Sends Multicast Control Message
图5：主干上的控制器发送多播控制消息
The use case in the previous section can also apply in networks where nodes support the MLD protocol [RFC3810]. The lights then take on the role of MLDv2 listener, and the routers (Rtr-1 and Rtr-2) are MLDv2 routers. In the Ethernet-based network configuration, MLD may be available on all involved network interfaces. Use of MLD in the 6LoWPAN-based configuration is also possible but requires MLD support in all nodes in the 6LoWPAN. In current 6LoWPAN implementations, MLD is, however, not supported.
上一节中的用例也适用于节点支持MLD协议[RFC3810]的网络。然后，这些灯扮演MLDv2侦听器的角色，路由器（Rtr-1和Rtr-2）就是MLDv2路由器。在基于以太网的网络配置中，MLD可在所有相关网络接口上使用。也可以在基于6LoWPAN的配置中使用MLD，但需要6LoWPAN中所有节点的MLD支持。但是，在当前6LoWPAN实现中，不支持MLD。
The resulting protocol flow is shown in Figure 6. This flow is executed after the commissioning phase, as soon as lights are configured with a group address to listen to. The (unicast) MLD
产生的协议流如图6所示。该流程在调试阶段之后执行，只要灯光配置了要侦听的组地址。（单播）MLD
Reports may require periodic refresh activity as specified by the MLD protocol. In the figure, 'LL' denotes link-local communication.
报告可能需要MLD协议规定的定期刷新活动。在图中，“LL”表示链路本地通信。
After the shown sequence of MLD Report messages has been executed, both Rtr-1 and Rtr-2 are automatically configured to forward IP multicast traffic destined to Room-A-Lights onto their connected subnet. Hence, no manual network configuration of routers, as previously indicated in Section 3.4, step 2, is needed anymore.
执行所示的MLD报告消息序列后，Rtr-1和Rtr-2自动配置为将目的地为Room-A-Lights的IP多播流量转发到其连接的子网。因此，不再需要第3.4节第2步中所述的路由器的手动网络配置。
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | | | | | |
| MLD Report: Join | | | | |
| Group (Room-A-Lights) | | | |
|---LL------------------------------------->| | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |---LL---->----LL---->|
| | | | | | |
| | MLD Report: Join | | | |
| | Group (Room-A-Lights) | | |
| |---LL------------------------------------->| |
| | | | | | |
| | | MLD Report: Join | | |
| | | Group (Room-A-Lights) | |
| | |---LL-------------------------->| |
| | | | | | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |<--LL-----+---LL---->|
| | | | | | |
| | | | | | |
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | | | | | |
| MLD Report: Join | | | | |
| Group (Room-A-Lights) | | | |
|---LL------------------------------------->| | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |---LL---->----LL---->|
| | | | | | |
| | MLD Report: Join | | | |
| | Group (Room-A-Lights) | | |
| |---LL------------------------------------->| |
| | | | | | |
| | | MLD Report: Join | | |
| | | Group (Room-A-Lights) | |
| | |---LL-------------------------->| |
| | | | | | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |<--LL-----+---LL---->|
| | | | | | |
| | | | | | |
Figure 6: Joining Lighting Groups Using MLD
图6：使用MLD连接照明组
This section outlines how devices in the lighting use case (both switches and lights) can be commissioned, making use of the RD [CoRE-RD] and its group configuration feature.
本节概述如何使用RD[核心RD]及其组配置功能调试照明用例中的设备（开关和灯）。
Once the RD is discovered, the Switches and lights need to be discovered and their groups need to be defined. For the commissioning of these devices, a commissioning tool can be used that
一旦发现RD，就需要发现开关和灯，并定义它们的组。对于这些设备的调试，可以使用调试工具
defines the entries in the RD. The commissioning tool has the authority to change the contents of the RD and the light/switch nodes. DTLS-based unicast security is used by the commissioning tool to modify operational data in RD, switches, and lights.
定义RD中的条目。调试工具有权更改RD和灯光/开关节点的内容。调试工具使用基于DTLS的单播安全性修改RD、交换机和灯光中的操作数据。
In our particular use case, a group of three lights is defined with one IP multicast address and hostname:
在我们的特定用例中，使用一个IP多播地址和主机名定义了一组三盏灯：
"Room-A-Lights.floor1.west.bldg6.example.com"
“Room-A-Lights.floor1.west.bldg6.example.com”
The commissioning tool has a list of the three lights and the associated IP multicast address. For each light in the list, the tool learns the IP address of the light and instructs the RD with three (unicast) POST commands to store the endpoints associated with the three lights as prescribed by the RD specification [CoRE-RD]. Finally, the commissioning tool defines the group in the RD to contain these three endpoints. Also the commissioning tool writes the IP multicast address in the light endpoints with, for example, the (unicast) POST command discussed in Section 2.6.2.2.
调试工具具有三个指示灯和相关IP多播地址的列表。对于列表中的每个灯光，该工具学习灯光的IP地址，并使用三个（单播）POST命令指示RD存储与RD规范[CoRE RD]规定的三个灯光相关联的端点。最后，调试工具在RD中定义包含这三个端点的组。此外，调试工具还使用第2.6.2.2节中讨论的（单播）POST命令将IP多播地址写入light端点。
The light switch can discover the group in RD and thus learn the IP multicast address of the group. The light switch will use this address to send CoAP group communication requests to the members of the group. When the message arrives, the lights should recognize the IP multicast address and accept the message.
光开关可以在RD中发现组，从而了解组的IP多播地址。灯开关将使用此地址向组成员发送CoAP组通信请求。当消息到达时，指示灯应识别IP多播地址并接受消息。
This section provides guidelines on how IP multicast-based CoAP group communication can be deployed in various network configurations.
本节提供了有关如何在各种网络配置中部署基于IP多播的CoAP组通信的指南。
CoAP group communication can be deployed in various network topologies. First, the target network may be a traditional IP network, or an LLN such as a 6LoWPAN network, or consist of mixed traditional/constrained network segments. Second, it may be a single subnet only or a multi-subnet, e.g., multiple 6LoWPAN networks joined by a single backbone LAN. Third, a wireless network segment may have all its nodes reachable in a single IP hop (fully connected), or it may require multiple IP hops for some pairs of nodes to reach each other.
CoAP组通信可以部署在各种网络拓扑中。首先，目标网络可以是传统IP网络，或者LLN，例如6LoWPAN网络，或者由混合的传统/受限网段组成。其次，它可以是单子网或多子网，例如，由单个主干LAN连接的多个6LoWPAN网络。第三，一个无线网段的所有节点都可以在一个IP跃点（完全连接）中到达，或者它可能需要多个IP跃点才能让一些节点对彼此到达。
Each topology may pose different requirements on the configuration of routers and protocol(s), in order to enable efficient CoAP group communication. To enable all the above target network topologies, an implementation of CoAP group communication needs to allow the following:
为了实现有效的CoAP组通信，每个拓扑可能对路由器和协议的配置提出不同的要求。要启用上述所有目标网络拓扑，CoAP组通信的实现需要允许以下内容：
1. Routing/forwarding of IP multicast packets over multiple hops.
1. 通过多跳路由/转发IP多播数据包。
2. Routing/forwarding of IP multicast packets over subnet boundaries between traditional and constrained (e.g., LLN) networks.
2. 在传统和受限（如LLN）网络之间的子网边界上路由/转发IP多播数据包。
The remainder of this section discusses solutions to enable both features.
本节的其余部分将讨论启用这两个功能的解决方案。
CoAP nodes that are IP hosts (i.e., not IP routers) are generally unaware of the specific IP multicast routing/forwarding protocol being used. When such a host needs to join a specific (CoAP) multicast group, it requires a way to signal to IP multicast routers which IP multicast traffic it wants to receive.
作为IP主机（即，非IP路由器）的CoAP节点通常不知道正在使用的特定IP多播路由/转发协议。当这样一个主机需要加入一个特定的（CoAP）多播组时，它需要一种向IP多播路由器发送信号的方式，告知它想要接收哪个IP多播流量。
The MLD protocol [RFC3810] (see Appendix A of this document) is the standard IPv6 method to achieve this; therefore, this approach should be used on traditional IP networks. CoAP server nodes would then act in the role of MLD Multicast Address Listener.
MLD协议[RFC3810]（见本文件附录A）是实现这一目标的标准IPv6方法；因此，这种方法应该在传统的IP网络上使用。然后，CoAP服务器节点将扮演MLD多播地址侦听器的角色。
The guidelines from [RFC6636] on the tuning of MLD for mobile and wireless networks may be useful when implementing MLD in LLNs. However, on LLNs and 6LoWPAN networks, the use of MLD may not be feasible at all due to constraints on code size, memory, or network capacity.
[RFC6636]中关于移动和无线网络MLD调谐的指南在LLN中实施MLD时可能有用。然而，在LLN和6LoWPAN网络上，由于代码大小、内存或网络容量的限制，MLD的使用可能根本不可行。
It is assumed in this section that the MLD protocol is not implemented in a network, for example, due to resource constraints. The RPL routing protocol (see Section 12 of [RFC6550]) defines the advertisement of IP multicast destinations using Destination Advertisement Object (DAO) messages and routing of multicast IPv6 packets based on this. It requires the RPL mode of operation to be 3 (Storing mode with multicast support).
在本节中，假设例如由于资源限制，MLD协议未在网络中实现。RPL路由协议（见[RFC6550]第12节）使用目的地公布对象（DAO）消息定义IP多播目的地的公布，并基于此定义多播IPv6数据包的路由。它要求RPL操作模式为3（支持多播的存储模式）。
Hence, RPL DAO can be used by CoAP nodes that are RPL routers, or are RPL Leaf Nodes, to advertise IP multicast group membership to parent routers. Then, RPL is used to route IP multicast CoAP requests over multiple hops to the correct CoAP servers.
因此，RPL DAO可由作为RPL路由器或RPL叶节点的CoAP节点用于向父路由器公布IP多播组成员资格。然后，RPL用于通过多个跃点将IP多播CoAP请求路由到正确的CoAP服务器。
The same DAO mechanism can be used to convey IP multicast group membership information to an edge router (e.g., 6LBR), in case the edge router is also the root of the RPL Destination-Oriented Directed Acyclic Graph (DODAG). This is useful because the edge router then learns which IP multicast traffic it needs to pass through from the backbone network into the LLN subnet. In 6LoWPAN networks, such
如果边缘路由器也是面向RPL目的地的有向无环图（DODAG）的根，则可以使用相同的DAO机制将IP多播组成员信息传送到边缘路由器（例如，6LBR）。这是很有用的，因为边缘路由器随后会了解它需要通过哪些IP多播流量从主干网进入LLN子网。在6LoWPAN网络中，例如
selective "filtering" helps to avoid congestion of a 6LoWPAN subnet by IP multicast traffic from the traditional backbone IP network.
选择性“过滤”有助于避免传统骨干IP网络的IP多播流量造成6LoWPAN子网拥塞。
The MPL forwarding protocol [MCAST-MPL] can be used for propagation of IPv6 multicast packets to all MPL Forwarders within a predefined network domain, over multiple hops. MPL is designed to work in LLNs. In this section, it is again assumed that MLD is not implemented in the network, for example, due to resource limitations in an LLN.
MPL转发协议[MCAST-MPL]可用于通过多跳将IPv6多播数据包传播到预定义网络域内的所有MPL转发器。MPL设计用于LLN。在本节中，再次假设例如由于LLN中的资源限制，MLD未在网络中实现。
The purpose of MPL is to let a predefined group of Forwarders collectively work towards the goal of distributing an IPv6 multicast packet throughout an MPL Domain. (A Forwarder node may be associated to multiple MPL Domains at the same time.) So, it would appear that there is no need for CoAP servers to advertise their multicast group membership, since any IP multicast packet that enters the MPL Domain is distributed to all MPL Forwarders without regard to what multicast addresses the individual nodes are listening to.
MPL的目的是让一组预定义的转发器共同工作，以实现在整个MPL域中分发IPv6多播数据包的目标。（转发器节点可能同时关联到多个MPL域。）因此，CoAP服务器似乎不需要公布其多播组成员身份，因为任何进入MPL域的IP多播数据包都被分发给所有MPL转发器，而不考虑各个节点正在侦听的多播地址。
However, if an IP multicast request originates just outside the MPL Domain, the request will not be propagated by MPL. An example of such a case is the network topology of Figure 1 where the subnets are 6LoWPAN subnets and for each 6LoWPAN subnet, one Realm-Local ([RFC7346]) MPL Domain is defined. The backbone network in this case is not part of any MPL Domain.
但是，如果IP多播请求是在MPL域之外发起的，则MPL不会传播该请求。这种情况的一个例子是图1的网络拓扑，其中子网是6LoWPAN子网，对于每个6LoWPAN子网，定义了一个域本地（[RFC7346]）MPL域。在这种情况下，主干网不是任何MPL域的一部分。
This situation can become a problem in building control use cases, for example, when the controller client needs to send a single IP multicast request to the group Room-A-Lights. By default, the request would be blocked by Rtr-1 and by Rtr-2 and not enter the Realm-Local MPL Domains associated to Subnet-1 and Subnet-2. The reason is that Rtr-1 and Rtr-2 do not have the knowledge that devices in Subnet-1/2 want to listen for IP packets destined to IP multicast group Room-A-Lights.
这种情况可能成为构建控制用例的问题，例如，当控制器客户端需要向组Room-a-Lights发送单个IP多播请求时。默认情况下，请求将被Rtr-1和Rtr-2阻止，并且不会进入与子网1和子网2关联的领域本地MPL域。原因是Rtr-1和Rtr-2不知道子网1/2中的设备想要侦听发往IP多播组Room-A-Lights的IP数据包。
To solve the above issue, the following solutions could be applied:
为解决上述问题，可采用以下解决方案：
1. Extend the MPL Domain, e.g., in the above example, include the network backbone to be part of each of the two MPL Domains. Or, in the above example, create just a single MPL Domain that includes both 6LoWPAN subnets plus the backbone link, which is possible since MPL is not tied to a single link-layer technology.
1. 扩展MPL域，例如，在上述示例中，包括作为两个MPL域中的每一个的一部分的网络主干。或者，在上面的示例中，只创建一个包含6LoWPAN子网和主干链路的MPL域，这是可能的，因为MPL不绑定到单个链路层技术。
2. Manual configuration of an edge router(s) as an MPL Seed(s) for specific IP multicast traffic. In the above example, this could be done through the following three steps: First, configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights
2. 将边缘路由器手动配置为特定IP多播流量的MPL种子。在上面的示例中，这可以通过以下三个步骤完成：首先，配置Rtr-1和Rtr-2作为Room-A-Lights的MLD地址侦听器
IP multicast group. This step allows any (other) routers on the backbone to learn that at least one node on the backbone link is interested in receiving any IP multicast traffic to Room-A-Lights. Second, configure both routers to "inject" any IP multicast packets destined to group Room-A-Lights into the (Realm-Local) MPL Domain that is associated to that router. Third, configure both routers to propagate any IPv6 multicast packets originating from within their associated MPL Domain to the backbone, if at least one node on the backbone has indicated interest in receiving such IPv6 packets (for which MLD is used on the backbone).
IP多播组。此步骤允许主干上的任何（其他）路由器了解主干链路上至少有一个节点有兴趣接收到Room-A-Lights的任何IP多播流量。其次，将两个路由器配置为“注入”任何目的地为分组房间A-Lights的IP多播数据包到与该路由器关联的（领域本地）MPL域中。第三，如果主干上至少有一个节点表示有兴趣接收此类IPv6数据包（主干上使用MLD），则将两个路由器配置为将源自其相关MPL域内的任何IPv6多播数据包传播到主干。
3. Use an additional protocol/mechanism for injection of IP multicast traffic from outside an MPL Domain into that MPL Domain, based on IP multicast group subscriptions of Forwarders within the MPL Domain. Such a protocol is currently not defined in [MCAST-MPL].
3. 基于MPL域内转发器的IP多播组订阅，使用附加协议/机制将IP多播流量从MPL域外部注入该MPL域。[MCAST-MPL]中目前未定义此类协议。
In conclusion, MPL can be used directly in case all sources of IP multicast CoAP requests (CoAP clients) and also all the destinations (CoAP servers) are inside a single MPL Domain. Then, each source node acts as an MPL Seed. In all other cases, MPL can only be used with additional protocols and/or configuration on how IP multicast packets can be injected from outside into an MPL Domain.
总之，如果IP多播CoAP请求的所有源（CoAP客户端）以及所有目的地（CoAP服务器）都位于单个MPL域内，则可以直接使用MPL。然后，每个源节点充当MPL种子。在所有其他情况下，MPL只能与其他协议和/或配置一起使用，这些协议和/或配置涉及如何将IP多播数据包从外部注入MPL域。
To support multi-subnet scenarios for CoAP group communication, it is recommended that a 6LBR will act in an MLD router role on the backbone link. If this is not possible, then the 6LBR should be configured to act as an MLD Multicast Address Listener (see Appendix A) on the backbone link.
为了支持CoAP组通信的多子网方案，建议6LBR在主干链路上扮演MLD路由器角色。如果不可能，则应将6LBR配置为充当主干链路上的MLD多播地址侦听器（参见附录A）。
This section describes the relevant security configuration for CoAP group communication using IP multicast. The threats to CoAP group communication are also identified, and various approaches to mitigate these threats are summarized.
本节介绍使用IP多播的CoAP组通信的相关安全配置。还确定了对CoAP组通信的威胁，并总结了缓解这些威胁的各种方法。
As defined in Sections 8.1 and 9.1 of [RFC7252], CoAP group communication based on IP multicast will do the following:
如[RFC7252]第8.1节和第9.1节所述，基于IP多播的CoAP组通信将执行以下操作：
o Operate in CoAP NoSec (No Security) mode, until a future group security solution is developed (see also Section 5.3.3).
o 在CoAP NoSec（无安全）模式下运行，直到开发出未来的集团安全解决方案（另见第5.3.3节）。
o Use the "coap" scheme. The "coaps" scheme should only be used when a future group security solution is developed (see also Section 5.3.3).
o 使用“coap”方案。只有在开发未来的集团安全解决方案时，才应使用“coaps”方案（另请参见第5.3.3节）。
Essentially, the above configuration means that there is currently no security at the CoAP layer for group communication. Therefore, for sensitive and mission-critical applications (e.g., health monitoring systems and alarm monitoring systems), it is currently recommended to deploy CoAP group communication with an application-layer security mechanism (e.g., data object security) for improved security.
本质上，上述配置意味着当前在CoAP层没有用于组通信的安全性。因此，对于敏感和任务关键型应用程序（例如，健康监测系统和报警监测系统），目前建议使用应用层安全机制（例如，数据对象安全性）部署CoAP组通信，以提高安全性。
Application-level security has many desirable properties, including maintaining security properties while forwarding traffic through intermediaries (proxies). Application-level security also tends to more cleanly separate security from the dynamics of group membership (e.g., the problem of distributing security keys across large groups with many members that come and go).
应用程序级安全性有许多可取的属性，包括在通过中介（代理）转发流量时维护安全属性。应用程序级安全性还倾向于更清晰地将安全性与组成员身份的动态性分开（例如，在有许多成员来来往往的大型组之间分配安全密钥的问题）。
Without application-layer security, CoAP group communication should only be currently deployed in non-critical applications (e.g., read-only temperature sensors). Only when security solutions at the CoAP layer are mature enough (see Section 5.3.3) should CoAP group communication without application-layer security be considered for sensitive and mission-critical applications.
如果没有应用层安全性，CoAP组通信当前只能部署在非关键应用中（例如，只读温度传感器）。只有当CoAP层的安全解决方案足够成熟（见第5.3.3节）时，才应考虑敏感和任务关键型应用程序的无应用层安全的CoAP组通信。
As noted above, there is currently no security at the CoAP layer for group communication. This is due to the fact that the current DTLS-based approach for CoAP is exclusively unicast oriented and does not support group security features such as group key exchange and group authentication. As a direct consequence of this, CoAP group communication is vulnerable to all attacks mentioned in Section 11 of [RFC7252] for IP multicast.
如上所述，目前CoAP层没有用于组通信的安全性。这是因为当前基于DTLS的CoAP方法完全面向单播，不支持组密钥交换和组身份验证等组安全功能。因此，CoAP组通信容易受到[RFC7252]第11节中提到的IP多播攻击。
Section 11 of [RFC7252] identifies various threat mitigation techniques for CoAP group communication. In addition to those guidelines, it is recommended that for sensitive data or safety-critical control, a combination of appropriate link-layer security and administrative control of IP multicast boundaries should be used. Some examples are given below.
[RFC7252]第11节确定了CoAP组通信的各种威胁缓解技术。除了这些指南之外，建议对于敏感数据或安全关键控制，应结合使用适当的链路层安全和IP多播边界的管理控制。下面给出一些例子。
In a home automation scenario (using WiFi), the WiFi encryption should be enabled to prevent rogue nodes from joining. The Customer Premises Equipment (CPE) that enables access to the Internet should also have its IP multicast filters set so that it enforces multicast scope boundaries to isolate local multicast groups from the rest of the Internet (e.g., as per [RFC6092]). In addition, the scope of the IP multicast should be set to be site-local or smaller scope. For site-local scope, the CPE will be an appropriate multicast scope boundary point.
在家庭自动化场景中（使用WiFi），应启用WiFi加密以防止恶意节点加入。能够访问互联网的客户场所设备（CPE）还应设置其IP多播过滤器，以便强制多播范围边界，将本地多播组与互联网的其余部分隔离（例如，根据[RFC6092]）。此外，IP多播的作用域应设置为站点本地或更小的作用域。对于站点本地范围，CPE将是适当的多播范围边界点。
In a building automation scenario, a particular room may have a single 6LoWPAN network with a single edge router (6LBR). Nodes on the subnet can use link-layer encryption to prevent rogue nodes from joining. The 6LBR can be configured so that it blocks any incoming (6LoWPAN-bound) IP multicast traffic. Another example topology could be a multi-subnet 6LoWPAN in a large conference room. In this case, the backbone can implement port authentication (IEEE 802.1X) to ensure only authorized devices can join the Ethernet backbone. The access router to this secured network segment can also be configured to block incoming IP multicast traffic.
在楼宇自动化场景中，特定房间可能有一个带单边缘路由器（6LBR）的6LoWPAN网络。子网上的节点可以使用链路层加密来防止恶意节点加入。6LBR可以配置为阻止任何传入（6LoWPAN绑定）IP多播通信。另一个示例拓扑可能是大型会议室中的多子网6LoWPAN。在这种情况下，主干网可以实现端口身份验证（IEEE 802.1X），以确保只有经过授权的设备才能加入以太网主干网。该安全网段的接入路由器也可以配置为阻止传入的IP多播通信。
In the future, to further mitigate the threats, security enhancements need to be developed at the IETF for group communications. This will allow introduction of a secure mode of CoAP group communication and use of the "coaps" scheme for that purpose.
未来，为了进一步缓解这些威胁，需要在IETF上为组通信开发安全增强功能。这将允许引入CoAP组通信的安全模式，并为此目的使用“CoAP”方案。
At the time of writing this specification, there are various approaches being considered for security enhancements for group communications. Specifically, a lot of the current effort at the IETF is geared towards developing DTLS-based group communication. This is primarily motivated by the fact that unicast CoAP security is DTLS based (Section 9.1 of [RFC7252]. For example, [MCAST-SECURITY] proposes DTLS-based IP multicast security. However, it is too early to conclude if this is the best approach. Alternatively, [IPSEC-PAYLOAD] proposes IPsec-based IP multicast security. This approach also needs further investigation and validation.
在编写本规范时，正在考虑各种方法来增强组通信的安全性。具体来说，IETF当前的许多工作都是为了开发基于DTLS的组通信。这主要是因为单播CoAP安全性基于DTLS（RFC7252的第9.1节）。例如，[MCAST-security]提出了基于DTLS的IP多播安全性。但是，现在断定这是否是最佳方法还为时过早。或者，[IPSEC-PAYLOAD]提出了基于IPsec的IP组播安全方案，该方案还需要进一步的研究和验证。
CoAP group communication is meant to be used to control a set of related devices (e.g., simultaneously turn on all the lights in a room). This intrinsically exposes the group to some unique monitoring risks that solitary devices (i.e., devices not in a group) are not as vulnerable to. For example, assume an attacker is able to physically see a set of lights turn on in a room. Then the attacker can correlate a CoAP group communication message to that easily observable coordinated group action even if the contents of the message are encrypted by a future security solution (see Section 5.3.3). This will give the attacker side-channel information to plan further attacks (e.g., by determining the members of the group, then some network topology information may be deduced).
CoAP组通信用于控制一组相关设备（例如，同时打开房间中的所有灯）。这本质上使集团面临一些独特的监控风险，这些风险是单独的设备（即，不在集团内的设备）不易受到的。例如，假设攻击者能够看到房间中的一组灯亮起。然后，即使消息内容由未来的安全解决方案加密，攻击者也可以将CoAP组通信消息与易于观察到的协调组操作关联起来（参见第5.3.3节）。这将为攻击者提供计划进一步攻击的侧通道信息（例如，通过确定组成员，可以推断出一些网络拓扑信息）。
One mitigation to group communication monitoring risks that should be explored in the future is methods to decorrelate coordinated group actions. For example, if a CoAP group communication GET is sent to all the alarm sensors in a house, then their (unicast) responses should be as decorrelated as possible. This will introduce greater entropy into the system and will make it harder for an attacker to monitor and gather side-channel information.
未来应探讨的一种缓解集团沟通监控风险的方法是消除协调集团行动的相关性。例如，如果将CoAP组通信GET发送到房屋中的所有报警传感器，则它们的（单播）响应应尽可能不相关。这将在系统中引入更大的熵，使攻击者更难监视和收集旁道信息。
A key additional threat consideration for group communication is pointed to by [RFC7258], which warns of the dangers of pervasive monitoring. CoAP group communication solutions that are built on top of IP multicast need to pay particular heed to these dangers. This is because IP multicast is easier to intercept (e.g., and to secretly record) compared to unicast traffic. Also, CoAP traffic is meant for the Internet of Things. This means that CoAP traffic (once future security solutions are developed as in Section 5.3.3) may be used for the control and monitoring of critical infrastructure (e.g., lights, alarms, etc.) that may be prime targets for attack.
[RFC7258]指出了群组通信的另一个关键威胁因素，它警告了普遍监控的危险。建立在IP多播之上的CoAP组通信解决方案需要特别注意这些危险。这是因为与单播流量相比，IP多播更容易拦截（例如，和秘密记录）。此外，CoAP流量也适用于物联网。这意味着CoAP流量（一旦按照第5.3.3节开发了未来的安全解决方案）可用于控制和监控可能成为主要攻击目标的关键基础设施（如灯光、警报等）。
For example, an attacker may attempt to record all the CoAP traffic going over the smart grid (i.e., networked electrical utility) of a country and try to determine critical nodes for further attacks. For example, the source node (controller) sends out the CoAP group communication messages. CoAP multicast traffic is inherently more vulnerable (compared to a unicast packet) as the same packet may be replicated over many links, so there is a much higher probability of it getting captured by a pervasive monitoring system.
例如，攻击者可能试图记录通过一个国家的智能电网（即联网电力设施）的所有CoAP流量，并试图确定进一步攻击的关键节点。例如，源节点（控制器）发送CoAP组通信消息。CoAP多播流量本质上更容易受到攻击（与单播数据包相比），因为同一数据包可能会在多个链路上复制，因此它被普及监控系统捕获的概率更高。
One useful mitigation to pervasive monitoring is to restrict the scope of the IP multicast to the minimal scope that fulfills the application need. Thus, for example, site-local IP multicast scope is always preferred over global scope IP multicast if this fulfills the application needs. This approach has the added advantage that it coincides with the guidelines for minimizing congestion control (see Section 2.8).
普及监控的一个有用的缓解措施是将IP多播的范围限制在满足应用程序需求的最小范围内。因此，例如，如果满足应用程序的需要，则站点本地IP多播范围始终优于全局范围IP多播。这种方法还有一个额外的优点，即它符合最小化拥塞控制的指南（见第2.8节）。
In the future, even if all the CoAP multicast traffic is encrypted, an attacker may still attempt to capture the traffic and perform an off-line attack, though of course having the multicast traffic protected is always desirable as it significantly raises the cost to an attacker (e.g., to break the encryption) versus unprotected multicast traffic.
在未来，即使所有CoAP多播通信量都已加密，攻击者仍可能试图捕获通信量并执行离线攻击，当然，保护多播通信量始终是可取的，因为与未保护的多播通信量相比，这会显著增加攻击者的成本（例如，破坏加密）。
This memo registers a new Resource Type (rt=) Link Target Attribute, 'core.gp', in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
此备忘录在“受限RESTful环境（core）参数”注册表下的“资源类型（rt=）链接目标属性值”子注册表中注册新的资源类型（rt=）链接目标属性“core.gp”。
Attribute Value: core.gp
属性值：core.gp
Description: Group Configuration resource. This resource is used to query/manage the group membership of a CoAP server.
描述：组配置资源。此资源用于查询/管理CoAP服务器的组成员资格。
Reference: See Section 2.6.2.
参考：见第2.6.2节。
This memo registers a new Internet media type for the CoAP Group Configuration resource called 'application/coap-group+json'.
此备忘录为CoAP组配置资源注册了一个名为“应用程序/CoAP组+json”的新Internet媒体类型。
Type name: application
类型名称：应用程序
Subtype name: coap-group+json
子类型名称：coap组+json
Required parameters: None
所需参数：无
Optional parameters: None
可选参数：无
Encoding considerations: 8-bit UTF-8.
编码注意事项：8位UTF-8。
JSON to be represented using UTF-8, which is 8-bit compatible (and most efficient for resource constrained implementations).
JSON将使用UTF-8表示，UTF-8是8位兼容的（对于资源受限的实现来说效率最高）。
Security considerations:
安全考虑：
Denial-of-Service attacks could be performed by constantly (re-)setting the Group Configuration resource of a CoAP endpoint to different values. This will cause the endpoint to register (or deregister) from the related IP multicast group. To prevent this, it is recommended that a form of authorization (making use of unicast DTLS-secured CoAP) be used such that only authorized controllers are allowed by an endpoint to configure its group membership.
通过不断（重新）将CoAP端点的组配置资源设置为不同的值，可以执行拒绝服务攻击。这将导致端点从相关IP多播组注册（或取消注册）。为了防止出现这种情况，建议使用一种授权形式（利用单播DTLS安全CoAP），以便端点只允许授权控制器配置其组成员身份。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 7390
已发布规范：RFC 7390
Applications that use this media type:
使用此媒体类型的应用程序：
CoAP client and server implementations that wish to set/read the Group Configuration resource via the 'application/coap-group+json' payload as described in Section 2.6.2.
希望通过“应用程序/CoAP组+json”有效负载设置/读取组配置资源的CoAP客户端和服务器实现，如第2.6.2节所述。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional Information:
其他信息：
Deprecated alias names for this type: None
此类型的已弃用别名：无
Magic number(s): None
幻数：无
File extension(s): *.json
File extension(s): *.json
Macintosh file type code(s): TEXT
Macintosh文件类型代码：文本
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Esko Dijk ("Esko.Dijk@Philips.com")
Esko Dijk（“Esko。Dijk@Philips.com")
Intended usage: COMMON
预期用途：普通
Restrictions on usage: None
使用限制：无
Author: CoRE WG
作者：核心工作组
Change controller: IETF
更改控制器：IETF
Provisional registration? (standards tree only): N/A
临时登记？（仅限标准树）：不适用
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月<http://www.rfc-editor.org/info/rfc3376>.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002, <http://www.rfc-editor.org/info/rfc3433>.
[RFC3433]Bierman，A.，Romascanu，D.，和K.Norseth，“实体传感器管理信息库”，RFC 3433，2002年12月<http://www.rfc-editor.org/info/rfc3433>.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003, <http://www.rfc-editor.org/info/rfc3542>.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月<http://www.rfc-editor.org/info/rfc3542>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月<http://www.rfc-editor.org/info/rfc3810>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月<http://www.rfc-editor.org/info/rfc4601>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>.
[RFC4919]Kushalnagar，N.，黑山，G.，和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，2007年8月<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing Architecture", RFC 5110, January 2008, <http://www.rfc-editor.org/info/rfc5110>.
[RFC5110]Savola，P.，“互联网多播路由体系结构概述”，RFC51102008年1月<http://www.rfc-editor.org/info/rfc5110>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月<http://www.rfc-editor.org/info/rfc5771>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月<http://www.rfc-editor.org/info/rfc6092>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，图伯特，P.，布兰特，A.，许，J.，凯尔西，R.，列维斯，P.，皮斯特，K.，斯特鲁克，R.，瓦塞尔，JP.，和R.亚历山大，“RPL：低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月<http://www.rfc-editor.org/info/rfc6550>.
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012, <http://www.rfc-editor.org/info/rfc6636>.
[RFC6636]Asaeda，H.，Liu，H.，和Q.Wu，“调整移动和无线网络中路由器的互联网组管理协议（IGMP）和多播侦听器发现（MLD）的行为”，RFC 6636，2012年5月<http://www.rfc-editor.org/info/rfc6636>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 66902012年8月<http://www.rfc-editor.org/info/rfc6690>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年11月<http://www.rfc-editor.org/info/rfc6775>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, July 2014, <http://www.rfc-editor.org/info/rfc7320>.
[RFC7320]诺丁汉，M.，“URI设计和所有权”，BCP 190，RFC 7320，2014年7月<http://www.rfc-editor.org/info/rfc7320>.
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC 1033, November 1987, <http://www.rfc-editor.org/info/rfc1033>.
[RFC1033]洛托，M.，“域管理员操作指南”，RFC1033，1987年11月<http://www.rfc-editor.org/info/rfc1033>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月<http://www.rfc-editor.org/info/rfc4605>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009, <http://www.rfc-editor.org/info/rfc5740>.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月<http://www.rfc-editor.org/info/rfc5740>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>.
[RFC7346]Droms，R.，“IPv6多播地址范围”，RFC 73462014年8月<http://www.rfc-editor.org/info/rfc7346>.
[BLOCKWISE-CoAP] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Work in Progress, draft-ietf-core-block-15, July 2014.
[分块CoAP]Bormann，C.和Z.Shelby，“CoAP中的分块传输”，正在进行的工作，草稿-ietf-core-block-15，2014年7月。
[CoRE-RD] Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-01, December 2013.
[CoRE RD]谢尔比，Z.，鲍曼，C.，和S.Krco，“核心资源目录”，正在进行的工作，草稿-ietf-CoRE-Resource-Directory-01，2013年12月。
[OBSERVE-CoAP] Hartke, K., "Observing Resources in CoAP", Work in Progress, draft-ietf-core-observe-14, June 2014.
[观察CoAP]Hartke，K.，“CoAP中的观察资源”，正在进行的工作，草案-ietf-core-OBSERVICE-14，2014年6月。
[MCAST-MPL] Hui, J. and R. Kelsey, "Multicast Protocol for Low power and Lossy Networks (MPL)", Work in Progress, draft-ietf-roll-trickle-mcast-09, April 2014.
[MCAST-MPL]Hui，J.和R.Kelsey，“用于低功耗和有损网络（MPL）的多播协议”，正在进行的工作，草稿-ietf-roll-trickle-MCAST-092014年4月。
[MCAST-SECURITY] Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Rahman, "DTLS-based Multicast Security in Constrained Environments", Work in Progress, draft-keoh-dice-multicast-security-08, July 2014.
[MCAST-SECURITY]Keoh，S.，Kumar，S.，Garcia Morchon，O.，Dijk，E.，和A.Rahman，“受限环境中基于DTLS的多播安全”，正在进行的工作，草稿-Keoh-dice-Multicast-SECURITY-082014年7月。
[IPSEC-PAYLOAD] Migault, D. and C. Bormann, "IPsec/ESP for Application Payload", Work in Progress, draft-mglt-dice-ipsec-for-application-payload-00, July 2014.
[IPSEC-PAYLOAD]Migault，D.和C.Bormann，“应用程序有效负载的IPSEC/ESP”，正在进行的工作，草稿-mglt-dice-IPSEC-for-Application-PAYLOAD-00，2014年7月。
Appendix A. Multicast Listener Discovery (MLD)
附录A.多播侦听器发现（MLD）
In order to extend the scope of IP multicast beyond link-local scope, an IP multicast routing or forwarding protocol has to be active in routers on an LLN. To achieve efficient IP multicast routing (i.e., avoid always flooding IP multicast packets), routers have to learn which hosts need to receive packets addressed to specific IP multicast destinations.
为了将IP多播的范围扩展到链路本地范围之外，必须在LLN上的路由器中激活IP多播路由或转发协议。为了实现高效的IP多播路由（即，避免总是淹没IP多播数据包），路由器必须了解哪些主机需要接收发往特定IP多播目的地的数据包。
The MLD protocol [RFC3810] (or its IPv4 equivalent, IGMP [RFC3376]) is today the method of choice used by a (IP multicast-enabled) router to discover the presence of IP multicast listeners on directly attached links, and to discover which IP multicast addresses are of interest to those listening nodes. MLD was specifically designed to cope with fairly dynamic situations in which IP multicast listeners may join and leave at any time.
MLD协议[RFC3810]（或其IPv4等价物，IGMP[RFC3376]）是（启用IP多播的）路由器今天使用的一种选择方法，用于发现直接连接的链路上是否存在IP多播侦听器，以及发现这些侦听节点感兴趣的IP多播地址。MLD专门设计用于处理IP多播侦听器可以随时加入和离开的相当动态的情况。
Optimal tuning of the parameters of MLD/IGMP for routers for mobile and wireless networks is discussed in [RFC6636]. These guidelines may be useful when implementing MLD in LLNs.
[RFC6636]中讨论了移动和无线网络路由器MLD/IGMP参数的优化调整。在LLN中实施MLD时，这些指南可能有用。
Acknowledgements
致谢
Thanks to Jari Arkko, Peter Bigot, Anders Brandt, Ben Campbell, Angelo Castellani, Alissa Cooper, Spencer Dawkins, Badis Djamaa, Adrian Farrel, Stephen Farrell, Thomas Fossati, Brian Haberman, Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Kathleen Moriarty, Pete Resnick, Dale Seed, Zach Shelby, Martin Stiemerling, Peter van der Stok, Gengyu Wei, and Juan Carlos Zuniga for their helpful comments and discussions that have helped shape this document.
感谢贾里·阿尔科、彼得·比戈特、安德斯·勃兰特、本·坎贝尔、安杰洛·卡斯特拉尼、艾莉莎·库珀、斯宾塞·道金斯、巴迪斯·贾马、阿德里安·法雷尔、斯蒂芬·法雷尔、托马斯·福萨蒂、布赖恩·哈伯曼、比约恩·霍尔曼、马蒂亚斯·科瓦奇、广路、萨尔瓦托、克里·林恩、安德鲁·麦格雷戈、凯瑟琳·莫里亚蒂、皮特·雷斯尼克、戴尔·塞德、扎克·谢尔比，Martin Stieemerling、Peter van der Stok、Gengyu Wei和Juan Carlos Zuniga感谢他们的有益评论和讨论，这些评论和讨论有助于形成本文件。
Special thanks to Carsten Bormann and Barry Leiba for their extensive and thoughtful Chair and AD reviews of the document. Their reviews helped to immeasurably improve the document quality.
特别感谢Carsten Bormann和Barry Leiba对该文件进行了广泛而周到的主持和广告评论。他们的审查极大地提高了文件质量。
Authors' Addresses
作者地址
Akbar Rahman (editor) InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal, Quebec H3A 3G4 Canada
Akbar Rahman（编辑）InterDigital Communications有限责任公司，加拿大魁北克省蒙特利尔西谢尔布鲁克街1000号H3A 3G4
EMail: Akbar.Rahman@InterDigital.com
EMail: Akbar.Rahman@InterDigital.com
Esko Dijk (editor) Philips Research High Tech Campus 34 Eindhoven 5656AE Netherlands
Esko Dijk（编辑）飞利浦研究高科技园区34埃因霍温5656AE荷兰
EMail: esko.dijk@philips.com
EMail: esko.dijk@philips.com