Fig.1
En este documento se intenta dar una visión general sobre los distintos protocolos involucrados en una sesión de Packet Radio, la necesidad de una conversión entre ellos y la descripción de un dispositivo fundamental en la operación de Packet Radio: el TNC; con sus capacidades de operación y los distintos modos de trabajo soportados.
La comunicación entre dos equipos a través de un interfase serie se puede efectuar de varios modos. Fundamentalmente, la transferencia de datos se puede realizar, o bien caracter a caracter, o bien bloque a bloque, esto ese, transfiriendo bloques completos de caracteres agrupados de alguna manera bien definida. De acuerdo a esto, se habla de transferencias orientadas a caracter u orientadas a bloque. El fondo de la cuestión es conseguir una transferencia fiable de información entre los dos equipos; para ello, tanto un modo como otro, ha de poseer un método eficaz de sincronismo y control de los datos transferidos.
En las comunicaciones orientadas a caracter, también llamadas comunicaciones asíncronas, cada caracter a transferir contiene los elementos necesarios de control y sincronismo. En este caso (Fig. 1), cada caracter a transferir posee una longitud (número de bits) de información útil, mas dos bits de sincronismo: uno al comienzo (bit de start) y otro al final (bit de stop). Además, se suele incluir un bit mas de control, el bit de paridad, justo a continuación de los bits de información y antes del bit de stop. Este bit de paridad, que es opcional, depende del tipo de paridad aplicada a los bits de datos, pudiéndo ser paridad par o bien, impar. Según lo descrito, la longitud de cada caracter a transferir en bits (suponiendo caracteres de ocho bits) será: un bit de start mas ocho bits de datos, mas un bit de paridad mas un bit de stop; total: once bits. Con esta organización, la eficiencia de información útil con este método es del 72.7%.
Fig.1
En las comunicaciones orientadas a bloque, la transferencia de datos no se realiza caracter a caracter sino que se agrupa un número determinado de estos formando un bloque de información. Para el sincronismo de estos datos, al bloque, o también llamado paquete de datos, se le añade tanto al comienzo como al final, un caracter especial de sincronismo bien definido. Este caracter de sincronismo se suele denominar flag. Igualmente, para el control de bloque, se suele añadir uno o dos bytes de control cíclico de redundancia o crc, justo a continuación del último byte de información y antes del flag de cola del bloque. Según esto, y para un paquete de 128 bytes de información útil, la longitud del paquete será de 128 bytes mas dos de crc mas dos flags; total: 132 bytes. Con un paquete de estas características la eficiencia de información útil es del 96.9%.
En el caso de los PC's, los adaptadores standard de comunicaciones (los famosos COM) funcionan exclusivamente con el método asíncrono o start-stop, siendo, por tanto, útiles para la transferencia de datos en serie entre terminales o dispositivos asíncronos.
En el caso del Packet Radio, es bien conocido el uso del protocolo llamado AX25. Este protocolo, o método de intercambio de información, está orientado a bloques, transfiriendo la información agrupada en paquetes bien definidos de longitud variable. Estos paquetes de información tienen la siguiente estructura (Fig. 2):
Fig.2
Como se ha visto con anterioridad, el paquete de datos queda delimitado por dos flags. En este caso, el valor de los flags en AX25 es $7E. A continuación del primer flag de cabecera de paquete, aparece un campo, de longitud comprendida entre 14 y 70 bytes, en el que se indica el direccionado del paquete, esto es, el indicativo origen del paquete y la lista de indicativos destino del mismo (hasta ocho repetidores o digipeaters). Siguiendo al campo de direccionamiento, aparece un campo de control, de un byte, en el que se indica el tipo de paquete, a efectos de control de protocolo. A continuación de este campo de control, le sigue el campo de información, que puede contener hasta 256 bytes de datos útiles de usuario. Siguiendo a este campo de datos, aparece dos bytes de control de paquete (Frame Check Sequence), finalizando este con un flag de cola. La descripción del campo de control, los tipos de paquete y el intercambio de paquetes según el protocolo AX25, se escapa al ámbito de esta discusión.
Para transferir información digital a traves de un medio analógico, como pueda ser un canal de radio, es preciso transformar, de alguna manera, esa información digital en analógica y viceversa. Esto se realiza mediante un modem (MOdulador / DEModulador) que transformará los '1' y '0' lógicos en distintos tonos de audio, de acuerdo a una norma bien establecida. En el caso del Packet Radio, es preciso usar uno de tales modems para conectar una emisora a un PC y poder establecer una sesión.
Sin embargo, como se ha visto con anterioridad, el protocolo usado por la red de Packet Radio es el AX25, orientado a bloque, muy distinto del protocolo asíncrono, orientado a caracteres usado por el PC en sus puertos de comunicaciones. Por tanto, para poder usar un PC en Packet Radio, es preciso utilizar algun sistema o programa que permita la conversión de protocolos. Genéricamente, estos convertidores de protocolos se denominan PAD (Packet Assembly Disassembly) o ensambladores / desensambladores de paquetes. Esta función PAD puede estar soportada, o bien por un programa externo (el bien conocido TFPCX en el SP o GP), o bien por un tipo especial de modem para Packet Radio: el TNC.
Un TNC o Terminal Node Controller es un dispositivo adaptado al uso de Packet Radio que contiene, fundamentalmente, uno o varios modems para distintas velocidades, y un PAD, soportado por un microprocesador mas su memoria RAM / ROM y toda su lógica asociada, de forma que este PAD, o programa grabado en el firmware del microprocesador, por una parte se comunique con el PC en protocolo asíncrono y por otra, mantenga todo el protocolo AX25 frente al modem integrado y la radio conectada.
Adicionalmente, un TNC dispone de manera habitual, de un programa dedicado a buzón personal o PBBS, y otras facilidades tales como capacidad de NODO repetidor o GATEWAY, permitiendo el flujo de paquetes entre dos canales distintos en un TNC multipuerto. Estas facilidades son autónomas, de forma que no es preciso la actividad de un programa en el PC conectado al TNC para su funcionamiento.
Como se ha visto con anterioridad, un TNC es un dispositivo dotado de una cierta inteligencia, que permite establecer sesiones de Packet Radio, en protocolo AX25, presentando todo el flujo de información en formato asíncrono. Normalmente, el TNC, una vez conectado, queda en Modo Terminal, esto es, queda funcionando la parte de su programa dedicada a la función PAD. En este modo de trabajo, el TNC entrega al PC toda la información recibida perfectamente decodificada, controlada y libre de cabeceras de formato AX25 (a excepción de los paquetes de monitor, a los que le añade la cabecera, convenientemente decodificada, con propósito de información cara al usuario). En este modo, el TNC ofrece toda una serie de facilidades para la edición de las líneas de información que van a formar los paquetes a transmitir al corresponsal. Estas facilidades de edición incluyen el borrado del último caracter introducido, la cancelación de la línea en curso, la visualización del buffer de entrada del PAD o el fin de línea y orden de formación de un paquete y su retransmisión. Estas facilidades de edición se dan mediante caracteres de control tales como el Ctrl-H, Ctrl-X, Ctrl-R o Ctrl-M. De cualquier modo, el TNC dispone de comandos para alterar los caracteres de control asociados a cada una de estas funciones de edición, tales como SENDPAC, REDISPLAY o CANLINE.
Por otra parte, cuando el TNC se utiliza en modo PAD, el diálogo entre el y el PC se arbitra mediante un control de flujo, de manera que el PC pueda indicar al TNC que detenga la transferencia de información o la continúe. Este control de flujo se puede establecer de dos maneras: bien mediante caracteres de control (los caracteres XON y XOFF, correspondientes a Ctrl-Q y Ctrl-S, respectivamente) o bien mediante las señales de control del interfase RTS y CTS. En el primer caso se habla de control de flujo por software, mientras que en el segundo se habla de control de flujo por hardware. Obviamente, para implementar el control de flujo por hardware es preciso que el cable de conexión entre el TNC y el PC tenga cableadas ambas señales.
Igualmente, en modo PAD, el TNC acepta un caracter de control específico para pasar a modo Comando, esto es, a dejar pendiente un QSO y entrar en comunicación directa con los comandos del propio TNC. Habitualmente, este caracter de control es el Ctrl-C, o el indicado en el parámetro COMMAND.
Con lo visto hasta ahora, la función PAD del TNC ofrece las facilidades necesarias para el establecimiento de una manera sencilla, sesiones de Packet Radio, conectando este TNC a un PC, y usando un sencillo programa de terminal. Sin embargo, si se desea hacer transferencias binarias a traves de una sesión de Packet Radio, la presencia de todos los caracteres de control descritos con anterioridad son un auténtico problema. Para solventar esto, todos los TNC, en su función PAD, incluyen un modo de trabajo especial, el llamado modo Transparente, en contraposición al modo Convers visto hasta ahora. En este modo transparente, el TNC no reconoce ningún caracter de control, ni siquiera los caracteres de control de flujo por software, sino que considera todos ellos como caracteres válidos de información a transferir; en este modo, el control de flujo se realiza por hardware mediante las señales del interfase RTS y CTS. Para la transmisión de un paquete de datos en modo transparente, el TNC no usa el caracter parametrizado en SENDPAC (Ctrl-M, habitualmente), sino que transmite los paquetes AX25 regularmente, según el intervalo de tiempo parametrizado en PACTIME. En este modo, los paquetes se transmiten con la longitud indicada en PACLEN, transmitiendo el número de paquetes indicados en MAXFRAME en intervalos regulares indicados en PACTIME. Igualmente, en modo transparente, no existe ECHO de caracteres. Para entrar en modo transparente se da el comando 't', mientras que para salir a modo convers es preciso seguir una secuencia bien definida: o bien se entrega al TNC una señal BREAK por el interfase (si este lo soporta), o bien se sigue la siguiente secuencia:
Tal cómo se ha visto hasta ahora, la función PAD del TNC simplifica la tarea de conversión de protocolos y comunicación con el usuario de Packet Radio; sin embargo, esta misma facilidad tiene una limitación intrínseca: solo funciona como un terminal, liberando al programa de aplicación de cualquier manejo de protocolo AX25. Esto es bueno y malo a la vez, ya que impide la utilización de otros protocolos de mayor nivel que el AX25, tales como el NET/ROM para nodos, o TCP/IP para red. Igualmente, impide la confección de programas de usuario mas amigables que separen en distintas ventanas las distintas sesiones simultáneas de Packet Radio que el usuario desee tener, o separe la presentación de monitor y sesión.
Para evitar estos problemas, se estableció un protocolo para los TNC, lo mas sencillo y transparente: el protocolo KISS (Keep It Simply Stupid). Este protocolo presenta la información recibida en modo paquete AX25, en paquetes iguales pero con formato asíncrono, esto es, añadiendo a cada byte del paquete los bits de start, stop y paridad, de modo que el PC sea capaz de reconocerlos; por tanto, la transferencia entre el PC y el TNC se realiza mediante paquetes de caracteres asíncronos, en los que se incluye toda la información de cabecera y control AX25. En este caso, el TNC no mantiene el protocolo; símplemente lo transmite al PC. Esto deja una gran flexibilidad de operación al programa de aplicación, teniendo como contrapartida una complejidad mucho mayor del programa de aplicación y la pérdida de facilidades del TNC, como el PBBS y el NODO.
Algunos fabricantes de TNC, tales cómo MFJ o Kantronics, dotan a sus TNC de otro modo de funcionamiento: el modo HOST. En este modo, el TNC transfiere la información al PC, no caracter a caracter como en el modo PAD, sino en bloques de caracteres asíncronos, flanqueados por caracteres de sincronismo, de manera similar al modo KISS, pero manteniendo el TNC todo el protocolo AX25 y conservando las facilidades de PBBS y NODO. En este modo, cada bloque de datos a transferir lleva su propia cabecera, en donde se indica el tipo de paquete (comando, monitor, control, estado o datos), el puerto, y el canal a que corresponde ese paquete. Esta organización permite la confección de programas de aplicación áltamente eficientes y amigables, tales como el HostMaster de Kantronics.
En resumen: Un TNC es un dispositivo dedicado al trabajo en Packet Radio, que ofrece la facilidad de conversión de protocolo AX25 a asíncrono, con facilidades de PBBS y NODO autónomas, capaz de funcionar en los modos siguientes:
Modo KISS: Encapsulado en paquetes asíncronos.
Modo HOST: Encapsulado en paquetes asíncronos.
Desde los primeros tiempos de la informática, surgió la necesidad de conectar distintos ordenadores, o terminales de estos, entre sí. Por ejemplo, empresas que poseían un ordenador de gestión en su central, necesitaban conectar distintos terminales repartidos en distintas sucursales de estas a lo largo de toda la geografía nacional; o intercambiar datos entre otros ordenadores de otras compañías. Dada la gran variedad de marcas y modelos de ordenadores, y de distintos programas de aplicación, estas conexiones representaban un auténtico quebradero de cabeza.
Ante la gran variedad de equipos informáticos a interconectar por distintos medios (por conexión directa entre ellos, o a través de una línea de transmisión), surgió la necesidad de establecer unas reglas de juego, o protocolo, como método de interconexión e intercambio de datos entre distintos ordenadores. Para ello, surgieron varias oficinas internacionales de normalización, que crearon las recomendaciones necesarias para el establecimiento de los distintos protocolos de conexión entre ordenadores. Como quiera que la conexión distante entre ordenadores se efectuaba usando líneas telefónicas, fue, precisamente, un comité internacional de compañías telefónicas, el CCITT (Comité Consultivo Internacional de Telegrafía y Telefonia), el que se encargó desde un principio de establecer las recomendaciones necesarias para la interconexión entre ordenadores. Estas recomendaciones afectan tanto al medio físico de la conexión, como niveles de señales, numero de señales a usar, conectores, tonos y demas; como al medio lógico, como organización de los bytes a transferir. Por otra parte, el trabajo mas significativo en el establecimiento de standares internacionales para la interconexión de distintos sistemas de ordenadores (lo que habitualmente se denomina Sistemas Abiertos), se debe a la organización ISO (International Standarization Organization). El primer paso para el establecimiento de una arquitectura abierta de interconexión, frente a las arquitecturas propietarias de cada marca de ordenadores, la dió en 1977 el comité ISO desarrollando un modelo de referencia para la interconexión de Sistemas Abiertos (OSI, Open System Interconnection). Este modelo es la base para la coordinación y desarrollo de standares para cualquier tipo de comunicación entre ordenadores.
En 1983 se creó un modelo de referencia para solventar el problema de la interconexión entre Sistemas Abiertos: el ISO 7498.
Este modelo está organizado en capas o niveles (Layers), a
fin de de dividir los problemas de una interconexión en partes
mas pequeñas y manejables. Este modelo de referencia
identifica las funciones necesarias para que los ordenadores
interconectados puedan transferir información de una manera
fiable.
La organización en capas asegura modularidad y la facilidad
para la adaptación del software de red con independencia de la
procedencia de este.
El modelo está organizado en siete capas o niveles, tal
cómo se ilustra en la Fig.3.
Fig.3
Tal cómo se observa en la figura, dos Sistemas Abiertos interconectados implementan los mismos standares en cada nivel, y dos entidades cualquiera que pertenezcan al mismo nivel en el sistema correspondiente, se comunican mediante un protocolo común. Cuando un sistema transmite un mensaje, este pasa del nivel 7 al 1 del sistema emisor, y cada nivel le añade una cabecera o trata el mensaje de alguna forma; se transfiere por el medio de interconexión, y llega desde el nivel 1 al nivel 7 del sistema receptor, eliminándose las cabeceras y reconstruyendo el mensaje. Cuando las funciones de un nivel particular no son necesarias, se emplea un nivel nulo.
Cada nivel ofrece servicios específicos al nivel superior, y la comunicación lógica tiene lugar entre los niveles correspondientes de los dos sistemas. Los datos no se transmiten directamente entre los niveles, excepto en el nivel físico, en el que existe una interconexión física entre ambos sistemas.
Los niveles 1 al 3 proporcionan los protocolos de bajo nivel, habitualmente implementados en el hardware de los equipos o mediante controladores dedicados, mientras que los niveles 4 al 7 proporcionan los protocolos de alto nivel, normalmente implementados en el software de los sistemas interconectados.
El nivel 1 asegura la compatibilidad de los interfases físicos, proporcionando la transmisión física de los datos a traves del medio, definición de conectores, señales de control, velocidades de transmisión y definición de señales a nivel de interfase.
El nivel 2 asegura la compatibilidad de los protocolos del nivel de enlace que proporcionan una transmisión libre de errores, así como el acceso al medio de comunicaciones. Este nivel controla el establecimiento y liberación de un enlace, organiza los mensajes en paquetes, dividiendo estos en paquetes de datos y de control o sincronismo, detecta y corrige errores de comunicacion, organiza el control de flujo de datos y la retransmisión de paquetes y supervisa la conexión física.
El nivel 3 establece el camino de la transmisión y las conexiones de red utilizando enlaces protegidos frente a errores, posiblemente mediante nodos intermedios de conmutación y mediante varios sistemas terminales. También define cómo pueden compartir un enlace varias conexiones de red, determinando las conmutaciones y direccionamiento que debe sufrir un mensaje, y el orden de los paquetes en un sistema de conmutación de paquetes.
El nivel 4 es el responsable del establecimiento, control y liberación de las conexiones de transporte entre entidades de nivel superior. Una conexión de transporte es una conexión extremo a extremo entre los sistemas de comunicaciones, que pueden hacer uso de varias conexiones de red suministradas por el nivel 3.
El nivel 5 establece la relación entre los participantes de la comunicación de una manera ordenada y sincronizada, determinando qué conexión de transporte se asociará a la sesión. El control de sesión incluye la cesión del derecho a transmitir en el caso de sistemas half-duplex.
El nivel 6 adapta el formato de los datos de una aplicación a un formato adecuado para los sistemas de comunicación. Los protocolos de presentación definen las reglas relativas a cómo se presentarán e intercambiarán los datos en un lenguaje común y neutral, es decir, puede ser necesario traducir datos expresados en caracteres ASCII a EBCDIC, o de formato de punto fijo a formato de punto flotante.
El nivel 7 lleva los servicios de red al usuario final, definiendo cómo deben funcionar dos usuarios del sistema de comunicaciones. Este es el nivel mas alto en dos sistemas interconectados.
Para ilustrar las funciones de cada uno de los niveles del modelo ISO, se puede hacer una analogía entre una sesión ISO y una llamada telefónica:
Un medio físico (la línea telefónica) enlaza los dos equipos de comunicaciones, y el nivel 1 (físico) asegura que las señales vocales sean transformadas en señales eléctricas adecuadas para ser transmitidas en un extremo de la línea y que las señales recibidas se conviertan en voz en el otro extremo. El nivel 1 define el tipo de conector a usar por los teléfonos, el propósito de cada patilla del conector y los niveles de señal de cada una de estas patillas.
El nivel 2 (enlace) garantiza que siempre que una palabra no sea claramente recibida, se indicará esta situación al emisor para que la repita. La clave que se usará para solicitar la retransmisión de una palabra se acordará de antemano para evitar confusiones. Si el sistema telefónico permite mantener conversaciones en las que intervengan mas de dos personas, el nivel 2 definirá el proceso para controlar quien habla. Una persona que ha terminado de hablar puede decir "cambio" o, simplemente, permanecer en silencio. Entonces, cualquiera que está esperando puede empezar a hablar.
El nivel 3 (red) establece la llamada, proporcionando un mecanismo para conectar con el número de la persona con la que desea comunicar el llamante. Al oir el timbre del teléfono, la persona llamada descuelgay, si el sistema telefónico ha direccionado correctamente, la comunicación comienza; en otro caso, la persona que recibe la llamada indica al que llama que se ha equivocado y este vuelve a marcar. Si la persona llamada tiene una extensión de centralita, la operadora direccionará la llamada a la extensión apropiada.
El nivel 4 (transporte) se emplea para asegurar que los mensajes solicitados se envían sin pérdidas. Si la calidad de la línea se degrada, ambas partes pueden acordar interrumpir la llamada colgando, y una de ellas volverá a marcar para establecer la comunicación. Si la persona que contesta al teléfono no es la deseada, habrá que buscar a la persona correcta. Si la persona ha cambiado de número, se determinará cual es el nuevo número. Cuando la conexión de transporte ya no es necesaria, ambas partes se despiden y cuelgan.
En el nivel 5 (sesión) se proporcionan protocolos que permiten al que llama establecer una sesión con la otra persona en la oficina a la que llama, preguntando por esa persona e identificándose. Si una de las dos partes que intervienen en la llamada está ocupada atendiendo otra sesión, la misma sesión se puede establecer mas tarde utilizando otra conexión de transporte. Cuando las dos personas que intervienen en una llamada telefónica no pueden hablar de forma simultánea, se establece un flujo de control entre ambas, observando cuando ha terminado de hablar la otra parte; otra alternativa consistiría en decir "cambio", para invitar a la otra persona a hablar.
En el nivel 6 (presentación) se resuelven los problemas del lenguaje. Si ambas partes no hablan la misma lengua, pero ambas hablan esperanto, el nivel 6 puede especificar que la conversación se realice en esperanto. Si el asunto que se discute es confidencial, puede acordarse la utilización de palabras clave para identificar algunos términos.
El nivel 7 (aplicación) depende de la forma en que las dos personas que se comunican desean intercambiarse el mensaje. Si la conversación va a tratar sobre apuestas de carreras de caballos, puede acordarse utilizar un protocolo que consista en citar el nombre de un caballo seguido de la apuesta que se hace sobre el.
Las comunicaciones en Packet Radio siguen, como cualquier otro tipo de comunicación entre sistemas abiertos, el modelo ISO/OSI. En este caso, y debido a la relativa complejidad de las redes de Packet Radio, se suele utilizar los niveles uno, dos y tres, y en determinados casos, el cuarto. El resto de niveles queda englobado en el nivel de aplicación, es decir, en el programa de usuario de red de Packet Radio.
En el nivel uno se establece los requerimientos físicos del medio. En el caso del Packet Radio, estos requerimientos se refieren al tipo de modulación a usar en un canal, a la velocidad de transferencia de datos y a los tonos usados para la modulación. En términos generales, los requisitos de nivel uno en Radio Packet son los siguientes:
HF: En las bandas de HF se usa una modulación en Banda Lateral Inferior (LSB), con una velocidad de transferencia de datos de 300 baudios, usando la norma BELL 103 para los tonos de modulación. En esta norma, el desplazamiento de tonos es de 200 Hz, y a diferencia de la misma, el modo de trabajo es Semi-Duplex.
VHF: En la banda de VHF (2m), y ocasionalmente en UHF (70cm), se usa Modulación de Frecuencia, con una velocidad habitual de transferencia de datos a 1.200 baudios, no estando excluídas otras velocidades de transferencia, como 2.400 baudios. La norma que se sigue es la Bell 202, con desplazamiento de tonos de 1000 Hz y un funcionamiento Semi-Duplex.
UHF: En bandas de UHF se suele usar igualmente Modulación de Frecuencia, con velocidad de transferencia de 1.200 baudios, pero con canales de ancho de banda mayor que 25 KHz, se suele utilizar PSK a 9.600 baudios. Igualmente, y con condicionantes de ancho de banda y equipos, es posible un funcionamiento Full-Duplex.
El nivel dos establece los requerimientos de enlace. En el caso del Radio Packet, el nivel dos está standarizado el uso del protocolo AX25. Este es un protocolo de comunicaciones derivado del standard X25, orientado a bloque o paquetes, que permite el uso de canales compartidos, y múltiples sesiones por usuario. Una descripción mas detallada de este protocolo queda fuera del alcance del presente documento.
El nivel tres establece los requisitos de red. En las redes de Packet Radio se usa el protocolo NET/ROM. Este es un protocolo definido exclusivamente para redes de Radio Packet, y proporciona el ruteo adecuado de mensajes entre distintos nodos o repetidores digitales de Packet Radio, proporcionando rutas seguras entre sesiones AX25. Cara al usuario, este nivel de red está implementado en los programas TheNet o BPQ de los nodos digitales.
Ultimamente es frecuente en Packet Radio el uso de programas TCP/IP. En este sistema se organizan los niveles de red y transporte con los protocolos TCP (Transmission Control Protocol) e IP (Internet Protocol), dotando de una flexibilidad adicional a las redes de Packet Radio.
El resto de niveles de la recomendación ISO, están agrupados en los programas de aplicación de usuario de una red de Packet Radio.
Cada vez es mas habitual el uso de ordenadores personales en nuestros cuartos de radio, como complemento de nuestros equipos, usándolos para el mantenimiento de libros de guardia, control de emisoras y, fundamentalmente, para el trabajo en otras modalidades de transmisión distintas a la fonía, las llamadas digitales, tales cómo RTTY, AMTOR y, sobre todo, Radio Packet.
Uno de los aspectos mas interesantes en el uso de ordenadores personales es el de la INTERCONECTIVIDAD entre distintos ordenadores, o distintos periféricos a estos ordenadores, a traves de un interfase serie, es decir, un interfase en el que los datos se propagan en serie, bit a bit. Para poder obtener un buen partido en el uso de estos ordenadores personales, tanto en comunicaciones digitales como en la conexión a estos de ciertos periféricos para comunicaciones, es preciso conocer como se establecen estas OTRAS TRANSMISIONES, y de los distintos standares establecidos al respecto.
La comunicación entre ordenadores es un procedimiento habitual desde hace bastantes años, y para ello, existen varias oficinas internacionales dedicadas a establecer los standares adecuados. De estas oficinas, las mas conocidas son la EIA americana y la CCITT europea.
La norma que establece las características de un interfase en serie, para el intercambio de información entre dos ordenadores o un ordenador y un periférico, es la norma V24 europea, o RS232 americana. Ambas normas son equivalentes.
Esta norma V24 establece los requisitos físicos a cumplir por el interfase. En primer lugar, establece los niveles de tensión de las señales a usar: Una señal con tensión comprendida entre +3 y +15v se considera como un '1' lógico, mientras que una señal con una tensión comprendida entre -3 y -15v se considera como un '0' lógico. (Ver Fig. 4). Cualquier tensión no comprendida dentro de estos umbrales, se considera inválida.
Fig.4
Como consecuencia de estos niveles de señal, la norma V24 garantiza un funcionamiento fiable del interfase para una longitud máxima de 25m, mientras que la norma RS232 garantiza un funcionamiento fiable con una longitud máxima de 100 pies (unos 30m).
En segundo lugar, la norma V24 establece el tipo de conector a usar en ese interfase. El conector debe ser del tipo DB25 de 25 pines; cualquier otro conector no está normalizado. Este conector será MACHO cuando esté situado en el ordenador, y HEMBRA, cuando esté situado en cualquier otro periférico, como un modem, TNC o impresora.
En tercer lugar, la norma V24 establece las señales de datos, control y sincronismo a usar en el interfase, así cómo el protocolo físico a establecer con estas señales, entre los dos participantes en el interfase. El conjunto de estas señales son: dos, para los datos a emitir / recibir; seis, para el control de protocolo; tres, para los relojes de sincronismo, y dos para las tierras / neutros de retorno.
Antes de describir cada una de estas señales, y a efectos de comprensión, es preciso definir algunos conceptos: En principio, esta norma se desarrolló para la conexión de un equipo terminal de datos, o un ordenador, a un equipo modulador / demodulador (modem), capaz de convertir los datos digitales suministrados por el ordenador, en tonos analógicos susceptibles de ser transmitidos a traves de un medio analógico tal como una línea telefónica, y convertir los tonos recibidos por ese medio, en señales digitales tratables por ese ordenador conectado. Según esto, se estableció el concepto de equipo terminal de datos, o DTE (Data Terminal Equipment), y el de equipo de modulación / demodulación, o DSE (Data Set Equipment). Es este trabajo, se usará ámpliamente esta terminología.
Las señales normalizadas para el interfase V24 son las que se detallan a continuación, apareciendo en primer lugar la abreviatura usada para ella, a continuación, el nombre según la norma DIN, y en tercer lugar, el nombre dado por la CCITT.
| TXD | D1 | 103 | TRANSMIT DATA | Datos transmitidos desde el DTE hacia el DSE, para su transformación en señales analógicas a transmitir por el medio. Esta señal está presente en el pin 2 del conector. |
| RXD | D2 | 104 | RECEIVED DATA | Datos recibidos por el medio desde el DSE. Esta señal está presente en el pin 3 del conector. |
| DTR | S1 | 108 | DATA TERMINAL READY | Señal de control enviada por el DTE hacia el DSE, indicando a este que el DTE se encuentra preparado para cualquier operación en el interfase. Esta señal está presente en el pin 20 del conector. |
| DSR | M1 | 107 | DATA SET READY | Señal de control, enviada por el DSE hacia el DTE, indicando a este que el DSE se encuentra preparado para cualquier operación en el interfase. Esta señal está presente en el pin 6 del conector. |
| RTS | S2 | 105 | REQUEST TO SEND | Señal de control, enviada por el DTE hacia el DSE, indicando a este una petición de emisión de datos por parte del DTE. Esta señal está presente en el pin 4 del conector. |
| CTS | M2 | 106 | CLEAR TO SEND | Señal de control, enviada por el DSE hacia el DTE, indicando una confirmación a la petición de transmisión (RTS) solicitada por el DTE. Esta señal está presente en el pin 5 del conector. |
| DCD | M5 | 109 | DATA CARRIER DETECT | Señal de control, enviada por el DSE hacia el DTE, indicando a este la presencia de portadora en el medio, y por tanto, datos a recibir. Esta señal está presente en el pin 8 del conector. |
| RI | M3 | 125 | RING INDICATOR | Señal de control, enviada por el DSE hacia el DTE, indicando a este una llamada en progreso, o una petición de conexión. Esta señal está presente en el pin 22 del conector. |
| TXC | T1 | 114 | TRANSMIT CLOCK | señal de reloj, entregada por el DTE, para el sincronismo de transmisión. Esta señal está presente en el pin 15 del conector. |
| RXC | T2 | 115 | RECEIVE CLOCK | Señal de reloj, entregada por el DTE, para el sincronismo de recepción. Esta señal está presente en el pin 17 del conector. |
| ETXC | T4 | 113 | EXTERNAL CLOCK | Señal de reloj, entregada por el DSE, para el sincronismo de transmisión / recepción. Esta señal está presente en el pin 24 del conector. |
| SHD | E1 | 101 | SHIELD | Malla o tierra del cable de conexión del interfase. Esta señal está presente en el pin 1 del conector. |
| SG | E2 | 102 | SIGNAL GROUND | Neutro o retorno de señales del interfase. Esta señal está presente en el pin 7 del conector. |
Con estas señales, la norma V24 establece un protocolo de conexión entre dos equipos de datos, un DTE y un DSE, de la siguiente forma:
Esta es la fase previa a una transferencia de datos entre un DTE y un DSE. En ella, el DTE envía al interfase la señal DTR (Data Terminal Ready), indicando al DSE qu el equipo terminal de datos está dispuesto para una sesión de comunicación. Igualmente, el DSE envía al interfase la señal DSR (Data Set Ready), indicando con ello que ese dispositivo se encuentra listo para la transferencia de información. Ambas señales deben permanecer activas durante toda la sesión de comunicación.
En esta fase, el DTE necesita transmitir datos al interfase; para ello, envía la señal RTS (Request to Send), indicando al DSE una petición de emisión. Una vez que el DSE está preparado para transmitir (esto es, modular la señal digital), se lo indica al DTE por medio de la señal CTS (Clear to Send), con lo que el DTE puede comenzar a transmitir los datos a traves de la línea TXD. La Fig.5 muestra la cronología de estas señales en el interfase.
Fig.5
Según se observa en el cronograma, el DTE no manda los datos al interfase mientras no reciba la señal CTS como confirmación a la petición de emisión. Por otra parte, si el DSE es un modem, suele existir un retardo entre la llegada de la señal RTS y el envío de CTS, debido al tiempo de conmutación de la circuitería del modem para pasar de modo recepción a emisión, y viceversa.
En esta fase, en la que el DSE detecta datos en el medio de transmisión, con destino al DTE, la única señal de control utilizada es la generada por el DSE, siendo esta, DCD (Data Carrier Detect), e indicando con ella, la presencia de portadora y datos en el medio. A partir de ese momento, el DSE envía los datos recibidos al DTE por la línea RXD, según se observa en el cronograma de la Fig.6.
Fig.6
A diferencia con la fase de transmisión, en la fase de recepción no hay confirmación de la señal de control enviada por el DSE ni retardo entre esta señal de control y los datos recibidos.
Se ha visto anteriormente que la norma V24 define tres señales de reloj. El significado de las mismas es el siguiente: Cuando se transfiere datos digitales de un equipo a otro, estos datos deben estar sincronizados convenientemente, ya que cada equipo dispone de sus propios relojes de sincronismo, y estos no tienen porque encontrarse en fase. Cuando en un interfase V24, el DSE es un modem, para la sincronización de estos datos éste usa un solo reloj de sincronismo, que puede mandar al interfase a traves de la línea ETXC. En tal caso, el DTE utiliza la señal de reloj suministrada por el modem, hablándose de sincronismo síncrono. En el caso en que las señales de sincronismo las suministre el DTE, este envía al interfase dos señales de reloj, una para el sincronismo de emisión (TXC) y otra para el sincronismo de recepción (RXC). En tal caso, el modem no entrega señales de reloj al interfase y se habla de sincronismo asíncrono.. Naturalmente, en una conexión a traves de un interfase V24 solo puede existir un reloj de sincronismo: o bien lo entrega el DSE, a traves de la linea ETXC, o bien lo entrega el DTE a traves de las líneas TXC y RXC.
En el interfase V24 están previstas dos líneas de protección: Una tierra de protección (SHD), y un neutro de retorno de señales (SG). Habitualmente, la primera línea no se usa, y en la segunda se conecta la malla del cable utilizado para al interfase.
En transmisión de datos se habla de comunicaciones síncronas o asíncronas, según el método a utilizar para el sincronismo de los datos a modular / demodular por el DSE. En el caso de comunicaciones síncronas, los datos emitidos y recibidos por el DTE se empaquetan formando bloques de bits de longitud variable, y de la manera indicada por el protocolo de comunicación utilizado; la sincronización de estos datos se realiza por las señales de reloj previstas en el interfase. En el caso de comunicaciones asíncronas, no se usa estas señales de reloj, ya que la transmisión se efectúa sincronizando cada caracter mediante los flancos de subida y bajada de dos bits extra añadidos a cada caracter: estos son los bits de Start y Stop.
Fig.7
El modo de comunicación síncrona, se reserva para la transmisión de datos orientada a paquete, con protocolos de alto nivel, tales cómo BCD, BSC, HDLC, etc. mientras que las comunicaciones asíncronas se ulitizan para las comunicaciones orientadas a caracter con protocolos de bajo nivel, tal cómo emulación de terminales, teletipos, impresoras serie, etc. Este es el tico de comunicación previsto en todos los PC's y compatibles, como canales de comunicación serie.
Comunicaciones asíncronas: Como se ha indicado anteriormente, este es el modo de comunicación mas usado en los sistemas informáticos domésticos, usando, para ello, un interfase V24 / RS232. Este método de comunicación está orientado a caracter, con sincronización mediante los flancos de los bits de Start y Stop, y sin uso de relojes de sincronismo. Adicionalmente, se suele usar un bit de paridad para cada caracter, quedando la trama de la siguiente forma:
Fig.8
Tal como se muestra en la figura, la trama queda compuesta por:
Tanto el número de bits de información del caracter, como los bits de STOP y PARIDAD, suelen ser configurables bien por software como por hardware en estos equipos.
Como se ha visto hasta ahora, la norma V24 contiene las suficientes señales de control para garantizar una comunicación fiable entre dos sistemas informáticos. En el caso de equipos domésticos, tales cómo PC's, la utilización de este interfase se simplifica al usar comunicaciones asíncronas. por lo que no son necesarias señales de reloj. A continuación se muestra los casos mas habituales de conexión de un canal V24 / RS232 en un PC.
Para conectar un PC a un modem, a traves de un canal de comunicación asíncrona, tal cómo el COM1 - COM4 de un PC, son necesarias todas las señales de control, a excepción de las de reloj, ya que se va a utilizar un modo de comunicación asíncrona. En este caso, el interfase se debe establecer tal cómo muestra la fig.9.
Fig.9
Tal como se muestra en la figura, se usa un cable con todas las señales de control establecidas.
Si la conexión va a ser permanente, y no se desea usar un cable con tantos hilos, se puede eliminar los hilos correspondientes a las señales DTR y DSR, en ambos extremos, sustituyéndolos por puentes en los conectores de cada uno de los extremos del cable, tal cómo se muestra en la fig.10.
Fig.10
Para efectuar una conexión entre dos PC's o un PC y un terminal, en forma directa, -esto es, sin usar modem-, y usando un interfase V24, es preciso hacer el siguiente razonamiento: ambos participantes en el interfase son DTE's, no existiendo ningún DSE. Por tanto, la señal TXD del primer PC debe llegar a la línea RXD del segundo PC, y viceversa. De esta manera, cuando el primer PC transmita algo, le llegará al segundo PC por la línea de recepción del interfase. Según esto, y en principio, el cable de conexión entre esos dos PC's será:
Fig.11
En cuanto a las señales de control a utilizar, el razonamiento es similar: Cuando el primer PC esté listo, ha de mandar la señal DTR al interfase y viceversa. Ambas señales deben llegar a las líneas DSR de cada PC, a fin de informar sobre la disponibilidad de la línea; por tanto, el cable de conexión quedará en la forma:
Fig.12
Como se ha visto en el caso anterior de conexión a modem, estas dos últimas señales se pueden sustituir por puentes en ambos extremos del interfase, con lo cual, el cable quedaría configurado en la forma:
Fig.13
En cuanto al resto de señales de control del interfase, se hace el siguiente razonamiento: cuando el primer PC desea transmitir, debe enviar al interfase la señal RTS, no comenzando la transmisión hasta recibir la señal CTS desde el otro extremo del interfase. Por otra parte, y al tratarse de una conexión directa, no existe retardo entre las señales RTS y CTS, con lo que se puede puentear ambas señales. En el otro extremo, se debe recibir la señal DCD, informando de la presencia de datos a recibir, por lo que el puente establecido entre RTS y CTS en el extremo del primer PC, se debe conectar a la señal DCD en el extremo del segundo PC. En la Fig.14 se muestra el esquema definitivo del cable a usar para la conexión entre dos PC's o un PC y un terminal, usando un interfase V24.
Fig.14
Con un cable de este tipo, funcionaría correctamente una conexión serie, a traves de un interfase V24 entre dos PC's o dos equipos funcionando con un protocolo asíncrono.
La conexión de un PC a una TNC de Radio Packet, es exactamente igual a la conexión entre un PC y un modem, por lo que vale el mismo tipo de cable. Hay que hacer notar que esto no se aplica a modems para radio del tipo BayCom, HamCom o Expert. Esto es debido a que en estos tipos de modem, el software que los usa no trata el interfase de manera standard, por lo que para la conexión de tales modems ha de consultarse la documentación suministrada con los programas que los manejan.
A menudo es preciso adaptar circuitería TTL/CMOS al interfase V24, por ejemplo, a la hora de realizar un interfase RTTY , CW o modem para Radio Packet. Como se ha visto con anterioridad, los niveles de las señales V24 son de +5 a +15V para el nivel lógico '1' y -5 a -15V para el nivel lógico '0', mientras que para la circuitería TTL, estos niveles son +5 y 0V respectivamente. Para adaptar estos niveles, existe distintos circuitos integrados diseñados al respecto, tales cómo los 1488 y 1489, o el MAX232. No obstante, una buena solución es la utilización de acopladores ópticos: una descripción excelente de estos se da en un artículo de EA3NJ aparecido en la revista de URE correspondiente al mes de Noviembre de 1.991.
Afortunadamente, la mayoría de circuitos integrados digitales que usan el interfase V24 utilizan niveles TTL negados para las señales del interfase (esto es, +5V para el '0' lógico y 0V para el '1' lógico). Esto simplifica la adaptación a los niveles del interfase V24 mediante acopladores ópticos, ya que estos circuitos invierten el nivel de la señal. En la Fig. 15 se muestra dos circuitos para la adaptación de niveles TTL negados a V24.
Fig.15
La figura de la izquierda adapta niveles TTL negados a V24, mientras que la derecha adapta niveles V24 a lógica TTL negada.
En el circuito de la izquierda, T1 funciona como inversor y como amplificador de corriente para el LED del acoplador óptico, entregándole unos 10mA con un drenaje de saturación de unos 0.5mA. El transistor de salida del acoplador óptico está polarizado de forma flotante, drenando también unos 10mA. Cuando la señal de entrada a adaptar es de +5V (nivel lógico '0'), T1 está saturado, con lo que el LED del acoplador óptico está activado, saturando al transistor del acoplador óptico, con lo que en la salida V24 aparece una tensión de -12V, que corresponde al nivel lógico '0' del interfase V24. Cuando la entrada de este circuito toma un valor de 0V ('1' lógico), T1 no conduce, por tanto el LED del acoplador óptico tampoco, con lo que el transistor del acoplador óptico tampoco conduce, con lo que en la salida V24 aparece una tensión de +12V, correspondiente a un nivel lógico '1'.
El circuito de la derecha es similar al anterior, con la excepción de D1, usado como protección del transistor T1 cuando la señal de entrada V24 toma valores negativos; en ese caso D1 conduce, protegiendo a T1.
Otra alternativa para adaptar niveles V24 a TTL/CMOS, la da el circuito integrado de Maxim MAX232. En la Fig.16 se muestra el diagrama interno de este circuito.
Fig.16
Este circuito integrado usa una única tensión de alimentación (5V) y contiene unos generadores de tensión negativa para el interfase V24 (10V). Igualmente, contiene dos adaptadores de nivel V24 a TTL y otros dos TTL a V24.
En la figura siguiente se muestra una aplicación de este circuito integrado: La realización de un interfase para conectar un transceptor con interfase CAT a un PC a traves de un puerto COM.
Fig.17
En la figura se observa el conexionado del circuito MAX232 para adaptar la entrada / salida del interfase CAT a V24. La presencia de los inversores 7404 es necesaria ya que el interfase CAT utiliza lógica TTL normal, es decir, no negada. Como quiera que el MAX232 invierte las señales, es preciso el uso de estos dos inversores. La alimentación de este circuito se obtiene a partir de una tensión de 12V contínua, regulándose a 5V por medio del circuito 7805. Las patillas del conector CAT se refieren al conector presente en los equipos FT747 y FT757 de YAESU. Para otros equipos, hay que consultar los manuales de estos.
Según se ha visto, el interfase V24 / RS232 ofrece un medio muy efectivo para la conexión de dos ordenadores o distinos periféricos a un ordenador. Se espera que con este documento se hayan disipado la mayor parte de las dudas sobre la concepción y el uso de este tipo de interfase.
El Packet Radio es un modo de comunicación digital que permite el enlace de dos estaciones de radio bien directamente o bien a traves de una red. Este modo está basado en la utilización de paquetes de información en formato síncrono y con corrección de errores, que asegura una comunicación fiable entre dos estaciones, el direccionado fiable de paquetes y la compartición de un mismo canal por varios usuarios.
Para el establecimiento de sesiones de Packet Radio, se ha definido un protocolo de enlace (Nivel 2 ISO/OSI) que garantiza la fiabilidad de la sesión. A este protocolo se le dió el nombre de AX25.
Este protocolo AX25 sigue las recomendaciones ISO 3309, 4335 y 6256; ANSI X3.66; y CCITT Q.921; todas ellas relativas a protocolos síncronos en formato HDLC (High Level Data Link). Por tanto, este es un protocolo orientado a paquetes, en el que la información a transferir viaja encapsulada en un paquete completo dotado, además de esa información de usuario, de caracteres de control, dirección y corrección de errores.
Un paquete de AX25 es una unidad de información que contiene diversos campos. En la Fig. 1 se muestra la organización de los dos tipos de paquetes existentes en el protocolo AX25, dependiendo del tipo de información que contienen.
Fig.18
Cada campo está constituído por una cantidad entera de octetos y sirve para especificar una función, tal como se detalla a continuación.
El campo Flag tiene una longitud de un octeto y se usa para delimitar el paquete; por tanto, aparecerá tanto en la cabecera como en la cola de este. Este campo siempre tiene el mismo valor: $7E, es decir, una máscara binaria 01111110.
El campo de Dirección se usa para identificar tanto la estación originaria del paquete como la estación destino del mismo. Igualmente, este campo contiene la información de Comando / Respuesta y facilidades, tal como se verá mas adelante.
El campo de Control se usa para identificar el tipo de paquete y los atributos de control de protocolo, tal como se verá mas adelante.
El campo PID identifica el tipo de protocolo de nivel 3 de ISO, al que va asociado el paquete. La codificación de este octeto es la siguiente:
Bits Descripción ------------------------------------------------------- yy01yyyy Implementación de nivel 3 AX25 yy10yyyy Implementación de nivel 3 AX25 11001100 Implementación de nivel 3 TCP/IP 11001101 Implementación de nivel 3 ARP 11110000 Nivel 3 no implementado 11111111 Caracter de Escape. -------------------------------------------------------
Fig.19
Todas las máscaras en la forma yy11yyyy ó yy00yyyy distintas a las mostradas arriba, están reservadas a futuras implementaciones de protocolos de nivel 3.
El campo de Información contiene la información propia de usuario a trasmitir. Estos compos de información (I) solo están permitidos en paquetes del tipo I, UI y FRMR. Este campo I puede contener hasta 256 octetos.
El campo FCS (Frame Check Sequence) es un campo de 16 bits que contiene el número calculado de control de paquete, para la corrección de errores, según la norma ISO 3309.
El campo de dirección de todos los paquetes debe contener, en un formato dado, el indicativo de la estación originaria del paquete, así como el indicativo de la estación destino del mismo. Para permitir el establecimiento de múltiples sesiones AX25 por estación, se le añade al indicativo un número, del 0 al 15, llamado SSID (Sub Station ID). Como el protocolo AX25 permite el uso de repetidores digitales (Digipeaters), el campo de dirección del paquete deberá contener los indicativos de todos los repetidores a usar por ese paquete, junto con sus SSID.
Cada indicativo codificado en el campo de dirección deberá constar de seis caracteres, con las letras en mayúscula, y codificadas en ASCII. En caso de indicativos de menos de seis caracteres, se rellenará con espacios.
Como quiera que este campo de dirección puede tener una longitud variable, (dependiendo del número de repetidores usados), el protocolo AX25 establece el concepto de 'extension bit' para indicar el final de este campo. Este es el bit menos significativo del octeto correspondiente al SSID de cada indicativo en el campo de dirección. Si este bit está puesto a '0', significa que los siguientes octetos del paquete pertenecen al campo de dirección del mismo, mientras que si este bit está puesto a '1', indica el final del campo de dirección. Para dar mejor significado a este bit, los caracteres correspondientes a los indicativos están desplazados un bit a la izquierda. Para ilustrar este campo, en la figura siguiente se muestra un paquete AX25 originado por EA7FPE y dirigido a EA7URS-2 sin usar digipeaters:
Octeto ASCII Binario Hexa ---------------------------------------------------------------------- Flag 01111110 7E A1 E 10001010 8A A2 A 10000010 82 A3 7 01101110 6E A4 U 10101010 AA A5 R 10100100 A4 A6 S 10100110 A6 A7 SSID 11100100 E0 Ext. Bit = 0; SSID = 2 A8 E 10001010 8A A9 A 10000010 82 A10 7 01101110 6E A11 F 10001100 8C A12 P 10100000 A0 A13 E 10001010 8A A14 SSID 01100001 61 Ext. Bit = 1; SSID = 0 Control I 00111110 3E PID nada 11110000 F0 FCS parte1 xxxxxxxx hh FCS parte2 xxxxxxxx hh Flag 01111110 7E ----------------------------------------------------------------------
Fig.:20
Como se observa en la figura, el primer indicativo que debe aparecer en el campo de dirección del paquete es el del destino. Por otra parte, los subcampos SSID contienen, además del SSID de ese indicativo (en este caso, 0) y el 'Extension Bit', cuatro bits mas de protocolo cuyo significado es el siguiente: El bit mas significativo (bit 7) corresponde al bit 'Comando/Respuesta'; los dos bits siguientes, están reservados; los cuatro siguientes corresponden al SSID y finalmente, el último, corresponde al 'Extension bit'. El significado del bit 'Comando/Respuesta' se indicará mas adelante.
En el caso de usar repetidores (Digipeaters), en el campo de dirección del paquete aparecerá la lista de indicativos de los digipeaters usados, a continuación del indicativo de la estación que ha originado el paquete. En este caso, el SSID del indicativo origen del paquete tendrá el 'Extension bit' a '0', indicando con ello que continúa el campo de dirección. Suponiendo un paquete originado por EA7FPE y dirigido a EA7URS-2 via EA7O-1, la codificación sería la siguiente:
Octeto ASCII Binario Hexa ---------------------------------------------------------------------- Flag 01111110 7E A1 E 10001010 8A A2 A 10000010 82 A3 7 01101110 6E A4 U 10101010 AA A5 R 10100100 A4 A6 S 10100110 A6 A7 SSID 11100100 E0 Ext. Bit = 0; SSID = 2 A8 E 10001010 8A A9 A 10000010 82 A10 7 01101110 6E A11 F 10001100 8C A12 P 10100000 A0 A13 E 10001010 8A A14 SSID 01100000 61 Ext. Bit = 0; SSID = 0 A15 E 10001010 8A A16 A 10000010 82 A17 7 01101110 6E A18 O 10011110 9E A19 espacio 01000000 40 A20 espacio 01000000 40 A21 SSID 11100011 E3 Ext. Bit = 1; SSID = 1 Control I 00111110 3E PID nada 11110000 F0 FCS parte1 xxxxxxxx hh FCS parte2 xxxxxxxx hh Flag 01111110 7E -----------------------------------------------------------------------
Fig.:21
Para disponer de un método para saber cuando un paquete ha sido retransmitido por un digipeater, al bit mas significativo del SSID de los digipeaters presentes en el paquete se le da el siguiente significado: cuando el paquete se retransmite por el digipeater, ese bit toma el valor '1', mientras que si el paquete no ha sido retransmitido por el, toma el valor '0'. El número máximo de digipeaters permitido por el protocolo AX25 es de ocho.
El campo de control de un paquete identifica el tipo de paquete y se usa para indicar los comandos y respuestas a estos entre los dos participantes en el enlace. Este campo de control usa la recomendación X.25 para operación balanceada (LAPB).
El protocolo AX25 soporta tres tipos de paquetes: Los paquetes de información (I), los de supervisión (S) y los no numerados (U). La codificación del campo de control, según el tipo de paquete, se muestra en la siguiente figura.
Fig.22
El significado de los distintos subcampos es el siguiente:
Paquetes de Información: Todos los paquetes de información (I) tienen el bit 0 a '0'. Estos paquetes contienen la información de usuario a trasmitir. En N(R) se indica el número de secuencia de recepción y en N(S) se indica el número de secuencia de transmisión. El significado de estos números se indica mas adelante.
Paquetes de Supervisión: Todos los paquetes de supervisión tienen el bit 0 a '1' y el 1 a '0'. Estos paquetes son de control de enlace y tienen que ver con la posible retransmisión de paquetes recibidos erróneamente o el reconocimiento de paquetes correctos.
Paquetes No Numerados: Estos paquetes se distinguen por tener el bit 0 y 1 a '1'. Estos paquetes son responsables del mantenimiento de un control adicional al de los paquetes S. Igualmente, son los responsables del establecimiento de la conexión entre dos estaciones y la transmisión de mensajes sin destino (Unproto).
Números de secuencia: Cada paquete I en el protocolo AX25 debe tener asignado un número de secuencia, módulo 8, comprendido entre 0 y 7. Esto permite la transmisión o recepción de hasta ocho paquetes de datos de una sola vez. Cada paquete contiene un número de secuencia, tanto para los emitidos (N(S)) como para los recibidos (N(R)). A este número de secuencia también se le da el nombre de tamaño de ventana.
Función del bit Poll/Final (P/F): El bit P/F se usa en todos los tipos de paquetes. Se usa en modo de comando (Poll) para solicitar una respuesta inmediata a un paquete. La respuesta a este Poll se indica activando el bit Final en el paquete adecuado.
Como se ha indicado anteriormente, los paquetes de información son aquellos que contienen la información de usuario a transferir por medio de una conexión de nivel 2 mediante el protocolo AX25. Estos paquetes contienen en el campo de control el bit 0 a '0', y también los números de secuencia de recepción y transmisión.
Los paquetes de control son los que permiten establecer una conexión AX25 y proporcionan el control del tráfico de la sesión. Estos paquetes son de Supervisión o No Numerados, describiéndose a continuación.
Los paquetes de Supervisión, junto con la codificación de su campo de control se definen en la figura siguiente:
Fig.23
Paquetes RR: Los paquetes Receive Ready (RR) se usan para indicar la disposición de recibir mas paquetes de Información, para reconocer la recepción correcta de paquetes de Información recibidos y para borrar cualquier condición de ocupado creada por la recepción de algún paquete RNR. También se usan para preguntar al corresponsal su disposición, mediante la activación del bit de Poll.
Paquetes RNR: Los paquetes Receive Not Ready se usan para indicar al corresponsal la condición de no preparado u ocupado, sin posibilidad de aceptar ningún otro paquete de Información. Igualmente, se le indica al corresponsal el reconocimiento de los paquetes hasta el N(R)-1. Cualquier paquete posterior no será reconocido. La condición RNR se puede borrar mandando un paquete UA, RR, REJ o SABM. El estado del enlace se puede solicitar mandando un paquete RNR con el bit Poll activado.
Paquetes REJ: Los paquetes Reject se usan para solicitar la retransmisión de un paquete de Información, comenzando en el número de secuencia N(R). Solo se permite una condición REJ en cada dirección al mismo tiempo. La condición REJ se borra mediante la repetición correcta de los paquetes de Información.
Paquetes No Numerados: Los paquetes no numerados son los que se usan para el establecimiento de una sesión AX25, la terminación de una sesión o el lanzamiento de balizas. El campo de control para estos paquetes se detalla en la figura siguiente.
Fig.24
Paquetes Set Asynchronous Balanced Mode (SABM): Los paquetes SABM se utilizan para conectar dos estaciones AX25, estableciendo un modo balanceado de operación. Este tipo de paquete no tiene campo de Información.
La aceptación de un paquete SABM se realiza mediante el envío, por la estación contraria, de un paquete UA. Si la estación contraria no está en condiciones de establecer la comunicación, responderá con un paquete DM.
Paquetes Disconnect (DISC): Los paquetes DISC se usan para terminar una sesión AX25 entre dos estaciones. Este tipo de paquete no tiene campo de Información.
La aceptación de este paquete DISC se realiza mediante el envío de un paquete UA por la estación contraria.
Paquetes Frame Reject (FRMR): Los paquetes FRMR se mandan al corresponsal para indicar una violación del protocolo. Estos paquetes se envían por una de las siguientes condiciones:
Paquetes Unnumbered Acknowledge (UA): Los paquetes UA se mandan como respuesta y confirmación de la recepción de un paquete SABM o DISC. Estos paquetes no poseen campo de Información.
Paquetes Disconnected Mode (DM): Los paquetes DM se mandan a la recepción de un paquete SABM o UI mientras que la estación está en modo desconectado.
Cuando una estación recibe un paquete SABM, y no está en disposición de aceptar la conexión, se devuelve un paquete DM.
Paquetes Unnumbered Information (UI): Los paquetes UI contienen campos de información y PID. Estos paquetes fuera de secuencia se mandan sin necesidad de reconocimento, y por tanto, no pueden ser recuperados. El uso habitual de estos paquetes es el de Balizas o información Broadcast para protocolos de nivel superior, tales como NET/ROM o TCP/IP.
Hay varios errores de enlace que son recuperables sin necesidad de terminar con la sesión. Estas situaciones de error pueden ocurrir, tanto en los equipos de los corresponsales como por errores del medio de comunicación.
Condición Ocupado: Cuando una estación es incapaz de recibir paquetes de Información, de forma temporal, enviará al corresponsal un paquete RNR. Una vez que esté lista para la operación, enviará un paquete UA, RR, REJ o SABM, según en el estado en que se encuentre el enlace.
Recuperación REJ: Los paquetes REJ se mandan para la solicitud de la retransmisión de un paquete de Información al corresponsal, siguiendo la secuencia N(S). El protocolo solo permite una única secuencia REJ al tiempo. Esta condición se restablece a la recepción del paquete solicitado. El corresponsal que recibe el paquete REJ, deberá enviar todos los paquetes de Información, hasta el tamaño de ventana, comenzando por el número de paquete N(R) indicado en el paquete REJ.
Recuperación de errores de tiempo: El protocolo mantiene dos temporizadores de enlace (T1 y T3). La misión del primero es la retransmisión de un paquete no confirmado, mientras que la misión del segundo es el control de actividad del enlace en períodos de tráfico escaso.
A continuación se describe los procedimientos de conexión, uso y desconexión entre dos estaciones, usando el protocolo AX25.
Fase de conexión: Cuando una estación desea conectar con
otra, manda un paquete SABM y attanca el temporizador T1.
Si la estación destino puede responder a esa petición
de conexión, devuelve un paquete UA. Una vez recibido
este paquete por la primera estación, cancelará el
temporizador T1.
Si la segunda estación no responde, y termina el tiempo T1,
la primera estación vuelve a mandar un paquete SABM y
rearrancar el T1. Este proceso se repite N2 veces.
Si el corresponsal recibe el paquete SABM, y no puede entrar en
fase de conexión por la razón que sea, devuelve un
paquete DM.
Una vez recibido el paquete DM por la primera estación,
cancela el temporizador T1 y abandona la fase de conexión.
Fase de transferencia de información: Una vez establecida una conexión, ambos participantes entran en estado de intercambio de información. En este estado, ambos participantes aceptan y transmiten paquetes de información y supervisión de acuerdo con el protocolo AX25.
Fase de desconexión: Mientras que ambas estaciones están
en fase de transferencia de información, cualquiera de ellas
puede solicitar una desconexión de enlace. Para ello, manda un
paquete DISC y arranca el temporizador T1.
Una vez recibido un paquete DISC, se debe confirmar con un paquete
UA.
En una red Half-Duplex de canales compartidos, como la red de Packet Radio, puede suceder que dos estaciones deseen mandar un paquete al canal en el mismo instante. Si ambas lo hacen en un mismo instante, se produce una colisión de paquetes y la información se degrada. Para evitar esto, se utiliza el procedimiento CSCD (Carrier Sense, Collision Detect). Este procedimiento actúa de la siguiente forma: Cuando una estación desea mandar un paquete al canal, primero espera a que el canal esté libre (ausencia de portadora); en ese momento, espera un tiempo fijo, dado por el parámetro del protocolo SLOTTIME. Una vez cancelado el tiempo indicado en SLOTTIME, genera un número aleatorio compendido entre 0 y 255. Si este número es superior al número dado por el parámetro PERSIST, vuelve a esperar el tiempo indicado por SLOTTIME y se repite el ciclo. Si el número generado es inferior a PERSIST, se escucha el canal, y si no se detecta portadora, se transmite el paquete.
La modalidad de comunicación digital de Packet Radio está soportada por el protocolo AX25. Este, por ser un protocolo de nivel de enlace, posee ciertas limitaciones a la hora de establecer comunicados mas allá del alcance de las dos estaciones que deseen establecer un QSO. Dicho de otra manera, le falta la capacidad de enrutamiento a traves de una red.
La única posibilidad de establecer un contacto mas allá del alcance de las dos estaciones, usando exclusivamente el protocolo AX25, es mediante el uso de la capacidad de Digipeater el protocolo AX25. La función Digipeater habilita el uso de una estación de Packet Radio como estación repetidora digital, funcionando en modo transparente para el usuario: simplemente, la estación usada como Digipeater lee los paquetes de una estación retransmitiéndolos a la siguiente, y viceversa. Esta función permite utilizar hasta siete estaciones intermedias como repetidoras de paquetes. En la Fig. 25 se muestra la función Digipeater según el modelo ISO.
Fig.25
Como se observa en la figura, la estación usada como Digipeater ofrece un enlace entre ambas TNC's, a nivel de enlace y compartiendo el mismo medio físico de comunicación.
De acuerdo con la descripción del modelo ISO de siete niveles para comunicaciones digitales, el nivel de red es el responsable del enrutamiento adecuado de mensajes entre dos estaciones presentes en una red, garantizando el mantenimiento de una sesión punto a punto entre los dos participantes, independientemente de la ruta seguida. Este nivel de Red se implementa en la red de Packet Radio mediante Nodos Digitales o Routers, provistos de un programa que mantenga uno de los distintos protocolos de nivel de Red existentes. En la Fig. 26 se muestra un Nodo Digital o Router según el modelo ISO.
Fig.26
Como se observa en la figura, ambas TNC's están enlazadas a traves
de un Router, dotado de un protocolo de nivel de Red, sin
compartir necesariamente el mismo medio físico de
comunicación.
Como primera diferencia entre un Digipeater y un Router, se
observa que, mientras el primero comparte el mismo medio físico
de conexión entre las dos TNC's, el segundo no necesariamente
comparte el mismo medio físico. Esto hace que un Router
tenga capacidad de Gateway o conmutación entre
distintas redes o distintos canales de radio en una red de Packet
Radio.
Para el mantenimiento del nivel de red en una red de Packet Radio, se han desarrollado varios protocolos, básicamente agrupados en dos tipos:
Los protocolos del primer tipo establecen circuitos virtuales entre los dos participantes, manteniendo tablas fijas de ruteo entre los distintos Routers intermedios, mientras que los protocolos del segundo tipo mantienen en los paquetes a transferir (Datagramas) toda la información de ruteo.
La ventaja de los protocolos del primer grupo es que, al mantener los Routers toda la información de ruteo, los paquetes de usuario son mas sencillos, ya que no necesitan contener información de ruta, por lo que el QRM en el canal es menor.
La ventaja de los protocolos del segundo grupo es que, al contener el paquete de datos la ruta a seguir, esta se puede optimizar en cualquier momento, eligiendo la mas adecuada o de mayor calidad.
Un protocolo de Circuito Virtual da la apariencia de ofrecer una conexión directa entre dos estaciones remotas de Packet Radio. Antes de que la comunicación entre ambas comience, los Routers intermedios intercambian la información necesaria para el mantenimiento del enlace, y esta información se mantiene en los Routers mientras dura el QSO. Una vez finalizado el QSO, esa información de ruteo presente en los Routers, se descarga. Una vez establecido el enlace, los paquetes de ambas estaciones viajan a traves de la red, de acuerdo con el Circuito Virtual establecido, sin necesidad de sobrecargarlos con información adicional sobre la ruta. Este procedimiento es el utilizado por la recomendación CCITT X.25.
El protocolo ROSE (RATS Open System Environment) se desarrolló hace ya algunos años por Radio Amateur Telecommunications Society como protocolo de nivel de Red para Routers, usando el procedimiento de Circuitos Virtuales, e implementado como firmware en las TNC-2.
La función del protocolo ROSE es la de establecer el ruteo necesario de mensajes por la misma red. Esto es, son los propios Routers los que se encargan de establecer la ruta adecuada, y no los paquetes de usuario.
Este protocolo utiliza el concepto de confirmación de paquetes nodo a nodo en lugar de usuario a usuario. Cuando un usuario manda un paquete a otro a traves de un Digipeater, este paquete es, simplemente retransmitido. Si la estación destino lo recibe sin error, lo confirma a traves del Digipeater. Sin embargo, ese paquete se puede degradar a traves del Digipeater o puede sufrir una colisión. En ese caso, la estación destino no lo podrá confirmar, por lo que la estación origen puede perder la secuencia de paquetes. Igualmente, el Digipeater puede perder el enlace con la segunda estación; en ese caso, el enlace final se pierde.
Cuando un usuario manda un paquete a traves de una red que mantiene una confirmación nodo a nodo, las cosas suceden de forma bien distinta: La responsabilidad de la confirmación de paquetes y el mantenimiento del enlace punto a punto pertenece a los nodos involucrados en la ruta. Por tanto, si un paquete se pierde entre dos nodos, son esos dos nodos los que se encargan de la retransmisión del paquete perdido y no el usuario de la red. Igualmente, si se pierde la conexión entre dos nodos mientras que la sesión se mantiene abierta, la responsabilidad de reconexión entre nodos pertenece a estos, y no a los usuarios del enlace.
En la implementación del protocolo ROSE, cada nodo de la red usa la especificación CCITT X.121. Esta especificación indica un número por nodo, partiendo de los prefijos de los números telefónicos: coda nodo dispone de una identificación de seis dígitos, correspondiendo los tres primeros al código de área y los tres restantes al código local. Cada nodo dispone de un mapa de ruteo para los códigos de área de los nodos presentes en la red. Por tanto, cada nodo ROSE posee dos identificadores: Su propio indicativo AX25, y el número de nodo de seis dígitos.
Para la conexión de una estación con otra, a traves de una red ROSE, solo es necesario conocer el indicativo de la estación final y el código del nodo alcanzable por esta.
Una implementación típica del protocolo ROSE es la implementación FPAC en la red de nodos francesa.
Un protocolo de Datagramas es aquel en el que la información a transferir a traves de la red se encapsula añadiéndole una cabecera especial con la información necesaria para el ruteo del paquete. A diferencia de los protocolos de Circuitos Virtuales, los protocolos de Datagramas sobrecargan mas la red con información extra, pero tienen la ventaja de no necesitar mapas fijos de ruteo entre nodos, pudiendo elegir la ruta mas adecuada o de mayor calidad para su retransmisión. Todos estos protocolos están basados en el Internet Protocol (IP) de DARPA (Defense Advanced Research Projects).
El protocolo NET/ROM fue desarrollado por WA8DED y se implementa en un EPROM para las TNC-2. Igualmente, está disponible la implementación G3BPQ como programa para PC. Este es un protocolo de Datagramas muy sencillo y de uso ámpliamente generalizado. Este es el protocolo usado por la red de nodos española.
El usuario de una red NET/ROM no necesita conocer los detalles de ruteo de la red para enlazar un punto con otro; símplemente necesita conocer el nodo local de la estación destino. El protocolo NET/ROM conoce el camino a seguir para establecer la conexión entre los dos participantes, y si por alguna razón un nodo intermedio no está disponible, el protocolo es capaz de conmutar a un nodo vecino para restablecer el camino. Esto es posible ya que el protocolo hace que cada nodo mantenga una lista de nodos vecinos escuchados y una calidad de estos. Cuando un nodo aparece en el aire, informa al resto de nodos de su presencia, de forma que estos puedan actualizar su información de rutas. Esta información de rutas, también se puede actualizar manualmente por medio de un terminal remoto del nodo.
Una vez establecida la conexión entre dos usuarios a traves de una red NET/ROM, la confirmación de paquetes y mantenimiento del enlace es responsabilidad de los nodos, de la misma manera que los nodos con procedimiento de Circuito Virtual.
El protocolo NET/ROM usa conexiones AX25 entre nodos vecinos y en el establecimiento de sesión con los usuarios. Adicionalmente, NET/ROM usa el procedimiento de Sliding Windows, que provee un mejor sistema cara a la recuperación de errores y paquetes perdidos en el enlace. Igualmente, este procedimiento asegura una menor carga o QRM sobre el canal, al adecuar el tamaño de ventana a la calidad y congestión del enlace.
Como quiera que el protocolo NET/ROM distingue claramente los procesos de nivel de red de los de nivel de transporte, hace que este protocolo sea el mas adecuado para la retransmisión de paquetes TCP/IP
El TCP/IP (Transport Control Protocol / Internet Protocol) es una serie de protocolos desarrollados para que un conjunto de ordenadores interconectados compartan recursos a traves de una red. Tradicionalmente, esa red o conjunto de redes se ha denominado Internet.
Por ser un conjunto de protocolos de uso universal, la definición y estandarización de estos se establece en la documentación RFC (Request For Comments).
Estrictamente hablando, tanto TCP como IP son dos protocolos de esa serie, que se ocupan de las funciones de bajo nivel, al igual que el UDP. Dentro de esa serie de protocolos existen otros que se dedican a funciones de alto nivel tales cómo TELNET, FTP o NFS.
Las facilidades que ofrecen la familia de protocolos TCP/IP son las siguientes:
El protocolo FTP (File Transfer Protocol) permite al usuario de cualquier ordenador presente en la red la transferencia de ficheros con otros ordenadores presentes en la red. La seguridad de la información se mantiene mediante nombres de usuario y passwords. Las especificaciones del FTP se contemplan en el documento RFC 959.
El protocolo TELNET permite la conexión de un ordenador a otro en la red, emulando un terminal remoto. Un usuario puede establecer una sesión de terminal en otro ordenador presente en la red usando un protocolo TELNET. Las especificaciones del terminal TELNET se encuentran descritas en los documentos RFC 854 y 855.
El protocolo SMTP permite la distribución de mensajería electrónica entre los distintos participantes de una red. Las especificaciones SMTP se contemplan en los documentos RFC 821, 822 y 937.
Estas son las facilidades presentes en todas las implementaciones de TCP/IP. Además de estas, en instalaciones de servidores de red se suele incluir tres facilidades adicionales:
El protocolo NFS permite a un sistema en red acceder a ficheros en otro sistema, agrupados en un File System, en modo transparente al sistema operativo usado, dando la sensación que el sistema que accede a este File System lo ve como propio. Por ejemplo: suponiendo un sistema Unix conectado a una red, que ofrece un servicio NFS, y un PC que accede a traves de la red a ese servicio. El PC está trabajando normalmente en MS-DOS, y para el, el File System que ofrece el sistema UNIX a traves de la red aparece como una unidad de disco 'M', nativa de MS-DOS, permitiendo toda la explotación de ficheros en ella que permite el MS-DOS. La descripción de estos protocolos, en particular para PC's, aparecen en los documentos RFC 1001 y 1002 relativos al NET-BIOS bajo TCP/IP.
Esta facilidad permite el acceso a impresoras conectadas a otros sistemas presentes en la red. Desafortunadamente, no hay descripción exacta del protocolo a usar, aunque se utiliza la implementación de Unix de Berkeley.
Esta facilidad permite la ejecución remota de programas en otros ordenadores presentes en la red. Esta facilidad está soportada por los procedimientos RPC (Remote Procedure Call), y habitualmente presentes en sistemas Unix.
Los protocolos TCP/IP siguen el modelo ISO de siete niveles, organizando la información de usuario en Datagramas. Un datagrama es un paquete completo de información, con las cabeceras adecuadas para cada nivel dentro del modelo ISO. Dentro de esta terminología, el protocolo TCP es un protocolo de nivel 4 (Transporte), mientras que el protocolo IP es un protocolo de nivel 3 (Red). Para ilustrar la interrelación entre ellos, veamos una situación habitual: el envío de correo a través de la red: Primero, hay un protocolo para el envío de correo (SMTP). Este protocolo define un conjunto de comandos y respuestas para que una máquina mande correo a otra. Como protocolo de aplicación, asume que hay una comunicación fiable establecida entre las dos máquinas, y para ello, se comunica con el protocolo inmediatamente inferior, el protocolo de Transporte. En este caso, ese protocolo de transporte es el TCP. A ese nivel, el TCP tiene la responsabilidad de hacer llegar de manera fiable los mensajes originados por manejador de correo a su otro destino, reconociendo los transmitido correctamente y retransmitiendo lo necesario. Si un mensaje a transmitir es muy largo, el TCP lo recorta para adecuar los datagramas a una longitud correcta. Una vez preparados los datagramas de forma adecuada, el TCP pasa la información al nivel inmediatamente inferior, el nivel de Red, en este caso representado por el protocolo IP. Este protocolo es el responsable del ruteo adecuado del datagrama a traves de la red, manteniendo de forma fiable ese ruteo. Finalmente, ese datagrama debe pasar al nivel inmediatamente inferior, el de Enlace, para su transmisión a la red. Ese nivel de enlace está soportado por protocolos Ethernet en redes locales o Internet, o AX25 en redes de Packet Radio. Por tanto, una aplicación TCP/IP usa cuatro niveles del modelo ISO:
Los protocolos TCP/IP se usan en cientos de redes interconectadas entre sí. Para que los datagramas originados por todos los participantes de estas redes alcancen sus destinos, con un ruteo transparente para ellos, estos protocolos utilizan un direccionado propio, el llamado Direccionado Internet. Una dirección Internet es un número de 32 bits, único para cada participante de la red, que habitualmente se representa como cuatro grupos de números decimales separados por puntos. Una dirección Internet aparece como 44.133.41.11. Generalmente, esta estructura de dirección define tanto al usuario como a la red. En el ejemplo propuesto, el 44 indica una red de Packet Radio, el 133 define a España, el 41 a Sevilla y el 11 a EA7FPE.
Por supuesto, al usar estos protocolos de red nos referimos siempre a un nombre de usuario en lugar de su número Internet. Todos los paquetes de red disponen de ficheros en donde están presentes los nombres de los usuarios y sus direcciones de red. El documento RFC 882 indica como se debe hacer esta traducción.
Los protocolos TCP/IP funcionan usando el concepto de no conexión, esto es, no necesitan de un procedimiento de conexión o desconexión para establecer una sesión; símplemente, mandan y reciben de la red un conjunto de datagramas con la información a transferir. El establecimiento y cierre de sesión es responsabilidad de los protocolos de aplicación, como pueda ser TELNET, FTP o SMTP.
El nivel TCP es el responsable de dividir un mensaje en datagramas, reensamblarlos en el destino, reenviar cualquier datagrama perdido y agruparlos en el orden correcto. Según esto puede parecer que el nivel TCP hace todo el trabajo, sin embargo, en redes grandes con otras subredes conectadas, el ruteo de datagramas puede ser muy complicado. Este ruteo lo soporta el nivel de red IP.
El protocolo TCP permite establecer varias sesiones para un mismo usuario, para ello, TCP usa el concepto de 'Port'. Un Port o puerto no es mas que un número de sesión para un usuario. Para el mantenimiento del protocolo, se añade una cabecera especial a cada datagrama, indicando en esta los datos necesarios para el protocolo. En la Fig. 27 se muestra una cabecera TCP.
Fig.27
Esta cabecera TCP contiene 20 bytes, y los campos mas significativos son: los números de Puerto Fuente y Destino, en donde se indican los números de los puertos correspondientes a cada una de las sesiones abiertas por el usuario; el Número de Secuencia, en donde se numera, no la secuencia del datagrama sino el número de bytes transferidos para esa sesión. El Número de Reconocimiento indica hasta qué byte se ha recibido correctamente. La Ventana indica cuantos datagramas se transmitirán simultáneamente, y el Checksum es una suma binaria de control del datagrama. El resto de campos se utilizan para el control del protocolo y quedan fuera del ámbito de este documento.
El protocolo TCP manda datagramas al nivel inferior, esto es, al protocolo IP. Este nivel de red es el encargado de buscar la ruta a esos datagramas y mantenerla a lo largo de toda una sesión. Para poder transmitir esos datagramas a través de distintas redes o subredes a través de Gateways, el nivel IP añade al datagrama su propia cabecera. Esta cabecera, tal como se indica en la Fig. 28.
Fig.28
En esta cabecera, los campos mas significativos son las Direcciones Origen y Destino, en donde se indica las direcciones Internet origen y destino de los datagramas; el Protocolo, que indica el tipo de protocolo del nivel de transporte usado (habitualmente, TCP), y el checksum del paquete. A continuación en el datagrama, aparecerá la cabecera TCP y siguiendo a esta, los datos del usuario. El resto de los campos de la cabecera IP no son significativos y su discusión cae fuera del ámbito de este documento.
Centrando la discusión en una red de Packet Radio, el flujo de datos de usuario entre los distintos protocolos TCP/IP es el mostrado en la Fig. 29.
Fig.29
En ella se observa dos usuarios, usando un programa de aplicación bajo TCP/IP y usando una red de Packet Radio.
La comunicación entre ambos usuarios se establece siguiendo el siguiente flujo: El usuario 1 manda un mensaje desde su programa de aplicación, al nivel de transporte. Este nivel está soportado por un protocolo TCP, por tanto, este protocolo distribuye el mensaje del usuario en datagramas y le añade a cada uno de ellos una cabecera TCP. Una vez compuesto el datagrama, los pasa al nivel de red, en este caso soportado por el protocolo IP. Este protocolo añade al datagrama una cabecera IP y lo pasa al nivel inmediatamente inferior: el nivel de enlace. Este nivel está soportado en este caso por el protocolo AX25, el cual incorporará una cabecera AX25 al datagrama y lo mandará al medio físico, en este caso, un canal de radio, para su transmisión. Hay que hacer notar que en este nivel de enlace, todos los paquetes TCP/IP o datagramas se transmiten como paquetes UI (Unumbred Information). Una vez alcanzado el receptor del datagrama, el proceso se invierte. El nivel AX25 elimina su cabecera al datagrama y lo entrega al nivel IP, el cual hace lo mismo, pasando el datagrama al nivel TCP. Este elimina la cabecera TCP y pasa la información de usuario al programa de aplicación del usuario 2.
Como se observa en la figura, el nivel de red puede estar soportado por dos protocolos: el IP o el NET/ROM; esto es debido a la proliferación de nodos NET/ROM dentro de una red de Packet Radio. Sin embargo, esto no es un problema, ya que la información IP se puede encapsular en un paquete NET/ROM, ya que este protocolo queda referenciado en el campo PID de la cabecera AX25.
Tal como se ha visto en la discusión anterior, el nivel de transporte en esta familia de protocolos está soportado por el protocolo TCP. Este protocolo rompe los mensajes de usuario en datagramas, le añade una cabecera que controla los números de puerto origen y destino y los manda al protocolo de red IP. Sin embargo, en esta familia de protocolos existe dos protocolos de nivel de transporte muy específicos, estos son el UDP (User Datagram Protocol) y el ICMP (Internet Control Message Protocol). El primero se usa para transferencia de ficheros, mientras que el segundo se usa para transferencia de mensajes específicos de red.
Como se ha visto con anterioridad, los protocolos de red manejan direcciones Internet de 32 bits para el establecimiento de sesiones. Sin embargo, siempre es preferible el uso de nombres en lugar de números. Para ello, cada paquete de TCP/IP posee ficheros en donde se relaciona el nombre de los usuarios con su número o dirección Internet. Cuando una red es pequeña y limitada a un grupo cerrado de usuarios, basta con un fichero que relacione un nombre de usuario con su dirección Internet; pero cuando las redes aumentan, es preciso establecer un mecanismo de nombres adecuado. Este mecanismo se basa en una serie de servidores de dominios, en donde dominio indica un ámbito de red. Estos servidores de dominios están establecidos de forma jerárquica, correspondiendo a una estructura institucional. La representación de esta estructura en el nombre de un dominio se realiza separando los distintos componentes del dominio mediante puntos, tal como se indica en los documentos RFC 882, 883, 973 y 974. Un ejemplo típico puede ser un ordenador en el Laboratory of Computer Science en el MIT. El nombre de este ordenador será: BORAX.LCS.MIT.EDU. Este nombre, leído de izquierda a derecha indica que se trata de un ordenador perteneciente a Educación, dentro de ella, al MIT, dentro del MIT al Laboratory of Computer Science, y dentro de este, la máquina se llama BORAX. Para poder consultar la dirección Internet de esta máquina, es preciso consultar cuatro servidores de dominios: en primer lugar, se debe consultar al servidor principal (EDU). Este servidor contiene toda la información y direcciones Internet de todos los servidores de su ámbito, entre los que se encuentra el servidor de dominios MIT. Este servidor contiene las direcciones de sus servidores de dominio, entre los que se encuentra LCS, y este, a su vez, contiene las direcciones de todas las máquinas de su entorno, en las que se encuentra BORAX.
En el nombre de dominio se suele indicar el usuario de ese ordenador. En el ejemplo anterior, si se precisa mandar un mensaje o correo al usuario PETER en la máquina indicada, el nombre a usar sería: [email protected]. Como se observa, el nombre del usuario se separa del nombre del dominio mediante el caracter '@'.
Afortunadamente, todos los paquetes TCP/IP poseen los mecanismos necesarios para consultar ina dirección Internet, a partir de un dominio institucional (en este ejemplo, EDU), sin necesidad de cabalgar a traves del árbol de dominios.
Tal como se ha visto en la discusión anterior, los protocolos TCP/IP utilizan un direccionado Internet para el establecimiento de sesiones. Supongamos que se quiere establecer una sesión FTP entre las máquinas 44.133.41.6 y 44.133.41.11. Esta información es suficiente para establecer una sesión a nivel TCP e IP. Sin embargo, el nivel de enlace (nivel 2) está soportado, en caso de una red de Packet Radio por el protocolo AX25. Este protocolo AX25 necesita obligatoriamente, un direccionado compuesto por indicativos de radioaficionado. El mecanismo de traducción entre una dirección Internet y un indicativo está soportado por el protocolo ARP (Address Ressolution Protocol). En caso de redes Ethernet, este protocolo ARP es el que se encarga de traducir direcciones Ethernet a direcciones Internet. Este protocolo, para la traducción de direcciones utiliza una tabla propia de equivalencias. En el caso de que esta tabla no contenga la equivalencia de dirección Internet / indicativo, el protocolo ARP manda a la red un paquete especial 'ARP request' conteniendo la dirección Internet a consultar. Cuando el propietario de esa dirección internet escucha ese paquete, contesta con un paquete conteniendo el indicativo solicitado. Una vez recibido este paquete por la estación solicitante, agrega esa información a su tabla de traducción de direcciones.
Desde hace unos años, se ha desarrollado varias implementaciones de los protocolos TCP/IP y aplicaciones standard TCP/IP para su uso en redes de Packet Radio. La primera de ellas, y origen del resto fue la implementación de Phil Karn (KA9Q) para distintas plataformas (PC's, Atari ST, UNIX, MAC...). Partiendo de esta implementación se ha desarrollado otras para PC's por otros grupos de trabajo, tal como las versiones de PA0GRI o G6DHU.
Todas estas versiones comparten la misma estructura: son programas con capacidad reducida de multitarea, multiprotocolo y multiaplicación. Las características mas habituales de estos programas son las siguientes:
Todos los programas de esta familia (NET, NOS, WNOS, JNOS, etc.) tienen la misma estructura y una funcionalidad similar. Todos ellos utilizan los protocolos TCP/UDP/ICMP/IP, permiten la definición y el uso de múltiples TNC's / Modems mediante el concepto de 'interface'. Contienen servidores de las aplicaciones standard de red, esto es, AX25, NET/ROM, FTP, CONVERS, SMTP, y organizan las distintas conexiones de packet como 'sesiones' de aplicación. Todos ellos poseen BBS con capacidad de forwarding en cualquier protocolo soportado, y Nodo con capacidad de autoruteo.
La implementación de los programas standard de red suele ser bastante completa y contienen agentes de usuario para correo SMTP.
Una descripción mas detallada de este tipo de programas supera el ámbito de este documento, remitiendo al interesado a la abundante información que contiene cada uno de ellos.
Página anterior