ICN报告

一、绪论
互联网获得了巨大的成功，但成功的背后却是危机。

随着数据应用的日益复杂化、海量化，IP架构的固有缺陷日益突出，严重影响着网络生态系统，难以适应未来信息化的需求，具体表现有以下几点：
1) 互联网流量增长超摩尔定律，路由表庞大，网络可持续发展面临严峻的挑战。

器件的性能已接近极限，目前的硬件架构难以适应流量高速增长的网络，网络稳定性不断下降，域间路由的收敛不断变慢，路由表的增长也对硬件性能提出严峻的挑战。

2) 互联网安全缺乏系统性的解决方案。

互联网的架构本质是被动的安全防范架构，每年因互联网安全而造成的损失高达数千亿美元。

TCP/IP作为原始网络协议在提出之初，旨在利用可信任的固定主机对可信任的用户提供远程接入以实现信息共享，但随着网络的扩展，主机和用户逐渐不再完全信任，此时为了实现需求则需要更多的中间件如补丁，附件等。

3) 当思路从基于位置的系统转变到基于信息的系统，出现了IP模型，它建立了两个地址间的连接。

而服务器承载了大量不相干的数据,大量信息冗余，造成存储资源浪费。

4) 为了使协议适用于网络需求，在原始TCP/IP协议中添加了更多添加项增加了复杂性。

5) 动态性问题，互联网终端形态发生了很大变化，动态性显著增加，移动终端流量占网络流量的比重日益增加；物联网等低智能终端的数量爆炸式增长；IP地址既表征身份又表征位置，导致对移动性支持能力不强。

6) 互联网设备制造工艺复杂，发热量大，导致其相配套的动力设备增多，能源消耗巨大。

未来网络应是低能且无污染的。

信息中心网络，Information-Centric Networking(ICN)的思想：一切都是信息，信息互联而不是主机互联；通过信息的名字标识每一个信息，与信息的地理位置无关；网络的作用就是管理所有信息的流动和缓存，并用正确的信息快速响应信息的请求者。

ICN采用信息名字为网络传输的标识，IP地址不被考虑或者只作为一种底层的本地化的传输标识。

传统体系结构的通信模式是主机之间的通信，通过源主机地址和目的主机地址获取通信路径，ICN则采用主机到网络的通信模式，通过信息名字获取源主机到网络信息的通信路径。

IP网络体系结构的传输模式是“推”模式，由服务器主导传输。

无论你是否感兴趣，服务器的信息都可能传到你的主机上。

ICN则采用“拉”模式，用户实时向网络发送请求信息，由于网络可能已经缓存了该信息，网络可以把信息回应给用户。

“拉”模式更适合海量信息的情况。

二、ICN关键技术
1 信息命名
在ICN中，信息名字是信息的唯一标识。

从用户请求开始，信息就作为请求的对象，信息名字必然作为请求分组的一个重要字段。

路由过程中，信息名字成为寻址的唯一标识。

传输过程也是基于信息名字进行传输。

信息命名应该满足四类性质，即可聚合性、持久性、自我验证性和全局唯一性。

可聚合性是指信息名字可实现汇聚，如IP网络中的IP地址，最后可聚合到地址前缀。

可聚合性是信息命名的重要特性，信息是海量的，若信息名字不能聚合，路由表膨胀速度将远远超过IP网络,导致ICN网络可扩展能力更差，可聚合性可大大缩小路由表项数，保证可扩展性。

持久性是指无论信息所在主机改变，还是信息所在主机位置改变，信息名字始终一致，不因信息的移动而发生改变。

在IP网络中，若主机位于不同的自制系统automation system(AS)内，其分配到的IP地址与AS所属的地址段相关。

IP网络中主机发生移动时，相应的IP地址则要发生改变，导致了移动性问题。

在ICN中，信息命名在设计时必须考虑移动性问题，因此提出了持久性的性质要求。

一般而言，持久性要求信息名字具有扁平性，如哈希值，因此可聚合性和持久性是一对矛盾，怎么能够合理地整合这对矛盾是信息命名的重要研究内容。

自我验证性是指信息名字本身具有安全验证功能，通过与其他数据的计算，可验证信息是否完整、真实、安全，从而更快速、简洁地实现信息的安全性验证。

在ICN中，安全性是直接针对于信息本身
的，IP网络则是针对主机的，主机可能是安全的，但信息不一定是安全的。

ICN安全性验证更加合理。

全局唯一性是命名的最基本的性质，指信息名字是信息的唯一标识，一条信息具有一个信息名字，一个信息名字定义一条信息。

如IP地址一样，信息名字是ICN传输和寻址的标志，若出现不唯一的情况，必然造成网络冲突和混乱。

目前主要存在两种命名方式。

第一种是分层命名，便于理解、记忆，加密算法变化时名字可以保持不变。

这种命名与URL相似，并且是可聚合的，因此能够方便地与URL相匹配，这意味着在当前网络环境上进行部署较为容易，但是安全性较低。

另一种是扁平命名方法，其格式是P : L，P 是内容发布者公钥的加密哈希，L是内容标签。

这样的命名是没有语义的哈希串，具有较好的稳定性和唯一性，但也带来了不便于理解、记忆，加密算法升级后其名字将发生变化等问题。

2 名字解析和路由
在ICN中，信息名字必须可以被解析到信息的位置，从而实现对信息的寻址，因此仍然存在名字解析技术。

在IP网络中，采用DNS实现域名到IP地址的解析。

DNS采用分布式结构，解析过程复杂，解析效率不高。

同时DNS将解析与路由分离，增加了传输延时。

ICN可以合并解析和路由过程，，路由的路径和解析的路径是一致的，传输过程中没有单独的解析时间，因而减少了传输延时，提高了传输效率。

另外，解析和路由路径的合并，也减少了解析路径的故障导致的通信失败，保证ICN更可靠地传输。

解析和路由绑定也增加了路由器的存储和处理负载。

为了按照信息名字路由和解析数据位置，路由器中将缓存将信息名字映射到转发接口的路由表，而增长的信息名字必然填满路由表，导致路由表膨胀，必须不断增长存储空间以满足不断增长的路由表。

因此，在ICN中，信息命名技术的可聚合性研究是至关重要的。

3 缓存
ICN在中间节点采用了信息缓存技术，利用存储开销换取传输效率。

信息缓存的优势在于若中间节点已经缓存了信息，请求端不需要再到服务器端获取信息，而到最近的中间节点处获取信息即可。

分布式缓存方式是指多个中间路由器互相合作，共同协商存储完整的信息，信息分块存储。

边缘分布式缓存方式将信息尽量存储在离需求端近的路由器上，即边缘路由器上。

用户请求信息时，若缓存中有相应信息，直接从最近的路由器获得，传输效率必然高于从远端路由器获取方式。

4 移动性
当前网络基于主机连接的特性使其移动性和多寻址成为一个管理端到端连接和选择路径和端口进行连接的问题，而ICN没有端到端的连接，故不需要类似的连接管理。

一个移动用户仅仅需要在一个接入时不断请求NDOs。

新接入的请求极有可能需要一个新的服务器的服务而不需要维持和之前服务器的连接。

一个多宿主的客户可以选择发送请求给任一个、多个或所有的服务器。

三、几种主流方案
1 DONA
DONA (Data-Oriented Network Architecture)，DONA是由美国伯克利大学发起的，是第一个完整的ICN架构，它采用扁平的命名方式，也保留IP地址和路由，名字解析机制覆盖在IP层之上。

1)命名
P:L命名结构，发布者公钥P、独特的信息标示L的哈希值。

名字与应用、地理位置无关，任何提供商都能提供同样的数据。

如果客户对某个信息感兴趣，他可能通过某些外部机制，比如搜索引擎知道这个名字。

2) 名字解析和路由
DONA中名字解析由解析处理器，Resolution Handlers(RHs)完成。

在每个自制系统AS中都至少有一个本地的RH。

RHs之间互相连接，以提供一种分层的名字解析服务，名字解析和数据路由都采用现有的路由策略。

内容发布者首先向他本地的RH发一个注册信息，这个RH就保存了一个指向发布者的指针。

这个RH再通过现有的路由策略向它的邻，父域传递这个注册信息，这样中介RH就保存了一个对象名字和转发注册信息的RH的映射。

订阅者向他本地的RH发一个FIND分组，RH再向父域转发这个分组，直到找到有一个注册的实体与它匹配。

然后，请求将随着RH中注册信息创建的指针找到发布者。

数据路由可能与名字解析分离，也可能不分离。

如果分离，数据可能直接通过常规的IP路由和转发。

由于IP地址将要耗尽，DONA可能只使用本地域内的IP地址。

在分离的策中，FIND分组在RH间转发时会记录路径的标签，数据返回时只要沿着标签就可以找到订阅者。

3) 缓存
DONA通过RH提供路径上的缓存，当请求经过RH时，可能从RH直接获取数据。

4) 移动性
订阅者移动可以重发FIND分组；发布者移动需要重新在RH中注册，这将产生不必要的开销。

5) 安全性
DONA的命名方式支持自认证，这使得订阅者可以验证她请求的数据名字和接收到的数据是否匹配。

2 NDN
内容中心网络，Content Centric Networking(CCN)，由施乐帕克研究中心发起。

2010年美国NSF 设立了未来互联网体系结构(Future Internet Architecture program FIA)计划，FIA资助了4个项目，其中命名数据网，Named Data Networking(NDN)项目继承了CCN的思想。

NDN重构了Internet
协议栈，将IP网络中细腰的IP包换成命名数据。

1) 命名
NDN采用分层命名，类似URLs，如果请求的内容的名字是某个名字的前缀，这
两个名字就匹配了，另外，这种匹配规则也允许订阅者请求还没生产的内容，发布者可能广告他可以满足请求者提出的名字的前缀，这在信息对象动态产生的业务中很常用
2) 名字解析和路由
订阅者发出Interest分组请求信息，并得到Data分组。

所有信息在内容路由器
Content Routers(CRs)转发，每个CR维护3个数据结构，转发信息表Forwarding Information Base(FIB)，待处理请求表Pending Interest Table (PIT) 和内容存储器Content Store(CS)。

FIB保存内容名字到转发接口的映射，PIT暂存输入接口到未处理的Interest分组请求内容名字的映射，CS 暂存信息对象和其名字的映射。

当CR收到Interest分组时，首先查看CS中是否由于Interest分组请求的数据，如果有，则返回数据；没有，再查看PIT是否有同样请求的名字，如果有，则丢弃Interest分组，并在表中匹配的名字后添加输入接口；如果没有，则根据FIB转发Interest分组，并在PIT插入输入接口到名字的映射。

发布者收到Interest分组，就返回Data。

之后每隔CR收到Data后，根据PIT中的输入接口转发Data，并删除PIT中的对应项，并在CS中暂存一段时间。

NDN中数据路由和名字解析是在一起的。

FIB表的填充可能需要现有的内部网关协议。

4) 缓存
NDN天生支持路径上存储，每一个CR在收到Interest分组时都先查看CR，并通过某种策略删除CR中的项
5) 移动性
A 每个移动订阅者和发布者都至少连接在一个PoA(Point of Attachment)上，当一个订阅者切换后在新的PoA注册，新PoA通知原PoA，原PoA把PIT发给新PoA，更新FIB和PIT。

也可能原PoA将缓存的数据转发给订阅者。

同理，发布者移动时，也要向新PoA注册，并更新所有相关CR的FIB。

B 订阅者也可能向他可能切换的PoA任播Interest，这样这些PoA都可能收到Data并返给订阅者。

发布者移动时，旧PoA也会任播Interest，保证Data能顺利返回。

6) 安全
Data分组中都有信息5的签名，保证任何CR都可以检查Data以确定其完整性和安全性。

3 PURSUIT
Publish-Subscribe Internet Routing Paradigm由欧盟F7P赞助，完全移除IP协议栈，并使用发布-
订阅协议栈。

PRUSUIT由三个分离的功能：汇聚、拓扑管理、转发。

汇聚处理发布和订阅的匹配，
并通知拓扑管理器创建一个路由，最后转发功能使用这个路由传输信息。

1) 命名
PURSUIT中的信息对象由两个唯一的ID所标示，scope ID范围ID和rendezvous ID汇聚ID。

一个信息可能属于多个范围ID，并至少属于一个，但只有一个确定的汇聚ID。

每个范围有不同的接入权利。

因此，一个完整的名字可能有一系列范围ID和单独一个汇聚ID组成。

2) 名字解析和数据路由
PURSUIT中名字解析由汇聚节点实现。

当一个发布者向广告一个信息时，他向本地的汇聚节点发送PUBLISH分组；当一个订阅者想得到同样的信息时，它查询本地汇聚节点，并最终找到发布者的汇聚节点。

当发布和订阅匹配，汇聚节点就会只是拓扑管理器创建一个连接发布者和订阅者的路由。

拓扑管理器把这个路由发给发布者，发布者就会把信息通过转发节点FN发给订阅者。

在PURSUIT中，名字解析和路由分离，名字解析由汇聚网络完成，数据路由由拓扑管理器组织，由转发节点执行。

3) 缓存
PURSUIT支持路径缓存，也支持脱离路径缓存。

FN可以缓存数据，但这种方式效率低，因为路由可能选取不同的路径，即使是对同样数据的请求。

脱离路径缓存，缓存将被当作发布者，也同样要在
汇聚网络里发布广告。

4) 移动性
PURSUIT通过缓存和多播支持移动性。

如果订阅者在本地移动，则可向移动订阅者可能移动的位置多播信息对象。

对于全局的移动订阅者，则需调整转发路径。

对于移动发布者，拓扑管理器必须获知发布者的新位置。

5) 安全
PRUSUIT支持包级认证Packet Level Authentication (PLA)，加密和签名每个不同的包，这将保证数据完整性和可信性。

PLA可以用在FNs，也可用于包的目的节点。

扁平命名也支持自认证
4 SAIL
未来网络架构和设计Architecture and design for the future Internet(4WARD)项目和它的后续，可扩展和可适应因特网方案Scalable and Adaptive Internet Solutions(SAIL)，均由欧盟F7P赞助，致力于设计未来网络，并能从现有互联网平滑的演进。

其中Network of Information(NetInf)是其中一个ICN架构，支持命名数据对象的交换，融合了NDN和PURSUIT的特点。

1) 命名
SAIL的命名方式是混合的，它们具有某种结构，可能是分层的，但不包含地址和组织信息。

SAIL 定义名字格式ni://A/L，A是身份认证部分，L是相对于身份认证部分的本地地址，两个部分都可以是
哈希。

当路由时，名字可以被当作是分层的，路由器可以使用最长前缀匹配规则来决定如何路由；在名字的比对时，比如订阅和发展部匹配时，可以认为名字是扁平的。

2) 名字解析和数据路由
在SAIL中，名字解析和数据路由可绑定在一起，也可以分离。

名字解析系统，Name Resolution System(NRS)，
用于映射对象的名字和其位置。

发布者先发一个publish分组和他的位置给本地NRS，这个本地NRS 保存L到位置的映射。

本地NRS使用布隆过滤器汇聚了同样A的所有L，并发一个publish分组给全局NRS，全局NRS保存A的布隆过滤器到某个本地NRS的映射，并移除之前这个映射。

当订阅者对某个信息对象感兴趣时，他发一个subscribe分组给他的本地NRS，本地NRS有查询全局NRS，这项就能定位对象的位置。

最后，订阅者再发一个get分组给发布者，发布者返回Data分组。

3) 缓存
SAIL可能提供分层缓存，本地缓存可能是一个根包含少量缓存服务器的缓存树的一部分。

这个树的高层因该有较大的存储空间，为了存储流行的内容。

同时，流行的内容业动态向网络边缘迁徙，以便用户能更好地获取。

4) 移动性
当移动主机更新他的位置后，就要刷新他注册在NRS中的拓扑信息，与其通信的任何节点都要受到一个通知
5) 安全
基本的安全架构要将哈希值包含在名字中，这就允许身份认证和本地部分的自我验证。

5 Mobility First
移动性优先由美国未来互联网架构赞助，这种架构将移动设备作为通常的情况。

因此，Mobility First将提供一系列机制来处理移动性、无线连接，比如多播、多宿主、网络存储、安全性等。

Mobility First的基础就是将所有网络实体，包括信息对象，设备，服务器的名字和它们的地址分离：每个实体有一个全局的、唯一的名字，可以被映射到一个或多个地址。

1) 命名
Mobility First中的每个网络实体都通过全局命名服务器被签名，GUID。

网络中每个设备，和他的信息对象，所提供的服务，都有GUID。

GUID是一个扁平的160比特的串。

GUID可以是能够自我验证的信息对象的哈希值，因此允许信息的完整性验证；或者是公钥的哈希值，可以与发布者绑定，信息对象所有的拷贝拥有相同的GUID。

2) 名字解析和数据路由
在Mobility First中，通信由GUIDs发起，在通信过程中GUID可能一次或多次通过全局名称服务器GNRS被翻译成网络地址。

发布者向GNRS注册他的地址和信息名字。

一个GUID可能通过哈希值映射到多个GNRS。

当订阅者向接受一些信息，就还会发一个Get分组给他本地的内容路由器，这个Get包括请求信息对象的GUID，和他自己的GUID。

内容路由器Content Router(CR)通过IP地址路由，他询问GNRS，获得请求的信息对象的一个或多个地址。

CR选择一个地址，把他加入Get分组，在更加路由表转发。

路径上的每个CR都可以再次查询GNRS以更新目的GUID的网络地址，因为发布者的移动性可能造成Get分组不能到达。

当发布者收到Get分组，就以同样的机制向发布者的GUID发送数据。

3)缓存
Mobility First可以在中间CR中缓存经过的信息，因此接下来对同样GUID的请求可以通过缓存直接得到回应。

每次缓存时，GNRS都要为缓存的GUID注册新的地址。

4) 移动性
主机移动性由GNRS处理，当一个对象切换它的附着点是，GNRS必须更新。

如果请求的GUID移动频繁，CR就要多次查询GNRS。

同时，在域内使用一种存储发现的路由机制，当因为移动导致失连时提供更好的链接。

5) 安全
Mobility First为名字验证提供去中心化的信任模型，独立的命名组织将人类可读的名字映射到GUID。

这样一个实体的GUID就可以通过加密技术安全的绑定到这个实体上。

四、方案对比
五、研究方向
1 命名
分层命名是人类可读的，并容易汇聚，但扩展性差。

另一方面，扁平命名容易验证，也不需要最长前缀匹配，可以通过分布式哈希表扩展，但难以聚合，容易导致路由表膨胀。

对于信息对象名称结构的版本，删除，撤销等还没有做细致的研究，并且有人认为对每个包都惊醒检查会造成额外开销。

对信息的搜索也没得到很多关注。

对信息的感知可能是搜索更有效，可能要加入有数据，比如上下文参数，地址，信息类型等，这些元数据要与信息实体共存，这就允许对某些请求智能流量操控。

但这会破坏网络的中立性。

2 名字解析
巨大的命名空间为名字解析带来严重的挑战。

分布式哈希表因为它的对数扩展性得到广泛关注，但这些方法的效率不高。

另外，对域间结构的研究表明，自制系统间的关系导致网格转的域间图，因此使用分层结构组织命名空间不能反映现实。

最近也提出直接用哈希表将名字映射到IP地址，但这
需要全局的名字解析系统。

3 路由
目前对域间路由策略的研究还很少。

在ICN领域，主要的问题是将域内路由方案扩大到互联网范围，如何确定域间路由路径。

4 缓存
缓存机制在应用层的研究很多，主要是web应用。

但在ICN中大量使用缓存可能不会很有效。

一些形式的流量可能会竞争缓存空间。

因此智能的缓存空间管理是至关重要的。

另外，使用缓存也要结合优化路由和转发策略。

另外，如果内容的原始提供者更新了内容
5 移动性
移动性被视为目前网络主要的短板，在ICN中，人们对移动性的研究也不多。

发布者，或者说信息的移动性，是主要的挑战，因为大部分ICN架构使用的名字解析机制更新都很慢。

另外，路由表名字汇聚的使用，又一次引入了位置标示，当路由改变时，。

6 安全、隐私、信任
所有ICN架构的安全机制都基于密钥联合名字的加密。

这些密钥如何管理却没人研究，比如对和谐密钥的创建、发布、撤销。

ICN架构的接入控制方面的研究也很少，比如接入控制策略，在缓存信息上的引用，对用户的认证。

因为用户对某个信息的Interest，所有处理此请求的节点都知道这个请求，请求的内容可能存储在所有经过的路由器上，而发出同样请求的用户则会共享这个内容，。

7 传输
ICN数据传输因为其内部的一系列机制和功能，比如缓存和复制使得带宽可以交换，从根本上改变了传输层，因此比端到端模型更复杂。

新的分发机制，比如多播和汇播，对多路径路由的支持，需要很多机制如流控制，拥塞和错误控制。

8 QoS
9 商用和部署
抛开技术问题，ICN的商业化仍面对一系列问题。

比如ICN是否应该覆盖在现有网络之上？如何与现有的技术融合？将ICN作为覆盖网络肯定花费更小，也更平滑，对ICN的采用要先采用在现有网络上的覆盖机制，要长期维持与TCP/IP应用的兼容性。

对于覆盖的ICN来说，这种转变简单直接，但对于完整的ICN方案还很远。

另外，ICN社区对于使用哪种架构还没达成共识。

如果采用多种架构，它们之间还需要可以互操作。

参考文献
[1] George Xylomenos, Christopher N. Ververidis, Vasilios A. Siris, Nikos Fotiou, Christos Tsilopoulos, Xenofon Vasilakos, Konstantinos V. Katsaros, and George C. Polyzos, “A Survey of Information-Centric Networking Research”, IEEE COMMUNICATIONS SURVEYS & TUTORIALS J, vol. 16, no. 2, pp. 1024-
1049,SECOND QUARTER 2014.
[2] Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher, and Börje Ohlman,”A Survey of Information-Centric Networking”,IEEE Communications Magazine J, vol. 50, no. 7, pp. 26-36 July 2012. [3] Ravishankar Ravindran, Samantha Lo, Xinwen Zhang, Guoqiang Wang, “Supporting Seamless Mobility in Named Data Networking”, Communications (ICC), 2012 IEEE International Conference on, C, pp. 5854-5869, 2012.
[4] Gareth Tyson, Nishanth Sastry, Ivica Rimac, Ruben Cuevas, and Andreas Mauthe, “A Survey of Mobility
in Information-Centric Networks: Challenges and Research Directions”, Proceedings of the 1st ACM workshop on Emerging Name-Oriented Mobile Networking Design - Architecture, Algorithms, and Applications, June 2012.
[5] 于晔, 李联峰, 郭红纲, “新一代互联网NDN面临的挑战及脆弱性分析”, 信息安全与通信保密J,
pp.123-127, 2014年.
[6] Dookyoon Han, Munyoung Lee, Kideok Cho, Ted “Taekyoung” Kwon, and Yanghee Choi, “Publisher Mobility Support in Content Centric Networks”, Information Networking (ICOIN) C, pp. 214-219, 2014.。