La arquitectura de sistemas en red [1] ( SNA ) es la arquitectura de red patentada de IBM , creada en 1974. [2] Es una pila de protocolos completa para interconectar computadoras y sus recursos. SNA describe formatos y protocolos pero, en sí misma, no es una pieza de software. La implementación de SNA toma la forma de varios paquetes de comunicaciones, más notablemente el Método de acceso a telecomunicaciones virtuales (VTAM), el paquete de software de mainframe para comunicaciones SNA.
Contaban con el apoyo de los controladores de comunicaciones IBM 3704/3705 y su Programa de Control de Red (NCP), y de System/370 y su VTAM y otros programas informáticos como CICS e IMS. A este anuncio le siguió otro en julio de 1975, que presentó la estación de entrada de datos IBM 3760 , el sistema de comunicaciones IBM 3790 y los nuevos modelos del sistema de visualización IBM 3270. [4]
SNA fue diseñado en una época en la que la industria informática no había adoptado por completo el concepto de comunicación en capas. Las aplicaciones, bases de datos y funciones de comunicación se mezclaban en el mismo protocolo o producto, lo que dificultaba su mantenimiento y gestión. [5] [6] SNA fue diseñado principalmente por el laboratorio de la División de Desarrollo de Sistemas de IBM en Research Triangle Park , Carolina del Norte , EE. UU., [7] con la ayuda de otros laboratorios que implementaron SNA/SDLC. Posteriormente, IBM hizo públicos los detalles en sus manuales de la Biblioteca de referencia del sistema y en IBM Systems Journal .
Todavía se utiliza ampliamente en bancos y otras redes de transacciones financieras, así como en muchas agencias gubernamentales. En 1999 había aproximadamente 3.500 empresas "con 11.000 mainframes SNA". [8] Uno de los componentes principales del hardware, el controlador de comunicaciones 3745/3746 , ha sido retirado [a] del mercado por IBM. IBM continúa brindando servicio de mantenimiento de hardware y funciones de microcódigo para brindar soporte a los usuarios. Un mercado robusto de empresas más pequeñas continúa brindando funciones, partes y servicio al 3745/3746. IBM también brinda soporte a VTAM, al igual que al NCP requerido por los controladores 3745/3746.
En 2008, una publicación de IBM decía:
Con la popularidad y el crecimiento de TCP/IP, SNA está pasando de ser una verdadera arquitectura de red a ser lo que podría denominarse una "arquitectura de aplicación y acceso a aplicaciones". En otras palabras, hay muchas aplicaciones que aún necesitan comunicarse en SNA, pero los protocolos SNA necesarios se transmiten por la red mediante IP. [9]
Objetivos del SCN
A mediados de los años 70, IBM se consideraba principalmente un vendedor de hardware y, por lo tanto, todas sus innovaciones en ese período apuntaban a aumentar las ventas de hardware. El objetivo de SNA era reducir los costos de operación de grandes cantidades de terminales y, de esa manera, inducir a los clientes a desarrollar o expandir sistemas basados en terminales interactivos en lugar de sistemas por lotes . Una expansión de los sistemas basados en terminales interactivos aumentaría las ventas de terminales y, lo que es más importante, de computadoras mainframe y periféricos, en parte debido al simple aumento en el volumen de trabajo realizado por los sistemas y en parte porque el procesamiento interactivo requiere más potencia de procesamiento por transacción que el procesamiento por lotes.
Por tanto, el SNA se propuso reducir los principales costes no informáticos y otras dificultades que presentaba el funcionamiento de grandes redes utilizando protocolos de comunicación anteriores. Entre las dificultades se encontraban las siguientes:
A menudo, una línea de comunicaciones no podía ser compartida por terminales de distintos tipos, ya que utilizaban distintos "dialectos" de los protocolos de comunicación existentes. Hasta principios de los años 70, los componentes informáticos eran tan caros y voluminosos que no era posible incluir en los terminales tarjetas de interfaz de comunicaciones multipropósito. Cada tipo de terminal tenía una tarjeta de comunicaciones cableada que sólo admitía el funcionamiento de un tipo de terminal sin compatibilidad con otros tipos de terminales en la misma línea.
Los protocolos que manejaban las primitivas tarjetas de comunicaciones no eran eficientes. Cada línea de comunicaciones empleaba más tiempo en transmitir datos que las líneas modernas.
En aquella época, las líneas de telecomunicaciones eran de una calidad mucho menor. Por ejemplo, era casi imposible utilizar una línea de acceso telefónico a más de 19.200 bits por segundo debido a la abrumadora tasa de errores, en comparación con los 56.000 bits por segundo que hoy tienen las líneas de acceso telefónico; y a principios de los años 70, pocas líneas alquiladas funcionaban a más de 2.400 bits por segundo (estas bajas velocidades son consecuencia de la Ley de Shannon en un entorno de tecnología relativamente baja).
Como resultado, para operar un gran número de terminales se necesitaban muchas más líneas de comunicación que las que se requieren hoy en día, especialmente si era necesario dar soporte a distintos tipos de terminales o si los usuarios querían utilizar distintos tipos de aplicaciones (por ejemplo, bajo CICS o TSO) desde la misma ubicación. En términos puramente financieros, los objetivos de SNA eran aumentar el gasto de los clientes en sistemas basados en terminales y, al mismo tiempo, aumentar la participación de IBM en ese gasto, principalmente a expensas de las empresas de telecomunicaciones.
SNA también pretendía superar una limitación de la arquitectura que los mainframes System/370 de IBM heredaron del System/360 . Cada CPU podía conectarse a un máximo de 16 canales de E/S [10] y cada canal podía manejar hasta 256 periféricos, es decir, había un máximo de 4096 periféricos por CPU. En la época en que se diseñó SNA, cada línea de comunicaciones contaba como un periférico. Por lo tanto, el número de terminales con los que los mainframes potentes podían comunicarse era limitado.
Componentes principales y tecnologías
Las mejoras en la tecnología de los componentes informáticos hicieron posible la construcción de terminales que incluían tarjetas de comunicaciones más potentes que podían utilizar un único protocolo de comunicaciones estándar en lugar de un protocolo muy simplificado que sólo se adaptaba a un tipo específico de terminal. Como resultado, en la década de 1970 se propusieron varios protocolos de comunicaciones multicapa , de los cuales el SNA de IBM y el X.25 de la UIT-T se convirtieron más tarde en los dominantes.
Los elementos más importantes del SNA incluyen:
IBM Network Control Program (NCP) [11] [12] es un programa de comunicaciones que se ejecuta en los procesadores de comunicaciones 3705 y 37xx posteriores y que, entre otras cosas, implementa el protocolo de conmutación de paquetes definido por SNA. El protocolo realizaba dos funciones principales:
Es un protocolo de reenvío de paquetes, que actúa como un conmutador moderno : reenvía paquetes de datos al siguiente nodo, que puede ser un mainframe, una terminal u otro 3705. Los procesadores de comunicaciones solo admitían redes jerárquicas con un mainframe en el centro, a diferencia de los enrutadores modernos que admiten redes peer-to-peer en las que una máquina al final de la línea puede ser cliente y servidor al mismo tiempo.
Se trata de un multiplexor que conectaba múltiples terminales en una línea de comunicación con la CPU, aliviando así las restricciones sobre el número máximo de líneas de comunicación por CPU. Un 3705 podía soportar un mayor número de líneas (352 inicialmente) pero las CPU y los canales sólo lo contaban como un periférico. Desde el lanzamiento de SNA, IBM ha introducido procesadores de comunicaciones mejorados, de los cuales el último es el 3745 .
Control de enlace de datos sincrónico [13] (SDLC), un protocolo que mejoró enormemente la eficiencia de la transferencia de datos a través de un solo enlace: [14]
Es un protocolo de ventana deslizante , que permite a los terminales y procesadores de comunicaciones 3705 enviar tramas de datos una tras otra sin esperar un acuse de recibo de la trama anterior – las tarjetas de comunicaciones tenían suficiente memoria y capacidad de procesamiento para recordar las últimas 7 tramas enviadas o recibidas, solicitar la retransmisión sólo de aquellas tramas que contenían errores y colocar las tramas retransmitidas en el lugar correcto de la secuencia antes de reenviarlas a la siguiente etapa.
Todos estos marcos tenían el mismo tipo de envoltura (encabezado y final del marco) [15] que contenía suficiente información para que los paquetes de datos de diferentes tipos de terminales se enviaran a lo largo de la misma línea de comunicaciones, dejando que el mainframe se ocupara de cualquier diferencia en el formato del contenido o en las reglas que rigen los diálogos con diferentes tipos de terminales.
Los terminales remotos (por ejemplo, aquellos conectados a la computadora central mediante líneas telefónicas) y los procesadores de comunicaciones 3705 tendrían tarjetas de comunicaciones compatibles con SDLC.
Este es el precursor de la comunicación por paquetes que eventualmente evolucionó hasta convertirse en la tecnología TCP/IP actual [ cita requerida ] . El propio SDLC evolucionó hasta convertirse en HDLC , [16] una de las tecnologías base para circuitos de telecomunicaciones dedicados.
VTAM , [17] [18] un paquete de software para proporcionar servicios de inicio de sesión, mantenimiento de sesión y enrutamiento dentro del mainframe. Un usuario de terminal iniciaría sesión a través de VTAM en una aplicación o entorno de aplicación específico (por ejemplo, CICS , IMS , DB2 o TSO / ISPF ). Un dispositivo VTAM enrutaría entonces los datos desde ese terminal a la aplicación o entorno de aplicación apropiado hasta que el usuario cerrara la sesión y posiblemente iniciara sesión en otra aplicación. Las versiones originales del hardware de IBM solo podían mantener una sesión por terminal. En la década de 1980, otro software (principalmente de proveedores externos) hizo posible que un terminal tuviera sesiones simultáneas con diferentes aplicaciones o entornos de aplicación.
Ventajas y desventajas
SNA eliminó el control de enlaces del programa de aplicación y lo colocó en el NCP. Esto tuvo las siguientes ventajas y desventajas:
Ventajas
La localización de problemas en la red de telecomunicaciones era más sencilla porque una cantidad relativamente pequeña de software se ocupaba de los enlaces de comunicación y existía un único sistema de notificación de errores.
Agregar capacidad de comunicación a un programa de aplicación fue mucho más fácil porque el área formidable del software de control de enlace que normalmente requiere procesadores de interrupciones y temporizadores de software fue relegada al software del sistema y al NCP .
Con la llegada de la red avanzada entre pares (APPN), la funcionalidad de enrutamiento pasó a ser responsabilidad de la computadora, en lugar del enrutador (como en las redes TCP/IP). Cada computadora mantenía una lista de nodos que definían los mecanismos de reenvío. Un tipo de nodo centralizado, conocido como nodo de red, mantenía tablas globales de todos los demás tipos de nodos. APPN eliminó la necesidad de mantener tablas de enrutamiento de comunicación avanzada entre programas (APPC) que definían explícitamente la conectividad de punto final a punto. Las sesiones APPN se enrutaban a los puntos finales a través de otros tipos de nodos permitidos hasta que encontraban el destino. Esto es similar a la forma en que funcionan los enrutadores para el protocolo de Internet y el protocolo de intercambio de paquetes entre redes Netware . (APPN también se conoce a veces como PU2.1 o Unidad física 2.1. APPC, también conocido a veces como LU6.2 o Unidad lógica 6.2, fue el único protocolo definido para redes APPN, pero originalmente fue uno de los muchos protocolos compatibles con VTAM/NCP, junto con LU0, LU1, LU2 (Terminal 3270) y LU3. APPC se utilizó principalmente entre entornos CICS, así como servicios de bases de datos, porque contacta protocolos para el procesamiento de confirmación de 2 fases). Las unidades físicas eran PU5 (VTAM), PU4 (37xx), PU2 (Controlador de clúster). Un PU5 era el más capaz y se consideraba el principal en todas las comunicaciones. Otros dispositivos PU solicitaban una conexión del PU5 y el PU5 podía establecer la conexión o no. Los otros tipos de PU solo podían ser secundarios al PU5. Un PU2.1 agregó la capacidad a un PU2.1 de conectarse a otro PU2.1 en un entorno de igual a igual. [19] )
Se debía diseñar previamente y almacenar de forma centralizada un conjunto de rutas alternativas entre cada par de nodos de una red. La elección entre estas rutas por parte de SNA era rígida y no aprovechaba las cargas de enlace actuales para lograr una velocidad óptima.
La instalación y el mantenimiento de redes SNA son complicados y los productos de redes SNA son (o eran) caros. Los intentos de reducir la complejidad de las redes SNA añadiendo la funcionalidad de IBM Advanced Peer-to-Peer Networking no tuvieron mucho éxito, aunque sólo fuera porque la migración de SNA tradicional a SNA/APPN era muy compleja y no aportaba mucho valor añadido, al menos al principio. Las licencias de software SNA (VTAM) costaban hasta 10.000 dólares al mes para sistemas de gama alta, y los controladores de comunicaciones SNA IBM 3745 normalmente costaban más de 100.000 dólares. Hasta finales de los años 1980, TCP/IP todavía se consideraba inadecuado para aplicaciones comerciales, por ejemplo, en el sector financiero, pero rápidamente se impuso en los años 1990 gracias a su tecnología de redes peer-to-peer y comunicación por paquetes.
La arquitectura basada en conexión de SNA invocaba una lógica de máquina de estados enorme para realizar un seguimiento de todo. APPN agregó una nueva dimensión a la lógica de estados con su concepto de diferentes tipos de nodos. Si bien era sólido cuando todo funcionaba correctamente, aún existía la necesidad de intervención manual. Cosas simples como observar las sesiones de Control Point debían hacerse manualmente. APPN no estaba exento de problemas; en los primeros días, muchas empresas lo abandonaron debido a problemas encontrados en el soporte de APPN. Sin embargo, con el tiempo, muchos de los problemas se resolvieron, pero no antes de que TCP/IP se volviera cada vez más popular a principios de la década de 1990, lo que marcó el comienzo del fin de SNA.
Seguridad
En esencia, SNA fue diseñado con la capacidad de envolver diferentes capas de conexiones con un manto de seguridad. Para comunicarse dentro de un entorno SNA, primero debe conectarse a un nodo y establecer y mantener una conexión de enlace a la red. Luego, debe negociar una sesión adecuada y luego manejar los flujos dentro de la propia sesión. En cada nivel hay diferentes controles de seguridad que pueden gobernar las conexiones y proteger la información de la sesión. [20]
Unidades direccionables en red
Las unidades direccionables de red en una red SNA son todos los componentes a los que se les puede asignar una dirección y que pueden enviar y recibir información. Se distinguen además de la siguiente manera: [21]
Un punto de control de servicios del sistema (SSCP) proporciona gestión de recursos y otros servicios de sesión (como servicios de directorio) para usuarios en una red de subárea; [22]
Una unidad física es una combinación de componentes de hardware y software que controlan los enlaces a otros nodos. [23]
Una Unidad Lógica actúa como intermediario entre el usuario y la red. [24]
Unidad lógica (LU)
En esencia, SNA ofrece una comunicación transparente: características específicas del equipo que no imponen restricciones a la comunicación LU-LU. Sin embargo, en última instancia, resulta útil hacer una distinción entre los tipos de LU, ya que la aplicación debe tener en cuenta la funcionalidad del equipo terminal (por ejemplo, el tamaño y el diseño de la pantalla).
Dentro de SNA hay tres tipos de flujo de datos para conectar terminales de visualización locales e impresoras: está la cadena de caracteres SNA (SCS), utilizada para terminales LU1 y para iniciar sesión en una red SNA con servicios de sistema sin formato (USS), está el flujo de datos 3270 utilizado principalmente por mainframes como el System/370 y sucesores, incluida la familia zSeries , y el flujo de datos 5250 utilizado principalmente por minicomputadoras/servidores como el System/34 , System/36 , System/38 y AS/400 y sus sucesores, incluidos System i e IBM Power Systems que ejecutan IBM i .
SNA define varios tipos de dispositivos, llamados tipos de unidades lógicas: [25]
LU0 permite utilizar dispositivos no definidos o crear su propio protocolo. También se utiliza para dispositivos que no son SNA 3270 compatibles con TCAM o VTAM.
Los dispositivos LU1 son impresoras o combinaciones de teclados e impresoras.
Los dispositivos LU2 son terminales de pantalla IBM 3270.
Los dispositivos LU3 son impresoras que utilizan protocolos 3270.
Los dispositivos LU4 son terminales por lotes.
LU5 nunca ha sido definido.
LU6 proporciona protocolos entre dos aplicaciones.
LU7 permite realizar sesiones con terminales IBM 5250.
Los principales en uso son LU1, LU2 y LU6.2 (un protocolo avanzado para conversaciones de aplicación a aplicación).
Unidad Física (PU)
Los nodos PU1 son controladores de terminal como IBM 6670 o IBM 3767
Los nodos PU2 son controladores de clúster que ejecutan programas de soporte de configuración como IBM 3174 , IBM 3274 o IBM 4701 o IBM 4702 Branch Controller.
Los nodos VTAM/NCP PU4 conectados a redes IBM Token Ring pueden compartir la misma infraestructura de red de área local con estaciones de trabajo y servidores. NCP encapsula los paquetes SNA en tramas Token-Ring, lo que permite que las sesiones fluyan a través de una red Token-Ring. La encapsulación y desencapsulación reales se llevan a cabo en el 3745.
SNA sobre IP
A medida que las entidades basadas en mainframes buscaban alternativas a sus redes basadas en 37XX, IBM se asoció con Cisco a mediados de la década de 1990 y juntos desarrollaron Data Link Switching o DLSw. DLSw encapsula los paquetes SNA en datagramas IP, lo que permite que las sesiones fluyan a través de una red IP. La encapsulación y desencapsulación reales se llevan a cabo en enrutadores Cisco en cada extremo de una conexión entre pares DLSw. En el sitio local o mainframe, el enrutador utiliza la topología Token Ring para conectarse de forma nativa a VTAM. En el extremo remoto (usuario) de la conexión, un emulador PU tipo 2 (como un servidor de puerta de enlace SNA) se conecta al enrutador entre pares a través de la interfaz LAN del enrutador. Los terminales de usuario final suelen ser PC con software de emulación 3270 que se define para la puerta de enlace SNA. La definición de tipo 2 de PU VTAM/NCP se convierte en un nodo principal conmutado que puede ser local para VTAM (sin un NCP), y se puede definir una conexión de "línea" utilizando varias soluciones posibles (como una interfaz Token Ring en el 3745, una estación de canal Lan 3172 o un procesador de interfaz de canal compatible con Cisco ESCON ).
Competidores
La arquitectura de red patentada para los mainframes de Honeywell Bull es la arquitectura de sistemas distribuidos (DSA). [27] El paquete de comunicaciones para DSA es VIP . DSA ya no es compatible con el acceso de clientes. Los mainframes de Bull están equipados con Mainway para traducir DSA a TCP/IP y los dispositivos VIP se reemplazan por emulaciones de terminal TNVIP (GLink, Winsurf). GCOS 8 admite TNVIP SE sobre TCP/IP.
La arquitectura de red para los mainframes de Univac era la arquitectura de computación distribuida (DCA), y la arquitectura de red para los mainframes de Burroughs era la arquitectura de red de Burroughs (BNA); después de que se fusionaran para formar Unisys , ambas fueron proporcionadas por la empresa fusionada. Ambas quedaron prácticamente obsoletas en 2012. International Computers Limited (ICL) proporcionó su arquitectura de procesamiento de información (IPA).
SNA también compitió con la Interconexión de Sistemas Abiertos de ISO , que fue un intento de crear una arquitectura de red neutral respecto de los proveedores que fracasó debido a los problemas de " diseño por comité ". [ cita requerida ] Los sistemas OSI son muy complejos, y las muchas partes involucradas requirieron amplias flexibilidades que perjudicaron la interoperabilidad de los sistemas OSI, que era el objetivo principal para empezar. [ cita requerida ]
Durante muchos años, IBM no consideró que la suite TCP/IP fuera una alternativa seria, en parte debido a la falta de control sobre la propiedad intelectual. [ cita requerida ] La publicación en 1988 de RFC 1041, escrita por Yakov Rekhter , que define una opción para ejecutar sesiones IBM 3270 sobre Telnet , reconoce explícitamente la demanda de los clientes de interoperabilidad en el centro de datos. Posteriormente, el IETF amplió este trabajo con múltiples otras RFC. TN3270 (Telnet 3270), definido por esas RFC, admite conexiones directas de cliente-servidor al mainframe utilizando un servidor TN3270 en el mainframe y un paquete de emulación TN3270 en la computadora en el sitio del usuario final. Este protocolo permite que las aplicaciones VTAM existentes (CICS, TSO) se ejecuten con poco o ningún cambio con respecto al SNA tradicional al admitir el protocolo de terminal 3270 tradicional sobre la sesión TCP/IP. Este protocolo se utiliza ampliamente para reemplazar la conectividad SNA heredada más que la conmutación de enlace de datos (DLSw) y otras tecnologías de reemplazo de SNA. Existe una variante similar de TN5250 (Telnet 5250) para IBM 5250 .
Implementaciones de SNA que no son de IBM
El software SNA no IBM permitió que sistemas distintos a los de IBM se comunicaran con los mainframes y las computadoras de rango medio AS/400 de IBM utilizando los protocolos SNA.
Algunos proveedores de sistemas Unix, como Sun Microsystems con su línea de productos SunLink SNA, incluido PU2.1 Server, [31] y Hewlett-Packard / Hewlett Packard Enterprise , con su producto SNAplus2, [32] proporcionaron software SNA.
Digital Equipment Corporation tenía VMS/SNA para VMS . [34] También estaban disponibles paquetes de software SNA de terceros para VMS, como los productos VAX Link de Systems Strategies, Inc., [34] .
Hewlett-Packard ofreció SNA Server y SNA Access para sus sistemas HP 3000. [35]
Brixton Systems desarrolló varios paquetes de software SNA, vendidos bajo el nombre "Brixton ", [36] [37] [38] como Brixton BrxPU21, BrxPU5, BrxLU62 y BrxAPPC, para sistemas como estaciones de trabajo de Hewlett-Packard , [39] y Sun Microsystems . [40]
IBM admitió el uso de varias implementaciones de software no IBM de APPC/PU2.1/LU6.2 para comunicarse con z/OS , incluyendo SNAplus2 para sistemas de HP , [41] Brixton 4.1 SNA para Sun Solaris , [42] y SunLink SNA 9.1 Support para Sun Solaris. [43]
^ Peter H. Lewis (14 de mayo de 1989). «Un vínculo para todos los sistemas operativos». The New York Times . Consultado el 15 de septiembre de 2022 .
^ (Schatt 1991, pág. 227).
^ IBM Corporation. «IBM Highlights, 1970-1984» (PDF) . IBM . Consultado el 19 de abril de 2019 .
^ IBM 3770 Family Batch Communications Terminal (PDF) (Informe). Datapro. y el sistema de entrada de datos/comunicaciones de datos 3790/3760...
^ "Conecte sus sistemas heredados a la Web". Datamation .
^ "Arquitectura Net de Fujitsu". Computerworld . 15 de noviembre de 1976. pág. 99.
^ RJ Sundstrom (1987), "SNA: avances recientes y requisitos adicionales", Networking in Open Systems , Notas de clase en informática, vol. 248, Springer Publishing , págs. 107-116, doi :10.1007/BFb0026957, ISBN3-540-17707-8
^ "AT&T describe un plan de migración a VPN". Informationweek . 12 de mayo de 1999 . Consultado el 16 de septiembre de 2022 .
^ Redes en z/OS (PDF) . IBM Corporation. 2010. pág. 31. "Redes en z/OS (documento web)". IBM Corporation.
^ dispositivos que actuaban como controladores DMA para unidades de control, que a su vez conectaban periféricos como unidades de cinta y disco, impresoras y lectores de tarjetas
^ "Capas funcionales de SNA". Microsoft Docs . Microsoft. 11 de septiembre de 2008 . Consultado el 16 de septiembre de 2022 .
^ WS Hobgood (1976). "El papel del programa de control de red en la arquitectura de redes de sistemas" (PDF) . IBM Systems Journal . 15 (1): 39–52. doi :10.1147/sj.151.0039. Archivado desde el original (PDF) el 16 de marzo de 2007 . Consultado el 26 de agosto de 2006 .
^ Conceptos de control de enlace de datos síncrono (PDF) (Quinta edición). IBM. Mayo de 1992. GA27-3093-4.
^ (Pooch, Greene y Moss 1983, pág. 310).
^ (Pooch, Greene y Moss 1983, pág. 313).
^ (Friend et al. 1988, pág. 191).
^ Frank, Ronald A (17 de octubre de 1973). "IBM retrasa el lanzamiento de la segunda TP virtual; se espera un impacto en SD:C". Computerworld . Consultado el 30 de junio de 2020 .
^ Introducción a VTAM (PDF) . IBM. Abril de 1976. GC27-6987-5.
^ Guías de referencia de la arquitectura de red de sistemas IBM y APPN PU2.1
^ Buecker, Axel; et al. (2015). Reducir el riesgo y mejorar la seguridad en mainframes de IBM: Volumen 2 Seguridad de redes y comunicaciones de mainframes. IBM Corporation. p. 132. ISBN978-0738440941. Recuperado el 23 de abril de 2019 .
^ Términos y conceptos básicos del SCN
^ "z/OS Communications Server: Guía de implementación de red SNA (6)". IBM Knowledge Center . IBM Corporation . Consultado el 3 de octubre de 2015 .
^ "z/OS Communications Server: Guía de implementación de red SNA (11)". IBM Knowledge Center . IBM Corporation. 11 de septiembre de 2014 . Consultado el 3 de octubre de 2015 .
^ "z/OS Communications Server: Guía de implementación de red SNA (12)". IBM Knowledge Center . IBM Corporation. 11 de septiembre de 2014 . Consultado el 3 de octubre de 2015 .
^ (Schatt 1991, pág. 229).
^ Microsoft. «Unidad física (PU)» . Consultado el 7 de septiembre de 2012 .
^ "Arquitectura de sistemas distribuidos".
^ James M. Moran; Brian J. Edwards (febrero de 1984). "Darle a DECnet una LAN". Copia impresa . págs. 62–65.
^ "DECnet para Linux". SourceForge . Archivado desde el original el 4 de octubre de 2009. Consultado el 26 de junio de 2018 .
^ "Productos de redes introducidos por Digital". The New York Times . 24 de agosto de 1988.
^ Guía de configuración del servidor SunLink SNA 9.1 PU2.1 (PDF) . Sun Microsystems . 1997.
^ "Software HP-UX SNAplus2: descripción general". Soporte de HPE .
^ Willett, Shawn; Wilson, Jayne (22 de noviembre de 1993). "Microsoft, Novell e IBM apuntan a los enlaces host-a-LAN". InfoWorld . Vol. 15, núm. 47. pág. 39.
^ ab Gonze, Josh (25 de abril de 1988). "Cómo encontrar una conexión DEC-to-IBM". Network World . p. 28. VMS/SNA, software que se ejecuta bajo VMS junto con una placa síncrona, en un VAX configurado con un BIbus, hace que un solo VAX aparezca como un nodo PU 2.
^ "Las ofertas de software acompañan al anuncio de Spectrum". Computerworld . Vol. 20, no. 9. 3 de marzo de 1986. p. 10. HP también presentó las capacidades de conexión de IBM con el software de acceso a servidores y servidores de arquitectura de redes de sistemas (SNA).
^ Brixton SNA Server: software certificado por Red Hat
^ "Sistemas CNT/Brixton". Network World . 31 de julio de 1995.
^ Brixton PU2.1 SNA Server , consultado el 14 de septiembre de 2022
^ Cooney, Michael (29 de noviembre de 1993). "Brixton convierte las estaciones de trabajo HP en alternativas a los mainframes". Network World . Vol. 10, núm. 48. pág. 15.
^ Orrange, Kate (9 de marzo de 1992). "Brixton expande la conexión IBM/Sun". InfoWorld . Vol. 14, núm. 10. pág. 41.
^ "Requisitos de configuración de HP SNAplus2". IBM .
^ "Requisitos de Brixton 4.1 SNA para Sun Solaris". IBM .
^ "Configuración de la compatibilidad de SunLink SNA 9.1 con Sun Solaris". IBM .
Referencias
Friend, George E.; Fike, John L.; Baker, H. Charles; Bellamy, John C. (1988). Entendiendo las comunicaciones de datos (2.ª ed.). Indianápolis: Howard W. Sams & Company. ISBN 0-672-27270-9.
Pooch, Udo W.; Greene, William H.; Moss, Gary G. (1983). Telecomunicaciones y redes . Boston: Little, Brown and Company. ISBN 0-316-71498-4.
Schatt, Stan (1991). Vinculación de redes LAN: una guía para microadministradores . McGraw-Hill. ISBN 0-8306-3755-9.
Información general sobre arquitectura de redes de sistemas (PDF) . Primera edición. IBM. Enero de 1975. GA27-3102-0.
Conceptos y productos de arquitectura de sistemas y redes (PDF) . Segunda edición. IBM. Febrero de 1984. GC30-3072-1.
Descripción técnica de la arquitectura de redes de sistemas. Quinta edición. IBM. Enero de 1994. GC30-3073-04.
Guía de arquitectura de sistemas de redes para publicaciones de SNA. Tercera edición. IBM. Julio de 1994. GC30-3438-02.
Enlaces externos
Artículo de Cisco sobre SNA
Repositorio de documentos de arquitectura del taller de implementadores de APPN
Los protocolos SNA son bastante técnicos
Documentos técnicos relacionados sdsusa.com
Resumen de funciones avanzadas para sistemas de comunicaciones (PDF) . Segunda edición. IBM. Julio de 1975. GA27-3099-1 . Consultado el 22 de mayo de 2014 .
Formatos de arquitectura de sistemas y redes (PDF) . Vigésima primera edición. IBM. Marzo de 2004. GA27-3136-20.
Arquitectura de redes de sistemas: sesiones entre unidades lógicas (PDF) . Tercera edición. IBM. Abril de 1981. GC20-1868-2.
Arquitectura de redes de sistemas: Introducción a las sesiones entre unidades lógicas (PDF) . Tercera edición. IBM. Diciembre de 1979. GC20-1869-2.
Manual de referencia de protocolos y formatos de arquitectura de redes de sistemas: lógica arquitectónica (PDF) . Tercera edición. IBM. Noviembre de 1980. SY20-3112-2.
Arquitectura de redes de sistemas: Manual de referencia del programador de transacciones para LU tipo 6.2. Sexta edición. IBM. Junio de 1993. GC30-3084-05.
Referencia de nodos de tipo 2.1 de arquitectura de redes de sistemas. Quinta edición. IBM. Diciembre de 1996. SC30-3422-04.
Arquitectura de redes de sistemas LU 6.2 Referencia: Protocolos entre pares. Tercera edición. IBM. Octubre de 1996. SC31-6808-02.
.jpg/1280px-Tapes_and_IBM_3745-170_(13889447458).jpg)