摘要：在NDN中，由于PIT表的存在，所以NDN就自然具有了支持内容消费者节点可移动的功能，但是内容生产者节点的移动性问题尚未得到很好的解决方案。本篇工作从NDN的Interest-Data模型中Data会沿着Interest在PIT留下的trace（Breadcrumbs）返回到移动的consumer上得到启发，建立了一个风筝模型（Kite）来解决producer的移动通信问题，即producer好比一个风筝，一个不移动的anchor好比牵引风筝的人，则中间的线就是producer留下的trace。本篇工作主要介绍了这个kite模型的设计，同时设计了四种producer移动的应用场景（Upload、Pull、Push、Share）来阐述kite模型的可行性。
导言：本篇Reading note先简单
（一）介绍一下移动的consumer是如何获取数据的，接着
（二）介绍由consumer移动问题的解决思路中启发得到的kite模型的简单设计思路，然后
（三）介绍kite模型在四个应用场景（Upload、Pull、Push、Share）中的应用，最后
（四）再回过头来描述kite模型的技术细节。
（一）
如图2所示，当consumer想从非移动的server节点上下载（Download）数据时，它会先发送Interest包到server上，而Data则沿着沿途节点留下的trace往回发送。然而，当consumer节点还没接收数据时，就已经从location1移动到了location2，这时候consumer会重新发送Interest包，则该Interest包将会在中途的缓存节点（假设为A）上命中内容，该内容则沿着新的trace返回到consumer上。
可以看出，移动的consumer通过发出Interest包在和server之间建立了一条trace，当consumer节点移动后，consumer会重新发出Interest包建立新的trace。这样Data总能沿着新的trace发送到consumer上。
（二）
那么如果图2中的移动节点是producer节点的话，问题该如何解决呢？
这就是kite模型的提出目的，解决移动producer的通信问题。
其实kite模型的整体思路和移动consumer的解决思路差不多，只不过这次是由producer发出一个Interest包来建立一条trace。
即所谓的kite模型是，移动的producer充当风筝，通信节点（correspondent node）或者不移动的anchor节点充当牵引风筝的人，由producer发出Interest在沿途节点PIT表上留下的trace充当人和风筝之间的牵引线。与consumer发出的Interest包类型不一样的是，这里producer发出的Interest被称之为traced Interest,作用就是用来创造一条trace（风筝线），而通信节点发出的Interest包被称之为tracing Interest，作用就是沿着traced Interest 留下的痕迹到移动的producer上获取数据。
Traced Interest —tracing Interest与Interest—Data之间的区别：
其实这里的traced Interest 就好比NDN中的Interest包，而tracing Interest就好比Data，traced Interest就是为了拉取tracing Interest包的返回，而tracing Interest主要目的就是为了请求真实的Data。当然这里的traced Interest会在沿途的PIT表上留下trace，则tracing Interest则沿着这trace到达移动的producer上。
如图四所示（这是一个Upload场景，即移动的producer想上传文件到非移动的server上），移动的producer会先发出traced Interest到server上建立风筝线，则server会发出tracing Interest沿着该trace发送。当producer还未接收到tracing Interest时，就从location1移动到了location2上，这时候producer会重新发送traced Interest包建立新的trace，值得注意的是，该新的traced Interest会在A节点的PIT表上汇聚，从而不会被继续往下一跳转发。这样新的traced Interest会将tracing Interest从新的trace上拉取过来，然后producer就将相应地数据沿着tracing Interest的痕迹上传到server上。
（为何在这个Upload场景中，移动producer既然能把traced Interest 直接发送到server上，为何不直接就把数据上传过去（一个过程就可以完成），而是需要先发traced Interest，再拉取server的tracing Interest，最后再发Data（这需要三个过程）。后来想应该是Data要比traced Interest大太多，在Data还没上传完成时，producer有可能就已经发生了移动，这样Data的上传进程就被打断了，上传的Data可能就无效了。而通过traced Interest来拉取server的tracing Interest包，这样就可以把Data分割成一小块一小块沿着tracing Interest包的反向路径发送到server上。而且这样也不需要担心中间会有某块Data片段没被server接收，因为如果没接收到的话server会重新发送tracing Interest包来拉取。）
（三）
在开始介绍kite模型在四种场景（Upload、Pull、Push、Share）中应用时，先在介绍一下kite模型中的两个不同类型，即direct kite和indirect kite，前者意思是移动的producer直接和通信节点（consumer）建立trace，后者是移动的producer先和固定的anchor节点建立trace，然后通信节点通过这个anchor再和producer联系，这就是间接型的kite。
如图3所示，Mobile Node和Immobile Server之间的trace的建立就是direct kite模型的运用；而mobile Node先和Immobile anchor之间建立trace，然后mobile correspondent node再通过Immobile Anchor来获取Mobile Node的trace从而与Mobile Node建立联系就属于indirect kite。
那么什么类型的场景是运用direct kite模型的场景，什么类型的场景又是indirect kite模型的运用场景？可以分析为如果是移动producer主动想联系固定的通信节点的就是direct kite场景，如果是通信节点想主动联系移动producer的就是indirect kite场景。为何这么说，因为一般来说通信节点位置是固定的，那么移动的producer是可以知道通信节点的拓扑位置，从而直接和通信节点建立trace，这就是direct kite；而由于producer是移动的，通信节点不知道producer的拓扑位置，只能通过到固定的anchor节点上获取producer的trace，这就是间接的kite。
那么四种场景中，Upload是属于direct kite，而其他三种都属于indirect kite。
这是因为Upload场景是，移动的producer想把数据上传到Immobile的server上，因为producer是可以知道Immobile server的拓扑位置的，所以就可以建立direct kite；
Pull场景指的是Immobile server（Facebook server）充当consumer角色，想从Mobile的producer那里拉取数据（如用户的GPS 信息），因为producer是移动的，拓扑位置未知，所以只能通过Immobile anchor来建立联系，这就是indirect kite；
Push场景指的是Immobile server想将一条message发送给移动的用户（producer），同Pull场景，server未知producer位置，需要通过Immobile anchor的帮助，所以也是indirect kite；
Share among Mobiles场景指的是两台以上的移动手机（Producer）想要分享信息，则也需要中间的Immobile anchor来建立trace，所以也是indirect kite。
如图3所示，移动的producer会定期地发送traced Interest 到Immobile anchor上不断更新它的trace，这样其他节点通过Immobile anchor总能达到移动的producer上。
a) Upload场景：producer（Alice‘s phone）想上传一张图片.jpg到Facebook server上，因为该server是固定的，这样移动的producer就可以发出(1)traced Interest到该server上建立trace，然后该server再发送(2)tracing Interest 沿着traced Interest留下的trace到producer上请求该图片.jpg，最后producer再把该图片发送给server。总共是三个步骤。
b) Pull 场景：Facebook server想拉取移动producer（Alice’s phone）的GPS信息。因为producer会定期地往Alice’s home anchor发送(1)traced Interest建立风筝线（trace）。这样Facebook server想发送Interest到达producer上，就只能先将该tracing Interest按照沿途节点的FIB路由到Alice’s home anchor上，再由前面的trace指引发送到移动的producer上，最后producer就把相应的Data沿着trace发送到server上。也是三个步骤。
c) Push场景：Facebook server想发送一条Message到移动的producer上（Alice’s phone）。同Pull场景，Alice‘s phone（producer）会定期地发送（1）traced Interest到Alert service anchor上建立trace，这样Facebook server就得先把它自身的traced Interest发送到Alert service anchor上再沿着trace发送到Alice’s phone上拉取tracing Interest回来，最后再由tracing Interest把Data拉取回去。四个步骤。
d) Share among mobiles：多个移动producer之间分享数据，这里以两个producer为例。这两个producers都会把它的traced Interest发送到chatroom’s rendezvous anchor上建立两条trace。这样Bob’s phone发出的(2)traced Interest就能沿着Alice’s phone发出的traced Interest留下的trace发送到Alice‘s phone上拉取它的tracing Interest回到Bob’s phone上，再由该tracing Interest拉取所需的打他回到Alice’s phone上。
（四）
Kite 模型主要是通过修改Interest包的格式和修改forwarding plane上的转发处理过程来进行技术实现。
- 往Interest包里添加了三个域（field）：
- Tracing Name：这表明该Interest是要沿着trace路径来转发，traced Interest和tracing Interest的tracing name是一致的，这样traced Interest才可以通过名字来匹配相应的tracing Interest.
- TraceOnly:一个flag，用来表示该Interest是沿着trace转发，还是按照FIB来转发。如果TraceOnly未设置（default），则该Interest是沿着FIB来转发；如果已经设置，则沿着trace转发，如果没有匹配的trace存在，再通过FIB来转发。如上图的Pull场景中，由Facebook Server发出的tracing Interest的TraceOnly肯定是已设置，所以在从Facebook Server到Alice’s home anchor的转发中是按照FIB来转发，而从home anchor到Alice’s phone上则是按照trace来转发；
- Traceable：一个flag,用来表示该trace是否允许被其他的Interest沿着它的trace进行转发。
- 修改forwarding plane上的PIT表，其实就是往PIT表里添加了两张表：Trace Forwarding Table(TFT)和Trace Name Table（TNT）
- TFT表主要记录了traced Interest的Traceable flag，指引tracing Interest的转发；
- TNT表则主要记录traced Interest的Trace Name，通过这个Trace Name来匹配拉取相应的Tracing Interest。
如图1所示（最下层），通过PIT表里的TNT表的Trace Name匹配相应的tracing Interest（Pull），然后沿着TFT里的记录返回。