Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
La responsabilidad del módulo físico consiste en transmitir los datagramas provenientes de las capas superiores (IP y ARP) y recibir los datagramas que les envían otras máuinas. Existen multitud de variantes posibles a la hora de implementar una capa física para la torre de protocolos TCP/IP, dependiendo de la interfaz o interfaces físicas disponibles.
En este Proyecto nos hemos centrado en las interfaces serie RS232C, MIDI y LAN, aunque actualmente sólo se ha implementado la versión RS232C. Asimismo existen básicamente cuatro protocolos diferentes para encapsular los datagramas IP/ARP en canales serie: SLIP (Serial Line IP) [RFC1055], PPP (Point to Point Protocol) [RFC1661] [RFC1662], KISS (Keep It Simply Stupid) [KISS] y SMACK (Stuttgart's Modified Amateur CRC KISS) [SMACK].
El protocolo SLIP es un sistema de encapsulado muy simple, sin ningún tipo de control de errores o flujo. Dado que está ideado para su empleo en conexiones punto a punto no soporta datagramas ARP. KISS, en cambio, ha sido diseñado específicamente considerando su aplicación en la red de RadioPaquete de Aficionado (AX.25) -una red broadcast- por lo que, aún siendo funcionalmente idéntico al SLIP, soporta datagramas ARP, RARP, etc. SMACK, por otra parte, es una mejora del KISS para entornos electromagnéticamente ruidosos como es el caso, lógicamente, de una estación de Radioaficionado. Para ello incorpora un CRC de 16 bits a todas las tramas. Los dos últimos sistemas, hasta donde sabe el autor, son utilizados exclusivamente en entornos de Radioaficionado.
El protocolo PPP (Point to Point Protocol) contrasta con los anteriores por su gran complejidad. Permite multiplexar a través de una misma línea protocolos de red diferentes, no estando exclusivamente limitado al mundo TCP/IP. Incorpora detección de errores en las tramas, autentificación, una capacidad de negociación de extensiones extremadamente desarrollada, asignación dinámica de direcciones IP, búsqueda de servidores de nombres y un largo etcétera. Está compuesto de un protocolo de control de enlace (LCP - Link Control Protocol) y una familia de protocolos de control de red (NCP - Network Control Protocol), siendo uno de los protocolos soportados el IP (Internet Protocol).
En [RFC1661] se definen sus características básicas, siendo el documento [RFC1662] donde se especifica su formato de trama (similar al HDLC - High-level Data Link Control). Las especificaciones son ampliadas en los documentos [RFC1333], [RFC1334] y [RFC1570]. Cada uno de las posibles familias de protocolos de control de red se especifica en uno o más documentos diferentes e independientes. El que nos interesa a nosotros es el protocolo asociado al IP [RFC1332].
Por último, en [RFC1912] se describen los problemas de patentes
que han surgido durante el desarrollo de una serie de extensiones
al protocolo PPP para posibilitar la compresión y encriptación en
línea. El propietario de las patentes es Motorola y aunque dicha
compañía ha mostrado su intención de
facilitar licencias "bajo
términos equitativos y razonables", todavía se
ignora cuales serán
dichas condiciones...
Interfaz
La interfaz de este módulo está constituida por diversos procesos cooperantes y varias rutinas que se ejecutan en el contexto del llamante.
PROC_FIS_BC
Este proceso es el encargado de inicializar este módulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". En general éste debería ser el primero o, en cualquier caso, uno de los primeros módulos en ser inicializado.
PROC_FIS_SUP
Este proceso recibe mensajes "MSG_MBUF" conteniendo una cadena de MBUF's representando un datagrama y lo transmite a través del canal indicado. Un canal especifica una interfaz física y un protocolo a emplear. El formato es el siguiente:
Asimismo los datagramas que se reciben a través de una interfaz y un protocolo dado, asimilables a un canal existente, son enviados hacia los procesos "PROC_IP_INF" o "PROC_ARP_INF", según corresponda. Los mensajes serán, también, "MSG_MBUF". El formato es como sigue:
En cuanto a las rutinas, sus prototipos son:
estado fis_alta_canal(uint32 canal,uint32 protocolo,uint32 dispositivo);
Esta rutina crea un nuevo canal. Su identificador será 'canal', 'protocolo' el protocolo a emplear y 'dispositivo' el nombre de la interfaz física utilizada.
En la actualidad los protocolos existentes son:
En cuanto a las interfaces físicas soportadas, o dispositivos, tenemos los siguientes:
void fis_baja_canal(uint32 canal);
Esta rutina da de baja un canal. Su dispositivo asociado queda libre para un nuevo uso.
estado fis_flujo_canal(uint32 canal,uint16 tamanho);
Esta rutina solicita a permiso a la capa física para transmitir un datagrama de 'tamanho' bytes a través del canal 'canal'. Si podemos hacerlo la función retornará "OK". En caso contrario indicará "FLUJO_LLENO". Si el canal especificado no existe, devuelve "ERR_NO_CANAL".
La capa física dispone de una serie de búfferes internos para cada interfaz física, de una capacidad determinada. Ello permite mantener permanentemente ocupada la unidad de transmisión, si hay datos para ello. Aún cuando la capa física gestionará adecuadamente cualquier datagrama recibido con el control de flujo cerrado, se desaconseja dicha práctica.
void fis_ppp_auth(uint32 canal,pmbuf auth);
Esta rutina permite especificar los parámetros de
autentificación para un canal PPP dado. El canal especificado
debe utilizar el protocolo PPP. 'auth' es una cadena de dos
MBUF's conteniendo el primero la identidad del usuario y el
segundo su palabra de paso asociada.
Implementación
A pesar de la intención inicial finalmente no se programaron los protocolos KISS [KISS] ni SMACK [SMACK] debido a que en mi entorno urbano no existe ninguna red TCP/IP de Radioaficionado para poder evaluar el funcionamiento correcto de las rutinas desarrolladas. Es muy posible, no obstante, que muy pronto sean añadidas a la herramienta, ya que su difusión así lo exige.
En la actualidad el módulo físico sólo permite un protocolo por interfaz, debido a la dificultad de demultiplexarlo. A pesar de que el protocolo PPP incorpora bastantes funcionalidades al respecto se ha considerado innecesario para un uso normal.
Por otra parte el protocolo SLIP implantado no utiliza la idea de Phil Karn de acotar los datagramas por ambos extremos, y se limita a indicar su final. No se ha seguido dicha recomendación porque el autor opina que la calidad actual de las líneas telefónicas es lo bastante elevada como para que sea muy improbable que se detecten caracteres espúreos debidos al ruido. Si a ello unimos la amplia difusión del protocolo V.42 y similares (corrección de errores) en el mundo de los MODEMS, deducimos que no vale la pena la mayor complejidad y pérdida de prestaciones. No obstante el proceso receptor implementado es capaz de gestionar de forma adecuada datagramas nulos como los que resultarían si el otro extremo sí aplicase dicha técnica.
En cuanto al protocolo PPP, se ha realizado una implantación funcionalmente mínima. Se han seguido de forma detallada todos los pasos a la hora de la negociación LCP [RFC1661], pero la mayoría de las opciones son denegadas. Se deniega la compresión Van Jacobson [RFC1144] y la compresión de cabeceras. Se deniega la opción de CRC32 y CRC8. Se acepta, no obstante, la gestión de autentificación y la asignación dinámica de dirección IP. A pesar de todo el subconjunto implantado ha sido capaz de interoperar convenientemente con todos los sistemas proveedores con los que se ha probado. En cualquier caso, para facilitar la subsanación de cualquier problema, este módulo imprime información exhaustiva sobre las opciones que se están negociando y lo que, en todo momento, nos solicita el otro extremo.
En cuanto a la gestión de los dispositivos físicos, la transmisión
y recepción de caracteres se realiza por interrupciones. No
obstante en procesado en sí de los datagramas, así como la lectura
del búffer de recepción y el rellenado del búffer de transmisión,
se realizan durante los períodos IDLE del programa. Es muy
importante que no haya ningún proceso IDLE con un tiempo de
ejecución demasiado elevado, ni demasiados procesos IDLE activos
en un momento determinado, so pena de perder datagramas por
errores debidos a desbordamientos del búffer de recepción. Ello
también tiene repercusiones en la transmisión, ya que aparecerán
tiempos muertos que harán bajar el rendimiento. Se ha fijado una
longitud de las colas de 4Kbytes, lo cual implica que disponemos
una capacidad de tiempo muerto de unos dos segundos y medio en un
modem de 14.400bps, más de un segundo para 28.800bps y
prácticamente un segundo para 33.600bps (no se ha considerado la
compresión de datos, pero sí el V.42). Dadas las velocidades de
proceso de los sistemas personales actuales, ello parece más que
suficiente.
Bibliografía
[KISS] "Proposed "Raw" (aka "KISS") TNC Functional Spec"
Phil Karn, KA9Q
Mike Cheppionis, K3MC
6 August 1986
[LABCD] Laboratorio de Comunicación de Datos
Curso 94-95. Vigo, 16 de Marzo de 1.995
Alvaro Manuel Gómez Vieites
Carlos Gabieiro Martínez
Jose Cadavid Jáuregui
Jesús Cea Avión
[LABCD-FIS] Laboratorio de Comunicación de Datos
Curso 94-95. Vigo, 16 de Marzo de 1.995
Capa Física
Alvaro Manuel Gómez Vieites
Carlos Gabieiro Martínez
Jose Cadavid Jáuregui
Jesús Cea Avión
[MACAX25] "MacAX25 Design Speficications"
Tim Hayes, N2KBG
Abril 1.995
[POWERNET] Proyecto PowerNet
Jesús Cea Avión
Implementación de multitarea cooperativa en lenguaje C
11 de Abril de 1.990
[RFC1055] RFC1055: "A NONSTANDARD FOR TRANSMISSION OF IP
DATAGRAMS OVER SERIAL LINES: SLIP"
J. Romkey
Junio 1.988
[RFC1122] RFC1122: "Requirements for Internet Hosts --
Communication Layers"
Robert Braden
Octubre 1.989
[RFC1144] RFC1144: "Compressing TCP/IP Headers for Low-Speed
Serial Links"
Van Jacobson
Febrero 1.990
[RFC1332] RFC1332: "The PPP Internet Protocol Control Protocol
(IPCP)"
Glenn McGregor
Mayo 1.992
[RFC1333] RFC1333: "PPP Link Quality Monitoring"
William Allen Simpson
Mayo 1.992
[RFC1334] RFC1334: "PPP Authentication Protocols"
Brian Lloyd
William Allen Simpson
Octubre 1.992
[RFC1377] RFC1377: "The PPP OSI Network Layer Control Protocol
(OSINLCP)"
Dave Katz
Noviembre 1.992
[RFC1541] RFC1541: "Dynamic Host Configuration Protocol"
R. Droms
Octubre 1993
[RFC1570] RFC1570: "PPP LCP Extensions"
William Allen Simpson
Enero 1.994
[RFC1661] RFC1661: "The Point-to-Point Protocol (PPP)"
William Allen Simpson
Julio 1.994
[RFC1662] RFC1662: "PPP in HDLC-like Framing"
William Allen Simpson
Julio 1.994
[RFC1841] RFC1841: "PPP Network Control Protocol for LAN Extension"
Joelle Bafile Chapman
Dave Coli
Andy Harvey
Bent Jensen
Kevin Rowett
Septiembre 1.995
[RFC1877] RFC1877: "PPP Internet Protocol Control Protocol
Extensions for Name Server Addresses"
Steve Cobb
Diciembre 1.995
[RFC1915] RFC1915: "Variance for The PPP Connection Control
Protocol and The PPP Encryption Control Protocol"
Frank Kastenholz
Febrero 1.996
[SMACK] "The SMACK Protocol"
Jan Schiefer, DL5UE
Dieter Deyke, DK5SG/N0PRA
27 de Febrero de 1.992
Original en Alemán. Traducción al Inglés por Mike
Chace, G6DHU, en Febrero de 1.993
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
