Transparent Flow Migration for NFV

摘要

因为SDN提供的灵活性，NF之间存在着流量的迁入和迁出问题。而且NF也要根据相关的状态信息处理数据包，所以流量迁移必须满足以下两点要求：

保持数据包和状态的迁移顺序，必须获取状态才能处理数据包。
想都不用想，这点一定是低开销、低时延～

目前现有的流量迁移架构，把流量迁移和状态迁移耦合在一起，这种架构不能实现安全、高效、低开销的迁移。
于是本篇论文提出了一个流量迁移架构，叫TFM（Transparent Flow Migration ），显然，TFM和以往的架构相反，解藕流量迁移和状态迁移，这样的好处是可以对两个过程分别的进行优化，并且实现两个过程的并行处理。
TFM通过TFM box实现了一系列的优化，TFM box是一个中间层，它可以提供NF之间透明的数据包迁移。

INTRODUCTION

Background and Motivation

流量迁入迁出的目的是为了节约资源、规避SLA惩罚、负载均衡。
NF对流量的处理往往依赖于状态，在迁移后如果没有相应的状态信息，将很难重新对某条流量起到路由作用。
流量迁移的几种方法：

待源NF处理完所有in-flows，然后把新来的流量全部转移到目标NF。
缺点：时间未知性，根本就无法预知当前处理的in-flow何时结束。举个例子：当一个NF已经过载并无法满足SLA，这时候还要它处理完剩余的in-flows，这显然是不合理的。而且即将被迁入NF也要等待它处理完剩余的in-flows，造成了资源的浪费。
立刻迁移，为了满足NF的带状态处理，数据包迁移要伴随着状态迁移一起进行。
缺点：由于流量是源源不断的流入NF，这种方式比较害怕目标NF没有开启的情况。

流量迁移目前存在的问题

如何协调状态迁移和数据包迁移，并确保状态一致性，同时提高效率和最小化开销。

设计一个合理的流量迁移架构必须满足以下要求

状态一致性：迁移前后源NF和目标NF状态保持一致。
保证安全性：无损，保序。
高效率迁移：限的时间内完成，以减少迁移对控制和数据平面的影响。
实现低开销：不用说我们都懂。

Summary and Limitations of Prior Art

现有的流量迁移架构有两个：Split/Merge和OpenNF。（状态迁移和数据包迁移耦合）

共同点：
通过一个中央控制器缓存状态迁移过程中到来的数据包，这样不会丢包，也不会丢失状态信息。等待状态迁移结束之后，把缓存的数据包发送给目标NF。但需要中央控制器拥有足够多的缓冲资源。
差异点：
两种方法的区别在于in-transit数据包处理（in-transit数据包：实例A迁移到实例B当，实例A开始迁移的时候它还有一些数据报等待处理或者正在发往目标NF的路上，但是不会被A处理因为迁移开始了）
- Split/Merge：直接丢弃in-transit数据包，
- OpenNF：将in-transit数据包重定向到控制器，然后交给目的NF（三角形路由），但是这种操作可能会引起额外的迁移时间。

以往方法把状态迁移和数据包迁移耦合在一起（按照顺序执行），虽然实现了状态的一致性，但是存在着以下两个问题：

额外的时间：因为在状态迁移的过程中到达的数据包无法得到处理，增加了它们的处理时延。
更重要的问题是，执行迁出操作时不能保证安全性（不丢包、保持包的顺序）。这是因为已经超载的源NF在状态迁移完毕之前必须继续处理进入的数据包。这样会造成很高的丢包率。而且超载的源NF还加剧了包处理线程和状态迁移线程之间的锁争用，这也会增加额外的时间开销。

TFM

TFM把状态迁移和数据包迁移解耦，这样带来的好处是：

二者可以并行，状态迁移时同时完成两件事情：
- 告诉switch立刻把要迁移的流量转移到目标NF。
- 告诉源NF立刻开始向目标NF传输状态。
不必等待状态迁移完毕结束，就可以提前转移数据包，避免“三角形路由”，节约了时间和空间。

实现TFM的三个技术挑战：

解决带状态的数据包处理问题：
根据TFM的做法，状态迁移开始时，所有的数据流立刻转向到目标NF。那么这就要求源NF和目的NF用对应的状态信息来处理对应的数据包。如何区分状态迁移前的数据包和状态迁移后的数据包
解决方案：
打标签，通过标签来标记迁移前数据包和迁移后数据包，首先处理迁移前数据包，接着处理迁移后数据包。
保持状态迁移的透明性：
处理被状态迁移所影响的数据包，最简单的方法就是将它们转移到目标NF并进行缓存，但是这需要NF具备相应的功能，但是增加这些功能会影响NF的性能。
解决方案：
加入一个TFM box（数据包处理单元）来实现这些功能。（缓存、区分数据包、协调状态迁移的过程），TFM box在那些被迁移的流量到达NF之前，直接把它们处理掉，也就是说TFM box是被专门用来处理迁移流量的，这对源NF和目标NF来说是透明的。
最小化迁移开销：
各个TFM box之间交换状态信息，需要额外的开销（生成携带控制信息的数据包，通过三角形路由的形式传递）。
解决方案：
通过流量来携带控制信息，在数据平面范围内解决这个问题。

DESIGN OVERVIEW

TFM Controller：提供北向接口，以及Flow Migration Orchestrator。
Flow Migration Orchestrator：由State Manager、Flow Manager、Forwarding Manager组成，提供状态迁移期间的：状态迁移（State Manager）、数据包迁移（Flow Manager）以及流量转向功能（Forwarding Manager）。
State Manager：依靠现有的南向API工作。
Flow Manager：管理TFM box。
TFM box：在状态迁移期间，为被迁移的流量提供数据包缓存，和处理。
Forwarding Manager：调用SDN控制器，在状态迁移开始时，更改流表项，迅速的把要迁移的流量导向到目标NF。

总体功能细化分成三部分可以增加TFM的灵活性，三者间相互独立，改变一个并不会影响其他两个：

Working with a new NF with a specific southbound state import/export API only needs to update the State manager; using a new type of OpenFlow or SDN controller only needs to change the forwarding manager,