ES2625741T3 - Codificación transitoria de transporte de servicio universal - Google Patents

Codificación transitoria de transporte de servicio universal Download PDF

Info

Publication number
ES2625741T3
ES2625741T3 ES10801961.3T ES10801961T ES2625741T3 ES 2625741 T3 ES2625741 T3 ES 2625741T3 ES 10801961 T ES10801961 T ES 10801961T ES 2625741 T3 ES2625741 T3 ES 2625741T3
Authority
ES
Spain
Prior art keywords
traffic
ustm
flow
ust
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES10801961.3T
Other languages
English (en)
Inventor
Serge Francois Fourcand
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2625741T3 publication Critical patent/ES2625741T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Time-Division Multiplex Systems (AREA)

Abstract

Un aparato que comprende: una matriz de conmutación (310) acoplada a una pluralidad de interfaces y configurada para conmutar un flujo de datos de multiplexación de transporte de servicio universal (UST) (USTM) recibido a partir de una de las interfaces hacia al menos algunas de las otras interfaces, en donde la matriz de conmutación (310) comprende medios para recibir el flujo de datos USTM, en donde el flujo de datos USTM comprende una pluralidad de intervalos temporales, un tráfico de conmutación de paquetes, un tráfico de conmutación de circuitos y un indicador de transición de tipo de datos que separa el tráfico de conmutación de circuitos del tráfico de conmutación de paquetes, el indicador de transición de tipo de datos indica un cambio de estado entre el tráfico de conmutación de paquetes y el tráfico de conmutación de circuitos, la matriz de conmutación (310) comprende, además, medios para separar el tráfico de conmutación de circuitos y el tráfico de conmutación de paquetes utilizando el indicador de transición de tipo de datos, un primer conmutador para conmutar el tráfico de conmutación de circuitos y un segundo conmutador para conmutar el tráfico de conmutación de paquetes, caracterizado por cuanto que el indicador de transición de tipo de datos se proporciona utilizando campos de código de operación (510) en un bloque de codificación (500), siendo los campos de código de operación (510) utilizados para indicar un conjunto de señales de transición UST, que comprende un inicio y un final de diferentes flujos de tráfico.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Codificacion transitoria de transporte de servicio universal ANTECEDENTES DE LA INVENCION
Ethernet es el protocolo preferido para numerosos tipos de redes puesto que es flexible, descentralizado y escalable. Ethernet comprende una familia de tecnologfas de gestion de redes informaticas basadas en tramas para redes de area local (LANs), y define varias normas de cableado y senalizacion para el modelo de gestion de red de Capa Ffsica de la Interconexion de Sistemas Abiertos (OSI) y un formato de direccionamiento comun y Control de Acceso a Soporte (MAC) en la Capa de Enlace de Datos. Ethernet es flexible por cuanto que permite que paquetes de datos de tamanos variables se transporten a traves de diferentes tipos de soportes utilizando varios nodos que tienen cada uno diferentes velocidades de transmision.
La gestion de Redes Opticas Smcronas (SONET)/Jerarqma Digital Smcrona (SDH) son protocolos de multiplexacion normalizados que transfieren multiples flujos de bits digitales a traves de fibras opticas o de interfaces electricas. Debido a las caractensticas de neutralidad y orientadas al transporte del protocolo SONET/SDH, SONET/SDH se utiliza para transportar cantidades bastante grandes de llamadas telefonicas y trafico de datos a traves de la misma fibra o hilo de conexion sin problemas de sincronizacion. Las normas de transmision de redes SONET/SDH estan basadas en la denominada multiplexacion por division temporal (TDM). TDM es una tecnologfa en donde dos o mas senales o flujos de bits son evidentemente objeto de transferencia simultanea como sub-canales en un solo canal de comunicaciones pero ffsicamente tienen turnos en el canal. Lo que antecede se consigue dividiendo el dominio temporal en una pluralidad de intervalos temporales recurrentes, p.ej., de aproximadamente la misma longitud, uno por cada sub-canal. En consecuencia, una trama TDM corresponde a un intervalo temporal por sub-canal.
El documento WO2008/092389A1 da a conocer una arquitectura de datos compatible con multiples componentes. Una red central comprende un primer conmutador que incluye un primer puerto configurado para comunicar un flujo de datos por intermedio de una interfaz de Ethernet, y un segundo puerto configurado para comunicar el flujo de datos por intermedio de una interfaz de SONET/SDH, y un segundo conmutador que comprende un tercer puerto configurado para recibir el flujo de datos a partir del primer conmutador por intermedio de la interfaz de Ethernet, en donde el primer conmutador y el segundo conmutador estan sincronizados.
El documento WO 01/69834A1 da a conocer un esquema de transporte de datos hubrido por intermedio de redes opticas. Una trama esta configurada para ser transmitida en una red y memorizar paquetes de datos en una pluralidad de canales. Uno o mas de entre la pluralidad de canales pueden configurarse para memorizar uno o mas fragmentos de los paquetes de datos. Cada uno esta separado y vinculado por un apuntador de desplazamiento. Cada uno puede ser tambien cualquier tipo, cualquier longitud y estar situado en cualquier lugar en la trama incluyendo partes de error y etiquetas para controlar el enrutamiento de la carga util.
SUMARIO DE LA INVENCION
En una forma de realizacion, la idea inventiva incluye un aparato que comprende una matriz de conmutacion acoplada a una pluralidad de interfaces y configurada para conmutar una pluralidad de flujos de datos de multiplexacion de transporte de servicio universal UST (USTM) recibidos desde una de las interfaces hacia al menos alguna de las demas interfaces, en donde la matriz de conmutacion comprende medios para recibir el flujo de datos USTM, en donde el flujo de datos USTM comprende una pluralidad de intervalos temporales, un trafico de conmutacion de paquetes, un trafico de conmutacion de circuitos y un indicador de transicion de tipo de datos que separa el trafico de conmutacion de circuitos con respecto al trafico de conmutacion de paquetes, en donde el indicador de transicion de tipo de datos indica un cambio de estado entre el trafico de conmutacion de paquetes y el trafico de conmutacion de circuitos, comprendiendo, ademas, la matriz de conmutacion medios para separar el trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes utilizando el indicador de transicion de tipo de datos, un primer conmutador para conmutar el trafico de conmutacion de circuitos y un segundo conmutador para conmutar el trafico de conmutacion de paquetes, en donde el indicador de transicion de tipo de datos se proporciona utilizando campos de codigo de operacion en un bloque de codificacion, utilizandose los campos de codigo de operacion para indicar un conjunto de senales de transicion UST, que comprenden un inicio y un final de diferentes flujos de trafico.
En otra forma de realizacion la idea inventiva incluye un metodo que comprende la recepcion de un flujo de datos de multiplexacion por parte de servicio universal (UST) (USTM) que comprende una pluralidad de intervalos temporales, un trafico de conmutacion de paquetes, un trafico de conmutacion de circuitos y un indicador de transicion de tipo de datos que separa el trafico de conmutacion de circuitos con respecto al trafico de conmutacion de paquetes, en donde el indicador de transicion de tipo de datos indica un cambio de estado entre el trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes; la separacion del trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes utilizando el indicador de transicion de tipo de datos; y la conmutacion del trafico de conmutacion de circuitos en un primer conmutador y el trafico de conmutacion de paquetes en un segundo conmutador, en donde el indicador de transicion de tipo de datos se proporciona utilizando campos de codigos de
5
10
15
20
25
30
35
40
45
50
55
60
65
operacion en un bloque de codificacion, siendo los campos de codigo operacion utilizados para indicar un conjunto de senales de transicion UST, que comprende un inicio y un final de diferentes flujos de trafico.
Estas y otras caractensticas se entenderan con mayor claridad a partir de la siguiente descripcion detallada haciendo referencia a los dibujos adjuntos y las reivindicaciones.
Para un entendimiento mas completo de esta idea inventiva, se hace ahora referencia a la siguiente breve descripcion tomada en referencia con los dibujos adjuntos y una descripcion detallada en donde las referencias numericas similares representan elementos similares.
BREVE DESCRIPCION DE LOS DIBUJOS
La Figura 1 es un diagrama esquematico de una pluralidad de diferentes tipos de trafico.
La Figura 2A es un diagrama esquematico de una forma de realizacion de una arquitectura de multiplexacion/demultiplexacion de transporte de servicio universal.
La Figura 2B es un diagrama esquematico de una forma de realizacion de un trafico transportado.
La Figura 3 es un diagrama esquematico de una forma de realizacion de un aparato de conmutacion UST.
La Figura 4 es un diagrama esquematico de una forma de realizacion de una unidad de senalizacion de codigo de operacion multiparte (SU).
La Figura 5A es un diagrama esquematico de una forma de realizacion de un bloque de codificacion.
La Figura 5B es un diagrama esquematico de otra forma de realizacion de un bloque de codificacion.
La Figura 6 es un diagrama esquematico de una forma de realizacion de una unidad SU de codificacion.
La Figura 7 es un diagrama esquematico de otra forma de realizacion de una unidad SU de codificacion.
La Figura 8 es un diagrama de una forma de realizacion de una pluralidad de sfmbolos de control.
La Figura 9 es un diagrama esquematico de una forma de realizacion de un mapa de flujos.
La Figura 10 es un diagrama de flujo de una forma de realizacion de un metodo de senalizacion UST.
La Figura 11 es un diagrama esquematico de una forma de realizacion de un sistema informatico de uso general. DESCRIPCION DETALLADA DE LAS FORMAS DE REALIZACION
Debe entenderse, desde el principio, que aunque una puesta en practica ilustrativa de una o mas formas de realizacion se proporcionan a continuacion, los sistemas y/o metodos dados a conocer pueden ponerse en practica utilizando cualquier numero de tecnicas, actualmente conocidas o en existencia. La idea inventiva no debe, en forma alguna, limitarse a las puestas en practica ilustrativas, dibujos y tecnicas que se ilustran a continuacion, incluyendo los disenos y puestas en practica, a modo de ejemplo, que se ilustran y describen a continuacion, sino que pueden modificarse dentro del alcance de las reivindicaciones adjuntas junto con su gama completa de equivalentes.
UST es una tecnologfa de conmutacion y transporte convergente. El esquema UST puede utilizarse para el mapeado de correspondencia del trafico de conmutacion de paquetes (o sin conexion) y/o el trafico de conmutacion de circuitos (u orientados a la conexion) en un flujo unico, que puede transportarse en un enlace. La tecnologfa UST puede proporcionar un transporte de trafico de conmutacion de paquetes y de conmutacion de circuitos convergente en un enlace unico y soportar capacidades de sincronizacion de reloj de red extremo a extremo y de conmutacion de paquetes y conmutacion de circuitos, y tener un interfuncionamiento incorporado con protocolos existentes que pueden soportar la emulacion del servicio de conmutacion de circuitos. La tecnologfa UST puede ser compatible con las redes SDH/SONET existentes y desplegarse como parte de las redes basadas en paquetes actuales o emergentes, tales como redes basadas en Ethernet.
A continuacion se dan a conocer sistemas y metodos para mejorar la conmutacion de trafico sin conexiones (o de conmutacion de paquetes) y trafico orientado a la conexion (o de conmutacion de circuitos) utilizando la tecnologfa UST. Los sistemas y metodos comprenden una pluralidad de esquemas de codificacion transicionales UST que pueden utilizarse para soportar UST, p.ej., para redes SDH/SONET y/o redes basadas en Ethernet. Los esquemas de codificacion transicional UST pueden utilizarse para mejorar el mapeado de correspondencia de trafico TDM y/o trafico de Ethernet en un enlace de transporte UST, p.ej., basado en un protocolo USTM, anadiendo informacion de transicion de trafico sin anadir una sobrecarga importante al flujo/enlace de transporte. Utilizando el protocolo USTM,
5
10
15
20
25
30
35
40
45
50
55
60
65
el trafico TDM y el trafico de Ethernet pueden multiplexarse en una pluralidad de intervalos temporales y transportarse por intermedio de un enlace. Cuando el trafico multiplexado alcanza su destino, el trafico TDM y el trafico de Ethernet pueden demultiplexarse a partir del flujo USTM transportado. Los esquemas de codificacion transicionales de uSt pueden proporcionar senalizacion UST mejorada en el trafico USTM, a modo de ejemplo, para indicar la transicion de diferentes trafico TDM y/o trafico de Ethernet en el flujo USTM sin utilizar un ancho de banda de enlace importante y en consecuencia, pueden reducir la utilizacion del enlace o su capacidad. En los esquemas de codificacion transicionales de UST, una pluralidad de codigos de operacion (opcodes) pueden utilizarse en el flujo USTM para proporcionar diferentes indicaciones de senalizacion UST, p.ej., para indicar transiciones entre diferentes traficos en el flujo.
La Figura 1 ilustra una forma de realizacion de una pluralidad de tipos de trafico diferentes 100, UE pueden multiplexarse y transportarse utilizando UST. Los diferentes tipos de trafico 100 pueden comprender trafico tDm 102 y el trafico de Ethernet 104. A modo de ejemplo, el trafico tDm 102 puede corresponder a redes SONET/SDH y el trafico de Ethernet 104 puede corresponder a redes basadas en Ethernet. El trafico TDM 102 y una parte del trafico Ethernet 104 pueden corresponder al trafico orientado a la conexion 106. En condiciones normales, el trafico orientado a la conexion 106 puede transportarse en una red por intermedio de una pluralidad de rutas configuradas o calculadas, p.ej., utilizando una pluralidad de conmutadores de red. Otra parte del trafico de Ethernet 104 puede estar en correspondencia con un trafico sin conexiones 108. En condiciones normales, el trafico sin conexiones 108 puede transportarse entre nodos de redes, p.ej., utilizando puentes de red, basados en una direccion de destino (DA), una direccion origen (SA), o ambas en el trafico. A modo de ejemplo, el trafico sin conexiones 108 puede reenviarse sobre una base de salto por salto operativo con un procesamiento mmimo en cada nodo. El trafico sin conexiones 108 puede tener mas baja prioridad que el trafico orientado a la conexion 106.
En una forma de realizacion, el esquema UST puede utilizarse para proporcionar funciones de transporte, conmutacion y sincronizacion para los diferentes tipos de trafico 100. A modo de ejemplo, un conmutador (no ilustrado) puede poner en practica el protocolo USTM para transportar los diferentes tipos de trafico 100 desde un nodo origen a un nodo de destino. El conmutador puede conmutar tambien los diferentes tipos de trafico 100 entre una pluralidad de nodos origen y una pluralidad de nodos destino y sincronizar sus transmisiones. En consecuencia, el conmutador puede recibir y multiplexar los diferentes tipos de trafico 100 a partir de los nodos origen. El trafico recibido puede comprender el trafico TDM 102 y/o el trafico de Ethernet 104, que pueden multiplexarse en un trafico TDM 110, trafico de flujo de alto rendimiento (HPF) 112, trafico de paquetes de mejor esfuerzo (BEP) 114 o sus combinaciones. El trafico TDM 110, el trafico HPF 112 y/o el trafico BEP 114 pueden transportarse luego a un segundo conmutador en, p.ej., mediante un enlace/flujo, utilizando un esquema TDM en su formato original (o modo) sin necesidad de empaquetado o encapsulacion adicional. El segundo conmutador puede demultiplexar luego el trafico, p.ej., utilizando el protocolo USTM, en el trafico TDM originalmente enviado 102 y/o el trafico de Ethernet 104 y enviar el trafico TDM 102 y/o el trafico Ethernet 104 a sus nodos de destino correspondientes.
El trafico TDM 110 y el trafico HPF 112 pueden corresponder al trafico orientado a la conexion 106 y pueden tener mas alta prioridad que el trafico BEP 114, que puede corresponder al trafico sin conexiones 108. Sobre la base del esquema UST, el trafico orientado a la conexion 106 y el trafico sin conexiones 108 pueden multiplexarse y transportarse en un enlace/flujo unico desde un nodo origen a un nodo destino. En consecuencia, el esquema UST puede proporcionar una Calidad de Servicio (QoS) para servicios basados en la orientacion a la conexion y alta prioridad, compatibilidad de redes de legado (p.ej., para SONET/SDH y sistemas de Ethernet) y funciones de distribucion y sincronizacion de reloj de redes de alta calidad.
La Figura 2A ilustra una forma de realizacion de una arquitectura de multiplexacion/demultiplexacion de UST 200, p.ej., que puede utilizarse para transportar y/o conmutar los diferentes tipos de trafico 100. La arquitectura de multiplexacion/demultiplexacion de UST 200 puede basarse en el protocolo USTM y ponerse en practica en un conmutador, p.ej., entre un nodo origen (o de entrada) y un nodo destino (o de salida). La arquitectura de multiplexacion/demultiplexacion de UST 200 puede utilizarse para transportar trafico para una pluralidad de redes/tecnologfas, tales como Ethernet, SONET/SDH, red de transporte optico (OTN) u otras redes. La tecnologfa de multiplexacion/demultiplexacion de UST 200 puede proporcionar funciones de transporte, conmutacion y sincronizacion de reloj en una manera sin discontinuidades para las diferentes redes/tecnologfas. La arquitectura de multiplexacion/demultiplexacion de UST 200 puede proporcionar tambien funciones de frecuencia, fase absoluta y transporte temporal absoluto y sincronizacion para las diferentes redes/tecnologfas.
Inicialmente, el conmutador puede recibir trafico TDM 202 y/o trafico Ethernet 204 desde el nodo origen. El trafico Ethernet 204 puede demultiplexarse (p.ej., utilizando un demultiplexor (Demux)/agente de enrutamiento (RA)) en trafico de paquetes de alta prioridad (HPP) 205 y trafico de paquetes de baja prioridad (LPP) 206. El trafico HPP 205 puede comprender trafico orientado a la conexion y puede convertirse a trafico HPF 207 (p.ej., utilizando un adaptador HPF). El trafico LPP 206 puede comprender trafico sin conexiones y de modo opcional, un trafico orientado a la conexion y puede convertirse a un trafico de flujo de paquetes combinados (CPF) 208 (p.ej., utilizando un adaptador CPF). El trafico CPF 208 puede demultiplexarse (p.ej., utilizando un demultiplexor Demux) para obtener una primera parte que puede comprender cualquier trafico orientado a la conexion que tenga una prioridad relativamente alta y una segunda parte que puede comprender trafico sin conexiones que tenga una prioridad relativamente baja. La primera parte del trafico CPF 208 puede multiplexarse con el trafico HPF 207 y la segunda
5
10
15
20
25
30
35
40
45
50
55
60
65
parte del trafico CPF corresponde al trafico BEP. Posteriormente, el trafico HPF 207 (incluyendo la primera parte del trafico CPF 208, si lo hubiere) y el trafico TDM 202 pueden multiplexarse (p.ej., utilizando un multiplexor (Mux)) en un trafico USTM 210, y por lo tanto, transportarse mediante un enlace/flujo unico. El trafico BEP puede multiplexarse tambien con el trafico TdM 202 y el trafico HPF 207 en el trafico UsTm 210 sobre la base del ancho de banda disponible.
En el otro extremo del conmutador, el trafico USTM 210 puede procesarse en una manera inversa para obtener el trafico TDM original 202 y el trafico Ethernet 204. El trafico USTM 210 puede demultiplexarse primero (p.ej., utilizando un Demux) retornando al trafico TDM 202, el trafico HPF 207 y el trafico BEP. El trafico cPf original 208 puede obtenerse mediante la multiplexacion (p.ej., utilizando un Mux) de la primera parte del trafico CPF 208 en el trafico HPF 207 (si lo hubiere) y en la segunda parte del trafico CPF 208 en el trafico BEP. El trafico HPF 207 y el trafico CPF 208 pueden convertirse luego de nuevo en el trafico HPP 205 y el trafico LPP 206, respectivamente, que pueden multiplexarse luego para obtener el trafico Ethernet original 204 (p.ej., utilizando un Mux/RA)).
La Figura 2B ilustra el trafico TDM 202 y el trafico HPF 207 (incluyendo la primera parte del trafico CPF) que pueden transportarse mediante el mapeado de correspondencia de este trafico con una pluralidad de intervalos temporales proporcionados, p.ej., dentro de una ventana temporal periodica que puede ser igual a aproximadamente 125 microsegundos (js). El trafico TDM 202 y el trafico HPF 207 pueden tener una prioridad relativamente alta y/o un ancho de banda de transmision garantizado asignado. En consecuencia, la ventana temporal periodica puede comprender una pluralidad de intervalos temporales reservados separados que pueden asignarse al trafico TDM 202 y el trafico HPF 207. En condiciones normales, el trafico TDM 202 puede ser objeto de mapeado de correspondencia en formato original en los intervalos temporales correspondientes, p.ej., sin utilizar senalizacion UST adicional. Ademas, el trafico TDM 202 no puede soportar la reutilizacion o asignacion de ancho de banda dinamico como el trafico HPF 207. A modo de ejemplo, el trafico TDM 202 no puede redistribuirse en intervalos temporales diferentes o adicionales en la ventana temporal periodica que sean diferentes de los intervalos temporales asignados originalmente del trafico TDM 202. Sin embargo, en algunas formas de realizacion, el trafico TDM 202 puede ser de tasa de transmision adaptada y/o en correspondencia con el trafico HPF 207. En consecuencia, el trafico TDM 202 y el trafico HPF 207 pueden ser objeto de mapeado de correspondencia en la misma magnitud de intervalos temporales y/o los mismos intervalos temporales en la ventana periodica. En este caso, el trafico TDM 202 puede soportar una reutilizacion de ancho de banda dinamico. En una forma de realizacion, el trafico HPF 207 y de modo similar, el trafico TDM 202 pueden soportar una adaptacion de tasa dinamica utilizando un sfmbolo de control para suspender/reducir algunos de los intervalos temporales correspondientes.
De modo adicional, el trafico BEP de mas baja prioridad puede ser objeto de mapeado de correspondencia en cualesquiera intervalos temporales remanentes, que pueden corresponder al ancho de banda de transmision remanente o disponible despues de la asignacion del trafico TDM 202 y del trafico HPF 207. Los intervalos temporales remanentes pueden comprender intervalos temporales no asignados (indicados por cajas vadas) en donde el trafico TDM 202 y el trafico HPF 207 no tienen un ancho de banda transmitido y/o asignado. Los intervalos temporales remanentes pueden comprender tambien intervalos temporales de trafico HPF inactivo (indicados por cajas rayadas), en donde la transmision del trafico HPF esta inactiva. A modo de ejemplo, el trafico BEP puede ser objeto de mapeado de correspondencia en los intervalos temporales remanentes en la ventana periodica en una manera dinamica sobre la base de byte por byte. La transmision de trafico BEP puede interrumpirse para transportar otros paquetes de mas alta prioridad, p.ej., el trafico HPF 207 y/o el trafico tDm 202, reasignando algunos de los intervalos temporales del trafico BEP al trafico de mas alta prioridad. Ademas, el trafico BEP puede soportar una adaptacion de tasa dinamica utilizando un sfmbolo de control para suspender/reducir algunos de los intervalos temporales correspondientes.
En algunas formas de realizacion, el trafico TDM 202, el trafico HPF 207 y el trafico BEP que se asignan a los intervalos temporales en la ventana periodica pueden transportarse en cualquier combinacion y por intermedio de cualquier cantidad de enlaces/flujos entre el nodo de entrada y el nodo de salida, p.ej., en la matriz de conmutacion. A modo de ejemplo, los tres tipos de trafico pueden transportarse por intermedio de tres buses de conexion separados dentro de sus intervalos temporales asignados en la ventana periodica. Como alternativa, el trafico TDM 202 y el trafico HPF 207 pueden transportarse por intermedio de un primer bus de conexion y el trafico BEP puede transportarse por intermedio de un segundo bus de conexion dentro de sus intervalos temporales asignados.
En una forma de realizacion, el trafico USTM 210 puede comprender tambien una codificacion transicional UST para indicar diferentes transiciones entre diferentes traficos dentro del trafico USTM 210. La codificacion transicional UST puede proporcionar una senalizacion UST que puede indicar el inicio y/o el final de diferentes flujos de trafico, p.ej., trafico TDM, trafico HPF y/o trafico BEP, en el trafico USTM 210. La codificacion transicional UST puede mejorar las funciones de transporte, conmutacion y/o sincronizacion de los diferentes tipos de trafico en el flujo de transporte. Mas concretamente, la codificacion transicional UST puede utilizarse para indicar las transiciones entre los diferentes tipos de trafico en el flujo de transporte sin necesidad de utilizar un ancho de banda importante del flujo de transporte, p.ej., sin utilizar una cantidad importante de intervalos temporales en la ventana temporal periodica. En consecuencia, una pluralidad de esquemas de codificacion transicionales UST pueden utilizarse para proporcionar una senalizacion UST mejorada en el trafico USTM y mejorar la utilizacion del enlace o su capacidad.
5
10
15
20
25
30
35
40
45
50
55
60
65
A diferencia del caso del trafico de conmutacion de circuitos o del trafico orientado a la conexion, que pueden transportarse utilizando metodos de ancho de banda fijado, el transporte del trafico de conmutacion de paquetes o sin conexiones puede requerir alguna informacion de control, tal como el conocimiento sobre la actividad de trafico y/o sus lfmites, a modo de ejemplo, para beneficiarse de la utilizacion compartida del ancho de banda cuando se transporta trafico TDM. La senalizacion UST puede incorporarse en el trafico UST para proporcionar dicha informacion de control para trafico HPF y BEP multiplexados en el flujo de transporte. La senalizacion UST puede proporcionar una funcionalidad similar a la que se proporciona por la capa ffsica de Ethernet, p.ej., para indicar o identificar los lfmites de paquetes. Mas concretamente, una codificacion transicional UST puede proporcionarse en el flujo de transporte para indicar o senalar las transiciones entre diferentes tipos de trafico y/o flujos en la corriente y de este modo, efectuar un seguimiento del estado activo o inactivo de cada flujo en la corriente. A modo de ejemplo, un flujo logico en el trafico transportado puede corresponder a una conexion virtual HPF logica o una instancia continua de trafico BEP. La indicacion de las transiciones entre los tipos de trafico y/o flujos, en lugar de senalizar informacion mas detallada sobre diferentes actividades de trafico puede reducir la magnitud de la informacion de control que puede intercambiarse y de este modo, reducir la sobrecarga en el enlace.
Ademas, el trafico de conmutacion de circuitos u orientado a la conexion, tal como el trafico TDM, puede ser adaptado en su frecuencia o tasa de transmision antes de transportar el trafico utilizando UST, p.ej., cuando la frecuencia original de trafico TDM recibido en la red TDM es diferente de la frecuencia de transmision en la red de transporte UST. La adaptacion de la frecuencia o tasa de transmision puede conseguirse mediante una sobrealimentacion del canal TDM (p.ej., en la red de transporte UST) que puede asignarse para transportar el trafico de conmutacion de circuitos y utilizando el ancho de banda excedente para insertar informacion de control TDM y/o atenuacion, p.ej., informacion de operacion, administracion y gestion (OAM). A modo de ejemplo, el trafico tDm recibido puede ser intervalos temporales asignados en la ventana temporal periodica para anadir una codificacion transicional UST y de este modo, senalizar dicha informacion de control.
La Figura 3 ilustra una forma de realizacion de un aparato de conmutacion UST 300, que puede proporcionar las funciones de transporte, conmutacion y sincronizacion para diferentes tipos de trafico, p.ej., trafico tDm, HPF y/o BEP. El aparato de conmutacion UST puede comprender una matriz de conmutacion 3l0 acoplada a una pluralidad de primeros enlaces de Ethernet 320 por intermedio de una interfaz tributaria 330 y a una pluralidad de segundos enlaces de Ethernet 340 por intermedio de una interfaz de lmea 350. Los primeros enlaces de Ethernet 320 pueden acoplarse a una pluralidad de primeros nodos (no ilustrados) y los segundos enlaces de Ethernet 340 pueden acoplarse a una pluralidad de segundos nodos (no ilustrados). Los primeros nodos y los segundos nodos pueden situarse en la misma red, p.ej., red de Ethernet o redes diferentes. Utilizando el aparato de conmutacion UST 300, el trafico puede transportarse desde cualquiera de los primeros nodos a cualquiera de los segundos nodos pasando a traves de los primeros enlaces de Ethernet 320, la interfaz tributaria 330, la matriz de conmutacion 310, la interfaz de lmea 350 y posteriormente, los segundos enlaces de Ethernet 340. De forma adicional o alternativa, el trafico puede transportarse desde los segundos nodos a los primeros nodos pasando por los segundos enlaces de Ethernet 340, la interfaz de lmea 350, la matriz de conmutacion 310, la interfaz tributaria 330 y posteriormente, los primeros enlaces de Ethernet 320.
La interfaz tributaria 330 puede configurarse para recibir y/o reenviar diferentes tipos de trafico a traves de los primeros enlaces 320, p.ej., en la forma o formato original del trafico. Ademas, la interfaz tributaria 330 puede recibir y/o enviar trafico USTM y/o trafico BEP desde/a la matriz de conmutacion 310, p.ej., por intermedio de una Interfaz de Unidad de Conexion (XAUI) 10 G, una Unidad de Interfaz de Conexion (XLAUI) de 40G u otra interfaz, tal como una interfaz de BEP solamente. En una forma de realizacion, el trafico USTM transportado por intermedio de una interfaz XLAUI puede ser objeto de mapeado de correspondencia utilizando un esquema de codificacion T6xb que puede basarse en un formato de codificacion 64b/66b, segun se describe a continuacion. Como alternativa, el trafico USTM transportado por intermedio de una interfaz XAUI puede ser objeto de mapeado de correspondencia utilizando un esquema de codificacion T10b, que puede basarse en un formato de codificacion 8b/10b, segun se ilustra a continuacion. La interfaz tributaria 330 puede comprender tambien un mapeado de flujo 332, una Tabla de estado de flujo 334 y una Tabla de estados de intervalo temporal (TS) 330, que pueden utilizarse para el seguimiento del estado de los flujos e intervalos temporales, segun se describe en detalle a continuacion.
La matriz de conmutacion 310 puede configurarse para recibir y conmutar diferentes tipos de trafico desde cualquiera de los primeros enlaces 320 y/o los segundos enlaces 340 y reenviar el trafico sobre cualquiera de los segundos enlaces 340 y/o los primeros enlaces 320. El trafico puede recibirse y reenviarse por intermedio de la interfaz tributaria 330 y/o la interfaz de lmea 350. Los primeros enlaces 320 y los segundos enlaces 340 pueden corresponder a un sistema Ethernet de 100 Gigabit (G), Ethernet 40G y/o Ethernet 10G y el trafico de Ethernet en cualquiera de los enlaces puede codificarse sobre la base de diferentes esquemas o formatos (p.ej., 64b/66b, 8b/10b, 4b/5b, T6xb y/o T10b). En otras formas de realizacion, pueden utilizarse otras disposiciones para la matriz de conmutacion 310, la interfaz tributaria 330, la interfaz de lmea 350 y/o sus sub-componentes.
La matriz de conmutacion 310 puede comprender un demultiplexor Demux USTM 316, un conmutador de flujo 312 que comprende un mapa de conexiones 315 y un conmutador de paquetes 314. El Demux USTM 316 puede configurarse para recibir el trafico USTM desde la interfaz tributaria 330 y/o la interfaz de lmea 350, demultiplexar el trafico en trafico TDM, trafico HPF y/o trafico BEP y renviar el trafico al conmutador de flujos 312 y/o el conmutador
5
10
15
20
25
30
35
40
45
50
de paquetes 314. El conmutador de flujos 312 puede configurarse para recibir y conmutar trafico USTM que puede incluir trafico TDM y/o trafico HPF entre los primeros enlaces 320 y los segundos enlaces 340. El mapa de conexiones 315 puede utilizarse para soportar una conmutacion basada en el tiempo p.ej., para trafico tDm. El conmutador de paquetes 314 puede configurarse para recibir y conmutar trafico BEP entre los primeros enlaces 320 y los segundos enlaces 340. El demultiplexor Demux USTM 316 puede recibir luego, los conmutados trafico TDM, trafico HPF y/o trafico BEP desde el conmutador de flujos 312 y/o el conmutador de paquetes 314, multiplexar el trafico en trafico USTM y reenviar el trafico USTM a la interfaz tributaria 330 y/o la interfaz de lmea 350.
De modo similar a la interfaz tributaria 330, la interfaz de lmea 350 puede configurarse para recibir y/o reenviar diferentes tipos de trafico por intermedio de los segundos enlaces 340 y puede recibir y/o enviar trafico USTM y/o trafico BEP desde/a la matriz de conmutacion 310. Mas concretamente, la interfaz 340 puede transportar trafico USTM por intermedio de los diversos esquemas de codificacion ilustrados en la Figura 3. La interfaz de lmea 350 puede comprender un mapa de flujos 352, una Tabla de estados de flujos 354 y una Tabla de estados de intervalos temporales (TS) 356, que puede utilizarse para el seguimiento del estado de los flujos y de los intervalos temporales.
En una forma de realizacion, la codificacion transicional de UST puede proporcionarse utilizando una pluralidad de sfmbolos de control en el flujo USTM, a modo de ejemplo, para el soporte de OAM y/o atenuacion. Los sfmbolos de control pueden comprender una pluralidad de codigos de operacion unicos para diferentes funciones de control, que pueden utilizarse en los intervalos temporales en la ventana temporal. Un codigo de operacion multiparte puede utilizarse tambien para proporcionar una senalizacion UST adicional o continuada en un intervalo temporal, p.ej., para proporcionar funciones de control adicionales o mas avanzadas. A modo de ejemplo, una pluralidad de codigos de operacion multiparte pueden utilizarse en una ventana temporal o en un intervalo temporal para proporcionar senalizacion UST adicional. El codigo de operacion y el codigo de operacion multiparte pueden codificarse utilizando un formato de codificacion 64b/66b.
La Tabla 1 ilustra una senalizacion transicional UST para diferentes tipos de transicion en el trafico USTM. La senalizacion transicional UST puede corresponder a un esquema de codificacion T6xb, que se describe en detalle a continuacion. Segun se ilustra, un conjunto de senales de transicion UST pueden utilizarse para cada uno de los traficos HPF, BEP y TDM, a modo de ejemplo, segun intervalo temporal, por flujo o por trama UST. La senalizacion de transicion UST puede proporcionarse utilizando un codigo de operacion unico para cada tipo de transicion, que puede comprender la zona no valida/rellenada, inicio de trama UST, HPF activo, HPF inactivo, BEP activo, BEP inactivo, control de continuidad (CC), e inicio de codigo de operacion multiparte. El codigo de operacion no valido/relleno o la senal pueden utilizarse en cualquiera de entre los traficos HPF, BEP y TDM sobre una base de intervalo temporal. El codigo de operacion CC puede utilizarse en cualquiera de los traficos HPF, BEP y TDM sobre una base de flujo. El inicio del codigo de operacion de trama UST puede utilizarse por cada trama UST. A modo de ejemplo, una pluralidad de inicio consecutivo de sfmbolos de control de trama UST puede utilizarse para conseguir una propagacion de errores a nivel de enlace. Los codigos de operacion activo e inactivo de HPF pueden utilizarse en el trafico HPF sobre una base de flujo. Los codigos de operacion activo e inactivo de BEP pueden utilizarse en cualquiera de los traficos BEP y HPF sobre una base de flujo. El inicio del codigo de operacion multiparte puede utilizarse en cualquiera de los traficos HPF, BEP y TDM sobre una base de intervalo temporal, en donde los codigos de operacion multiples pueden utilizarse para indicar la continuacion de la informacion de senalizacion.
Tabla 1: Senalizacion transicional UST.
Descripcion
HPF BEP TDM Asociacion
No valido/relleno
V V V Intervalo temporal
Inicio de trama UST
Trama UST
HPF ^ activo
V Flujo
HPF ^ inactivo
V Flujo
BEP ^ activo
V V Flujo
BEP ^ inactivo
V V Flujo
Comprobacion de continuidad (CC)
V V V Flujo
Inicio de codigo de operacion multiparte
V V V Intervalo temporal
La Figura 4 ilustra una forma de realizacion de una SU de codigo de operacion multiparte 400, que puede utilizarse para proporcionar una informacion de senalizacion continuada o adicional en el trafico USTM. La SU de codigo de operacion multiparte 400 puede comprender un octeto transmitido dentro de un intervalo temporal. El octeto puede comprender un campo de senalizacion 410, un campo de continuacion 420 y un campo de paridad 430. El campo de senalizacion 410 puede comprender un codigo de operacion o un codigo de operacion multiparte y puede comprender aproximadamente seis bits (p.ej., bits cero a bit cinco) que puede especificar la informacion de senalizacion. El campo de continuacion 420 puede comprender aproximadamente un bit (p.ej., bit 6) y puede
5
10
15
20
25
30
35
40
45
50
55
60
65
utilizarse para indicar si la SU de codigo de operacion multiparte 400 comprende el ultimo codigo de operacion multiparte de la informacion de senalizacion continuada o esta seguido por un octeto posterior que comprende mas informacion de senalizacion. A modo de ejemplo, el bit 6 puede establecerse a aproximadamente cero para indicar que la SU de codigo de operacion multiparte 400 comprende el ultimo codigo de operacion multiparte de la informacion de senalizacion o aproximadamente uno para indicar que la informacion de senalizacion es continuada en otro codigo de operacion multiparte en un octeto posterior, p.ej., en el mismo intervalo temporal o posterior. El campo de paridad 430 puede comprender aproximadamente un bit (p.ej., bit 7) y puede utilizarse para detectar errores en los datos transmitidos.
La informacion de senalizacion en la SU de codigo de operacion multiparte 400 puede utilizarse para indicar el establecimiento del flujo de trafico, desgaste del flujo, ancho de banda de flujo aumentado, ancho de banda de flujo disminuido y/o otra informacion relacionada con el trafico. En consecuencia, una pluralidad de codigos de operacion multiparte puede senalizar una operacion adicional sobre una base de por intervalo temporal, p.ej., en las ventanas temporales periodicas (p.ej., ventanas temporales de 125 ps aproximadamente) posteriores al codigo de operacion inicial. La informacion en los codigos de operacion multiparte puede comprender un numero de flujo que indica el mismo flujo para todos los codigos de operacion multiparte en los intervalos temporales. La informacion en la SU de codigo de operacion multiparte 400 puede comprender informacion sobre el nodo de destino o de salida para el trafico transportado, que puede utilizarse luego para determinar el salto operativo siguiente. En una forma de realizacion, los codigos de operacion multiparte en una pluralidad de bloques de senalizacion de codigo de operacion multiparte pueden utilizarse para proporcionar operaciones OAM orientadas al flujo logico, que pueden ser objeto de mapeado de correspondencia en paquetes BEP y/o HPF etiquetados en el flujo transportado.
Las Figuras 5A y 5B ilustran una forma de realizacion de un bloque de codificacion 500, que pude corresponder a un esquema de codificacion T6xb. El esquema de codificacion T6xb puede utilizarse para multiplexar trafico TDM, trafico HPF, trafico BEP y sus combinaciones utilizando el formato de codificacion 64b/66b, p.ej., realizando un mapeado de correspondencia de cada aproximadamente 66 bits en el flujo en aproximadamente 64 bits. El formato de codificacion 64b/66b puede utilizarse para redes Ethernet, tales como para sistemas Ethernet de aproximadamente 10G, Ethernet 40G o Ethernet 100G. Como alternativa, el esquema de codificacion T6xb puede utilizarse para transiciones de senales en el trafico USTM, p.ej., para mantener un estado por flujo para el trafico HPF y/o el trafico BEP y de este modo, efectuar un seguimiento de los estados inactivo e inactivo de cada flujo.
Segun se ilustra en la Figura 5A, el esquema de codificacion 500 puede comprender hasta aproximadamente ocho octetos, p.ej., en el trafico USTM, que corresponden a un bloque 64b/66b. Los octetos pueden comprender trafico TDM, HPF y/o BEP sin informacion o senal transicional. En consecuencia, el bloque de codificacion 500 puede ir precedido por un valor de sincronizacion (p.ej., en el flujo de transporte), que indica la ausencia de informacion de transicion en el bloque de codificacion 500. A modo de ejemplo, el valor de sincronizacion puede establecerse a aproximadamente uno o "01" para indicar que ninguna senalizacion de transicion se proporciona en un bloque de codificacion 500 posterior. Como alternativa, al menos un octeto (p.ej., octeto 1) en bloque de codificacion 500 puede comprender una senalizacion transicional, segun se ilustra en la Figura 5B. En consecuencia, el bloque de codificacion 500 puede ir precedido por un valor de sincronizacion (p.ej., de aproximadamente 10) que indica la presencia de informacion de transicion en el bloque de codificacion 500. En consecuencia, al menos una parte de la informacion de transicion puede estar situada en la parte frontal del bloque de codificacion 500 p.ej., en el primer octeto del bloque de codificacion 500, segun se describe a continuacion.
En el caso de una senalizacion transicional, el bloque de codificacion 500 puede comprender al menos un primer octeto (p.ej., desde el bit cero al bit siete) que comprenden un campo de codigo de operacion 510, un campo de localizacion 512, un campo de continuacion 520 y un campo de paridad 530. El campo de codigo de operacion 510 puede comprender aproximadamente tres bits (p.ej., bit cero a bit dos) y puede indicar una senal transicional, p.ej., segun se ilustra en la Tabla 1 o la Tabla 2 siguiente. El campo de localizacion 512 puede comprender aproximadamente tres bits (p.ej., desde el bit tres al bit cinco) y puede indicar la localizacion de la transicion en el trafico. A modo de ejemplo, los tres bits pueden indicar la localizacion en el bloque 64b/66b en bytes en donde se produce la transicion del trafico. Los tres bits pueden indicar un valor entero desde aproximadamente cero bytes a aproximadamente siete bytes.
El campo de continuacion 520 puede comprender aproximadamente un bit (p.ej., bit 6) que puede utilizarse para indicar si el octeto de senalizacion transicional es el ultimo en el bloque de codificacion 500. A modo de ejemplo, el bit 6 puede establecerse a aproximadamente cero para indicar que el siguiente octeto en el bloque 64b/66b comprende trafico de TDM, HPF y/o BEP sin transiciones o a aproximadamente uno para indicar que el siguiente octeto comprende informacion de senalizacion adicional. A modo de ejemplo, el siguiente octeto en el bloque de codificacion 500 puede corresponder a un bloque de senalizacion de codigo de operacion multiparte 500. El campo de paridad 530 puede comprender aproximadamente un bit (p.ej., bit 7) y puede utilizarse para detectar errores en los datos transmitidos.
La Tabla 2 indica otra senalizacion transicional de UST basada en el esquema de codificacion T6xb. La senalizacion de transicion de UST puede proporcionarse utilizando los campos de codigo de operacion 510 en el bloque de codificacion 500. Los campos de codigo de operacion 510 pueden utilizarse para indicar un conjunto de senales de
5
10
15
20
25
30
35
40
45
50
transicion UST, que pueden comprender un estado inactivo, el inicio de una trama UST, el inicio de un paquete de HPF, el final de paquete de HPF, el inicio del paquete BEP, el final del paquete BEP, CC y el inicio del codigo de operacion multiparte. El estado inactivo puede indicarse por un valor de codigo de operacion de aproximadamente cero y puede utilizarse en cualquiera de los traficos HPF, BEP y TDM sobre una base de intervalo temporal. El inicio de la trama UST puede indicarse por un valor de codigo de operacion de aproximadamente uno y puede utilizarse para cada trama UST. El inicio de trama y el final de trama de HPF pueden indicarse por valores de codigo de operacion de aproximadamente dos y aproximadamente tres, respectivamente, y pueden utilizarse en el trafico HPF sobre una base de flujo. El inicio y el final de la trama de BEP pueden indicarse por valores de codigo de operacion de aproximadamente cuatro y aproximadamente cinco, respectivamente, y pueden utilizarse en cualquiera del trafico BEP y HPF sobre una base de flujo. El CC puede indicarse por un valor de codigo de operacion de aproximadamente seis y puede utilizarse en cualquiera del trafico HPF, BEP y TDM sobre una base de flujo. El inicio de multiparte puede indicarse por un valor de codigo de operacion de aproximadamente siete y puede utilizarse en cualquiera del trafico HPF, BEP y TDM sobre una base de intervalo temporal.
Codigo de operacion
Descripcion HPF BEP TDM Asociacion
0
Inactivo V V V Intervalo temporal
1
Inicio de trama UST Trama UST
2
Inicio de paquete HPF V Flujo
3
Final de paquete HPF V Flujo
4
Inicio de paquete BEP V V Flujo
5
Final de paquete BEP V V Flujo
6
Comprobacion de Continuidad (CC) V V V Flujo
7
Inicio de codigo de operacion multiparte V V V Intervalo temporal
Tabla 2: Senalizacion transicional de UST utilizando la codificacion T6xb
Cuando una transicion se senaliza en el bloque de codificacion 500, al menos un octeto en el bloque 64b/66b puede comprender la informacion de senalizacion en lugar del trafico real transmitido. En este caso, el trafico real puede desplazarse en una cantidad de bytes que corresponde a la cantidad de octetos utilizados para la senalizacion. De este modo, los octetos que siguen a los octetos de senalizacion en el bloque 64b/66b y que comprenden el trafico TDM, HPF y/o BEP, pueden desplazarse en al menos aproximadamente un byte y al menos aproximadamente siete bytes. Cuando se recibe el bloque 64b/66b, la posicion original y los valores del trafico, que pueden desplazarse debido a la adicion de la informacion de transicion, pueden extrapolarse a partir de los campos de senalizacion transicionales u octetos. A modo de ejemplo, cuando un trafico TDM en un bloque 64b/66b es demultiplexado, los octetos correspondientes pueden restablecerse a su respectivas posiciones (p.ej., con respecto a una ventana temporal de transmision) antes de un procesamiento adicional. Utilizando el bloque de codificacion 500, el trafico originalmente transmitido puede desplazarse, como maximo, en aproximadamente siete octetos y dentro de un bloque 64b/66b unico. En consecuencia, una cantidad relativamente pequena de memorizacion intermedia puede requerirse para realinear un flujo en el nodo de destino. A modo de ejemplo, un tamano de memoria intermedia de aproximadamente 8 octetos puede ser suficiente, que puede no anadir una importante latencia o retardo en el flujo de datos.
La Figura 6 ilustra una forma de realizacion de una SU de codificacion 600, que puede utilizarse para transportar trafico USTM o proporcionar una senalizacion transicional. La SU de codificacion 600 puede corresponder a un formato de codificacion T9b, que puede comprender aproximadamente ocho bits seguidos por un bit de senalizacion adicional y puede utilizarse en rutas de datos de anchura aproximada de nueve bits. A modo de ejemplo, el formato de codificacion T9b puede utilizarse en un conjunto matricial de puertas programables en campo (FPGA) o componentes de conmutacion de circuitos integrados espedficos de la aplicacion (ASIC). El formato de codificacion T9b puede utilizarse en lugar del formato de codificacion 64b/66b para proporcionar mas informacion de senalizacion, p.ej., por bloque, y de este modo, reducir la cantidad de informacion de consulta o estructuras de control (p.ej., tablas de consulta) y/o recursos que pueden necesitarse para procesar la informacion de senalizacion en el trafico USTM. En una forma de realizacion, la SU de codificacion 600 puede tener un ancho de banda de aproximadamente 64 Kilobytes por segundo (Kb/s), p.ej., sobre la base de una ventana temporal de aproximadamente 125 ps.
De modo similar a los octetos en el bloque de codificacion 500, la SU de codificacion 600 puede comprender trafico USTM o como alternativa, informacion de transicion. Mas concretamente, la SU de codificacion 600 puede comprender aproximadamente nueve bits, en donde una primera parte 602 puede comprender aproximadamente ocho bits (p.ej., B0 a B8) y una segunda parte 604 puede comprender el bit de senalizacion restante (p.ej., Bs). La primera parte 602 puede comprender trafico TDM, HPF o BEP. Como alternativa, la primera parte 602 puede
5
10
15
20
25
30
35
40
45
50
comprender una senalizacion similar y otra informacion como el campo de codigo de operacion 510, el campo de localizacion 512 y el campo de continuacion 520 en el bloque de codificacion 500. La segunda parte 604 puede comprender aproximadamente un bit de paridad (p.ej., bit 7) y puede utilizarse para detectar errores en los datos transmitidos. El bit de paridad puede utilizarse para realizar un control de paridad para los bits restantes en la primera parte 602. Ademas, el bit de paridad puede utilizarse comprobar si la SU de codificacion 600 comprende datos de trafico o informacion de senalizacion (o control). A modo de ejemplo, si la cantidad de un bit en la SU de codificacion 600 que incluye el bit de paridad Bs es impar, en tal caso, la SU de codificacion 600 puede ser una SU de datos. De no ser asf, la SU de codificacion 600 puede ser una SU de control.
En el caso de una SU de control, la primera parte 602 puede comprender cualquiera de entre una pluralidad de codigos de operacion que indican las senales transicionales en la Tabla 1 o la Tabla 2. La primera parte 602 puede indicar tambien otra informacion transicional utilizando otros codigos de operacion. Puesto que un numero relativamente pequeno de codigos de operacion, p.ej., aproximadamente ocho, puede utilizarse en la primera parte 602, el formato de codificacion T9b puede proporcionar codigos adicionales que pueden utilizarse en la SU de codificacion 600, a modo de ejemplo, para proporcionar una deteccion de errores eficiente. La codificacion binaria en los codigos de operacion o codigos que puedan utilizarse en la primera parte 602 puede seleccionarse o determinarse de modo que proporcione una distancia suficiente entre las secuencias de bits o codigos. De este modo, se pueden mejorar las capacidades de deteccion utilizando el bit de paridad.
La Figura 7 ilustra una forma de realizacion de una SU de codificacion 700, que puede corresponder a un esquema de codificacion T10b. El esquema de codificacion T10b puede utilizarse para multiplexar detector fotosensible TDM, trafico HPF, trafico BEP o sus combinaciones utilizando el formato de codificacion 8b/10b, p.ej., estableciendo un mapeado de correspondencia cada aproximadamente 10 bits en el flujo en aproximadamente ocho bits. El formato de codificacion 8b/10b puede utilizarse en un sistema de Ethernet de Gigabits o una XAUI de 10 Gigabits, que se puede utilizar para transportar datos de Ethernet dentro de un plano central. Como alternativa, el esquema de codificacion T10b puede utilizarse para transiciones de senales en el trafico USTM. El formato de codificacion T10b puede utilizarse en lugar del formato de codificacion 64b/66b y el formato de codificacion T9b para proporcionar mas informacion de senalizacion, p.ej., por bloque y de este modo, reducir la cantidad de estructuras de control y/o recursos en el conmutador.
De modo similar a los octetos en el bloque de codificacion 500, la SU de codificacion 700 puede comprender codigos de operacion de control (p.ej., transicional o de senalizacion) o datos de trafico. Mas concretamente, la SU de codificacion 700 puede comprender aproximadamente 10 bits, que pueden utilizarse para indicar los datos de trafico o los codigos de operacion de control, tales como las senales transicionales en la Tabla 1, Tabla 2 o la Tabla 3 siguiente. En una forma de realizacion, los datos de trafico en la SU de codificacion 700 pueden codificarse utilizando al menos algunos de los sfmbolos de datos estandar 8b/10b y los codigos de operacion de control pueden codificarse utilizando un conjunto especificado de sfmbolos de control 8b/10b.
La Figura 8 y la Tabla 3 ilustran un ejemplo del conjunto de sfmbolos de control 8b/10b 800 que se pueden utilizar como codigos de operacion de control en la SU de codificacion 700. La Figura 8 ilustra un conjunto de codigos de operacion de control adecuados que pueden seleccionarse de entre una pluralidad de sfmbolos de control 8b/10b 800 para indicar diferentes tipos de transicion. Los codigos de operacion de control seleccionados pueden corresponder a aproximadamente ocho grupos de codigos (p.ej., K28.1, K28.2, K28.3, K28.4, K28.5, K28.6, K29.7 y K30.7) que pueden utilizarse segun se indica por los bloques sombreados. La Tabla 3 resume los tipos de transicion que pueden indicarse por los codigos de operacion de control seleccionados. La Figura 8 y la Tabla 3 ilustran un conjunto de codigos de operacion de control que pueden seleccionarse a partir de los sfmbolos de control 8b/10b 800 para indicar diferentes tipos de transicion, pero otros conjuntos que comprenden otros codigos de operacion de control a partir de los bolso de control 8b/10b 800 pueden utilizarse en otras formas de realizacion.
Codigo 8b/10b
Descripcion HPF BEP TDM Asociacion
K28.5
Inactivo V V V Intervalo temporal
K28.1
Inicio de trama UST Trama UST
K28.2
Inicio de paquete HPF V Flujo
K28.3
Final de paquete HPF V Flujo
K28.4
Inicio de paquete BEP V V Flujo
K29.7
Final de paquete BEP V V Flujo
K28.6
Comprobacion de Continuidad (CC) V V V Flujo
K30.7
Inicio codigo de operacion multiparte V V V Intervalo temporal
Tabla 3: Senalizacion transicional de UST utilizando la codificacion T10b
5
10
15
20
25
30
35
40
45
En una forma de realizacion, para procesar la informacion de senalizacion en el trafico USTM y gestionar los formatos de codificacion anteriores, el conmutador puede mantener una estructura de control, tal como un mapa de flujos y/o una Tabla de estados de intervalos temporales (TS), a modo de ejemplo en una componente de memoria o almacenamiento de base de datos. La estructura de control puede utilizarse para el seguimiento de los estados de los flujos de trafico o los intervalos temporales en el flujo de datos USTM, a modo de ejemplo, para permitir la reutilizacion de los intervalos temporales asignados HPF por el trafico BEP cuando el trafico HPF este en condicion inactiva. De forma adicional, la estructura de control puede soportar el establecimiento de flujos de datos, flujos de datos de desgaste, aumento de los anchos de banda de los flujos y/o disminucion de los anchos de banda. La estructura de control puede utilizarse tambien para recordar y solicitar un estado anterior de un flujo cuando se interrumpe por un sfmbolo de condicion inactiva (o codigo de operacion).
La Figura 9 ilustra una forma de realizacion de un mapa de flujo 900, que puede ser una estructura de control utilizada para gestionar el trafico USTM. El mapa de flujo 900 puede comprender una pluralidad de entradas que establecen un mapa de correspondencia de una pluralidad de intervalos temporales, p.ej., en una ventana temporal periodica. A modo de ejemplo, el mapa de flujos 900 puede comprender aproximadamente N entradas (N es un numero entero) que corresponden a aproximadamente N intervalos temporales en la ventana temporal periodica. Cada entrada en el mapa de flujo 900 puede comprender un campo de numero de flujo 902, que puede incluir un identificador de flujo (ID) que indica un flujo en el flujo de datos USTM y un campo de paridad 904, que puede utilizarse para comprobar la paridad. A modo de ejemplo, el campo de numero de flujo 902 puede comprender aproximadamente 17 bits (p.ej., desde el bit cero al bit 16) y el campo de paridad 904 puede comprender aproximadamente un bit (p.ej., bit siete). En consecuencia, el mapa de flujo 900 puede soportar aproximadamente 128,000 flujos en el flujo de datos, que puede ser suficiente para soportar aproximadamente sistemas de Ethernet de 100G. El campo de numero de flujo 902 puede aumentarse en longitud (p.ej., en cantidad de bits) para soportar un mayor numero de flujos si asf se desea. Los flujos pueden corresponder a flujos de trafico HPF o flujos de trafico BEP.
La Tabla 4 ilustra un esquema de numeracion de flujos que comprende un conjunto de numeros de flujos o identificadores IDs, que pueden utilizarse para indicar diferentes tipos de flujos de trafico en el flujo de datos (p.ej., asignacion). Los diferentes tipos de flujos de trafico pueden comprender un trafico no asignado (p.ej., trafico BEP), un trafico de no utilizar (DNU) y un trafico HPF/TDM. Algunos de los numeros de flujos pueden no utilizarse y/o pueden reservarse para uso futuro. El mapa de flujo 900 puede actualizarse a nivel local, p.ej., utilizando software o de forma dinamica, enviando una senalizacion OAM incorporada en los intervalos temporales. A modo de ejemplo, el mapa de flujo 900 puede actualizarse utilizando codigos de operaciones multiparte (p.ej., SU de codigo de operacion multiparte 400) para establecer un flujo, el desgaste de un flujo, aumento del ancho de banda de un flujo, disminucion del ancho de banda de un flujo o sus combinaciones.
Numero de flujo
Asignacion
0
No asignado (BEP)
1
DNU
2
Reservado
3
Reservado
4
Reservado
5
Reservado
6
Reservado
7
Reservado
8
HPF/TDM
N
Tabla 4: Numeracion de flujos
La Tabla 5 ilustra una forma de realizacion de una entrada en una Tabla de estados TS, que puede ser otra estructura de control utilizada para gestionar el trafico USTM. Mas concretamente, la Tabla de estados TS puede utilizarse para especificar el estado de cada intervalo temporal en el flujo de datos y puede comprender una entrada para cada intervalo temporal. La entrada puede comprender aproximadamente dos bits (p.ej., bit cero a bit uno), a los que a cada uno puede asignarse uno de los valores para indicar diferentes estados TS y diferentes tipos de trafico. A modo de ejemplo, el bit cero puede establecerse a aproximadamente cero para indicar un estado TS por defecto o a aproximadamente uno para indicar un estado pendiente de OAM. De forma adicional, el bit uno puede establecerse a aproximadamente cero para indicar trafico basado en paquetes o a aproximadamente uno para indicar trafico basado en TDM. En otra forma de realizacion, la Tabla 5 o la informacion en la Tabla 5 puede incluirse
5
10
15
20
25
30
35
40
en el mapa de flujos 900 y/o la Tabla 4.
Bit
Valor Estado TS
0
0
Por defecto
0
1 Pendiente OAM
1
0 Paquete
1
1
TDM
Tabla 5: Entrada de Tabla de estados TS
La Tabla 6 ilustra una forma de realizacion de la Tabla de estados de flujo, que puede utilizarse para mantener un registro del estado de cada flujo en el flujo de datos. La Tabla de estados de flujo puede comprender una entrada para cada flujo para indicar su estado correspondiente. A modo de ejemplo, cada entrada puede comprender un numero de flujo que identifica un flujo y un valor de estado de flujo. El valor de estado de flujo puede indicarse utilizando aproximadamente dos bits (p.ej., bit cero y bit uno). La Tabla 7 ilustra los valores de estado de flujo que pueden utilizarse para indicar diferentes estados para los flujos, p.ej., estado inactivo, paquete soporte activo, paquete OAM activo y reservado/repuesto.
En una forma de realizacion, el trafico USTM puede tener una granularidad igual a aproximadamente 64 kb/s, p.ej., en donde el mas pequeno tamano de bloque de datos puede ser igual a aproximadamente 64 kb/s. Sin embargo, en otras formas de realizacion, la granularidad del trafico USTM puede ser igual a un numero entero multiplo de aproximadamente 64 kb/s. Ademas, los intervalos temporales en el flujo de datos pueden tener una granularidad de una columna de SONET/SDH, p.ej., aproximadamente nueve bits por cada ventana temporal de 125 ps. En consecuencia, los mismos dos bits pueden utilizarse aproximadamente nueve veces dentro de la ventana temporal de 125 ps. Dicha configuracion de granularidad puede reducir el tamano logico y de este modo, reducir el coste de la realizacion de mapas de intervalos temporales y flujos y/o otras estructuras de control.
Numero de flujo
0 1
0
Estado de flujo
1
Estado de flujo
N
Estado de flujo
Tabla 6: Tabla de estados de flujo
Valor de estado de flujo
Definicion
0
Inactivo
1
Paquete soporte activo
2
Paquete OAM activo
3
Reservado / repuesto
Tabla 7: Estados de flujos
En una forma de realizacion, el sistema de conmutacion USTM (p.ej., el aparato de conmutacion UST 300) puede soportar una ventana temporal flotante (p.ej., de aproximadamente 125 ps) y la insercion de trafico inactivo o intervalos temporales para proporcionar una adaptacion de tasas para los diferentes tipos de trafico. A modo de ejemplo, la adaptacion de tasas puede ponerse en practica en las tarjetas de interfaz de lmea, p.ej., la interfaz tributaria 330, la interfaz de lmea 350 y/o otras interfaces de red. En consecuencia, la ventana temporal flotante puede soportar una adaptacion de frecuencia de nodo a nodo al nivel de enlace. Ademas, ciclos de estado inactivo (o intervalos temporales) pueden insertarse en cualquier momento o logar en el flujo de datos USTM para suspender el procesamiento del flujo de datos y/o proporcionar adaptacion de tasas al nivel de flujo logico. Los ciclos de estado inactivo pueden insertarse para el trafico TDM, HPF y/o BEP, p.ej., dentro o entre paquetes.
En otra forma de realizacion, el sistema de conmutacion UST puede soportar una ventana temporal periodica (p.ej., de aproximadamente 125 ps), mapa de flujos con soporte de hardware y actualizacion de estado TS y mecanismos de sincronizacion para proporcionar una gestion del ancho de banda dinamica sin saltos operativos. En consecuencia, la gestion del ancho de banda, el establecimiento de flujos y el desgaste de flujos puede realizarse utilizando codigos OAM, segun se describio con anterioridad. A modo de ejemplo, un nodo puede transmitir un
5
10
15
20
25
30
35
40
45
50
55
60
65
codigo de operacion multiparte al conmutador, p.ej., sobre una base por intervalo temporal, que puede indicar la operacion a realizarse y el numero de flujo asociado. Despues de transmitir el numero de flujo y otros parametros, el numero de flujo puede cargarse en la ventana temporal siguiente, p.ej., el siguiente lfmite de 125 js. Como alternativa, puede generarse una confirmacion y enviarse por el conmutador en respuesta a la recepcion del numero de flujo y otros parametros.
La Figura 10 ilustra una forma de realizacion de un metodo de senalizacion UST 1000, que puede utilizarse para transportar datos en un flujo de datos USTM y proporcionar informacion de transicion en el flujo de datos USTM transmitido. Los datos transportados en el flujo de datos USTM pueden corresponder a una pluralidad de flujos y/o tipos de trafico, que pueden reenviarse desde al menos un nodo origen. El metodo de senalizacion de UST 1000 puede realizarse mediante un sistema de conmutacion UST, tal como el aparato de conmutacion UST 300, en donde las diferentes etapas en el metodo 1000 pueden realizarse por cualquiera de los componentes del aparato 300.
El metodo 1000 puede iniciarse en el bloque 1002, en donde pueden recibirse datos en un flujo. A modo de ejemplo, la interfaz tributaria 330 puede recibir datos en un flujo desde uno de los primeros enlaces 320, p.ej., datos de Ethernet 100G basados en el formato de codificacion 64b/66b. De forma adicional, o alternativa, la interfaz tributaria 330 puede recibir datos de trafico TDM, p.ej., desde una red SONET/SDH. En el bloque 1004, el flujo puede identificarse utilizando un mapa de flujos. A modo de ejemplo, la interfaz tributaria 330 puede obtener un identificador ID de flujo a partir de los datos que indican el flujo de los datos recibidos. El identificador ID de flujo o numero pueden adaptar una entrada al mapa de flujos 332. En el bloque 1008, el metodo 1000 puede determinar si ha cambiado el estado del flujo. Si ha cambiado el estado de flujo, tal como desde inactivo a activo, entonces, el metodo 1000 puede proseguir con el bloque 1010. De no ser asf, el metodo 1000 puede proseguir en el bloque 1014.
En el bloque 1010, una senalizacion transicional puede enviarse en el flujo de datos USTM. La senalizacion transicional puede anadirse al flujo USTM utilizando un codigo de operacion, p.ej., sobre la base de cualquiera de los esquemas de codificacion UST anteriormente descritos. La senalizacion transicional puede especificar el tipo de transicion que ocurrio en el flujo de los datos recibidos. En el bloque 1012, la Tabla de estado de flujos y/o la Tabla de estados TS pueden actualizarse. A modo de ejemplo, la entrada en la Tabla de estados de flujo (p.ej., Tabla 6) que corresponde al flujo de los datos, p.ej., que comprende el mismo identificador ID de flujo de los datos, puede actualizarse para indicar el estado cambiado actual del flujo. De forma adicional o alternativa, una entrada en la Tabla de estados TS (p.ej., Tabla 5) que corresponde al intervalo temporal asignado para los datos puede actualizarse para indicar el estado cambiado actual.
En el bloque 1014, los datos pueden enviarse en el flujo de datos USTM, p.ej., en un enlace unico a una matriz de conmutacion (p.ej., la matriz de conmutacion 310). A modo de ejemplo, la interfaz tributaria 330 puede enviar los datos en el intervalo temporal asignado en el flujo USTM por intermedio de una interfaz XLAUI o XAUI. En el bloque 1016, el metodo 1000 puede determinar si continuar, p.ej., si existen mas datos a recibirse. El metodo 1000 puede retornar al bloque 1002 si continua la recepcion de datos. De no ser asf, el metodo 1000 puede finalizarse.
Los componentes descritos con anterioridad pueden ser objeto de operacion en conjuncion con cualquier componente de red de uso general, tal como un ordenador o componente de red con potencia de procesamiento suficiente, recursos de memoria y capacidad de rendimiento de red para gestionar la carga de trabajo necesaria que se le ha impuesto. La Figura 11 ilustra una componente de red de uso general tfpica 1100 adecuado para realizar una o mas formas de realizacion de los componentes aqrn dados a conocer. El componente de red 1100 puede incluir un procesador 1102 (que puede referirse como una unidad central de procesador o CPU) que esta en comunicacion con cualesquiera dispositivos de memoria incluyendo una memoria secundaria 1104, una memoria de solamente lectura (ROM) 1106, una memoria de acceso aleatorio (RAM) 1108, dispositivos de entrada/salida (I/O) 1110, y dispositivos de conectividad de red 1112 o sus combinaciones. El procesador 1102 puede ponerse en practica como uno o mas circuitos integrados de la CPU o puede ser parte de uno o mas circuitos integrados ASICs.
La memoria secundaria 1104 suele estar constituida por una o mas unidades de disco u otros dispositivos de memorizacion y se utiliza para memorizacion no volatil de datos y como un dispositivo de memorizacion de datos de sobreflujo si la memoria RAM 1108 no tiene capacidad suficiente para mantener todos los datos de trabajo. La memoria secundaria 1104 puede utilizarse para memorizar programas que se cargan en memoria RAM 1108 cuando dichos programas se seleccionan para su ejecucion. La memoria ROM 1106 se utiliza para memorizar instrucciones y quizas datos que son objeto de lectura durante la ejecucion del programa. La memoria ROM 1106 es un dispositivo de memoria no volatil que suele tener una pequena capacidad de memoria relativa a la mayor capacidad de memoria de la memoria secundaria 1104. La memoria RAM 1108 se utiliza para memorizar datos volatiles y quizas para memorizar instrucciones. El acceso a la memoria ROM 1106 y a la memoria RAM 1108 suele ser mas rapido que a la memoria secundaria 1104.
Al menos una forma de realizacion se da a conocer y variaciones, combinaciones y/o modificaciones de las formas de realizacion y/o caractensticas de las formas de realizacion realizadas por un experto en esta tecnica estan dentro del alcance de la idea inventiva. Formas de realizacion alternativas que resulten de combinar, integrar y/o omitir caractensticas de las formas de realizacion estan tambien dentro del alcance de la idea inventiva. En donde se
5
10
15
20
25
30
35
establezca expresamente margenes numericos o limitaciones, dichos margenes numericos o limitaciones debe entenderse que incluyen margenes iterativos o limitaciones de magnitud similar que caen dentro de los margenes o limitaciones establecidos de forma expresa. A modo de ejemplo, cuando se da a conocer un margen numerico con un lfmite inferior, R1, y un lfmite superior Ru, cualquier numero que caiga dentro del margen se da a conocer de forma concreta. En particular, los siguientes numeros dentro del margen se dan a conocer concretamente: R = R1 + k * (Ru - Ri), en donde k es un margen variable desde 1 por ciento a 100 por ciento con un incremento del 1 por ciento, esto es, k es 1 por ciento, 2 por ciento, 3 por ciento, 4 por ciento, 5 por ciento, ..., 50 por ciento, 51 por ciento, 52 por ciento, ..., 95 por ciento, 96 por ciento, 97 por ciento, 98 por ciento, 99 por ciento o 100 por ciento. Ademas, cualquier margen numerico definido por dos numeros R en la forma anteriormente definida se da a conocer de forma concreta. La utilizacion del termino “de modo opcional” con respecto a cualquier elemento de una reivindicacion significa que se requiere el elemento o como alternativa, el elemento no se requiere, estando ambas alternativas dentro del alcance de la reivindicacion. La utilizacion de terminos mas amplios tales como comprende, incluye y teniendo debe entenderse que proporciona soporte para terminos menos amplios tales como consiste en, consiste esencialmente y comprende sustancialmente. En consecuencia, el alcance de la proteccion no esta limitado con la descripcion anteriormente establecida sino que se define por las reivindicaciones siguientes, incluyendo ese alcance todos los equivalentes del contenido de las reivindicaciones. Todas y cada reivindicacion se incorporan como idea inventiva adicional en la especificacion y las reivindicaciones son formas de realizacion de la presente invencion. El examen de una referencia en la idea inventiva no es una admision de que es tecnica anterior, en particular, cualquier referencia que tenga una fecha de publicacion despues de la fecha de prioridad de esta solicitud de patente.
Aunque varias formas de realizacion han sido dadas a conocer en la presente idea inventiva, debe entenderse que los sistemas y metodos dados a conocer podnan materializarse en numerosas otras formas espedficas sin desviarse por ello del espmtu o del alcance de proteccion de la presente invencion. Los presentes ejemplos han de considerarse como ilustrativos y no restrictivos y su intencion no es limitarse a los detalles aqrn dados. A modo de ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o determinadas caractensticas pueden omitirse o no ponerse en practica.
Ademas, las tecnicas, los sistemas, los subsistemas y los metodos descritos e ilustrados en las diversas formas de realizacion como discretos o separados pueden combinarse o integrarse con otros sistemas, modulos, tecnicas o metodos sin desviarse por ello del alcance de la presente invencion. Otros elementos ilustrados o examinados como estando acoplados o directamente acoplados o en comunicacion entre sf pueden acoplarse de forma indirecta o comunicarse por intermedio de alguna interfaz, dispositivo o componente intermedio tanto electrico como mecanico o de cualquier otra naturaleza. Otros ejemplos de cambios, sustituciones y modificaciones son averiguables por un experto en esta tecnica y podnan realizarse sin desviarse por ello del alcance de la presente invencion.

Claims (9)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un aparato que comprende:
    una matriz de conmutacion (310) acoplada a una pluralidad de interfaces y configurada para conmutar un flujo de datos de multiplexacion de transporte de servicio universal (UST) (USTM) recibido a partir de una de las interfaces hacia al menos algunas de las otras interfaces,
    en donde la matriz de conmutacion (310) comprende medios para recibir el flujo de datos USTM, en donde el flujo de datos USTM comprende una pluralidad de intervalos temporales, un trafico de conmutacion de paquetes, un trafico de conmutacion de circuitos y un indicador de transicion de tipo de datos que separa el trafico de conmutacion de circuitos del trafico de conmutacion de paquetes,
    el indicador de transicion de tipo de datos indica un cambio de estado entre el trafico de conmutacion de paquetes y el trafico de conmutacion de circuitos,
    la matriz de conmutacion (310) comprende, ademas, medios para separar el trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes utilizando el indicador de transicion de tipo de datos, un primer conmutador para conmutar el trafico de conmutacion de circuitos y un segundo conmutador para conmutar el trafico de conmutacion de paquetes,
    caracterizado por cuanto que el indicador de transicion de tipo de datos se proporciona utilizando campos de codigo de operacion (510) en un bloque de codificacion (500), siendo los campos de codigo de operacion (5l0) utilizados para indicar un conjunto de senales de transicion UST, que comprende un inicio y un final de diferentes flujos de trafico.
  2. 2. El aparato segun la reivindicacion 1, en donde el indicador de transicion de tipo de datos en el flujo de datos USTM indica un inicio del trafico de conmutacion de paquetes o del trafico de conmutacion de circuitos que sigue al indicador de transicion de tipo de datos en el flujo de datos.
  3. 3. El aparato segun la reivindicacion 1, en donde el trafico de conmutacion de paquetes comprende un trafico de paquetes de mejor esfuerzo, BEP, en donde el trafico de conmutacion de circuitos comprende un trafico de multiplexacion por division temporal, TDM, y un trafico de flujo de alto rendimiento, HPF, y en donde el trafico TDM, el trafico HPF y el trafico BEP son multiplexados utilizando un esquema TDM en el flujo de datos USTM.
  4. 4. El aparato segun la reivindicacion 3, en donde un primer conjunto de intervalos temporales asignados dentro de una ventana temporal se asigna al trafico HPF, un segundo conjunto de intervalos temporales asignados dentro de la ventana temporal se asigna al trafico TDM y un conjunto de intervalos temporales no asignados dentro de la ventana temporal se asigna al trafico BEP.
  5. 5. El aparato segun la reivindicacion 3 o 4, en donde el indicador de transicion de tipo de datos en el flujo de datos USTM indica, ademas, una transicion entre un estado activo y un estado inactivo para un flujo del trafico HPF.
  6. 6. Un metodo caracterizado por cuanto que comprende:
    recibir un flujo de datos de multiplexacion de transporte de servicio universal (UST) (USTM) que comprende una pluralidad de intervalos temporales, un trafico de conmutacion de paquetes, un trafico de conmutacion de circuitos y un indicador de transicion de tipo de datos que separa el trafico de conmutacion de circuitos con respecto del trafico de conmutacion de paquetes, en donde el indicador de transicion de tipo de datos indica un cambio de estado entre el trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes;
    separar el trafico de conmutacion de circuitos y el trafico de conmutacion de paquetes utilizando el indicador de transicion de tipo de datos; y
    conmutar el trafico de conmutacion de circuitos en un primer conmutador y el trafico de conmutacion de paquetes en un segundo conmutador,
    caracterizado por cuanto que el indicador de transicion de tipo de datos se proporciona utilizando campos de codigo de operacion en un bloque de codificacion, siendo los campos de codigo de operacion utilizados para indicar un conjunto de senales de transicion UST, que comprenden un inicio y un final de diferentes flujos de trafico.
  7. 7. El metodo segun la reivindicacion 6, en donde el flujo de datos USTM comprende una pluralidad de unidades de senalizacion de codificacion (SUs), y en donde cada unidad SU de codificacion comprende un codigo de operacion multiparte que indica informacion de transicion adicional, un campo de continuacion que se establece para indicar un ultimo codigo de operacion multiparte o un codigo de operacion multiparte posterior en una unidad SU de codificacion posterior y un bit de paridad.
  8. 8. El metodo segun la reivindicacion 6, en donde el flujo de datos USTM comprende un bloque de codificacion T6xb basado en un formato de codificacion 64b/66b, y en donde el bloque de codificacion T6xb comprende aproximadamente ocho octetos, en donde al menos un primer octeto en el bloque de codificacion T6xb comprende
    5 un codigo de operacion de control que indica informacion de transicion y en donde el bloque de codificacion T6xb esta precedido por un valor de sincronizacion que indica la presencia del codigo de operacion de control en el bloque de codificacion T6xb.
  9. 9. El metodo segun la reivindicacion 6, en donde el flujo de datos USTM comprende una unidad de senalizacion 10 (SU) de codificacion T9b que comprende aproximadamente nueve bits, y en donde la unidad de senalizacion T9b
    comprende un codigo de operacion de control que indica informacion de transicion y un bit de senalizacion que se utiliza para detectar cualquier error en la unidad de senalizacion de codificacion T9b y la presencia del codigo de operacion de control.
    15
ES10801961.3T 2009-07-20 2010-07-20 Codificación transitoria de transporte de servicio universal Active ES2625741T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US836638 1992-02-14
US22697209P 2009-07-20 2009-07-20
US226972P 2009-07-20
US12/836,638 US8416770B2 (en) 2009-07-20 2010-07-15 Universal service transport transitional encoding
PCT/CN2010/075329 WO2011009402A1 (en) 2009-07-20 2010-07-20 Universal service transport transitional encoding

Publications (1)

Publication Number Publication Date
ES2625741T3 true ES2625741T3 (es) 2017-07-20

Family

ID=43465256

Family Applications (1)

Application Number Title Priority Date Filing Date
ES10801961.3T Active ES2625741T3 (es) 2009-07-20 2010-07-20 Codificación transitoria de transporte de servicio universal

Country Status (5)

Country Link
US (1) US8416770B2 (es)
EP (1) EP2430804B1 (es)
CN (1) CN102439923B (es)
ES (1) ES2625741T3 (es)
WO (1) WO2011009402A1 (es)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7986700B2 (en) 2006-09-25 2011-07-26 Futurewei Technologies, Inc. Multiplexed data stream circuit architecture
US8976796B2 (en) * 2006-09-25 2015-03-10 Futurewei Technologies, Inc. Bandwidth reuse in multiplexed data stream
US7809027B2 (en) 2006-09-25 2010-10-05 Futurewei Technologies, Inc. Network clock synchronization floating window and window delineation
US8340101B2 (en) * 2006-09-25 2012-12-25 Futurewei Technologies, Inc. Multiplexed data stream payload format
US8295310B2 (en) 2006-09-25 2012-10-23 Futurewei Technologies, Inc. Inter-packet gap network clock synchronization
KR101593241B1 (ko) * 2007-06-13 2016-02-11 엔엑스피 비 브이 보증된 서비스를 보장하는 전자장치 및 방법
US8473695B2 (en) * 2011-03-31 2013-06-25 Mosys, Inc. Memory system including variable write command scheduling
US9354823B2 (en) 2012-06-06 2016-05-31 Mosys, Inc. Memory system including variable write burst and broadcast command scheduling
US10612051B2 (en) * 2015-03-31 2020-04-07 White Dog Labs, Inc. Method of producing bioproducts
US11277217B2 (en) * 2015-06-30 2022-03-15 Ciena Corporation Flexible Ethernet switching systems and methods
CN108988977B (zh) * 2017-05-31 2021-06-08 中兴通讯股份有限公司 一种灵活以太网协议中传递业务流的方法、装置和系统
CN109962762B (zh) 2017-12-25 2020-06-16 华为技术有限公司 一种数据传输方法、发送装置及接收装置
DE102018129774A1 (de) * 2018-11-26 2020-05-28 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Netzwerkteilnehmers und Netzwerkteilnehmer
WO2020107298A1 (zh) * 2018-11-29 2020-06-04 唐山曹妃甸联城科技有限公司 传输通用服务传输转变编码的设备和方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1266476A4 (en) * 2000-03-10 2009-08-05 Cypress Semiconductor Corp PROMOTION SXHEMA FOR HYBRID DATA ON OPTICAL NETWORKS
US6925096B2 (en) * 2000-09-22 2005-08-02 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for managing traffic flows
US6646983B1 (en) * 2000-11-21 2003-11-11 Transwitch Corporation Network switch which supports TDM, ATM, and variable length packet traffic and includes automatic fault/congestion correction
US6999450B2 (en) * 2001-04-25 2006-02-14 Occam Networks Ethernet based TDM switch
CN1953400A (zh) * 2005-10-17 2007-04-25 华为技术有限公司 一种控制以太网链路连续性检测的方法
CN1859382A (zh) 2005-12-16 2006-11-08 华为技术有限公司 支持多业务的通信设备及其方法
US7843827B2 (en) * 2005-12-22 2010-11-30 International Business Machines Corporation Method and device for configuring a network device
US7675945B2 (en) 2006-09-25 2010-03-09 Futurewei Technologies, Inc. Multi-component compatible data architecture
CN101212424B (zh) 2006-12-28 2011-03-23 杭州华三通信技术有限公司 融合了电路交换和分组交换的以太网交换方法与设备
WO2008077320A1 (fr) * 2006-12-26 2008-07-03 Hangzhou H3C Technologies Co., Ltd. Procédé et dispositif de commutation ethernet
CN101212290B (zh) * 2006-12-26 2012-05-23 杭州华三通信技术有限公司 同步时分以太网传输方法及相应的传输装置
CN101299649B (zh) 2008-06-19 2011-08-24 中兴通讯股份有限公司 基于通用成帧规程的多业务混合汇聚方法和装置

Also Published As

Publication number Publication date
EP2430804A1 (en) 2012-03-21
EP2430804A4 (en) 2012-03-21
US8416770B2 (en) 2013-04-09
CN102439923B (zh) 2014-07-09
CN102439923A (zh) 2012-05-02
WO2011009402A1 (en) 2011-01-27
US20110013619A1 (en) 2011-01-20
EP2430804B1 (en) 2017-04-05

Similar Documents

Publication Publication Date Title
ES2625741T3 (es) Codificación transitoria de transporte de servicio universal
EP3713158B1 (en) Time transfer systems and methods over a stream of ethernet blocks
JP5883509B2 (ja) 時分割多重信号をスイッチングするためのネットワーク要素
JP5258976B2 (ja) 時分割多重信号を交換するために分割および再組み立て（ｓａｒ）機能を用いるスケーラブルなネットワーク要素
ES2336730T3 (es) Sistema de comunicacion.
ES2607934T3 (es) Reutilización del ancho de banda en un flujo de datos multiplexados
WO2020231877A1 (en) Ethernet signal format using 256b/257b block encoding
CN113557696A (zh) 在网络中路由FlexE数据
US8107362B2 (en) Multi-ring resilient packet ring add/drop device
US7573898B2 (en) Method and apparatus to double LAN service unit bandwidth
WO2017181675A1 (zh) 一种以太网中数据处理的方法、设备及系统
US20070047579A1 (en) Multipacket interface
US11916662B2 (en) System and method for performing rate adaptation of constant bit rate (CBR) client data with a fixed number of idle blocks for transmission over a metro transport network (MTN)
US7583599B1 (en) Transporting stream client signals via packet interface using GFP mapping
ES2224030T3 (es) Transporte mejorado de trafico ethernet sobre una red de transporte sdh/sonet.
US11838111B2 (en) System and method for performing rate adaptation of constant bit rate (CBR) client data with a variable number of idle blocks for transmission over a metro transport network (MTN)
WO2020107298A1 (zh) 传输通用服务传输转变编码的设备和方法
US8127055B1 (en) Resilient packet ring add/drop device supporting plug and play redundancy
US20230006938A1 (en) System and method for performing rate adaptation and multiplexing of constant bit rate (cbr) client data for transmission over a metro transport network (mtn)
JP3783623B2 (ja) ネットワーク装置及びそれを用いたネットワークシステム
Vishishtha et al. Designing and Implementation of GFP-T Frame Mapper
Ellanti et al. Next Generation Transport Technologies
Dutta et al. Grooming mechanisms in SONET/SDH and next-generation SONET/SDH