Posts etiquetados ‘Protocolo’

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

Cambio de Tamaño de las ODUflex

El cambio de tamaño en los flujos de las ODUflex se especifica en la  ITU G.7044.  Cuando una ODUflex es sometida a un cambio en su tamaño, la velocidad de la ODUflex puede modificarse en un factor de hasta 80X. Esta cantidad en la variación se encuentra fuera del rango de Dnom ± DΔ. Sin embargo, los flujos de ODUflex(GFP)  no se utilizan para enviar información de sincronismos, especialmente durante las operaciones de cambio de tamaño.

Además, la velocidad precisa y la capacidad de señalización de fase de un tamaño de paquete variable no es necesario. La pendiente en la velocidad de la ODUflex se especifica como una velocidad fija de 512Mbps/s. El siguiente esquema se utiliza para señalizar la velocidad de la ODUflex durante el proceso de cambio de tamaño:

  1. Durante “GMP Special Mode” , las funciones SAR de entrada no necesitan generar decisiones de tamaño de paquete para establecer un seguimiento de la velocidad de las ODUflex, ya que serán ignoradas por las funciones SAR de salida. Aunque los tamaños de paquetes individuales son arbitrarios, deben estar dentro del rango de  Bnom±1.
  2. Durante “GMP Special Mode”, las funciones SAR de salida no usan las variaciones del tamaño de los paquetes para determinar la velocidad de la ODUflex. En lugar de eso, las funciones SAR de salida comparan el campo de sincronización de la cabecera OFP con el valor actual del contador de sincronización para determinar la edad del paquete. La velocidad de la ODUflex se ve incrementada si la edad de filtrado es mayor que el objetivo que se ha configurado, y decrementada si es más joven.
  3. Hasta que sea señalado para comenzar por el campo BWR_IND en la cabecera de la  ODUflex, las funciones SAR de salida cambian la velocidad de la ODUflex hasta la velocidad nominal de 512Mbps/s, sujeta al posible recorte por el filtrado en función de la edad del paquete. La pendiente se detiene cuando ha sido señalizado por BWR_IND o cuando la ODUflex ha alcanzado la velocidad final configurada. Durante la pendiente, los procesos descritos para los ajustes basados en la edad actuarán para compensar los ppm offsets entre el reloj de referencia de los Elementos de Red de subida y el reloj de referencia local.
  4. En cualquier momento durante “GMP Special Mode”, las funciones SAR de entrada y salida pueden ser reconfiguradas a la velocidad final de la ODUflex. El Elemento de Red sale “GMP Special Mode” cuando el nodo de subida ha salido “GMP Special Mode”, las funciones SAR han sido reconfiguradas y tanto las funciones SAR de salida como las de entrada se han estabilizado  a la velocidad final de la ODUflex.
  5. Al salir “GMP Special Mode”, el tamaño de paquete variable se utiliza de nuevo para señalizar la velocidad de la ODUflex entre las funciones SAR de entrada y salida.

 Resumen

El Acuerdo de Implementación para OTN sobre Matriz de Conmutación de Paquetes, OFP, define el protocolo que permite la conmutación de las unidades de datos ópticos (ODUk/ODUflex)  de la jerarquía de la  Red de Transporte Óptica (OTN) sobre una matriz de conmutación de paquetes en un elemento de red (NE). Este acuerdo de implementación proporciona las funciones de segmentación y el reensamblado necesarias para la transferencia síncrona, detección de pérdidas de paquetes y reemplazo, y compensación por las variaciones de retardo de los paquetes en los clientes ODUk/ODUflex.

Anuncios

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

Formato de Paquete

En la siguiente figura se puede observar el formato de la trama de paquete del OFP.

 

  • Contiene un campo opcional de 0 a 12 bytes para las sobrecargas del usuario específio y de la matriz. No son ámbito del documento.
  • A continuación un campo de 4 bytes que contiene la cabecera OFP
  • Por último un campo que contiene la carga útil de las ODUk/ODUflex, cuyo tamaño es Bnom±1 byte. Bnom puede configurarse por software, de manera que se optimice el tamaño del paquete con las características de la matriz de conmutación de paquetes.

Veamos con más detalles los campos que forman la cabecera OFP:

  • Timestamp. Es un contador de 16 bits que registra el tiempo de creación de cada paquete en relación al sistema de pulso de trama de 8 KHz (SYNC)  en saltos de ciclos del reloj del sistema de referencia de 311.04MHz (REFCLK) . El rango de Timestamp se encuentra entre 0 y 38879.
  • RSV 1. Es un campo de 6 bits reservado para la futura estandarización. Por ejemplo, se podría combinar con el campo SQ formando una mayor secuencia numérica que podría encargarse de gestionar matrices de paquetes que tendrían que encargarse de entregar paquetes fuera de servicio.
  • SQ. Es una secuencia numérica de 2 bits utilizada para detectar paquetes descartados por la matriz de conmutación, debido por ejemplo a congestión o bits erróneos.  SQ es un contador binario que se incrementa con cada paquete por ODUk/ODUflex.

  • PPSI 1 . Es un campo de dos bits que registra el tamaño del paquete previo. Cuando el paquete previo ha sido descartado por la matriz de conmutación, la tarjeta de línea de salida puede usar PPSI 1 para construir un paquete de reemplazo del tamaño indicado para evitar tener que cambiar el alineamiento de trama del flujo de la  ODUk/ODUflex.

    • PPSI 1 = ‘b00 : El tamaño del paquete previo es de  Bnom bytes

    • PPSI 1 = ‘b01 : El tamaño del paquete previo es de Bnom+1 bytes

    • PPSI 1 = ‘b10 : Reservado

    • PPSI 1 = ‘b11 : El tamaño del paquete previo es de Bnom-1 bytes

  • CSI . Es un campo opcional destinado a la indicación del estado del cliente, que puede ser usado por aplicaciones APS rápidas. CSI transporta el estado del flujo de la ODUk/ODUflex

    • CSI = ‘b000 : Fuerza a la matriz de conmutación a seleccionar esta ODUk/ODUflex  incluso si el flujo alternativo se encuentra en el estado Sin Defectos

    • CSI = ‘b001 : Sin Defectos detectado. Este es el valor por defecto cuando no se usa este campo.

    • CSI = ‘b010 : Signal Degradada detectada

    • CSI = ‘b011 : Fallo de la Señal detectado
    • CSI = ‘b100 : Fallo del servidor de la Señal detectado
    • CSI = ‘b111 :  Fuerza a la matriz de conmutación a no seleccionar esta ODUk/ODUflex sin tener en cuenta el estado del flujo alternativo.
    • CSI = ‘b101 and ‘b110 : Reservado
  • PPSI 2. Es un campo de 2 bits opcional que registra el tamaño del paquete anterior al previo. Cuando dos paquetes consecutivos son descartados por la matriz de conmutación, la tarjeta de línea de salida puede usar PPSI 1 y PPSI 2 para construir dos paquetes de reemplazo del tamaño indicado de manera que se evite  cualquier cambio en el alineamiento de la trama del flujo de la ODUk/ODUflex.
    • PPSI 2 = ‘b00 : El tamaño del paquete anterior al previo es Bnom bytes. Cuando no se usa este campo, adopta este valor por defecto.
    • PPSI 2 = ‘b01 : El tamaño del paquete anterior al previo es Bnom+1 bytes
    • PPSI 2 = ‘b10 : Reservado
    • PPSI 2 = ‘b11 : El tamaño del paquete anterior al previo es Bnom-1 bytes
  • P . Es un campo de paridad impar de 1 bit, que se calcula sobre la cabecera completa del OFP, desde Timestamp a PP
  • Carga adicional para el usuario específico y la matriz. Es un campo opcional de 0 a 12 bytes reservado para datos propietarios del usuario y de la matriz. La especificación de este campo queda fuera del ámbito del documento.
  • Carga útil. Es un campo que transporta  Bnom-1, Bnom, o Bnom+1 bytes de un flujo de ODUk/ODUflex

 En la siguiente figura se muestran el bit de orden de los bits de la  ODUk/ODUflex en ITU G.709 y en este acuerdo de implementación.

El bit más significativo se transmite primero en G.709 y se le asigna el bit 1. El bit menos significativo se transmite el último y se le asigna el bit 8. Los bits correspondientes en el byte de la carga útil son bits  [7] y [0], respectivamente. Los octetos ODUk/ODUflex son insertados en el campo de carga útil en el orden de transmisión.

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.