[转帖]SLA网络性能监测和发展

 

SLA网络性能监测和发展(2007-8-3 9:26)

摘    要    随着Internet的高速发展，网络支持的业务和应用增长迅速，管理者希望对网络的质量和运行的状况有准确及时的了解，对网络的可靠性和性能分析能力提出了更高的要求。随着越来越多的网络供应商和用户之间网络等级协议SLA（Service Level Agreement）的达成，SLA网络性能监测工具应运而生并且得到了广泛的开发和应用。

关键词    服务等级协议　网络性能监测

1　引言

网络服务日新月异，近几年的发展变化尤其快速，最显著的表现在话音、视频、关键业务的快速增长，并逐渐成为网络中数据内容的主体。这些业务的发展促使网络供应商除了定义所提供业务的可用性外，还需要向客户提供服务质量QoS（Quality of Service）和安全性等业务保证。另一方面，越来越多的客户也希望介入业务的管理和监测中，确认服务质量。由此SLA（Service Level Agreement）服务等级协议应运而生。实施SLA管理就要求使用者能对当前运行的网络性能进行准确的实时的监控，获得SLA规定的网络性能参数，由此对网络性能和服务进行监测和评估。如果网络出现故障，网络业务管理应该能够及时诊断故障原因。针对这样的新需求，各厂商对SLA网络监测工具的研发投入了较多的人力和财力，比如Cisco的IOS SLA，ADC Kentrox公司的FrameVison，Pradyne公司的FrameSave和VisualNetworks公司的Visual UpTime。

性能优异的SLA网络监测工具对于厂商和用户都有着很重要的意义。对于供应商它可以增强部署新应用的信心，对于用户可以增加用户的信心和用户满意度。通过SLA网络性能监测工具，用户可以确认它的网络应用是否按照他们的需求在运行，可以连续的、可靠的周期性度量网络的性能。本文将具体描述目前SLA网络性能监测工具的使用和发展，着重讲述SLA在网络抖动和VoIP性能测试，以及在网络监测工具开发中遇到的影响测试精度的问题和解决方法。

2　SLA监测工具特性概述

对基于IP的QoS网络，IETF的IP性能工作组制定了IP业务质量的衡量标准，主要指标有：单向/环回时延、时延抖动、丢包、带宽等。我们知道，Ping功能只能使用ICMP协议来测试目的主机是否可达，以及报文在源端和目的端之间的往返时间。SLA网络性能监测工具可以对多种协议进行探测和监测，因此我们可以将SLA网络监测工具视为一种多功能Ping，不但能够根据用户的具体需求完成探测，同时完成指定服务业务所产生的各种信息的收集和统计。

SLA监测工具的基本监测能力包括：ICMP响应时间和连通性；探测DHCP，FTP，HTTP，DNS，SNMP服务是否可用以及服务的响应时间；测试网络时延抖动Jitter；验证TCP，UDP，DLSw协议是否可用；模拟VoIP的Codec测试出语音质量的MOS/ICPIF得分等。

SLA的探测模型可以看作一对Client和Server关系（如图1所示），网络节点作为Client（比如路由器）上运行SLA监测程序，向作为Server的目的端发起探测。目的端收到探测报文后回应源端，源端则根据回应内容解析网络服务及质量情况。

3　SLA监测工具测试网络功能

3.1　ICMP ECHO测试

ICMP ECHO测试是最基本的功能，其实现与ping功能相似，源端根据用户设置的探测时间及探测频率向目的端发送ICMP ECHO报文，目的地址在收到ICMP报文之后会恢复ICMP ECHO Reply报文，源端根据Reply报文计算到目的端路径的时延及丢包率。该测试使用的是ICMP标准协议报文，测试目的端只要支持ICMP协议即可。SLA监测用户可以对ICMP报文数据长度进行设置。

3.2　TCP ECHO测试

和UDP测试一样，TCP测试也分为Public和Private两种类型，Public遵循RFC 2925实现，使用固定的TCP目的端口号7。SLA TCP测试是向目的端发起一个TCP连接，如果对端开启了相应的端口，则可以建立起这个连接，建立成功后则解除连接，认为本次测试成功。

3.3　UDP ECHO测试

SLA UDP测试内容包括UDP报文在网络中的响应时间、单向时延、抖动、丢包率和连通性。

测试UDP的连通性与Ping中测试ICMP连通性原理相似。UDP测试分为Public和Private两种。前者在RFC 2925中规定 Server端使用固定的UDP端口号7，后者是对Public的扩展，支持UDP端口的灵活配置，两者除了端口不同外，其他实现原理都相同。源端针对某一测试端口构造UDP探测报文向目的端发送，目的端接收此报文后如果相应端口开启，则向源端发送回应UDP报文，源端对回应报文进行解析计算得到到目的端往返路径上的时延以及丢包率等。SLA监测用户可以对UDP报文数据长度进行设置。

UDP的单向时延和抖动测试在SLA监测有时会单独作为一种测试类型，就是下面所介绍的Jitter测试。

3.4　Jitter测试

我们通常用4个基本的参数来描述一个流所要求的服务质量是否符合需求：可靠性、时延、抖动和带宽，不同的应用对这4个特征的要求各不相同，比如电子邮件、文件传输、Web访问和远程登录应用对于可靠性有很严格的要求，任何一位都不允许被错误递交，而音频点播、视频点播、IP电话和视频会议应用可以容忍错误，但这些实时性要求高的应用对于时延和抖动的极为敏感，所以网络时延和抖动是衡量网络对多媒体业务承载性能的重要参数，在一个对时延敏感的网络中，最理想的情况是抖动为0。随着网络多媒体业务的快速增长，这两种参数的关注率也越来越高。

SLA Jitter测试是探测网络状况对实时性业务是否提供合理服务质量的重要工具，可以得到网络的可达性、时延和网络抖动等统计数据。在这种测试类型中抖动（Jitter）和单向延迟定义如图2所示，T1为报文Packet1的发送时间，T2为接收Packet1的时间（这里将B处理报文的时间忽略未计，因此T2也作为回应报文的发送时间），T3为接收响应报文的时间，T4，T5，T6的定义以此类推。

Jitter测试的Client端A开始探测后，以固定的时间间隔向目的端发送指定数量的UDP报文。每次探测发送的Jitter报文的数量和发送频率用户都可以根据自己的需要进行设置。假设一次Jitter探测发送了10个UDP报文，探测结果有：

1. 报文往返时延RTD（Round-Trip Delay）：Packet1的往返时延RTD1 = T3 - T1；

2. 报文单向时延OWD（One-Way Delay）（这种测试需要A和B之间首先进行时钟同步）：S-Source   D-Destination

Packet1  SD-Delay1 = T2 - T1    DS-Delay1 = T3 - T2

Packet2  SD-Delay2 = T5 - T4     DS-Delay2 =T6 - T5

3.网络抖动Jitter：

SD方向   SD Jitter1 = (T5 - T4) - (T2 - T1)

DS方向   DS Jitter1 = (T6 - T5) - (T3 - T2)

由此可见，如果成功收到的回应报文数为10，则计算得到的Jitter抖动数应该为9，SLA监测工具即可对这些统计值计算出抖动的最值、方差等做计算统计，从而了解到网络状况。

为了能够更真实地反映网络对实时性业务的服务质量，许多网络设备供应商对SLA Jitter测试进行了扩展，支持模拟G711a/G711u/G729a语音编码进行测试。如果SLA监测工具配置了G729a模拟语音测试，那么这种Jitter测试将按照对应语音流的频率何报文大小发送测试报文，最后统计计算得出表示语音质量的参数MOS和ICPIF。

一些SLA监测工具还具有阈值告警功能，即用户可对监测项进行阈值设定，比如对SD Delay设置时延阈值为5ms，当报文SD Delay超过5ms时，设备会产生一个SNMP Trap，实现实时监测以实现更详细的分析功能。

3.5　其他类型测试

为了能够增加SLA网络监测的通用性和兼容性，支持更多的网络业务特性监测，SLA监测增加了许多扩展类型。

3.5.1　SNMP Query测试

这种探测目的端的SNMP服务是否打开，如果打开则表示可以用MIB-Browser等网管软件连接到设备上。SNMP Query探测会发送3个特定格式的SNMP服务请求报文分别对应SNMP协议的单个版本SNMP v1/v2/v3，如果目的端开起了任一SNMP版本的服务，就会回应可以接收请求的报文，收到回应报文后则本次探测成功。

3.5.2　HTTP测试

HTTP探测是向指定的目的端请求HTTP服务，可以设置选择请求下载网页或者上传数据。如果操作成功说明目的端提供HTTP服务。用户可以选择设置HTTP探测报文采用v1.0还是v1.1，从而判断对端的HTTP服务版本。通过对响应报文解析统计，可以了解源端到目的端之间的HTTP数据连接状态。如果探测失败，可以通过解析响应报文估计失败原因：提供的HTTP Server提供的端口号不是80；没有对应的网页存在；Server的网页不支持上传数据操作；Server繁忙响应太慢导致超时等。

目前大多SLA监测工具还支持探测网络DHCP服务，测试网络的DNS服。此外，具有扩展功能的SLA监测工具还对ATM，和帧中继网络也具有探测和分析功能。

4　SLA网络监测工具开发难点和发展趋势

目前许多厂商的SLA监测工具的开发都是以相对独立软件模块和硬件模块嵌入在相关设备上的，作为网络设备自带的模块提供给测试方和用户，这样的模式不但能直接利用现有设备的系统资源减少额外的开销，还增加了对网络节点的直接掌握控制能力。但是一个网络系统由很多网络节点组成，有高端性能卓越处理能力强的骨干路由器，也有负责微小区设备连接交换的小型交换机。设备性能的差异就要求SLA监测参数设置必须在一定的合理范围内。如果参数设置不合理，如探测报文发送频率和探测报文数据过大等，对于处理速度慢的低端设备影响会很大，甚至造成网络的拥塞，测试结果失真。因此在设置测试参数时需要注意设备本身硬件处理能力的限制。换言之，这就要求SLA的监测具有快速分析能力和监测参数收敛功能，这也是SLA监测工具开发的一大趋势和难点。

SLA监测工具的软件设计方案也对SLA测试精确性有着重要的意义，这也是处理性能较弱的硬件系统设备的SLA监测工具可能会比硬件性能优越许多的SLA监测工具更精确的原因。就测试的精确性而言，软件的设计的重点和难点来自算法的设计和解析报文的时机。以计算网络时延为例，我们知道，网络的性能测试最基本的手段就是对时间的测试，即对报文打时间戳。现在越来越多的测试针对的是上层应用和服务，当网络背景流量很大时，探测报文很有可能会在报文队列中等待很久才被送至上层打时间戳，如果系统有任务切换，则送至上层处理的时延会更长，这样以上层时间戳计算的话，报文的单向时延和抖动测试结果将与实际相差较远，导致测试结果失真。如图3所示，如果处理时间T’过长，实际的单向时延T1与测试结果T1 + T’将会有较大误差。所以，要得到更精确的统计，在计算单向时延时，为了更准确的计算网络路径时延，目的端接应该在链路层处理时给探测报文打时间戳；在上层处理时打服务响应的时间戳。

随着硬件性能的提高，SLA网络监测工具在这方面的限制将会越来越少（忽略T’），但是随着网络业务种类的增加和网络复杂度的提供，SLA网络监测有待研发的领域会越来越宽广。无论网络怎样发展，如何能更好的融合于网络背景中进行非干扰监测，更加准确快速地反映出网络运行的状况和质量是SLA监测工具开发的基准和目标。

由于本网页不支持图片与公式效果，如有需要请参阅杂志。

 

源文档 <http://ppc.c114.net/175/a207426.html>

推荐到鲜果： 查阅更多相关主题的帖子: 网络管理