张丽霞老师写的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应用的角度看