Kite: Mobility support for NDN
一、在NDN(Named Data Networking)上来解决节点移动的问题
NDN对于移动性的两个优势：the data-centric nature and the stateful forwarding plane.
1、NDN以内容为中心，对数据进行区分和查找，而不是对机器，不关心拓扑位置(Destinations should be data names rather than machine addresses.)在NDN上，问题从How to reach a moving destination? 变成了How to retrieve a piece of data?
2、利用PIT表联络节点(The pending interest table makes nodes transparent.)
二、Kite的提出
本文提出了Kite – String – Hand Model，来实现对移动节点(MN)的定位。MN和固定位置的anchor节点之间通过发送traced & tracing interest，构建PIT表项来保持定位。(Specifically, an application can send an Interest to a routable anchor to create the PIT entries as breadcrumbs (a hop-by-hop trace) leading back to itself on demand. )
MN(mobility node)如同风筝，anchor／CN(correspondent node)节点好比手，traced & tracing interest好比风筝线。
*Kite的局限性：Kite only aims to mobility over a stable network infrastructure, not for wireless mobile ad-hoc networking, because trace setup and maintenance depends on stable underlying routing. Second, we consider Kite an alternative to, not a replacement of, those mapping-based schemes with explicit locators. Particularly, Kite is not suitable for the long-term relocation of data producers.
三、Kite在五种情形(Scenario)下的使用
1) Upload（actively produce）: a photo to a server; or
2) Download（actively consume）: a photo from a server. If the immobile CN, e.g., a server, is active, it may either
3) Pull（passively produce）: data from a phone; or
4) Push（passively consume）: data to a phone. In the case of group communications among mobiles, the MNs can
5) Share data（mutual）, such as chat via phones directly without a centric server.
其中Download是靠NDN本身机制就可以解决的：参见Figure 1：
NDN中的每个节点含有Cache Store(CS), PIT(Pending Interest Table), Forwarding Information Base(FIB)；当一个节点请求某个数据时，它对外广播一个interest；收到interest的节点首先检查CS中是否缓存了对应数据，如果有则返回该数据，否则，在自己的PIT表中记录下该interest，若有FIB表项，根据FIB表继续向外广播；收到数据的节点检查自己的PIT表中有无对应的interest，若有则将该数据保存在自己的CS中，删除PIT中该interest项，并向外广播，若无则不广播：由此实现数据的“原路返回”。(Interests are forwarded along routes in FIBs set up by the routing plane; Data are forwarded along traces in PITs set up by the Interests. If there is no match in CS and PIT, but a match in the FIB, the Interest will be stored into the PIT and be forwarded to the next hop. When a Data comes back and satisfies an Interest in the PIT, the Data will be cached and sent back to the incoming interfaces of satisfied Interests, and the corresponding PIT entry will be removed. So an Interest and its corresponding Data travel along the symmetric paths.)
还有一个问题就是consumer移动、producer不动(move-before-get)。参见Figure 2：consumer会重发interest，而路线相当于被PIT表所保存，因此其移动也没有关系：As shown in Figure 2, after relocation from Location 1 to Location 2, the MN will fetch the Data from Router A by expressing a new Interest. Therefore, no one is actually aware of the movement of an active consumer during the communication.
而剩下的四种情形，则需要用到Kite的框架。
Kite增加的内容（这部分参看了师兄师姐的理解）：
- 往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。
把本来的Interest – Data的两次发送变成Traced Interest – Tracing Interest – Data的多次发送，Traced Interest请求Tracing Interest，Tracing Interest请求Data；多出一次发送是因为一开始还不知道路线，事先铺路：The trace source issues traced Interests, of which the name prefix is called trace prefix, to a trace anchor, which is reachable by announcing the trace prefix into the routing plane. Note that both traced and tracing Interests are still Interests in a sense that they are the requests for Data.
至于移动问题，也是靠周期性地发送来解决的。
具体的附加机制：Kite supports the mobility in two ways.
1、Upload使用direct Kite，MN发送traced interest给CN，CN原路返回tracing interest；如果MN没有接收到tracing interest就移动了，超时以后由MN重发traced interest，值得注意的是，该新的traced Interest会在A节点的PIT表上汇聚，从而不会被继续往下一跳转发。这样新的traced Interest会将tracing Interest从新的trace上拉取过来，产生新的tracing interest路径，然后producer就将相应的数据沿着新tracing Interest的痕迹上传到server上。这样做的目的：因为数据太大，中途一旦移动就会失效，损失很大，所以先发一个traced interest
2、Pull使用indirect Kite: MN一直向Alice anchor周期性地发送traced interest；服务器沿着FIB表向Alice anchor发送tracing interest时，就可以沿着traced interest的路径到达MN，最后MN把数据发到CN
3、Push使用indirect Kite：MN一直向Alice anchor周期性地发送traced interest；服务器向Alice anchor发送traced interest，沿着MN的traced interest的路径到达MN，MN发送tracing interest回来，最后CN把数据沿着两段路发到MN
4、Share特殊在于，MN既是producer又是consumer。Alice和Bob都向Chatting anchor发送traced interest，然后Bob的traced interest沿着Alice的traced interest到达Alice，Alice发送tracing interest到达Bob
*四、评估与优化
*五、其他问题：比如安全性等
Kite outperformers the mapping-based mobility solutions in terms of path stretch and mobile delay, with similar signaling overhead in the case of high-frequent movement.
Discuss security considerations and architectural implications.