[友猫]NFD Developers Guide--Table（1）

Table 提供NFD中的的主要数据结构.
Forwarding Information Base(FIB)用于转发兴趣包到潜在可能匹配数据的源节点。他与IP FIB是相同的，唯一的区别在于他允许多个出口，而不是一个出口;
Network Region Table 包含一系列生产者范围名字（producer region names）以提供移动支持;
Content Store(CS)数据包缓存，到达的数据包在这里尽可能长的保存，已满足未来请求相同数据的兴趣包;
The Interest Table (PIT)记录兴趣包转发上游，数据包可以发送下游到请求者，同时他还包含最近满足的兴趣包以支持LOOP检测和测量;
Dead Nonce List:是The Interest Table 的增加内容用于LOOP检测;
Strategy Chioce Table包含为每一个名字域的转发策略
Measurement Table,是forwarding strategirs 用来存储关于一个名字前缀的测量信息;
FIB，PIT， Strategy Chioce Table .Measurements Table的索引结构有很多的共性，为提高性能，节省存储空间。NameTree,作为一个通用common的索引被设计共享在这四种数据表中。

1. Forwarding Information Base

对每一个需要转发的兴趣包，都需要在FIB上执行最长前缀匹配，输出接口则是转发重要的参考。
结构和语义

FIB表项和下一跳记录
FIB表项包括一个名字前缀和非空的下一跳集合。他的意思是：对于该名字前缀的下的兴趣包，可以通过所给的下一跳记录的接口到达可能的数据源。
每一个下一跳包括到达可能数据源的接口和他的路由开销。一个FIB项至少包含一个下一跳记录。在FIB项中下一跳记录按照路由开销升序排列。
不同于RIB，在两个FIB项之前不存在继承关系，下一跳记录是“有效”下一跳。

FIB
FIB是FIB项的集合，由名字前缀索引。支持insertion, deletion, exact match操作。FIB条目可以以一个前向迭代器的形式以未指定的顺序进行迭代。（意思就是FIB表在更新）

最长前缀匹配
（Fib::findLongestPrefixMatch)用于发现一个指引转发的FIB项，将名字作为输入项，这个名字应该在兴趣包的名字域之内，返回一个FIB 项，该FIB项的名字前缀是1）输入参数的前缀，2）满足条件一的最长匹配；当不存在满足条件1 的项是，返回为NULL。

用法
FIB的更新由FIB管理协议实现，在NFD一侧是由FIB管理器（6.5）执行操作。FIB管理器从RIB核心中获取命令行，他负责接收手动配置静态路由或应用注册的路由以及动态路由协议产生的路由。由于大部分的FIB项来自于动态路由，所以FIB表最好包含最少数量的FIB项。
我们希望IFB表是相对稳定的,RIB的更新（手动静态路由配置，应用的开启与关闭，路由更新）会触发FIB的更新。这些更新在稳定网络中的相对较少，但是每一个RIB表的更新会触动多个FIB更新，这是应为RIB项的跟新会影响多个继承自他的后代。

2.Network Region Table

该表用于支持移动应用（4.2.3）。他包含一个上未排序的取自NFD配置文件（6.7.2）的生产者域名集。当一个兴趣包Link对象的degelation name是该表域名的任何一部分前缀，就是说兴趣包已到达生产者所在的区域，此后应该用名字而不是 degelation name 进行转发。

3. Content Store(CS)

根据NDN架构和第四部分的详细介绍我们知道CS匹配在兴趣包执行forwarding stretagy 已完成未来处理过程之前进行。因此存储的数据可以用来满足兴趣包而不需要再将其转发。

语义与用法
CS(nfd::cs::Cs)作为数据包存储器，在forwarding确定数据包合法性等一系类操作之后，数据包插入表(Cs::insert)中或者在incoming Data pipeline (Section 4.3.1)或Data unsolicited pipeline (Section 4.3.2)。
在存储数据包之前，将评估许可策略。本地应用程序可以为许可策略admission policy提供提示并附加到数据包的CachePolicy字段中的LocalControlHeader[11]。
之后，数据包被存储，并写入一个过期的时间点，这个时间点之后数据包就不能在匹配兴趣包（MustBeFresh Selector.）。
CS的查询在兴趣包达到incoming Interest pipeline之前，查询结果将最佳匹配数据包给ContentStore
hit pipeline (Section 4.2.4),当不能的时候交给 ContentStore miss pipeline (Section 4.2.3)。
CS的存储空间有限，用包的数量衡量，由NFD配置文件控制。管理通过调用Cs::setLimit更新容量，CS的实现应该确保存储的包不超过容量限度。

枚举和条目抽象 CS可以通过ForwardIterators来进行枚举，这一特征不是由NFD之间使用，可是在仿真环境中使用。
为了保持一个稳定的枚举接口，但仍然允许替换CS实现，将一个迭代器用在nfd::cs::Entry 类型上，这是一个CS项的抽象。
此类型的公共API允许调用方获取数据包以及它将变得过时的时间点，无论它是否是被请求的。一个CS实现可以定义自己的具体类型，并在枚举期间转换为抽象类型。

实现
CS性能对NFD的整体性能有很大影响，因为它存储了大量数据包，并且几乎每个包都访问CS。 底层数据结构的选则以实现高效的查找、插入和删除，以及缓存替换算法对于最大化网络缓存的实际效益至关重要。
当前使用两个分离的数据结构，Table作为名字索引,CachePolicy用于内容替换。

Table查询 该表是一个有序的容器，用于存储具体的条目(nfd::cs::EntryImpl），该容器使用隐式摘要按数据名称排序。 查询过成完全由Table执行，对查询过程进行了优化，以在预期的情况下问最小化条目数，在最坏的情况下，查找将访问所有以兴趣名称作为前缀的条目。虽然查找API是异步的，但当前的实现是同步查找的。Table使用std::set作为底层容器。以前的CS实现出于类似的目的使用了一个skip list但是它的性能比std:：set差，这可能是由于算法的复杂性和代码质量。

存储替换的存储协议 CachePolicy是一个接口，用于跟踪CS中的数据使用信息。并且始终具有与CS相同的容量限制。 CS使用CS::setPolicy指定存储策略，当cs:：setlimit调用以更新CS的容量。也应调用cachepolicy:：setlimit。所有的CS存储协议都是CS::CachePolicy的子类，父类提供四个公共API实现存储协议与CS的交互。

• CachePolicy::afterInsert 在插入一个新的表项之后由CS使用，在CachePolicy::doAfterInsert中实现
• CachePolicy::afterRefresh 在现有的一个表项被相同名字更新之前由CS使用，在CachePolicy::doAfterRefresh中实现;
• CachePolicy::beforeErase 由于管理命令而删除一个表项之前友CS使用，CachePolicy::doBeforeErase中实现
• CachePolicy::beforeUse 在用于匹配查询之前友CS使用，在CachePolicy::doBeforeUse中实现。

CachePolicy::doAfterInsert 当一个新的项插入CS时，该策略用以决定是否接受该项，接收则插入道清理索引中，否则将调用cachepolicy:：eviceEntries通知cs进行清理。
CachePolicy::doAfterRefresh 在CS中刷新数据时，策略可能会见证此刷新，从而更新数据使用范围信息以使未来更好的eviction决定。
CachePolicy::doBeforeErase当由于管理命令而删除条目时，策略可能不再需要跟踪其使用情况。它可能需要清除有关此项的信息。
CachePolicy::doBeforeUse当在CS中查找条目时，策略可能会见证此用法，从而更新数据使用范围信息以使未来更好的eviction决定。
CachePolicy::evictEntries,该协议用于帮助必要时作出驱逐eviction决定。当由于策略在插入或容量调整后超出其容量而需要收回时，它将发出一个CachePolicy::beforeEvict信号，cs并在此之后清除条目。这个将被选为逐出的条目取决于策略的设计方式。
(优化FIFO策略，LRU策略)