Edge-assisted Traffic Engineering and applications in the IoT

物联网中边缘辅助的流量工程和应用

本文为SIGCOMM 2018 Workshop (Mobile Edge Communications, MECOMM)论文。

笔者翻译了该论文。由于时间仓促，且笔者英文能力有限，错误之处在所难免；欢迎读者批评指正。

本文及翻译版本仅用于学习使用。如果有任何不当，请联系笔者删除。

本文作者包含3位，Nikos Fotiou, Dimitrios Mendrinos, George C. Polyzos@Mobile Multimedia Laboratory, Athens University of Economics and Business

ABSTRACT (摘要）

Software-Defned Networking (SDN) promises novel traffic engineering capabilities transforming every network from a mere packet forwarding fabric into an intelligent distribution medium. We extend the functionality of the core SDN component, the SDN controller, to perform path computations over “annotated” topologies. Specifcally, we exploit the use of tags, which describe network node properties and capabilities, enabling a new type of network control applications and thus connecting user applications and traffic flows with network decisions and management. Tags can be set and modifed in a number of different ways, supporting context awareness and cognition in the network in a lightweight and loosely integrated way. Intelligent applications running at edge nodes may request unicast, anycast, or multicast paths among nodes with specifc tags or tag properties, realizing efficiently traffic engineering goals and supporting network slicing, virtualization, finer resource control, and easier management. We illustrate this new capability in the IoT domain by demonstrating how CoAP group communication can be implemented in a seamless, lightweight, and effucient way, releasing the constrained endpoints from the requirement to support IP multicast.

软件定义网络（SDN）给新型流量工程功能（将每个网络从单纯的数据包转发结构转变为智能分发介质）带来希望。我们扩展了核心SDN组件（SDN控制器）的功能，以通过“带注释的”拓扑执行路径计算。具体而言，我们利用标签来描述网络节点的属性和功能，实现新型网络控制应用，从而将用户应用和流量与网络决策和管理相连接。标签可以通过多种不同的方式进行设置和修改，以轻量级和松散集成的方式支持网络中的上下文感知和认知。在边缘节点上运行的智能应用程序可以在具有特定标签或标签属性的节点之间请求单播，任播或多播路径，实现有效的流量工程目标并支持网络切片、虚拟化、更精细的资源控制和更容易的管理。我们通过演示如何以无缝、轻量和高效的方式实现CoAP组通信来说明IoT领域内的这种新功能，从支持IP多播的需求中释放受限端点。

1 INTRODUCTION （引言）

Nowadays, it is evident that the Internet has evolved from a facility that interconnects static end-hosts, into a dynamic ecosystem which extends to our physical world. Smartphones, Things and home appliance with interconnection capabilities, portable computing devices, powerful personal workstations, all compose a powerful toolset that offers to end-users endless possibilities. Application providers create novel services that can be accessed through multiple devices, expand to multiple network locations, and generate vast amounts of traffic. Struggling to cope with this vivid environment, network operators seek to transform the traditionally static networks into an elastic, intelligent platform, that will not merely transfer packets from the “dump” edge to the “smart” core, but it will also provide in-network functions and services, making end-user experience even richer. A critical technology allowing the realization of this goal is SoftwareDefned Networking (SDN) [11].

如今，互联网显然已从一个互连静态终端主机的设施发展成一个延伸到我们物理世界的动态生态系统。 具有互连功能的事物和家用电器，便携式计算设备，功能强大的个人工作站，都构成了一个功能强大的工具集，可为最终用户提供无限可能。 应用程序提供商创建可以通过多个设备访问，扩展到多个网络位置并生成大量流量的新颖服务。 为了应对这种生动的环境，网络运营商试图将传统的静态网络转变为一个弹性的智能平台，不仅可以将数据包从“转储”边缘转移到“智能”核心，而且还可以提供 网内功能和服务，使最终用户体验更加丰富。 软件定义网络（SDN）[11]是实现这一目标的关键技术。

SDN allows the use of centrally managed switches, enabling network operators to leverage the full capabilities of their network. These switches are programmable in the sense that using a specialized protocol (such as OpenFlow), they can be confgured with rules to forward data “flows” towards their destinations through specifc node and link paths, facilitating in this way load-balancing, service differentiation, in-network functions, and providing novel network services [5]. At the heart of an SDN-based network is an SDN controller, which is responsible for dynamically setting up switch flow tables based on confgurations–usually expressed using a scripting or programming language–that capture the requirements and the business processes of the network operator.

SDN允许使用集中化管理的交换机，使网络运营商能够充分利用其网络的全部功能。 这些交换机在使用专用协议（例如OpenFlow）的意义上是可编程的，它们可以通过规则配置，通过特定的节点和链路路径将数据“流”转发到它们的目的地，从而以这种方式促进负载平衡、服务差异化 、网络内功能，并提供新颖的网络服务[5]。 基于SDN的网络的核心是SDN控制器，它负责根据配置动态设置交换机流表（通常使用脚本或编程语言表示 ）捕获网络运营商的要求和业务流程。

In this paper, we propose an enhanced SDN-based architecture that extends traditional approaches in the following way: (i) network nodes are annotated with “tags” describing their properties and capabilities, (ii) SDN controllers act as “path computation elements” and are capable of calculating on-demand paths among or composed of nodes with specifc tags or tag properties, (iii) intelligent applications, running on edge nodes, are able to request paths from the SDN controller, as well as to set/delete their own application-specifc tags. These enhancements are supported by a Bloom flterbased forwarding technique that achieves seamless multicast communication. This technique requires minimum and fxed state in the switches, which can be installed during the bootstrap. Despite that the path requesting applications and the path computation process can be application aware and act based on the requirements of a specifc application, or even based on the context of a specifc user, our approach does not require from the SDN components to perform deep packet inspection (as for example in [3]), neither requires modifcations to already established standards (as for example in [6]). As a matter of fact, our proof of concept implementation is based on readily available software switches and the OpenFlow 1.2 standard. We argue that the extensions proposed in this paper, combined with the Bloom flter-based forwarding, although simple, create many opportunities for novel services. In particular, our approach facilitates group/anycast communication paradigms, supports service chaining and composition, improves network management, and facilitates new services and applications. In order to demonstrate the efficiency of our approach, we present how a group communication protocol designed for the Internet of Things (IoT), i.e., the Constrained Application Protocol (CoAP) extension for group communication, can be efciently implemented over an SDN network that supports tag-based path computation. Traditional CoAP group communication requires from CoAP endpoints to support the IP multicast protocol. Moreover, CoAP group related information is maintained by the endpoints, hence, the number of groups increases and managing them becomes hard. With our implementation, constrained endpoints can beneft from group communication using vanilla CoAP without the extensions, without modifcations, and without the need to support IP multicast. Moreover, the creation of a new group becomes easier and the management of existing groups becomes more efcient. Finally, using our approach, service providers can easily leverage existing IoT deployments and offer new, group communication-based services.

在本文中，我们提出了一种增强的基于SDN的体系结构，它以下列方式扩展了传统方法：（i）网络节点注释了描述其属性和功能的“标签”，（ii）SDN控制器充当“路径计算元素”并且能够计算具有特定标签或标签属性的节点之间或由其组成的按需路径，（iii）在边缘节点上运行的智能应用程序能够从SDN控制器请求路径，以及设置/删除它们的应用程序特定标签。 Bloom基于flom的转发技术支持这些增强，实现无缝多播通信。此技术需要交换机中的最小和固定状态，可以在引导期间安装。尽管请求应用程序和路径计算过程的路径可以是应用程序感知的并且基于特定应用程序的要求或甚至基于特定用户的上下文来行动，但是我们的方法不需要来自SDN组件来执行深度分组检查（例如在[3]中），既不需要对已经建立的标准进行修改（例如在[6]中）。事实上，我们的概念验证实施基于现成的软件开关和OpenFlow 1.2标准。我们认为本文提出的扩展与基于Bloom flter的转发相结合，虽然简单，但却为新颖的服务创造了许多机会。特别是，我们的方法促进了组/任播通信范例，支持服务链和组合，改进了网络管理，并促进了新的服务和应用。为了证明我们的方法的效率，我们介绍了如何通过SDN网络有效地实现为物联网（IoT）设计的群组通信协议，即用于群组通信的约束应用协议（CoAP）扩展。支持基于标签的路径计算。传统CoAP组通信需要CoAP端点支持IP多播协议。此外，CoAP组相关信息由端点维护，因此，组的数量增加并且管理它们变得困难。通过我们的实现，受约束的端点可以使用没有扩展的vanilla CoAP进行组通信，无需修改，也无需支持IP多播。此外，新组的创建变得更加容易，现有组的管理变得更加有效。最后，使用我们的方法，服务提供商可以轻松利用现有的物联网部署和新的基于群组通信的服务。

The structure of the remainder of this paper is as follows. In Section 2 we present the design of our solution. In Section 3 we present our implementation of an Internet Service Provider’s (ISP) network that interconnects CoAP endpoints, which we selected as a use case in order to illustrate more details of our solution, as well as in order to highlight its advantages. Finally, in Section 4 we provide our conclusions and plans for future work.

本文其余部分的结构如下。 在第2节中，我们介绍了我们的解决方案的设计。 在第3节中，我们介绍了互联CoAP端点的Internet服务提供商（ISP）网络的实现，我们选择它作为用例，以便说明我们解决方案的更多细节，以及突出其优势。 最后，在第4节中，我们提供了我们的工作结论和未来计划。

2 DESIGN （设计）

Our design assumes the network of a single ISP implemented using SDN technology. ISP’s clients are connected to the network through “intelligent” edge-nodes.

我们的设计假定使用SDN技术实现的单个ISP网络。 ISP的客户端通过“智能”边缘节点连接到网络。

2.1 Bloom filter forwarding （Bloom filter转发）

For all in-network traffic (i.e., for the portion of the network surrounded by edge-nodes) Bloom flter-based forwarding is used. In particular we assume the Bloom flter-based forwarding approach described by Reed et al. in [9]. To realize this, each link of the SDN network is assigned a unique identifer, which is a fxed-size Bloom filter-based vector. Each link identifer is mapped to an arbitrary bitmask with length equal to two IPv6 addresses and corresponding OpenFlow [1] rules are installed at its adjacent switch interfaces. The forwarding identifer that realizes the communication between edge-nodes is a Bloom flter encoding the link identifers of the path that a packet should follow, by simply ORing these identifers. An interesting property of this type of forwarding is that by ORing the encodings of two paths A → B and A → C, the encoding of a multicast path from A to B and C is derived. The solution in [9] encodes Bloom flters in the IPv6 source and destination fields of an IPv6 packet and uses the OpenFlow arbitrary mask match in switches to make forwarding decisions. Therefore, this forwarding technique is implemented using standard OpenFlow mechanisms and without modifying the structure of network packets; to a network monitoring tool, these packets appear to be ordinary IPv6 packets, but with “strange” addresses. Moreover, the appropriate OpenFlow rules related to Bloom filter-based forwarding can be installed when a switch joins the network. With these rules, the switch will not require any further information set by the controller in order to forward a packet, achieving signifcant gains in terms of network overhead reduction.

对于所有网内流量（即，由边缘节点包围的网络部分），使用基于Bloom filter的转发。特别地，我们假设使用由Reed等人在文献[9]中描述的基于Bloom filter的转发方法。为了实现这一点，SDN网络的每条链路都被分配了一个唯一的标识符，它是一个固定大小的基于Bloom filter的向量。每个链路标识符映射到长度等于两个IPv6地址的任意位掩码，并且相应的OpenFlow [1]规则安装在其相邻的交换机接口上。实现边缘节点之间通信的转发标识符是Bloom filter，其通过简单地对这些标识符进行OR运算来编码数据包路径的链路标识符。这种转发的一个有趣特性是通过对两条路径A→B和A→C的编码进行“或”运算，可以导出从A到B和C的多播路径的编码。文献[9]中的解决方案在IPv6数据包的源和目的域中编码Bloom filters，并在交换机中使用OpenFlow任意掩码匹配做出转发决策。因此，这种转发技术是使用标准的OpenFlow机制实现的，不需要修改网络数据包的结构;对于网络监控工具，这些数据包看起来是普通的IPv6数据包，但具有“奇怪”的地址。此外，当交换机加入网络时，可以安装与基于Bloom filter的转发相关的适当的OpenFlow规则。利用这些规则，交换机将不需要控制器设置任何的进一步信息以转发分组，从而在网络开销减少方面取得显着收益。

Figure 1 illustrates a simplifed example of Bloom filter-based forwarding. As it can be seen each link is identifed by a (binary) identifer. The path that a packet should follow is encoded in a Bloom filter, constructed by ORing the identifers of the links that compose the path. For simplicity reasons we assume that the Bloom filter is stored in the Source IP field of the packet (padded with zeros to match the field’s length). Each switch port is confgured with a network mask and a source IP, both of which match the identifer of the link connected to that port. For each incoming packet, every switch performs the following actions:

图1说明了基于Bloom filter转发的简化示例。 可以看出，每个链接都由（二进制）标识符标识。 数据包路由路径在Bloom filter中编码，通过构成该路径的链接的标识符的OR运算构造。为简单起见，我们假设Bloom filter存储在数据包的源IP地址域中（用零填充以匹配字段的长度）。每个交换机端口都配有网络掩码和源IP，两者都与连接到该端口的链路的标识符相匹配。 对于每个传入的数据包，每个交换机都执行以下操作：

• It retrieves the Source IP address included in the incoming packet
• 获取传入数据包的源IP地址
• For each port (except the port from which the packet arrived) it ANDs the source IP of the packet with the network mask associated with the port
• 对于每一个端口（除了数据包传入的端口），将数据包的源IP和该端口的网络掩码进行AND运算
• If the output of the AND operation matches the source IP associated with the port, then the packet is forwarded to the link connected to that port
• 如果AND操作的输出和该端口的源IP匹配，数据包被转发到与该端口相连的链路。

These actions can be achieved using standard OpenFlow rules. For more details interested readers are referred to [9].

这些操作可以通过标准的OpenFlow规则实现。更多细节请参考[9]。

图1： 基于Bloom filter转发示例。

2.2 Tags （标签）

Each node in the network (i.e., both edge and internal nodes) is associated with a set of tags. These tags may represent network related attributes (e.g., network address, network function), physical location (e.g., room number, geolocation information), application layer functionality or context (e.g., service description, security properties) and many other types of information. Moreover, SDN controllers learn (using mechanisms which are out of the scope of this paper) the network topology, all link identifers, as well as the tags associated with each node.

网络中的每个节点（即，边缘和内部节点）与一组标签相关联。这些标签可以表示网络相关属性（例如，网络地址，网络功能）、物理位置（例如，房间号，地理位置信息）、应用层功能或上下文（例如，服务描述，安全属性）和许多其他类型的信息。 此外，SDN控制器学习（使用超出本文范围的机制）网络拓扑，所有链路标识以及与每个节点相关联的标签。

Controllers may also recognize types of tags (e.g., integer, geo-location, video quality) and perform some basic operations (e.g., arithmetic comparisons, compare dimensions, ordering, etc).

控制器还可以识别标签的类型（例如，整数，地理位置，视频质量）并执行一些基本操作（例如，算术比较，比较维度，排序等）。

2.3 Paths （路径）

SDN controllers are capable of computing paths (and determine the appropriate Bloom filter identifer) among nodes with specific tags or tag properties, as well as paths passing through or composed of nodes with specific tags. Specific algorithms are required for this and typically this functionality is provided with extra network apps with particular capabilities. A node in the network can send a packet to a (set of) node(s) identifed by (some) specifc tags. The node may specify that the packet should reach all nodes (multicast), or at least one node in the set or the best available node (anycast). Moreover, the origin may define whether the destination node(s) should be associated with all tags or with some of the tags, or even define an ordered list of tags, which should be reflected in an ordered list of nodes that must be part of the composed path (service chaining). For example, a node may request that a packet should be initially forwarded to a firewall, then to a compression service, and finally to a particular edge-node. If the sender node knows the path towards the destination node(s), then it simply encodes it in a Bloom flter and the aforementioned forwarding procedure is used. If the node does not know the path to the desired destination(s), it creates a special packet, it sets the Ethernet source and destination felds of the packet to a pre-defined constant value and adds the desired tags in the packet’s payload. The frst SDN switch that receives this special packet will not have a rule to switch it; hence, it forwards it to the SDN controller. The SDN controller extracts the tags, and given its knowledge of the underlying SDN topology, it calculates the appropriate Bloom flter, as well as a Bloom filter for the reverse path (if applicable), and returns this information to the origin switch as an Openflow PacketOut message. Finally, the switch forwards this message to the node that originally sent the packet. That node can now use the provided Bloom flter for all subsequent communications.

SDN控制器能够计算具有特定标签或标签属性的节点之间路径（并确定适当的Bloom filter标识符），以及计算由具有特定标签的节点组成的路径。为此需要特定的算法，并且此功能通常由具有特定功能的额外网络应用程序提供。网络中的节点可以将数据包发送到由某（些）特定标签标识的（一组）节点。节点可以指定数据包应该到达所有节点（多播），或者集合中的至少一个节点或最佳可用节点（任播）。此外，原点可以定义目标节点是应该与所有标签相关联还是与某些标签相关联，或者甚至定义标签的有序列表，这些标签应该在必须属于组成路径（服务链）的一部分的有序节点列表中反映出来。例如，节点可以要求将数据包首先转发到防火墙，然后转发到压缩服务，最后转发到特定的边缘节点。如果发送方节点知道到目的节点的路径，则它只是在Bloom filter中对其进行编码，并使用上述的转发过程。如果节点不知道到期望的目的地的路径，则会创建一个特殊数据包，它将数据包的以太网源和目标域设置为预定义的常量值，并在数据包的负载中添加所需的标记。接收此特殊数据包的第一个SDN交换机没有相关规则；因此，它将该数据包转发给SDN控制器。 SDN控制器提取标签，并根据其对底层SDN拓扑的了解，计算适当的Bloom filter，以及反向路径的Bloom filter（如果适用），并将此信息作为Openflow PacketOut消息返回到原始交换机。最后，交换机将此消息转发到最初发送该数据包的节点。该节点现在可以使用提供的Bloom filter进行所有后续通信。

3 USE CASE: COAP GROUP COMMUNICATION （使用案例：COAP组通信）

3.1 Background （背景）

CoAP [10] is a lightweight protocol, designed to be the “HTTP of the IoT.” The CoAP interaction model is similar to the client-server model of HTTP: a CoAP client requests a resource from a server; if the resource is available, the server responds, otherwise it simply ACKnowledges (ACK) the request and responds asynchronously when the resource becomes available. CoAP resources are identifed by a URI, similar to HTTP URIs. CoAP group communication is a CoAP extension defned in RFC 7390 [8]. This extension allows clients to retrieve or set resources from a group of servers e.g., retrieve the temperature from all sensors of a building, turn on all the lights of a smart city and so forth. When CoAP group communication is used, URI-hosts (e.g., coap://floor1.building6), are mapped to an IP multicast group in which all related CoAP endpoints are members. In order to implement this behavior in a legacy network (a) DNS servers should be modifed, and (b) all CoAP servers should join a priori all possible IP multicast groups.

CoAP [10]是一种轻量级协议，设计为“IoT的HTTP”。CoAP的交互模型类似于HTTP的客户端-服务器模型：CoAP客户端从服务器请求资源；如果资源可用，则服务器响应，否则它只是确认（ACK）请求并在资源可用时异步响应。 CoAP资源由URI标识，类似于HTTP URI。 CoAP组通信是RFC 7390中定义的CoAP扩展[8]。该扩展允许客户端从一组服务器检索或设置资源，例如，从建筑物的所有传感器中获取温度，打开智能城市的所有灯等等。当使用CoAP组通信时，URI主机（例如，coap://floor1.building6）被映射到IP多播组，其中所有相关的CoAP端点都是该IP多播组的成员。为了在传统网络中实现此行为（a）应修改DNS服务器，并且（b）所有的CoAP服务器应该加入所有可能的IP多播组。

3.2 Implementation （实现）

As a proof of concept, we used the mininet network emulator [4], the open vswitch programmable switch [7], and the POX network controller [2] to emulate an SDN-based network of an ISP that allows tag-based path computation. The network topology (including link identifers and node tags) is included into a JSON-encoded confguration fle. A Topology Manager helper class parses this fle and provides methods for creating a path among nodes with specifc tags. This helper class, implemented using the NetworkX python library, is used by the SDN controller whenever a path is requested by a network node. Moreover, this class is also used by the controller every time a new switch joins the network in order to install the appropriate rules related to the Bloom flter-based forwarding.

作为概念验证，我们使用mininet网络仿真器[4]、open vswitch可编程交换机[7]和POX网络控制器[2]来模拟基于SDN的ISP网络，该网络允许基于标签的路径计算。 网络拓扑（包括链路标识符和节点标记）包含在JSON编码的配置文件中。 拓扑管理器帮助类解析此文件并提供在具有特定标记的节点之间创建路径的方法。 每当网络节点请求路径时，SDN控制器都使用此Helper类（使用NetworkX python库实现）。 此外，每当新交换机加入网络时，控制器也会使用此类，以便安装与基于Bloom filter的转发相关的适当规则。

In addition to the emulated network, we implemented CoAP clients and servers using the libcoap library. Edge nodes of the ISP’s network act as CoAP proxies and CoAP clients are confgured to use an edge-node as a proxy. Hence, whenever a CoAP client wishes to send a CoAP (group) request it simply forwards it to an edge-node. Moreover, CoAP servers are associated with “group tags” that have application specifc semantics (e.g., “buiding6”, “floor1”). This association is implemented in the corresponding edge-nodes and CoAP servers are oblivious about it. Hence, tag-server (de-)association is implemented without communicating with the respective servers. A group name, included in the URI-host field of a CoAP group request, is interpreted as a list of tags and it should be forwarded to all servers associated with these tags. For example, a request for coap://floor1.building6 should be forwarded to all CoAP servers associated with the tags “floor1” and “building6”. Edge-nodes that are connected to a CoAP server maintain mappings of group names to IPv6 addresses. These mappings are used for forwarding CoAP requests to the appropriate CoAP server. Moreover, and since CoAP servers cannot handle Bloom flters, edge-nodes replace the Bloom flter included in the transmitted packet with the server’s IPv6 address. The implemented architecture is illustrated in Figure 2.

除了模拟网络，我们还使用libcoap库实现了CoAP客户端和服务器。 ISP网络的边缘节点充当CoAP代理，CoAP客户端被配置为使用边缘节点作为代理。因此，每当CoAP客户端希望发送CoAP（组）请求时，它只是将其转发到边缘节点。此外，CoAP服务器与具有应用程序特定语义的“组标签”相关联（例如，“buiding6”，“floor1”）。这种关联在相应的边缘节点中实现，CoAP服务器对比并不关心。因此，标签-服务器（解除）关联的实现不需要与相应的服务器通信。包含在CoAP组请求的URI主机域中的组名称被解释为标签列表，它应该被转发到与这些标签关联的所有服务器。例如，对coap:// floor1.building6的请求应转发到与标签“floor1”和“building6”关联的所有CoAP服务器。连接到CoAP服务器的边缘节点维护组名称到IPv6地址的映射。这些映射用于将CoAP请求转发到适当的CoAP服务器。此外，由于CoAP服务器无法处理Bloom filters，边缘节点使用服务器的IPv6地址替换传输的数据包中包含的Bloom filter。实现的体系结构如图2所示。

图2：参考架构

Given the above description, a CoAP group communicationbased transaction is implemented by executing the following procedures.

在给出以上描述的情况下，通过执行以下过程来实现基于CoAP组通信的事务。

3.2.1 CoAP request. The CoAP client sends the CoAP request to its proxy edge-node. This edge-node extracts the URI-host and splits it into tokens. If this is the frst request for that URI-host the edge node executes the “Path Request” procedure, otherwise it executes the “Request Forwarding” procedure.

3.2.1 CoAP请求。 CoAP客户端将CoAP请求发送到其代理边缘节点。 此边缘节点提取URI主机并将其拆分为令牌。 如果这是对该URI主机的第一个请求，则边缘节点执行“路径请求”过程，否则它执行“请求转发”过程。

3.2.2 Path request. The edge node creates a packet with Ethernet destination 00:00:00:00:00:01 and includes in its application payload the list of tokens. Then it forwards this packet to the network. The frst programmable switch that receives this packet forwards it to the SDN controller. The SDN controller extracts the token list and requests from the Topology Manager to compute a path from the sender edge-node to all edge-nodes connected to a CoAP server associated with all the desired tags. Then, it creates a new packet that includes in its payload the constructed Bloom flter and sends it back to the programmable switch; the switch in return forwards the received packet back to the sender edge-node.

3.2.2路径请求。 边缘节点创建一个以太网目的地为00：00：00：00：00：01的数据包，并在其应用程序有效负载中包含令牌列表。 然后它将此数据包转发到网络。 接收该数据包的第一个可编程交换机将其转发到SDN控制器。 SDN控制器从拓扑管理器中提取令牌列表和请求，以计算从发送方边缘节点到连接到与所有所需标签相关联的CoAP服务器的所有边缘节点的路径。 然后，它创建一个新的数据包，在其有效载荷中包含构造的Bloom filter并将其发送回可编程交换机; 交换机将接收的数据包转发回发送方边缘节点。

3.2.3 Request Forwarding. Now the edge-node knows the Bloom flter of the path towards all destinations. It creates a new packet and it uses the IPv6 source and destination fields to encode the Bloom flter. Moreover, it adds in the application payload CoAP request. Finally, it sends this packet in the network. The packet reaches all destination edge-nodes using Bloom flter-based forwarding. Each node extracts the CoAP request and forwards it to the appropriate CoAP server.

3.2.3请求转发。 现在，边缘节点知道到所有目的地的路径的Bloom filter。 它创建一个新数据包，并使用IPv6源和目标字段对Bloom filter进行编码。 而且，它在应用程序有效负载中添加CoAP请求。 最后，它在网络中发送此数据包。 数据包使用基于Bloom filter的转发到达所有目标边缘节点。 每个节点提取CoAP请求并将其转发到适当的CoAP服务器。

3.2.4 Response Forwarding. Each CoAP server generates a response and forwards it to the corresponding edge-node. The edge-node selects the appropriate Bloom flter, creates a new packet, and forwards it in the network. This packet includes the Bloom flter in the IPv6 address felds and the CoAP response in the payload. This packet eventually reaches the edge-node in which the CoAP client is connected. The latter node extracts the CoAP response and forwards it to the client.

3.2.4响应转发。 每个CoAP服务器生成响应并将其转发到相应的边缘节点。 边缘节点选择适当的Bloom filter，创建一个新的数据包，并在网络中转发它。 该数据包的IPv6地址域包含Bloom filter，负载中包含CoAP响应。 该数据包最终到达CoAP客户端所连接的边缘节点。 后者提取CoAP响应并将其转发给客户端。

The above procedure is illustrated in Figure 3.

图3描述了上述过程。

图3： CoAP组通信过程

3.3 Evaluation （评估）

From the description of our implementation, it is evident that our solution provides the following advantages:

从我们的实现描述中，我们的解决方案具有如下优势：

CoAP endpoints do not need to support IP multicast. As mentioned in [10] the recommended approach for implementing CoAP group communication is by using IP multicast. However, IP multicast is feared of becoming a barrier for the adoption of CoAP group communication for many (obvious) reasons:

CoAP端点不需要支持IP多播。 如[10]中所述，实现CoAP组通信的推荐方法是使用IP多播。 然而，出于许多（显而易见的）原因，IP组播可能成为采用CoAP组通信的障碍：

• CoAP endpoints must be preconfgured with all group names and the corresponding IP multicast addresses
• 必须使用所有的组名和相应的IP多播地址预先配置CoAP端点
• IoT devices should be enhanced to support IP multicast
• 需要增强IoT设备以支持IP多播
• Network management will become harder in order to not result in conflicting IP multicast addresses
• 网络管理将变得更加困难，以免导致冲突IP多播地址

With the proposed solution, all these drawbacks are overcome.
利用所提出的解决方案，克服了所有这些缺点。

DNS does not have to be modifed. Similarly, RFC 7390 states that URI hosts should be translated into IP multicast addresses using DNS servers. This implies that DNS servers should be confgured with all possible group names and the corresponding IP multicast addresses. Even worse, if group names are artifcially constructed by applications, DNS servers should implement the application logic used for the group name computation. With our solution, not only DNS servers do not have to be modifed, but DNS is not used at all! Indeed, the mapping from a group name to a Bloom filter-based forwarding identifer is performed by the controller using the provided confguration file.

DNS不必修改。 同样地，RFC 7390规定应使用DNS服务器将URI主机转换为IP多播地址。 这意味着DNS服务器应该使用所有可能的组名和相应的IP多播地址进行配置。 更糟糕的是，如果组名是由应用程序人工构造的，则DNS服务器应实现用于组名计算的应用程序逻辑。 使用我们的解决方案，不仅不需要修改DNS服务器，而且根本不使用DNS！ 实际上，控制器使用提供的配置文件来执行从组名到基于Bloom filter的转发标识符的映射。

Group management becomes more efcient. By having all groups centrally managed it becomes easier to create a new group, as well as to modify existing ones. For instance, a tag can be assigned to/removed from a CoAP server without informing it. Hence, a server can be added to or removed from a group with no additional communication overhead. Even better, a CoAP server does not have to be aware of the tags with which it is associated. This results in simpler applications running in CoAP endpoints.

组管理变得更有效率。 通过集中管理所有组，可以更轻松地创建新组，以及修改现有组。 例如，可以在不通知CoAP服务器的情况下将标签分配给CoAP服务器或从中删除。 因此，可以在没有额外通信开销的情况下向组内添加或移除服务器。 更好的是，CoAP服务器不必知道与之关联的标记。 这导致CoAP端点中运行的应用程序更简单。

Service creation and composition becomes easier. With the proposed solution, a service provider may offer new services using existing resources simply by updating the controller’s confguration fle. For example, consider the case of an already deployed IoT network composed of temperature sensors deployed in multiple buildings of a smart city. A service provider may provide aggregation services simply by creating a confguration fle that contains groups and associated sensors.

服务创建和组合变得更容易。 利用所提出的解决方案，服务提供商可以仅通过更新控制器的配置文件来使用现有资源来提供新服务。 例如，考虑已经部署的物联网网络的情况，该网络由部署在智能城市的多个建筑物中的温度传感器组成。 服务提供商可以简单地通过创建包含组和相关传感器的配置文件来提供聚合服务。

Network functions can be easily integrated. Supposedly, a network provider offers add-on network services (e.g. caching). These services are also associated with tags. A node may request from the controller to create a path through a service point.

网络功能可以轻松集成。 据推测，网络提供商提供附加网络服务（例如缓存）。 这些服务也与标签相关联。 节点可以从控制器请求创建通过服务点的路径。

In the implementation presented in this section, edge nodes request paths by simply providing a list of tags. Nevertheless, our implementation allows nodes to specify path creation criteria using attribute-values pairs (e.g., location=floor1). This can be extended to richer expressions, for example, quality >= standard, located in [co-ordinates]. What is more, our implementation allows the association of tags with links. In the future this feature can be used to provide, for example, QoS restrictions.

在本节介绍的实现中，边缘节点通过简单地提供标记列表来请求路径。 然而，我们的实现允许节点使用属性-值对（例如，location = floor1）指定路径创建标准。这可以扩展到更丰富的表达式，例如，质量>=标准，位于[坐标]中。 更重要的是，我们的实现允许标记与链接的关联。 将来，此功能可用于提供QoS限制。