X – 25

La norma X.25 es el estándar para redes de paquetes recomendado por CCITT, el cual emitió el primer borrador en 1974. Este original sería revisado en 1976, en 1978 y en 1980, y de nuevo en 1984, para dar lugar al texto definitivo publicado en 1985. El documento inicial incluía una serie de propuestas sugeridas por Datapac, Telenet y Tymnet, tres nuevas redes de conmutación de paquetes. La X.25 se define como la interfaz entre equipos terminales de datos y equipos de terminación del circuito de datos para terminales que trabajan en modo paquete sobre redes de datos públicas. Las redes utilizan la norma X.25 para establecer los procedimientos mediante los cuales dos DTE que trabajan en modo paquete se comunican a través de la red. Este estándar pretende proporcionar procedimientos comunes de establecimiento de sesión e intercambio de datos entre un DTE y una red de paquetes (DCE). Entre estos procedimientos se encuentran funciones como las siguientes: identificación de paquetes procedentes de ordenadores y terminales concretos, asentimiento de paquetes, rechazo de paquetes, recuperación de errores y control de flujo. Además, X.25 proporciona algunas facilidades muy útiles, como por ejemplo en la facturación a estaciones DTE distintas de la que genera el tráfico. Dentro de la perspectiva de X.25, una red opera en gran parte como un sistema telefónico. Una red X.25 se asume como si estuviera formada por complejos conmutadores de paquetes que tienen la capacidad necesaria para el enrutamiento de paquetes. Los anfitriones no están comunicados de manera directa a los cables de comunicación de la red. En lugar de ello, cada anfitrión se comunica con uno de los conmutadores de paquetes por medio de una línea de comunicación serial. En cierto sentido la comunicación entre un anfitrión y un conmutador de paquetes X.25 es una red miniatura que consiste en un enlace serial. El anfitrión puede seguir un complicado procedimiento para transferir sus paquetes hacia la red. El estándar X.25 no incluye algoritmos de encaminamiento, pero conviene resaltar que, aunque los interfaces DTE Y DCE de ambos extremos de la red son independientes uno de otro, X.25 interviene desde un extremo hasta el otro, ya que el tráfico seleccionado se encamina el final. A pesar de ello, el estándar recomendado es asimétrico ya que sólo se define un lado de la interfaz con la red (DTE Y DCE)

Por lo tanto, el servicio X.25 es un diálogo entre dos entidades DTE Y DCE. La forma más común de conexión y lo que abarca cada nivel.

Nomenclatura:

• DTE (Data Terminal Equipment): Es lo que utiliza el usuario final (PC con placa X.25 por ejemplo). Es el equipo terminal de datos. Incorpora los niveles 2 y 3.
• DCE (Data Circuit Terminating Equipment): Podemos interpretarlo como un nodo local. A nivel de enlace (LAPB) las conexiones se establecen DTE-DCE. Ahora con el nivel de red, ampliamos las comunicaciones más allá del DCE, que hace de interconexión. Sólo incluye el nivel 1.

Con X.25 no hay conexiones multipunto. Es un servicio punto a punto, por lo que sólo puedo conectar un DTE con otro DTE. En X.25 se regulan:

• INTERFAZ A NIVEL FÍSICO.
• PROTOCOLO DE ENLACE.
• PROTOCOLO DE RED.

• 25 y su relación con el modelo ISO

Aun cuando fue diseñado para proporcionar un modelo conceptual y no una guía de implementación, el esquema de estratificación por capas de ISO ha sido la base para la implementación de varios protocolos. Entre los protocolos comúnmente asociados con el modelo ISO, el conjunto de protocolos conocido como X.25 es probablemente el mejor conocido y el más ampliamente utilizado. X.25 fue establecido como una recomendación de la Telecommunications Section de la International Telecommunications Union (ITU-TS), una organización internacional que recomienda estándares para los servicios telefónicos internacionales. X.25 ha sido adoptado para las redes públicas de datos y es especialmente popular en Europa. Consideraremos a X.25 para ayudar a explicar la estratificación por capas de ISO.

Dentro de la perspectiva de X.25, una red opera en gran parte como un sistema telefónico. Una red X.25 se asume como si estuviera formada por complejos conmutadores de paquetes que tienen la capacidad necesaria para el ruteo de paquetes. Los anfitriones no están comunicados de manera directa a los cables de comunicación de la red. En lugar de ello, cada anfitrión se comunica con uno de los conmutadores de paquetes por medio de una línea de comunicación serial. En cierto sentido la comunicación entre un anfitrión y un conmutador de paquetes X.25 es una red miniatura que consiste en un enlace serial. El anfitrión puede seguir un complicado procedimiento para transferir paquetes hacia la red.

• Capa física. X.25 especifica un estándar para la interconexión física entre computadoras anfitrión y conmutadores de paquetes de red, así como los procedimientosutilizados para transferir paquetes de una máquina a otra. En el modelo de referencia, el nivel 1 especifica la interconexión física incluyendo las características de voltaje y corriente. Un protocolo correspondiente, X.2 1, establece los detalles empleados en las redes publicas de datos.
• Capa de enlace de datos. El nivel 2 del protocolo X.25 especifica la forma en que los datos viajan entre un anfitrión y un conmutador de paquetes al cual esta conectado. X.25 utiliza él termino trama para referirse a la unidad de datos cuando esta pasa entre un anfitrión y un conmutador de paquetes (es importante entender que la definición de X.25 de trama difiere ligeramente de la forma en que la hemos empleado hasta aquí). Dado que el hardware, como tal, entrega solo un flujo de bits, el nivel de protocolos 2 debe definir el formato de las tramas y especificar cómo las dos maquinas reconocen las fronteras de la trama. Dado que los errores de transmisión pueden destruir los datos, el nivel de protocolos 2 incluye unadetección de errores (esto es, una suma de verificación de trama). Finalmente, dado que la transmisión es no confiable, el nivel de protocolos 2 especifica un intercambio de acuses de recibo que permite a las dos máquinassaber cuando se ha transferido una trama con éxito.

Hay protocolos de nivel 2, utilizado comúnmente, que se conoce como High Level Data Link Communication (Comunicación de enlace de datos de alto nivel), mejor conocido por sus siglas, HDLC. Existen varias versiones del HDLC, la más reciente es conocida como HDLCILAPB. Es Recordar que una transferencia exitosa en el nivel 2 significa que una trama ha pasado hacia un conmutador de paquetes de red para su entrega; esto no garantiza que el conmutador de paquetes acepte el paquete o que este disponible para rutearlo.

• Capa de red. El modelo de referencia ISO especifica que el tercer nivel contiene funciones que completan la interacción entre el anfitrión y la red. Conocida como capa de red o subred de comunicación, este nivel define la unidad básica de transferencia a través de la red e incluye el conceptode direccionamiento de destino y ruteo. Debe recordarse que en el mundo de X.25 la comunicación entre el anfitrión y el conmutador de paquetes esta conceptualmente aislada respecto al trafico existente. Así, la red permitiría que paquetes definidos por los protocolos del nivel 3 sean mayores que el tamaño de la trama que puede ser transferida en el nivel 2. El software del nivel 3 ensambla un paquete en la forma esperada por la red y utiliza el nivel 2 para transferido (quizás en fragmentos) hacia el conmutador de paquetes. El nivel 3 también debe responder a los problemas de congestionamiento en la red.
• Capa de transporte. El nivel 4 proporciona confiabilidad punto a punto y mantiene comunicados al anfitrión de destino con el anfitrión fuente. La idea aquí es que, así como en los niveles inferiores de protocolos se logra cierta confiabilidad verificando cada transferencia, la capa punto a punto duplica la verificación para asegurarse de que ninguna máquina intermedia ha fallado.
• Capa de sesión. Los niveles superiores del modelo ISO describen cómo el software de protocolos puede organizarse para manejar todas las funciones necesarias para los programasde aplicación. El comité ISO considera el problema del acceso a una terminal remota como algo tan importante que asignó la capa 5 para manejarlo. De hecho, el servicio central ofrecido por las primeras redes publicas de datos consistía en una terminal para la interconexión de anfitriones. Las compañías proporcionaban en la red, mediante una línea de marcación, una computadoraanfitrión de propósito especial, llamada Packet Assembler and Disassembler ( Ensamblador -v desensamblador de paquetes o PAD, por sus siglas en ingles). Los suscriptores, por lo general de viajeros que

Transportaban su propia computadora y su módem, se ponían en contacto con la PAD local, haciendo una conexión de red hacia el anfitrión con el que deseaban comunicarse.

Muchas compañías prefirieron comunicarse por medio de la red para subcomunicación por larga distancia, porque resultaba menos cara que la marcación directa.

• Capa de presentación. La capa 6 de ISO esta proyectada para incluir funciones que muchos programas de aplicación necesitan cuando utilizan la red. Los ejemplos comunes incluyen rutinas estándar que comprimen textoo convierten imágenes gráficas en flujos de bits para su transmisión a través de la red. Por ejemplo, un estándar ISO, conocido como Abstract Svntax Notation 1 (Notación de sintaxis abstracta 1 o ASN 1, por sus siglas en ingles), proporciona una representación de datos que utilizan los programas de aplicación. Uno de los protocolos TCP/IP, SNMP, también utiliza ASN 1 para representar datos.
• Capa de aplicación. Finalmente, la capa 7 incluye programas de aplicación que utilizan la red. Como ejemplos de esto se tienen al correo electrónico o a los programas de transferencia de archivos. En particular, el ITU-TS tiene proyectado un protocolo para correo electrónico, conocido como estándar X.400. De hecho, el ITU y el ISO trabajan juntos en el sistema de manejo de mensajes; la versión de ISO es conocida como MOTIS.

2 – Nivel Físico.

Existen dos posibilidades para la interfaz a nivel físico:

• 21: Se utiliza para el acceso a redes de conmutación digital. (Similares a las de telefonía digital.)
• 21bis: Se emplea para el acceso a través de un enlace punto a punto. (Similar a RS-232 en modo síncrono.)

La recomendación X.25 para el nivel de paquetes coincide con una de las del tercer nivel ISO, que abarca también los dos niveles más bajos.

La interfaz de nivel físico recomendado entre el DTE y el DCE es el X.21.

X.25 asume que: el nivel físico X.21 mantiene activados los circuitos T (transmisión) y R (recepción) durante el intercambio de paquetes; que el X.21 se encuentra en estado 13S (enviar datos), 13R (recibir datos) o 13 (transferencia de datos); y supone también que los canales C (control) e I (indicación) de X.21 están activados.

Por todo esto, X.25 utiliza la interfaz X.21 que une el DTE y el DCE como un “conductor de paquetes”, en el cual los paquetes fluyen por las líneas de transmisión (T) y de recepción (R).

El nivel físico de X.25 no desempeña funciones de control significativas, sino que se trata más bien de un conducto pasivo, de cuyo control se encargan los niveles de enlace y de red.

El protocolo X.21bis es el protocolo de la capa física de X.21 que: define las interfaces eléctricas y mecánicas; maneja la activación y desactivación del medio físico entre DTE y DCE; soporta conexiones punto a punto, velocidad de hasta 19.2kbps y transmisión síncrona full duplex sobre 2 pares.

La interfaz de nivel físico regula el diálogo entre el DCE y el DTE, y se describe desde 3 puntos de vista distintos:

1. Mecánico
2. Eléctrico.

En cuanto la interfaz mecánica, se usan conectores Canon DB15 (de 15 pines,  para X.21) o DB25 (de 25 pines para X.21 bis).
En cuanto a la interfaz eléctrica X.21 utiliza X.26, que es una interfaz no balanceada, por lo que se suele usar mejor X.27 que es balanceada y, por tanto, permite tasas de transmisión superiores. La interfaz eléctrica de X.21 bis está recogida en la norma V.28. Las velocidades se mueven entre los 64kbps y los 2Mbps, velocidades que pueden parecer bajas y, de hecho, así son. X.25 presenta un problema de baja eficiencia por la exagerada protección contra errores que implementa y que con las redes de hoy en día no tienen sentido.
La interfaz funcional de X.21 se define mediante las distintas señales que intercambia el DB15. La interfaz funcional de X.21 bis está recogida en la norma  V.24. X.21 no ha tenido mucho éxito. X.21 bis es más popular.

3 – Nivel de Enlace (LAP-B)

En este nivel X.25 ofrece controles de enlace de datos utilizando un protocolo orientado a bit denominado protocolo balanceado de acceso a enlace (LAPB), que es un subconjunto de HDLC. Es LAPB el que se encarga de que lleguen correctamente los paquetes X.25 que se transmiten a través de un canal susceptible de errores, desde o hacia la interfaz ETD/ETCD. La diferencia entre paquete y trama es que los paquetes se crean en el nivel de red y se insertan dentro de una trama, la cual se crea en nivel de enlace. El servicio que ofrece el nivel 2 al nivel superior es orientado a conexión, fiable y en modo paquete. El nivel 2 sólo ofrece  una  conexión al nivel superior. El nodo local es el que presta servicio al DTE conectado a él. El nivel de enlace no resuelve el servicio extremo a extremo.  La comunicación extremo a extremo la resuelve el nivel de red. El diálogo entre entidades de enlace es salto a salto. Por tanto, existen tantas conexiones de enlace como unidades tengamos entre el DTE local y DTE remoto.

LAPB y X.25 interactúan de la siguiente forma: En la trama LAPB, el paquete X.25 se transporta dentro del campo I(información).

Para funcionar bajo el entorno X.25, LAPB utiliza información (I), Receptor Preparado(RR), Rechazo(REJ), Receptor No Preparado(RNR), Desconexión(DSC), Activar Modo de Respuesta Asíncrono(SARM) y Activar Modo Asíncrono Equilibrado(SABM). Las respuestas utilizadas son las siguientes: Receptor Preparado(RR), Rechazo(REJ), Receptor No Preparado(RNR), Asentimiento No Numerado(UA), Rechazo de Trama(FRMR) y Desconectar Modo(DM). Los datos de usuario del campo I no pueden enviarse como respuesta. De acuerdo con las reglas de direccionamiento HDLC, ello implica que las tramas I siempre contendrán la dirección de destino con lo cual se evita toda posible ambigüedad en la interpretación de la trama. X.25 exige que LAPB utilice direcciones específicas dentro del nivel de enlace.

Debido a que la comunicación es de punto a punto en modo asíncrono balanceada, las dos únicas direcciones son 00000001 para el DTE y 00000011 para el DCE como se muestra en la figura 3.2.

En cuanto a las tramas se tienen 3 categorías que son:

* Tramas I que se utilizan para encapsular paquetes PLP de nivel de red. ). Lleva información de la capa superior, sus funciones son, control de flujo, detección y corrección de error, y control de secuencia de las tramas.
* Tramas S que se utilizan para control de errores y flujo de nivel de trama. ). Lleva información de control, sus funciones son, solicitud y suspensión de la transmisión, reporte del estado, y reconocimiento de recepción de I-frames.
* Tramas U que se usan para establecer y desconectar los enlaces entre un DTE y un DCE. Lleva información de control, sus funciones son, establecimiento del enlace y desconexión, reporte de errores.

En el nivel de trama la comunicación entre el DTE y el DCE se establece en tres fases: establecimiento de enlace, transferencia de paquetes y desconexión de enlace.

Establecimiento de enlace: El enlace entre un DTE y un DCE debe establecerse antes de que se puedan transferir los paquetes provenientes del nivel de paquetes. Tanto el DTE como el DCE pueden establecer el enlace enviando una trama SABM (establecer modo balanceado asíncrono). La parte que responde envía una trama UA (confirmación no numerada) para confirmar que el enlace ya está establecido.

Transferencia de datos: Una vez establecido el enlace las dos partes pueden enviar y recibir paquetes del nivel de red (datos y control) utilizando tramas I y S. Desconexión del enlace: Cuando el nivel de red deja de utilizar el enlace, una de las partes puede emitir una trama de desconexión (DISC) para solicitar la desconexión, la otra parte puede responder con una UA.

4 – Nivel de red (Nivel 3) en la recomendación X.25.

El protocolo de la capa de red se ocupa de la asignación de direcciones, el control de flujo, la confirmación de la entrega, las interrupciones y otras consideraciones relacionadas. Básicamente, este protocolo permite al usuario establecer circuitos virtuales y después enviar paquetes de hasta 128 bytes a través de ellos. Estos paquetes se entregan en forma confiable y en orden. La mayor parte de la redes X.25 trabajan a velocidades  de hasta 64kbps, la cual las hace obsoleta para muchos propósitos. No obstante su uso aun, es extenso.

En relación al modelo OSI, en la capa de Red tenemos que prestar atención al PLP (Packet Layer Protocol).

• Administra las conexiones entre el DCE y el DTE.
• PLP tiene 5 modos de operación:
  • 1) Call setup.
  • 2) Data Transfer.
  • 3) Idle.
  • 4) Call Clearing
  • 5) Restaring.

• Call Setup: es el modo utilizado para establecer SVC’s (Circuitos virtuales conmutados) entre los DTE.

• Data transfer mode: Se utiliza para transferir datos entre dos DTE’s sobre un circuito virtual. En este modo PLP realiza la segmentacion y el reensamble, bit padding, y control de flujo y errores.

• Idle mode: Se utiliza cuando se establece un circuito virtual y no hay transferencia de datos, se utiliza solo para SVC’s.

• Call clearing mode: Se utiliza para terminar sesión entre DTE’s y para terminar SVC’s, se utiliza solo para SVC’s.

• Restarting mode: Se utiliza para sincronizar la transmisión entre DTE’s y DCE’s. Afecta a todos los circuitos virtuales del DTE.

En Resumen:

Las aplicaciones hoy en día del X.25:

• Verificación de tarjetas de créditos y otras transacciones
• Correo electrónico

5- X.25 en la actualidad

Actualmente los enlaces de cajeros automáticos y las transacciones de las tarjetas de crédito (POSNET) siguen requiriendo de un enlace X.25.

Al no haber en la actualidad redes puramente X.25, se realiza el transporte sobre redes IP, lo que requiere de la adaptación de los paquetes X.25 para ser transportados a través de una red TCP/IP en lugar de hacerlo sobre LAPB.

Esta adaptación al transporte se conoce como XOT. XOT permite transportar paquetes X.25 a través de una red TCP/IP en lugar de hacerlo sobre LAPB. Se realiza un túnel sobre una red IP para interconectar dos redes X.25. Cuando se recibe una llamada X.25 entrante que debe ser reenviada, se consultan dos campos en la tabla de ruteo de X.25 para determinar la ruta remota:

La dirección X.121 de destino y opcionalmente el campo CUD (call user data).

Cuando se encuentra la información en la tabla de ruteo, la llamada es reenviada.

Se puede especificar un origen XOT que hace que la conexión XOT  TCP use una dirección IP de una interfaz específica como dirección de origen de la conexión TCP.

Los paquetes X.25 necesitan una capa de enlace confiable, TCP provee un flujo de bytes confiable.

X.25 necesita que la capa inferior provea  una semántica de mensajes, en particular en la frontera entre paquetes, para poder hacer esto, se usa un header XOT de 4-bytes entre el paquete X.25 y TCP.

El contenido de este header es un campo de longitud que es usado para separar el paquete X.25 dentro de la trama TCP

Relación entre XOT y X.25

Cuando un dispositivo de red utiliza como protocolo X.25, debe ser conectado a una interfaz de LAPB o a una interfaz lógica que este corriendo LLC o XOT/TCP/IP.

La norma X.25 llama a un determinado paquete de diferentes formas según sea el rol de la interfaz que lo origina (DTE/DCE).

XOT es insensible al rol de las interfaces locales en los extremos de una conexión TCP, por lo que los siguientes términos son intercambiables:

• Call, Call Request, Incoming Call
• Call Confirm, Call Accepted, Call Connected
• Clear, Clear Request, Clear Indication
• Clear Confirm, DTE Clear Confirmation, DCE Clear Confirmation
• Data, DTE Data, DCE Data
• Interrupt, DTE Interrupt, DCE Interrupt
• Interrupt Confirm, DTE Interrupt Confirmation, DCE Interrupt Confirmation
• RR, DTE RR, DCE RR
• RNR, DTE RNR, DCE RNR
• REJ, Reject, DTE REJ
• Reset, Reset Request, Reset Indication
• Reset Confirm, DTE Reset Confirmation, DCE Reset Confirmation
• Restart, Restart Request, Restart Indication
• Restart Confirm, DTE Restart Confirmation,
• DCE Restart Confirmation

Formato del paquete

El paquete encapsulado tiene el siguiente formato:

Según la convención RFC, el formato del paquete es tal que los datos enviados primero están por encima de los datos enviados después.

HEADER XOT
El header XOT tiene el siguiente formato :

Versión (2 octetos)

El número de versión del protocolo XOT está codificado en los dos primeros octetos, el valor de la versión debe ser cero, si se recibe un valor distinto de cero, la conexión TCP debe ser cerrada
Longitud (2 octetos)
La longitud del paquete X.25 está codificada en los otros dos octetos.

Los valores deben tener la longitud de un paquete X.25, si tienen otra longitud la conexión TCP debe ser cerrada.

Conexión TCP, número de puerto, canal lógico y número de canales logicos (LCNs)

Se debe usar una conexión TCP independiente para cada circuito virtual X.25, las conexiones se realizan en el puerto TCP 1998 que es el registrado para el uso de XOT.

La conexión TCP debe ser creada antes de que se establezca el circuito virtual. La conexión TCP se puede mantener una vez que se cerró el circuito virtual. Los datos no deben ser pasados junto con el paquete SYN de TCP.

El campo LCN en el header X.25 no tiene significancia y tiene valores arbitrarios. Como consecuencia de esto es que no hay asignación de DTE y DCE.

Paquete XOT

Por cada paquete X.25 recibido de la conexión TCP para ser enviado por la interfaz, XOT debe establecer el número de canal lógico que debe ser usado en la interfaz de salida.

El número de canal lógico es un campo de 12 bits donde los 4 bits de alto orden son el número de channel group lógico  y los 8 bits restantes son el número de canal lógico.

La aplicación XOT no debe modificar la información del header del paquete X.25 recibido en la interfaz local.

La aplicación XOT debe modificar la información del header del paquete X.25 recibido por la conexión TCP para ser transmitido a través de la interfaz local.

Debe soportar la conexión entre interfaces que usan diferentes módulos de control de flujo y modificar el formato de identificación general en todos los paquetes recibidos sobre la conexión TCP para establecer el identificador de módulo adecuado
Configuración y liberación de circuitos virtuales:

Una vez que se estableció una conexión  TCP, el paquete X.25 es enviado por el XOT que inició la conexión TCP.

Para simplificar el control de flujo end-to-end, el tamaño de paquete y el tamaño de la ventana son enviados explícitamente en el Call packet

El paquete Call confirm puede tener está información.
Si una llamada recibida sobre una conexión TCP no codifica alguna de las funciones de control es un problema local, si XOT acepta la llamada, debe codificar los valores de control de flujo que no le fueron enviados para el paquete de call confirm.

Datos y control de flujo

La aplicación de control de flujo X.25 es un asunto local, pero diferentes implementaciones afectan el comportamiento de XOT.

Una aplicación XOT podrá implementar el control de flujo end-to-end cuando los paquetes de datos, RR y RNR sean enviados a través de la conexión TCP o el control de flujo local sea enviado en un VC de acuerdo a criterios locales, una secuencia completa de paquetes de datos debe ser fragmentada o combinada, la numeración de los paquetes de datos normalmente tiene significancia a nivel local

Interrupción y reset de paquetes

Los paquetes de interrupción, confirmación de interrupción, reset y confirmación de reset son enviados a través de la conexión TCP usando el formato normal de paquetes X.25 y las transiciones de estado.

La naturaleza end-to-end de la interrupción y reset deben mantenerse para la correcta operación de X.25
Reinicio, rechazo de DTE, Diagnostico y registración

Los paquetes X.25 que solo tienen significancia en una interfaz DTE/DCE, no deberan ser enviados sobre la conexión TCP.

Si se recibe uno de estos paquetes debe ser descartado.

Configuración de PVC

La implementación XOT debe soportar la conexión de PVC´s. Los PVC X.25 son circuitos virtuales que deben estar disponibles cuando el servicio X.25 está disponible.

Conectar un PVC a través de XOT es complicado ya que los mensajes de Call, Call Confirm, Clear o Clear Confirm no son transferidos a través de la interfaz X.25.

La configuración de un PVC entre dos entidades XOT se realiza a través del intercambio de paquetes no estándar para X.25(encapsulados en el header XOT) La configuración del PVC se realiza inmediatamente después de que se establece una nueva conexión TCP XOT.

La configuración del PVC incluye los paquetes X.25 General Format Identifier, LCN y Packet Type Identifier seguidos por información adicional.

Este paquete no estándar toma la siguiente forma: