stringtranslate.com

X.25

X.25 es un conjunto de protocolos estándar ITU-T para la comunicación de datos conmutados por paquetes en redes de área amplia (WAN). Fue definido originalmente por el Comité Consultivo Internacional de Telégrafos y Teléfonos (CCITT, ahora UIT-T) en una serie de borradores y finalizado en una publicación conocida como El Libro Naranja en 1976. [1] [2]

El conjunto de protocolos está diseñado como tres capas conceptuales, que se corresponden estrechamente con las tres capas inferiores del modelo de referencia OSI de siete capas , aunque se desarrolló varios años antes que el modelo OSI (1984). [3] [4] También admite funciones que no se encuentran en la capa de red OSI . [5] [6] Una WAN X.25 consta de nodos de intercambio de conmutación de paquetes (PSE) como hardware de red y líneas arrendadas , conexiones de servicio telefónico antiguas o conexiones RDSI como enlaces físicos.

X.25 fue popular entre las empresas de telecomunicaciones por sus redes públicas de datos desde finales de los años 1970 hasta los años 1990, que proporcionaban cobertura mundial. También se utilizó en sistemas de transacciones financieras , como cajeros automáticos , y en la industria de pagos con tarjeta de crédito. [7] Sin embargo, desde entonces la mayoría de los usuarios se han trasladado al conjunto de protocolos de Internet (TCP/IP). X.25 todavía se utiliza, por ejemplo, en la industria de la aviación.

Historia

Representantes de PTT y empresas privadas que defendieron el desarrollo de redes y servicios basados ​​en X.25 en Europa, América del Norte y Japón. Fotografiado en la reunión del grupo de Relator del CCITT de marzo de 1975 en Ottawa, donde redactaron la primera propuesta X.25.
Principales contribuyentes al CCITT X.25, fotografiados justo después de su aprobación en marzo de 1976.

El CCITT (más tarde UIT-T ), la organización responsable de la estandarización internacional de los servicios de telecomunicaciones, comenzó a desarrollar un estándar para la comunicación de datos conmutados por paquetes a mediados de la década de 1970 basándose en una serie de proyectos de redes de datos emergentes. [8] Entre los participantes en el diseño de X.25 se encontraban ingenieros de Canadá, Francia, Japón, Reino Unido y Estados Unidos, que representaban una combinación de PTT nacionales (Francia, Japón, Reino Unido) y operadores privados (Canadá, Estados Unidos). En particular, el trabajo de Rémi Després contribuyó significativamente a la norma, que se basó en un servicio de circuito virtual . Se realizaron algunos cambios menores, que complementaron la especificación propuesta, para permitir que Larry Roberts se uniera al acuerdo. [9] [10] [11] Se incorporaron varias actualizaciones y adiciones al estándar, que finalmente se registraron en la serie de libros técnicos de la UIT que describen los sistemas de telecomunicaciones. Estos libros se publicaban cada cuatro años con cubiertas de diferentes colores. La especificación X.25 es parte del conjunto más grande de la Serie X. [12] [13]

Cómo el CCITT estandarizó los circuitos virtuales

El CCITT nombró un Relator Especial sobre conmutación de paquetes, Halvor Bothner-By , quien celebró una reunión inicial en enero de 1974. Esto dio lugar a una pregunta, que fue respondida por la Comisión de Estudio (SG) VII para la próxima sesión plenaria del CCITT en 1976, que fue “¿Debería proporcionarse el nodo de paquete de operación en redes públicas de datos y, en caso afirmativo, cómo debería implementarse?”. Se proporcionó una lista de redes de conmutación de paquetes “a considerar”: ARPANET (de la ARPA en EE.UU.), EIN (de la europea COST), [14] EPSS (de la British Post Office Telecommunications ), RCP (de la francesa PTT ), CYCLADES (de IRIA en Francia), la red NPL (de NPL en el Reino Unido), la red SWIFT (de la sociedad internacional SWIFT ) y la red SITA (de la empresa internacional SITA ). [15]

La segunda reunión de Relatores, organizada en Oslo por la Administración de Telecomunicaciones de Noruega en noviembre de 1974, reunió a 24 participantes, incluidos representantes de otras organizaciones internacionales ( ISO , IFIP , ECMA ). [16] Un documento presentado por Francia “con el apoyo activo de varias administraciones europeas” sirvió como “principal base para el debate en esta reunión”. Luego se “acordó que deberían considerarse dos tipos de servicios: un servicio de 'datagramas' y un servicio de 'llamada virtual'”. [16] :p3 

En la tercera reunión, la atención pasó de si deberían existir redes en modo paquete a si podría haber “un estándar para la interfaz entre la red y las computadoras”. [8] : p39 

A partir de enero de 1975, se celebraron varias reuniones bilaterales y multilaterales entre operadores de redes que tenían compromisos para un servicio de conmutación de paquetes, con vistas a redactar una especificación de interfaz común. Las reuniones comenzaron entre la canadiense DATAPAC y la francesa TRANSPAC , continuaron con la startup Telenet de EE. UU. y continuaron con la BPO del Reino Unido. [8] : p39  [17] : p44 

En marzo de 1975, Halvor Bothner-By elaboró ​​una lista de recomendaciones que debían crearse, o simplemente actualizarse, para que fuera posible un estándar de conmutación de paquetes. Se utilizó como marco en una reunión de redacción celebrada en Ottawa entre los ingenieros de los cuatro operadores que deseaban disponer de una norma lo antes posible en EE.UU., Canadá, Francia, Reino Unido y Japón. Prepararon contribuciones que las administraciones con derecho de voto en el CCITT presentarán a la CE VII en su nombre. Una contribución fue una especificación de interfaz X.2x, la primera versión de lo que será X.25). [18] [19]

La cuarta reunión de Relatores, celebrada en mayo de 1975 en Ginebra, contó con 45 participantes y 27 documentos nuevos. El Relator preguntó si deberían emitirse recomendaciones sobre conmutación de paquetes "con miras a hacer posible el interfuncionamiento internacional", "la administración francesa respondió afirmativamente y Canadá apoyó firmemente la propuesta francesa". Sin embargo, aún no se ha llegado a una conclusión firme. [20]

La quinta reunión de Relatores, celebrada en septiembre de 1975 en Ginebra, contó con unos 60 participantes. Después de las discusiones sobre la interfaz del circuito virtual propuesta, quedaron numerosas cuestiones sin resolver. [8] : p40  Con respecto a los datagramas, 'Larry Roberts de la delegación de EE. UU. propuso, con el apoyo de representantes de Francia y Canadá respectivamente, que la clasificación de los datagramas se cambiara de “E” a “A”', es decir, de esencial "a estar disponible internacionalmente” hasta agregar que “puede estar disponible en ciertos países e internacionalmente”. [21] El último informe del Relator expresó dudas “de que una norma esté lista para ser adoptada por el SG VII”. [8] : p40 

En la última reunión del pleno del CE VII antes del pleno del CCITT de septiembre de 1976, el proyecto X.25 disponible planteó numerosas cuestiones aclaratorias y/o objeciones técnicas. El presidente del SG VII, Vern MacDonald, nombró un editor y proporcionó un lugar para reuniones durante el fin de semana. Después de un intenso trabajo durante el mismo, se solucionaron todos los problemas. Para la aprobación por parte del grupo de estudio en pleno, aún quedaba un desafío: las copias del borrador X.25 actualizado tenían que estar disponibles en dos idiomas. Para conseguirlos a su debido tiempo, Anton Rybzynski de DATAPAC y Paul Guinaudeau de TRANSPAC pasaron una noche entera escribiendo a mano todas las enmiendas negociadas y uniéndolas con pasta y tijeras para convertirlas en documentos limpios. Luego, el COM VII revisó las copias distribuidas y las aprobó por unanimidad para su presentación en la próxima sesión plenaria del CCITT. [17] En este plenario de septiembre de 1976, la recomendación X.25 y las otras 10 del SG VII fueron aprobadas por unanimidad. [8] : p40 

A petición de EE.UU., se añadió un servicio de datagramas opcional al X.25 revisado de 1980, junto con una alineación de su capa de enlace, ahora denominada LAPB, con una evolución reciente de HDLC en ISO . A falta de que ningún operador de red pública implementara esta opción, los datagramas finalmente se eliminaron de X.25 en su actualización de 1984. [8] : p41 

Redes de datos públicas mundiales

Las redes X.25 de acceso público, comúnmente llamadas redes públicas de datos , se establecieron en muchos países a finales de los años 1970 y 1980 para reducir el costo de acceso a diversos servicios en línea . Los ejemplos incluyen Iberpac , TRANSPAC , Compuserve , Tymnet , Telenet , Euronet , PSS , Datapac , Datanet 1 y AUSTPAC , así como el Servicio Internacional de Conmutación de Paquetes . Su red combinada tuvo una gran cobertura global durante los años 1980 y 1990. [22]

A principios de la década de 1990, en América del Norte, el uso de redes X.25 (predominadas por Telenet y Tymnet) [22] comenzó a ser reemplazado por servicios Frame Relay ofrecidos por compañías telefónicas nacionales. [23] La mayoría de los sistemas que requerían X.25 ahora usan TCP/IP , sin embargo, es posible transportar X.25 a través de TCP/IP cuando sea necesario. [24]

Las redes X.25 todavía se utilizan en todo el mundo. Una variante llamada AX.25 es ampliamente utilizada por los radioaficionados por paquetes . Racal Paknet, ahora conocido como Widanet, sigue funcionando en muchas regiones del mundo y funciona sobre una base de protocolo X.25. En algunos países, como los Países Bajos o Alemania, es posible utilizar una versión simplificada de X.25 a través del canal D de una conexión RDSI -2 (o RDSI BRI ) para aplicaciones de bajo volumen, como puntos de venta. terminales; pero el futuro de este servicio en los Países Bajos es incierto.

X.25 todavía se utiliza en el negocio aeronáutico (especialmente en Asia), aunque la transición a protocolos modernos como X.400 no tiene opción, ya que el hardware X.25 se vuelve cada vez más raro y costoso. [ se necesita aclaración ] Tan recientemente como marzo de 2006, la Red Nacional de Intercambio de Datos del Espacio Aéreo de los Estados Unidos ha utilizado X.25 para interconectar aeródromos remotos con centros de control de tráfico de rutas aéreas .

Francia fue uno de los últimos países donde funcionó el servicio comercial de usuario final basado en X.25. Conocido como Minitel , estaba basado en Videotex , que a su vez funcionaba en X.25. En 2002, Minitel tenía alrededor de 9 millones de usuarios, y en 2011 contaba con alrededor de 2 millones de usuarios en Francia cuando France Télécom anunció que cerraría el servicio antes del 30 de junio de 2012. [25] Tal como estaba previsto, el servicio finalizó el 30 de junio de 2012. En aquel momento había 800.000 terminales en funcionamiento. [26] En 2019 todavía se podía adquirir un servicio X.25 de BT en el Reino Unido. [27]

Arquitectura

El concepto general del X.25 era crear una red de conmutación de paquetes universal y global . Gran parte del sistema X.25 es una descripción de la rigurosa corrección de errores necesaria para lograrlo, así como de un intercambio más eficiente de recursos físicos intensivos en capital.

La especificación X.25 define únicamente la interfaz entre un abonado (DTE) y una red X.25 (DCE). X.75 , un protocolo muy similar a X.25, define la interfaz entre dos redes X.25 para permitir que las conexiones atraviesen dos o más redes. X.25 no especifica cómo funciona la red internamente: muchas implementaciones de red X.25 utilizaron algo muy similar a X.25 o X.75 internamente, pero otras utilizaron protocolos bastante diferentes internamente. El protocolo ISO equivalente a X.25, ISO 8208, es compatible con X.25, pero además incluye la posibilidad de conectar dos DTE X.25 directamente entre sí sin ninguna red intermedia. Al separar el protocolo de capa de paquetes , ISO 8208 permite la operación en redes adicionales como ISO 8802 LLC2 (ISO LAN) y la capa de enlace de datos OSI. [28]

X.25 definió originalmente tres niveles de protocolo básicos o capas arquitectónicas. En las especificaciones originales, estos se denominaban niveles y también tenían un número de nivel, mientras que todas las recomendaciones ITU-T X.25 y los estándares ISO 8208 publicados después de 1984 se refieren a ellos como capas . [29] Los números de capa se eliminaron para evitar confusión con las capas del modelo OSI. [1]

El modelo X.25 se basó en el concepto de telefonía tradicional de establecer circuitos confiables a través de una red compartida, pero utilizando software para crear " llamadas virtuales " a través de la red. Estas llamadas interconectan "equipos terminales de datos" (DTE) proporcionando puntos finales a los usuarios, que parecían conexiones punto a punto . Cada punto final puede establecer muchas llamadas virtuales independientes a diferentes puntos finales.

Durante un breve período, la especificación también incluyó un servicio de datagramas sin conexión, pero se eliminó en la siguiente revisión. La "función de selección rápida con respuesta restringida" es intermedia entre el establecimiento completo de la llamada y la comunicación sin conexión. Se utiliza ampliamente en aplicaciones de transacciones de consulta-respuesta que implican una única solicitud y respuesta limitada a 128 bytes de datos transportados en cada sentido. Los datos se transportan en un paquete de solicitud de llamada extendida y la respuesta se transporta en un campo extendido del paquete de rechazo de llamada, sin que nunca se establezca completamente la conexión.

Estrechamente relacionados con el protocolo X.25 están los protocolos para conectar dispositivos asíncronos (como terminales tontos e impresoras) a una red X.25: X.3 , X.28 y X.29 . Esta funcionalidad se realizaba mediante un ensamblador/desensamblador de paquetes o PAD (también conocido como dispositivo triple-X , en referencia a los tres protocolos utilizados).

Relación con el modelo de referencia OSI

Aunque X.25 es anterior al modelo de referencia OSI (OSIRM), la capa física del modelo OSI corresponde a la capa física X.25 , la capa de enlace de datos a la capa de enlace de datos X.25 y la capa de red a la capa X.25. Capa de 25 paquetes . [13] La capa de enlace de datos X.25 , LAPB , proporciona una ruta de datos confiable a través de un enlace de datos (o múltiples enlaces de datos paralelos, multienlace) que puede no ser confiable en sí mismo. La capa de paquetes X.25 proporciona los mecanismos de llamada virtual, ejecutándose sobre X.25 LAPB . La capa de paquete incluye mecanismos para mantener llamadas virtuales y señalar errores de datos en el caso de que la capa de enlace de datos no pueda recuperarse de los errores de transmisión de datos. Todas, excepto las primeras versiones de X.25, incluyen funciones [30] que proporcionan direccionamiento de capa de red OSI (direccionamiento NSAP, ver más abajo). [31]

Soporte de dispositivo de usuario

Un terminal de Televideo modelo 925 fabricado alrededor de 1982.

X.25 se desarrolló en la era de los terminales informáticos que se conectaban a ordenadores host, aunque también se puede utilizar para comunicaciones entre ordenadores. En lugar de marcar directamente "a" la computadora anfitriona (lo que requeriría que la anfitriona tuviera su propio conjunto de módems y líneas telefónicas, y requeriría que las personas que llaman no locales hicieran llamadas de larga distancia), la anfitriona podría tener una conexión X.25 a un proveedor de servicios de red. Ahora los usuarios de terminales tontos podrían marcar al “PAD” local de la red ( instalación de ensamblaje/desensamblaje de paquetes ), un dispositivo de puerta de enlace que conecta módems y líneas seriales al enlace X.25 según lo definido por los estándares X.29 y X.3 .

Una vez conectado al PAD, el usuario del terminal tonto le dice al PAD a qué host conectarse, dándole una dirección similar a un número de teléfono en el formato de dirección X.121 (o dando un nombre de host, si el proveedor de servicios lo permite). nombres que se asignan a direcciones X.121 ). Luego, el PAD realiza una llamada X.25 al host, estableciendo una llamada virtual . Tenga en cuenta que X.25 proporciona llamadas virtuales, por lo que parece ser una red de conmutación de circuitos , aunque en realidad los datos en sí se conmutan por paquetes internamente, de forma similar a la forma en que TCP proporciona conexiones, aunque los datos subyacentes se conmutan por paquetes. Por supuesto, dos hosts X.25 podrían llamarse entre sí directamente; En este caso no hay ningún PAD involucrado. En teoría, no importa si la persona que llama X.25 y el destino X.25 están conectados al mismo operador, pero en la práctica no siempre fue posible realizar llamadas de un operador a otro.

Para fines de control de flujo, se utiliza un protocolo de ventana deslizante con el tamaño de ventana predeterminado de 2. Los acuses de recibo pueden tener significado local o de extremo a extremo. El bit AD (bit de entrega de datos) en cada paquete de datos indica si el remitente requiere un acuse de recibo de un extremo a otro. Cuando D=1, significa que el acuse de recibo tiene significado de extremo a extremo y debe tener lugar sólo después de que el DTE remoto haya acusado recibo de los datos. Cuando D=0, a la red se le permite (pero no se le exige) reconocer antes de que el DTE remoto haya reconocido o incluso recibido los datos.

Si bien la función PAD definida por X.28 y X.29 admitía específicamente terminales de caracteres asíncronos, se desarrollaron equivalentes de PAD para admitir una amplia gama de dispositivos de comunicaciones inteligentes propietarios, como los de IBM System Network Architecture (SNA).

control de errores

Los procedimientos de recuperación de errores en la capa de paquete suponen que la capa de enlace de datos es responsable de retransmitir los datos recibidos por error. El manejo de errores de la capa de paquetes se centra en resincronizar el flujo de información en las llamadas, así como en borrar las llamadas que han entrado en estados irrecuperables:

Direccionamiento y circuitos virtuales.

Un módem X.25 que alguna vez se usó para conectarse a la red alemana Datex-P

X.25 admite dos tipos de circuitos virtuales ; llamadas virtuales (VC) y circuitos virtuales permanentes (PVC). Las llamadas virtuales se establecen según sea necesario. Por ejemplo, un VC se establece cuando se realiza una llamada y se cancela una vez completada la llamada. Los VC se establecen mediante un procedimiento de establecimiento y compensación de llamadas. Por otro lado, los circuitos virtuales permanentes están preconfigurados en la red. [32] Los PVC rara vez se derriban y, por lo tanto, proporcionan una conexión dedicada entre los puntos finales.

La VC se puede establecer utilizando direcciones X.121. La dirección X.121 consta de un código de país de datos (DCC) de tres dígitos más un dígito de red, que juntos forman el código de identificación de red de datos (DNIC) de cuatro dígitos, seguido del número de terminal nacional (NTN) de como máximo diez dígitos. . Tenga en cuenta el uso de un solo dígito de red, lo que aparentemente permite solo 10 operadores de red por país, pero a algunos países se les asigna más de un DCC para evitar esta limitación. Las redes a menudo usaban menos de los dígitos NTN completos para el enrutamiento y ponían los dígitos de repuesto a disposición del suscriptor (a veces llamados subdirección) donde podían usarse para identificar aplicaciones o para un enrutamiento adicional en las redes de los suscriptores.

La función de direccionamiento NSAP se agregó en la revisión X.25 (1984) de la especificación, y esto permitió que X.25 cumpliera mejor con los requisitos del servicio de red orientado a la conexión (CONS) OSI . [33] Las redes públicas X.25 no estaban obligadas a utilizar el direccionamiento NSAP, pero, para admitir OSI CONS, debían transportar las direcciones NSAP y otras instalaciones DTE especificadas por el UIT-T de forma transparente de DTE a DTE. [34] Las revisiones posteriores permitieron que se transportaran múltiples direcciones además de las direcciones X.121 en la misma interfaz DTE-DCE: direccionamiento télex ( F.69 ), direccionamiento PSTN ( E.163 ), direccionamiento RDSI ( E.164 ), Direcciones de protocolo de Internet (IANA ICP) y direcciones MAC locales IEEE 802.2 . [35]

Los PVC están establecidos permanentemente en la red y, por lo tanto, no requieren el uso de direcciones para el establecimiento de llamadas. Los PVC se identifican en la interfaz del abonado mediante su identificador de canal lógico (ver más abajo). Sin embargo, en la práctica no muchas de las redes nacionales X.25 soportaban PVC.

Una interfaz DTE-DCE para una red X.25 tiene un máximo de 4095 canales lógicos en los que se permite establecer llamadas virtuales y circuitos virtuales permanentes, [36] aunque no se espera que las redes admitan 4095 circuitos virtuales completos. [37] Para identificar el canal al que está asociado un paquete, cada paquete contiene un identificador de canal lógico de 12 bits compuesto por un número de canal lógico de 8 bits y un número de grupo de canales lógicos de 4 bits. [36] Los identificadores de canal lógico permanecen asignados a un circuito virtual mientras dure la conexión. [36] Los identificadores de canal lógico identifican un canal lógico específico entre el DTE (dispositivo de abonado) y el DCE (red), y solo tienen significado local en el enlace entre el abonado y la red. Es probable que al otro extremo de la conexión en el DTE remoto se le haya asignado un identificador de canal lógico diferente. La gama de posibles canales lógicos se divide en 4 grupos: canales asignados a circuitos virtuales permanentes, asignados a llamadas virtuales entrantes, llamadas virtuales bidireccionales (entrantes o salientes) y llamadas virtuales salientes. [38] (Las direcciones se refieren a la dirección de inicio de llamada virtual vista por el DTE; todas transportan datos en ambas direcciones). [39] Los rangos permitieron configurar a un suscriptor para manejar números significativamente diferentes de llamadas en cada dirección mientras reservando algunos canales para llamadas en una dirección. Todas las redes Internacionales están obligadas a implementar soporte para circuitos virtuales permanentes, canales lógicos bidireccionales y canales lógicos unidireccionales de salida; Los canales lógicos unidireccionales entrantes son una facilidad opcional adicional. [40] No es necesario que las interfaces DTE-DCE admitan más de un canal lógico. [38] El identificador cero del canal lógico no se asignará a un circuito virtual permanente o a una llamada virtual. [41] El identificador de canal lógico cero se utiliza para paquetes que no se relacionan con un circuito virtual específico (por ejemplo, paquetes de diagnóstico, registro y reinicio de capa de paquete).

Facturación

En las redes públicas, X.25 normalmente se facturaba como una tarifa de servicio mensual fija dependiendo de la velocidad del enlace, y luego un precio por segmento además de esto. [42] Las velocidades de enlace variaban, típicamente desde 2400 bit/s hasta 2 Mbit/s, aunque velocidades superiores a 64 kbit/s eran poco comunes en las redes públicas. Un segmento constaba de 64 bytes de datos (redondeados hacia arriba, sin transferencia entre paquetes), [43] cargados a la persona que llama [44] (o al destinatario en el caso de llamadas con cobro invertido, cuando sea compatible). [45] Las llamadas que invocan la función de selección rápida (que permite 128 bytes de datos en las fases de solicitud de llamada, confirmación de llamada y liberación de llamada) [46] generalmente generarían un cargo adicional, al igual que el uso de algunas de las otras funciones X.25. Los PVC tendrían un cargo de alquiler mensual y un precio por segmento más bajo que los VC, lo que los haría más baratos sólo cuando se transfieren grandes volúmenes de datos.

Tipos de paquetes X.25

Detalles del X.25

La red puede permitir la selección de la longitud máxima en el rango de 16 a 4096 octetos (sólo 2 n valores) por circuito virtual mediante negociación como parte del procedimiento de establecimiento de llamada. La longitud máxima puede ser diferente en los dos extremos del circuito virtual.

Instalaciones X.25

X.25 proporciona un conjunto de facilidades de usuario definidas y descritas en la Recomendación UIT-T X.2. [47] Las facilidades de usuario X.2 se dividen en cinco categorías:

X.25 también proporciona facilidades opcionales de usuario DTE especificadas por X.25 y UIT-T, definidas y descritas en la Recomendación UIT-T X.7. [48] ​​Las facilidades opcionales de usuario X.7 se dividen en cuatro categorías de facilidades de usuario que requieren:

Versiones del protocolo X.25

Las versiones CCITT/ITU-T de las especificaciones del protocolo son para redes públicas de datos (PDN). [49] Las versiones ISO/IEC abordan características adicionales para redes privadas (por ejemplo, uso de redes de área local (LAN)) manteniendo al mismo tiempo la compatibilidad con las especificaciones CCITT/ITU-T. [50]

Las funciones de usuario y otras características admitidas por cada versión de X.25 e ISO/IEC 8208 han variado de una edición a otra. [51] Existen varias versiones importantes del protocolo X.25: [52]

La Recomendación X.25 permite que cada red elija muchas opciones al decidir qué características admitir y cómo se realizan ciertas operaciones. Esto significa que cada red necesita publicar su propio documento que proporcione la especificación de su implementación X.25, y la mayoría de las redes exigieron que los fabricantes de dispositivos DTE realizaran pruebas de conformidad del protocolo, que incluían pruebas de estricto cumplimiento y aplicación de las opciones específicas de su red. (Los operadores de red estaban particularmente preocupados por la posibilidad de que un dispositivo DTE que se comportara mal o estuviera mal configurado desconectara partes de la red y afectara a otros suscriptores). Por lo tanto, los dispositivos DTE del suscriptor deben configurarse para que coincidan con las especificaciones de la red particular a la que están conectados. conectando. La mayoría de ellos eran lo suficientemente diferentes como para evitar el interfuncionamiento si el suscriptor no configuraba su dispositivo correctamente o el fabricante del dispositivo no incluía soporte específico para esa red. A pesar de las pruebas de conformidad del protocolo, esto a menudo genera problemas de interfuncionamiento al conectar inicialmente un dispositivo a una red.

Además de las versiones CCITT/ITU-T del protocolo, existen cuatro ediciones de ISO/IEC 8208: [51]

Legado

El protocolo X.25 tenía muchos gastos generales para lidiar con las pérdidas (los circuitos en ese entonces funcionaban con cableado de mala calidad y tenían que lidiar con muchos errores de un solo bit). A medida que los circuitos se volvieron cada vez más confiables, los gastos generales ya no fueron necesarios y se hizo cargo Frame Relay , menos costoso. Frame Relay tiene su base técnica en X.25, pero no intenta corregir errores.

Las redes públicas de datos mundiales basadas en X.25 ayudaron a hacer crecer el IP como protocolo superior.

X.25 también estaba disponible en aplicaciones especializadas como Retronet, que permiten que las computadoras antiguas utilicen Internet .

Ver también

Referencias

  1. ^ ab CCITT, Comisión de Estudio VII, Proyecto de Recomendación X-25 , marzo de 1976
  2. ^ Historia de X.25, Asambleas Plenarias del CCITT y colores de libros
  3. ^ (Friend et al. 1988, pág. 242)
  4. ^ (Friend et al. 1988, pág. 243)
  5. ^ Recomendación UIT-T X.28.
  6. ^ Recomendación UIT-T X.3.
  7. ^ Foregenix (febrero de 2012). «X.25 dentro de la Industria de las Tarjetas de Pago» (PDF) . Archivado desde el original (PDF) el 4 de marzo de 2016 . Consultado el 25 de mayo de 2016 .
  8. ^ abcdefg Sirbu, Marvin A; Zwimpfer, Laurence E (marzo de 1985). "Establecimiento de estándares para la comunicación informática: el caso de X.25". IEEE.
  9. ^ Despres, Remi (2010). "Circuitos virtuales X.25 - TRANSPAC en Francia - Redes de datos previas a Internet". Revista de comunicaciones IEEE . 48 (11): 40–46. doi :10.1109/MCOM.2010.5621965. ISSN  1558-1896.
  10. ^ Rybczynski, Tony (2009). "Comercialización de la conmutación de paquetes (1975-1985): una perspectiva canadiense [Historia de las comunicaciones]". Revista de comunicaciones IEEE . 47 (12): 26–31. doi :10.1109/MCOM.2009.5350364. ISSN  1558-1896. S2CID  23243636.
  11. ^ "Breve historia del grupo de estudio ... 7". www.itu.int . Consultado el 4 de febrero de 2020 .
  12. ^ Recomendaciones de la serie X
  13. ^ ab (Friend et al.1988, p.230)
  14. ^ "Cooperación europea en el campo de la investigación científica y técnica (COST), 1971-".
  15. ^ Bothner-By, Halvor (julio de 1974). «INFORME DEL GRUPO DEL RELATOR SOBRE EL PUNTO C -».
  16. ^ ab Grupo de relatores sobre conmutación de paquetes. "Informe de la reunión de Oslo (15 - 16 de agosto de 1974)". CCITT.
  17. ^ ab Després, Rémi (2010). Schwartz, Mischa (ed.). "Circuitos virtuales X.25 - TRANSPAC en Francia - Redes de datos anteriores a Internet". Revista de comunicaciones IEEE . 48 (11): 40–46. doi :10.1109/MCOM.2010.5621965. S2CID  23639680.
  18. ^ Relator del CCITT sobre conmutación de paquetes (26 de marzo de 1975). "Propuestas de Recomendaciones" (PDF) .
  19. ^ Rybczynski, Tony (diciembre de 2009). "Comercialización de la conmutación de paquetes (1975-1985): una perspectiva canadiense [Historia de las comunicaciones]". Revista de comunicaciones IEEE . 47 (12): 26–31. doi :10.1109/MCOM.2009.5350364. S2CID  23243636.
  20. ^ INWG#99. "Informe de la reunión de Ginebra (28 de mayo - 6 de junio de 1975) (Extractos)".{{cite web}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )
  21. ^ Pouzin, Louis (octubre de 1975). "Reunión del Grupo de Relator del CCITT sobre conmutación de paquetes - (Ginebra, 16 a 19 de septiembre de 1975)". pag. 6 en el Anexo 4.
  22. ^ ab (Schatt 1991, pag. 200).
  23. ^ (Schatt 1991, pag. 207).
  24. ^ "Ejecución de X.25 sobre TCP/IP en enrutadores Cisco". 1 de febrero de 2001. Archivado desde el original el 21 de enero de 2012.
  25. ^ (en francés) Presse, Agence France (21 de julio de 2011). "Le Minitel disparaîtra en juin 2012" [Minitel desaparecerá en junio de 2012]. Le Fígaro (en francés).
  26. ^ (en francés) [1]
  27. ^ "Lista de precios de BT: Sección 13: Redes IP de BT". BT . Consultado el 30 de mayo de 2019 .
  28. ^ ISO 8208:2000
  29. ^ ISO 8208, Anexo B.
  30. ^ Recomendación UIT-T X.25, G.3.2 Servicio de extensión de dirección llamada, págs.
  31. ^ Recomendación UIT-T X.223, Apéndice II.
  32. ^ Recomendación UIT-T X.7 (04/2004), págs. 17-18.
  33. ^ Recomendación UIT-T X.223.
  34. ^ Recomendación UIT-T X.25 (10/96), anexo G, p. 140.
  35. ^ Recomendación UIT-T X.213, anexo A.
  36. ^ abc Recomendación UIT-T X.25 (10/96), pág. 45.
  37. ^ Recomendación UIT-T X.283 (12/97), pág. 42.
  38. ^ ab Recomendación UIT-T X.25 (10/96), anexo A, págs.
  39. ^ ISO/IEC 8208:2000, cuarta edición, p. 61.
  40. ^ Recomendación UIT-T X.2 (03/2000), pág. 4.
  41. ^ ISO/IEC 8208:2000, cuarta edición, 3.7.1, pág. 7.
  42. ^ Recomendación UIT-T D.11 (03/91), pág. 2.
  43. ^ Recomendación UIT-T D.12 (11/88), pág. 1.
  44. ^ Recomendación UIT-T X.7 (04/2004), pág. 42.
  45. ^ Recomendación UIT-T D.11 (03/91), pág. 3.
  46. ^ Recomendación UIT-T X.7 (04/2004), pág. 38.
  47. ^ Recomendación UIT-T X.2
  48. ^ Recomendación UIT-T X.7
  49. ^ Recomendación UIT-T X.25 (10/96), Resumen, pv
  50. ^ ISO/IEC 8208:2000, cuarta edición, sección 1: alcance, p. 1.
  51. ^ ab ISO/IEC 8208:2000, cuarta edición, anexo C.
  52. ^ Recomendación UIT-T X.25.
  53. ^ Libro Blanco de la Recomendación UIT-T X.25 (1993)
  54. ^ Libro gris de la Recomendación UIT-T X.25 (1996)

Otras lecturas

enlaces externos