关于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则具有全局的信息。

关于DONA的一些理解与解读_第1张图片

图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层结构,而对传输层有新的要求。

关于DONA的一些理解与解读_第2张图片

图1-2

1.1.4. 内容的注册

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

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

Name

Next Hop

Cost

图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位显然不足以满足未来网络发展要求,或者所,固定长度很难满足内容发展要求。


你可能感兴趣的:(未来网络)