【YD通讯标准】 互联网业务质量监测系统技术要求

ICS33.040.40
中华人民共和国通信行业标准
YD/T3139-2016
互联网业务质量监测系统技术要求Technical specification of internet service quality monitoring system2016-07-11发布
2016-10-01实施
中华人民共和国工业和信息化部　发布前
2术语、定义和缩略语
2.1术语和定义·
2.2缩略语·
3系统的组成和架构·
3.1概述
3.2组件描述
4系统的业务控制流程
4.1流程概述·
4.2详细流程
5系统各组件接口要求
5.1接口概述
5.2接口总体要求
5.3接口定义与要求
参考文献·
YD/T3139-2016
YD/T3139-2016
本标准按照GB/T1.1-2009给出的规则起草。注意本文件的某些内容可能涉及专利，本文件的发布机构不承担识别这些专利的责任本标准由中国通信标准化协会提出并归口。本标准起草单位：中国联合网络通信集团有限公司、华为技术有限公司。本标准主要起草人：徐东、刘永生、黄斌、刘刚。I
HiiKAoiKAca
1范围
互联网业务质量监测系统技术要求YD/T3139-2016
本标准规定了互联网业务质量监测系统技术要求，该技术要求依据运营商网络的具体部署场景和需求制定。
本标准适用于支持互联网业务质量监测系统。2术语、定义和缩略语
2.1术语和定义
下列术语和定义适用于本文件。2.1.1
监测中心MonitoringCenter
互联网业务质量监测系统的控制中心，管理所有监测探针，控制监测探针的监测任务，接收并分析监测探针上报的监测数据，对监测数据进行处理后，存储在监测中心的数据库中，供用户后续查看。2.1.2
监测探针MonitoringProbe
部署在网络中，监测互联网业务质量的设备，可以是硬件设备或安装在终端中的软件。2.1.3
监测客户端MonitoringClient
管理员用来登录监测中心、操作监测中心、查看监测数据的终端设备，监测客户端通过浏览器或专用的互联网监测系统客户端软件与监测中心连接2.1.4
监测任务MonitoringTask
监测探针上运行的多个监测实例，监测任务可按HTTP、FTP、视频等类型分类。2.2缩略语
下列缩略语适用于本文件。
Browser/Server
File Transport Protocol
Secure File Transfer ProtocolHypertext Transfer Protocol
HyperTextTransferProtocol overSecureSocketLayerInternet Control Message ProtocolInternet Protocol
Network Address Translation
TWAMPATwo-WayActiveMeasurementProtocol浏览器/服务器
文件传输协议
安全文件传输协议
超文本传输协议
加密的超文本传输协议
因特网控制报文协议
互联网协议
网络地址转换
双向主动测试协议
HiiKAoNiKAca
YD/T3139-2016
Virtual Local AreaNetwork
Virtual Private Network
WirelessLocal AreaNetwork
ExtensibleMarkupLanguage
3系统的组成和架构
3.1概述
虚拟局域网
虚拟专用网
无线局域网
可扩展标记语言
互联网业务质量监测系统的工作方式为分布式部署探针，集中式数据管理。监测探针部署在网络的各个层次、各个地点或各种终端中，这些监测探针模拟用户访问互联网业务的行为来监测互联网业务质量，然后把监测数据上报给监测中心。监测中心管理所有的监测探针，控制监测探针上的监测任务的运行，并对监测探针上报的监测数据进行整理、分析和存储。监测探针可能由于不同的接入场景、不同的监测性能要求等具有不同的物理和软件形态；监测中心是系统的控制中心，负责探针的管理、测试例部署、数据分析、报表呈现等，如图1所示。Internet
监测探针
IP网络
监测中心
监测客户端
图1互联网业务质量监测系统组成3.2组件描述
3.2.1概述
北向接口
运维中心
上级系统
互联网业务质量监测系统一般采用一级架构，集中部署。在运营商总部集中部署监测中心，包括采集分析服务器、数据库服务器、各种应用服务器、磁盘阵列等，在各城域网部署监测探针，各监测探针通过互联网访问监测中心。同时，运维人员通过监测客户端访问监测中心进行互联网业务质量监测维护和数据查询。
3.2.2监测中心
监测中心是互联网业务质量监测系统的神经中枢，实现网络质量监控、业务质量监控、按需测试阈值告警管理、探针管理、系统管理和报表管理功能。监测中心与监测客户端一般采用B/S（Browser/Server）架构，用户通过Web浏览器即可方便地登录系统进行操作：
a）普通用户通过WEB浏览器登录监测中心进行业务及网络质量监控；2
TiiKAoiKAca
b）系统管理员通过WEB浏览器登录监测中心进行安全、日志和License的管理。监测中心主要实现如下功能：
YD/T3139-2016
c）性能数据采集：通过分布式部署的监测探针实时采集网络性能及互联网业务质量数据，并支持对探针的诊断测试：
d）网络及业务质量监控：接收探针上报的采集数据，并对网络性能和互联网业务质量做分析，得出优化建议、质量排名、产生告警、记录日志等：e）报表生成：以丰富的图表形式在客户端实时展现监测结果，便于用户直观识别业务质量的优劣。3.2.3监测探针
监测中心把指令发送到相关监测探针上，执行计划监测或按需监测，以测量网络性能和用户的业务质量体验，监测探针分为以下两类：a）互联网业务监测探针：互联网业务监测探针定为专为拨测互联网业务质量而设计的探针，该类型探针一般部署在靠近用户侧的网络中，为了适应不同的接入场景，它的接口和接入网络方式比较丰富。另外，它一般不做高性能、大规模的业务测试：b）网络性能监测探针：网络性能监测探针是集成了互联网业务质量测试和网络性能测试，并可以进行高性能、大规模测试的监测探针，它一般部署高层次的网络中，比如，可集中部署在互联网业务出口来测试SP业务质量，网络端到端性能监控等3.2.4监测客户端
监测客户端是互联网业务质量监测系统操作人员用来远程操作监测中心的终端设备，监测客户端一般是操作人员办公区的PC或家中的台式机。监测客户端通常通过Web浏览器接入监测中心。4系统的业务控制流程
4.1流程概述
互联网业务质量监测系统的业务控制流程总体上分为四个阶段：探针注册、心跳保活、业务监测和探针升级。如图2所示，这四个阶段可完成探针注册、配置下发与上报、监测任务下发与监测结果上报、监测探针与监测中心心跳维护、监测探针告警及状态上报、监测探针版本升级等功能。监测探针
探针注册
心跳保活
业务测试
探针升级
监测中心
图2监测探针与监测系统交互
iiiKAoNiKAca
YD/T3139-2016
监测探针与监测中心的四个交互阶段先后顺序可能在时间上交义，重叠。比如业务测试的时候，也存在心跳：探针升级过程中，业务测试还在继续等。以下对每个交互过程进行详细描述：a）探针注册：
探针注册是指监测探针向监测中心发起认证、并成功注册到监测中心的过程，包括监测探针离线后重新注册。该认证过程中探针需向监测中心提供探针的基础信息，监测中心需对接入探针进行认证。探针注册信息应该至少包含探针名称、探针管理地址、探针软件版本、探针硬件型号、探针运行参数、探针认证等信息。监测中心也能够通过注册回复对探针进行参数配置。探针在得知监测中心有新配置下发时，应立即调用注册请求，从而从注册回复中获取新配置信息。b）心跳保活：
心跳保活是监测中心与监测探针间维持连接关系而使用的功能，心跳保活过程是指监测中心与探针之间的定期心跳交互处理过程，包括监测探针是否在线，以及监测中心向监测探针通告有新配置、新任务或新版本需要下发。
c）业务测试
业务测试是指监测中心向监测探针下发监测任务或更新监测任务与监测探针向监测中心上报监测数据两个交互过程。任务下发或任务更新过程中，监测中心需将监测任务的具体参数设置通过该接口传递给指定探针。监测数据上报至少应包括监测ID、监测端口、监测类型、具体监测结果数据等信息。d）探针升级：
探针升级用于监测中心向指定监测探针下发软件升级命令，并用于传递升级所需的文件。互联网业务质量监测系统的操作维护流程比较简单，操作人员通过监测客户端访问监控中心，如图3所示，监测客户端一般是WEB浏览器，访问过程分为：HTTP连接建立，用户认证，浏览数据，用户离线。由于它的流程比较固定和通用，因此本文不对它的流程做详细描述。监测客户端
HTTP连接建立
用户认证
浏览数据
用户离线
监测中心
图3监测中心与监测客户端交互
4.2详细流程
4.2.1概述
控制流程的不同阶段完成不同的功能，有些控制流程在时间上又可能交叉。本节针对控制流程进行了整体上定义，对各流程中交互内容不做要求。HiiKAoNiKAca
4.2.2探针注册
YD/T3139-2016
探针注册实现探针自动注册到监测中心的功能，探针上报注册信息到监测中心请求注册，监测中心解析注册信息，做相应的注册处理，注册处理后向该探针下发注册回复。监测中心也能够通过注册回复对探针进行参数配置。
探针注册信息应该至少包含探针名称、探针管理地址、探针软件版本、探针硬件型号、探针运行参数、探针认证等信息。
探针新接入网络，或者重新上线时应立即触发探针注册。在收到带有配置更新标志的心跳回复后，探针也应立即发送注册报文，使得监测中心通过注册回复来下发更新的配置。监测探针
注册请求
认证请求
认证回复
注册成功
图4探针注册示意
监测中心
探针注册过程应该包括认证和授权过程，在通过认证后，监测探针才能与监测中心正常通信，如图4所示，注册交互过程如下：
a）注册请求：
监测探针主动收集探针名称、探针管理地址、探针软件版本、探针硬件型号、探针运行参数等信息，这些信息可供监测中心做参考，并进行相应的处理。收集完成后，向监测中心发起注册请求，并在请求消息中携带这些信息。
b）认证请求！
监测中心对注册请求消息进行校验，校验通过后，返回认证请求，要求监测探针提供身份信息。认证请求中应该包括一个随机数（加密算法盐值），目的是防止攻击者通过抓取报文进行回放进行破解。c）认证回复：
监测探针收到认证请求后，把用户名、用户密码和盐值一起进行加密，加密算法宜采用公有算法然后，监测探针吧加密的用户名、用户密码和盐值通过认证回复发送给监测中心。当然，监测探针与监测中心间也可以通过HTTPS等认证方式来提高安全性。d）注册成功
监测中心收到注册信息，并成功校验认证信息后，做相应的处理，并更新数据库中的信息。认证成功或失败均应返回状态信息。
4.2.3心跳保活
监测探针定期向监测中心发送心跳信息，用于探测监测探针与监测中心间的网络连通性，监测中心可通过心跳信息判断探针是否在线，以及在有新配置、新任务或新版本需要下发时通告监测探针。监测探针使用探针ID请求心跳服务，监测中心判断探针ID合法性，判断合法后将该探针的最后一次心跳时间更新为系统当前时间，并回复探针操作状态。如图5所示，心跳保活过程如下：5
TiiKAoiKAca
YD/T3139-2016
a）心跳请求：
监测探针向监测中心发送探针ID。b）心跳回复：
监测中心根据监测探针ID查询数据库判断探针ID是否合法，如果探针ID合法，监测中心中更新探针最后心跳时间。
监测探针
4.2.4业务测试
心跳请求
心跳回复
图5心跳保活示意
监测中心
监测探针新注册、上线时，通过心跳消息向监测中心请求所有任务重新下发。监测中心在接收到这种类型的心跳消息后，通过任务下发接口向探针下发所有监测任务。另外，监测中心收到心跳消息后，根据探针ID查看是否有新监测任务需要下发，若存在监测任务更新，监测中心则向探针下发更新的监测任务。如图6所示，业务测试过程如下：a）心跳请求：
监测中心收到心跳请求时，根据探针ID检查是否有任务需要下发或更新，若存在则触发任务下发b）测试请求：
监测中心下发测试任务请求，可包括新监测任务下发、监测探针配置下发、旧监测任务更新等。c）结果上报：
监测探针启动监测任务，并将监测结果立即或定期上报给监测中心。监测探针
4.2.5探针升级
心跳请求
测试请求
结果上级
图6业务测试示意
监测中心
监测中心收到心跳报文后，根据心跳报文中的监测探针ID查看是否有对监测探针升级的必要，若存在必要，则通过探针升级消息向探针发送升级文件。监测探针收到完整的升级文件后，更新升级包，自动重启，重新注册。如图7所示，探针升级过程如下：a）心跳请求：
监测中心收到心跳请求后，查看是否有探针升级任务，若存在，则进行探针升级。b）下载升级文件：
HiiKAoNiKAca
YD/T3139-2016
监测中心通过升级消息下发升级文件。升级文件下发完成后，探针更新系统文件，自动重启，重新进行注册。
监测探针
5系统各组件接口要求
5.1接口概述
心跳请求
下载升级文件
图7探针升级示意
监测中心
互联网业务质量监测系统的接口分为外部接口和内部接口。外部接口是指互联网业务质量监测系统与现有系统之间的接口，比如与已有上层系统对接接口和接入Internet的接口等；内部接口是指监测系统各组件间的接口，比如监测探针与监测中心的接口。这两种接口因用途不同，具体要求也不一样。系统接口的位置如图8所示。
Internet
接口B
检测探针
监控客户端正
5.2接口总体要求
IP网络www.bzxz.net
检测探针
图8系统接口示意
接口H
上级系统
运维中
监控中心
互联网业务质量监测系统各组件可能部署在不同的网络环境，因此部署环境决定了监测系统各组件间接口的基本要求，只有满足了这些要求，才能让系统各组件完整地运行起来：另外，互联网业务质量监测系统各组件接口也存在由不同厂商提供，文相互协作的可能，因此，接口就应尽量采用标准化的互通性好的接口，以便减少协调工作量、增加可扩展性：最后，出于部署成本考虑，接口也应该尽量利用现有的条件和技术，优先考虑不增加新硬件和开发新软件的接口。总之，接口应具有以下要求：a）标准性：采用现有通用的标准协议。b）互通性：采用扩展性好、互操作强、简单易用的接口。c）可穿越防火墙：互联网业务质量监测系统通过模拟用户的上网行为测量互联网业务质量，而互联网用户访问互联网业务的时候，可能会遇到IP地址被NAT转换，穿越防火墙、透过VPN等场景，监测系统7
YD/T3139-2016
也应该考虑这些场景的要求。
d）可移植性：移植性好的接口将会为后续系统增加新组件减少工作量。e）易读性：各组件间难免会出现协调问题或系统故障，而出现问题的时候，能否快速故障分责、查看问题根源，在很大程度上依赖接口的设计与定义。易于理解、可读性强的接口可大大减少故障定位时间。
5.3接口定义与要求
5.3.1接口A：监测探针与互联网接口互联网业务质量监测的目的是监测互联网用户的上网体验，而互联网用户可通过多种方式接入互联网，因此，为了准确测试互联网业务在各种接入场景下的用户体验，监测探针应该具备接入各种组网场景的能力，并正确测试。现对监测探针与互联网接口做如下要求：a）应支持主流接入方式：以太接入是自前PC，笔记本电脑最广泛的接入方式，监测探针既然是监测用户的上网体验，支持以太接入是基本要求。b）应支持WLAN接入方式：WLAN接入方式在机场、宾馆、商场、会议厅等场所越来越普遍，为监测这些场景下的互联网用户的上网体验，监测探针应支持这种接入方式。另外，在一些线缆不方便接入的地方，使用WLAN接入也是一种选择。c）宜支持3G/4G接入方式：随着3G/4G无线网络的完善，下载速度越来越快，越来越多的用户通过手机、PAD等网上接入访问互联网业务，为了监测这些场景下的互联网用户的上网体验，监测探针宜支持这种接入方式。
d）同一探针应支持多个、多种接入接口：监测探针需要适应不同的接入场景，比如，监测探针可能在交换机、路由器等不同设备接入；也可能在楼道、机房等不同位置接入：还可能在接入网、城域网、骨干网等不同网络层次接入。
e）宜管理接口和业务监测接口分离：监测探针应支持管理接口和业务监测接口使用同一个接口接入的方式，但是为了提高监测探针的可管理性和可靠性，管理接口和业务监测接口宜使用不同的物理接口。5.3.2接口B：监测探针与监测中心接口监测中心管理所有的监测探针，它们之间的接口包括监测中心与监测探针间的心跳监测接口、监测探针注册接口、监测中心下发监测任务接口、监测探针上报监测结果接口、监测探针升级接口等等。另外，监测中心可能处于运维中心的防火墙后，监测探针获得的IP地址可能会经过NAT转换，因此接口B是监测系统所有接口中最复杂的接口。从目前的行业来看，监测中心与监测探针间的接口一般是私有的，它们之间承载了非常多的信息，本文不对这种场景下的接口做要求。对于监测中心与监测探针属于不同厂家开发的设备场景，现对它们之间的接口做如下要求：a）承载协议要求：优选采用WebService作为承载协议，WebService是基于HTTP传递XML定义的SOAP协议数据，是开放的标准，不依赖于具体的开发语言和运行平台，扩展性好，开发工作量小，主要缺点是性能方面相对于其它中间件服务调用较低。b）穿越防火墙要求：监测探针的IP地址可能被NAT转换，在这种场景下，位于防火墙后的监测中心无法主动联系到监测探针，因此，该接口要求探针主动上报所有通信内容。c）通信内容要求：由于涉及到多厂家系统协同工作，接口的通信内容宜采用文本格式。YD/T3139-2016
d）认证要求：监测探针应该通过认证后才能注册到监测中心，目的是防止伪设备、减少被攻击的可能，认证协议要求采用不可逆的SHA256算法或不对称加密算法。5.3.3接口C：监测中心与监测客户端接口监测中心一般部署在运维中心机房的服务器、云中心等地方，只有在安装、调测、故障定位的时候才会现场操作。其它时间，运维人员需要通过监测客户端远程查看监测质量数据，监测客户端可能是运维人员办公区的办公电脑或家中的便携电脑，连接到监测中心后，可进行日常监控、维护、出报告等工作。出于易用性考虑，优选使用Windows系统的客户端，接口C具体要求如下：a）客户端软件要求：宜采用业界使用率高、性能好、安全性高的浏览器，比如IE、Chrome、火狐等。b）认证要求：请参考接口B的认证要求。c）可视化要求：监测中心对监测数据进行分析后，一般都提供丰富的曲线、表格、饼图等呈现形式，因此要求客户端能展示这些数据d）性能要求：图形化、拓扑化呈现监测数据已经非常普遍，选择的客户端应该能满足拓扑呈现的时候快速响应。
5.3.4接口D：网络管道监测接口业务质量体验的好坏由三部分决定：业务源质量、网络管道传输质量、用户使用的终端性能。接口D就是用来监测网络传输对业务质量的影响程度，可以通过监测探针与监测探针互测某段网络的传输质量来完成，也可以通过监测探针与网络设备互测来完成。网络管道传输质量测试应尽量模拟被测业务的报文大小、报文优先级、发包频率等，而测试指标一般包括时延、抖动、丢包等。在某些场景下，参与测试的监测探针A与监测探针B可能是不同厂家的设备，现对接口D做如下要求：
a）若探针A与探针B是同一厂家设备，允许私有协议进行测试：b）若探针A与探针B是不同厂家设备，宜使用标准协议进行测试，比如ICMP、TWAMP等标准协议：c）监测接口应支持对发送的报文自定义报文优先级、报文长度、发包频率等，目的是最大程度的模拟现网业务：
d）监测接口支持网络普遍组网要求，比如VLAN、QinQ、VPN等。5.3.5接口E：监测中心北向接口北向接口是监测中心把监测到的互联网业务质量数据上报给上级系统，供上级系统统一呈现、出报告等用途。另外，上级系统也可能在某些场景下向监测中心下发监测请求，监测中心收到请求后，建立相关监测，并把监测结果通过北向接口上报给上级系统。在这种场景下，一个上级系统可能对应多个监测中心，上级系统与监测中心也可能是不同厂商、不同时间、不同团队开发的系统。因此，他们之间的接口应该尽量采用业界通用、技术成熟度高的协议，该接口应满足以下要求：a）对于实时性要求不高的场景，并且上级系统只是周期性地获取监测中心的数据用于出报告、规划、优化等自的，在这种场景下宜采用FTP/sFTP作为接口。b）对于实时性要求比较高的场景，上级系统要求监测中心立即反馈监测结果，并且具有不定期性。比如，出于故障定位的目的，上级系统随时通过北向接口调取监测中心的测试数据，要求监测中心立即反馈结果，在这种场景下宜采用WebService作为接口，并采用XML编码来提高可读性，减少接口对接的协调工作。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。