CN108200199B - IPV4 over IPV6隧道场景中的负载均衡系统及方法 - Google Patents

Abstract

本发明公开了一种IPV4 over IPV6隧道场景中的负载均衡系统及方法，该系统包括至少一个客户端以及与客户端对应的网关，网关将客户端发出的IPv4数据包封装成IPv6数据包；还包括主服务器和至少一个AFTR处理器，主服务器的输入端与所有网关的输出端连接，网关将上行流量均发往主服务器,入口均采用统一的VIP，主服务器将所有目的IP是VIP的IPv6数据包全部将其MAC头部信息改换，并且存储记录AFTR处理器处理的用户信息，主服务器将目的MAC地址转换成相应的AFTR处理器的MAC地址，将请求分发给相应的AFTR处理器，AFTR处理器与资源网站进行通信。本发明解决了在IPv4 over IPv6隧道中数据包处理场景中，传统的负载均衡软件无法处理隧道数据包的问题，解决了服务器集群中的软件实现负载均衡的问题。

Description

IPV4 over IPV6隧道场景中的负载均衡系统及方法

技术领域

本发明属于信息技术领域，涉及一种数据传输系统及方法，具体涉及一种IPV4over IPV6(IPV4向IPV6的转换)隧道场景中的负载均衡系统及方法。

背景技术

我国IPv4地址规模永久性定格(3.32亿)、人均IP(Internet Protocol，网络之间互连的协议)地址持有量的永久性降低，已对新兴互联网经济(移动互联网、电子商务等)的可持续发展、我国信息化(三网融合、物联网、云计算、大数据等)的基础建设、国家信息化战略的部署实施(信息安全、互联网+、宽带中国、智慧城市等)造成严重制约。

目前，广电的IP承载网基本都是基于IPv4的，演进过程首先需要完成承载网对IPv6的支持，继而才能实现业务、认证系统、运营支撑系统等向IPv6迁移，因此，网络从IPv4向IPv6的升级是过渡的重点。网络过渡需要在降低对现网影响、保证业务连续性以及减少过渡成本的基础上，以渐进的过程实现网络的平滑升级，应该综合考虑地址分配方案及网管系统升级方案。

IPv6网络的过渡后期，IPv6流量已经超过IPv4流量，业务已经基本实现对IPv6访问的支持，此时应该以IPv6网络承载IPv4流量为主要方式进行最后阶段的演进。在IPv6网络的过渡后期，IPv6流量已经超过IPv4流量，IPv4协议栈的接入设备成为IPv6网络中的孤岛通信问题。

DS-Lite(Dual-stack lite，轻型双栈协议)是一种典型的IPv4 over IPv6隧道技术，DS-Lite隧道技术的工作原理是：用户侧设备将IPv4流量封装在IPv6隧道内，通过运营商的IPv6接入网络到达“网关”设备后终结IPv6隧道封装，再进行集中式NAT(NetworkAddress Translation，网络地址转换)转换，最终转发至IPv4网络。如图1所示，DS-lite网络主要由三个部分组成：

CPE(Customer Premise Equipment，用户侧设备)：也叫B4终端，位于用户网络侧、用来连接ISP(Internet Service Provider，互联网服务提供商)网络的设备，通常为用户网络的网关。CPE作为IPv4 over IPv6隧道的端点，负责将用户网络的IPv4报文封装成IPv6报文发送给隧道的另一个端点，同时将从隧道接收到的IPv6报文解封装成IPv4报文发送给用户网络。某些用户网络的主机本身也可以作为CPE，直接连接到ISP网络，这样的主机称为DS-lite主机。

AFTR(Address Family Translation Router，地址族转换路由器)：ISP网络中的设备。AFTR同时作为IPv4 over IPv6隧道端点和NAT(Network Address Translation，网络地址转换)网关设备。AFTR负责将解封装后的用户网络报文的源IPv4地址(私网地址)转换为公网地址，并将转换后的报文发送给目的IPv4主机；同时负责将目的IPv4主机返回的应答报文的目的IPv4地址(公网地址)转换为对应的私网地址，并将转换后的报文封装成IPv6报文通过隧道发送给CPE。AFTR进行NAT转换时，同时记录NAT映射关系和IPv4 over IPv6隧道对端设备(即CPE)的IPv6地址，从而实现不同CPE连接的用户网络地址可以重叠。

DS-lite隧道：CPE和AFTR之间的IPv4 over IPv6隧道，用来实现IPv4报文跨越IPv6网络传输。

实际的业务场景中，为提高系统的健壮性，并对用户请求进行任务调度，AFTR需采用集群方式。入口服务器采用统一虚拟IP地址，后台是具体AFTR服务集群。当某台设备发生故障宕机时，入口服务器通过心跳机制发现故障，并将后续请求重定向到其他AFTR可用服务器；入口服务器实时统计后台服务器的负载和运行状况，当接到新用户请求时，可合理调度任务，实现负载均衡。

负载均衡是将进入某一系统的负载分发至集群内各个服务器共同完成任务，并且处理该任务的每一服务器负荷相对均衡，负载均衡代表将一个系统请求分发至另一个独立系统同时处理请求的能力。

负载均衡技术不仅能提高系统可用性，还可以避免网络中关键节点故障。负载均衡技术的服务器集群采用的是对称式结构，集群中每台服务器的地位相等，当服务器池中的一台或几台服务器出现故障时，负载均衡调度器会将用户请求分发至可正常工作的服务器，不会因为单点故障导致整个系统崩溃，从而提高了服务质量。总体而言，负载均衡有以下优点：

负载均衡提高了集群的处理能力，缩短了用户等待时间；

负载均衡能够避免网络中的关键节点故障，为用户提供高效的服务；

集群采用负载均衡技术，能够有效利用资源，提高了系统的可用性。

在此应用场景之中，IPv4 over IPv6隧道对所有进入隧道的数据包进行了封装，其数据包格式发生变化，原始的数据包格式如图2所示，而经由隧道转发的数据包格式如图3所示，导致了利用传统的负载均衡软件无法正常工作，不能够满足实际工程的需求。

发明内容

本发明旨在至少解决现有技术中存在的技术问题，特别创新地提出了一种IPV4over IPV6隧道场景中的负载均衡系统及方法。

为了实现本发明的上述目的，根据本发明的第一个方面，本发明提供了一种IPV4over IPV6隧道场景中的负载均衡系统，其包括至少一个客户端以及与客户端对应的至少一个网关，所述网关将客户端发出的IPv4数据包封装成IPv6数据包；还包括主服务器和至少一个AFTR处理器，所述主服务器的输入端与所有网关的输出端均连接，所有网关将上行流量均发往主服务器,网关的入口均采用统一的VIP，主服务器将所有目的IP是VIP的IPv6数据包全部将其MAC头部信息改换，并且存储记录AFTR处理器处理的用户信息，主服务器将目的MAC地址转换成相应的AFTR处理器的MAC地址，将请求分发给相应的AFTR处理器，所述AFTR处理器与资源网站进行通信。

本发明的IPV4 over IPV6隧道场景中的负载均衡系统解决了在IPv4 over IPv6隧道中数据包处理场景中，传统的负载均衡软件无法处理隧道数据包的问题，解决了服务器集群中的软件实现负载均衡的问题。

在本发明的一种优选实施方式中，所述入口服务器通过心跳机制发现AFTR处理器故障,并将后续请求重定向到其他可用AFTR处理器。

保障服务的连续性，一旦某台的AFTR处理器发生故障宕机，发往该AFTR处理器的数据会重定向到另外的工作正常的AFTRAFTR处理器，保证的用户的请求能够被正常处理。

在本发明的另一种优选实施方式中，数据包上行时，用户请求数据包通过网关，到达主服务器，由主服务器判断后转发给AFTR处理器；数据包下行时，资源网站的数据包经过AFTR处理器直接流向网关，不再经过主服务器。

整个系统之中只有上行的数据请求会通过主服务器,下行数据由AFTR处理器直接经隧道传回至智能网关，因此主服务器的处理能力不会成为整个系统的瓶颈，影响系统的处理能力，缩短用户等待时间，提高系统整体吞吐率。

真实服务器可以运行任何操作系统来处理大量请求不需与主服务器建立隧道，数据直接返回给客户端提高了速度快并降低了成本。

为了实现本发明的上述目的，根据本发明的第二个方面，本发明提供了一种负载均衡方法，其包括如下步骤：

S1，客户端发送基本的请求数据包，数据包经过智能网关处理之后，封装成隧道格式的数据包，发送至主服务器；

S2，主服务器收集所有来自网关上的数据包，通过包过滤器对数据包过滤；由于通信会有各种类型请求的数据包，过滤之后可以只捕获有效的数据包。在本实施方式中，具体做法是利用Libpcap函数库里面的BPF函数，设置相应的过滤条件，具体设置可采用本领域中通用的设置方式。

S3，MAC(Media Access Control,介质访问控制)地址转换，在数据包进行拆分，将以太网头部信息中的源Mac，目的Mac替换为相应的地址，数据包重组之后转发新的数据包；替换之后相应的数据包字段改变，主机系统的TCP/IP协议栈自动重组数据包发送出去；

S4，AFTR处理器接受到由主服务器转发到的数据包，正常的服务交互之后，直接经过隧道返回回复的数据包至智能网关；

S5，AFTR处理器返回的数据包，由网关对隧道数据包解封装后返回给用户，完成一次完整的请求。

本发明解决了在IPv4 over IPv6隧道中数据包处理场景中，传统的负载均衡软件无法处理隧道数据包的问题，解决了服务器集群中的软件实现负载均衡的问题。

在本发明的另一种优选实施方式中，根据后端AFTR处理器连接数的多少将目的MAC地址转换成相应的AFTR的MAC地址。

首先确定AFTR处理器的的连接数多少，可以判断其负载状况，进而选择合理的均衡策略(例如加权轮询，最少连接)，保障每台服务器处理的业务请求相当，避免出现某台服务器工作繁忙，如果某台服务器空闲，影响用户请求的时延，保障业务的实时性，缩短用户等待时间，提升用户体验。

在本发明的另一种优选实施方式中，主服务器对数据包处理的具体方法为：

S61，主处理器的输入端开启，准备接收网关发送的数据包；

S62，主处理器接收每一个网关发送的数据包；

S63，主处理器对接收的数据包进行过滤；

S64，判断接收到的数据包的目的IP是否为VIP地址，如果不是，将数据包丢弃，如果是，则执行步骤S65；

S65，查询所有AFTR处理器的IP和MAC映射表；

S66，监测AFTR处理器是否宕机，如果是则将对应的AFTR处理器从处理器列表中剔除并添加记录到服务器列表，如果不是则执行步骤S67；

S67，查询所述AFTR处理器是否存在该条用户记录(每个用户的请求都会在相应的AFTR服务器上存在记录，即是否该用户的请求发送到AFTR服务器上)，如果是则将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；如果不是则查询服务器集群中的AFTR处理器列表，添加用户记录到连接数最少的AFTR处理器，记录其MAC地址，将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；

S68，改变目的MAC字段的数据包重组；

S69，数据包重新进入链路层转发至选定的AFTR处理器，结束。

有效处理了隧道数据包。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是现有技术中DS-Lite组网图；

图2是原始数据包格式；

图3是图2所述的数据包经过隧道封装之后的数据包格式；

图4用户借助DS-lite技术访问IPv4资源示意图；

图5是AFTR处理器集群示意图；

图6是本发明一种优选实施方式中系统的工作原理图；

图7是本发明一种优选实施方式中主服务器的负载均衡模块流程图；

图8是封装成隧道格式的数据包；

图9是重组之后转发新的数据包；

图10是主服务器转发的数据包。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

在本发明的描述中，除非另有规定和限定，需要说明的是，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是机械连接或电连接，也可以是两个元件内部的连通，可以是直接相连，也可以通过中间媒介间接相连，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语的具体含义。

在图4中，用户借助DS-lite技术实现用户资源访问IPv4资源。DS-lite技术包括B4和AFTR处理器两个主要部件，B4部署于家庭智能网关，用于建立必要的IPv4-in-IPv6隧道。AFTR处理器部署于城域网与资源池之间的IPv4/IPv6转换网关，用于实现隧道解封以及NAT44功能。

当用户访问IPv4资源时，借助DNS44服务器，用户首先发起一个DNS(Domain NameSystem,域名解析系统)解析请求，借助DNS44服务器获得待访问内容资源的公有IPv4目标地址。

此后，用户请求到达家庭智能网关时，网关会将IPv4请求数据包封装在IPv6数据包中，通过IPv4-Over-IPv6隧道传输到IPv4/IPv6转换网关。

转换网关将IPv4包解封装后，借助其NAT44功能同时将用户内网源私有IPv4地址转换为公网IPv4地址。该请求会被路由至IPv4资源服务器，从而实现双栈用户对IPv4资源的访问。

在AFTR处理器集群的场景中网络拓扑如图5所示，集群是一个相对较新的技术，使用一个集群服务器系统，可以实现高性能，低成本高收益。集群系统是计算机的集合，集合内的计算机是通过高性能网络物理连接的。集群内的计算机叫做节点，任意类型的计算机都可以充当节点。这些节点协同工作，以实现共同的任务，但是对外表现的是单一的映像，用户实际感知的是单个节点，即用户和集群系统相互通信时，集群就像一台超级服务器。

负载均衡群集，简称LBC，它的主要架构就是前端有一个或者多个负载均衡器，对于客户端的连接根据具体的算法均衡到一组真实服务器上，负载均衡用廉价的方法来拓宽带宽，提高服务器的通信能力和事物快响应和处理能力，同时该架构对于单点故障也可以避免。负载均衡的主要目的是提供快速的响应能力和数据处理能力，对于计算能力不做要求。当服务器提供的是服务时，要能同时响应大量请求，此时，负载均衡器就会把任务分发到各个节点处，节点数越多，整体的处理能力也就越强。所以，整体服务器系统提供的服务要优于单台服务器，简单来说，原来1000个用户请求被一个服务器承担，而现在1000个用户请求可以被10个服务器承担，响应速度明显会提高。

本发明所公开的一种IPV4 over IPV6隧道场景中的负载均衡系统，其包括至少一个客户端以及与客户端对应的至少一个网关，网关将客户端发出的IPv4数据包封装成IPv6数据包；还包括主服务器和至少一个AFTR处理器，所述主服务器的输入端与所有网关的输出端均连接，所有网关将上行流量均发往主服务器,入口均采用统一的VIP，主服务器将所有目的IP是VIP的IPv6数据包全部将其MAC头部信息改换，并且存储记录AFTR处理器处理的用户信息，主服务器将目的MAC地址转换成相应的AFTR处理器的MAC地址，将请求分发给相应的AFTR处理器，AFTR处理器与资源网站进行通信。

根据后端AFTR处理器连接数的多少将目的MAC地址转换成相应的AFTR的MAC地址，具体首先主服务器会查询到每台服务器的业务连接数，然后根据主服务器上存储的AFTR处理器的ip，Mac的映射表，选取最小连接AFTR处理器的IP对应的MAC地址，即刻做出正确的替换。

面对经过隧道之后的数据格式，传统的负载均衡软件无法对这种格式的数据包进行解析处理，导致无法直接对网络隧道的接口服务器实现处理,提出了一种新型的负载均衡技术。在IPv4 over IPv6隧道侧旁挂一台Master server负载均衡调度器，用来实现AFTR连接数的查询和任务调度，不是直接在B4上实现上述功能，减少了B4上的负载压力。

同时利用自主研发的模块实现数据包关键字段的修改，在二层实现转发来完成用户请求，所以要求均衡调度器和所有真实服务器需要通过交换机连接。

整个模块基本实现原理图如图6所示：

1，客户端发送基本的请求数据包，数据包经过智能网关B4处理之后，封装成隧道格式的数据包，发送至负载均衡器主服务器，具体的数据包格式为图8所示。

2，负载均衡器主服务器收集所有来自网卡上的数据包，通过包过滤器对数据包过滤。

3，MAC地址转换，在数据包进行拆分，将以太网头部信息中的源Mac，目的Mac替换为相应的地址，数据包重组之后转发新的数据包，如图9所示。

4，AFTR处理器接收到由主服务器转发到的数据包，如图10所示，正常的服务交互之后，直接经过隧道返回回复的数据包至智能网关B4。

5，服务器端返回的数据包，由B4对隧道数据包解封装后返回给用户，完成一次完整的请求。

负载均衡模块的核心是改写报文的MAC地址来完成用户请求，所以负载均衡器和所有真实服务器通过交换机连接，在同一网段内，且真实服务器必须在本地环路接口上配置虚拟IP地址。负载均衡调度器接收发送至VIP的包，将数据帧的MAC修改为某一内容节点的MAC,并不需要用户对请求服务的数据包进行修改。发送到内容服务器的组通过直接路由方式返回给用户。

利用DS-lite,在客户端发送基本应用请求，经过家庭网关B4，将数据包封装成IPv6数据包，所有上行流量均发往Master server,入口均采用统一的VIP(此VIP是隧道端点的虚拟IPv6地址)。利用Master server中自主开发的负载均衡模块，将所有目的IP是VIP的数据包全部将其MAC头部信息改换，并且存储记录AFTR处理的用户信息，根据后端AFTR服务器连接数的多少，将目的MAC地址转换成相应的AFTR的MAC地址，将请求分发给相应的AFTR,从而实现负载均衡，达到减小单台AFTR的负载压力，缩短用户请求等待时间等目的。

主服务器通过心跳机制发现AFTR故障,并将后续请求重定向到其他AFTR可用服务器。数据包流向：上行时，用户请求数据包通过B4，到达主服务器，由主服务器判断后转发给后续AFTR；下行时，资源网站的数据包经过AFTR直接流向B4，不再经过主服务器，避免在主服务器处形成瓶颈，整个负载均衡模块的工作流程如图7所示。

在本实施方式中，主服务器对数据包处理的具体方法为：

S61，主处理器的输入端开启，准备接收网关发送的数据包；

S62，主处理器接收每一个网关发送的数据包；

S63，主处理器对接收的数据包进行过滤，具体可以但不限于利用pcap_setfilter()设置包的过滤条件；

S64，判断接收到的数据包的目的IP是否为VIP地址，如果不是，将数据包丢弃，如果是，则执行步骤S65；

S65，查询所有AFTR处理器的IP和MAC映射表；

S66，监测AFTR处理器是否宕机(具体主服务器可通过心跳机制发现AFTR处理器故障)，如果是则将对应的AFTR处理器从处理器列表中剔除并添加记录到服务器列表，如果不是则执行步骤S67；

S67，查询所述AFTR处理器是否存在该条用户记录，如果是则将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；如果不是则查询服务器集群中的AFTR处理器列表，添加用户记录到连接数最少的AFTR处理器，记录其MAC地址，将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；

S68，改变目的MAC字段的数据包重组；

S69，数据包重新进入链路层转发至选定的AFTR处理器，结束。

图8至图10这三个图的是图6所示的系统进行数据传输时的数据包变换示例，和原理说明部分对应，标出的字段就是变换的部分；数据包拆分解析之后，变换数据包内部的关键字段(变换就是重新赋值)再重组数据包并发送。例如，图8中，以太网首部中，MAC1在MAC2之前，表示数据由用户传输至网关，网关的MAC与主服务器的MAC均为MAC2，当数据由MAC3传回时直接传输至MAC1。并且传输时，数据IPV6的首部也发生了相应的变化，例如图中示例的形式。

本发明解决了在特定场景中的，即在IPv4 over IPv6隧道中数据包处理场景中，传统的负载均衡软件无法处理隧道数据包的问题，解决了服务器集群中的软件实现负载均衡的问题。本发明保持了传统的直接路由模式带来的优点，整个系统之中只有上行的数据请求会通过,下行数据由AFTR直接经隧道传回至智能网关，因此主服务器的处理能力不会成为整个系统的瓶颈，影响系统的处理能力，缩短用户等待时间，提高系统整体吞吐率。本发明真实服务器可以运行任何操作系统来处理大量请求不需与主服务器建立隧道，数据直接返回给客户端提高了速度快并降低了成本。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

Claims (6)

1.一种IPV4 over IPV6隧道场景中的负载均衡系统，其特征在于，包括至少一个客户端以及与客户端对应的至少一个网关，所述网关将客户端发出的IPv4数据包封装成IPv6数据包；还包括主服务器和至少一个AFTR处理器，所述主服务器的输入端与所有网关的输出端连接，所有网关将上行流量均发往主服务器,网关的入口均采用统一的VIP，主服务器将所有目的IP是VIP的IPv6数据包的MAC头部信息改换，并且存储记录AFTR处理器处理的用户信息，主服务器根据后端AFTR处理器连接数的多少将目的MAC地址转换成相应的AFTR处理器的MAC地址，将请求分发给相应的AFTR处理器，所述AFTR处理器与资源网站进行通信。

2.根据权利要求1所述的IPV4 over IPV6隧道场景中的负载均衡系统，其特征在于，所述主服务器通过心跳机制发现AFTR处理器故障,并将后续请求重定向到其他可用AFTR处理器。

3.根据权利要求1所述的IPV4 over IPV6隧道场景中的负载均衡系统，其特征在于，数据包上行时，用户请求数据包通过网关，到达主服务器，由主服务器处理后转发给AFTR处理器；数据包下行时，资源网站的数据包经过AFTR处理器直接流向网关，不再经过主服务器。

4.一种用于权利要求1-3之一所述IPV4 over IPV6隧道场景中的负载均衡系统的负载均衡方法，其特征在于，包括如下步骤：

S1，客户端发送基本的请求数据包，数据包经过智能网关处理之后，封装成隧道格式的数据包，发送至主服务器；

S2，主服务器收集所有来自网关上的数据包，通过包过滤器对数据包过滤；

S3，MAC地址转换，在数据包进行拆分，将以太网头部信息中的源Mac，目的Mac替换为相应的地址，数据包重组之后转发新的数据包；

S4，AFTR处理器接收到由主服务器转发到的数据包，正常的服务交互之后，直接经过隧道返回回复的数据包至智能网关；

S5，AFTR处理器返回的数据包，由网关对隧道数据包解封装后返回给用户，完成一次完整的请求。

5.根据权利要求4所述的负载均衡方法，其特征在于，根据后端AFTR处理器连接数的多少将目的MAC地址转换成相应的AFTR的MAC地址。

6.根据权利要求4所述的负载均衡方法，其特征在于，主服务器对数据包处理的具体方法为：

S61，主处理器的输入端开启，准备接收网关发送的数据包；

S62，主处理器接收每一个网关发送的数据包；

S63，主处理器对接收的数据包进行过滤；

S64，判断接收到的数据包的目的IP是否为VIP地址，如果不是，将数据包丢弃，如果是，则执行步骤S65；

S65，查询所有AFTR处理器的IP和MAC映射表；

S66，监测AFTR处理器是否宕机，如果是则将对应的AFTR处理器从处理器列表中剔除并添加记录到服务器列表，如果不是则执行步骤S67；

S67，查询所述AFTR处理器是否存在该条用户记录，如果是则将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；如果不是则查询服务器集群中的AFTR处理器列表，添加用户记录到连接数最少的AFTR处理器，记录其MAC地址，将数据包的目的MAC替换为AFTR处理器的MAC，执行步骤S68；

S68，改变目的MAC字段的数据包重组；

S69，数据包重新进入链路层转发至选定的AFTR处理器，结束。

Images