Posts etiquetados ‘OFP’

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.

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.

Modelos de segmentación y reensamblado (SAR)

Introducción

En el contexto del OFP, un elemento de red consiste en una serie de funciones OTN de entrada, funciones SAR de entrada, una matriz de paquetes,  funciones SAR de salida y funciones OTN de salida.

Un reloj de referencia (REFCLK) y un pulso de sincronización (SYNC) deben ser distribuidos hacia todas las funciones SAR de entrada y salida. Ambos deben ser derivados de una referencia de tiempo común y  estarán en fase.

Las funciones OTN de entrada consisten en un entramador OTUk el cual terminará las cabeceras OTUk, implementará el FEC (Forward Error Correction) y las salidas correspondientes con el flujo ODUk de alto orden. Además, debería tener uno o mas etapas de demultiplexación ODTUjk, las cuales extraerían los clientes ODUj/ODUflex de bajo orden  desde el flujo portador de los ODUk. 

Las funciones SAR de entrada segmentan en paquetes los flujos de alto orden o de bajo orden y los envía hacia la matriz de paquetes.

La matriz de paquetes conmuta el tráfico, que será reensamblado por las funciones SAR de salida y convertidos de nuevo en un flujo de datos ODU que serán procesados en las funciones OTN de salida.

En las funciones OTN de salida, los flujos ODUk de alto orden pueden ser adaptados para convertirse en flujos OTUk añadiendo una cabecera OTUk y los bytes de comprobación del FEC. Los flujos ODUj/ODUflex de bajo orden son multiplexados en flujos ODUk de alto orden. El sistema al completo mantendrá la integridad de la sincronización de los flujos ODU desde la entrada hasta la salida.

Funciones SAR de entrada

A continuación veremos los bloques funcionales de las funciones de segmentación reensamblado de entrada, junto con una representación de las funciones OTN de entrada, tanto con como sin multiplexación de ODTU. Hay que considerar que se trata de representaciones lógicas y en ningún caso están enfocadas a limitar la implementación. Los bloques que están directamente relacionados con OFP están en azul.

En ambos casos, la OTUk será recuperada y procesada:

En el caso del REGENERADOR, el reloj de la ODUk  es un filtro paso bajo, en el caso de la multiplexación, la ODUj/ODUflex  se extrae y se filtra en banda base, antes de ser enviado a la función que decide el tamaño del paquete, PSD (Packet Size Decision).

El filtro paso-bajo representa el filtro desincronizador de 300 Hz estandar, que aparece en los estándares OTN. Los datos de la ODUk o de la  ODUj/ODUflex se envían a la función formateador de paquetes, PF (Packet Formatter).

La función toma decisiones sobre el tamaño del paquete en función de la velocidad del reloj de la ODUk o de la ODUj/ODUflex filtradas.  Decisiones de tamaño de paquetes se generan con una velocidad de N decisiones cada T ciclos del reloj de referencia del SAR, por ejemplo 1 decisión cada 237 ciclos o 32 decisiones cada 943 ciclos.

El PF construye paquetes con el tamaño que el PSD dicta. Además, los paquetes son construidos con una velocidad media de un paquete cada T/N ciclos del reloj de referencia del SAR y podría tener un tamaño medio de (ODUk/ODUflex Rate * T) / (8 * REFCLK * N) bytes. Generar una decisión de tamaño de paquete cada  T/N ciclos podría ser inviable en algunas implementaciones. Por lo tanto, sería deseable generar una decisión de tamaño de paquete cada T ciclos, y consecuentemente segmentarla en N decisiones de tamaño de paquete individuales.

Las decisiones de tamaño de paquete son equivalentes a una función de transporte común conocida como justificación. Los mecanismos tradicionales de  justificación pueden producir discontinuidades de fase de muy baja frecuencia en la sincronización de la señal cliente, difíciles de filtrar. Una técnica bien conocida para generar las decisiones de justificación (o el tamaño del paquete) que minimiza este problema es un modulador Sigma-Delta, que realiza decisiones de justificación muy frecuentemente para proporcionar  modelado de frecuencias de las discontinuidades de fase. Esta técnica debería ser utilizada en la función PSD para generar decisiones de tamaño de paquete agregadas, de manera que se mejoren las prestaciones de la transferencia de sincronismo. Las decisiones de tamaño de paquete individuales se escriben en una cola FIFO de decisión de tamaño. El PF, bajo el control de las decisiones individuales de tamaño de paquete lee desde la cola FIFO de decisión de tamaño, produciendo paquetes de datos del tamaño apropiado. Además le añade la cabecera apropiada requerida por el OFP. Esta cabecera incluye una referencia temporal la cual es determinada por un contador que se incrementa en uno con cada ciclo REFCLK, y se reinicia en cero con la pendiente creciente del pulso SYNC . Esta referencia temporal es utilizada por la función SAR de entrada para compensar las variaciones de latencia de los paquetes. Otra cabecera incluye la asignación de bits para la tolerancia a errores, particualmente pérdida de paquetes y los informes sobre el estado de la señal cliente desde las funciones de entrada a las de salida.

La función PSD se rige por una serie de ecuaciones, que pueden encontrarse en el documento. Una decisión de tamaño de paquete agregada (D) se genera cada T ciclos del reloj de referencia de 311.04MHz (REFCLK).

Dada la elevada velocidad de generación de decisión, la contribución de fase por el jitter/wander es insignificante. Un flujo de entrada ODUflex puede tener un offset de frecuencia de  hasta  ±100ppm. Cuando se acopla con el reloj de referencia local se podría incrementar hasta ±20ppm, con lo que el offset total efectivo sería de  ±120ppm.

Finalmente, los segmentos PSD agregan las decisiones de tamaño de paquete en N decisiones de tamaño paquete individuales. Cada paquete debería tener un tamaño de Bnom ± 1 bytes. La suma de los tamaños de paquete individuales debería codificar la decisión de tamaño de paquete agregada (D) sin ninguna pérdida. Los paquetes deberían ser generados con una velocidad media de  T/N ciclos del sistema del reloj de referencia de 311.04MHz .

Los datos de la ODUk  se envían al formateador de paquetes (PF), que lee las decisiones de tamaño de paquete individual (B) desde la cola FIFO de Decisión de Tamaño, y formatea los datos de la ODUk en paquetes del tamaño dirigido. El formateador de paquete mantiene un contador para la referencia temporal que se incrementa con cada ciclo del reloj de referencia de 311.04MHz (REFCLK).  El valor del contador de referencia temporal en el momento de la creación del paquete se captura en los bytes de cabecera del paquete.

El chip de la interfaz de la matriz  ( Fabric Interface Chip -FIC-) recoge paquetes construidos por el formateador de paquetes mediante un bus de aplicación para paquetes estandar, como OIF SPI-S, o Interlaken, y añade bytes de cabecera específicos de la matriz. Los paquetes se envían al corazón de la matriz para conmutar hacia la tarjeta de línea de salida. En el caso de una tarjeta de línea de entrada híbrida, que se utiliza tanto para clientes OTN como paquetes , el FIC debería segmentar el tráfico de paquete en segmentos más pequeños para transferirlos a través de la matriz.

Funciones SAR de Salida

En las siguientes figuras se puede observar el diagrama de bloques funcionales de dos clases de funciones de salida, configuración de regenerador y configuración de multiplexación de una ODUj/ODUflex en ODUk . Se trata de representaciones lógicas que no pretenden limitar la implementación. Los bloques directamente relacionados con la OFP están en azul.

 

 

 

 

 

 Los paquetes ODUk  son entregados por la matriz de paquetes. Las funciones de re-ensamblado de paquetes (Packet Re-assembly -PR-)  eliminan los bytes de cabecera del OFP y convierte el flujo de paquetes en un flujo serie continuo de ODUk/ODUflex . La función de extracción del tamaño de paquete (Packet Size Extraction -PSE-), como su nombre indica, extrae el tamaño de cada paquete. Dichos tamaños son cargados en la cola FIFO y extraidos a una velocidad media de uno cada T/N ciclos del reloj de referencia. La información resultante del reloj se filtra paso bajo, eliminando el ruido generado por el conformador de ruido de la entrada. Midiendo la velocidad de las actualizaciones de los tamaños de los paquetes en el filtro con un período preciso, las variaciones de retardo de la matriz de paquetes no tienen impacto en el jitter y wander del transmisor de ODUk/ODUflex.

La función SAR de salida mantiene un contador de referencia de tiempo que se incrementa con cada ciclo del reloj de referencia. El contador de referencia de tiempo se inicializa con el pulso SYNC. La función SAR de salida también proporciona una cola FIFO de la variación del retardo de paquete  para cada flujo ODUk/ODUflex. Estas FIFO almacenan tal cantidad de datos que el flujo transmitido ODUk/ODUflex no se ve  interrumpido por las variaciones del retardo en la matriz. Despues de reinicializar, la longitud de la cola FIFO se inicializa suspendiente la operación de lectura hasta que el paquete en la cabeza de la cola FIFO es de una edad configurada. El proceso de inicialización de la cola FIFO puede utilizarse para asegurarse que todos los flujos ODUk/ODUflex tienen la misma latencia a través de los elementos de red, sin tener en cuenta las variaciones de retardo en la matriz.

El flujo de datos de salida y su reloj filtrado son entonces procesados por las funciones OTN. Para una aplicación de regenerador esta información se pasa hacia el fragmentador OTN de salida. Si lo que se quiere es una configuración de multiplexación ODUj/ODUflex, entonces la información se utiliza por el multiplexor y la señal multiplexada se procesa por el fragmentador OTN.

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.

Las redes de comunicación ópticas están evolucionando desde una orientación puramente TDM (SONET/SDH) hacia una red convergente de paquetes (Ethernet) y TDM (OTN).

Históricamente, los elementos de red presentaban matrices separadas, por un lado los paquetes y por otro el tráfico TDM. Una única matriz simplificaría espacios y consumos.

Es una realidad que el tráfico se está desplazando progresivamente de TDM a paquetes, sería económicamente ventajoso construir elementos de red con matrices de conmutación orientadas a paquetes, y emplear técnicas de emulación de circuitos para convertir flujos de clientes OTN en un formato de paquete que sean conmutados por la matriz de paquetes.

El OIF  (Optical Internetworking Forum) ha aprobado recientemente un acuerdo de implementación para un protocolo de OTN sobre paquetes, OFP. El objetivo es facilitar a los desarrolladores el crear una única matriz de conmutación que sirva tanto para la red de transporte óptico (OTN) como para el tráfico basado en paquetes.

El acuerdo de implementación define el mapeo de protocolos necesario para convertir un flujo OTN en paquetes que mantengan frecuencia y fase. El protocolo puede ser implementado mediante ASSP (producto estandar para una aplicación específica), FPGA (matriz de puertas programable) o ASIC (circuitos integrados de aplicación específica).

Este acuerdo de implementación ha sido la respuesta que ha dado el OIF a los operadores que buscan una manera eficiente de gestionar, con una única matriz de conmutación, tráficos tan dispares como OTN y Ethernet/IP.

A día de hoy, la mayoría de suministradores ofrecen matrices de conmutación separadas, para OTN y cualquier otro tipo de tráfico. Esto conlleva que el espacio utilizado en las centrales para alojar los equipos y el consumo eléctrico es muy elevado.

Con este acuerdo de implementación se pretende acelerar la convergencia de tráfico de paquetes y tráfico OTN, adecuándose a las necesidades de la industria.

El acuerdo de implementación OFP  (OTN Over Packet Fabric Protocol) define los protocolos que habilitan la conmutación de flujos ODUk/ODUflex que llegan a las tarjetas  de cliente de un elemento de red y salen por la tarjeta de línea de una matriz de conmutación orientada a paquetes. Este nuevo acuerdo de implementación establece la segmentación y reensamblado de los flujos ODUk/ODUflex de manera que la frecuencia y la fase de dichos flujos se mantenga.

En breve más detalles, sólo aptos para ultratecnólogos y masoquistas.