Posts etiquetados ‘G.709’

Esta entrada es un resumen del Acuerdo de Implementación del OIF para OFP (OTN over Packet Fabric Protocol). Se trata de un documento de gran complejidad dirigido a los expertos. Se necesita conocimiento previo de la espeficiación G.709 de la ITU para sacarle el máximo partido a esta documentación.

Iré publicando los diferentes apartados en varias entradas, para facilitar su análisis y comprensión. Por favor, si detectas algún error o traducción mejorable, por favor indícamelo. Gracias de antemano.

Introducción

El protocolo OFP se basa en el mapeado de clientes CBR en una ODUk y en la multiplexación de una ODUj de bajo orden en una ODUk de alto orden, tal y como se define en la especificación G.709 de la ITU.

Una cantidad variable de datos provenientes de clientes CBR o de ODUj se mapea en cada ODUk, la cual tiene un periodo fijo. La variación de la cantidad de datos codifica la velocidad del cliente CBR o del flujo ODUj que se transporta dentro de la ODUk. Esta técnica, comunmente referida a los estándar  OTN, se llama justificación y se reutiliza aquí como la técnica para codificar la información de sincronización del ODUk/ODUflex conmutado a través de la matriz de paquetes. La velocidad del cliente ODUk se codifica variando la cantidad de datos en cada paquete, los cuales se construyen sobre un mismo periodo de tiempo fijado.

Requisitos del OFP

Para que el OFP pueda soportar el transporte de los clientes ODUk/ODUflex entre los elementos de red y las matrices de conmutación de paquetes con una variedad de características  de implementación, es necesario que cumpla una serie de requisitos.

OFP debería:

  • Proporcionar un mecanismo para transferir la información de sincronismo de las señales cliente ODUk/ODUflex a través de la matriz de paquetes, tal y como se recoge en la recomendación G.8251 ODCr  y Cp de la ITU-T, donde las especificaciones de sincronismo se siguen cumpliendo sin reducción en el máximo número de elemenos de red permitidos por el modelo de referencia hipotétito de la G.8251
  • Proporcionar un mecanismo para transferir la información de sincronismo de las señales cliente ODUk/ODUflex a través de una matriz de paquete que sea agnóstica de la latencia de la matriz y de las variaciones de latencia.
    • Soportar implementaciones de matriz de paquetes con un máximo de latencia de hasta 100μs y un máximo en la variación de la latencia de hasta  50μs.
    • Proporcionar un mecanismo para compensar la latencia de la matriz de paquetes, que tenga valor configurable mayor o igual que la máxima latencia de la matriz y menor o igual que  100μs, con una resolución mejor que 5ns.
  • Proporcionar un mecaniscmo para señalizar el estado del cliente ODUk/ODUflex (Status = No Defect,Signal Degrade, Signal Fail)
  • Proporcionar un mecanismo de protección contra el re-entramado del flujo ODUk/ODUflex ante la pérdida de un único paquete por parte de la matriz  de paquetes
  • Soportar el uso de un reloj de referencia común de 311.04MHz, que esté en fase con un pulso de sincronización de  8kHz
  • Soportar matrices de paquetes con una variedad de tamaños de paquete interno entre 128 y 512 bytes y una paquetización de ODUk/ODUflex que permita un uso óptimo del ancho de banda de la matriz de paquetes
  • Soporte para implementaciones de receptor y transmisor interoperables

No se requiere que las matrices de paquetes manejen paquetes fuera de servicio. La entrega ordenada de paquetes a través de la matriz de paquetes es responsabilidad de ella misma.

A continuación señalamos una serie de objetivos adicionales que debería cumplir OFP para garantizar el transporte de clientes ODUk/ODUflex a través de elementos de red y matrices de conmutación de paquetes con una variedad de características de implementación. OFP debería:

  • Proporcionar un mecanismo de protección contra un re-entramado del flujo ODUk/ODUflex ante la pérdida de paquete doble (consecutiva) producida en la matriz de paquete.