Protocolo de red de Microcom

El protocolo de red Microcom , casi siempre abreviado como MNP , ^[1] es una familia de protocolos de corrección de errores que se usaban comúnmente en los primeros módems de alta velocidad (2400 bit/s y superiores) . Originalmente desarrollado para su uso en la propia familia de módems de Microcom , el protocolo fue posteriormente licenciado abiertamente y utilizado por la mayor parte de la industria de los módems, en particular los "tres grandes", Telebit , USRobotics y Hayes . MNP fue posteriormente reemplazado por V.42bis , que se usó casi universalmente a partir de los primeros módems V.32bis a principios de los años 1990.

Aunque Xmodem se introdujo en 1977, en 1985 The New York Times describió primero a XMODEM, luego habló de MNP como un contendiente líder y de que los módems de 9600 baudios "están comenzando a hacer su aparición". ^[2] En 1988, el Times hablaba de 9600 y 19,2K, y de que "al menos otras 100 marcas de módems siguen" a MNP (en comparación con el uso de LAP-B por parte de Hayes). ^[3]

Los módems son, por su naturaleza, dispositivos propensos a errores. El ruido en la línea telefónica, algo habitual, puede imitar fácilmente los sonidos que utilizan los módems para transmitir datos, introduciendo así errores que son difíciles de detectar. Para algunas tareas, como leer o escribir textos sencillos, se puede aceptar una pequeña cantidad de errores sin causar demasiados problemas. Para otras tareas, como transferir programas informáticos en formato de máquina, incluso un error puede hacer que los datos recibidos sean inútiles. A medida que los módems aumentan su velocidad al utilizar más ancho de banda disponible , también aumenta la posibilidad de que el ruido aleatorio introduzca errores; por encima de los 2400 bit/s, estos errores son bastante comunes.

Para solucionar este problema, se introdujeron e implementaron varios protocolos de transferencia de archivos en varios programas. En general, estos protocolos descomponen un archivo en una serie de tramas o paquetes que contienen una cantidad de bytes del archivo original. Se agrega algún tipo de datos adicionales, normalmente una suma de comprobación o CRC , a cada paquete para indicar si el paquete encontró un error al recibirlo. Luego, el paquete se envía al sistema remoto, que vuelve a calcular la suma de comprobación o CRC de los datos y los compara con la suma de comprobación o CRC recibidos para determinar si se recibieron correctamente. Si fue así, el receptor envía un mensaje ACK ( reconocimiento ), lo que indica al remitente que envíe el siguiente paquete. Si hubo algún problema, en su lugar envía un mensaje NAK ( no reconocido ) y el remitente reenvía el paquete dañado.

Este proceso introduce una "sobrecarga" en la transferencia. Por un lado, la suma de comprobación adicional o CRC consume tiempo en el canal que de otro modo podría utilizarse para enviar datos adicionales. Sin embargo, se trata de una preocupación menor, a menos que los paquetes sean muy pequeños (como lo son en UUCP , por ejemplo). Una preocupación más seria es el tiempo que necesita el receptor para examinar el paquete, compararlo con el CRC ^{[ cita requerida ]} y luego enviar el ACK de vuelta al remitente. Este retraso aumenta en términos relativos a medida que aumenta la velocidad del módem; la latencia de la línea telefónica es constante, pero la cantidad de datos que podrían enviarse en ese lapso de tiempo fijo aumenta a medida que aumenta la velocidad. Para abordar este problema, los protocolos más nuevos utilizan un sistema conocido como " ventanas deslizantes ", que permite al remitente comenzar a transmitir el siguiente paquete sin recibir un mensaje ACK; solo si el ACK no llega durante algún tiempo, reenviará el paquete.

Las conexiones MNP se establecían después de que los módems se hubieran conectado con éxito. El sistema de origen (el módem que realizaba la llamada o, a veces, la computadora a la que estaba conectado) enviaba una serie corta de caracteres de 8 bits conocida como "Patrón de detección de originador" (ODP). La cadena constaba de DC1con paridad par ( 10001000) al comienzo, uno o dos $FF( 11111111), DC1con paridad impar ( 10001001) y la misma cantidad de $FFnuevamente. ^[4]

Una vez enviado el ODP, el remitente inicia el "temporizador de fase de detección", o T400. El sistema de respuesta tenía que responder adecuadamente al ODP dentro de este tiempo, o el sistema de origen asumiría que no se admitía el MNP. ^[4]

Si el módem que respondía admitía MNP, o los estándares V.42 posteriores que lo reemplazaron, respondía con uno de los "Patrones de detección de contestador" (ADP). Si el módem admitía compresión, respondía con la versión de 8 bits de la cadena E$FF[ $FF] C$FF[ $FF], que indicaba "EC" o "Corrección de errores y compresión". Si se admitía la corrección de errores, pero no la compresión, el ADP era E$FF[ $FF] NUL$FF[ $FF], que indicaba "E" o "Corrección de errores". El estándar permitía cualquier valor de los últimos cuatro bits del segundo carácter para indicar estándares diferentes, pero esto nunca se implementó. El ADP tenía que enviarse al menos diez veces. ^[4]

Si el ADP se recibe correctamente dentro del tiempo T400, el sistema ha determinado con éxito que los dos sistemas admiten algún tipo de corrección de errores y/o compresión. En ese momento, los sistemas entran en la "Fase de establecimiento de protocolo", donde se determinan y seleccionan los detalles de estos estándares. Esto comienza con el sistema de origen enviando la cadena L-ESTABLISH, indicando que el modo está cambiando al modo de corrección de errores, y el sistema de respuesta responde con el mismo L-ESTABLISH. El sistema de respuesta puede rechazar el intento enviando L-RELEASE. Esta fase está cronometrada por T401. ^[4]

El paso final del proceso de enlace es enviar un paquete MNP que contiene el comando "SABME", abreviatura de "set asynchronous balanced mode extended" (establecer modo equilibrado asíncrono extendido). Este es enviado por el originador, que contiene una serie de campos de datos que indican los protocolos exactos que puede soportar. El sistema de respuesta responde con una versión modificada del mismo paquete, intercambiando bits en los datos para indicar que se ha realizado correctamente. A partir de ese momento, los dos sistemas intercambian datos utilizando el protocolo de paquetes de corrección de errores. Si este último paso no se completa durante el temporizador T401, el originador envía L-RELEASE y regresa a un enlace no MNP. ^[4]

La idea de Microcom era sacar el protocolo de transferencia de archivos del ordenador anfitrión y colocarlo en el módem. De ese modo, se corregirían los errores de todos los datos que se transfirieran, no sólo de las transferencias de archivos. Esto también significaba que los dispositivos sin procesador, como los terminales tontos , podrían disfrutar de una conexión sin errores.

El protocolo original era extremadamente simple y bastante ineficiente, lo que dio lugar a una variedad de protocolos mejorados denominados "clases". ^[5] Cada clase generalmente mejoraba el rendimiento con respecto a las versiones anteriores, que se mantuvieron solo por razones de compatibilidad con versiones anteriores.

El primer estándar MNP, conocido retroactivamente como MNP Clase 1 , o simplemente MNP 1 , era un protocolo simple semidúplex similar a XModem en su naturaleza. Al carecer de soporte de ventana deslizante, la eficiencia de procesamiento era bastante baja, de alrededor del 70%. Eso significaba que en un módem de 2400 bit/s, como los que vendía Microcom, el procesamiento estaría limitado a aproximadamente 1690 bit/s cuando se utilizaba MNP 1. Este sistema fue creado principalmente para que fuera lo más fácil posible de implementar en hardware limitado, lo que explica su simplicidad.

Con la mejora de la capacidad de procesamiento de bajo costo, Microcom introdujo MNP 2 , una versión full-duplex de MNP 1 que permitía que los mensajes ACK se devolvieran mientras el siguiente paquete saliente ya estaba comenzando. Esto eliminó la pausa mientras el módem esperaba que se devolviera el ACK, agregando el requisito de que el sistema necesitaba algo de memoria para rastrear si se recibió o no un ACK dentro de una cantidad de tiempo determinada. Dado que se redujo el retraso entre paquetes, solo permaneció la sobrecarga del CRC, lo que mejoró el rendimiento a aproximadamente el 84%. ^[6]

En condiciones normales de uso, un módem puede enviar o recibir datos en cualquier momento, un modo de funcionamiento conocido como "asincrónico". El módem puede determinar la velocidad de los datos del remitente escuchando los bits que se le envían y "sincronizando" su reloj con la velocidad de los bits que se reciben. Como los datos pueden llegar en cualquier momento, no hay un cronometraje preciso; es posible que haya que reajustar el reloj para hacer pausas cuando el usuario deja de escribir (por ejemplo).

Desafortunadamente, este tipo de decodificación de reloj no funciona a menos que haya al menos algunas transiciones entre 1 y 0 en los datos; un flujo largo de 0 o 1 no tiene transiciones, lo que hace imposible saber dónde comienzan los datos de un byte en particular . Para evitar este problema, se agregan bits de encuadre adicionales a cada extremo de cada byte, generalmente un bit en cada lado conocido como "bits de inicio y detención" . Esto garantiza al menos una transición de 1 a 0 para cada byte, más que suficiente para mantener los relojes bloqueados. Sin embargo, estos bits también se expanden cada 8 bits de datos (un byte) a 10 bits, una sobrecarga del 20%.

Cuando se utiliza un protocolo de transferencia de archivos, los propios paquetes ofrecen su propio encuadre. Los paquetes siempre enviarán un flujo continuo de datos, por lo que el reloj no puede "desviarse" de la misma manera que podría hacerlo con los datos que envía un usuario escribiendo en un teclado. Al desactivar estos bits de encuadre cuando se opera en un enlace con corrección de errores, se puede eliminar esa sobrecarga del 20 %.

Esto es precisamente lo que hizo MNP 3. Después de negociar y determinar que ambos módems admitían MNP 3, se desactivaron los bits de tramado, lo que mejoró la eficiencia general en un 20 % aproximadamente. Esto compensó casi a la perfección la sobrecarga del protocolo, lo que significa que al utilizar MNP 3, un usuario puede esperar acercarse mucho al rendimiento ideal de 2400 bit/s (en comparación con 1900 bit/s).

MNP 4 fue una mejora adicional de MNP 3, agregando un sistema de tamaño de paquete variable al que denominaron Ensamblaje de Paquetes Adaptativo .

En el caso de MNP, la sobrecarga del sistema de paquetes era relativamente pequeña, pero incluso el CRC multibyte ocupaba espacio que se podría utilizar mejor para los datos. En general, el uso de un paquete más grande solucionaría este problema, porque el CRC sigue teniendo el mismo tamaño fijo y, por lo tanto, su sobrecarga relativa se reduce en comparación con la cantidad de datos. Sin embargo, cuando ocurre un error, el uso de paquetes más grandes también significa que se deben reenviar más datos. En líneas ruidosas, esto puede reducir el rendimiento general.

Con MNP 4, los dos módems monitorean constantemente la línea para detectar paquetes descartados y, si se supera un cierto umbral (seleccionado por el usuario), el módem vuelve a usar un tamaño de paquete más pequeño. Esto significa que cuando se descarta un paquete, la cantidad de datos que se deben reenviar es menor, lo que genera un mejor rendimiento. En líneas de buena calidad, el uso de paquetes más grandes significa que se reduce la sobrecarga del CRC. Los paquetes pueden tener entre 64 y 256 bytes y permiten al usuario forzarlos a un tamaño particular si lo desea.

MNP 4 también introdujo la optimización de la fase de datos , un cambio simple en el protocolo que permitió que parte de la información de encuadre de paquetes se descartara después de que se estableciera el enlace, lo que redujo aún más la sobrecarga del protocolo. La combinación de estas características, junto con la falta de encuadre de bytes de MNP 3, permitió un aumento adicional en la eficiencia del rendimiento.

En el caso de MNP 5 , se introdujo un cambio aún más radical: la compresión de datos sobre la marcha en el módem. Con MNP 5, los datos recibidos del ordenador se comprimen primero con un algoritmo simple y luego se pasan al sistema de empaquetamiento MNP 4 para su transmisión. En el mejor de los casos, el sistema ofrecía una compresión de aproximadamente 2:1, pero en términos generales, lo típico era una compresión de aproximadamente 1,6:1, al menos en el caso del texto. Como resultado, un módem de 2400 bit/s parecería transferir texto a unos 4000 bit/s.

Este espectacular aumento del rendimiento permitió que los módems de Microcom siguieran siendo competitivos en cierta medida con los modelos de otras empresas que, en teoría, eran mucho más rápidos. Por ejemplo, Microcom generalmente producía módems de 1200 y 2400 bit/s utilizando componentes básicos, mientras que empresas como USRobotics y Telebit ofrecían modelos con velocidades de hasta 19200 bit/s.

Sin embargo, esta mejora en el rendimiento sólo estaba disponible si los módems en ambos extremos admitían MNP. Eso hacía que el sistema sólo fuera realmente atractivo para los sitios que instalaban los módems en ambos extremos de los enlaces; para servicios de acceso telefónico como los sistemas de tablones de anuncios (BBS) no había ninguna razón convincente para utilizar un dispositivo Microcom cuando era poco probable que el usuario final tuviera uno. Incluso en los casos en que el usuario tenía el control de ambos extremos del enlace, los módems "propietarios" de Microcom eran menos interesantes que los modelos de otras empresas que ofrecían rendimientos "reales" mucho más altos.

Para crear un mercado para los módems Microcom, a partir del MNP 5, tomaron la decisión radical de conceder licencias gratuitas para todo el paquete MNP. La idea era que esto aumentaría drásticamente la cantidad de módems con MNP instalado, lo que haría que los módems Microcom "reales" fueran más atractivos. Además, los estándares más nuevos con un rendimiento mejorado ofrecerían un rendimiento aún mejor cuando hubiera un módem Microcom en ambos extremos del enlace.

Este plan fracasó. La introducción del sistema de compresión LAPM , muy mejorado , en el estándar V.42bis superó los avances de Microcom, lo que diluyó el valor de un modelo Microcom "real" casi a cero. Al utilizar V.42bis y componentes básicos, pronto estuvieron disponibles una gran cantidad de módems de bajo costo con un rendimiento incluso mejor que el de Microcom. Aunque Microcom continuó introduciendo estándares más nuevos, estos fueron ignorados en gran medida y Microcom dejó de ser una fuerza en el mercado.

La introducción del V.32 dio lugar a una serie de módems estándar de 9600 bit/s, casi todos los cuales ofrecían MNP 5. Para diferenciarse aún más de lo que se estaba convirtiendo en un mercado de productos básicos (aunque no realmente hasta la introducción del V.32bis SupraFAXModem 14400 en 1991), Microcom creó MNP 6 .

La característica principal de MNP 6 era el Duplexing Estadístico , que podía dedicar más o menos ancho de banda a un lado o al otro del enlace del módem. Por ejemplo, si una máquina estaba enviando un archivo grande, el otro extremo sólo enviaría de vuelta una pequeña cantidad de información, los mensajes ACK y NAK. En este caso los módems darían la mayor parte posible del canal al remitente, ofreciendo un ancho de banda unidireccional de hasta 19.200 bit/s. Esto en realidad no requería ningún cambio en el sistema de modulación: normalmente un módem de 9600 bit/s tenía un canal completo de 9600 bit/s en ambas direcciones, para un total de 19200 bit/s; MNP 6 simplemente permitía que más o menos de ese ancho de banda se diera a un lado o al otro, en lugar de dejarlo fijo en 9600 en ambos sentidos.

Este concepto básico ya se utilizaba ampliamente en la industria, y había formado la base del protocolo Express 96 de Hayes , el PEP de HST Telebit de USRobotics y (brevemente) el SpeedModem de CompuCom . Todos estos estándares tuvieron muchas dificultades para sobrevivir en el mercado dominado por V.32bis y, al igual que ellos, MNP 6 fue en gran medida ignorado.

Una adición menos notable a MNP 6 fue la negociación de enlaces universales . Con la introducción de modos de modulación adicionales, en particular V.32 y adiciones posteriores, los módems en ambos extremos del enlace tuvieron que dedicar una cantidad cada vez mayor de tiempo a negociar un estándar común. Por ejemplo, un módem V.32bis primero enviaría tonos a la línea para intentar obtener un enlace de 14,4; si eso fallaba después de un tiempo, intentaría con 9600, 2400 y finalmente 1200 bit/s. Dado que cada uno de estos estándares definía un período mínimo de tiempo para "intentar" un enlace, el retraso aumentó en más de 10 segundos.

ULN evitó este retraso negociando siempre el enlace a 2400 bit/s sin la corrección de errores activada. Aunque esto eliminó la compatibilidad con módems más antiguos de 1200 bit/s, en ese momento eran extremadamente raros. Una vez que se realizó la conexión, lo que ocurrió rápidamente, ambos módems enviaron una pequeña cadena de identificación al módem remoto. Ambos módems examinaron la cadena y seleccionaron el modo común más rápido. El interlocutor volvió a negociar una vez más a esa velocidad más alta.

MNP 7 introdujo nuevos algoritmos de compresión con una supuesta mejora en la compresión 3:1 en archivos de texto. Sin embargo, cuando se introdujo MNP 7, el estándar V.42bis ofrecía una compresión 4:1.

MNP 9 (aparentemente no se lanzó la versión 8) mejoró la detección de enlace universal para agregar modos de alta velocidad más nuevos, pero por lo demás era idéntico a MNP 7.

El MNP 10 introdujo un nuevo protocolo de corrección de errores diseñado específicamente para funcionar bien en las ruidosas líneas telefónicas que se utilizan ampliamente en Europa del Este. A diferencia de versiones anteriores como el MNP 4, el MNP 10 monitoreaba constantemente la calidad de la línea y ajustaba el tamaño de los paquetes si las condiciones mejoraban.

En 1991, Microcom otorgó la licencia de MNP 10 a Rockwell International para su uso en sus conjuntos de chips para módems, que eran extremadamente populares. Dado que casi todos los módems, con excepción de los modelos de USR, utilizaban el conjunto de chips de Rockwell desde aproximadamente 1995, MNP 10 se implementó de manera bastante amplia (si no se utilizó). USR finalmente agregó MNP 10 a sus módems de la serie V.everything, lo que lo convirtió en algo universal.

El MNP 10 se amplió posteriormente a MNP 10EC , donde "EC" significa "Extended Cellular". Se trató de una serie de modificaciones que permitieron al MNP 10 lidiar con las pausas de transmisión cuando un teléfono celular se mueve de una celda a otra, lo que normalmente se interpretaría como errores en la línea. Con el MNP 10EC, estas pausas se identifican correctamente como "no errores", y la velocidad del enlace sigue siendo mayor. Su éxito dio lugar al competidor creado por AT&T Paradyne, ETC.

El MNP 10EC resultó particularmente atractivo en el ámbito celular debido a la inclusión del método de negociación de enlaces ULN introducido originalmente en el MNP 6 (y mejorado en el MNP 9). En una red celular en la que se factura todo el tiempo de emisión, la configuración más rápida permitió ahorrar dinero. El MNP 10EC tuvo una vida útil limitada, ya que las redes celulares recurrieron a una variedad de sistemas totalmente digitales que ya no requerían un módem para conectarse a una computadora.

Aunque MNP es una propiedad exclusiva, las clases 2 a 4 se describen en realidad en la especificación V.42 en el Anexo A como un procedimiento alternativo para la función de control de errores. Este Anexo se presenta en la especificación hasta la revisión de 1996 ^[7] . En la última revisión de 2002 se eliminó.

• X.PC
• YMódem
• ZMódem
• BLAST (protocolo)
• Kermit (protocolo)