Challenges in IoT Networking via TCP/IP Architecture
在TCP/IP体系结构下物联网络存在的挑战

Wentao Shang                   Yingdi Yu

 UCLA                         UCLA

Los Angeles, CA                   Los Angeles, CA

wentao@cs.ucla.edu             yingdi@cs.ucla.edu

 

Ralph Droms                    Lixia Zhang

Cisco Systems                       UCLA

Cambridge, MA                Los Angeles, CA

rdroms@cisco.com              lixia@cs.ucla.edu

摘要

物联网将大量的资源限制设备连接起来，近年来正在变得越来越受欢迎。今天的物联网系统很大程度上基于TCP/IP协议的使用（特别是IPv6）。然而，经过到目前为止对TCP/IP和IoT的观察显示，TCP/IP协议栈，像原始设计的那样，并不能很好地适应IoT环境。在过去的几年里，IETF花费了大量的努力修改TCP/IP协议栈来适应IoT部署场景。这些努力导致对在TCP/IP体系结构中已存在协议的扩展和多种新协议的开发。新的问题仍然持续出现。在本文中，我们分析了将TCP/IP应用于IoT环境下的技术挑战，并评论了IETF提出的多种解决方案。我们讨论现存的基于IP的解决方案对于支持IoT应用程序或者并不高效，或者并不足够，因此，一个更有效的解决方案或许是存在于信息中心网络体系结构中的。

关键词：物联网；TCP/IP；网络体系结构

1   引言

物联网通常指的是不同类型可计算设备的互联，应用程序支持对其的多种监视和控制。为了兼容来自不同供应商的设备和应用程序的异构性，现代IoT系统采纳了TCP/IP协议族中的开放标准，以作为网络解决方案，该开放标准为几十年前的全球有线因特网而开发。然而，IoT网络与传统有线计算机网络在我们下面详细阐述的基本方面不同。这些不同对将TCP/IP应用于IoT环境形成了巨大挑战，应对这些挑战将对网络体系结构造成深远影响。本文的目标是系统地阐述IoT环境下形成的挑战，并阐明应对这些挑战的未来方向。

物联网络包含大量廉价的，资源限制设备。这些设备的设计绝大多数受低的制造和操作开销驱动。结果，IoT设备大多数配备有有限的计算能力，并需要电池能够支持长时间的操作（比如一年）。由于电源限制，IoT网络通常应用低能源二层技术，比如IEEE 802.15.4、蓝牙LE和低能源WiFi，这通常使用相较于传统以太网链路更小的MTU和更低的传输速率。因而，IoT网络协议设计的一个挑战立即被提出，该设计是将包大小适应于限制链路（在2.1节讨论）。为了节约能源，IoT节点可能不总是位于有线网络，此外，IoT系统可能将被部署在没有有线网络基础设施的环境（例如，森林，水下，战场环境），这样就必须依赖于无线网络技术通信。这带来了更多对于TCP/IP协议体系结构的挑战：第一，网状网络采用多链路子网模型，该模型并不被原始的IP编址体系结构支持（在2.2节讨论）；第二，广播和多播在以电池为能源的网络上是昂贵的，因为单独的多播将涉及一系列多跳转发，并可能唤醒多个沉睡节点（在2.3节讨论）；第三，一个可扩展的路由机制对于IP通信来说是必需的，以在网状网络运行（在2.4节讨论）；最后，TCP形式字节流的可靠按序交付通常对于应用程序并不合适，这些应用程序需要为其数据定制控制和优先级（在第3节讨论）。

绝大多数IoT应用程序与许多感知器和执行器交互，来在周围环境中执行各种各样监视和控制任务。这些应用程序的设计模型本质上需要对命名的配置和发现，数据获取和执行操作的安全保护，和面向资源的通信接口，比如，具体状态传递（REST）的高效可扩展的支持。不幸的是，现存的那些问题的许多解决方案广泛用于今天的Web技术，不满足IoT环境限制。例如，传统的基于DNS的命名服务在许多缺少基础设施支持的专用服务器的IoT部署场景中并不适合（在4.1节介绍）。应用程序层内容缓存和代理在断断续续连接的动态网络环境中通常并不高效（在4.2节讨论）。另外，基于信道的安全协议，比如TLS和DTLS，用于确保REST通信的安全，依据协议操作和资源消耗在IoT设备中加以高负载（在4.3节讨论）。

本文的下面部分详细讨论上述的每个问题。我们寻求当将TCP/IP应用于IoT时的体系结构方面引起这些问题的原因。我们也调查当前那些问题的解决方案，这些解决方案可能已被标准化或者正在被IETF开发。并分析为什么这些解决方案解决这些问题是不足够的。本文的目标是提供见解，并指出未来IoT体系结构的设计方向。

2   网络层存在的问题

IP，特别是IPv6，是为今天的因特网环境设计的，将台式电脑和便携式电脑作为终端设备与有线连接的服务器通信。在这一部分，我们讨论当前主机和网络的哪些特性存在于IP中却并不存在于IoT世界中，我们可以做什么来裁剪IP和它的同类协议，以将其适应于IoT环境。

2.1  小MTU值

IoT网络中受限的低能源链路通常具有非常小的MTU值。例如，IEEE 802.15.4-2006最大的物理层帧大小为127字节，这与今天的IP网络形成鲜明对比，IP网络的最小MTU值为1500字节或更多。在20世纪90年代（IoT出现之间）为传统因特网开发的IPv6规范包括两个设计方案，该方案对于小的MTU链路存在问题。首先，IPv6使用40字节固定长度的头，后跟可选的扩展头部，这为小包带来了大的协议开销。第二，IPv6规范需要所有能够运行IPv6的网络支持最小1280字节的MTU大小，这对受限链路是不现实的。

为了使IPv6适应于802.15.4网络，6LoWPAN阐述了在链路层和网络层之间，存在一个适配层，实现了处理上面提到问题的两种机制：头部压缩和链路层破裂。头部压缩允许除去未使用的区域（例如，流标签和流量类型）和冗余信息（例如，IPv6地址中的接口标识符可以由L2 MAC地址而得，因此被删去）。它也定义了扩展头部和UDP头部的压缩方案，这两种方案都频繁地用于IoT中（见2.4节和第3节），以便为应用程序负载留出更多的空间。链路层帧隐藏了802.15.4协议的实际MTU大小，并给网络层错觉它运行在一种遵守标准的链路，能够支持1280字节的MTU。然而，很少有IoT应用程序发送的包能够达到MTU限制。

在IPv6中拥有固定长度的头部的主要目的是提高协议的处理速度。设置一个最小 MTU是为了避免网络内部包的分裂（该问题被广泛认为引起性能问题），并减少了路由器的工作负载。这两个原因用于在当前的因特网中性能优化之用，并不考虑具有小的MTU的约束IoT环境。适配层的增加填补了旧的设计和新的使用需求之间的不匹配，但不可避免地引入了额外的复杂性和开销。

2.2  多链路子网

当前的IPv4和IPv6子网模型考虑了两种类型二层网络：多访问链路，多个节点共享相同的访问媒介，和点对点链路，在同一条链路中存在两个节点。两种网络都假定在相同的子网内的节点能够在一跳范围内可达。另一方面，一个IoT网状网络，包含一个二层设备连接在一起的链路集合，没有任何三层设备（例如，IP路由器）。这本质上创造了一个多链路子网模型，这一点是原始的IP编址的体系结构没有预料到的。

RFC 4903，多链路子网问题，在文档中写出IETF社区决定抛弃多链路子网模型的原因，该模型在二层链路和IP子网之间构建一一映射。主要的考虑围绕许多现存的协议依赖的一跳可达模型。首先，子网内的多链路转发为处理TTL/跳数限制带来了问题。在IP网络中，通过设置TTL/跳数限制为1到255，将通信范围限制到单个子网，并核实当收到时值保持相同。多链路子网模型将破坏任何遵从这样实践的协议，因为执行IP转发的节点跨越多条链路，必须减小TTL/跳数限制值。第二个问题是链路范围内的多播不工作在多链路子网上，并不支持多播路由（这在今天的因特网中也是不可用的）。结果，剩下的协议依赖于链路范围内的多播（例如，ARP、DHCP、邻居发现和多路由协议），也将在多链路子网中被打破。

从根本上，上面的问题由在旧的IP子网模型和新的IoT网状网络之间的不匹配引起。为了避免那些技术问题，我们必须或者依赖于二层机制将多条链路透明地连接成单个网络（与桥接多个以太网分段相似），或者将网状网络分割成多个拥有不同前缀的子网。第一种方法需要某种子网内部的路由性能形式，这将在2.4节讨论。第二种方法介绍了网络配置中的新的复杂性，因为前缀分配必须通过网状网络传播（例如，通过前缀代表），网中的链路形式在动态环境中可能随着时间改变。

2.3  多播效率

许多基于IP的协议大量使用IP多播来实现两个功能之一：在多播组中通知所有的成员，当并不确切地知道询问谁时做查询。然而，支持多播包交付是约束IoT网状网络的一个巨大挑战。首先，绝大多数无线MAC协议禁用多播的链路层确认，导致丢包在链路层不可恢复。第二，由于同时存在的多种MAC协议（例如，不同版本的WiFi），多播接收者可能经历不同的数据传输率，和/或适应不同的链路层速率；因此，发送者必须以最低的常见链路速度在所有的接收者之间传输。第三，IoT节点可能不时转换到睡眠模式以保存能量，因此可能丢失一些多播包。最后，当节点通过网状网络连接时，多播包需要在多路径之间通过多播包被转发，可能唤醒许多处于睡眠的节点，并使已经缺乏的网络资源超过负载。

为了应对在多播支持中的这些困难，遗留的协议必须重新设计以在IP多播被应用于约束IoT环境之前最小化使用IP多播。当IoT节点需要发送通知到多个接收者，而不是将包多播，他们可以在一些熟知位置临时缓存那些包，并等待接收者通过单播按需拉取包（基于他们的睡眠安排）。当他们想要对一个多播组做查询，而不是用多播在网络中洪泛，他们能够发送查询到一些设计好的节点，这些节点被预配为通过按优先级收集信息来响应查询。这些新的方法用按需单播拉取代替多播，来应对支持多播的问题，并适配睡眠节点。

一个对该协议的改进的例子是6LoWPAN的IPv6邻居发现优化。原始的IPv6邻居发现依赖于多播来学习默认网关路由器，将邻居的IP解析到MAC地址，并执行重复地址检测。当将邻居发现功能适应于6LoWPAN，而不是周期地让路由器多播路由通告（这将或者唤醒睡眠节点，或者被那些节点丢失），优化的协议允许约束节点用路由请求消息按需更新路由通告信息。另一个扩展是维持路由器上主机地址的注册，使路由器能够响应地址解析和代表端节点的重复地址检测请求，因此查询节点通过单播消息简单地发送请求到默认路由器。

另一个解决方案叫做MPL，被IETF roll WG提出，从根本上改变了约束网络中多播的转发语义。MPL在MPL转发者（例如，参与MPL的节点）之间使用可控的洪泛通过同步在整个多播域内传播多播包，不需要任何多播路由协议来维持拓扑信息。每个多播包被包生成器ID和一个序列号标识，以便于允许重复检测。同时，近期的包被MPL转发者在变化窗口样式中缓存（例如，FIFO缓存），这能够被用于未来重传。这种新的多播转发协议被当前的ZigBee IP规范采纳。

2.4  网状网络路由

典型的IoT网络拓扑可以分成两类，像在文献[14]中解释的那样：星型拓扑和点对点拓扑。路由配置在星形网络中直接转发，在该网络中集线器节点（例如，蓝牙主节点）为外部设备节点扮演默认网关。然而，星型拓扑的大规模部署被单个集线器节点的信号覆盖所限制，使得覆盖一个广阔区域的应用程序场景变得不适合。网状拓扑通过节点互相中继包来达到大范围覆盖。由于在整个网络中的洪泛很昂贵，路由机制对在网状网络中实现高效的包转发是必需的。

网状网络路由或者在链路层或者在网络层被支持。链路层方法，在IETF术语中叫做下面的网，依赖于二层转发者将多条链路加入一个单独的“一个IP一跳”子网中。网络层方法，叫做上面的路由，依赖于IP路由器来在多条之间转发包。在这一小节的下面部分，我们描述这两个分类中的每一个现存的解决方案。

IEEE公布了802.15.5标准来为由IEEE802.15.4协议形成的网状网络支持链路层路由。基本的方法是首先构建一个网状网络的生成树，以用于二层地址分配：生成树的树根为他的孩子分配连续的链路层地址块，这为它的派生物分配子块。这样的地址分配方法保证在相同的祖先下的节点的链路层地址落在相同的范围。一旦地址被分配，节点便和他的直接邻居开始交换本地链路状态信息，每个邻居构建他的两跳邻居节点表，包含邻居的地址块范围、树的层次和跳数距离。当将包转发到超过两跳距离的目的地时，发送节点应用简单的启发式方法来挑选更靠近生成树根的下一跳，因此我们知道更多关于网络拓扑的信息，但是没有远离发送节点太多。这个解决方案的一个缺点是，当新节点动态地加入网络时，地址分配过程可能必须重新执行，以便适应拓扑改变。

IETF通过上面的路由方法处理网状网络路由问题，并开发了RPL（低能源和丢失率网络路由协议）作为当前标准的解决方案。RPL与IEEE802.15.5分享相同的精神，它对一簇节点建模以作为一颗生成树，叫做面向目的地的有向无环图（DODAG），拥有所有终止于根的直接路径。当在DODAG中的两个节点彼此通信，他们的包向上传递，或者到根节点，或者到一个共同的祖先，然后跟随一条向下链路到目的地。然而，不像IEEE802.15.5分配依赖拓扑的二层地址那样，RPL   不做任何关于IP地址分配的假设。这高效地阻止了共享共同前缀的路由条目的汇聚。在靠近根的节点维护这样的路由表变得十分具有挑战，最坏情况下，必须为子网中的每个设备保存路由条目。RPL也提供一个替代的“非存储”模式，在该模式中，仅仅根节点维护路由表。当沿着下行链路转发包时，根节点需要将全路径信息插入包头部。当它在非根节点减少了内存使用，“非存储”模式增加了向下包的头部大小，这是小的MTU网络存在的问题（见2.1节）。

我们应该注意到在IoT网状网络中路由的基本挑战来自于为多链路环境中的每个主机维护路由信息的需求。这在传统IP网络中不是问题，在传统IP网络中，路由器或自学习桥可以被部署来为路由和转发提供基础设施的支持。然而，在约束IoT环境中，每主机路由或者被网中的每个节点用路由协议维护，这将消耗许多内存，或者被IP包承载作为转发期间的源路由，这与来自链路层的的小的MTU限制冲突。由于IP的面向主机通信语义，路由将仍然是基于IP的IoT网状技术的一个主要挑战。

3   传输层存在的问题

TCP/IP体系结构的传输层提供拥塞控制和可靠交付，这两者都被TCP实现，因特网上占据统治地位的传输层协议。TCP被设计了许多年，用以在长期存活的点对点连接上高效地交付大的数据块，而没有严格的延迟需求。它作为发送者和接收者之间字节流建模通信，执行流中的每个单独字节的可靠按序交付。

然而，IoT应用程序通常面对着大量的TCP不能有效支持的通信模型。首先，由于能源限制，设备可能频繁进入睡眠模式，因此这对于IoT应用程序维持长期存活的连接是不可行的。第二，许多IoT通信仅涉及很少量的数据，使建立连接的开销不可接受。第三，一些应用程序（例如设备驱动）可能有低延迟需求，这可能不会容忍被TCP握手引起的延迟。当工作在易丢包的无线网络中时，TCP的按序交付和重传机制也带来了队首阻塞，这引入了不需要的延迟。此外，绝大多数无线MAC协议也实现了链路层的自动重传请求（ARQ），这可能极大地损害了TCP的性能，如果二层的重传延迟比TCP RTO大。

当一些工业的IoT标准（例如ZigBee IP）仍然托管TCP支持，越来越多的IoT协议（比如BACnet/IP和CoAP）决定将传输功能植入应用层，并选择UDP作为传输层协议，这本质上将传输层转换到多路复用模块。这种趋势强调了应用层成帧的需要。随着应用层成帧，网络能够识别单独的应用数据单元（ADUs），因此允许更多灵活的传输支持，例如，为不同类型的ADUs应用不同的重传策略，用网内缓存更有效地分发数据等。不幸的是，当前的TCP/IP体系结构不允许应用程序将应用程序语义植入网络层包中，因此不能为应用程序层成帧提供足够的支持。

4   应用层存在的问题

绝大多数IoT应用程序实现面向资源的请求应答式通信模型。例如，模拟应用程序被感知器生成的请求数据；和通过执行器在物理对象上控制应用程序请求操作。这些应用程序类似今天的Web服务，为应用程序层通信采纳了REST（代表状态传输）体系结构。受Web巨大成功的影响，IoT社区致力于将REST体系结构引入IoT应用程序中。例如，IETF core WG定义了约束应用协议（CoAP）标准，一个基于UDP的数据传输协议为约束环境定制，为IoT应用程序提供REST形式的通信。在应用程序层实现REST的需求强调了对于TCP/IP体系结构低层重要功能的丢失的支持，包括资源发现，缓存和安全。在这一部分，我们检测当前的IoT应用程序怎样将那些沟壑和解决方案的限制桥接。

4.1  资源发现

面向资源的通信模型通常需要一种资源发现机制，借此应用程序能够请求或者调用资源上的操作。这个在传统IP网络中资源发现的解决方案是基于DNS的服务发现（DNS-SD）。然而，该解决方案在支持IoT应用程序方面存在几个限制。

首先，DNS-SD目标是支持服务发现，服务通常指的是一个正在运行的程序（例如运行在某台打印机上的打印服务）。相反，在IoT环境中的资源覆盖一个广阔的范围：除了服务，它也可能指的是IoT设备，感知器数据等。因而，IoT资源发现需要更加通用的方法来识别异构资源。例如，除了使用DNS记录，CoAP采纳了一种基于URI的命名方案来识别资源（类似HTTP）。基于此，IETF core WG开发了CoRE-RD，一个基于CoAP的资源发现机制，该机制依赖于更少的约束资源目录服务器来存储驻留在其他设备上的资源元信息。

第二，传统的服务发现通常依赖于多播，专用服务，比如DNS和CoRE-RD在本地环境下并不可用。例如，DNS-SD使用多播DNS（mDNS）作为通信的载体，用于本地网络内的服务发现和名字解析。然而，像我们在2.3节中分析的那样，IoT环境中的本地链路多播存在高效性问题。一个使用多播的替代解决方案是在网络内以点对点形式同步资源元信息（这与我们在2.3节讨论的MPL多播转发协议的精神相似）。例如，IETF homenet WG正在开发家庭网络控制协议（HNCP）来使用被分布式节点一致协议定义的同步机制，以分发家庭网络配置。

我们值得注意那些解决方案的必要性是由于在TCP/IP的网络和传输层不能发现由应用层名字定义的资源的事实。例如，IPv6的邻居发现协议仅能发现网络层和网络层以下的配置；而SRV在DNS-SD中记录，通过IP地址和端口号识别服务。给定IoT应用程序中资源发现的普遍需求，一个有效的IoT网络体系结构应该包含它以作为一个核心功能，使应用程序免于实现他们自己定制的解决方案。

4.2  缓存

TCP/IP通信模型需要客户端（资源请求者）和服务器（资源拥有者）同时处于在线状态。然而，在IoT场景中，为节约能源，约束设备可能频繁进入睡眠模式。此外，动态的断断续续的网络环境使得在通信各方维持稳定连接很困难。这使得IoT应用程序通常依赖缓存和代理来获得高效的数据分发。被选择的代理节点能够请求资源代表睡眠节点，并临时响应数据直到请求节点被唤醒。缓存内容也能够被用来服务来自其他的共享相同代理的节点的相似的请求，这将节约网络带宽并减少响应延迟。提供资源的服务器可能也指定一些代理节点代表自己处理请求（叫做反代理），因此它可以减少客户流量并当需要的时候离线。

当它是有帮助的时候，应用程序级的缓存被CoAP实现，HTTP在IoT环境中存在几个限制。第一，为了利用内容缓存能力，客户需要明确地选择一个转发代理节点或者相反代理节点。那些预配置的缓存点可能不会为所有的客户端节点做优化。客户可能利用资源发现机制按需找到附近的代理。但是这样的解决方案对整个系统引进了额外的复杂性。第二，在动态的断断续续的网络环境中，之前选择的代理点可能完全不可达。当网络拓扑变化时，客户需要重新配置或重新发现代理，或者完全停止使用缓存和代理。第三，缓存和代理打破了被当前的安全协议设定的端到端连接（我们将在4.3节讨论），使得保护应用程序数据变得更加困难。

为使得IoT环境中的缓存功能更加高效和灵活，网络体系结构需要在网络内部普遍提供机会缓存，并允许应用程序利用缓存而没有带来配置和通信的开销。这更需要网络层知道应用层的资源并将缓存集成进转发过程，以便当包在网络中传播时，每个网络包能够访问缓存。我们也需要一种安全模型上的根本改变，以便确保网内的缓存安全和可信。

4.3  安全

由于与物理世界的紧密交互，安全对于IoT应用程序来说至关重要。主流的基于IP的应用程序安全模型是基于信道的安全（例如，TLS和数据报变体DTLS），这在资源服务器和客户端之间提供一个安全通信信道。然而，该安全信道的解决方案因为下面几个原因不适合IoT环境。

第一个基于信道的安全问题是建立安全信道的开销。在第一个应用程序数据被发送之前，TLS和DTLS需要两个或更多轮的安全握手来认证信道并协商安全参数。

第二个问题是信道的两端必须维护信道的状态直到信道被关闭。在一个密集网状网络中，当设备需要同时与许多对等体通信时，这可能对内存使用造成很大压力。注意到该问题，与第一个一起，导致了一种艰难的权衡。缓解一个问题（例如，通过按需建立短暂存活的信道来减少内存）使用可能使其他的问题恶化（例如，每个新的短期存活的信道将拥有握手开销）。

最后一点，也是最重要的一点，一旦应用程序数据从信道中出去，基于信道的安全不能保证请求响应的安全。当中间件（例如缓存和代理）被部署用以缓存应用程序数据，这将是最麻烦的。资源拥有者需要信任中间件来正确执行访问控制策略，当资源请求者需要信任中间件来提供没有篡改的可信数据。

上面的限制强调需要IoT应用程序的一个不同的安全模型。IETF提出的一个替代模型是基于对象的安全，直接保护应用程序数据单元，而不是数据传输的信道。每个数据对象应该携带必需的认证信息（例如数字签名），因此任何接收到数据的人可以核实数据的有效性，而不管怎样获取数据。当我们关心数据的机密性，数据提供者可以加密内容以便只有目的接收者可以解密数据。相似的使用基于对象的安全的想法也在IoT领域之外出现，比如IETF jose WG对于确保JSON对象安全的持续努力。

5   对体系结构的重新思考

著名的间接原则表明计算机科学中的所有问题都可以被另一层间接解决。但是一个没有解决的问题是存在太多间接的层，这精确地描述了当前IoT网络体系结构的状况。

图1显示了基于IP的IoT协议栈的层次化结构。为了支持REST接口，IoT应用程序通常采纳CoAP或HTTP作为消息协议。通常，应用程序也需要与消息层顶部的共同服务交互（比如CoAP资源目录和对象安全支持）。就在传输层上面，TLS和DTLS被增加以确保通信信道的安全。另外，存在多种基础设施服务，来促进IP网络的通信，比如ICMP、DHCP和邻居发现（ND）、DNS和RPL。

如果我们通过聚焦来自应用程序视角的核心功能重新检查网络协议栈，我们将能够获得一个十分不同的图片，如图2所示。代替“everything over IP”,IoT应用程序以一个不同的范式聚集，该范式叫做“everything overREST”.在IoT协议栈底部，IoT协议栈使用数据传输协议，比如UDP和6LoWPAN。在协议栈的中心，一个REST的消息协议实现所有的服务组件，通过IoT应用程序定义的应用程序数据单元的简单抽象操作。新的视角和现存的协议栈层次视图的对比反映了IoT应用程序的期望和TCP/IP体系结构现实之间严重的不匹配。

REST层包含几个实现关键功能的子模块：

（1） 基于URI的通信机制能够将应用程序层的数据交付到网络目的地；

（2） 高效分发数据的缓存机制；

（3） 保护个人ADUs的完整性和机密性的对象安全机制；

（4） 为不同网络环境实现多种算法的拥塞控制模块；

（5） 帮助应用程序操作的名字配置和资源发现；

（6） 将不能适应单独ADU的大数据分块的排序机制；

（7） 一种支持包重传和依据应用程序需求排序的可靠机制。

当前的所有功能（包括REST接口自身）被应用程序层协议实现。然而，如果移入核心网络，一些功能会变得更加高效。例如，拥塞控制有利于网络层和链路层的反馈，以便其做出更明智的决定。如果缓存在网络内部是普遍存在的，而不是依赖于专用的缓存代理，缓存可能更加高效。为了利用网络内缓存，基于URI的转发,REST接口和对象安全也应该被网络层支持，以便缓存内容可以被容易地定位、获取和认证。该协议栈优化最终导致一个更简单的更高效的体系结构，类似于信息中心网络(ICN)。

在ICN体系结构中，比如NDN，不仅仅提供IoT应用程序本质上需求的的功能的本地支持，而且处理低层的网络挑战。该体系结构跨层应用相同的ADU，并将包的流控返回应用程序。没有最小MTU的人为需求；简化的协议栈实际上减少了包头的大小。由于普遍存在的缓存允许数据被多个消费者高效使用，因此它是天生多播友好的。它的面向数据的通信避免了寻址和路由到大量的感知器节点的问题，并为可扩展路由和通过应用层名字转发提供了机会。数据中心安全避免了基于信道的安全解决方案需要的开销，更好地将IoT设备适用于有限的资源和断断续续的连接。体系结构的简化相较于当前基于IP的IoT协议栈，导致了应用程序软件更小的代码大小，更低的能源和设备的内存足迹，更好地利用了网络资源。构建于ICN上的IoT的可能性已经引起了IRTFicnrg的关注，我们期望它变成一个活跃的研究话题，因为对于IoT技术的兴趣持续增长。

6   结束语

当TCP/IP协议栈在20世纪80年代早期被开发出来时，其目标是为了通过有线连接计算机的主帧。尽管协议栈在IP规范被发布后一直在进化，体系结构设计后面的根本假设没有改变。IoT网络代表一种新类型的应用程序，如果没有对协议栈的明显修改，IP体系结构不能容易地适应于IoT网络。

在本文中，我们讨论由网络层和传输层产生的将TCP/IP应用于IoT网络的挑战。我们也讨论应用层协议，比如CoAP怎样为期望的低层不能支持的功能提供他们自己的解决方案。通过将当前的IoT协议栈与从应用程序视角来看期望的体系结构做比较，不匹配更加明显。我们提出了一种体系结构上的改变，将与REST相关的组件移入核心网络层，并最终获得一个对现存的应用层解决方案更有效的体系结构。这种新的IoT栈将拥抱ICN设计并在网络内天然地更高效地实现需要的功能。

参考文献

[1] BACnet - A DataCommunication Protocol for Building Automation and Control Networks, Mar. 2013.

[2] ZigBee IP SpecicationRevision 34. ZigBee Document 095023r34, Mar. 2014.

[3] R. Barnes. Use Cases and Requirementsfor JSON Object Signing and Encryption (JOSE). RFC 7165 (Informational), Apr.2014.

[4] S. Cheshire and M.Krochmal. DNS-Based Service Discovery. RFC 6763 (Proposed Standard), Feb. 2013.

[5] S. Cheshire and M.Krochmal. Multicast DNS. RFC 6762 (Proposed Standard), Feb. 2013.

[6] D. D. Clark and D. L.Tennenhouse. Architectural Considerations for a New Generation of Protocols. SIGCOMMComput. Commun. Rev., 20(4):200{208, Aug. 1990.

[7] S. Deering and R. Hinden.Internet Protocol, Version 6 (IPv6) Specication. RFC 2460 (Draft Standard), Dec.1998. Updated by RFCs 5095, 5722, 5871, 6437, 6564, 6935, 6946, 7045, 7112.

[8] T. Dierks and E.Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (ProposedStandard), Aug. 2008. Updated by RFCs 5746, 5878, 6176.

[9] G. Fairhurst and L. Wood.Advice to link designers on link Automatic Repeat reQuest (ARQ). RFC 3366 (BestCurrent Practice), Aug. 2002.

[10] R. T. Fielding.Architectural styles and the design of network-based software architectures.PhD thesis, University of California, Irvine, 2000.

[11] R. Hinden and S.Deering. IP Version 6 Addressing Architecture. RFC 4291 (Draft Standard), Feb.2006. Updated by RFCs 5952, 6052, 7136, 7346, 7371.

[12] J. Hui and R. Kelsey.Multicast Protocol for Low power and Lossy Networks (MPL). draft-ietf-roll-trickle-mcast-12(work in progress), June 2015.

[13] J. Hui and P. Thubert.Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. RFC 6282(Proposed Standard), Sept. 2011.

[14] IEEE. IEEE Standard forLocal and metropolitan area networks{Part 15.4: Wireless Medium Access Control (MAC)and Physical Layer (PHY) Speci_cations for Low-Rate Wireless Personal AreaNetworks (WPANs). IEEE Std 802.15.4-2006, June 2006.

[15] IEEE. IEEE RecommendedPractice for Information technology-Telecommunications and information exchangebetween systems-Local and metropolitan area networks-Speci_c requirements Part15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs). IEEEStd 802.15.5-2009, pages 1{166, May 2009.

[16] V. Jacobson, D. K.Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard.Networking Named Content. In Proceedings of the 5th International Conference onEmerging Networking Experiments and Technologies, CoNEXT '09, pages 1{12, NewYork, NY, USA, 2009. ACM.

[17] C. A. Kent and J. C.Mogul. Fragmentation considered harmful. SIGCOMM Comput. Commun. Rev.,25(1):75{87, Jan. 1995.

[18] E. Kim, D. Kaspar, C.Gomez, and C. Bormann. Problem Statement and Requirements for IPv6 over Low-PowerWireless Personal Area Network (6LoWPAN) Routing. RFC 6606 (Informational), May2012.

[19] N. Kushalnagar, G.Montenegro, and C. Schumacher. IPv6 over Low-Power Wireless Personal Area Networks(6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. RFC 4919 (Informational),Aug. 2007.

[20] G. Montenegro, N.Kushalnagar, J. Hui, and D. Culler. Transmission of IPv6 Packets over IEEE 802.15.4Networks. RFC 4944 (Proposed Standard), Sept. 2007. Updated by RFCs 6282, 6775.

[21] T. Narten, E. Nordmark,W. Simpson, and H. Soliman. Neighbor Discovery for IP version 6 (IPv6). RFC4861 (Draft Standard), Sept. 2007. Updated by RFCs 5942, 6980, 7048.

[22] E. Rescorla and N.Modadugu. Datagram Transport Layer Security Version 1.2. RFC 6347 (Proposed Standard),Jan. 2012.

[23] G. Selander, J.Mattsson, F. Palombini, and L. Seitz. Object Security for CoAP. draft-selander-ace-object-security-03(work in progress), Oct. 2015.

[24] Z. Shelby, S.Chakrabarti, E. Nordmark, and C. Bormann. Neighbor Discovery Optimization for IPv6over Low-Power Wireless Personal Area Networks (6LoWPANs). RFC 6775 (Proposed Standard),Nov. 2012.

[25] Z. Shelby, K. Hartke,and C. Bormann. The Constrained Application Protocol (CoAP). RFC 7252 (ProposedStandard), June 2014.

[26] Z. Shelby, M. Koster, C.Bormann, and P. van der Stok. CoRE Resource Directory. draft-ietf-core-resource-directory-05(work in progress), Oct. 2015.

[27] M. Stenberg and S.Barth. Distributed Node Consensus Protocol. draft-ietf-homenet-dncp-12 (work inprogress), Nov. 2015.

[28] M. Stenberg, S. Barth,and P. P_ster. Home Networking Control Protocol. draft-ietf-homenet-hncp-10(work in progress), Nov. 2015.

[29] D. Thaler. Multi-LinkSubnet Issues. RFC 4903 (Informational), June 2007.

[30] T. Winter, P. Thubert,A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R.Alexander. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC6550 (Proposed Standard), Mar. 2012.

[31] L. Zhang, D. Estrin, J.Burke, V. Jacobson, J. D. Thornton, D. K. Smetters, B. Zhang, G. Tsudik, kccla_y, D. Krioukov, D. Massey, C. Papadopoulos, T. Abdelzaher, L. Wang, P.Crowley, and E. Yeh. Named Data Networking (NDN) Project. Technical ReportNDN-0001, October 2010.

[32] Y. Zhang, D.Raychadhuri, L. Grieco, E. Baccelli, J. Burke, R. Ravindran, and G. Wang. ICNbased Architecture for IoT - Requirements and Challenges. draft-zhang-iot-icn-challenges-02(work in progress), Aug. 2015.

【NDN IoT】Challenges in IoT Networking via TCP/IP Architecture 全文翻译相关推荐

  1. NDN Link :利用区块链技术代替TCP/IP 通信模式

    运行了近40年的互联网协议通信协议TCP / IP面对当今的互联网需求,已经变成难以增长的绊脚石,当年设计时根本无法想像到今时今日的网络世界.为令互联网可以持续发展,研究人员想要用新的互联网协议取代它 ...

  2. TCP/IP Model: Layers Protocol | What is TCP IP Stack?

    目录 What is the TCP/IP Model? TCP Characteristics Four Layers of TCP/IP model Application Layer The f ...

  3. 【NDN IoT】Caching in Named Data Networking for the Wireless Internet of Things 全文翻译

    Caching in Named Data Networking for the Wireless Internet of Things 研究关于将命名数据网络中的缓存运用于无线物联网 Mohamed ...

  4. IoT五种常见物联网协议：TCP/IP、UDP、HTTP、MQTT、CoAP初探

    对于软件公司来说,IoT模式为其硬件设计以及所提供的服务带来决定性的改变.其中影响最大的一个方面是通信协议. 通信协议可以被认为是一种语言,即两台或两台以上的设备可以相互交流.同时无规矩不成方圆,通信 ...

  5. NDN与TCP/IP

    搬运自http://blog.csdn.net/programmer_at/article/details/49203241  当前TCP/IP协议存在哪些问题?如何改进? 当时没有回答好,然后提到了 ...

  6. 【NDN基础】Named Data Networking 全文翻译

    Named Data Networking 命名数据网络 Lixia Zhang                 kc claffy                 Patrick Crowley A ...

  7. 命名数据网络（NDN）与TCP/IP网络

    之前面试时遇到一个十分有趣的开放性的问题:  当前TCP/IP协议存在哪些问题?如何改进? 当时没有回答好,然后提到了NDN可以针对TCP/IP做出改进,但是在行家面前就漏洞百出,一是对TCP/IP网 ...

  8. HiLink LiteOS IoT芯片 让IoT开发简单高效

    HiLink & LiteOS & IoT芯片 让IoT开发简单高效 华为HiLink & LiteOS & IoT芯片使能三件套,让IoT开发更简单高效.下一代智能手 ...

  9. 【NDN基础】Named Data Networking 学习笔记

    弄懂的问题: (1)Page 4:PIT表的设计考虑: <1>支持多播数据交付. <2>控制流量负载以实现流平衡. <3>PIT条目是路由器负载的指示器,限制PIT ...

最新文章

  1. 【Luogu】P3927 SAC E#1 - 一道中档题 Factorial
  2. 如何步入深度学习刷榜第一重境界
  3. 深入理解Kafka（3）-Consumer
  4. Python(24)-面向对象3-可迭代类对象Pokemon
  5. 5g信号频率是多少赫兹_5G的网速为什么那么快？这得从一个简单的公式说起
  6. xshell 无法定位输入点_机器人抓取汇总|涉及目标检测、分割、姿态识别、抓取点检测、路径规划...
  7. matlab最小二乘法拟合原理,最小二乘法曲线拟合_原理及matlab实现
  8. 一个文字类RPG游戏框架（走过路过别错过）C++
  9. 软件测试自学网站有哪些 ？
  10. android 屏幕没反应了,手机屏幕失灵了怎么办？安卓手机屏幕失灵解决方法
  11. Win10下搭建旷视YOLOX(新一代anchor-free目标检测网络)并训练自定义CoCo格式数据集
  12. 电脑没声音，喇叭上一个叉，显示无法找到输入输出设备（录制，耳机等等）
  13. Creo 产品高级装配视频教程
  14. 综述 | 图像计算传感器
  15. 英语学习详细笔记（三）代名词
  16. 免疫的特异性和非特异性
  17. 如何在百度搜索到自己的网站，加快百度的关键字录入
  18. 解决TeamViewer无法按给定网络地址联系伙伴
  19. VS编译器提示：C4996 ‘scanf‘: This function or variable may be unsafe. Consider using scanf_s instead.的解决方法
  20. linux下npm安装的全局命令无法执行

热门文章

  1. Python3-word文档操作（二）：利用python获取word文档的内容
  2. 震网三代cve_2017_8464漏洞复现
  3. 大学期间，为啥我能学好C语言？只因我做到了这五点！
  4. IDEA查看接口的实现类 快捷键
  5. 分享99个小清新PPT模板，总有一款适合您
  6. Win10-ODI12安装以及本地简单映射测试
  7. 002.计算机核心基础知识2
  8. 读懂8K慢直播对于文旅产业振兴的意义
  9. Chrome内存追踪
  10. git将本地代码推到远程仓库