stringtranslate.com

X.25

X.25 es un conjunto de protocolos estándar de la UIT-T para la comunicación de datos por conmutación de paquetes en redes de área amplia (WAN). Fue definido originalmente por el Comité Consultivo Internacional Telegráfico y Telefónico (CCITT, actualmente UIT-T) en una serie de borradores y finalizado en una publicación conocida como The Orange Book en 1976. [1] [2]

El conjunto de protocolos está diseñado como tres capas conceptuales, que corresponden estrechamente a las tres capas inferiores del Modelo de Referencia OSI de siete capas , aunque se desarrolló varios años antes del modelo OSI (1984). [3] [4] También admite funcionalidad que no se encuentra 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 tradicionales o conexiones ISDN como enlaces físicos.

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

Historia

Representantes de empresas privadas y de servicios postales que defendieron el desarrollo de redes y servicios basados ​​en X.25 en Europa, América del Norte y Japón. Fotografiados en la reunión del grupo de relatores 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 (posteriormente 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 por conmutación de 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, el Reino Unido y los EE. UU. que representaban una mezcla de PTT nacionales (Francia, Japón, el Reino Unido) y operadores privados (Canadá, EE. UU.). En particular, el trabajo de Rémi Després contribuyó significativamente al estándar, que se basaba en un servicio de circuito virtual . Se acomodaron algunos cambios menores, que complementaban la especificación propuesta, para permitir que Larry Roberts se uniera al acuerdo. [9] [10] [11] Se trabajaron varias actualizaciones y adiciones en el 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 publicaron 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 designó un relator especial sobre conmutación de paquetes, Halvor Bothner-By , que celebró una reunión inicial en enero de 1974. Esto dio lugar a una pregunta, que debía responder el grupo de estudio (SG) VII para la siguiente sesión plenaria del CCITT en 1976, que era "¿Debería proporcionarse el nodo de operación de paquetes en redes públicas de datos y, de ser así, cómo debería implementarse?". Se proporcionó una lista de redes de conmutación de paquetes "a considerar": ARPANET (de la ARPA en los EE. UU.), EIN (de la COST europea), EPSS (de la Post Office Telecommunications británica ), RCP (de la PTT francesa ), CYCLADES (de IRIA en Francia), la red NPL (de la NPL en el Reino Unido), la red SWIFT (de la sociedad internacional SWIFT ) y la red SITA (de la empresa internacional SITA ). [14]

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 ). [15] Un documento presentado por Francia “con el apoyo activo de varias administraciones europeas” sirvió como “base principal para el debate en esta reunión”. Se acordó entonces “que se deberían considerar dos tipos de servicios, un servicio de 'datagramas' y un servicio de 'llamada virtual'”. [15] : p3 

En la tercera reunión, el enfoque pasó de si debería haber 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 puesta en marcha de Telenet de los EE. UU. y continuaron con la BPO del Reino Unido. [8] : p39  [16] : 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 tener un estándar lo antes posible en los EE. UU., Canadá, Francia, el Reino Unido y Japón. Prepararon contribuciones que las administraciones con derecho a voto en el CCITT presentarían al SG VII en su nombre. Una de las contribuciones fue una especificación de interfaz X.2x, la primera versión de lo que se convertiría en X.25. [17] [18]

En la cuarta reunión de relatores, celebrada en mayo de 1975 en Ginebra, participaron 45 personas y se elaboraron 27 documentos nuevos. El relator preguntó si se debían formular recomendaciones sobre conmutación de paquetes "con vistas a hacer posible el interfuncionamiento internacional", "la administración francesa respondió afirmativamente y Canadá apoyó firmemente la propuesta francesa". Sin embargo, todavía no se llegó a ninguna conclusión firme. [19]

La quinta reunión del Relator, celebrada en septiembre de 1975 en Ginebra, contó con la presencia de unos 60 participantes. Tras los debates sobre la interfaz de circuito virtual propuesta, quedaron sin resolver numerosas cuestiones. [8] : pág. 40  En lo que respecta a los datagramas, "Larry Roberts, de la delegación de los Estados Unidos, propuso, con el apoyo de los representantes de Francia y Canadá respectivamente, que se cambiara la clasificación de los datagramas de "E" a "A", es decir, de esencial "que debe estar disponible internacionalmente" a adicional "que puede estar disponible en ciertos países y a nivel internacional". [20] El último informe del Relator expresó dudas "de que una norma estuviera lista para su adopción por el SG VII". [8] : pág. 40 

En la última reunión del SG VII en pleno antes de la sesión plenaria del CCITT de septiembre de 1976, el borrador X.25 disponible suscitó numerosas preguntas de aclaración y/o objeciones técnicas. El presidente del SG VII, Vern MacDonald, nombró un editor y proporcionó un lugar de reunión para el fin de semana. Después de un intenso trabajo durante la misma, se habían tratado todos los temas. Para que el grupo de estudio en pleno aprobara el borrador X.25, quedaba un desafío pendiente: copias del borrador X.25 actualizado debían estar disponibles en dos idiomas. Para obtenerlas a 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 pegamento y tijeras para formar documentos limpios. El COM VII revisó entonces las copias distribuidas y las aprobó por unanimidad para su presentación a la próxima sesión plenaria del CCITT. [16] En esta sesión plenaria 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 los EE.UU., se añadió un servicio opcional de datagramas a la versión revisada X.25 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 se eliminaron finalmente de X.25 en su actualización de 1984. [8] : p41 

Redes públicas de datos a nivel mundial

Las redes X.25 de acceso público, comúnmente llamadas redes públicas de datos , se establecieron en muchos países a fines de la década de 1970 y en la década de 1980 para reducir el costo de acceso a varios servicios en línea . Algunos 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 la década de 1980 y hasta la de 1990. [21]

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

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

X.25 todavía se utiliza en el sector aeronáutico (especialmente en Asia), aunque la transición a protocolos modernos es cada vez más importante a medida que el hardware X.25 se vuelve cada vez más raro y costoso. [ aclaración necesaria ] Tan recientemente como en 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 restantes donde funcionó un servicio comercial para usuarios finales basado en X.25. Conocido como Minitel, se basaba 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 unos 2 millones de usuarios en Francia cuando France Télécom anunció que cerraría el servicio el 30 de junio de 2012. [24] Como estaba previsto, el servicio finalizó el 30 de junio de 2012. Había 800.000 terminales en funcionamiento en ese momento. [25] En 2019, todavía se podía comprar un servicio X.25 a BT en el Reino Unido. [26]

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 una compartición más eficiente de recursos físicos que requieren un uso intensivo de capital.

La especificación X.25 define únicamente la interfaz entre un suscriptor (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 usaban algo muy similar a X.25 o X.75 internamente, pero otras usaban protocolos bastante diferentes internamente. El protocolo ISO equivalente a X.25, ISO 8208, es compatible con X.25, pero además incluye la provisión para que dos DTE X.25 se conecten directamente entre sí sin red de por medio. Al separar el Protocolo de capa de paquetes , ISO 8208 permite la operación sobre redes adicionales como ISO 8802 LLC2 (ISO LAN) y la capa de enlace de datos OSI. [27]

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

El modelo X.25 se basaba en el concepto tradicional de telefonía de establecer circuitos fiables a través de una red compartida, pero utilizando software para crear " llamadas virtuales " a través de la red. Estas llamadas interconectaban "equipos terminales de datos" (DTE) que proporcionaban puntos finales a los usuarios, que parecían conexiones punto a punto . Cada punto final podía 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 "selección rápida con función de respuesta restringida" es un método intermedio entre el establecimiento de una llamada completa 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 la conexión se establezca nunca por completo.

Estrechamente relacionados con el protocolo X.25 están los protocolos para conectar dispositivos asíncronos (como terminales tontas e impresoras) a una red X.25: X.3 , X.28 y X.29 . Esta funcionalidad se realizaba utilizando 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 de paquetes X.25 . [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í misma. La capa de paquetes X.25 proporciona los mecanismos de llamada virtual, que se ejecutan sobre X.25 LAPB . La capa de paquetes incluye mecanismos para mantener llamadas virtuales y para señalar errores de datos en caso de que la capa de enlace de datos no pueda recuperarse de errores de transmisión de datos. Todas las versiones de X.25, excepto las más antiguas, incluyen funciones [29] que proporcionan direccionamiento de capa de red OSI (direccionamiento NSAP, consulte a continuación). [30]

Compatibilidad con dispositivos de usuario

Un terminal Televideo modelo 925 fabricado alrededor de 1982

X.25 se desarrolló en la era de las terminales de ordenador que se conectaban a ordenadores host, aunque también puede utilizarse para comunicaciones entre ordenadores. En lugar de marcar directamente "a" el ordenador host -lo que requeriría que el host tuviera su propio conjunto de módems y líneas telefónicas, y que los llamantes no locales hicieran llamadas de larga distancia- el host podría tener una conexión X.25 con 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 de terminal tonta le dice al PAD a qué host debe conectarse, proporcionando una dirección similar a un número de teléfono en el formato de dirección X.121 (o proporcionando un nombre de host, si el proveedor de servicios permite nombres que se correspondan con direcciones X.121 ). A continuación, el PAD realiza una llamada X.25 al host, estableciendo una llamada virtual . Nótese que X.25 permite llamadas virtuales, por lo que parece ser una red conmutada por circuitos , aunque de hecho los datos en sí mismos 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 interviene ningún PAD. En teoría, no importa si el emisor de la llamada X.25 y el destino X.25 están conectados al mismo operador, pero en la práctica no siempre era posible realizar llamadas de un operador a otro.

Para el control de flujo, se utiliza un protocolo de ventana deslizante con un tamaño de ventana predeterminado de 2. Los reconocimientos pueden tener importancia 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 reconocimiento de extremo a extremo. Cuando D=1, significa que el reconocimiento tiene importancia de extremo a extremo y debe tener lugar solo después de que el DTE remoto haya reconocido la recepción de los datos. Cuando D=0, la red tiene permitido (pero no obligado) 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 asincrónicos, se desarrollaron equivalentes de PAD para admitir una amplia gama de dispositivos de comunicaciones inteligentes propietarios, como aquellos para IBM System Network Architecture (SNA).

Control de errores

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

Direccionamiento y circuitos virtuales

Un módem X.25 utilizado 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 desconecta una vez que se completa la llamada. Los VC se establecen a través de un procedimiento de establecimiento y liberación de llamadas. Por otro lado, los circuitos virtuales permanentes se preconfiguran en la red. [31] Los PVC rara vez se desconectan y, por lo tanto, proporcionan una conexión dedicada entre puntos finales.

El VC puede establecerse 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 diez dígitos como máximo. Nótese el uso de un solo dígito de red, 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 dígitos que los NTN completos para el enrutamiento y ponían los dígitos sobrantes a disposición del suscriptor (a veces llamado subdirección) donde podían usarse para identificar aplicaciones o para un enrutamiento adicional en las redes de los suscriptores.

La facilidad 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 Orientada a Conexión (CONS) OSI . [32] Las redes públicas X.25 no estaban obligadas a hacer uso del direccionamiento NSAP, pero, para soportar OSI CONS, estaban obligadas a transportar las direcciones NSAP y otras facilidades DTE especificadas por ITU-T de forma transparente de DTE a DTE. [33] Las revisiones posteriores permitieron que se transportaran múltiples direcciones además de las direcciones X.121 en la misma interfaz DTE-DCE: direccionamiento Telex ( F.69 ), direccionamiento PSTN ( E.163 ), direccionamiento ISDN ( E.164 ), direcciones de Protocolo de Internet (IANA ICP) y direcciones MAC IEEE 802.2 locales . [34]

Los PVC se establecen de forma permanente 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 suscriptor mediante su identificador de canal lógico (véase más abajo). Sin embargo, en la práctica, no muchas de las redes X.25 nacionales admitían PVC.

Una interfaz DTE-DCE con 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, [35] aunque no se espera que las redes admitan 4095 circuitos virtuales completos. [36] Para identificar el canal al que está asociado un paquete, cada paquete contiene un identificador de canal lógico de 12 bits formado por un número de canal lógico de 8 bits y un número de grupo de canal lógico de 4 bits. [35] Los identificadores de canal lógico permanecen asignados a un circuito virtual durante la duración de la conexión. [35] 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 importancia local en el enlace entre el abonado y la red. Es probable que el otro extremo de la conexión en el DTE remoto tenga asignado un identificador de canal lógico diferente. El rango 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. [37] (Las direcciones se refieren a la dirección de iniciación de la llamada virtual como la ve el DTE; todas llevan datos en ambas direcciones). [38] Los rangos permitieron que un suscriptor se configurara para manejar cantidades significativamente diferentes de llamadas en cada dirección mientras reservaba algunos canales para llamadas en una dirección. Se requiere que todas las redes internacionales implementen soporte para circuitos virtuales permanentes, canales lógicos bidireccionales y canales lógicos unidireccionales salientes; los canales lógicos unidireccionales entrantes son una facilidad opcional adicional. [39] No se requiere que las interfaces DTE-DCE admitan más de un canal lógico. [37] El identificador de canal lógico cero no se asignará a un circuito virtual permanente o una llamada virtual. [40] El identificador de canal lógico de cero se usa para paquetes que no se relacionan con un circuito virtual específico (por ejemplo, reinicio de capa de paquete, registro y paquetes de diagnóstico).

Facturación

En las redes públicas, X.25 se facturaba normalmente como una tarifa de servicio mensual fija que dependía de la velocidad del enlace, y luego un precio por segmento sobre esto. [41] Las velocidades de enlace variaban, típicamente desde 2400 bit/s hasta 2 Mbit/s, aunque las velocidades superiores a 64 kbit/s eran poco comunes en las redes públicas. Un segmento consistía en 64 bytes de datos (redondeados hacia arriba, sin transferencia entre paquetes), [42] que se cobraban al llamante [43] (o al llamado en el caso de llamadas con cobro revertido, donde se admitían). [44] Las llamadas que invocaban la facilidad 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) [45] generalmente atraían un cargo adicional, al igual que el uso de algunas de las otras facilidades 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 hacía más económicos solo cuando se pasaban grandes volúmenes de datos.

Tipos de paquetes X.25

Detalles de X.25

La red puede permitir la selección de la longitud máxima en un rango de 16 a 4096 octetos (solo valores 2 n ) por circuito virtual mediante negociación como parte del procedimiento de establecimiento de la 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 X.2 de la UIT-T. [46] Las facilidades de usuario X.2 se dividen en cinco categorías:

X.25 también proporciona facilidades de usuario opcionales DTE especificadas por X.25 y la UIT-T, definidas y descritas en la Recomendación X.7 de la UIT-T. [47] Las facilidades de usuario opcionales 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). [48] Las versiones ISO/IEC abordan características adicionales para redes privadas (por ejemplo, uso de redes de área local (LAN)) manteniendo la compatibilidad con las especificaciones CCITT/ITU-T. [49]

Las facilidades 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. [50] Existen varias versiones principales del protocolo X.25: [51]

La Recomendación X.25 permite que cada red elija muchas opciones a la hora de decidir qué características admitir y cómo se realizan determinadas operaciones. Esto significa que cada red debe publicar su propio documento con las especificaciones de su implementación X.25, y la mayoría de las redes exigían a los fabricantes de dispositivos DTE que realizaran pruebas de conformidad con el protocolo, que incluían pruebas de cumplimiento estricto y aplicación de sus opciones específicas de red. (Los operadores de red estaban especialmente preocupados por la posibilidad de que un dispositivo DTE mal configurado o con un mal comportamiento eliminara partes de la red y afectara a otros abonados). Por lo tanto, los dispositivos DTE del abonado tienen que configurarse para que coincidan con las especificaciones de la red particular a la que se están conectando. La mayoría de ellas eran lo suficientemente diferentes como para impedir el interfuncionamiento si el abonado 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 con el protocolo, esto a menudo provocaba problemas de interfuncionamiento cuando se conectaba inicialmente un dispositivo a una red.

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

Legado

El protocolo X.25 tenía una gran carga de trabajo para lidiar con la pérdida de datos, ya que los circuitos de la época funcionaban sobre cableado de mala calidad y tenían que lidiar con muchos errores de un solo bit. A medida que los circuitos se volvieron más y más confiables, la carga de trabajo ya no fue necesaria y el Frame Relay , menos costoso , tomó el relevo. 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 que IP se convirtiera en el protocolo de mayor importancia.

X.25 también estaba disponible en aplicaciones de nicho como Retronet, que permite a las computadoras antiguas utilizar Internet .

Véase también

Referencias

  1. ^ ab CCITT, Grupo 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 y otros, 1988, pág. 242)
  4. ^ (Friend y otros, 1988, pág. 243)
  5. ^ Recomendación UIT-T X.28.
  6. ^ Recomendación X.3 de la UIT-T.
  7. ^ Foregenix (febrero de 2012). «X.25 en la industria de 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 anteriores a Internet". Revista IEEE Communications . 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 del 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 y otros, 1988, pág. 230)
  14. ^ Bothner-By, Halvor (julio de 1974). "INFORME DEL GRUPO DEL PONENTE SOBRE EL PUNTO C -".
  15. ^ ab Grupo ponente sobre conmutación de paquetes. "Informe de la reunión de Oslo (15-16 DE AGOSTO DE 1974)". CCITT.
  16. ^ ab Després, Rémi (2010). Schwartz, Mischa (ed.). "Circuitos virtuales X.25 – TRANSPAC en Francia – Redes de datos anteriores a Internet". Revista IEEE Communications . 48 (11): 40–46. doi :10.1109/MCOM.2010.5621965. S2CID  23639680.
  17. ^ Relator del CCITT sobre conmutación de paquetes (26 de marzo de 1975). "Propuestas de recomendaciones" (PDF) .
  18. ^ 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 del IEEE . 47 (12): 26–31. doi :10.1109/MCOM.2009.5350364. S2CID  23243636.
  19. ^ INWG#99. "Informe de la reunión en Ginebra (28 de mayo - 6 de junio de 1975) (extractos)".{{cite web}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  20. ^ Pouzin, Louis (octubre de 1975). «Reunión del grupo de relatores del CCITT sobre conmutación de paquetes (Ginebra, 16-19 de septiembre de 1975)». pág. 6 en el Anexo 4.
  21. ^ ab (Schatt 1991, pág. 200).
  22. ^ (Schatt 1991, pág. 207).
  23. ^ "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.
  24. ^ (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).
  25. ^ (en francés) [1]
  26. ^ "Lista de precios de BT: Sección 13: Redes IP de BT". BT . Consultado el 30 de mayo de 2019 .
  27. ^ ISO 8208:2000
  28. ^ ISO 8208, Anexo B.
  29. ^ Recomendación UIT-T X.25, G.3.2 Facilidad de extensión de la dirección llamada, págs. 141–142.
  30. ^ Recomendación UIT-T X.223, Apéndice II.
  31. ^ Recomendación UIT-T X.7 (04/2004), págs. 17–18.
  32. ^ Recomendación UIT-T X.223.
  33. ^ Recomendación UIT-T X.25 (10/96), Anexo G, pág. 140.
  34. ^ Recomendación UIT-T X.213, Anexo A.
  35. ^ abc Recomendación UIT-T X.25 (10/96), pág. 45.
  36. ^ Recomendación UIT-T X.283 (12/97), pág. 42.
  37. ^ ab Recomendación UIT-T X.25 (10/96), Anexo A, págs. 119–120.
  38. ^ ISO/IEC 8208:2000, cuarta edición, pág. 61.
  39. ^ Recomendación UIT-T X.2 (03/2000), pág. 4.
  40. ^ ISO/IEC 8208:2000, cuarta edición, 3.7.1, pág. 7.
  41. ^ Recomendación UIT-T D.11 (03/91), pág. 2.
  42. ^ Recomendación UIT-T D.12 (11/88), pág. 1.
  43. ^ Recomendación UIT-T X.7 (04/2004), pág. 42.
  44. ^ Recomendación UIT-T D.11 (03/91), pág. 3.
  45. ^ Recomendación UIT-T X.7 (04/2004), pág. 38.
  46. ^ Recomendación UIT-T X.2
  47. ^ Recomendación UIT-T X.7
  48. ^ Recomendación UIT-T X.25 (10/96), Resumen, pv
  49. ^ ISO/IEC 8208:2000, Cuarta Edición, Sección 1: Alcance, pág. 1.
  50. ^ ab ISO/IEC 8208:2000, Cuarta Edición, Anexo C.
  51. ^ Recomendación UIT-T X.25.
  52. ^ Libro Blanco de la Recomendación UIT-T X.25 (1993)
  53. ^ Libro Gris de la Recomendación UIT-T X.25 (1996)

Lectura adicional

Enlaces externos