TWAMP Light原理描述

小乔

产生原因

TWAMP是IP性能监控IPPM（IP performance monitoring）工作组IP网络性能统计协议，它定义了一种跨网络的标准性能统计方法。协议自身定义两种架构：标准框架、轻量级架构。与TWAMP标准架构相比，TWAMP Light架构是将反射端的控制层移到发起端，这样，TWAMP整体框架的控制模块可以集中部署，反射端的能力要求被大大降低，有助于反射端的快速部署。

特点

TWAMP Light架构中，Controller端包含标准模型中的Client和Sender角色。Responder端包含标准模型中的Reflector角色。

在功能划分时，TWAMP Light架构的TWAMP Controller负责部署统计会话，计算性能统计数据并定期通过PM方式发布给网管；同时TWAMP Controller负责解析网管信息后通过私有通道传递给反射端。TWAMP Light架构的TWAMP Responder负责根据统计会话反射TWAMP-Test报文。

• TWAMP Light原理介绍
  
  • 通信模型
  • 报文格式
  • 检测类型
  • 检测指标
    
• TWAMP Light工作过程
  

TWAMP Light原理介绍


通信模型

TWAMP Light的通信模型由Cotroller和Responder两部分组成，与标准TWAMP在架构上有一定区别。

TWAMP Light通信模型

如图18-110所示，TWAMP-Test报文作为发送和接收性能测量的探针，使用预先设置好的统计会话的IP地址、UDP端口号，TTL固定为255。Controller发送TWAMP-Test报文，Responder收到该报文后，反射报文给Controller。Controller负责收集TWAMP测量的统计信息。

TWAMP Light定义了两个方向的TWAMP-Test报文：

• Session-Sender test报文：Controller发送给Responder的报文
• Session-Reflector test报文：Responder反射给Controller的报文
  

在Controller端，根据TWAMP-Test报文来计算出性能统计数据，客户可以通过网管界面得到相关统计数据。

                               
登录/注册后可看大图

• TWAMP-Test报文的发包受到链路负载和拥塞情况的影响。
• TWAMP-Test报文的默认DSCP值为0，即默认的调度优先级为BE，可以在创建发起端统计会话时进行配置。
  

图18-110 TWAMP Light基本通信模型

                               
登录/注册后可看大图

TWAMP Light和TWAMP的比较

TWAMP是IP性能监控IPPM（IP performance monitoring）工作组IP网络性能统计协议，它定义了一种跨网络的标准性能统计方法。协议自身定义两种架构：TWAMP标准框架、TWAMP Light轻量级架构。

如图18-111所示，TWAMP采用客户端-服务器通信模式，同时定义了如下四个逻辑角色：

• Control-Client：负责建立、启动和停止TWAMP会话，并收集统计结果。
• Session-Sender：由Client调度，主动向外发送用于性能统计的探针。
• Server：负责响应Client发起的建立、启动和停止TWAMP会话的请求。
• Session-Reflector：由Server调度，应答Sender发送过来的探针。
  

图18-111 TWAMP标准架构图

                               
登录/注册后可看大图

图18-112 TWAMP Light架构图

                               
登录/注册后可看大图

如图18-112所示，TWAMP Light属于轻量级架构，它将反射端的控制层移到发起端。发起端Controller包含Control-Client和Session-Sender角色，反射端Responder仅包含标准模型中的Session-Reflector角色。因此，在完成性能检测过程中可以省略标准架构中控制会话的建立过程。

TWAMP Light简化了工作模型，发起端Controller的控制模块可以集中部署，反射端Responder的能力要求也大大降低，可以快速部署，并且还可以做到即插即用。Controller和Responder有如下功能：

• Controller：主要完成统计会话的建立、启动和停止，以及测量会话报文的发送接收、性能数据采集和计算并将最后结果上送给网管平台。
• Responder：只负责相应测量会话报文的反射。
  

                               
登录/注册后可看大图

与TWAMP标准框架相比，TWAMP Light通过静态配置来指定统计实例的参数，Responder端的统计实例参数的IP地址、UDP端口号可以通过网管的MIB功能进行配置。配置完实例后，通过TWAMP-Test报文的交互来计算出该网络的丢包率、时延和抖动等性能数据。所以，TWAMP Light不需要控制协议来协商双方的参数。TWAMP Light简化了协议的工作过程，更便于在实际应用中部署。

报文格式

TWAMP Light定义了Controller发送给Responder的Session-Sender test报文以及Responder反射给Controller的Session-Reflector test报文，作为性能测量的探针。

图18-113列出了Session-Sender test报文的结构，表18-38提供了各部分内容的解释说明。

图18-113 Session-Sender test报文结构

                               
登录/注册后可看大图

表18-38 Session-Sender test报文各字段含义[td]

字段	解释
Sequence Number	根据传输顺序生成的报文序列号。
Timestamp	发送检测报文的时间戳。
Error Estimate	错误检测。
Member ID	发送该报文的成员链路的MAC地址或编号。
Packet Padding	报文填充字段。

图18-114列出了Session-Reflector test报文的结构，表18-39提供了各部分内容的解释说明。

图18-114 Session-Reflector test报文结构

                               
登录/注册后可看大图

表18-39 Session-Reflector test报文各字段含义

字段	解释
Sequence Number	根据传输顺序生成的报文序列号。
Timestamp	反射检测报文的时间戳。
Error Estimate	错误检测。
MBZ	必须为0。
Receive Timestamp	接收检测报文的时间戳。
Member ID	发送该报文的成员链路的MAC地址或编号。
Sender Sequence Number	从Session-Sender test报文的Sequence Number字段复制而来。
Sender Timestamp	从Session-Sender test报文的Timestamp字段复制而来。
Sender Error Estimate	从Session-Sender test报文的Error Estimate字段复制而来。
Sender Member ID	从Session-Sender test报文的Member ID字段复制而来。
Sender TTL	报文的生存时间。
Packet Padding	报文填充字段。

检测类型

TWAMP Light支持的检测类型包括基于非捆绑链路检测和基于绑定Trunk口的捆绑链路检测。

如图18-115所示，在基于非捆绑链路检测的情况下，当Controller端和Responder端间存在多条成员链路时，以其中某一条成员链路的质量代表所有成员链路的质量。

图18-115 基于非捆绑链路检测

                               
登录/注册后可看大图

如图18-116所示，在基于绑定Trunk口的捆绑链路检测的情况下，当Controller端和Responder端间存在基于Trunk成员口的检测链路时，假设该条链路由三条成员链路捆绑而成，在两端建立统计会话时均绑定指定的Trunk口，即可对捆绑链路中每一条成员链路的的性能进行检测，这就避免了用一条成员链路的质量代表所有成员链路的质量所带来的误差大的问题。得到各成员链路的性能指标后，可以根据需要将具有不同服务质量要求的流量调度到不同的成员链路上。

图18-116 基于绑定Trunk口的捆绑链路检测

                               
登录/注册后可看大图

                               
登录/注册后可看大图

不支持绑定IP-Trunk口。

检测指标


TWAMP Light可以统计时延、抖动和丢包率等测量数据，如图18-117所示，各检测指标的计算过程如下所述。

• 时延：由探针携带的时间戳产生，Sender在发送探针时携带发送时间戳t1，Reflector在应答探针时携带接收时间戳t1'和应答时间戳t2'，Sender在收到应答探针时记录接收时间戳t2，最终单个周期的时延通过四个时间戳来计算，具体如下：
  Delay1 = t2 - t1 - ( t2' - t1' )
• 抖动：由相邻周期的时延数据绝对值计算得来，通过上述的时延计算公式可以得到相邻周期的时延值Delay2 = t4 - t3 - ( t4' - t3' )，最终抖动值通过两个时延值来计算，具体如下：
  Jitter = | Delay2 - Delay1 |
• 丢包率：通过Sender发送和接收的报文数计算，当Sender发送的报文数为P1、接收的报文数为P2时，其丢包率为：
  Loss = ( P1 - P2 ) / P1
  
  

图18-117 TWAMP Light性能检测示意图

                               
登录/注册后可看大图

TWAMP Light工作过程

TWAMP Light的工作过程包括：先建立统计业务，再进行性能统计。

相关概念

TWAMP Light的性能统计包括如下方式：

• 按需统计：指有限的时间内为了诊断而由人工干预发起的性能检测，可以实现在诊断期间单次的性能检测。
• 连续统计：指连续、不间断发生的统计动作。
• 周期性的连续统计：指固定的间隔时间连续发生的统计动作。
  

工作过程

• 统计业务建立
  图18-118 TWAMP Light统计业务建立过程图
  
  
                                 
  登录/注册后可看大图
  
  
  如图18-118所示，Controller作为发起端，Responder作为反射端。
  
  
  • Controller端的Client角色创建统计会话。
  • Responder端创建反射端统计会话。
  • Controller端的Sender角色启动性能统计测试，然后，Controller端根据配置的发包频率和报文模板向Responder端发送TWAMP-Test报文。
  • Responder端反射TWAMP-Test报文。
    
• 性能统计
  TWAMP Light定义了两个方向的TWAMP-Test报文：
  
  • Session-Sender test报文：Controller发送给Responder的报文
  • Session-Reflector test报文：Responder反射给Controller的报文
    
  
  图18-119 TWAMP Light性能统计图
  
  
                                 
  登录/注册后可看大图
  
  
  如图18-119所示，在完成统计业务建立后，TWAMP-Test协议作为发送和接收性能测量的探针，使用预先设置好的统计会话的IP地址、UDP端口号。Controller发送TWAMP-Test报文，Responder收到该报文后，反射报文给Controller。Controller负责收集TWAMP测量的统计信息。详细性能统计过程如下：
  • Controller端收到反射的TWAMP-Test报文后，根据报文中的序列号、时间戳，计算出双向的丢包、时延以及抖动等性能统计量。
  • Controller端将上述计算出的性能统计数据上报给网管，客户可以通过网管界面得到相关统计数据。
    不同的统计方式上报网管方式不同：
    
    • 按需统计：测试结果通过SNMP（MIB）上报给网管。
    • 连续统计：测试结果通过性能监视PM（Performance Monitoring）上报给网管。
    • 周期性的连续统计：测试结果通过性能监视PM（Performance Monitoring）上报给网管。
      
    
    
    
  
  

TIAN_C

感谢分享