关于DONA的一些理解与解读

注意：本文为原创内容，欢迎并仅限于进行学术讨论的范畴，禁止应用于任何商业或项目性行为，否则将承担相应的法律责任！

最近在系统性研究ICN体系架构。想把影响力比较大的DONA、NetInf、CONET、COMET、PURSUIT等架构都梳理一遍，了解每个架构的原理，解决的问题以及优势和劣势所在，供大家分享以及自己反思所用。

1.    DONA

最先拜读的还是ScottShenker大神领导的DONA项目的代表性论文 AData-Oriented (and Beyond) Network Architecture, 发表在2007年的Sigcomm上。

1.1系统架构

DONA的系统架构在当时来讲是比较超前的，提出的主要方案是在网络层与传输层之间构造一层内容层，用于内容的寻址与传输，IP层为内容提供传输服务，而内容层则可以屏蔽底层差异，为上层提供统一的服务接口。

1.1.1. 基本元素

具体来讲，DONA网络中存在着三种基本的网元——内容的请求者，内容的发布服务者，RH（Resolution Handler）三种网络元素，这三种元素构成了网络连通与通信的主体。内容的请求者与发布服务者顾名思义，不需过多解释，所谓的RH指的的是内容的解析网关，能够将用户请求的内容解析为具体的转发行为，是三种网元中的核心部件；同时，为了能够实现基于内容的互联互通与可达性，DONA需要两种信息来维护网络与节点的状态并进行路由转发——Find以及Register两种消息，Find消息主要是由内容的请求者向网络发出针对具体内容的请求，而Register则是由内容的提供者向网络注册自己所拥有的内容，以便为网络中的其他用户提供内容服务。注意，Find与Register信息通常都要经由RH，Find信息通过RH进行路由与转发，最终到达内容的请求者；Register信息则由内容服务提供者发送给RH，登记自己的内容归属情况，RH再将该信息扩散到网络中的其他RH节点中去。

1.1.2. 网络组织形式

网络的基本组织形式如图1-1所示。从图1-1中我们可以看到，DONA网络是以RH为标准进行分级的，分级的依据可以是自治域，也可以是其他的标准。最低级别的RH主要负责接入用户的请求信息Find，将用户的内容请求转化为转发动作，不同层级的RH看可以理解为不同层级的DNS服务器，最高层的RH则具有全局的信息。

图1-1 DONA网络组织形式

1.1.3. 内容的命名

为了实现针对内容的路由与转发，需要对内容进行适当的命名，这也是ICN系统设计的过程中的关键技术。总体上来讲，ICN命名方式有两大种，层级式命名架构与扁平式的命名架构，DONA选择的是后者，名字的形式为P:L, 其中P为内容提供者的公钥的哈希值，用户验证内容提供者的身份，L为名字标签，是对内容的具体描述，并且L描述的粒度可以由用户灵活掌控，可以描述一个网站，也可以描述一个网页或者一个视频，只要内容提供者保证在P的前缀下L是唯一的即可。

除了上述标准的命名之外，DONA还支持P：*以及*：L的命名格式，前者可以用于校验前缀是否被占用，后者可以用户描述任意内容服务提供者提供的L内容或服务。

关于内容名在网络协议栈中所处的位置，可见图1-2。从1-2中可以看出，Name层所处的位置是网络层与传输层之间，也就是说Name不改变IP层结构，而对传输层有新的要求。

图1-2

1.1.4. 内容的注册

DONA以及其他ICN网络架构中，内容想要被访问，必须在网络中是可达的。DONA的实现方式是在让内容服务提供者在网络中注册其所能提供的内容，这就涉及到前文所提到的Register消息，内容服务的提供者针对其所提供的内容向其所归属的RH发送Register（P:L）信息，这样本地的RH就知晓了内容以及内容提供者的存在，并且会向其Parent RH（以及Peer RHs）报告相应的信息，这样就实现了内容在网络中的注册。

每个RH节点都会维持一张命名转发映射表，形式如图1-3所示：

图1-3 命名转发映射表

Register信息在RH节点的更新有一定的规则，RH只有在收到之前没有收到的内容的Register信息或者是对同一内容距离更近的Register信息时才会更新本地的内容信息表。

1.1.5. 内容请求的转发

内容请求的转发主要涉及到两个方面，内容请求的格式，另一个是节点的转发策略。

首先看请求的格式，内容的请求需要内容请求者发送Find(P:L)消息, 这个消息的内涵就是请求内容提供者P提供的内容L。同时，内容请求者也可以发送Find(*:L)消息，这样就可以请求L内容，而不关注到底是具体哪个服务提供者提供的内容。

当内容请求者构造好自己的请求之后，将自己的请求发送给其关联的本地RH，本地RH查询自己的命名映射表，进行最长前缀匹配，找到当前最匹配的条目，进行转发；一旦出现两个相同长度的匹配条目，则根据到内容源的距离或者是代价选择较小的一个进行转发。对于在本RH下的内容，直接转发给对应的内容服务提供者，由其返回内容，如果是在其他RH的控制下，则将该Find信息转发给对应的RH。如果在本地RH没有找到用户请求的内容的转发动作，则将请求转发到其Parent RH上，由Parent RH进一步进行路由与转发决策，如此循环迭代，，如果到了第一层（图中所示Tier-1）RH仍旧不能找到的话，就向用户返回报错信息。

注意，论文中并没有提到在同一个RH管理下，内容应该如何返回给用户。

1.2.  系统功能

论文中提到了很多的关于DONA的应用，包括多播、缓存、文件传输、DTN（Delay Tolerant Network） 等，但是我重点关注并觉得有的可说的是跨域转发，这个涉及到DONA的很多新特性，也需要对网络的特性进行拓展。

DONA提出的跨域转发策略可以有效地节约IP地址资源，因为内容是绑定在RH上的，而RH的规模远小于整个内容数量或者主机数量的规模，因此可以在RH上使用共有地址，而在RH管理的域内大量使用内部地址。但是这样的问题是，虽然可以实现内容的定位，但却没有办法将内容返回，为了解决这个问题，DONA新增加了一个字段叫Path-Label，用于记录经过的路径，但是因为使用的是内部的地址，没有办法做到全局可通，因此，在跨域的时候，Path-Label就会加上跨域的信息，这样，域的信息加上内部地址的信息，就可以实现从内容请求者到内容服务提供者之间路径的唯一确定。也就可以实现内容的双向传输。

1.3.  系统弊端

系统弊端的总结少一点，主要是：RH的负担过重，需要承担大量的解析任务，越到顶层负担越重；固定长度命名带来的问题是可扩展性问题，IP地址是32位已经耗尽，内容名的规模将从数量级上远大于IP地址，仅仅40位显然不足以满足未来网络发展要求，或者所，固定长度很难满足内容发展要求。