Si en el anterior post vimos las medidas de activación del servicio RFC2544 e Y.1564 en el de hoy veremos las medidas de monitorización de dichos circuitos según Y.1731 y TWAMP.
Lo primero que debemos tener claro es que las medidas de activación eran intrusivas ya que inyectaban tráfico o bien a la máxima velocidad del interfaz (RFC2544) o bien a la máxima velocidad comprometida del circuitos (CIR en Y.1564) y por tanto no pueden coexistir con el tráfico de usuario. Sin embargo, las medidas de monitorización NO deben ser intrusivas y deben permitir medir de forma constante en el tiempo la calidad de dicho servicio sin influir en el rendimiento del tráfico de usuario.
SLA (Service Level Agreement)
Toda medida debe monitorizar unos indicadores (KPIs 0 Key Performance Indicators) en relación a un nivel de servicio acordado (SLA). Para los servicios Ethernet, este SLA se basa en los siguientes indicadores:
- FLR - Frame Loss Ratio (TWAMP packet loss)
- FTD - Frame Transfer Delay (network transfer delay)
- IFDV - Interframe Delay Variation (jitter)
El SLA se definirá como el valor máximo permisible para estos indicadores dentro de un período de tiempo (típicamente 24h o incluso días o semanas). En este punto cabe destacar que un problema puntual y muy definido en el tiempo en nuestra red puede hacernos cumplir el SLA una vez promediado en un intervalo grande de tiempo. Por ello, el SLA no será siempre un buen indicador de las anomalías puntuales de la red.
TWAMP (Two-Way Active Measurement Protocol)
TWAMP define medidas entre dos puntos de la red que se identifican a través de su dirección IP. Un extremo (generador) origina la medida inyectando los paquetes y el otro extremo actúa como reflector, devolviendo los paquetes al origen. Los paquetes TWAMP se envían típicamente 1 por segundo ( 1 pps) y se encapsulan en un puerto UDP (evitando así las retransmisiones y reconocimientos de TCP). El extremo reflector básicamente cambia direcciones origen y destino para retornar el paquete.
Para las medidas de latencia y jitter, los paquetes TWAMP se marcan en tiempo al ser enviados y recibidos tanto en el extremo local (generador) como en extremo remoto (reflector).
Tiempo de proceso del paquete en el reflector = T_tx2 – T_rx1 (se resta del total)
RTD = T_rx2- T_Tx1 - (T_tx2 - T_rx1)
El jitter se mide como la diferencia en el RTD entre un paquete y el siguiente. Para algunos tráficos como VoIP es más importante tener un retardo constante aunque alto que no variable, es decir, un jitter elevado.
El packet loss (o FLR) se mide únicamente sobre los paquetes TWAMP y por tanto no representa una medida fiel de la pérdida de paquetes en la red.
Y.1731
A diferencia de TWAMP, las medidas Y.1731 se realizan a nivel 2, es decir, directamente sobre tramas Ethernet y por tanto sólo pueden realizarse en redes de nivel 2 extremo a extremo (no ruteadas).
Y.1731 define una compleja arquitectura para permitir realizar medidas extremo a extremo (end-to-end) con posibilidad de interconexión de diferentes redes y proveedores de servicio.
Los principales elementos de esta arquitectura son:- MEG - Maintenance Entity Group – Grupo de MEs
- ME - Maintenance Entity – Agrupa los MEPs que terminan las conexiones
- MEP - Maintenance End Point – Dos para punto a punto o varios para punto-mutipunto
La normativa Y.1731 define una métrica para FDV y para IFDV pero dos métricas diferentes para FLR. Estas métricas se basan en los siguientes tipos de mensajes/paquetes:
CCM - Continuity Check Message
Estos mensajes se usan para mantener una tabla de estado de todos los puntos o MEP de la arquitectura Y.1731 y poder dar un primer nivel de alarma en caso de fallo de alguno de ellos
Los MEP intercambian mensajes CCM Multicast (1 pps típicamente). Si un MEP para de transmitir mensajes CCM los otros MEPs envían una alarma
El mensaje incluye el estado de los puertos locales del MEP facilitando la localización exacta del fallo.
DMM/DMR - Delay Measurement Message/Reply
Estos paquetes se usan para medir latencia (FDV) y jitter (IFDV). Un extremo envía un paquete DDM (típicamente 1 pps) con marca de tiempo en tx y rx. El extremo remoto envía un paquete de respuesta DMR que incluye las marcas originales del DDM y le añade las nuevas locales. A través de la resta de estas marcas, se obtiene el RTD igual que en TWAMP.
Puesto que los paquetes se envían entre un extremo y otro son de tipo Unicasts entre dos MEP concretos de la red. En aplicaciones multipunto deberemos definir tantas sesiones MEP - MEP como extremos remotos queramos medir.
LMM/LMR – Loss Measurment Message/Reply
Estos paquetes se usan para medir frame loss ration (FLR).
El paquete LMM se marca con el contador de paquetes transmitidos del EVC (Ethernet Virtual Circuit) en transmisión y con el contador de paquetes recibidos en recepción.
La respuesta LMR se marca con los contadores en el sentido inverso. Comparando estas marcas en ambos extremos podemos calcular el FLR (Frame Loss Ratio) sobre TODO EL TRAFICO DEL EVC y no sólo sobre los paquetes LMM/LMR.
Al igual que en el caso anterior, esta medida sólo funciona en conexiones punto a punto ya que debemos medir todos los paquetes de usuario y del protocolo entre ambos extremos.
SMM/SMR - Synthetic Loss Measurment Message/Reply
De forma similar a la medida FLR en TWAMP, estos paquetes se usan para estimar la FLR y se envían a un ritmo de 1 pps.
El paquete SMM se marca con un número de secuencia autoincrementado
La respuesta SMR también se marca con un número de secuencia en el sentido opuesto
Por tanto, la pérdida o salto de un número de secuencia implica FL (pérdida de paquete) en los paquetes SM. A modo de ejemplo, un SM FLR de 0,01% implica un paquete perdido de 10000 = 10000 seg (2,7h). Por tanto los SLA basados en SMM/SMR deben procesarse en períodos de 24h o 30 días para tener validez.
No hay comentarios:
Publicar un comentario