ARP 代答功能需求分析与实现设计
NES 对 ARP 报文的处理分两种情况：
eNB 发出的 ARP
MEC GW 发出的 ARP
eNB 发出的 ARP
eNB 需要和 EPC 通信，需要知道其 MAC 地址，当 eNB 发出 ARP Request 到 Upstream，NES_IO 会将该 ARP Request 报文从 Downstream 透传出去，EPC 收到 ARP Request 后发出的 ARP Reply 也会从 Downstream 进入，NES_IO 再透传到 Upstream 出去。因为 NES 没有 ARP 类型的 Ring，对于二层数据帧会直接走 default route（透传）。
MEC GW 发出的 ARP
当 MEC GW 收到 UE 发出的访问报文（IP 数据包）后，MEC GW 首先会发出一个 ARP Request 询问 UE 的 MEC 地址，但实际上 UE 不是一个主机（没有网卡），而且 GTP-U 报文只封装了 UE 发出的 3 层 IP 数据包，没有二层数据帧。所以，从 eNB 发出的报文不具有 UE MAC 地址信息，就算 LBP 把 ARP Request 封装并原路返回也没有意义。这就要求 LBP Port 具有 ARP 代答的功能，这是由 NTS 来完成的。
注：手机接入蜂窝网络时是没有 MAC 地址这一说法的，MAC 是为了找到有线网卡，但是 UE 是无线接入的。而当 UE 使用 WIFI 的时候，会得到一个 Wi-Fi 无线网卡的 MAC 地址，但这时手机就不走蜂窝网络了而是走 Internal 网络。
流程如下：
MEC GW 发出对 UE IP 10.0.0.2 的 ARP Request（图中绿色框 PKT1）。
NTS 收到 ARP Request，经过 NTS 内部 match UE IP 获取到对应的 eNB 的 MAC，并以该 MAC 构造 ARP Reply 报文，再通过 LBP 发出（图中紫色框 PKT2）。
注：蓝色框为 UE 正常访问大网 DN 时，报文中 MAC 地址的转换过程，方向：gtpu-pkt1 → gtpu-pkt2 → gtpu-pkt3。
代码实现：
NTS 解析 MEC GW 发出的 ARP Request
函数接口：
struct arp_head_s * nts_edge_arp_check(struct rte_mbuf *mbufs)
通过 UE IP 查询 NTS 内部存储的 learning_route table，获取到对应的 eNB MAC。
函数接口：
int nes_lookup_bulk_get(nes_lookup_table_t *lookup_table, const void **keys, int num_keys,void **result)
以 eNB MAC 构造 ARP Reply 报文，然后通过 LBP 发出。
函数接口：
int nts_edge_arp_edit(struct rte_mbuf *mbuf , struct arp_head_s * arphdr, const nts_enc_subentry_t *encap_data)
