Integración Fotónica

Los grandes desafíos a los que se enfrenten las redes de transporte del futuro son básicamente minimizar el coste del transporte por bit, maximizando el alcance sin regeneración y la capacidad de la fibra.

Podemos incrementar la capacidad de la fibra usando más longitudes de onda con un menor espaciamiento entre ellas, o más velocidad por cada longitud de onda. Si te interesa el tema puedes ver más detalles de cómo incrementar la eficiencia espectral.

Podemos incrementar el alcance sin regeneración usando mejores soluciones de amplificación óptica en las que se incluya la amplificación Raman, o híbridos EDFA (Erbium Dopped Fiber Amplifier) + Raman. Se requerirá una menor OSNR (Optical Signal to Noise Ratio) por longitud de onda gracias a tecnologías como los receptores coherentes y el FEC SD (Forward Error Correction Soft Decision).

Podemos desplazar funcionalidades desde la óptica hacia la electrónica usando sistemas coherentes que optimicen el coste y potencialmente PICs (Photonic Integrated  Circuits)  para reducir el TCO ( Total Cost of Ownership), especialmente en el borde y en la zona metro.

Por otra parte, habría que optimizar la arquitectura de los nodos para permitir la conmutación a diferentes niveles, sustituyendo los enlaces punto a punto por topologías de mallas completamente ópticas. Las interfaces ópticas de cliente son un buen ejemplo donde coste, tamaño y disipación de potencia son factores críticos.

En cualquier caso, nos interesa  incrementar y mejorar la integración fotónica de los componentes que harán viable todas estas tendencias. Existen fundamentalmente cuatro tecnologías para realizar la integración fotónica, que veremos a continuación.

Tecnologías de Integración Fotónica

Existen diferentes alternativas tecnológicas para desarrollar los circuitos fotónicos integrados (PIC).

• CMOS Photonics. Las tecnologías de integración fotónica basadas en Silicio implementadas sobre CMOS (Complementary Metal Oxide Semiconductor) necesitan de un elevado volumen para que su fabricación sea rentable. El objetivo sería tomar ventaja de esta economía de escala que se produce en la electrónica usando las mismas  instalaciones que las que se utilizan para la fabricación CMOS, de manera que se abarataran los costes de producción de los PIC. La tecnología CMOS permite una integración íntima de óptica con electrónica en el mismo chip. La tecnología CMOS se utiliza en diferentes campos, pero para aplicaciones de telecomunicaciones, existen tres cuestiones fundamentales:
  • Fuentes de luz. Actualmente se utilizan fuentes de luz basadas en  InP o GaAs, y están integradas híbridamente en el chip de Silicio. Existen interesantes desarrollos en algunas startups, industrias de microelectrónica e investigación.
  • Como ya se ha comentado, CMOS photonics necesita de grandes volúmenes. Una fábrica de gran tamaño no es eficiente en costes a menos que se fabriquen más  100.000 unidades al año. El crecimiento de la fibra en el acceso y las conexiones de corto alcance puede ser un aliado para llegar a los volúmenes necesarios.
  • Las soluciones CMOS photonics no siempre serán las mejores aplicaciones fotónicas para las telecomunicaciones. La ventaja de la integración, la flexibilidad y el progreso en el diseño probablemente disminuirán estas limitaciones y las harán más atractivas.

 

• InP. Los PIC basados en Fosfuro de Indio constituyen una importante innovación tecnológica que simplifica el diseño de sistemas ópticos, reduciendo espacios y consumos. Adicionalmente, disminuyendo el coste de la conversión OEO (óptica-eléctrica-óptica) en las redes ópticas, proporcionan una oportunidad de transformación para abrazar el uso de circuitos integrados electrónicos y sistemas software en una red óptica «digital»  que maximice la funcionalidad del sistema, mejorando la flexibilidad de los servicios y simplificando la operación de la red.
  • monolítico, utilizando circuitos integrados
  • híbrido, mezclando componentes discretos con circuitos integrados
• VCSEL.Diodo Láser de Emisión Superficial con Cavidad Vertical.
  • Es un diodo semiconductor que emite luz en un haz cilíndrico vertical de la superficie de una oblea, y ofrece ventajas significativas cuando se compara con láser de emisión lateral comúnmente usados en la mayoría de comunicaciones por fibra óptica.
  • Los VCSELs pueden ser construidos con GaAs, InGaAs.
    
  • Para el funcionamiento del VCSEL, se requiere de una región activa de emisión de luz encerrada en un resonador que consta de dos espejos. En este caso, los espejos son parte de las películas epitaxiales, por lo que estas películas se sobreponen formando una pila. Estos espejos son conocidos como reflectores distribuidos de Bragg (DBRs).
  • Los DBR llegan a formar espesor usando entre 40 y 60 películas en cada DBR, produciéndose un espesor total de 6μm –8μm. Para crear la unión p-n se necesita que un DBR este dopado para hacerlo semiconductor tipo n y el otro DBR tipo p.
  • Los VCSELs tienen alto rendimiento y bajo costo, algunas de sus características son:
    • La estructura puede ser integrada en una configuración de arrays de 2 dimensiones.
    • Su haz circular y baja divergencia eliminan la necesidad de óptica correctiva.
    • Comercialmente la corriente de umbral de un VCSEL es de aproximadamente 4 mA.
    • Alcanza potencias ópticas del orden de 10 mW.
    • Su ancho espectral ( Dl ) es de aproximadamente 1nm.
    • Su longitud de onda central es de aproximadamente 850 nm.
    • Se puede aplicar un VCSEL en transmisión de datos en el rango de velocidad de 100 Mbs a 1 Gbs.

• Silica on silicon. Los bloques que conforman esta tecnología son:
  • Fuentes de luz. Integración del grupo III-V en los procesos estándares CMOS
  • Guías de ondas
  • Moduladores
  • Pasivos, como AWG
  • Receptores
  • Elementos de Conmutación Óptica
  • Funciones electrónicas

La tecnología de integración Silicon Photonics es aplicable en diferentes clases de productos en diferentes momentos temporales, dependiendo de los diferentes grados de madurez de la tecnología y de los mercados.

Integración fotónica en redes de transporte

De manera equivalente a como se integran los circuitos integrados sobre Silicio agrupando un elevado número de transistores en una única pequeña pieza física que es más poderosa, más fiable y consume menos potencia y espacio, hoy en día, los circuitos fotónicos integrados (PIC) agrupan centenares de componentes ópticos en una pequeña pieza física que es también más potente, más fiable y utiliza menos potencia y espacio que la aproximación equivalente usando componentes discretos.

En Enero de 2012 Ericsson anunció su trabajo sobre tecnología fotónica sobre Silicio (silicon photonics) para los supercanales de Terabit. El proyecto comenzó en abril de 2008 y concluyó a finales de 2011. Los resultados públicos los puedes encontrar en la web del proyecto APACHE.

El proyecto APACHE propone una nueva estrategia de integración, análoga a la aproximación que se realiza en la industria electrónica. En el caso de la electrónica, los componentes se montan de manera pasiva sobre una placa de circuitos impresos de acuerdo con las funcionalidades del diseño. Estos componentes pueden ser dispositivos discretos como resistencias, o chips monolíticos como circuitos integrados.

En APACHE, usando circuitos integrados fotónicos basados en la tecnología híbrida de integración Silica on silicon , se supera el primer obstáculo para el equivalente fotónico, a través de procesos de ensamblado pasivos que proporcionan alineamientos de precisión para dispositivos ópticos monomodo, en los que la tolerancia a los alineamientos deben ser de  micras o por debajo. Usando esta aproximación, un dispositivo guíaondas planar sobre silicio actúa como la placa de circuito impreso óptico (o placa madre), proporcionando la matriz de interconexión pasiva de guíaondas

Los componentes monolíticos se integran de manera pasiva sobre una placa hija, que a su vez se monta sobre la placa madre planar de silicio, PLCB (Planar Lightwave Circuit Board). Para ello se necesita un método de diseño unificado para el dispositivo híbrido en el que, además de haber definido las características de alineamiento necesarias para el ensamblaje, se definen los tamaños de los modos de los componentes ópticos en las interfaces entre los elementos activos y pasivos.

Además, comparados con InP, las guíaondas pasivas basadas en silicio muestran menores pérdidas de inserción, menor dispersión por velocidad de grupo, mejor acoplamiento a fibras ópticas y menor sensibilidad con la temperatura. En APACHE, se desarrollaron las placas madre e hijas para que puedan albergar chips monolíticos más grandes, tales como arrays de moduladores InP, láseres DFB, SOAs…La característica básica de los dispositivos APACHE es la agilidad, la cual es posible gracias a la capacidad de generar, modular y regenerar señales ópticas de varios formatos de modulación usando un dispositivo multifuncional. La funcionalidad requerida se ofrece a través de «add-ons» monolíticos,  como por ejemplo láseres moduladores basados en InP, amplificadores, etc., que se ensamblan de manera pasiva en las placas hijas y consecuentemente en la placa madre. Los esfuerzos se centraron en fabricar chips activos con modulación InP, regeneración y recepción de señales >100Gbps.

A finales de enero de 2012, Huawei anunció la adquisición del Centre for Integrated Photonics Ltd. (CIP), lo que apunta a que Huawei querría desarrollar su propia fotónica integrada, sin necesidad de recurrir al mercado. Infinera dispone hace tiempo de un PIC comercial de 500 Gbps que será de 1 Tbps en su siguiente generación.

Tecnología PPXC (Petabit Photonic Cross-Connect)

Se trata de una tecnología fotónica que permitírá la conmutación OTN a nivel de Petabit  a lo largo de todo el enlace óptico con una granularidad lo suficientemente fina.

Optimizando la tecnología de un láser sintonizable de InP se pueden generar prototipos de láseres para conmutación ultrarápida, permitiendo a su vez generar equipamiento que aproveche estas ultra capacidades. Esto ya está a puntito de mostrarse públicamente y puedes encontrar la referencia aquí

La conmutación ágil y de capacidad ultragrande es una prometedora tecnología para las redes ópticas del futuro. El componente clave de esta funcionalidad es la tecnología que permite láseres sintonizables. Estamos hablando de que los láseres se sintonizarían en nanosegundos.

Una tecnología de crossconexión todo óptica dotará de una ventaja única a los clusters de conmutación OTN de capacidad ultragrande que formarán parte de los backbone de las redes de transporte del futuro, o de los grandes Data Center o cualquier otra aplicación donde sea conveniente.

El nivel de integración es clave para el futuro de los PIC.  Recientemente la compañía Oclaro demostró con éxito que los PIC completamente monolíticos en InP pueden ser usados para ofrecer elevadas prestaciones a bajo coste

Todos estos movimientos apuntan a que la integración fotónica es el futuro habilitador de las nuevas prestaciones que se requieren en las redes de transporte ópticas. Es un futuro que ya ha comenzdo.

Integración de Redes de Paquetes y Redes Ópticas

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…

La Incertidumbre del Tráfico IP

El tráfico en las redes IP tiene fundamentalmente dos componentes. Por una parte está el tráfico que se establece entre usuarios y servicios que presta esa red IP. Si se establecen sesiones P2P (Peer to Peer) entre clientes de una misma red IP, ese tráfico permanece dentro de dicha red IP. En cambio, si el cliente busca información que no se encuentra disponible en la red IP, saldrá hacia las interconexiones para buscarlo, en otras redes IP del mismo país, o hacia la salida internacional, en busca de redes IP de otros países donde se conectan los servidores en los que reside la información y/o el servicio que el usuario anda buscando.

Cuando los programas P2P hicieron su aparición se produjo dos efectos principales en las grandes redes IP. Por una parte, el tráfico sufrió un incremento considerable. Por la otra, gran parte de ese incremento fue asumido dentro de las propias redes, ya que se establecían conexiones entre clientes de la misma red. Estamos hablando de la época de oro del emule y demás familiares y los torrents.

Con la aparición de páginas de descarga directa, el perfil del tráfico sufrió un importante cambio. Como los servidores de este tipo de páginas se encontraban en países muy concretos y te ofrecían la posibilidad de acceder a los contenidos de manera mucho más rápida, el tráfico P2P fue decreciendo lentamente a la par que se incrementaba el tráfico que iba dirigido a las interconexiones, en busca de esos pocos países donde residían los servidores de descarga directa. Estamos hablando de Megaupload, Rapidshare y demás familiares.

Ahora llega el FBI y pega un portazo a una de las principales páginas de descarga directa, y el resto aplican el dicho de…cuando las barbas de tu vecino veas pelar…Consecuencias inmediatas, el tráfico de interconexión desciende drásticamente mientras se va recuperando las antiguas costumbres peer to peer.

La moraleja de este cuento es que el tráfico IP crece, más o menos rápido, pero crece. Lo que no sabemos es cómo. Creo que ha quedado claro que las aplicaciones y los usos serán los que determinen como dimensionar y planificar una red IP. No es lo mismo llevarlo todo a un punto o un par de puntos que distribuirlo por toda tu red.

La cuestión es que en cualquier momento puede aparecer cualquier nueva killer application que te vuelva a poner patas arriba los patrones de tráfico de tu red y tire por tierra todas tus previsiones de planificación y gestión de recursos. Con esta incertidumbre manifiesta, una integración entre el plano IP y el plano óptico empieza a cobrar sentido por encima de las pretensiones de algunos jugadores específicos que siempre habían apostado por ello.

La red IP enruta el tráfico estupendamente, pero si no tiene asociada una red óptica que transporte los paquetes de un router a otro, nos vale de bien poco.

En la mayoría de las redes de los grandes proveedores de servicio, red IP y red óptica conforman dos mundos independientes en todos los sentidos, operativo, diseño, planificación, gestión… Pero en estos tiempos revueltos, empieza a  tomar forma la idea de que si dispongo de una planificación flexible , dinámica y conjunta de mis recursos IP y de mis recursos ópticos seré mucho más eficiente a la hora de enfrentarme a nuevos cambios del veleta tráfico IP, afrontándolos de manera ágil, dinámica y por supuesto efectiva en costes.

Eso sólo sería viable si existe algún tipo de integración entre los planos de control de ambos mundos. Es decir, si la red IP se constituye como cliente de la red óptica y es capaz de solicitar servicios de conectividad en tiempo real. Y la red óptica es capaz de servirlos.

Pero esa es otra historia, de la que hablaremos en otro cuento…

Acuerdo de Implementación del OIF para OFP. 4_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

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.

Acuerdo de Implementación del OIF para OFP. 3_Formato de Paquetes

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.

Acuerdo de Implementación del OIF para OFP. 2_Modelos de Segmentación y Reensamblado (SAR)

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.

Acuerdo de Implementación del OIF para OFP. 1_Requisitos.

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.

Acuerdo de Implementación para OFP (OTN over Packet Fabric Protocol)

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.