一文读懂带内网络遥测技术

随着业务应用的推陈出新和用户规模的不断增长，网络呈现出“高速率、大规模、多接入、不可预期”的特点。传统网络管控方式和手段已经难以解决现有网络和未来网络的挑战。

[[311748]]

 

因此，网络管理者迫切需要颠覆传统网络监测及故障排除方法，提出能够应对网络状态测量、网络失效检测、故障定位与恢复等场景用例的实时灵活的测量解决方案。

P4开创了数据平面可编程的新时代，这为网络管控提供了从数据平面直接获取状态信息的崭新途径。数据平面可编程技术的平台无关、协议无关和可重构性使网络管理者可以重塑网络测量及网络管控流程。

[[311749]]

 

图1 Nick McKeown 教授于2014 年首次设计并提出了数据平面特定领域编程语言P4

2、传统网络测量

网络测量是网络管控的基础手段和数据来源。按照测量方式的不同，传统意义上的网络测量(Network Measurement)可以分为主动测量(Active Measurement)、被动测量(Passive Measurement)和混合测量(Hybrid Measurement)。

主动测量通过向网络中主动发送探测分组，并根据探测分组受网络影响而发生的特性变化来分析网络行为。被测量的网络性能指标通常是丢包率、延迟、抖动、TTL和带宽等。常见的主动测量协议包括PING、Traceroute、IP测量协议(IP Measurement Protocol，IPMP)、单向主动测量协议(One-Way Active Measurement Protocol，OWAMP)、双向主动测量协议(Two-Way Active Measurement Protocol，TWAMP)、MPLS丢包/延迟测量协议(MPLS L/DM Protocol)等。

主动测量的优点是使用灵活，缺点是给网络增加额外带宽/处理开销，往往会引起海森堡效应(Heisenberg effect)，即观察者的介入干扰测量结果。

被动测量通过捕获流经测量点的分组来测量网络状态、流量特征和性能参数。被动测量使用控制平面消息即可监测网络流量状态性能，被监测的性能指标通常是包/字节统计值、协议类型、队列长度和延迟统计信息。常见的被动测量协议有网络数据流统计协议(Cisco Netflow)、sFlow、IP流量信息输出协议(IPFIX)、数据包采样协议(PSAMP)。

被动测量不会产生额外的测量负载，因此不会影响网络本身特性。但被动测量往往只能监测交换节点本地状态信息，而不能监测网络状态和丢包率等全局状态信息。

混合测量通过灵活组合主/被动测量方法，或结合主/被动测量优点重新设计测量机制的方式，对网络进行协同测量。典型代表有反应式测量(Reactive Measurement)、带内测量(In-band Measurement)和交替标记性能测量(Alternate Marking-Performance Measurement，AM-PM)。

表1 网络测量方案及其分类

 

带内测量是近几年兴起的一种混合测量方法，通过路径中间交换节点对数据包依次插入元数据(Measure metadata)的方式完成网络状态采集。相较于传统网络测量方案，带内测量能够对网络拓扑、网络性能和网络流量实现更细粒度的测量。目前，带内测量的研究方向主要为IETF IPPM工作组[1]和OPSA工作组主导的带内OAM(In-situ Operation Administration and Maintenance，IOAM)和P4联盟主导的带内网络遥测(In-band Network Telemetry，INT)。

3、带内网络遥测

带内网络遥测由Barefoot、Arista、Dell、Intel和VMware于2015年共同提出[2]，是一种不需要网络控制平面干预，网络数据平面收集和报告网络状态的框架。在带内网络遥测架构中，交换设备转发处理携带遥测指令(Telemetry instructions)的数据包。当遥测数据包经过该设备时，这些遥测指令告诉具备网络遥测功能的网络设备应该收集并写入何种网络状态信息。

如图2所示，带内网络遥测系统由遥测服务器和具备带内网络遥测功能的交换机组成。根据实际遥测任务的需要，该系统还可能需要时间同步服务器等设备完成辅助工作。

带内网络遥测的数据包处理流程如下：1.普通数据报文到达带内网络遥测系统的第一个交换节点时，带内网络遥测模块通过 在交换机上设置的采样方式匹配并镜像出该报文，根据遥测任务的需要在四层头部后插入INT头部，将INT头部所指定的遥测信息封装成元数据(MetaData，MD)插入到INT头部之后;2.报文转发到中间节点时，设备匹配INT头部后插入MD;3.报文转发到带内网络遥测系统最后一跳时，交换设备匹配INT头部插入最后一个MD并提取全部遥测信息并通过gRPC等方式转发到遥测服务器。4.遥测服务器解析遥测报文内的遥测信息，上报给上层遥测应用程序。

 

图2 带内网络遥测工作流程

既有方案一：P4-based INT

基于P4实现的带内网络遥测(P4-based INT)是最早的带内网络遥测实现方案[3]。P4-based INT包括两种实体：INT traffic sources和INT traffic sinks。INT traffic sources负责将遥测指令嵌入到正常数据包或遥测数据包中。INT traffic sinks对遥测结果进行提取和上报。INT traffic sources和INT traffic sinks可以是应用、终端网络协议栈、网管程序、NIC、发送侧/接收侧ToR交换机等。

表2 带内网络遥测系统术语及其说明

 

随着逐跳增加INT元数据，遥测数据包大小逐渐增加，这可能导致数据包大小超过链路MTU值。P4-based INT给出了两种解决方案：(1)根据INT跳数及逐跳元数据长度适当增大链路MTU配置值;(2)根据三层路径MTU发现机制确定逐跳链路MTU，中间节点根据遥测数据包长度选择是否插入遥测数据。

既有方案二：INT in 6TiSCH

Abdulkadir Karaagac等人将带内网络遥测从有线网络拓展到无线网络场景中[4]，针对工业无线传感器网络提出了一种带内网络遥测方案INT in 6TiSCH。该方案以最小化资源消耗和通信开销作为设计目标，能够处理6TiSCH网络功能异常监测、拥塞控制、集中路由和调度管理等场景和用例。

INT in 6TiSCH在IEEE 802.15.4 MAC帧中Information Elements(IEs)字段插入遥测数据。遥测报文由三部分组成：IEs Subtype ID、INT Header及INT Content。

其中，INT Header由三部分组成：INT Control header(8 bits)、Sequence Number(8 bits)及Bitmap(8 bits)。INT Control header用于定义遥测模式及遥测功能。Sequence Number用于区分来自同一节点的不同INT遥测数据。Bitmap中每个bit位代表一种预定义的遥测数据。

 

图3 INT in 6TiSCH中插入的INT报文格式

值得注意的是，INT Control header中的HBH Mode(2 bits)定义了三种遥测模式，当Mode=00时，中间节点全部遥测;当Mode=10时，中间节点将随机添加遥测数据;当Mode=01时，中间节点根据上一次添加遥测数据的时间、转发帧长度及剩余跳数计算概率值，并依据概率值进行遥测数据添加。HBH Mode在一定程度上能够降低带内网络遥测的带宽开销。

Bitmap Mode定义了两种位图模式：内容位图(Content Bitmap)和节点位图(Node Bitmap)。内容位图模式下，中间节点将依据Bitmap字段的遥测组合进行遥测数据的添加。节点位图模式下，中间节点允许自行添加位图及INT数据。

INT in 6TiSCH定义的遥测数据模型包括：Node ID(2 Byte)、Receive Channel & Timestamp(2 Byte)、Utilization indicator(1 Byte)、RSSI(1 Byte)及其他保留信息类型。

既有方案三：NetVision

Zhengzheng Liu等人提出了网络遥测即服务的概念[5]，并设计了带内网络遥测平台NetVision。NetVision主动发送与网络状态和遥测任务相匹配的适当数量和格式的探针数据包，降低了遥测开销，提高了网络遥测的覆盖性和可扩展性。在路径规划方面，NetVision采用段路由进行简单灵活的路由控制，通过更改SR标签的方式定制探测路径。

为了降低网络管理员部署带内网络遥测的难度，NetVision设计了一套包括遥测元数据和查询原语在内的遥测原语，并封装为遥测服务API，可以对外提供端到端延迟测量、实时包传输速率计算、链路/节点包黑洞发现等功能。

 

图4 NetVision架构及处理流程

NetVision探针为“SR+INT”双栈结构，SR Stack包括SR列表长度和输出端口标签，INT Stack包括标签列表长度和遥测标签列表。路由器通过弹出SR标签并放入INT标签完成一次遥测转发。

 

图5 NetVision探针封装格式

既有方案四：INTCollector

INTCollector是一种针对带内网络遥测计算及数据存储开销大的问题而设计的从带内网络遥测原始数据中提取并过滤重要网络信息的机制[6]。INTCollector只过滤诸如新流到达或逐跳延迟剧烈变化等重要网络事件，并将重要网络时间存储在时间序列数据库中，从而降低CPU使用率和存储成本。INTCollector为INT信息处理设计了快慢两条通道，快通道用于处理INT报告数据包，慢通道用于处理重要事件并将其存储到数据库中。实验结果表明，INTCollector机制可以将带内网络遥测存储数据量减少2-3个数量级，并降低遥测服务器负载。

综上所述，带内网络遥测是一种随路测量方案。因此，带内网络遥测存在一些固有的缺点。首先，带内网络遥测检测范围有限，预先定义的随路检测特性使得带内网络遥测往往无法及时获得全网全状态的网络视图。因此带内网络遥测只能监测特定路径上的某些数据包的遥测数据。其次，由于将遥测指令和数据封装到正常数据包中，正常数据包的有效载荷比降低，遥测开销较大。最后，遥测指令和数据的构造、封装、填充和提取等环境增加了交换机处理负担。

值得注意的是，与带内网络遥测相对应的是带外网络遥测(Out-band Network Telemetry，ONT)。带外网络遥测通过监控设备单独发送探测报文，收集链路状态信息。探测报文与网络业务无关，因此测量结果并不准确。带外网络遥测与带内网络遥测的遥测数据包生成、接收处理流程不同，对网络本身产生的影响和测量精度也不相同。严格来说，带外网络遥测应属于主动遥测的范畴。

传统网络测量技术因其静态、低效、开销大等缺陷，在网络状态监测与管理上存在精度和时效性等性能问题。因此，带内网络遥测系统亟需解决以下几个技术需求：

• 性能

带内网络遥测系统应能根据遥测需求，快速生成并下发遥测方案，上报网络状态信息。

• 可拓展性

带内网络遥测系统应能够应对未来网络异质化和高速化挑战，满足各类服务的遥测需求。

• 轻量级

有限的网络资源导致网络带内网络遥测系统必须是轻量级的，以减少资源消耗和通信开销。

• 鲁棒性

网络遥测系统应该能够应对网络节点或链路故障，不依赖于特定的遥测服务器或网络节点进行部署，并且能够适应网络状态频繁变化。

• 安全性

对用户数据包的遥测操作可能伴随着用户隐私泄露和安全风险问题。因此，带内网络遥测需要研究如何通过技术手段减少对用户数据的影响。

4、带内网络遥测应用

带内网络遥测技术的应用范围已经从最初的网络运维可视化、故障定位拓展到了网络测量、拥塞控制、路径决策、流量工程和网络数据平面验证等领域。

 

[[311750]]

4.1网络测量

 

为了满足网络运行、维护和安全的需要，控制平面需要实时获取网络流量状态。网络查询成为日渐兴起的研究领域。常见的网络查询包括：大小流检测、异常流量检测等。带内网络遥测可以收集统计的网络状态信息如表3所示。

表3 带内网络遥测统计信息分类

 

现有遥测系统可以实时收集和分析测量数据，但存在两个普遍问题：(1)仅支持单一遥测任务;(2)处理和存储开销随流量及查询量增加而增大。

学术界的研究人员也关注到了上面的问题，Arpit Gupta等人针对遥测提供了一个声明式接口，可以满足11种遥测任务的查询需求[7]。这11种遥测任务包括：TCP新建连接查询、Slowloris DOS攻击查询、Zorro Attacks查询、SSH暴力破解攻击查询、Superspreader、端口扫描查询、DDoS攻击查询、TCP SYN Flood攻击查询、TCP Incomplete Flows查询、DNS Tunneling检测查询、DNS反向攻击查询。

网络状态测量也是带内网络遥测在产业应用方面最为典型的场景。Barefoot 推出的Deep Insight是全球首个可以运行在商业级服务器上的提供逐包状态监测的网络系统，能够实时解释、分析和定位数据包延迟发生的原因和位置[8]。结合机器学习技术，Barefoot Deep Insight可以在纳秒级分辨率上实现对网络性能的有状态自动化异常监测。

 

 

图6 DeepInsight的口号便是纳秒级逐数据包洞察

 

 

 

[[311750]]

4.2微突发检测

 

微突发(Microbursts)是指端口在非常短的时间(毫秒级别)内收到非常多的突发数据，以至于瞬时突发速率达到平均速率的数十倍、数百倍，甚至超过端口带宽的现象。受限于秒级流量监控周期的技术局限性，SNMP协议或网络性能检测工具很难采集毫秒级的微突发流量。带内网络遥测通过在数据包转发时刻记录交换机队列长度的方式便可以轻松检测网络微突发程度。

图7 基于遥测的微突发检测[9]

 

 

[[311750]]

3故障快照

 

由于网络遥测通过端口计数器、数据包采样和hop-by-hop带内遥测等方式提取网络状态数据，因此会产生大量的遥测数据。由于这类遥测数据缺乏关于异常网络行为的上下文状态和可操作信息，网络管理员不得不采用各类状态监测工具进行长时间的巨量数据分析，才能找到网络问题的根本原因。针对这一问题，Mellanox提出故障快照 (What Just Happened，WJH)技术[10]。

 

[[311751]]

 

图8 故障快照 (What Just Happened，WJH)

 

 

故障快照技术利用Mellanox Spectrum™和Spectrum™-2以太网交换机芯片，以T-比特级别的速率检测所有端口上的数据包，然后识别异常行为，并将其整合为简洁、具体且可操作的数据，从而简化网络故障排除和快速恢复。

4.4拥塞控制

 

网络源端可以利用带内网络遥测提供的丰富的网络状态信息进行拥塞避免和控制。

速率控制协议(Rate Control Protocol，RCP)通过调整链路容量分配进行拥塞控制。网络中的每个RCP路由器根据入口链路利用率、平均队列长度、流平均RTT等网络状态参数周期性计算每条链路上的公平共享速率(Fair-share rate)。

RCP*是在RCP基础上设计的针对个流状态统计的拥塞控制方案。RCP*在终端主机上针对每个流部署速率限制器和速率控制器。网络控制平面为每个流分配AppSpecific_0和AppSpecific_1两个内存地址存储公平速率。其中，AppSpecific_0储存当前公平速率版本号，AppSpecific_1存储真正的公平速率。每个流的速率控制器周期性通过“收集-计算-更新”三个阶段查询和更新网络状态。

在收集阶段，速率控制器以毫秒为周期统计逐跳交换机ID、队列长度、链路利用率和链路公平共享率(即AppSpecific_0值和AppSpecific_1值)。

在计算阶段，发送方速率控制器根据收集信息计算延路每条链路的平均队列长度，然后使用RCP拥塞控制算法计算每条链路的公平共享速率R_link。

在更新阶段，每个流的速率控制器异步更新所有链路上的公平共享速率。

由于RCP*在每个RTT周期内发送一次公平速率调整遥测数据包，因此RCP*的开销与TCP相似。值得注意的是，RCP*的CSTORE指令在遥测基础上增加了向交换机“写数据”的操作，开辟了一种新的拥塞控制方案。

4.5路由决策

 

网络遥测为路由决策提供了除网络连接、网络跳数以外的更多、更详细的网络状态参数，例如链路时延、丢包率、网络拥塞情况和链路利用率等。因此，基于这些网络状态参数，结合Segement Route等新型路由方式，网络节点可以制定个性化的性能路由。

4.6流量工程

 

在运行多路径路由协议的数据中心网络中，终端主机允许根据数据包头部值选择路由路径。以VLAN标签为例，终端主机通过改变VLAN ID值选择不同的转发路径。

Vimalkumar Jeyakumar等人在设计了一种基于带内网络遥测的负载均衡方案[11]。终端主机在其发出的数据包中插入由路径VLAN ID、链路利用率TX-Utilization、链路发送字节数TX-Bytes构成的遥测指令。其中，设置链路发送字节数字段的目的是在链路利用率没有更新的情况下评估路径拥塞程度。

接收方在收到遥测数据包后回传给发送方。发送方根据遥测字段信息构建“路径-拥塞程度”的映射表。其中拥塞程度可以用逐跳链路利用率最大值或总和表示。发送方根据拥塞程度映射表选择合适路径进行转发。

4.7网络智慧化

 

限制网络智慧化部署的瓶颈除了算力算法问题，实时数据供给也是一大挑战。而带内网络遥测恰恰能够为网络智慧化方案的部署提供源源不断的实时网络状态数据。

5、未来展望

带内网络遥测已经得到了学术界和产业界的广泛关注。学术界更加关注带内网络遥测能否给网络闭环控制带来新的解决思路，产业界已经有成熟的网络监管产品问世。带内网络遥测技术方兴未艾，但也面临着一些挑战。

5.1通用遥测模型

 

带内网络遥测具有数据平面可编程、随路测量、可重配置等特点。如何利用这些特点破解传统测量无法被普遍适用的局面，对完善网络遥测研究具有重要意义。目前学术界和产业界缺乏针对一体化融合网络互联互通场景的通用遥测模型的研究。利用可编程数据平面的灵活性和可扩展性针对异构网络特性设计随路遥测方案，形成统一网络状态视图成为带内网络遥测技术的潜在应用场景。

5.2性能损失评估

 

带内网络遥测可以插入数据包中的遥测元数据数量受数据包原始大小及网络最大传输单元(MTU)的限制。这也意味着带内网络遥测侵占部分网络带宽。除此之外，带内网络遥测支持VXLAN-GPE、Geneve、NSH、TCP和UDP等多种封装协议。这些封装协议大多包含头部校验过程。因此，元测量数据的插入需要更新校验和字段，这将会增加交换机的处理开销。目前，学术界缺少关于带内网络遥测对网络性能损失产生的影响评估研究。

5.3个流数据分析

 

相较于其他测量方案，带内网络遥测可以捕捉更为详尽的个流网络状态信息(如网络流逐跳延迟、逐跳缓存大小、多路径传输的子路径特性等)。这些个流网络状态信息的是传统测量方案无法获取或未曾研究的。如何针对个流建立准确的统计分析模型(如时间序列分析、回归分析、关联分析等)并基于这些模型设计部署网络管理、优化方案成为未来带内网络遥测研究的重要任务。

5.4遥测数据聚合

 

首先，带内网络遥测可能会产生大量遥测数据，除了占据网络带宽以外，还加重了服务器数据收集、存储和分析负担。假如网络所有节点转发的所有流量都进行带内网络遥测，一个节点将为每个数据包添加几十个字节的遥测数据，数据包在整个转发路径可能会累计大量跟踪数据，这些累计跟踪数据甚至可能会超过原始数据包的大小。数据平面汇聚产生的遥测数据量与遥测元数据量、流量规模、网络规模等有关。遥测服务器如何处理规模庞大的遥测数据是遥测系统性能衡量的关键环节。因此，遥测终点在汇报遥测数据时，应考虑对遥测数据进行预先压缩、筛选和聚合处理，以减少遥测服务器压力。

其次，现有状态采集字段只能存放一些必不可少的有限数据。随着网络自动化技术、虚拟化技术、网络融合、分组光纤融合的发展趋势，带内网络遥测要按需并可交互地采集并提供更多网络数据。因此，未来带内网络遥测技术的研究需要充分考虑数据字段的定义、聚合、获取和过滤的灵活性和可扩展性。

最后，现有遥测原语(primitives)和模型过于复杂，带内网络遥测需要对遥测数据(如节点、链路、端口、路径、流、时间戳等)查询原语进行简化。

5.5遥测安全风险

 

带内网络遥测的数据平面可编程性导致潜在的软件漏洞、后门、病毒带来安全问题。带内网络遥测伴随着对网络数据包的查看、插入、封装等包级操作。这些操作给用户信息的保密和安全带来一定威胁。除此之外，恶意INT Source通过不断构造遥测数据包，侵占网络带宽，消耗中间节点处理能力，也可能会造成网络可用资源枯竭的情况。因此，带内网络遥测系统中的节点认证与鉴权方案亟需研究。

参考文献/资料

[1].https://datatracker.ietf.org/wg/ippm/documents/

[2].Kim C, Sivaraman A, Katta N, et al. In-band network telemetry via programmable dataplanes[C]//ACM SIGCOMM. 2015.

[3].https://p4.org/assets/INT-current-spec.pdf

[4].Karaagac A, De Poorter E, Hoebeke J. In-Band Network Telemetry in Industrial Wireless Sensor Networks[J]. IEEE Transactions on Network and Service Management, 2019.

[5].刘争争, 毕军, 周禹, et al. 基于P4的主动网络遥测机制[J]. 通信学报, 2018, 39(S1):168-175.

[6].Tu N V , Hyun J , Kim G Y , et al. INTCollector: A High-performance Collector for In-band Network Telemetry[C]// 2018 14th International Conference on Network and Service Management (CNSM). IEEE Computer Society, 2018.

[7].Gupta A, Harrison R, Canini M, et al. Sonata: Query-driven streaming network telemetry[C]//Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication. ACM, 2018: 357-371.

[8].https://barefootnetworks.com/static/app/pdf/DI-UG42-003ea-ProdBrief.pdf

[9].https://support.huawei.com/enterprise/zh/doc/EDOC1100059517/46d2dd1d

[10].https://www.mellanox.com/related-docs/solutions/SB_Mellanox_WJH.pdf

[11].Jeyakumar V, Alizadeh M, Geng Y, et al. Millions of little minions: Using packets for low latency network programming and visibility[C]//ACM SIGCOMM Computer Communication Review. ACM, 2014, 44(4): 3-14.