Network Working Group Ken Lebowitz Request for Comments: 947 David Mankins BBN Laboratories Junio 1985 Difusión entre redes dentro de Internet 1. Estado de este memorándum Este RFC describe la extensión de un dominio de emisión de red para incluir más de una red física a través del uso de un repetidor de paquete de difusión. El siguiente informe presentará el problema de una difusión entre redes y nuestra motivación para la resolución de este problema que está en el contexto del desarrollo de un sistema operativo distribuido. Discutimos diferentes soluciones para extender un dominio de emisión y por qué elegimos el que ha sido implementado. Además, hay información sobre la implementación en sí misma y algunos apuntes de su rendimiento. Se espera que las ideas presentadas aquí ayudarán a la gente en Internet que tiene aplicaciones que hacen uso de la difusión y se han encontrado con la limitación de sólo ser capaz de emitir dentro de una única red. La información aquí presentada es precisa a la fecha de publicación pero especifica detalles, particularmente aquellos considerando nuestra implementación, que pueden cambiar en el futuro. La distribución de este memorándum es ilimitada. 2. El problema Generalmente, nos hemos enfrentado a la comunicación entre equipos en redes separadas a través del uso de protocolos de Internet y puertas de enlace. Un aspecto de la comunicación entre redes que no ha sido resuelto en Internet es la difusión extendida para abarcar dos o más redes. La difusión es una vía eficiente para enviar información a muchos equipos teniendo que transmitir un solo paquete. Muchas de las arquitecturas de red de área local (LAN, 'Local Area Network') actuales soportan directamente un mecanismo de difusión. Desafortunadamente, este mecanismo de difusión tiene un defecto cuando es usado en ambientes de trabajo en red que incluyen múltiples LANs conectadas por puertas de enlace como en la DARPA Internet. Este defecto es que los paquetes difundidos son sólo recibidos por los equipos en la red física en que el paquete fue difundido. Como resultado, cualquier aplicación que toma provecho de la difusión en LAN sólo puede difundir a aquellos equipos en sus redes físicas. Lebowitz & Mankins [Página 1] RFC 947 Difusión entre redes dentro de Internet Junio 1985 Aprovechamos la difusión en el desarrollo del Sistema Operativo Distribuido Cronus [1]. Cronus proporciona servicios y comunicación para procesos distribuidos en medio de una variedad de diferentes tipos de sistemas de computadoras. Cronus está hecho alrededor de grupos lógicos de equipos conectados a una o más LANs de alta velocidad. La comunicación en Cronus se hace sobre los protocolos TCP y UDP. Cronus hace uso de la difusión para la ubicación dinámica de recursos en otros equipos y para la recolección de información de estado desde un conjunto de servidores. Ya que las capacidades de la difusión de Cronus no pretenden estar limitadas a una sola LAN, necesitábamos encontrar alguna manera de extender nuestro dominio de difusión para incluir los equipos en LANs distantes para experimentar con grupos que cruzan varias redes físicas. Cronus usa difusiones predominantemente para comunicarse con un subconjunto de los equipos que reciben los mensajes difundidos. Un mecanismo de multidifusión sería más apropiado, pero no está disponible en algunas de las implementaciones de nuestra red, entonces elegimos la difusión para la implementación inicial de las utilidades de Cronus. 3. Nuestra solución La técnica que elegimos para experimentar con el problema de la difusión entre redes puede ser descrito como un "repetidor de difusión". Un repetidor de difusión es un mecanismo que retransmite transparentemente los paquetes de difusión desde una LAN a otra, y puede también reenviar paquetes de difusión a equipos en una red que no soporta la difusión en el nivel de enlace. Este mecanismo proporciona flexibilidad a la vez que aprovecha la comodidad de las difusiones LAN. Nuestro repetidor de difusión es un proceso en un equipo de red que escucha paquetes de difusión. Se toman estos paquetes y son retransmitidos, usando un simple protocolo repetidor a repetidor, para uno o más repetidores que están conectados a LANs distantes. El repetidor en el extremo receptor reemitirá el paquete en su LAN reteniendo la dirección de origen del paquete original. El repetidor de difusión puede ser muy inteligente en la selección de mensajes que serán reenviados. Actualmente tenemos el repetidor reenviando sólo mensajes de difusión enviados usando los puertos UDP usados por Cronus, pero los mensajes pueden ser seleccionados usando cualquier campo en los encabezados UDP o IP, o pueden ser reenviados todos los mensajes de difusión del nivel IP. 4. Alternativas al repetidor de difusión Exploramos algunas alternativas antes de decidir sobre nuestra técnica para reenviar mensajes de difusión. Uno de estos métodos fue poner funciones adicionales dentro de las puertas de enlace de Lebowitz & Mankins [Página 2] RFC 947 Difusión entre redes dentro de Internet Junio 1985 Internet. Las puertas de enlace pueden escuchar en el nivel de enlace por paquetes de difusión y retransmitir los paquetes a una o más puertas de enlace en LANs distantes. Estas puertas de enlace pueden entonces transmitir el mismo paquete en sus redes usando la capacidad de difusión del nivel de enlace de la red local, si alguna está disponible. Todas las puertas de enlace participantes en este esquema tendrían que mantener tablas de todas las otras puertas de enlace que están recibiendo difusiones. Si el receptor de la puerta de enlace estuvo sirviendo una red sin capacidad de difundirlas puede reenviar los mensajes directamente a uno o más equipos designados en sus redes pero, de nuevo, requerirían mantenimiento de las tablas en la puerta de enlace. Se rechazó poner esta clase de función dentro de las puertas de enlace por varias razones: (a) requerirían extensiones al protocolo de control de puerta de enlace para permitir actualización de las listas de puertas de enlace que tendrían que mantener, (b) ya que no todos los mensajes (ej.: dirección LAN - mensajes de resolución) necesitan ser reenviados, la necesidad de controlar el reenvío estaría bajo el control de los niveles más altos de los protocolos que pueden estar disponibles para las puertas de enlace, (c) Cronus puede ser puesto dentro de ambientes donde las puertas de enlace pueden ser provistas por vendedores alternativos que pueden no implementar la propagación de difusión, (d) como una parte de la red fundamental, las puertas de enlace están a lo mejor controladas por una agencia diferente de la que controla la configuración de un sistema Cronus, sumando complejidad burocrática para la reconfiguración. Otra idea que fue rechazada fue poner la funcionalidad de difusión dentro del kernel de Cronus. El kernel de Cronus es un proceso que corre en cada equipo participando en Cronus, y tiene la tarea de encaminar todos los mensajes pasados entre los procesos Cronus. El kernel de Cronus es el único programa en el sistema Cronus que directamente usa la capacidad de difusión (otra parte de comunicar Cronus usando mecanismos provistos por el kernel). Podemos, o eliminar completamente la dependencia del kernel de Cronus en la difusión, o agregar un mecanismo para emulación de difusión usando mensajes transmitidos en serie cuando la red fundamental en si misma no proporciona la difusión. Tampoco la solución requiere que todos los procesos del kernel de Cronus conozcan las direcciones de todos los otros participantes en un sistema Cronus, que vemos como un límite no deseable en la flexibilidad de configuración. También, esta solución sería específica de Cronus, mientras que la solución del repetidor de difusión es aplicable a otros protocolos basados en difusión. 5. Implementación El repetidor de difusión es implementado como dos procesos separados Lebowitz & Mankins [Página 3] RFC 947 Difusión entre redes dentro de Internet Junio 1985 - el reenviador y el repetidor. El proceso reenviador espera paquetes UDP de difusión que llegan a través de su red local que coinciden con uno o más números de puerto específicos (o direcciones de destino). Cuando se encuentra uno de estos paquetes, es encapsulado en un mensaje de reenviador-repetidor enviado a un proceso repetidor en una red foránea. El repetidor entonces retransmite el paquete reenviado en su LAN usando esa dirección de difusión del nivel de enlace de la red en el campo de destino del paquete, pero preservando la dirección de origen del paquete original. Cuando el proceso reenviador comienza por primera vez lee un archivo de configuración. Este archivo especifica las direcciones de los procesos repetidores y selecciona que paquetes serían reenviados a cada proceso repetidor (diferentes repetidores pueden seleccionar diferentes conjuntos de paquetes UDP). El reenviador intenta establecer una conexión TCP a cada repetidor listado en el archivo de configuración. Si un enlace TCP a un repetidor falla, el reenviador reintentará la conexión a el periódicamente. Los equipos no repetidores pueden también estar listados en los archivos de configuración. Para estos equipos el reenviador simplemente reemplazará la dirección de difusión de destino en el paquete UDP con la dirección del equipo y enviará este nuevo datagrama directamente al equipo no repetidor. Si un repetidor y un reenviador coexisten en la misma LAN puede haber un problema si el reenviador toma paquetes que han sido reemitidos por el repetidor. Como una precaución ante reemisiones de paquetes reenviados ("regeneración" o "resonancia"), el reenviador no se conecta a ningún repetidor listado en su archivo de configuración que está en la misma red que el reenviador mismo. También, para permitir un ciclo de difusión implicando dos LANs, cada una con un reenviador hablando a un repetidor en la otra LAN, los reenviadores no reenvían paquetes cuyas direcciones de origen no estén en la LAN del reenviador. 6. Experiencia A la fecha, el repetidor de difusión ha sido implementado en el VAX corriendo el sistema operativo UNIX BSD 4.2 con software de trabajo en red de BBN y ha demostrado trabajar completamente bien para nuestros propósitos. Nuestra configuración actual incluye dos Ethernets que están físicamente separadas por otras dos LANs. En los últimos meses el repetidor de difusión ha extendido exitosamente nuestro dominio de difusión para incluir ambas Ethernets aunque los mensajes entre las dos redes deben pasar a través de al menos dos puertas de enlace. Nos vimos forzados a agregar una capacidad especial a la implementación TCP/IP de BBN que permite procesos privilegiados para enviar emitir paquetes IP con otra dirección de Lebowitz & Mankins [Página 4] RFC 947 Difusión entre redes dentro de Internet Junio 1985 equipo de origen. El repetidor impone una considerable carga en los equipos compartidos que actualmente lo soportan debido a la necesidad de activar el proceso de reenvío en todos los paquetes UDP que llegan al equipo, ya que la decisión de rechazar un paquete la hace el software de nivel de usuario, en lugar de los controladores del protocolo de red. Una solución para este problema sería implementar el filtrado de paquetes en el kernel del sistema (dejando la administración de la configuración y el mecanismo de reemisión en el código de usuario) como se ha hecho en Stanford/CMU en un filtro de paquetes UNIX que ellos han desarrollado. Como una alternativa estamos planeando cambiar de host la implementación de la función del repetidor como un servicio de red especializado provisto por una microcomputadora basada en un sistema de tiempo real que es también parte de nuestra configuración Cronus. Este tipo de máquina se adapta mejor a la tarea ya que la sobrecarga por la planificación es mucho menor que en un sistema multiusuario de tiempo compartido. 7. Referencia [1] "Cronus, A Distributed Operating System: Phase 1 Final Report", R. Schantz, R. Thomas, R. Gurwitz, G. Bono, M. Dean, K. Lebowitz, K. Schroder, M. Barrow y R. Sand, reporte técnico n 5885, Bolt Beranek and Newman, Inc., enero 1985. El proyecto Cronus es mantenido por el Rome Air Development Cen- ter. 8. Nota de los editores Vea también los RFCs 919 y 940 sobre este tema. Traducción al castellano: Javier Waisbrot (2003), jwais@fi.uba.ar Lebowitz & Mankins [Página 5]