El protocolo AX.25 (3ª parte)

Autor: EA3CIW.
Publicado en: DIGICLUB Nº 3, Octubre 1988 (*).
Primera parte. Segunda parte. Tercera parte. Cuarta parte. Versión original.

Una vez comentados, en anteriores capítulos, algunos detalles de como está codificada la información, la estructura del paquete y, dentro de este, de quien viene y a quien va dirigido, veamos ahora el efecto que produce cada uno de ellos.

El campo de control

No sé si te acordarás, pero en la primera parte había un diagrama en el que se veían las distintas partes (campos) en que podemos dividir un paquete. El campo de control, cuyo tamaño es fijo de 8 bits, es el que indica que tipo de paquete es y que acción debe emprenderse.

Las distintas combinaciones de estos 8 bits dan una serie de posibilidades que trataremos aquí por sus nemónicos profesionales (X.25) y que son los que también usa el programa Digicom. Siempre será más agradable (?) que hacerlo con su código hexadecimal.

Existe una agrupación de estos tipos de paquetes en tres categorías generales: Información, Supervisión y No Numerados. Pero me inclino más por seguir una explicación "cronológica", dejando esta clasificación en segundo término.

La conexión

¿Qué es lo primero que hago? Pues conectarme con un corresponsal. Doy la orden C EA3RCN-2, con lo cual se envía un paquete de petición de conexión, que monitorizaremos así:

EA3CIW>EA3RCN-2>SABM:

Si la estación remota está libre, me confirma la conexión con un paquete tal que este:

EA3RCN-2>EA3CIW>UA:

Esta es la confirmación de que la conexión ha sido positiva, y provoca localmente la aparición del mensaje "*** Connected to EA3RCN-2", mensaje que, por supuesto, no ha sido enviado por el aire.

Si por contra hubieramos visto el mensaje de ocupado "*** Busy from EA3RCN-2", habría sido consecuencia de recibir este otro paquete:

EA3RCN-2>EA3CIW>DM:

O sea, que ya hemos visto el significado de tres de estos nemónicos: SABM, UA y DM, que junto con DISC, FRMR y UI constituyen la categoría de No Numerados.

El diálogo

Y empieza el intercambio de información (que es nuestro objetivo) mediante paquetes del tipo I:

EA3RCN-2>EA3CIW>I0: Bienvenido al buzón de ...

Que debe ser confirmado por nuestro equipo con un paquete RR (Receive Ready) al cabo del tiempo RESPTIME + DWAIT:

EA3CIW>EA3RCN-2>RR0:

Parece sencillo, ¿no? Pues tiene miga la cosa. Antes de seguir, hay que sentar una serie de conceptos.

Os habreis fijado que en el ejemplo anterior el paquete de información llevaba un número: I0, y que a su vez el de acuse de recibo también: RR0.

Podeis encontrar, en la práctica, estos paquetes numerados desde el 0 al 7 (contador de 3 bits). Empezando con el 0 en el momento de la conexión, se irá incrementando hasta llegar a 7, para posteriormente saltar a 0 y vuelta a empezar la numeración. Total, que podríamos enviar hasta 8 paquetes seguidos sin que se repitiese ningún número, aunque, para evitar confusiones, el máximo será de 7. Esto es lo que se llama ventana, y podemos ajustar con el MAXFRAME su tamaño, es decir, cuantos paquetes dejamos que se manden en una sola transmisión (valor entre 1 y 7).

Pero normalmente no se confirman los paquetes individualmente, sino por grupos, por ejemplo, si se envió:

EA3RCN-2>EA3CIW>I0: Bienvenido al buzón ...
EA3RCN-2>EA3CIW>I1: Tienes mensajes personales
EA3RCN-2>EA3CIW>I2: EA3RCN PBBS>

confirmando el último paquete recibido será suficiente para todo el grupo:

EA3CIW>EA3RCN-2>RR2:

Y así sucesivamente:

EA3CIW>EA3RCN-2>I0: L
EA3RCN-2>EA3CIW>RR0:
...

Resumiendo y ampliando: En cada estación existen 2 contadores de 3 bits: uno con la numeración del paquete enviado y otro con la del paquete recibido, que sirven para que no se pierda ninguno. Ambos contadores viajan dentro de los 8 bits correspondientes al campo de control de los paquetes de tipo I. En el caso de los RR sólo viaja el contador de recepción.

Esta sería la estructura del octeto de control de un I:

Fig. 2a. Campo de control de un paquete de Información.
7	6	5	4	3	2	1	0
N(R)			P	N(S)			0

donde:

N(R): contador de paquetes recibidos
N(S): contador de paquetes enviados
P: bit de "poll"

Obsérvese que el bit de peso más bajo es siempre "0" para los paquetes de Información.

Por contra, en un paquete RR, el campo de control tiene la siguiente estructura:

Fig. 2b. Campo de control de un paquete RR.
7	6	5	4	3	2	1	0
N(R)			P/F	0	0	0	1

en este caso:

P/F: bit de "poll/final"

Casos especiales

En el ejemplo aquel que se enviaban de una vez los paquetes I0, I1 e I2, supongamos que, por culpa del QRM, no se hubiera recibido correctamente el paquete I1, pero si los dos restantes. La respuesta hubiera sido:

EA3CIW>EA3RCN-2>REJ0:

El REJ significa rechazo, puesto que ha recibido el paquete I2 sin haber recibido el I1 (es obligatorio recibirlos consecutivamente, al menos en esta versión 2.0 que estamos comentando), pero confirma la recepción del I0. Esto provoca la inmediata (sólo espera DWAIT) repetición de I1 e I2 por parte de EA3RCN-2, incluso podría enviar ya el I3, si suponemos que había más información pendiente y el MAXFRAME era de 3.

Fig. 2c. Campo de control de un paquete REJ.
7	6	5	4	3	2	1	0
N(R)			P/F	1	0	0	1

Otro caso bastante frecuente es cuando se llena el buffer del corresponsal (nodos también) y nos manda un RNR (Receive Not Ready). Por ejemplo, RNR5 confirmaría el paquete I5, pero pediría a la estación remota que se abstenga de enviar más info hasta que se haya rebajado el buffer del TNC hacia el ordenador.

Fig. 2d. Campo de control de un paquete RNR.
7	6	5	4	3	2	1	0
N(R)			P/F	0	1	0	1

Tanto RR, como REJ y RNR pertenecen a la categoría de Supervisión, que se distingue en que sus bits de menor peso valen "01".

Comando-Respuesta (básico)

Mientras que en la versión 1.0 del AX.25, cuando un paquete I no recibía confirmación al cabo de FRACK segundos, se volvían a mandar todos los paquetes pendientes de confirmar (bastante largo), en la versión 2.0 se implementó la técnica comando-respuesta, que consiste en enviar sólo un paquete RR (muy corto) del tipo comando, para interrogar al corresponsal de si aún está en frecuencia y hasta que paquete recibió, con la intención de poder volver a mandar lo que falte. Por contra, el corresponsal ha de contestar con un paquete RR del tipo respuesta, en el que se indica el último paquete recibido.

En el siguiente ejemplo mostramos la presentación del monitor en el programa Digicom 2.00, donde P (poll) es el bit que distingue el comando de la respuesta, marcada F (final):

EA3RCN-2>EA3CIW>RR2,P
EA3CIW>EA3RCN-2>RR5,F

Además de los bits P y F, también interviene el bit C (ver SSID) del campo de dirección para distinguir entre un comando y una respuesta. Pero profundizar en eso ya sería objeto de ulterior estudio.

Los que nos faltan ...

Siguiendo con el ejemplo de una sesión habitual de packet, terminaríamos la misma dando la orden de desconectar a la TNC, lo cual provocaría el envío y recepción de los siguientes paquetes:

EA3CIW>EA3RCN-2>DISC:
EA3RCN-2>EA3CIW>UA:

Esta es la función de DISC: cerrar el diálogo iniciado con la conexión.

Otro tipo de paquete existente es el UI (Unnumbered Information), utilizado básicamente para enviar balizas, tal como ya veíamos en la segunda parte de este artículo:

EA3BRA/EA3G-1/EA3C-1>BEACON>UI:

Y por último tenemos el FRMR (Frame Reject), que indica que se ha producido un error de difícil recuperación. Generalmente esto provocará la desconexión de la sesión de trabajo.

Continuación

Federación Digital EA

DIGICLUB

El protocolo AX.25 (3ª parte)