Xerox Network Systems ( XNS ) es un conjunto de protocolos de redes informáticas desarrollado por Xerox dentro de la arquitectura de sistemas de redes de Xerox . Proporcionaba comunicaciones de red de propósito general, enrutamiento de interredes y entrega de paquetes, y funciones de nivel superior como un flujo confiable y llamadas a procedimientos remotos . XNS precedió e influyó en el desarrollo del modelo de red de interconexión de sistemas abiertos (OSI), y fue muy influyente en los diseños de redes de área local durante la década de 1980.
XNS fue desarrollado por el Departamento de Desarrollo de Sistemas de Xerox a principios de los años 1980, quienes se encargaron de llevar la investigación de Xerox PARC al mercado. XNS se basó en la suite PARC Universal Packet (PUP) anterior (e igualmente influyente) de finales de los años 1970. Algunos de los protocolos de la suite XNS eran versiones ligeramente modificadas de los de la suite Pup. XNS agregó el concepto de un número de red, lo que permitió construir redes más grandes a partir de varias redes más pequeñas, con enrutadores que controlaban el flujo de información entre las redes.
Las especificaciones del conjunto de protocolos para XNS se pusieron a disposición del público en 1977. Esto ayudó a que XNS se convirtiera en el protocolo de red de área local canónico , copiado en diversos grados por prácticamente todos los sistemas de red en uso hasta la década de 1990. XNS fue utilizado sin cambios por 3+Share de 3Com y Net/One de Ungermann-Bass . También se utilizó, con modificaciones, como base para Novell NetWare y Banyan VINES . XNS se utilizó como base para el sistema AppleNet , pero este nunca se comercializó; varias de las soluciones de XNS a problemas comunes se utilizaron en el reemplazo de AppleNet, AppleTalk .
En comparación con las siete capas del modelo OSI , XNS es un sistema de cinco capas, [1] como el conjunto de protocolos de Internet posterior .
Las capas física y de enlace de datos del modelo OSI corresponden a la capa física (capa 0) de XNS, que fue diseñada para utilizar el mecanismo de transporte del hardware subyacente y no separó el enlace de datos. En concreto, la capa física de XNS es en realidad el sistema de red de área local Ethernet , que también estaba siendo desarrollado por Xerox al mismo tiempo, y varias de sus decisiones de diseño reflejan ese hecho. [1] El sistema fue diseñado para permitir que Ethernet fuera reemplazado por algún otro sistema, pero eso no estaba definido por el protocolo (ni tenía por qué estarlo).
La parte principal de XNS es la definición de la capa de transporte interno (capa 1), que corresponde a la capa de red de OSI, y es aquí donde se define el protocolo de interconexión de redes primario, IDP. XNS combinó las capas de sesión y transporte de OSI en una única capa de comunicaciones entre procesos (capa 2). La capa 3 era de control de recursos, similar a la capa de presentación de OSI. [1] [2]
Finalmente, por encima de ambos modelos, se encuentra la capa de Aplicación, aunque estas capas no fueron definidas en el estándar XNS. [1]
El protocolo principal de la capa de interconexión de redes es el Protocolo de datagramas de Internet ( IDP ). IDP es un descendiente cercano del protocolo de interconexión de redes de Pup y corresponde aproximadamente a la capa de Protocolo de Internet (IP) en el conjunto de protocolos de Internet. [1]
IDP utiliza la dirección de 48 bits de Ethernet como base para su propio direccionamiento de red , generalmente utilizando la dirección MAC de la máquina como el identificador único principal. A esto se agrega otra sección de dirección de 48 bits proporcionada por el equipo de red; 32 bits son proporcionados por enrutadores para identificar el número de red en la interconexión de redes, y otros 16 bits definen un número de socket para la selección de servicio dentro de un solo host. La parte del número de red de la dirección también incluye un valor especial que significa "esta red", para uso de los hosts que (aún) no conocen su número de red. [2]
A diferencia de TCP/IP, los números de socket son parte de la dirección de red completa en el encabezado IDP, de modo que los protocolos de capa superior no necesitan implementar la demultiplexación; IDP también proporciona tipos de paquetes (de nuevo, a diferencia de IP). IDP también contiene una suma de comprobación que cubre todo el paquete, pero es opcional, no obligatoria. Esto refleja el hecho de que las LAN generalmente tienen bajas tasas de error, por lo que XNS eliminó la corrección de errores de los protocolos de nivel inferior para mejorar el rendimiento. La corrección de errores podría agregarse opcionalmente en niveles superiores en la pila de protocolos, por ejemplo, en el propio protocolo SPP de XNS. XNS fue ampliamente considerado como más rápido que IP debido a esta nota de diseño. [1]
En consonancia con las conexiones LAN de baja latencia en las que se ejecuta, XNS utiliza un tamaño de paquete corto, lo que mejora el rendimiento en el caso de bajas tasas de error y tiempos de respuesta cortos. Los paquetes IDP tienen una longitud de hasta 576 bytes, incluido el encabezado IDP de 30 bytes . [2] En comparación, IP requiere que todos los hosts admitan al menos 576, pero admite paquetes de hasta 65K bytes. Los pares de host XNS individuales en una red particular pueden usar paquetes más grandes, pero no se requiere ningún enrutador XNS para manejarlos y no se define ningún mecanismo para descubrir si los enrutadores intermedios admiten paquetes más grandes. Además, los paquetes no se pueden fragmentar, como se puede hacer en IP.
El Protocolo de Información de Enrutamiento (RIP), un descendiente del Protocolo de Información de Puerta de Enlace de Pup , se utiliza como sistema de intercambio de información del enrutador y (ligeramente modificado para que coincida con la sintaxis de las direcciones de otras suites de protocolos), sigue utilizándose hoy en día en otras suites de protocolos, como la suite de protocolos de Internet. [2]
XNS también implementa un protocolo de eco simple en la capa de interconexión de redes, similar al ping de IP , pero que opera en un nivel inferior en la pila de red. En lugar de agregar los datos ICMP como carga útil en un paquete IP, como en ping, el eco de XNS coloca el comando directamente dentro del paquete IDP subyacente. [2] Lo mismo se puede lograr en IP expandiendo el campo Protocolo ICMP del encabezado IP.
Hay dos protocolos de capa de transporte principales, ambos muy diferentes de su predecesor Pup:
XNS, al igual que Pup, también utiliza EP (el protocolo de errores ) como sistema de notificación de problemas como la pérdida de paquetes. Esto proporciona un conjunto único de paquetes que se pueden filtrar para buscar problemas. [2]
En el concepto original de Xerox, los protocolos de aplicación como impresión remota, archivo y envío de correo, etc., empleaban un protocolo de llamada a procedimiento remoto llamado Courier . Courier contenía primitivas para implementar la mayoría de las características de las llamadas a funciones del lenguaje de programación Mesa de Xerox . Las aplicaciones tenían que serializar y deserializar manualmente las llamadas a funciones en Courier; no había ninguna función automática para traducir un marco de activación de función en un RPC (es decir, no había ningún "compilador RPC" disponible). Debido a que todas las aplicaciones usaban Courier, los documentos del protocolo de aplicación XNS especificaban solo interfaces de llamada a funciones de Courier y tuplas de enlace de módulo+función. Había una función especial en Courier para permitir que una llamada a función enviara o recibiera datos en masa. [2]
Inicialmente, la localización del servicio XNS se realizaba mediante la difusión de llamadas a procedimientos remotos utilizando una serie de difusiones de anillo expansivo (en consulta con el enrutador local, para obtener redes a distancias cada vez mayores). Más tarde, se creó el servicio de directorio de 3 niveles del Protocolo Clearinghouse para realizar la localización del servicio, y las difusiones de anillo expansivo se utilizaron solo para localizar un Clearinghouse inicial. [2]
Debido a su estrecha integración con Mesa como tecnología subyacente, muchos de los protocolos tradicionales de nivel superior no formaban parte del propio sistema XNS. Esto significaba que los proveedores que utilizaban los protocolos XNS creaban sus propias soluciones para compartir archivos y compatibilidad con impresoras . Si bien muchos de estos productos de terceros en teoría podían comunicarse entre sí a nivel de paquetes, había poca o ninguna capacidad para llamar a los servicios de aplicación de los demás. Esto llevó a una fragmentación completa del mercado XNS y se ha citado como una de las razones por las que IP lo desplazó fácilmente. [1]
Los protocolos XNS también incluían un Protocolo de Autenticación y un Servicio de Autenticación para respaldarlo. Sus "credenciales fuertes" se basaban en el mismo protocolo Needham-Schroeder que luego utilizó Kerberos . Después de contactar al servicio de autenticación para obtener las credenciales, este protocolo proporcionaba una forma liviana de firmar digitalmente las llamadas al procedimiento Courier, de modo que los receptores pudieran verificar la firma y autenticar a los remitentes a través de Internet XNS, sin tener que contactar nuevamente al servicio de Autenticación durante la sesión de comunicación del protocolo. [3]
El lenguaje de impresión de Xerox, Interpress , era un estándar con formato binario para controlar impresoras láser. Los diseñadores de este lenguaje, John Warnock y Chuck Geschke, abandonaron más tarde Xerox PARC para fundar Adobe Systems . Antes de irse, se dieron cuenta de la dificultad de especificar un lenguaje de impresión binario, en el que las funciones para serializar el trabajo de impresión eran engorrosas y dificultaban la depuración de trabajos de impresión erróneos. Para darse cuenta del valor de especificar un trabajo de impresión programable y fácilmente depurable en ASCII, Warnock y Geschke crearon el lenguaje Postscript como uno de sus primeros productos en Adobe.
Como las más de 8000 máquinas de la intranet corporativa de Xerox utilizaban la arquitectura Wildflower (diseñada por Butler Lampson), existía un protocolo de depuración remota para el microcódigo. Básicamente, una función de búsqueda y descifrado podía detener y manipular el estado del microcódigo de una máquina de la serie C o de la serie D, en cualquier parte del mundo, y luego reiniciar la máquina.
Además, existía un protocolo de depuración remota para el depurador de intercambio de mundos. [4] Este protocolo podía, a través del "nub" del depurador, congelar una estación de trabajo y luego echar un vistazo a varias partes de la memoria, cambiar variables y continuar la ejecución. Si hubiera símbolos de depuración disponibles, una máquina bloqueada podría depurarse de forma remota desde cualquier lugar de la Tierra.
En su último año en la Universidad de Harvard , Bob Metcalfe comenzó a hacer entrevistas en varias empresas y recibió una cálida bienvenida de Jerry Elkind y Bob Taylor en Xerox PARC , que estaban empezando a trabajar en las estaciones de trabajo informáticas en red que se convertirían en Xerox Alto . Aceptó unirse a PARC en julio, después de defender su tesis. En 1970, mientras dormía en el sofá de la casa de Steve Crocker mientras asistía a una conferencia, Metcalfe cogió una copia de las Actas de la Conferencia Conjunta de Otoño de la mesa con el objetivo de quedarse dormido mientras la leía. En cambio, quedó fascinado por un artículo sobre ALOHAnet , un sistema de red de área amplia anterior. En junio había desarrollado sus propias teorías sobre redes y las presentó a sus profesores, quienes las rechazaron y lo "echaron a patadas". [5]
Metcalfe fue bien recibido en PARC a pesar de su tesis fallida y pronto comenzó el desarrollo de lo que entonces se conocía como "ALOHAnet en un cable". Se asoció con David Boggs para ayudar con la implementación electrónica y a fines de 1973 estaban construyendo hardware funcional a 3 Mbit/s. Luego, la pareja comenzó a trabajar en un protocolo simple que se ejecutaría en el sistema. Esto condujo al desarrollo del sistema PARC Universal Packet (Pup) y, a fines de 1974, los dos lograron ejecutar Pup con éxito en Ethernet. Presentaron una patente sobre los conceptos, y Metcalfe agregó varios otros nombres porque creía que merecían ser mencionados, y luego presentaron un artículo sobre el concepto a Communications of the ACM sobre "Ethernet: Distributed Packet Switching for Local Computer Networks", publicado en julio de 1976. [5]
En 1975, mucho antes de que se completara el PUP, Metcalfe ya estaba molesto con la rígida dirección de Xerox. Creía que la empresa debía poner inmediatamente a producir Ethernet, pero encontró poco interés entre la alta dirección. Un acontecimiento trascendental tuvo lugar cuando profesores del famoso Laboratorio de Inteligencia Artificial del MIT se acercaron a Xerox en 1974 con la intención de comprar Ethernet para utilizarlo en su laboratorio. La dirección de Xerox se negó, creyendo que Ethernet se utilizaría mejor para ayudar a vender su propio equipo. El Laboratorio de Inteligencia Artificial luego pasaría a fabricar su propia versión de Ethernet, Chaosnet . [6]
Metcalfe finalmente dejó Xerox en noviembre de 1975 para trabajar en Transaction Technology, una división de Citibank encargada del desarrollo avanzado de productos. Sin embargo, siete meses después David Liddle lo atrajo de nuevo a Xerox , ya que había organizado recientemente la División de Desarrollo de Sistemas dentro de Xerox específicamente para llevar los conceptos de PARC al mercado. Metcalfe comenzó inmediatamente a rediseñar Ethernet para que funcionara a 20 Mbit/s y comenzó un esfuerzo para reescribir Pup en una versión de calidad de producción. En busca de ayuda para Pup, Metcalfe se acercó a Yogen Dalal , que en ese momento estaba completando su tesis doctoral con Vint Cerf en la Universidad de Stanford . Dalal también estaba siendo reclutado en gran medida por el equipo ARPANET de Bob Kahn (que trabajaba en TCP/IP), pero cuando Cerf se fue para unirse a DARPA , Dalal aceptó mudarse a PARC y comenzó allí en 1977. [7]
Dalal formó un equipo que incluía a William Crowther y Hal Murray, y comenzó con una revisión completa de Pup. Dalal también intentó seguir involucrado en los esfuerzos de TCP en marcha en DARPA, pero finalmente se dio por vencido y se concentró completamente en Pup. Dalal combinó su experiencia con ARPANET con los conceptos de Pup y para fines de 1977 habían publicado el primer borrador de la especificación del Sistema de Red Xerox. Esto era esencialmente una versión de Pup con identificadores de host absolutos de 48 bits y el protocolo de enlace de 3 vías de TCP en el Protocolo de Paquetes Secuenciados. [8]
A principios de 1978, el nuevo sistema ya estaba funcionando, pero la dirección todavía no hacía ningún movimiento para comercializarlo. Como dijo Metcalfe:
Cuando regresé a Xerox en 1976, estábamos a dos años y medio de enviar el producto y en 1978 estábamos a dos años y medio de enviar el producto. [7]
Al no haber más medidas disponibles, Metcalfe abandonó la empresa a finales de 1978. [7]
XNS , que Xerox utilizó por última vez para comunicarse con el sistema de publicación DocuTech 135, ya no se utiliza debido a la ubicuidad del protocolo IP. Sin embargo, desempeñó un papel importante en el desarrollo de la tecnología de redes en la década de 1980, al influir en los proveedores de software y hardware para que consideraran seriamente la necesidad de que las plataformas informáticas admitieran más de una pila de protocolos de red simultáneamente.
Una amplia variedad de sistemas de redes propietarios se basaban directamente en XNS o ofrecían variaciones menores sobre el tema. Entre ellos se encontraban Net/One, 3+, [1] Banyan VINES [9] y el IPX/SPX de Novell . [10] Estos sistemas añadieron sus propios conceptos sobre el sistema de direccionamiento y enrutamiento XNS; VINES añadió un servicio de directorio entre otros servicios, mientras que Novell NetWare añadió una serie de servicios orientados al usuario como la impresión y el uso compartido de archivos. AppleTalk utilizaba un enrutamiento similar al de XNS, pero tenía direcciones incompatibles que utilizaban números más cortos.
XNS también ayudó a validar el diseño del subsistema de red 4.2BSD al proporcionar un segundo conjunto de protocolos, uno que era significativamente diferente de los protocolos de Internet; al implementar ambas pilas en el mismo núcleo, los investigadores de Berkeley demostraron que el diseño era adecuado para más que solo IP. [11] Finalmente, se necesitaron modificaciones BSD adicionales para soportar la gama completa de protocolos de Interconexión de Sistemas Abiertos (OSI).
Introducción a los sistemas de red de Xerox (XNSG 058504) es "una discusión general destinada a quienes desean saber cómo el personal de oficina puede volverse más efectivo y productivo mediante el uso de los sistemas de red de Xerox". [12] : p.5
Los componentes de la arquitectura de sistemas de red de Xerox se describen brevemente en el Manual de información general de la arquitectura de sistemas de red de Xerox (XNSG 068504). [13]
En el Catálogo de literatura del Xerox Systems Institute se incluye una serie de dieciséis descripciones de protocolos individuales . [12] Posiblemente, las versiones más recientes de estos estándares son: