Posts etiquetados ‘Redes de Paquetes’

En  La Incertidumbre del Tráfico IP, traté de poner de manifiesto, que era cada vez más interesante y necesario tratar de unificar los planos de paquetes y óptico.

La red IP está compuesta de routers conectados entre sí. Cada router está en una ubicación o PoP (Point of Presence) diferente. Los routers deciden para cada paquete que reciben, por dónde lo tienen que sacar. Pero hasta ahí llega su trabajo, que no es poco. Para que el paquete llegue al router destino, necesita de una red de transporte o de transmisión, que es la que facilita la conectividad, no sólo de las redes IP, sino de todas las redes en general.

La red de transporte para largas distancias es una red óptica. Se utilizan sistemas DWDM para transmitir la información. Se trata de un sistema que utiliza una multiplexación en longitud de onda, de manera que cada longitud de onda es capaz de transportar información de manera independiente, cada longitud de onda es un canal y todos los canales van sobre la misma fibra óptica.

Las redes de paquetes y las redes ópticas son dos mundos separados. Pero si hubiera algún tipo de interacción entre ellos, se produciría una eficiencia importante para afrontar la incertidumbre del tráfico IP. La red IP detectaría sus necesidades de transporte y al hablar con la red óptica, ésta le proporcionaría los caminos requeridos. A día de hoy, estos caminos se provisionan de manera estática y modificarlos o ampliarlos requiere de una serie de actuaciones y procedimientos que no son ni ágiles, ni flexibles, ni dinámicos. Agilidad, flexibilidad y dinamismo son justo las capacidades que estamos buscando en las redes de nueva generación.

Podemos entonces abordar esa integración desde dos perspectivas diferentes, que no son excluyentes sino complementarias. Es decir, podemos afrontar la integración desde cada una de ellas o combinándo ambas:

  • Integrando el plano de datos. El Plano de datos representa los datos reales de los usuarios. Por ejemplo, los bits de información contenidos en los flujos de datos de un circuito óptico que lleva un servicio o múltiples servicios.
  • Integrando el plano de control. El Plano de Control es una entidad donde reside parte de la inteligencia de la red. Automatiza funcionalidades dentro de una red, como añadir o eliminar circuitos y restaurarlos una vez que se ha solventado el fallo que produjo su caída. Abarca protocolos de señalización internodos e intercomponentes, descubrimiento de la topología, anuncio y reserva de recursos, cálculo de caminos y cálculos de enrutamiento e información a intercambiar, y gestión automatizada de los estados de los enlaces.

La interfaz UNI (User Network Interface) se posiciona como una gran valedora de este tipo de soluciones. UNI es la interfaz de señalización fuera de banda que permite a un router de la capa IP solicitar servicios de conectividad a los equipos de la capa de  red óptica de transporte, facilitando así una coordinación multicapa.

Integración del Plano de Datos

Actualmente los elementos de red que componen las redes de paquetes IP son los routers, y los elementos de red que componen las redes ópticas son, (simplificando) los ROADM (Multiplexores Ópticos de Extracción e Inserción Reconfigurables). Se trata de equipamiento diferenciado e independiente. Se ubican en sitios distintos. Es decir, hablamos de cajas diferentes que no tienen nada que ver entre ellas.

De cara a la integración del plano de datos, se plantean tres posibles alternativas:

  • Overlay: El equipamiento de  paquetes y óptico seguirán estando en dos cajas distintas, pero se hablarán entre ellos usando  UNI
  • Augmented: Los transpondedores, que son los elementos necesarios para realizar la conversión de óptico a eléctrico y viceversa y que actualmente forman parte de los ROADM, pasarían a formar parte de los routers
  • Integrado: Tenemos una única caja con todas las funcionalidades necesarias tanto a nivel de paquete como a nivel óptico. Es decir, tendríamos un nuevo elemento de red que sería la  fusión del router y el ROADM

Cada una de ellas con sus ventajas e inconvenientes, sus seguidores y detractores. Por ejemplo, considerando aspectos de flexibilidad, las propuestas integradas y aumentadas tienen bastante que perder frente a la elevada flexibilidad que ofrece la propuesta overlay.

Si hablamos de tener diferentes suministradores en las dos capas, el modelo integrado deja de tener interés.

De cara a la madurez tecnológica, el modelo overlay es el que parece mejor posicionado, y de cara a un análisis de costes no está nada claro cual sería la opción ganadora, sobre todo en abstracto, sin aplicarlo a un escenario concreto.

Integración del Plano de Control

Cada red tiene su propio plano de control.  Si conectamos los planos de control de la red de paquetes y la red óptica mediante interfaces UNI, al establecerse un flujo de comunicación entre ambas, en el mismo idioma…se entenderían.

Se plantean igualmente tres modelos posibles a seguir

  • Modelo Único: Existe un único plano de control integrado, sin separación entre capas. Es decir, no se trata de que hablen entre ellos, sino que sólo hay uno.
    • Las redes de paquetes y las redes ópticas se tratan como una única red integrada desde el punto de vista del plano de control.
    • La red IP y la red de transporte utilizan la misma instancia de los protocolos de encaminamiento y señalización.
  • Modelo Coordinados: Los planos de control están separados y hablan entre ellos.
    • Mantiene una señalización común para ambos planos mediante UNI
    • Los encaminamiento en cambio están completamente separados
    • La red IP se configuraría automáticamente mediante el sistema de gestión.
  • Modelo Separado: Los planos de control seguirían siendo completamente independientes:
    • La señalización entre ellos se realizaría mediante UNI
    • La red IP se configuraría de manera manual

De nuevo, cada uno de los modelos tienen ventajas e inconvenientes. Si hablamos de escalabilidad, el único modelo que la garantiza es el separado, en los otros dos habría que hacer estudios sobre escenarios concretos para poder hacer una estimación.

El modelo único queda descartado en una política de muchos suministradores. El modelo separado es el más maduro, seguido del coordinado y finalmente el único, que se encuentra más lejos en el tiempo.

Las implicaciones de realizar la integración de los planos de control, en cualquiera de las opciones planteadas son considerables. Los problemas asociados también. Por lo pronto, estándares y tecnologías tienen que dar el pistoletazo de salida. Pero cuando tienes claro el camino que debes tomar, no por ser farragoso hay que desanimarse…

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.

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.

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.