第四章 基于逆向转发的意向回溯策略
在 SDN 网络中，逻辑上的集中控制给予控制器对全局网络的实时了解，因此能够灵活地在控制器上开发回溯应用。SDN 中的数据包回溯策略有不同的实现方式，在交换机上安装代理应用，由控制器上的收集器实时获取数据包的位置并进行缓存，回溯时对每个数据包重构出完整路径。但这样会增加交换机的数据包处理时间，还会浪费交换机的计算资源。本章采用逆向转发技术不会对数据平面造成影响，通过转发规则重构回溯路径，基于数据包最后一次转发规则进行逆向运算，每次运算得出上一跳地址，直到回溯至源地址结束。但是这种回溯策略依赖于特定的数据包，数据包的选取决定于用户的意向。因此进一步尝试根据用户意向先对数据包过滤，只对符合特定意向的数据包进行回溯，是对现有 SDN 回溯策略的重要改进。
本章要设计的意向回溯系统是意向的，轻量的，实时的。
（1）意向的：数据包进入回溯节点，并不立即启动回溯。借助意向策略的自动进行匹配，网络管理员可以对数据包进行先进行一次过滤。因为在真实网络，大量数据包快速通过回溯节点，既要保证效率，又要保证准确性，需要把数据包全部收集起来再人工选择，而选择标准只是基于 IP 地址、端口等底层特征，难度可想而知。
（2）轻量的：并不需要对现有交换机硬件作出改变，通过使用软件系统达到意向匹配，轻量的数据包回溯策略无疑对现有网络管理员更有吸引力。
（3）实时的：数据包意向匹配具有实时性特点，意向策略由软件系统动态维护，保证按照实时的意向进行匹配和数据包回溯。
4.1 意向策略
本节首先介绍意向回溯系统中需要定义的意向类型，以及每种意向类型对应的数据包的高级特征，最后介绍意向策略在意向回溯系统中实现的步骤。
意向系统[52]中可以根据数据包的意向特征这样进行分类，“这是来自视频应用的数据包”、“这是来自移动设备的数据包”,而不是仅仅知道“这是来自某 IP 地址的数据包”、“这是到达端口值 80 的数据包”.当然可以这样说，“我要回溯某网站视频应用的数据包”.现在为了实现一个可扩展的意向回溯策略的编程接口，需要对控制器特征、应用特征、设备特征加以明确，以便于在定义意向的时候不会产生歧义。意向回溯策略的实质在于确定到底要回溯哪些意向类型的数据包，并获取符合这些意向特征的样本数据包，把过滤后的数据包交给控制器，由上层应用来计算数据包的回溯路径。
意向回溯策略分成三个步骤：（1）控制器将编写好的意向策略下发到交换机上（2）当数据包经过回溯节点时，如果匹配到已下发的意向策略，则数据包在转发到目标服务器的同时上传给控制器（3）控制器根据逆向策略进行迭代回溯重构出回溯路径。
在步骤一中，网络管理员为意向定义，不同的终端用户使用网络目的不同，例如作为提供网络服务的运营商和提供内容的内容提供商，为用户提供多样的服务，因此用户具有丰富的意向选择。因为网络资源大多具有统一资源定位符来标识，为了方便将用户意向定义为一类网址的集合。意向创建后，只需要使用 DNS 解析模块将资源地址解析成 IP 地址，意向定义成在网络上用户使用不同的设备，访问不同资源、服务。由 DNS 解析模块将已创建的意向策略（用户、视频、设备）转换成 IP 地址、以太网地址、端口等信息，并下发到回溯节点上。
DNS 解析模块负责对意向的创建、更新和维护，并不需要用户的干预。
在步骤二中，DNS 解析模块已将意向策略下发到交换机上。因此所有数据包都会被意向策略匹配一次，成功匹配的数据包被转发到目标服务器。同时交换机将最先匹配到意向的数据包上传到控制器。
在步骤三中，控制器先计算出整个网络的拓扑策略，也就是网络拓扑中的所有链路策略的集合。数据包进入控制器后，作为输入参数参与逆向策略（back policy）的计算，并将得出上一跳交换机，如此迭代计算后直到该数据包被丢弃或者回溯终止得出整个路径。
4.2 意向回溯策略
回溯策略既是控制器的上层应用，也可以作为网络服务提供给用户，意向性给网络管理员提供基于数据包的高级特征的匹配功能，而不是只能对数据包基于低层次特征如 IP 地址、端口进行回溯。为了满足网络管理员多样的需要和适应复杂的网络环境，增加了数据包的意向表示，以便网络管理员可以根据不同意向表达对应用、设备、控制器上的回溯操作。
4.2.1 带应用特征的意向回溯
对不同的业务，如视频、音乐、文件下载等，需要网络管理员细致的分类。但是无论如何，层出不穷的网络应用仍然难以区别。 对某一业务，如视频业务，如何将其定义为意向策略，是不是我们可以认为访问 video.baidu.com 的主机就是在使用视频业务呢？当然不是，可能用户正在查询、下载，或者只是在网页上浏览，我们无法确定用户在某一时刻的行为。但是事实是用户访问了 video.baidu.com,就知道用户的主要意向在观看视频，而不是为了查询，因为如果仅仅为了查询，显然专业的搜索引擎更加有用。这样就可以将视频应用意向广义地定义为“访问网址 video.baidu.com 的数据包”.
在视频意向的网址集合中添加视频网站的网址，控制器根据定义的意向策略，下发到回溯节点，这样实现“回溯用户访问网址 video.baidu.com 的数据包”.首次成功匹配的数据包上传到控制器进行回溯操作，并将回溯到的数据包路径返回给用户。现实网络环境总是处在不断变化之中，例如在内容分发网络中，由于同样的网址可能解析出不同的 IP 地址，并且这些 IP 地址被不同的应用共享，即应用服务器对应多个提供不同的服务 IP 地址，如何正确区分出视频服务还是其他的服务，对于网络的管理员来说总是挑战。即使 DNS 动态解析出应用服务器对应的所有的 IP 地址，还需要知道视频网站的源 IP 地址才能知道确定一个应用特征。
4.2.2 带控制器特征的意向回溯
在 SDN 回溯系统中，控制器的作用是最重要的，负责意向策略的下发和支持回溯策略的计算。在单一控制器环境中，问题相对简单。我们只要保证意向策略编写正确，准确下发到交换机，交换机能够与控制器正常通信就可以完成意向回溯。
在多控制器环境中，来自不同控制器之间的信息交换显得格外重要。由于控制器间信任关系复杂，来自外部网络安全方面的压力不断阻碍新技术的应用。如果可以在设计初期对控制器进行统一标识，用于不同控制器间的信息交互，但是在现有控制器框架下，并没有看到这方面成熟的技术。增加认证中心对控制器以及管理员用户进行身份认证可以有效解决信任问题。这样通过 SDN 可编程接口解决控制器统一标识问题，下发的意向策略就能够区分出控制器的特征，通过权威认证中心的认证就可以解决控制器的管理员的身份认证问题。这样我们可以给控制器 IP 地址一个认证的域名“c0.controller.org”.假设每个控制器是有唯一的网络管理员，这样我们就认为，如果控制器是安全的，那么控制器的属性由管理员确定，而不是由 IP 地址决定，因为 IP 地址是可以轻易伪造的。因此通过定义这样的意向“回溯控制器 C0的数据包”这样意向回溯的目标是可以实现的。能够实时回溯到数据包的路径会有助于快速定位网络故障，同样如果数据包携带控制器信息，在匹配的时候就可以通过在意向策略，只回溯指定的控制器的数据包。这样网络管理员可以就通过在回溯节点捕获到的数据包，当然这种回溯还是仅限于本控制器拓扑范围以内，在跨控制器回溯方面则需要不同控制器合作完成。
4.2.3 带移动设备特征的意向回溯
SDN 网络中存在设备的多样性是无论如何都无法忽视的。同一个用户可能将自己的网络设备如手机随身携带到任何地方并连接到互联网。对这种单个用户的网络设备的上网特征如果仅从设备的物理地址开始进行回溯是非常困难的，但是假设讨论某一个区域内移动设备的上网特征则容易的多。
网络中大多数手机、平板、PDA 等移动设备都可以通过浏览器请求网页服务，在服务器端则可以通过请求数据包判断其是否来自于移动设备，并将其适用于移动设备显示的页面返回给用户。在这里，如果我们将访问结果进行归纳分析的话，则可以推断出“从网址mobile.baidu.com 的数据包都来自于移动设备”.基于这个判断，因此可以这样定义移动设备的意向特征“从网址 mobile.baidu.com 的数据包都来自于移动设备”.在不考虑某些移动设备属于某个用户的情况下，将移动设备意向广义地定义为“从网址 mobile.baidu.com 的返回数据包”.如前所述，如果站在用户的角度，在网络中所有用户的接入的移动设备进行回溯是很困难的。但是站在网络管理员的角度，只对经过回溯节点的“回溯从网址 mobile.baidu.com的返回数据包”则是相对容易实现的，这种实现更大范围内的对一类数据包行为的回溯，在意向回溯中也是更有价值的。
4.3 意向回溯实验验证
根据上述意向回溯策略的实现目标，本节对 Pyretic 运行时环境进行扩展来支持所定义的策略。运行时环境还负责对所有用户编写的高级策略进行编译并转换成 OpenFlow 流规则下发到交换上。Pyretic[53]提供了这样一个运行时环境，提供在多种拓扑环境中，使用多种策略，在 Mininet[54]对数据包进行意向回溯测试的分析。本节从模块化编程、拓扑策略、迭代回溯三个方面详细描述意向回溯的实现过程。
下面介绍应用策略的编写过程方法，Pyretic 运行时环境提供了意向回溯策略的语法框架，允许对数据包的“虚拟包报头”进行直接操作。Pyretic 平台还为用户提供了模块化编程的扩展接口，网络管理员通过 drop、fwd（port）、flood 等原语对数据包进行操作，还支持对数据包进行类似数据库语言中“groupby”分组查询操作，由其运行时系统负责将这些“虚拟包报头”编译成 OpenFlow 交换机可以理解的流规则并下发到交换机上。因为对于每个数据包报头域来说，Pyretic 会将其视为一个 key-value 的对应关系，这样编程时只要对主键进行扩展，就可以完成对运行时环境的对更多匹配域的扩展，每个 key 可以对应多个不同的 value,支持用户自由地对数据包报头上字段进行栈上入栈、出栈操作，并且对于多个应用策略现已支持并行和串行两种组合操作。只要编写符合语法规则的程序，运行时系统会自动将高级策略转换成流规则的下发到 OpenFlow 交换机上。
4.3.1 模块化组件
按照前面的定义，将 video.baidu.com 看作视频应用，或者将主机上开启的 80 端口看作网页应用。视频应用不仅仅只包含 video.baidu.com 这个网址，但是视频应用意向指定的是video.baidu.com,只要匹配 video.baidu.com 的数据包就默认是视频应用。
NetAssay[52]意向监控的 DNS 解析模块的运行方式类似，我们的模块化组件分成两部分，元数据引擎和控制应用组件。不同的是元数据引擎（Metadata Engine）由控制应用组件进行管理，通过扩展 Pyretic 的运行时环境以支持更多意向策略匹配。以视频意向为例，假设我们有 3 个提供视频业务的服务器：180.149.133.169,180.149.133.159,180.149.133.139,而且它们共享同一个网络网址以便提供高质量的服务。
首先扩展元数据引擎对意向进行标识，指定视频意向的网络地址集合，以支持视频类型的意向策略的创建及维护。其工作原理就是当把元数据引擎支持的视频意向创建，会转换成流规则下发到指定交换机上，以后当有用户访问视频网络地址的请求数据包经过该交换机后，会自动匹配后按定义的动作执行。
根据需要修改控制应用（Control Application）支持该元数据引擎的扩展。意向策略创建后，控制器对指定的交换机可以使用高级特征进行意向匹配，在低级特征如 IP 地址、端口发生变化时，由元数据引擎负责实时更新当前的高级特征。
4.3.2 拓扑策略
网络对象[53包含的三种不同元素：拓扑、策略、派生网络与真实网络的映射。利用 Pyretic提供的拓扑策略的函数集，我们可以方便地模拟出以太网网关、路由器等多种功能网络中间件。在意向回溯模型中，我们利用派生网络模型的便利，在不同网络拓扑环境中检验模型的可靠性。
链路策略将转发策略与拓扑策略区分开，数据包在链路上的转发策略，如图 4.2 所示，可以其定义为从交换机 b 到 a 的链路策略Lba:
转发策略同网络拓扑 T 的关系可以表示成将 P 应用到 T（如P ? T）。这样数据包在进入交换机，从进入交换机的到离开，数据包在链路上运行的链路策略。在数据包从交换机的某一端口离开后，通过链路策略进入下一个交换的端口。这样结果就是既能对数据包的转发进行控制，也能对数据包的在链路上的传输进行控制。
4.3.3 迭代回溯
由于元数据引擎把意向策略的下发到回溯节点上，而回溯策略计算只需在控制器上进行，因此二者可以互不干扰地进行。
接下来观察数据包在端口 2 和端口 3 上的状态，以端口 2 为例，由于链路 ab 已经按照公式 4.1 写好链路策略，数据包在通过该链路时，从交换机 a 的端口 2 发出的数据包会从交换机 b 的端口 1 和端口 2 进入。这是因为交换机 b 有两个端口，而链路策略并不能明确是从哪个端口进行回溯，因此两个端口都需要进行回溯。
在此次回溯迭代中，在交换机 b 上有数据包 x 的两个副本，再根据逆向策略P?1,匹配srcip=1*后，只有从端口 2 进入的数据包会从交换机的端口 1、端口 2 继续回溯下去，而从端口 1 进入的数据包因为没有匹配项而被丢弃。根据同样的原因，Lbc1同样会继续把数据包 x 复制 3 份，回溯到交换机 c 的端口 1,2,3,由于端口 2,3 无法匹配到转发规则而丢弃，回溯至交换机 c 的端口 1.在网络未出现故障时回溯结果是 a->b->c->主机，但是发现回溯结束后出现另外两种结果之一：a->b;d->c 和 a->b->c->丢弃，需要使用第五章的方法进行故障排除。
4.4 本章小结
本章主要通过介绍意向策略在数据包回溯过程中的应用，用户通过意向回溯接口进行数据包回溯，不必关心底层 IP 地址、端口等操作内容，用户意向特征的定义范围包括控制器特征、应用特征、移动设备特征。在带有意向性的数据包回溯系统中，用户自定义意向，根据意向对数据包进行过滤并交由控制器进行回溯，提高了回溯的实用性。回溯系统的设计重点在于意向的定义并且设计编程接口提供给用户调用。回溯策略在控制器上根据转发策略的逆向计算即可得出，无需浪费数据平面的资源。意向策略由控制器创建并下发到交换机，同时可以随着网络拓扑的变化实时维护，自动启动回溯过程。整个意向回溯过程并不需要用户进行人为的干预，具有实时性这个特点。
