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限制。