Xerox Network Systems ( XNS ) es un conjunto de protocolos de redes informáticas desarrollado por Xerox dentro de la arquitectura de sistemas de red Xerox . Proporcionó comunicaciones de red de propósito general, enrutamiento de redes y entrega de paquetes, y funciones de nivel superior, como una transmisión confiable y llamadas a procedimientos remotos . XNS fue anterior 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 la década de 1980, encargado de llevar la investigación de Xerox PARC al mercado. XNS se basó en la anterior (e igualmente influyente) suite PARC Universal Packet (PUP) 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 número de red, lo que permite construir redes más grandes a partir de varias más pequeñas, con enrutadores que controlan el flujo de información entre las redes.
Las especificaciones del conjunto de protocolos para XNS pasaron a ser de dominio público en 1977. Esto ayudó a que XNS se convirtiera en el protocolo canónico de red de área local , copiado en diversos grados por prácticamente todos los sistemas de red utilizados en 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 nunca se comercializó; Se utilizaron varias soluciones de XNS para problemas comunes en el reemplazo de AppleNet, AppleTalk .
En comparación con las 7 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) en XNS, que fue diseñada para utilizar el mecanismo de transporte del hardware subyacente y no separó el enlace de datos. Específicamente, la capa física de XNS es en realidad el sistema de red de área local Ethernet , que también está 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 que estarlo).
La parte principal de XNS es su 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 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 Control de Recursos, similar a la Presentación de OSI. [1] [2]
Finalmente, encima de ambos modelos, se encuentra la capa de Aplicación, aunque estas capas no estaban definidas en el estándar XNS. [1]
El principal protocolo de la capa de red es el Protocolo de datagramas de Internet ( IDP ). IDP es un descendiente cercano del protocolo de red 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 identificador único principal. A esto se suma otro apartado de dirección de 48 bits proporcionado por el equipo de networking; Los enrutadores proporcionan 32 bits para identificar el número de red en la red y otros 16 bits definen un número de socket para la selección de servicios 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 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, por lo que los protocolos de capa superior no necesitan implementar demultiplexación; IDP también proporciona tipos de paquetes (nuevamente, a diferencia de IP). IDP también contiene una suma de verificación que cubre todo el paquete, pero es opcional, no obligatoria. Esto refleja el hecho de que las LAN generalmente tienen tasas de error bajas, por lo que XNS eliminó la corrección de errores de los protocolos de nivel inferior para mejorar el rendimiento. Opcionalmente, se podría agregar corrección de errores en niveles superiores en la pila de protocolos, por ejemplo, en el propio protocolo SPP de XNS. XNS fue ampliamente considerado más rápido que IP debido a esta nota de diseño. [1]
De acuerdo 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 tasas de error bajas y tiempos de respuesta cortos. Los paquetes IDP tienen una longitud máxima de 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 65 KB. Los pares de hosts 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 intervinientes admiten paquetes más grandes. Además, los paquetes no se pueden fragmentar, como ocurre 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 otros conjuntos de protocolos) sigue utilizándose hoy en día en otros conjuntos de protocolos. , como el conjunto de protocolos de Internet. [2]
XNS también implementa un protocolo de eco simple en la capa de red, similar al ping de IP , pero operando 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 el ping, el eco de XNS colocó el comando directamente dentro del paquete IDP subyacente. [2] Se podría lograr lo mismo 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 error , como sistema de informes para problemas como la caída de paquetes. Esto proporcionó 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, archivo y envío remotos, etc., empleaban un protocolo de llamada a procedimiento remoto denominado 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 a un RPC (es decir, no había ningún "compilador RPC" disponible). Debido a que todas las aplicaciones utilizaban Courier, los documentos del protocolo de aplicación XNS especificaban solo interfaces de llamada de función de mensajería y tuplas de enlace de módulo+función. Había una función especial en Courier para permitir que una llamada de función enviara o recibiera datos masivos. [2]
Inicialmente, la ubicación del servicio XNS se realizaba mediante la transmisión de llamadas a procedimientos remotos utilizando una serie de transmisiones en anillo en expansión (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 ubicación del servicio, y las transmisiones del anillo en expansión se utilizaron solo para ubicar un Centro de Información 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 sistema XNS en sí. Esto significó que todos los proveedores que utilizaban los protocolos XNS crearon sus propias soluciones para compartir archivos y admitir impresoras . Si bien muchos de estos productos de terceros, en teoría, podían comunicarse entre sí a nivel de paquete, había poca o ninguna capacidad para llamar a los servicios de aplicaciones de cada uno. Esto condujo a una fragmentación completa del mercado XNS y se ha citado como una de las razones por las que la propiedad intelectual 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 sólidas" se basaron en el mismo protocolo Needham-Schroeder que luego utilizó Kerberos . Después de comunicarse con el servicio de autenticación para obtener las credenciales, este protocolo proporcionó una forma liviana de firmar digitalmente llamadas a procedimientos de mensajería, de modo que los receptores pudieran verificar la firma y autenticar a los remitentes a través de Internet XNS, sin tener que comunicarse nuevamente con el servicio de autenticación durante la duración del protocolo. sesión de comunicación. [3]
El lenguaje de impresión de Xerox, Interpress , era un estándar de formato binario para controlar impresoras láser. Los diseñadores de este lenguaje, John Warnock y Chuck Geschke, abandonaron posteriormente Xerox PARC para iniciar Adobe Systems . Antes de partir, se dieron cuenta de la dificultad de especificar un lenguaje de impresión binario, donde 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.
Debido a que las más de 8000 máquinas de la intranet corporativa de Xerox ejecutaban 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 mirar y tocar podría detener y manipular el estado del microcódigo de una máquina de la serie C o de la serie D, en cualquier lugar del mundo, y luego reiniciar la máquina.
Además, había un protocolo de depuración remota para el depurador de intercambio mundial. [4] Este protocolo podría, a través del "nub" del depurador, congelar una estación de trabajo y luego mirar y hurgar en varias partes de la memoria, cambiar variables y continuar la ejecución. Si los símbolos de depuración estuvieran disponibles, una máquina averiada podría depurarse de forma remota desde cualquier lugar del mundo.
En su último año en la Universidad de Harvard , Bob Metcalfe comenzó a realizar entrevistas en varias empresas y Jerry Elkind y Bob Taylor le dieron una cálida bienvenida en Xerox PARC , quienes estaban comenzando 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 navegaba en el sofá de la casa de Steve Crocker mientras asistía a una conferencia, Metcalfe tomó una copia de las Actas de la Fall Joint Computer Conference 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 redes de área amplia anterior. En junio había desarrollado sus propias teorías sobre las redes y las presentó a sus profesores, quienes las rechazaron y "lo echaron de culo". [5]
Metcalfe fue bienvenido en PARC a pesar de su tesis fallida y pronto comenzó el desarrollo de lo que entonces se conocía como "ALOHAnet in a wire". Se asoció con David Boggs para ayudar con la implementación electrónica y, a finales de 1973, estaban construyendo hardware que funcionara a 3 Mbit/s. Luego, la pareja comenzó a trabajar en un protocolo simple que se ejecutaría en el sistema. Esto llevó al desarrollo del sistema PARC Universal Packet (Pup) y, a finales de 1974, los dos tenían Pup funcionando con éxito en Ethernet. Presentaron una patente sobre los conceptos, y Metcalfe agregó varios otros nombres porque creía que merecían una mención, y luego presentaron un artículo sobre el concepto a Comunicaciones de ACM sobre "Ethernet: conmutación de paquetes distribuidos para redes informáticas locales", publicado en julio. 1976. [5]
En 1975, mucho antes de que se completara PUP, Metcalfe ya estaba irritado por la rígida dirección de Xerox. Creía que la empresa debería poner inmediatamente en producción Ethernet, pero encontró poco interés entre la alta dirección. Un acontecimiento fundamental 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 gerencia de Xerox se negó, creyendo que era mejor utilizar Ethernet para ayudar a vender sus propios equipos. Luego, el AI Lab crearía su propia versión de Ethernet, Chaosnet . [6]
Metcalfe finalmente dejó Xerox en noviembre de 1975 para incorporarse a Transaction Technology, una división de Citibank encargada del desarrollo de productos avanzados. Sin embargo, siete meses después David Liddle lo atrajo de nuevo a Xerox , quien recientemente había organizado la División de Desarrollo de Sistemas dentro de Xerox específicamente para llevar los conceptos de PARC al mercado. Metcalfe inmediatamente comenzó a rediseñar Ethernet para que funcionara a 20 Mbit/s y comenzó un esfuerzo para reescribir Pup en una versión con calidad de producción. Buscando ayuda sobre Pup, Metcalfe se acercó a Yogen Dalal , quien 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 curso en DARPA, pero finalmente se dio por vencido y se centró completamente en Pup. Dalal combinó su experiencia con ARPANET con los conceptos de Pup y, a finales de 1977, habían publicado el primer borrador de la especificación del sistema de red Xerox. Esta era esencialmente una versión de Pup con ID de host absolutas de 48 bits y protocolo de enlace de tres vías de TCP en el protocolo de paquetes secuenciados. [8]
A principios de 1978, el nuevo sistema estaba funcionando, pero la dirección todavía no hacía ningún movimiento para comercializarlo. Como lo expresó Metcalfe:
Cuando regresé a Xerox en 1976, estábamos a unos dos años y medio del envío del producto y en 1978 estábamos a unos dos años y medio del envío del producto. [7]
Cuando no se tomaron más medidas, Metcalfe dejó la empresa a finales de 1978. [7]
XNS , utilizado por última vez por Xerox para comunicarse con el sistema de publicación DocuTech 135, ya no se utiliza debido a la ubicuidad de IP. Sin embargo, jugó 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 Novell's IPX/SPX . [10] Estos sistemas agregaron sus propios conceptos además del sistema de enrutamiento y direccionamiento XNS; VINES agregó un servicio de directorio entre otros servicios, mientras que Novell NetWare agregó una serie de servicios orientados al usuario, como impresión y uso compartido de archivos. AppleTalk usaba enrutamiento similar a XNS, pero tenía direcciones incompatibles que usaban 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 algo más que IP. [11] Eventualmente fueron necesarias modificaciones BSD adicionales para soportar la gama completa de protocolos de Interconexión de Sistemas Abiertos (OSI).
Arquitectura de sistemas de red Xerox Introducción a los sistemas de red Xerox (XNSG 058504) es "una discusión general destinada a aquellos que desean saber cómo el personal de oficina puede volverse más eficaz y productivo utilizando los sistemas de red Xerox". [12] : pág.5
Los componentes de la arquitectura de sistemas de red Xerox se describen brevemente en el Manual de información general de arquitectura de sistemas de red 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 versiones más recientes de estos estándares sean: