Ethernet en tiempo real

Ethernet en tiempo real:
(RETHER,
EtheReal)
Domingo Ortega Pérez de Villar
Ethernet en tiempo real 2
Índice
1 Invitación
2 Introducción
3 Ethernet
4 Modificaciones
4.1 Modificaciones que no alteran la compatibilidad
4.1.1 Homogéneas
4.1.2 RETHER
4.1.2.1 Introducción
4.1.2.2 Cambio a modo RETHER
4.1.2.3 Algoritmo
4.1.2.4 Cambio a modo CSMA
4.1.2.5 RETHER multisegmento
4.1.3 Heterogéneas
4.1.4 EtheReal
4.1.4.1 Introducción
4.1.4.2 Establecimiento de la conexión
4.1.4.3 Gestión de los recursos
4.1.4.4 Limitaciones
4.1.4.5 Requerimientos
4.1.4.6 Conmutación de paquetes
4.1.4.7 Conclusiones EtheReal
5 Conclusiones
6 Referencias
Ethernet en tiempo real 3
1 - Invitación
Hoy en día tanto la industria como los usuarios particulares demandan servicios que requieren de
una mínima calidad de servicio y que lleguen sin mas retraso que el inevitable al destino.
Hasta ahora dichos servicios los ofrecían protocolos como TTP(TDMA based), timed-token
protocol, Token bus(IEEE 802.4), Token Ring(IEEE 802.5), mientras que los protocolos basados en
Ethernet no daban ninguna garantía de cumplir con unos tiempos límites determinados.
Sin embargo, pese a la característica no determinista de Ethernet, se han conseguido cumplir con los
requerimientos de tiempo demandados.
A continuación pasaré a enfocar las distintas posibilidades.
2 - Introducción
Actualmente el uso de Ethernet para las redes de área local es la solución más extendida. El
abaratamiento de los conmutadores y de los hubs, ha provocado que se produzca la interconexión
de segmentos Ethernet entre otras redes locales Ethernet. De este modo y por su gran popularidad
se ha conseguido que se abaraten mucho los costes de los componentes para formar redes Ethernet.
Debido a estas características se ha provocado que el uso de Ethernet como solución para la
creación de redes de área local sea la opción mas extendida.
Sin embargo, no todo han sido ventajas para quienes hubieren elegido Ethernet como solución.
Aplicaciones como teleconferencias, ..., así como servicios de carácter industrial, requieren de una
comunicación en tiempo real. Éste es un problema para Ethernet ya que éste es, intrínsecamente, un
protocolo no determinista. No es posible establecer un límite máximo de tiempo a la hora de
transmitir un mensaje desde un punto a otro. Paquetes transmitidos desde un origen a un destino
pueden producir colisiones entre ellos. El protocolo de control de acceso al medio(MAC) de
Ethernet, CSMA/CD (Carrier Sense Multiple Acces con Collision Detection), permite dichas
colisiones. Estas colisiones hace imposible determinar de antemano cualquier retraso que se pueda
producir al enviar paquetes de un nodo a otro.
Sin embargo, y aprovechando que está tan extendido su uso, se han desarrollado variaciones del
protocolo en algunos casos y se ha considerado el uso de hardware especial en otros, para poder
satisfacer las necesidades de las aplicaciones que requieren cumplir unos límites de tiempo en la
retransmisión de los paquetes(radio, televisión, redes de sensores en entornos industriales, ...).
Cogiendo como base el sistema de capas del modelo OSI, se necesitan un esfuerzo conjunto de
todas las capas para satisfacer las condiciones de comunicación en tiempo real.
Ethernet en tiempo real 4
La capa de aplicación: no sólo la red debe garantizar una rápida respuesta para cumplir con las
condiciones de tiempo real, también lo debe de hacer la aplicación pertinente sirviendo una
respuesta en un tiempo acotado según las necesidades propias de la aplicación.
La capa de transporte: TCP y UDP, al ser los más extendidos, es dónde se han concentrado la mayor
parte delos esfuerzos para cumplir con las necesidades.
La capa de red: en donde más se ha trabajado es en el protocolo IP al ser la solución más extendida.
También se ha trabajado con las políticas de enrutamiento de paquetes en los routers para garantizar
que se cumplan unas condiciones de prioridad sobre otros paquetes que no tengan las mismas
restricciones de tiempo.
Con respecto a la capa de enlace de datos(Data link): para sobreponerse al indeterminismo que
supone Ethernet, se han propuesto una serie de soluciones para el control de acceso al medio.
Algunas pueden coexistir con los nodos Ethernet estandard, algunas son capaces de usar el mismo
hardware pero son incompatibles con el protocolo actual, y otras son compatibles pero no
garantizan nada en entornos en donde no todos de los nodos implementen las mismas
modificaciones.
3 - Ethernet
En Ethernet todo nodo antes de transmitir, al hacer uso de CSMA/CD, monitorea el medio para
comprobar posibles colisiones. Cuando la red está poco cargada, el tiempo de espera
para
transmitir es mínimo. Cuando la carga de la red aumenta, el mecanismo que hace uso de números
aleatorios para comprobar cuando puede tener una acceso, se va adaptando suavemente acorde a la
carga existente.
Una red es capaz de operar con un ratio de utilización cercano al 100% cuando los paquetes son lo
suficientemente grandes, incluso con un gran número de nodos. Con paquetes más pequeños el ratio
de utilización decrece. Cuando el medio no está muy cargado el control de acceso al medio se
comporta generalmente de manera justa ofreciendo un tiempo de espera pequeño. En caso contrario,
cuando hay mucho tráfico, deja de comportarse de una manera justa produciendo efecto captura(el
nodo que sea capaz de procesar y preparar la trama a enviar en un tiempo inferior al del hueco entre
tramas será el que cada vez irá incrementando su capacidad para acceder al medio decrementando la
del resto).
Los conmutadores Ethernet, en teoría, gestionan hasta ocho niveles de prioridad de tráfico. Sin
embargo, en la práctica sólo trabajan con cuatro. Aun así, muchos sólo disponen de tres colas para
gestionar el tráfico: “Best-effort”, “real time” y “management”. De modo que no es suficiente para
Ethernet en tiempo real 5
lograr una planificación adecuada que cumpla con las necesidades de las aplicaciones que sí que
requieran una mejor gestión en la transmisión para garantizar la entrega de paquetes en un tiempo
acotado.
4 - Modificaciones
Se han definido tres enfoques sobre modificaciones con respecto del estándar para aproximarnos a
la comunicación en tiempo real que buscamos. Estos posibles enfoques son: la supresión de
colisiones, reducir su número y la resolución de colisiones de una manera determinista.
Partiendo del protocolo original, existen dos tipos de modificaciones: las que necesitan que las
mismas modificaciones se produzcan en todos los dispositivos(soluciones homogéneas) y las que
no hacen falta que se lleven a cabo en todos los dispositivos(soluciones heterogéneas). Este último
grupo sería aquel en el que podrían coexistir con los productos habituales estándar.
→ Modificaciones que alteran la compatibilidad
→ Modificaciones que no alteran la compatibilidad
∟→ Homogéneas
(RHETER)
∟→ Heterogéneas
(EtheReal)
4.1 - Modificaciones que no alteran la compatibilidad
Se distinguen dos grupos entre las modificaciones que no alteran la compatibilidad, las
homogéneas, que como he mencionado antes se deben aplicar las mismas modificaciones a todos
los nodos de la red, y las heterogéneas, que no hace falta que se apliquen a todos los nodos.
4.1.1 - Homogéneas
Una solución vendría dada mediante la contención del tráfico de manera que se controlo el tráfico y
que en lugar de enviar tráfico a ráfagas, regular el tráfico de manera que se vaya liberando de
manera continua de forma moderada(traffic smooth). Con este tipo de tráfico, en el que los
mensajes llegan a una frecuencia constante, es más difícil sufrir colisiones que con un tráfico a base
de ráfagas. En time-triggered applications(aplicaciones que se activan de manera periódica), el
Ethernet en tiempo real 6
tráfico de tiempo real generado se produce de una manera regulada, de modo que es adecuado. Sin
embargo, el tráfico sin los requerimientos de tiempo real, se produce a modo de ráfagas. Este tráfico
al llegar, y antes de pasar a la capa de enlace de datos(data link), debe ser 'suavizado' atrasándolo en
periodos de tiempo mayores. Cuando se produce una ráfaga, los mensajes deben ser almacenados en
una cola y enviados uno tras otro a una frecuencia menor que la tasa de llegada que soporte la red.
Esta técnica de suavizado de ráfagas hace uso de la técnica del token bucket(cuba). La cuba tiene un
número fijo de créditos y un periodo de rellenado. Por cada periodo de relleno, se añaden créditos a
la cuba. Si el total de créditos excede el tamaño total de la cuba, se descarta el excedente Cuando se
envían paquetes, se sustraen de la cuba tantos créditos como el tamaño total de los paquetes
enviados. Y sólo se envía mientras queden créditos en la cuba. Si ya no hay créditos, se aguantan
los paquetes hasta que haya un número de créditos suficiente para llevar a cabo la acción. El reatime traffic no requiere ningún tipo de control en este sentido y es enviado tan pronto como llega.
4.1.2 - RETHER
4.1.2.1 - Introducción
Otro ejemplo es el protocolo RETHER. La única modificación que se requiere es reemplazar el
controlador de Ethernet por el de RETHER en cada dispositivo de la red. Sin embargo, es capaz de
garantizar los requerimientos de comunicación de aplicaciones multimedia sin tener que modificar
el hardware existente.
Cuando una aplicación solicita ancho de banda, se lo garantiza si es posible mientras esté activa
dicha aplicación. Los estudios del grupo de investigación de los desarrolladores de RETHER
demuestran que es posible reservar hasta el 60% de la capacidad de la red para comunicación en
tiempo real(RT: Real-Time) sin deteriorar el rendimiento de las aplicaciones sin ese
requerimiento(NRT: Non-Real-Time).
4.1.2.2 - Cambio a modo RETHER
La red opera usando Ethernet tal como se define el protocolo originalmente (CSMA/CD) hasta que
se produce una petición para garantizar tráfico en tiempo real. Cuando eso sucede, cambia a modo
token-bus (con el que puede garantizar una comunicación en tiempo real).
Ethernet en tiempo real 7
Cuando se está en modo token-bus, el tiempo se divide en ciclos de un periodo. Se asume que el
tráfico en tiempo real es periódico. En cada ciclo, el acceso al canal tanto el tráfico RT como el
NRT, está controlado mediante un token. Un nodo que solicite transmitir tráfico RT, pasará a
inscribirse en el grupo RT. En este grupo estarán presentes todos aquellos nodos con necesidad de
enviar información RT. En cada ciclo, primero se usará el canal para enviar tráfico en tiempo real y
lo que quede del ciclo se dejará para el resto de tráfico. De este modo, todos los nodos a los que se
les permitió entrar en el grupo de nodos RT consiguen transmitir información. Sin embargo no se
puede decir lo mismo de los nodos que quisieran enviar tráfico NRT, pues no tienen garantizado un
tiempo.
Cuando un nodo realiza una petición de real-time traffic, y todavía se está en modo CSMA, este
nodo se convierte en iniciador. Lo que hace es, mediante broadcast, indicar al resto de nodos de la
red que cambien al modo RETHER. Si más de un nodo intenta ser el iniciador al mismo tiempo, se
da al nodo con una ID menor, las mayor prioridad. El resto entonces espera a que se complete la
transmisión que mantiene en el buffer de salida y entonces envían un
acknowledgement al
iniciador. En cuanto el iniciador recolecta todos los acknowledgements, crea el token y lo pone en
circulación.
4.1.2.3 - Algoritmo
La información que debe contener el token será: el tiempo total que tarda el token en dar única
vuelta(Timed-token Rotation Time: TRT), así como también el tiempo que le queda en cada
momento para completarla, que será el tiempo residual(Residual Time: RT), la lista de todos los
nodos con requerimientos para real-time traffic, y todos los nodos que están activos en la red.
El token visitara tanto a los nodos con requerimientos RT como a los que transmitan tráfico NRT.
Cada nodo podrá disponer del token durante un periodo de tiempo específico(Token Holding time:
THT). Durante este tiempo el nodo que posea el token podrá enviar el tipo de tráfico que le
corresponda.
Cada proceso que necesite enviar real-time traffic especificará tanto el ancho de banda como la
cantidad de información que necesite enviar por cada TRT. De esta manera, se calcularan los
correspondientes THT de cada nodo.
Ethernet en tiempo real 8
Datos por TRT
S /W Overhead t token
ancho de banda Ethernet
Datos por TRT
THT NRT =
S /W Overhead t token
ancho de banda Ethernet
THT RT =
1
2
(1)se calcula solo una vez, cuando se hace la petición de reserva, mientras que (2) se calcula cada
vez que el token visita el nodo NRT(non-real-time traffic) basado en el tamaño del mensaje que
quiere enviar.
Cuando a un nodo perteneciente al grupo NRT necesite pasar al grupo RT, él mismo calculara si es
posible hacerlo garantizando sus necesidades así como mantener garantizadas las de aquellos otros
nodos que ya pertenecían al grupo. Se calcula de la siguiente manera:
 ∑ THT RT THT RT T NRT ≤TRT
iRT set
i
nuevo
De modo que si la suma de todos los anteriores THT RT , junto con el THT RT
nuevo
y el THT NRT son
menores que el Timed-token Rotation Time, esa transmisión será aceptada y por tanto el nodo
admitido en el grupo RT(para dicha conexión).
Es posible tener múltiples conexiones de entrada/salida por nodo, visitando el token tantas veces el
mismo nodo como haga falta y según el tipo de conexión RT o NRT.
Por ejemplo, dado el siguiente segmento, la asignación de tiempo disponible para enviar cada uno
de los nodos quedaría de la siguiente manera:
El token visitará primeramente a los nodos RT(aquellos que requieran real-time traffic). Cada uno
de estos nodos envía una unidad de tráfico real-time y decrementa el tiempo residual en THT RT . El
tiempo sobrante, el token visita los nodos NRT siguiendo una planificación Round-Robin
comenzando desde el siguiente nodo al último que visitó en el ciclo anterior. Cada nodo que visita
el token, calcula si tiene suficiente tiempo para enviar datos. En el caso de que tenga suficiente
Ethernet en tiempo real 9
tiempo, envía igual que hemos dicho antes. Decrementa el tiempo residual que marca el token en
THT NRT y transfiere el token al vecino. En caso de que no tenga tiempo para enviar, él mismo se
anota en el token como el siguiente nodo a visitar una vez hayan transmitido los nodos
pertenecientes al grupo RT. Entonces, dicho nodo envía el token al primer nodo del grupo RT. Este
nodo inicializa el tiempo residual que almacena el token a TRT(Timed-Token Rotation Time). De
este modo, todos los nodos pertenecientes al grupo RT (con necesidades de real-time traffic) tienen
prioridad sobre el resto de nodos pertenecientes al grupo NRT(sin necesidad de real-time traffic).
4.1.2.4 - Cambio a modo CSMA
Una vez los nodos pertenecientes a RT transmiten todo el tráfico deseado, en posesión del token, se
extraen del grupo RT y se añaden al grupo NRT en el token. En caso de ser el último token en el
grupo RT y haber cumplido ya con la transmisión de sus datos, manda un mensaje en broadcast a
todos los nodos indicando el cambio de nuevo al modo CSMA..
4.1.2.5 - RETHER Multisegmento
Pero RETHER no se limita sólo a un segmento, se puede extender a varios segmentos. Será
necesario por tanto, una conexión en tiempo real entre nodos pertenecientes a distintos segmentos.
De esta manera, a los que están conectados cada uno de los nodos.
Sin embargo, ésto trae varios problemas, como que ahora es mas difícil garantizar la latencia ya que
las conexiones real-time en cada uno de los segmentos son completamente diferentes. Por esta
razón, serán necesarios buffers para almacenar la información temporalmente retenida debido a las
diferencias entre cada segmento.
Otro problema que se presenta es el tiempo de establecimiento de la conexión donde en el peor de
los casos cada segmento debería cambiar de modo CSMA a modo RETHER.
4.1.3 - Heterogéneas
Soluciones heterogéneas serán aquellas en las que no haga falta que todos los dispositivos
Ethernet en tiempo real 10
implementen las mismas modificaciones para garantizar una comunicación en tiempo real.
Como ejemplo de solución heterogénea presentaré EtheReal.
4.1.4 - EtheReal
4.1.4.1 - Introducción
Un ejemplo de solución heterogénea, donde no todos los dispositivos de la red deben implementar
las mismas modificaciones para garantizar comunicación en tiempo real, sería EtheReal.
EtheReal garantiza ancho de banda basado en conexión a las aplicaciones que requieran de
comunicación en tiempo real usando los controladores y adaptadores normales de Ethernet. La
clave de EtheReal se encuentra en el uso de los conmutadores para garantizar conexiones que
requieran de comunicación en tiempo real. Las modificaciones en las que se basa EtheReal pueden
ser implementadas en software, de manera que no hace falta ningún requerimiento hardware
especial. A los usuarios, simplemente se les instalan librerías que serán capaces de establecer dichas
conexiones desde el origen hasta el destino sin involucrar los kernel de ningún nodo.
En el diseño de EtheReal se asume lo siguiente:
●
Los nodos están conectados a los conmutadores EtheReal mediante conexiones punto a
punto. De esta manera se elimina la mayor fuente de indeterminismo debida al protocolo de
acceso al medio CSMA/CD.
●
Todo el ancho de banda requerido por un nodo, tanto real-time como non-real-time, será
menor que el total del ancho de banda de la red. Así se elimina la mayor fuente de
problemas para garantizar un comportamiento adecuado para las aplicaciones con
requerimientos de comunicación en tiempo real, que se considera que está producida por
aplicaciones que ejecutan el resto de los nodos.
●
Se soportaran dos tipos de servicios sobre la red: conexiones en tiempo real con tasa de
transferencia variable, las cuales requerirán de un proceso de setup, y conexiones sin
requerimientos real-time con las cuales no será necesaria ninguna fase de setup, y por lo
tanto, no tendrán ninguna garantía.
●
Los nodos deberán soportar los protocolos TCP/UDP e IP.
4.1.4.2 - Establecimiento de la conexión
Uno de los propósitos al establecer la conexión entre nodos y conmutadores era no tener que añadir
Ethernet en tiempo real 11
al kernel ninguna capacidad especial para soportar el establecimiento de estas conexiones con las
características que acarrean.
Los identificadores de cada conexión deberán, por tanto, quedar embebidos en las cabeceras de la
capa de enlace, ya que los conmutadores trabajarán en esa capa.
Lo que han tenido que desarrollar era una forma de introducir identificadores de conexión en las
cabeceras ethernet de modo que conserve la semántica propia de ethernet y no tenga que modificar
ni el kernel del cliente como el del servidor.
Se asume que el sistema operativo de los nodos soporta los protocolos UDP/IP así como el ARP.
Cuando una aplicación solicita establecer una conexión en tiempo real, manda una petición de
reserva al real-time communication Daemon (RTCD)-en el mismo nodo-, que es un proceso que se
ejecuta a nivel de usuario. El RTCD será el encargado de establecer la conexión así como del “teardown”. En la solicitud de conexión se incluye la Ip del nodo destino, el puerto, y la calidad de
servicio que se desea obtener.
RTCD solicita la reserva al conmutador EtheReal al cual está conectado el nodo que quiere
establecer la conexión. Lo hará a través de paquetes UDP. El paquete incluirá la IP del nodo
destino, los parámetros de calidad de servicio, y un identificador único de dos bytes para la
conexión EtheReal entre el nodo origen y el conmutador al que está conectado. Está solicitud será
redirigida de un conmutador a otro hasta alcanzar el conmutador al cual está conectado el nodo
destino, de forma que sólo cambiarán los dos bytes que sirven para identificar la conexión EtheReal
entre conmutador y conmutador.
Una vez en el último conmutador, ya no es necesario que se redirija la reserva al nodo de destino,
ya que es el conmutador conectado a él el que le garantizará la conexión. De este modo, este último
conmutador, usará ya la dirección del nodo de destino.
Si la petición de establecimiento para la conexión real-time es aceptada por todos y cada uno de los
conmutadores a través de los que se conectan origen y destino, el ultimo conmutador enviara a
Ethernet en tiempo real 12
través de un paquete UDP un “succes” que recibirá el RTCD en el origen.
El RTCD crea una dirección proxy IP y otra Ethernet para la conexión en tiempo real añadiendo el
prefijo 1.1 para IP y FF.FF.FF.FF para Ethernet. También, añadirá en la cache ARP del nodo origen
una entrada ARP que transforma la dirección proxy IP en la dirección Ethernet de 6 bytes. El nodo
de origen entonces para comenzar a transferir a través de la conexión en tiempo real, creará sockets
UDP con la dirección proxy IP.
Cuando la capa IP del nodo reciba paquetes UDP de la aplicación en tiempo real, mirará en la cache
ARP para asociar la dirección de destino del paquete IP 147.156.21.33 con la dirección Ethernet
FF.FF.FF.FF.05.04 a través de la cual se hará la transmisión.
Cuando cualquiera de los conmutadores EtheReal reciben paquetes con una dirección de destino del
tipo FF.FF.FF.FF.XX.YY, él ya sabrá de que se trata de una conexión en tiempo real y en lugar de
interpretarla como una dirección Ethernet, sabe que XX.YY representan el ID de la conexión en
tiempo real. Cuando esto ocurra, dicho conmutador se encargará de cambiar la dirección de destino
cambiando XX.YY con el identificador de la conexión de dicho conmutador con el siguiente en la
cadena hasta llegar al conmutador directamente conectado con el nodo destino. Este último
conmutador cambiará el campo destino del paquete ethernet por la dirección ethernet del nodo
destino.
Una vez establecida la conexión, la comunicación se hará usando UDP como protocolo de
transporte.
Ethernet en tiempo real 13
4.1.4.3 - Gestión de los recursos
Dada la naturaleza de las conexiones en tiempo real, se debe reservar y garantizar los recursos
necesarios según los solicito el origen y con el propósito de mantener una calidad de servicio. Por
cada conmutador a través del cual se establece la conexión será necesario hacer esta reserva.
Cada conmutador cuando recibe la petición de establecimiento de conexión comprueba sus recursos
disponibles. Deberá comprobar si dispone del ancho de banda necesario en la interfaz por la que se
desea establecer la conexión. Deberá comprobar si dispone de la capacidad de procesamiento
necesaria para mantener un rendimiento deseado y cumplir con los requerimientos solicitados, y un
buffer lo suficientemente grande para almacenar las paquetes ante una posible diferencia en la
capacidad de entrada y de salida. El envío de paquetes en tiempo real está regulado de manera que
se intenta enviar continuamente una tasa constante de tráfico. De este modo, si se reciben muchos
paquetes de golpe, se irán almacenando porque se enviarán a una tasa constante y no a ráfagas
irregulares.
Si está en capacidad de garantizar una conexión bien con el siguiente conmutador o bien con el
nodo destino con las requerimientos solicitados, entonces aceptará la conexión. Si por el contrario
no está en disposición de garantizar los recursos necesarios, rechaza el establecimiento y se lo
comunica al nodo de origen.
4.1.4.4 - Limitaciones
Uno de los problemas vendría dado al colisionar paquetes cuando ambos, origen y destino intentan
acceder el uno al otro. Pero esto se resuelve cuando ambos lados soportan full-duplex en una
topología punto a punto.
Otro problema con el que se encuentra EtheReal está relacionado con la QoS sobre la conexión RT.
Mientras un nodo está transmitiendo su tráfico NRT, y comienza una transmisión en tiempo real
(RT), es posible que los buffers del nodo se llenen en el kernel. Esto supondría un agravio
importante de tiempo para las conexiones en tiempo real. De este modo el problema se recoge en
cómo priorizar los paquetes en el mismo nodo, dependiendo de su naturaleza, sin acceder al kernel.
Los conmutadores EtheReal controlan la tasa de transferencia TCP de los nodos que a él se
conectan. Cuando un nodo se excede en la cantidad de tráfico de salida-cuyo máximo tiene
asignado-, el conmutador EtheReal descarta los paquetes. Esto provoca que se llamen a los
procedimientos de control de congestión para conexiones TCP.
El ancho de banda TCP/UDP asignado a cada nodo es la diferencia entre el total de ancho de banda
Ethernet en tiempo real 14
para ese enlace y el total de ancho de banda asignado para las conexiones en tiempo real en dicho
nodo.
De este modo, asegura que las conexiones en tiempo real que se originan desde dicho nodo
obtengan su parte del ancho de banda así como de buffer suficiente para controlar la correcta
transferencia.
4.1.4.5 - Requerimientos
Qué requerimientos tiene el protocolo EtheReal. EtheReal está diseñado para poder funcionar en
nodos que soporten distintos sistemas operativos. De modo que es independiente de la plataforma
de los nodos.
Cada nodo deberá soportar dos componentes software para hacer funcionar EtheReal. Una es el
RTCD (Real-Time Communication Daemon). Éste implementará el establecimiento de la conexión
que anteriormente he explicado, y el tear-down. El RTCD comprobará periódicamente si la
aplicación en tiempo real está todavía en ejecución. En caso de no estarlo, las conexiones en tiempo
real que tiene asociada dicha aplicación son liberadas.
La otra es el RTTR (Real-Time data Transmission/Reception), que es una librería que implementa
el traffic shaping usando un algoritmo de “leaky bucket”. Este algoritmo lo que hace es suavizar el
tráfico saliente.
EtheReal suprime las colisiones, pero tampoco construye una solución determinista al problema. Si
todos los nodos al principio del periodo enviaran tráfico al mismo tiempo y a la máxima velocidad,
el enlace de red entre el último conmutador y el controlador se saturaría. Si los buffers en los
conmutadores no son lo suficientemente grandes para almacenar temporalmente el exceso de
tráfico, se corre el riesgo de que el buffer rebose con la consiguiente pérdida de frames. Sin
embargo, si suponemos que los buffer son lo suficientemente grandes para que esto no ocurra,
podría ser posible para aplicaciones críticas en tiempo real.
Una manera de evitar este problema es el uso de "traffic shaping” que lleva a cabo el RTTR.
La única particularidad que debe soportar el Sistema Operativo es la necesidad de añadir y eliminar
entradas ARP para enlazar la dirección IP del proxy a la dirección Ethernet del proxy. Pero esto
tampoco es un gran inconveniente ya que la mayaría de los sistemas operativos actuales
implementan esta característica.
Ethernet en tiempo real 15
4.1.4.6 - Conmutación de paquetes
Los conmutadores EtheReal distinguen cinco tipos de paquetes: (1) paquetes con dirección
broadcast como destino, (2)paquetes con destino al conmutador, (3) paquetes con direcciones de
destino entre FF.FF.FF.FF.00.00 y FF.FF.FF.FF.0A, (4) paquetes con direcciones de destino en el
rango FF.FF.FF.FF.**.** y que no pertenecen al grupo anterior, (5) paquetes con direcciones que
no pertenecen a ninguno de los grupos anteriores.
Para paquetes que pertenecen al primer grupo, los conmutadores EtheReal redirigen los paquetes en
todas las interfaces excepto por aquella por la que ha llegado. Al segundo grupo pertenecen los
paquetes que tienen como finalidad el uso de ARP. Los paquetes pertenecientes al grupo tres, son
aquellos paquetes que utilizan los conmutadores para comunicarse entre si. Por ejemplo para el
proceso de establecimiento de una nueva conexión. El cuarto grupo lo conforman los paquetes de
los cuales los dos últimos bytes de la dirección des destino sirven como ID para los conmutadores
EtheReal. Con este identificador, miran en sus tablas a ver a quien tienen que redirigir los paquetes.
Cada conexión entre conmutadores EtheReal para cada comunicación en tiempo real tiene su propio
identificador. El último grupo son todos aquellos paquetes cuya dirección de destino no pertenece a
ninguno de los grupos anteriores. Esto es para paquetes NRT (sin ningún requerimiento de conexión
en tiempo real).
Para datos en tiempo real, solamente el conmutador conectado al nodo de origen necesitará
manipular la cabecera IP para cambiar la dirección de destino del proxy por la dirección IP del
destinatario. El resto de conmutadores por los que atravesará el paquete usaran únicamente la
dirección de la cabecera Ethernet.
Para garantizar el ancho de banda reservado para cada conexión RT se usa un algoritmo de
planificación. EtheReal usa Round Robin cíclico. Cada cola dedicada a conexiones RT tendrá
garantizado un cierto intervalo de tiempo para transmitir.
En cada ciclo, el planificador visita primero todas las colas dedicadas a conexión en tiempo real en
cada puerto de salida, y después visitará las colas para conexiones NRT. Una vez se pone a
transmitir paquetes NRT, no volverá a las colas de RT hasta que no se acabe el ciclo (parecido a
cómo lo hacía RETHER). Así evita que luego se produzcan ráfagas de tráfico en la red. Esta
política de visitas ayuda a reducir la latencia media que tienen que soportar los paquetes NRT. Para
evitar la inanición de los paquetes NRT y grandes intervalos de tiempo provocados por los
protocolos de las capas superiores debido al retraso de paquetes grandes, la suma total del ancho de
banda reservado para las conexiones en tiempo real no excederán de un determinado porcentaje del
Ethernet en tiempo real 16
total del ancho de banda. Normalmente alrededor del 60%.
4.1.4.7 - Conclusiones EtheReal
Por todo lo visto hasta ahora, EtheReal es único en dos aspectos: es el único capaz de garantizar
realmente ancho de banda en lugar de otorgar distintos niveles de prioridad a los paquetes (DifServ)
y, por estar diseñado para poder conectar dispositivos directamente, en el sentido de que es
transparente tanto para el Sistema Operativo como para la interfaz de red (HW).
5 - Conclusiones
En este desarrollo sólo he comentado un par de ejemplos sobre soluciones homogéneas
y heterogéneas. Éstas, pertenecen al grupo de soluciones cuyas modificaciones sobre
Ethernet no alteran la compatibilidad con el protocolo actual. Dentro de el conjunto
desarrollado, la elección de soluciones homogéneas o heterogéneas dependerá
totalmente del entorno dónde se requiera una comunicación en tiempo real. No son los
mismos requerimientos en un entorno industrial que en un conjunto de oficinas, por lo que
la elección de una solución u otra se debe ajustar a las necesidades reales.
6 - Referencias
· efecto captura: http://www.rediris.es/rediris/boletin/49/enfoque3.html
· EtheReal: EtheReal: A Host-Transparent Rea-Time Fast Ethernet Switch. Srinidhi Varadajan, Tzicker Chiueh
· RETHER: Supporting Real-Time Traffic on Ethernet. Chitra Venkatramani, Tzi-cker Chiueh
· RETHER: Design, Implementation, and Evaluation of a Software-based Real-Time Ethernet
Protocol. Chitra Venkatramani, Tzi-cker Chiueh
· Achievong Real-Time Communication over Ethernet with Adaptative Traffic Smoothing. SeokKyu Kweon, Kang G. Shin
· Ethernet-Based Real-Time and Industrial Communications. Jean-Dominique Decotignie
· http://www.ce.chalmers.se/edu/course/EDA420/Documents/Slides/Slides_9_4up.pdf
· http://www.ce.chalmers.se/edu/course/EDA420/Documents/Slides/RTComm.pdf