9.4.4 路由机制
低速率无线个域网（WPAN）在诸多特点上与Ad-Hoc网络非常相似，Ad-Hoc网络的路由协议有很多[56]，而AODV[44]（Ad-hoc On-Demand Distance Vector routing，无线自组网按需平面距离矢量路由协议）是其中的典型协议。因此WPAN的路由协议设计可以从中得到一些启发，故本节对AODV协议进行简要介绍。
1.AODV协议简介
AODV协议是基于洪泛的。在Ad-Hoc网络的初始状态，整个网络是静止的，没有任何信息的交互。所以当有连接建立的需求时，洪泛是一种很自然的选择：一个网络节点要建立连接时洪泛广播一个连接建立请求，其他节点转发这个请求消息，并记录源节点和回到源节点的临时路由。
AODV是一种按需驱动的路由协议，它能够在移动节点之间建立动态多跳路由并维护一个Ad-Hoc网络。AODV能让节点快速建立到新目的节点的路由，而且并不需要节点维护处于非活动状态路径的路由。在链路损坏或网络拓扑发生变化时，网络中多个移动节点能够及时做出反应，网络能够快速自愈。当网络链路出现断裂时，AODV能够通知所有受影响的节点，让它们及时删除使用该链路的路由。
AODV一个很重要的特点是对每一条路由使用了一个目的序列号，任何一个路由表项必须包含到目的节点的最新的序列号信息。每一个目的节点在它发送给请求节点的任何路由信息中都会包含这个序列号。使用目的序列号可以保证路由无环路，也利于编程实现。当出现两条路由到达目的节点时，请求节点会选择序列号大的路由。节点收到任何有关报文，只要其中有关于目的序列号的信息，该目的节点序列号都会更新。网络中的节点各自保存和维护自己的序列号。一个目的节点在发送路由请求时会增加自己的序列号，为的是不会与以前建立的到该节点的反向路由冲突。同样，发送路由回复时将自己节点的序列号更新为目前节点的序列号和路由请求中该节点序列号两者的较大值。序列号更新的唯一例外是发现到目的节点的下一跳链路丢失。这时候，对于使用该下一跳的每一条路由，节点都将其目的序列号加1，并将该路由标记为失败。只有再次收到“足够新”的路由信息时（序列号等于或大于该记录的序列号），该节点才会将路由表中相应的信息更新。
AODV定义了三种消息类型：路由请求（RREQ）、路由回复（RREP）、路由错误（RERR）。这些消息包装在UDP报文之中，使用UDP端口号654，并使用通常的IP报头，请求节点使用自己的IP地址作为路由消息中的“源IP地址”字段。
AODV的路由发现算法如下。
（1）源节点：应用层有数据发送请求，并且指向目的节点的路由有效，源节点直接通过该路由发送数据包；如果没有从源节点到达目的节点的有效路径，则产生RREQ广播帧，RREQ的序列号、ID字段加1，将源节点的IP、序列号，目的节点的IP、序列号等信息添加到该RREQ中，广播至网络。
（2）中间节点：如果中间节点路由表中记录的到目的节点的路由有效，并且记录的目的节点的序列号比RREQ中的目的节点序列号更新（大于或等于），则该中间节点可以产生路由应答帧；如果该中间节点不产生应答帧，更改RREQ中的目的节点序列号至当前最大，跳数字段加1，然后转发。
（3）目的节点：目的节点的序列号加1，并产生RREP应答帧（包括源节点的IP、目的节点的IP和更新后的序列号），单播发送至源节点。
对于广播消息，使用IP广播地址255.255.255.255。这意味着这些消息不会被盲目地转发。但是，AODV确实需要某些报文（如路由请求消息）能够大范围甚至在整个网络中泛洪，IP报文的TTL字段可以用来限定传播范围。只要通信的两端有到对方的有效路由，那么AODV并不起任何作用。当节点需要一个到新目的节点的路由时，该节点会广播路由请求进行寻找。当该路由请求到达目的节点，或者一个中间节点具有一个到目的节点的“足够新”的路由时，这条新路由便可以确定下来。当一条到目的节点的路由项序列号大于或等于路由请求中该目的节点的序列号时，这条路由便是“足够新”的路由。具有“足够新”路由的节点会通过单播“路由回复”的方法将该路由信息告诉路由请求节点。每一个收到路由请求的节点都会缓存一个到路由请求源节点的反向路由，这样，“路由回复”便会从最终目的节点或满足请求条件的中间节点顺利传递到请求节点。
节点会一直监测有效路由下一条链路的状态。当监测到有链路发生断裂时，节点会发送路由错误消息来通知其他节点链路已经丢失，需要重新寻找路由。“路由错误”消息用来表明一些节点通过该断裂的链路已经不可达。为了采用这种错误报告的机制，所有节点保存一个“前驱列表”，前驱列表包含一些邻居的源地址，这些邻居节点可能使用本节点作为到达目的地的下一跳。前驱列表的信息可以很容易地在路由回复的时候获取，因为从定义上来说，“路由回复”就是要发送给前驱列表中的节点的。
AODV有自己的路由表管理机制。即使是暂时的路由信息（如到路由请求源节点的暂时的反向路由），也需要在路由表中保存。AODV的路由表由以下几部分组成：目的IP地址、目的序列号、有效目的序列号标志及其他标志（如有效、无效、可修复、正在修复中）、网络接口、跳数、下一跳、前驱列表、生命期（路由表的失效或删除时间）。管理序列号对避免路由环路十分重要，甚至在链路断裂和节点不能提供自己信息的时候也是如此。当链路断裂或失效时，目的节点便处于不可达状态，此时这条路由被标志为失效。
2.RoLL工作组介绍
RoLL——Routing over Lossy and Low-power Networks工作组[29]研究的问题是低功率有损网络的路由问题。研究的目标是以IPv6为中心，修正现有的路由协议或创造一个新协议，使路由能够穿越复杂的基本链路层协议和数目巨大的物理媒体。以解决低功率设备因干扰和移动性等因素导致的容易丢包的现象。
什么是有损链路？有损链路是指有着高BER（Bit Error Rate，误比特率）和均匀错误分布的链路，在有损链路上丢包极为频繁，链路可能会在相当长的一段时间内变得完全不可用，可能的原因有很多，如能量耗尽、休眠及干扰等。这些问题对协议设计的影响很大。实际上，如果链路错误是频繁的并且通常是短暂的，则意味着路由协议不应该对错误过度反应，也不应该在不稳定的状态下试图稳定化。例如，节点A原本选择了节点B作为它优先的下一跳，突然灾难降临了，节点B或者被某个好奇的猩猩抱回窝研究一番，或者被闪电击中了，再者也许节点B的电池能量不足了，总之A和B之间无法连通，那么节点A立即选择节点C作为替代的下一跳并马上重新计算路由表。这不仅会引起路由的不稳定，也会在控制层面产生相当多的数据流，对整个网络产生不良影响。
IETF RoLL工作组于2008年2月成立，属于IETF路由领域的工作组，致力于制定低功耗网络中IPv6路由协议的规范。RoLL工作组的主要挑战之一就是决定工作的范围。与传统IP网络（如核心的服务提供商）相比，低功耗有损网络（LLN）彼此之间可能差异很大。一个用于研究野生动植物的移动的延时可容忍网络（Delay Tolerant Network， DTN），与一个用于工业自动化的密集“全时在线”网络之间可能只有很少的共同点。所以，RoLL工作组的思路是从各个应用场景的路由需求出发，将应用范围划为4个主要领域，并制定了相应的路由需求：家庭自动化应用（RFC 5826）[45]、工业控制应用（RFC 5673）[46]、城市应用（RFC 5548）[47]和楼宇自动化应用（RFC 5867）[48]。这些应用领域可以代表其他类型的网络，如果一个低功耗有损网络的路由协议能够满足这些应用场景的路由需求，就能够满足物联网中的大多数路由需求。
为了制定出适合低功耗网络的路由协议，RoLL工作组首先对现有的传感器网络的路由协议进行了综述分析，工作组文稿draft-ietf-roll-protocols-survey[49]分析了相关协议的特点及不足。然后研究了路由协议中路径选择的定量指标。RoLL工作组文稿draft-ietf-roll-routing-metrics[50]包含两个方面的定量指标：一方面是节点选择指标、包括节点状态、节点能量、节点跳数（Hop Count）；另一方面是链路指标，包括链路吞吐率、链路延迟、链路可靠性、预期传输计数（Expected Transmission Count， ETX）[51]、链路着色（区分不同流类型）。为了辅助动态路由，节点还可以设计目标函数（Objective Function）来指定如何利用这些定量指标来选择路径。
在路由需求、链路选择定量指标等工作的基础上，RoLL工作组研究制定了RPL（Routing Protocol for LLN）协议。RPL协议已于2012年3月形成RFC 6550[31]。
3.RPL协议
RPL是专门为低功耗有损网络（LLN）设计的路由协议，因此其设计出发点是由LLN的诸多特性所决定的。
（1）在LLN中包交付率比较低，链路错误是比较常见的，因而一个节点应该尝试判断一条链路是否失效、是否适合流量转发，同时还要判断一条链路是否应该作为第一条可用链路。因此记住LLN中链路的有损特性，对于理解RPL协议的设计选择是非常有帮助的。
（2）因为资源稀少，控制流量必须严格限制为尽可能少，以节约带宽和能量。因此使用快速探测机制及其他传统的路由协议是行不通的，理想情况下，控制流量应该随着路由拓扑的稳定而减少。节点本身也是受限的，意味着RPL协议不应维护很多状态。因此，RPL被设计为一个距离向量协议，而不是链路状态协议。
（3）由于LLN中节点采集到的信息需要向边界路由器（LBR）汇聚，类似于WSN中信息流量向汇聚点（sink）汇聚，所以RPL中的节点通过交换距离向量创建一个DODAG（面向目的地的有向无环图，Destination Oriented Directed Acyclic Graph），并把一个或多个节点配置为根，即LBR。
RPL使用新定义的ICMPv6消息的节点发现机制来创建DODAG。RPL定义了两种新的ICMPv6消息，叫做DODAG信息对象（DODAG Information Object， DIO）消息和目的地通告对象（Destination Advertisement Object， DAO）信息。DIO消息是由节点发送的，用于通告有关DODAG的信息。当一个节点发现多个DODAG邻居（可能是父节点或兄弟节点）时，它会使用多种规则来决定是否加入DODAG，或从哪儿加入DODAG。这允许通过加节点的方式来创建DODAG。一旦一个节点加入到一个DODAG中，它就会拥有到DODAG根的路由，用来支持从叶节点到DODAG根的MP2P（多点到点）流量（方向向上）。
PRL使用“上”和“下”表示方向术语，向上表示从叶到DODAG根，向下则相反。PRL也使用表示父、子的通常术语。DODAG中，一个节点的父节点是向上的直接后继，而DODAG兄弟节点指的是相同级别的节点。如果DODAG连接到一个与外部IP专网或互联网相连的节点，RPL称为“终点”（Goal），那么它被认为是连网的。反之，一个非连网的DODAG被称为“漂浮的”（Floating）。
至此DODAG已经为网络中的每个节点提供了到DODAG根的默认路由，现在需要一种机制对下行（从根到叶）的流量提供路由信息。RPL使用DAO消息向叶节点通告前缀可达性。DAO携带前缀信息及生命周期（用来判断目的地通告的新鲜度）和深度（用来确定目的地有多远的路径成本信息）。注意，这个方向的路径是由RPL在另一个方向创建的DODAG所规定的。在一些情况下，DAO也会记录访问过的节点集合。当中间节点不能存储任何路由状态时，这将非常有用。如果父节点收到可以从多个子节点聚集的目的地通告，可以使用本地策略来执行前缀聚集，以减小路由表和DAO消息的大小。注意，冗余的DAO消息是沿着DODAG聚集的。
RPL协议支持3种类型的数据通信模型，即低功耗节点到主控设备的多点到点（MP2P）的通信，主控设备到多个低功耗节点的点到多点（P2MP）通信，以及低功耗节点之间点到点（P2P）的通信。注意，此处的P2P是point-to-point的缩写，指LLN中任意两台节点设备。当节点A向节点B发包时，如果B不是直接可达的，它会把包转发给它的DODAG父节点。对于父节点，如果目的地从它的一个子节点是可达的，那么它把包向下转发给那个子节点，如果它所有子节点都不可达，那么它继续向其父节点转发，如此重复（注意这是向上的），直到某个节点的子节点可达目的地，这个包才会向下转发。
DIO和DAO消息的发送是用“滴流”定时器管理的。“滴流”定时器使用动态的计时器，管理RPL控制消息的发送，以减少冗余信息。当DODAG不稳定时（如DODAG正在重建），RPL控制信息将会更频繁地发送。另外，当DODAG变得稳定时，消息发送会减少，以降低控制层面的开销。这种“滴流”机制在LLN中是很重要的，可以极大地限制RPL的控制信息流，以节约能耗和链路开销。
DIS消息（DODAG Information Solicitation）与IPv6路由请求消息相似，用于发现附近的DODAG和从附近的RPL节点请求DIO消息。DIS消息没有附加的消息体。
4.RPL DODAG创建过程
下面讨论在RPL中创建DODAG的操作方式。DODAG的构成遵从以下规则：避免回路的RPL规则、通告的OF（目标函数，Objective Function）、通告的路径度量、已配置节点的策略。
DIO消息在“滴流”定时器到期时发送。当检测到DODAG的不一致性时，节点会重启它的“滴流”定时器，以使DIO消息的通告更为频繁。随着DODAG的稳定，检测不到不一致性，DIO消息的发送会减少，以控制流量。这里，DODAG的不一致性是指DODAG的参数更新或检测到回路。
当一个节点开始它的初始化过程时，它或许会一直保持沉默，直到它收到一个DODAG通告的DIO消息。或者，节点可能发送DIS消息来探测邻居节点，这样就可以更快地从邻居节点收到DIO消息。另一个选择是创建它自己的DODAG，然后开始为它的DODAG多播DIO消息。发送单播DIO用于答复单播DIS消息，并且也会包括一个完整的DODAG配置选项集合。
收到一条DIO消息后，节点必须首先确定这条DIO消息是否应该被处理。如果DIO消息是错误的，它应该被直接丢弃；如果消息是正确的，节点必须判断这条DIO是否是由候选邻居发送的。候选邻居的概念与本地信任的概念是紧密耦合的，这个重要的概念是由具体实现决定的，用于判断一个节点是否有资格被选为父节点。例如，当一个节点初次监听到一个邻居节点，它或许会选择等待一段时间，以确定连接它们的链路是足够可靠的。
然后，节点判断DIO消息与其加入的DODAG的相关性。
如果发送DIO消息的节点级别（Rank），比接收到DIO消息的节点级别加上最小级别增量（DAG Max Rank Increase）之和还小，那么这条DIO消息会被处理。如果DIO消息是由更低级别节点发出的，并且DIO消息通告了一个能提供更好路径的DODAG，那么这条DIO消息必须被处理。
如果DIO消息是由一个DODAG父节点发起的，到另一个不同的、节点不属于其中的DODAG，那么它必须被处理。因为DODAG父节点或许已经跳到另一个DODAG中了。
如果两个节点同时向对方发送DIO并且决定加入对方，那么可能会发生碰撞。这就是在风险窗口时收到的DIO消息不会被处理的原因。由于“滴流”定时器的随机效果，接来下发送的DIO消息不太可能再次碰撞。
下面介绍一个具体的实例。
DODAG创建过程。图中展示了LLN的物理拓扑和DODAG的创建步骤。链路度量是ETX， OF是找到使路径ETX最小的路径，就是所有经过的链路ETX总和最小。OF还规定了一个避免电池供电节点的附加限制，级别是基于跳数的。注意，OF是不同的。
第一步：DODAG根开始发送链路本地多播DIO消息。事件可能按下面的顺序发生。其中一个节点可能也会发送DIS消息，这种情况下DODAG根（LBR）应该立即发送DIO消息以答复DIS消息。
第二步：节点11、节点12、节点13收到LBR的DIO。处理完DIO后，节点11、节点12、节点13选择LBR作为它们的父节点（注意：节点12和节点13可能需要等待一段时间来建立足够的本地信任）。这时，节点11、节点12、节点13基于跳数计算它们新的级别，并计算路径ETX值。节点11还选择了节点12作为它的兄弟节点，反之亦然（相同级别）。
第三步：展示了另一轮迭代后形成的DODAG。注意：链路22—11已经被从DODAG中删除掉，因为考虑到OF（最小化路径ETX），节点12是一个更好的父节点。节点23选择了两个路径成本相等（ETX=3.3）的父节点。
第四步：展示了最终的DODAG。由于OF规定了不能经过电池供电节点，节点46没有把节点35选为最优的父节点。本地策略可能会用于指示OF限制是否也需要应用到兄弟节点上（此例中，节点34确实选择了35作为兄弟节点）。一个潜在的兄弟回路33—34—35—33形成了（后面的回路避免继续讨论）。
5.RPL中的回路避免机制和回路检测机制
路由协议的目标之一就是尽量避免回路的形成。下面来看一下RPL的相关机制。
在高速网络中，包的TTL在每一跳都会递减，这样回路上的包很快就会被丢弃，即使回路很短。在高数据传输速率的情况下，即使很短的回路也可能导致丢包和链路拥塞。但是，在LLN中，情况有些不同。首先，LLN流量速率相对较低，所以一个临时回路的影响可能很有限。其次，在不稳定的情况下，不能过度反应，这是非常重要的。与“快速反应（重汇聚）”的传统网络相反，在LLN中不能过快反应，因为可能存在回路。所以必须尽可能地避免回路，并且当回路产生时将其检测出来。RPL不能从根本上保证消除回路。这意味着要在控制层面上使用开销很大的机制，并且这可能不太适合有损耗的和不稳定的环境。RPL使用通过数据路径验证的回路检测机制作为替代，尽量避免回路。
1）回路避免机制
RPL制定了两条规则来进行回路避免。
（1）最大深度（max_depth）规则。一个节点不允许选择一个级别比它的级别加最小级别增量（DAG Max Rank Increase）还大的节点作为父节点。
制定此规则的主要原因是，减小节点连接到另一个属于它自己的子DODAG上的节点的风险，因为这可能会导致计数到无穷的回路。例如，如果节点24丢失了它所有的父节点，然后选择节点46作为父节点，因为从节点46到根的路径是经过节点24的，一个回路就形成了。并且节点24没有办法知道节点46实际上属于它自己的子DODAG。注意，最大深度（max_depth）规则不能防止回路的产生，但它可以限制回路的大小，并且可以检测出这样一个回路而不用等到计数到无穷。
（2）节点不应该是“贪婪”的，即不能为了获得更多的父节点而向DODAG的纵深移动。假设节点22和23的级别都是3，共享一个相同的父节点12，它们之间有一条可用链路22—23（它们是兄弟节点）。假设节点22和23都想要增加可用的后继集合，以便在与父节点之间的链路发生故障时拥有备用的路由，如通过在可控方式下脱离然后向下移动。假设22首先决定选择23和12作为DODAG父节点，这时22新的级别为4（选父节点中最高的级别）。然后23没有遵守RPL规则，并且处理从22（级别比自己高）接收到的DIO消息，于是23可以选择12和22作为DODAG父节点，从而把它的级别增加到5。然后节点22重复这个过程直到计数到无穷。
然而，即使有前面所说的回路避免机制，DODAG里在很多情况下还是会产生回路。一种可能的回路类型就是兄弟回路。再次考虑，加入到根的多条链路（如35—24，34—24，33—23）发生故障，从节点35发送到LBR的包很可能出现回路（35—34—33—35），因为兄弟节点按定义级别是相同的。如果只有一条链路发生故障，如35—24，节点35把指定到根的包重新路由到节点34，然后包会被节点34转发到根而没有回路。但是像上面说的多个故障的情况，就可能会发生兄弟节点回路。
2）回路检测机制
前面说明了路由回路是很难避免的，因此必须有路由检测机制。路由检测机制通过在数据包的包头设定标志位来附带路由控制数据。
例如，当包被重路由到兄弟节点上时，在包头设置一个标志位，以标志这个包已经被转发到兄弟节点上。当到达下一跳时，如果因为到根没有可用链路而需要把这个包再次转发到另一个兄弟节点，则这个包会被丢弃。例如，DAO回路可以通过使用一个“向下”位来检测。当一个包向下发送时，这个位设置为1。当节点收到一个“向下”位为1的包后，其路由表指示要向上发送它，则会产生DODAG的不一致性，就可能有回路，此包被丢弃。同时，不一致性触发了“滴流”定时器的重置。
6.RPL的“滴流”定时器
定时器管理是任何一个协议的重要组成部分，RPL也不例外。“滴流”机制（Trickle）是RPL不同于其他路由协议的另一个重要组成部分。RPL协议工作在较低限制的环境中，因为在LLN网络中构成网络的节点必须要考虑节能问题，因此当务之急是尽量限制RPL的控制流。大多数路由协议通过发送周期性的连接保持消息来维持路由邻居和路由表更新，不必显式地限制控制信息。但在LLN网络中资源是非常有限的，因此RPL采用了一种自适应机制，叫做“滴流”定时器（Trickle Timer）。它的工作原理很简单：当网络出现循环或DODAG的参数发生变化时，即检测到不一致性时，定时器就重启到一个最小值，RPL控制消息会更频繁地发送；随着网络的稳定，定时器将周期倍增至最大值，RPL控制消息就会逐渐减少。
7.RPL小结
RPL路由协议是IETF ROLL工作组为低功耗有损网络设计的高效的距离向量路由协议，通过一系列的新机制设计，支持LLN的MP2P、P2MP、P2P流量。RPL被设计成高度模块化的，它只有很少的封装，能够在受限环境中运行，根据不同的环境支持多种度量和限制，从而尽可能地减少控制流量。RPL通过回路避免和回路检测及“滴流”机制，动态维护路由的稳定，减少振荡的发生，保证了高度的健壮性和灵活性。
9.4.5 TCP/IP协议栈的简化
Berkeley Unix中标准TCP/IP协议栈具有上万行的代码量，开销大，物联网节点无法支持，需要将TCP/IP协议栈简化。简化的TCP/IP协议栈也称为轻量级TCP/IP协议栈，其主要目的是减少存储器利用量和代码量，使IP适合应用于小的、资源有限的处理器，并能与运行标准TCP/IP或其他简化的TCP/IP的系统互相通信。
现有的几种简化TCP/IP协议栈有uC/IP[52]、TinyTCP[53]、LwIP[54]、uIP[55]等。此外，IETF已于2011年1月成立LWIP工作组，致力于建立一个精简的TCP/IP协议栈的标准。以下分别进行简要介绍。
1.uC/IP
uC/IP是由Guy Lancaster编写的一套基于uC/OS且开放源码的TCP/IP协议栈，也可移植到其他操作系统，是一套完全免费的、可供研究的TCP/IP协议栈，uC/IP大部分源码是从公开源码BSD发布站点和KA9Q（一个基于DOS单任务环境运行的TCP/IP协议栈）移植过来的。
uC/IP具有如下一些特点：带身份验证和报头压缩支持的PPP协议，优化的单一请求/回复交互过程，支持IP/TCP/UDP协议，可实现的网络功能较为强大，并可裁减。
uC/IP协议栈被设计为一个带最小化用户接口及可应用串行链路网络模块。根据采用CPU、编译器和系统所需实现协议的多少，协议栈需要的代码容量空间在30～60KB之间。
2.TinyTCP
TinyTCP栈是TCP/IP的一个非常小的简单实现，其初衷是为固化到ROM而设计的，并且现在开始支持大端结构（初始目标是68000个芯片）。TinyTCP包括一个FTP客户，一个简单的以太网驱动器用于3COM多总线卡。
3.LwIP
LwIP是由瑞典计算机科学院（Swedish Institute of Computer Science）网络嵌入式系统小组的Adam Dunkels等开发的一套用于嵌入式系统的开放源代码TCP/IP协议栈。LwIP的含义是Light Weight（轻型）IP协议，相对于uIP（micro-IP，微型IP协议）。LwIP可以移植到操作系统上，也可以在无操作系统的情况下独立运行。LwIP中TCP/IP实现的重点是在保持TCP协议主要功能的基础上减少对RAM的占用，一般它只需要几十千字节的RAM和40KB左右的ROM就可以运行，这使LwIP协议栈适合在低端嵌入式系统中使用。
LwIP的特性如下：支持多网络接口下的IP转发，支持ICMP协议，包括实验性扩展的UDP（用户数据报协议），阻塞控制，RTT估算和快速恢复和快速转发的TCP（传输控制协议），提供专门的内部回调接口（Raw API）用于提高应用程序性能，并提供了可选择的Berkeley接口API。
uIP同样是Adam Dunkels开发的，其源代码用C语言编写，并完全公开，可移植到各种不同的结构和操作系统上。uIP是专门为8位和16位微处理器嵌入式系统设计的一个极小的TCP/IP协议栈，一个编译过的栈可以在几千字节的ROM或几百字节的RAM中运行。uIP协议栈去掉了完整的TCP/IP中不常用的功能，简化了通信流程，但保留了网络通信必须使用的协议，它实现了TCP/IP协议集的4个基本协议：ARP地址解析、IP网际互联协议、ICMP网络控制报文协议和TCP传输协议，保证了其代码的通用性和结构的稳定性。
9.4.6 CoRE
资源受限IP的网络情况是指包大小受限，较高的丢包率，设备随时断电，设备周期性唤醒，节点吞吐量有限、电量有限、内存受限。IETF的CoRE（Constrained RESTful Environments）工作组提供一个面向IP网络资源受限的应用程序架构，基于该架构应用程序可以操作一些简单资源。
2010年3月，CoRE工作组正式成立，属于应用领域（Application Area）。CoRE起源于6LowApp兴趣组（BOF），主要讨论受限节点上的应用层协议。随着讨论的深入，IETF技术专家把工作组的内容界定在为受限节点制定相关的REST（Representational State Transfer）形式的协议上。REST是指表述性状态转换架构，是互联网资源访问协议的一般性设计风格。REST提出了一些设计概念和准则：网络上的所有对象都被抽象为资源；每个资源对应一个唯一的资源标识；通过通用的连接器接口；对资源的各种操作不会改变资源标识；对资源的所有操作是无状态的。HTTP就是一个典型的符合REST准则的协议。在资源受限的传感器网络中，HTTP过于复杂、开销过大，因此需要设计一种符合REST准则的协议，这就是CoRE工作组正在制订的CoAP[33]（Constrained Application Protocol）。
应用CoAP之后，互联网上的服务就能直接通过CoAP或通过HTTP与CoAP之间的网关来进行资源读取、修改、删除等操作，节点和网关的协议栈都是建立在IPv6和6LoWPAN协议栈之上的。显示了CoAP在传感器、网关、互联网服务器上的呈现。其中，显示了CoAP通过网关与HTTP进行转换的方式，显示了传感器节点直接与支持CoAP的互联网服务器进行信息交互的方式。在这两种方式中，节点和网关的协议栈都建立在IPv6和6LoWPAN协议栈之上。
除了CoAP，资源受限环境中的资源发现、安全、API等都在工作组的工作范围之内，相关的工作正在积极地展开。
9.4.7 小结
本节由下而上对物联网的典型协议栈进行了简要介绍，从著名的低速率无线个域网标准IEEE 802.15.4到新兴的ZigBee协议；并重点介绍了基于IPv6的低速无线个域网标准——6LoWPAN适配层，旨在将IPv6引入以IEEE 802.15.4为底层标准的无线个域网中；然后对物联网的路由机制进行了详述，以Ad-Hoc网络的经典路由协议AODV为开端，启发式地引出了ROLL工作组专门为低功耗有损网络（LLN）设计的RPL路由协议，重点介绍了其网络拓扑的创建过程和回路避免、回路检测及“滴流”机制，并做了简短的小结；而后对现有的几种简化的TCP/IP协议栈uC/IP、TinyTCP、LwIP、uIP分别进行了简要介绍；最后对IETF的CoRE工作组及其致力研究的受限节点上的应用层协议CoAP做了简要介绍。至此，已经展现了物联网典型的协议栈结构，为进一步的研究工作提供了参考。
