读《Challenges in IoT Networking via TCP/IP Architecture》笔记

张丽霞老师写的NDN+IoT领域必看的两篇综述之一

小小感受：将应用层普遍需要的功能下放到网络层来做是有必要的，那要使网络层能实现这些功能，需要的就是网络层对内容的感知，NDN的数据命名其实就是使得网络层对应用层的内容感知很容易实现。

网络基础知识还是差，有时间撸一遍《TCP/IP详解：卷一》吧

一、网络层的问题

1.small MTU：

• IPv6有两大限制：头部长度至少40字节；要求链路MTU至少为1280字节

• IoT的链路层协议帧长小：IEEE802.15.4为127字节

为了克服链路层和网络层MTU不适配问题，引进了6LoWPAN协议，相当于在链路层和网络层中间加入了一个适配层，这个适配层提供了两大功能：IPv6头部压缩；链路层分片。

2.multi-link subnet

本质是老的IP子网模型与IoT环境下mesh网络之间的不适配问题。（这个问题还不是很理解，后续参看RFC4903）

• 多链路转发在multi-link subnet环境下，无法正确控制包的TTL/hop limit
• link scope的广播在multi-link subnet环境下将需要multicast rooting的支持（目前的网络没有multicast rooting功能）

解决方法：

• 依靠链路层将多个链路透明地组合成一个网络（但这又需要跨子网路由协议的支持）
• 将mesh网络切分成以不同prefix命名的子网（配置prefix带了复杂性；无法适应动态变化）

3.multicast efficiency

广播被广泛用来支持两大场景：通知一群用户；询问目标不明确时。但在IoT mesh网络下支持广播功能很有挑战性：

• 多数无线MAC协议不回应广播包，因此广播包的丢包无法在链路层被恢复
• 由于不同MAC协议的存在或者链路层速率调整，不同链路上广播包的传输速度不一样，因此发送者要以最低速率来发送广播包
• 休眠的节点会错过广播包
• 在mesh网络中广播会唤醒很多节点，造成能耗过大

解决方法：

• 尽量减少multicast的使用；如果一定要用multicast，那么可以将multicast包发到特定的公共节点，供其他节点在不休眠的时候去取；向公共节点发请求以代替multicast，公共节点事先要收集信息。
• 例如：6LoWPAN的邻居发现机制，MPL

4.mesh network routing

在multi-link环境下维护路由信息完全靠IoT节点而没有infrastructure支持是很困难的。

IoT场景的拓扑可以归为两类：

• 星型拓扑：覆盖范围小
• p2p(mesh)网络：覆盖范围大，路由复杂

p2p(mesh)网络的路由可以分为两类：

• 链路层路由（mesh-under）：802.15.5（缺点是对于拓扑变化要重新计算）
• 网络层路由（route-over）：RPL

二、传输层的问题

TCP适合在长时间维护的通道中传输大量数据，并且提供拥塞控制和可靠传输。

TCP在IoT中不适用的原因：

• 维护传输通道对于会休眠的IoT节点不适用
• IoT要传输的信息一般是少量的，不必要维护传输通道
• IoT的时延要求高，TCP的握手环节会增大时延
• IoT的网络环境复杂，TCP执行按序交付所造成的重传会进一步增大时延
• 大多数无线MAC协议执行链路层自动重复请求，这进一步造成TCP的超时重传（RTO）

越来越多的IoT协议将TCP提供的功能放到应用层去实现，在传输层采用UDP，如BACnet/IP和CoAP。

呈现出对application level framming的需求，允许应用层给包打标签，对不同标签的包，网络层提供不同类型的服务。但是TCP/IP不允许将应用层的语义带到网络层，因此无法支持application level framming（这就是NDN能干的事了）

三、应用层的问题

1.resource discovery

传统IP网络所使用的资源发现的方法是基于DNS的，这类方法在IoT场景不适用的原因：

• 基于DNS的资源发现机制中的资源一般指服务（一个正在运行的程序），在IoT场景下，资源包括服务、物联网设备、数据等，范围更广。因此CoAP采用基于URI的命名机制，CoRE-RD将元信息存储在一个资源更不受限的节点。
• 在资源发现服务不可用的时候，转而使用广播在IoT环境是不可取的，一个替代的方法是使用同步机制（如HNCP）

应用层之所以需要复杂的资源发现机制，就是因为网络层和传输层无法根据应用层定义的名字进行资源发现。既然IoT环境下对于资源发现的要求是普遍的，那就应该考虑在网络层提供这一功能。（NDN）

2.caching

应用层缓存在IoT环境有很多局限性：

• IoT节点需要显式地选择代理节点（缓存节点），要么预先配置（可能不是最优代理节点），要么临时选择（增加通信负担）
• 拓扑变化时，原先配置的代理节点可能不可达
• 代理节点的引入打破了原先端到端的安全机制，带来安全隐患

在不增加IoT节点通信和配置负担的前提下利用缓存：将缓存集成到网络层，同时需要一个新的安全机制。

3.security

基于通道的安全机制（如TLS和DTLS）不适合IoT场景的原因：

• 建立安全通道的握手环节带来额外的负载
• 维持通道信息消耗IoT资源
• 无法保证数据出通道之后的安全

解决方法：将基于通道的安全改为基于内容的安全

四、IoT协议栈

TCP/IP架构下的IoT协议栈

从IoT应用的角度看