Tema 2. Estructura de un protocolo

Transcripción

1 Tema 2 Estructura de un protocolo 5º curso de Ingeniería Informática Ingeniería de protocolos Curso Profesora: Mª del Carmen Romero [email protected] ETSII L3 (1ª planta) Despacho G1.52 [ Autor original de esta documentación: Antonio Barbancho (curso ) Modificada por: Mª del Carmen Romero (curso ) ]

2 Ingeniería de protocolos Indice 1. Introducción 3 2. Los cinco elementos de un protocolo 5 3. Servicio y entorno Vocabulario y formato de los mensajes Reglas de procedimiento Diseño de protocolo estructurado Simplicidad Modularidad Protocolos bien formados Robustez Consistencia Las diez reglas de diseño Mecanismos básicos de los protocolos Control de secuencia y control de errores Redundancia Tipos de códigos Códigos de paridad Corrección de errores Control de flujo Protocolo simple sin control de flujo Protocolo Xon-Xoff Protocolo de parada y espera Protocolo de parada y espera con timeout Protocolo de bit alternante Protocolos de ventana Bibliografía 36 2 de 37

3 Ingeniería de Protocolos 1. Introducción En este tema se van repasar los elementos básicos de la ingeniería de protocolos, haciendo hincapié en la metodología de diseño. No es el propósito de este tema tratar los protocolos físicos, simplemente supondremos que se dispone de un medio físico capaz de transmitir bits o bytes. Nuestro objetivo será escribir correctamente una serie de reglas que usen adecuadamente dicho medio, definiendo cómo se codifican los mensajes, cómo se inicia o finaliza una comunicación, etc. Hay que evitar, por todos los medios, dos tipos de errores: el diseño de un conjunto de reglas incompleto y el diseño de reglas contradictorias. En este capítulo, buscaremos formas de asegurar que el conjunto de reglas desarrollado sea completo y consistente. Esto requiere que seamos precisos a la hora de especificar todas las partes relevantes de un protocolo. Además, requiere alguna disciplina para separar los aspectos independientes, utilizando modularidad y estructuración. Echemos un primer vistazo a los tipos generales de servicios que un protocolo de comunicaciones debe ser capaz de proporcionar. Supongamos dos computadores, A y B. A está conectado a un dispositivo de almacenamiento de ficheros d, y B está conectado a la impresora i. Queremos enviar un fichero de texto desde el almacén de ficheros de A (d) a la impresora conectada a B (i). Para poder llevar a cabo la comunicación, ambas máquinas deben usar el mismo medio físico, codificaciones de caracteres compatibles y transmitir y recibir las señales de los medios aproximadamente a la misma velocidad. Sin embargo, suponiendo que esas cuestiones han sido resueltas, aún queda el problema de enviar las señales por un cable. El computador A debe ser capaz de comprobar si la impresora está o no disponible para imprimir. Debe ser capaz de adaptar la velocidad a la que está enviando los caracteres a la velocidad en la que la impresora los procesa. Concretamente, la máquina debe ser capaz de dejar de enviar cuando la impresora no tiene papel o se ha apagado. Es importante observar que, aunque los datos actuales flujen en una única dirección, desde A hasta B, necesitamos un canal bidireccional para intercambiar información de control. Las dos máquinas deben haber alcanzado previamente un acuerdo en el significado de la información de control y en los procedimientos 3 de 37

4 Ingeniería de protocolos utilizados para iniciar, suspender, reanudar y concluir las transmisiones. Además, si hay errores de transmisión, es necesario intercambiar información de control para controlar la transferencia de los datos. Mensajes de control típicos son, por ejemplo, el acuse de recibo positivo y el acuse de recibo negativo, que el receptor puede usar para permitir al emisor saber si el dato fue o no recibido intacto (sin errores). Todas las reglas, formatos y procedimientos que han sido acordados entre la máquina A y B son denominados de forma conjunta como un protocolo. En definitiva, el protocolo formaliza la interacción estandarizando el uso de un canal de comunicación. El protocolo, entonces, puede contener acuerdos sobre los mecanismos utilizados para: - Iniciación y finalización de los intercambios de datos - Sincronización de emisores y receptores - Detección y corrección de errores de transmisión - Formateo y codificación de los datos La mayoría de estas cuestiones pueden ser definidas en más de un nivel de abstracción. Menor abstracción Mayor abstracción Figura 1. Niveles de abstracción de ejemplo: formateo. A bajo nivel de abstracción, por ejemplo, cualquier sincronización se trata de aplicar la sincronización del reloj del transmisor y receptor que es utilizado para poner o tomar los datos de la línea física de transmisión. A alto nivel de abstracción, la sincronización está relacionada con la sincronización de las transferencias de mensajes (por ejemplo en los mecanismos de control de flujo y control de velocidad), y aún a más alto nivel, se llega a un acuerdo con la sincronización y coordinación de las fases principales del protocolo. 4 de 37

5 Ingeniería de Protocolos En el nivel más bajo de abstracción, una definición de formato podría ser un método para codificar bits con señales eléctricas analógicas. En el siguiente nivel, se pueden aplicar métodos para codificar los caracteres individuales de la transmisión en patrones de bits. En el siguiente nivel, los códigos de carácter pueden ser agrupados en distintos campos dentro de un mismo mensaje y los campos del mensaje, a su vez, agrupados en tramas o paquetes, cada uno con un significado y una estructura específicos. Los métodos de control de error que un protocolo necesita dependen de las propiedades específicas del medio de transmisión utilizado. Este medio puede insertar, borrar, distorsionar o incluso duplicar y desordenar los mensajes. Dependiendo del comportamiento específico, el diseñador del protocolo puede idear una estrategia de control de error. Las descripciones de protocolo que hemos comentado hasta ahora son informales y fragmentadas. Es fácil suponer que el implementador se encargará de completar la funcionalidad que el diseñador no ha especificado plenamente. Sin embargo, esto puede llevar a implementaciones ambigüas e incorrectas del protocolo. Por ello, es muy importante en el diseño de protocolos formalizar y estructurar las descripciones, indicando explícitamente todas las suposiciones. 2. Los cinco elementos de un protocolo Una especificación de protocolo está constituida por cinco partes diferenciadas. Para que fuera completa, cada especificación debería incluir de manera explícita lo siguiente: 1. El servicio que debe proporcionar el protocolo 2. Las suposiciones acerca del entorno en la que el protocolo va a ser ejecutado 3. El vocabulario de los mensajes utilizados para implementar el protocolo 4. La codificación (formato) de cada mensaje en el vocabulario 5. Las reglas de procedimiento que controlan la consistencia del intercambio de mensajes El quinto elemento de una especificación de protocolo es el más complejo de diseñar y el más arduo de verificar. También es el menos conocido, pues la mayor parte de la bibliografía sobre comunicaciones y redes se centra en los otros aspectos de la especificación. Cada parte de la especificación del protocolo puede definir una jerarquía de elementos. Por ejemplo, el vocabulario del protocolo puede estar formado por una jerarquía de clases de mensajes. De igual modo, la definición del formato puede especificar cómo se construyen los mensajes de más alto nivel a partir de los elementos de mensajes de más bajo nivel y así. Una definición de protocolo puede compararse con una definición de un lenguaje, pues un lenguaje contiene una definición de vocabulario y de sintaxis (formato del protocolo), las reglas de procedimiento definen colectivamente una gramática, y la especificación del servicio define la semántica del lenguaje. Hay algunos requerimientos especiales que debemos imponer a este lenguaje de protocolo: no debe ser ambíguo y debe especificar el comportamiento de procesos concurrentes. Esto último hace que tengan que considerarse nuevos problemas: la temporización, las condiciones de carrera y los bloqueos, entre otros. Como la secuencia de eventos no puede ser pronosticada de forma precisa, el número de combinaciones de los 5 de 37

6 Ingeniería de protocolos eventos puede ser tan grande que frusta cualquier intento de analizar el protocolo con un simple análisis manual. Es necesario, por tanto, utilizar una herramienta que permita especificar lenguajes (protocolos) con todas las consideraciones anteriores y de forma efectiva, facilitando el tratamiento automatizado de la mayor parte de las fases de la ingeniería. Veamos un ejemplo en cada una de las cinco partes de la especificación de un protocolo. Especificación del servicio El propósito del protocolo es transferir ficheros de texto como secuencias de caracteres a través de una línea da datos mientras que en la protección frente a errores de transmisión, se asume que todos los errores pueden ser detectados. El protocolo se define para transferencias full-duplex, es decir, debería permitir transferir en ambas direcciones simultáneamente. Los acuses de recibo positivos y negativos para el tráfico desde A hasta B se envían por el canal desde B hasta A y viceversa. Cada mensaje contiene dos partes: una parte que es el mensaje en sí y una parte de control que se aplica al tráfico del canal inverso. Suposiciones sobre el entorno El "entorno" en el que el protocolo se ejecuta está constituido, como mínimo, por dos usuarios del servicio de transferencia de ficheros y un canal de transmisión. Se puede suponer que los usuarios simplemente envían una solicitud de transferencia de fichero y esperan a que dicha transferencia finalice. Se supone que el canal de transmisión causa distorsiones aleatorias en los mensajes, pero no se pierden, duplican, insertan o desordenan los mensajes. Asumiremos que utilizamos un módulo del nivel más bajo para captar todas las distorsiones y cambiarlas a mensajes no distorsionados de tipo err. Vocabulario del protocolo Se diferencian tres tipos de mensajes: - ack, corresponde a un mensaje combinado con una acuse de recibo positivo - nack, corresponde a un mensaje combinado con acuse de recibo negativo - err, para un mensaje con un error de transmisión El vocabulario puede ser expresado como un conjunto: V={ack, nack, err} Cada tipo de mensaje puede ser refinado posteriormente en una clase de mensajes de más bajo nivel, estando formado, por ejemplo, de un subtipo para cada código de carácter que vaya a ser transmitido. Formato del mensaje Cada mensaje está constituido por un campo de control que identifica el tipo de mensaje y un campo de dato con la codificación del carácter. Vamos a suponer, por ejemplo, que los campos de control y dato poseen un tamaño fijo. Considerando lo anterior, la forma general de cada mensaje puede ser representada simbólicamente como una estructura simple de dos campos: {etiqueta de control, dato} 6 de 37

7 Ingeniería de Protocolos Que en una especificación en C podría ser especificada más detalladamente como: enum control {ack, nack, err}; struct message { enum control etiqueta; unsigned char dato; }; La primera línea comienza con la palabra reservada enum que declara un tipo enumerado llamado control con tres posibles valores, uno para cada tipo posible de mensaje. La estructura del mensaje en sí misma contiene dos campos; una etiqueta de tipo control y un campo de dato declarado como un unsigned char (byte). Reglas de procedimiento Las reglas de procedimiento para el protocolo se describen informalmente como: 1. Si la recepción anterior estuvo libre de errores, el siguiente mensaje por el canal inverso debe llevar un reconocimiento positivo; en caso contrario, llevará un reconocimiento negativo. 2. Si la recepción anterior portaba un reconocimiento negativo, o si fue errónea, se retransmitirá el último mensaje; en caso contrario se transmitirá el mensaje siguiente." Para formalizar estas reglas se pueden utilizar diagramas de transición de estados, diagramas de flujo, expresiones algebraicas o descripciones en forma de programa. Para este ejemplo, utilizaremos este diagrama de flujo: Inicio de la transmisión ste:o recibiendo nack:i ack:i err:i ste:o ack:o ack:o nack:o Figura 2. Diagrama de flujo del protocolo ejemplo. 7 de 37

8 Ingeniería de protocolos La transmisión se inicia enviando el primer mensaje, se pasa al estado de espera aguardando la respuesta del receptor a través del canal. Estando en estado de espera pueden recibirse (y reconocerse) una de estas tres cosas: 1. un acuse de recibo positivo (ack) de entrada 2. un acuse de recibo negativo (nack) de entrada 3. un mensaje de error (err) de entrada Si se recibe un ack, se obtiene el siguiente mensaje (ste:o) y se transmite, puesto que el receptor nos ha indicado que recibió el anterior correctamente, y se envía un ack de salida hacia al receptor indicándole que llegó su mensaje. En el caso 2, se envía un ack de salida (ack:o) con un acuse de recibo positivo del último mensaje recibido, pero retransmitiendo el último dato de la cola de mensajes a enviar. En el caso 3, se envía un ack de salida (nack:o) con un acuse de recibo negativo y también se retransmite de nuevo el último dato de la cola de mensajes a enviar. En cualquiera de los tres casos, una vez que se envía el acuse de recibo al receptor, se pasa de nuevo al estado de espera. Como era de esperar, hay ciertos problemas con esta descripción que necesitarán ser reconsiderados. Defectos de diseño Primero, tenemos el problema de que la transferencia en una dirección no puede continuar hasta que no haya finalizado la transferencia del dato en la otra dirección. Otro problema que tenemos que resolver antes de utilizar el protocolo es decidir cómo se va a iniciar y a finalizar una transmisión de datos. Las dos reglas de procedimiento especifican transferencia de dato ordinario, pero no los procedimientos de inicio y finalización. Podemos tratar de iniciar la transferencia de datos haciendo que uno de los dos procesos envíe un mensaje intencionado de error. Observa que, si se permite que ambas partes inicien el protocolo de esa forma, es difícil traer los dos procesos a la misma fase. Sin embargo, terminar la transferencia cuando los procesos han terminado de intercambiar mensajes requiere mensajes de control extras. Una deficiencia muy importante de este protocolo es que se ha omitido una operación básica en la especificación. El receptor tiene que ser capaz de decidir si el dato recibido y almacenado temporalmente en la variable i es o no aceptado (y, por ejemplo, guardado en un fichero). Los mensajes recibidos correctamente, pero que son duplicados de mensajes anteriores, no deberían ser aceptados de nuevo. Este problema parece no tener solución si mantenemos las dos reglas de procedimiento indicadas anteriormente. Considera qué puede ocurrir si cada mensaje recibido correctamente es aceptado, es decir, el dato añadido a los mensajes de ack y nack son aceptados, pero el dato añadido al mensaje err no. La extensión parece acertada pero desafortunadamente no resuelve el problema. La siguiente secuencia de ejecución, por ejemplo, lleva a la aceptación de un mensaje duplicado. Primero el proceso A inicia la transferencia enviando un mensaje de error intencionado (err) a B. Suponemos que A intenta transmitir el alfabeto (de la 'a' a la 'z'), y que B responde transmitiendo los caracteres en orden inverso (de la 'z' a la 'a'). Considera entonces la secuencia de eventos sin error ilustrada en la diagrama temporal de la Figura 3 (izq) y el caso donde se producen dos errores consecutivos en la secuencia, ilustrado en la Figura 3 (der). 8 de 37

9 Ingeniería de Protocolos Figura 3. Ejemplo: (izq) transmisión sin errores, (der) transmisión con dos errores consecutivos. Veamos, paso a paso, qué ocurre en esa secuencia: Figura 4. Ejemplo: explicación de la secuencia 9 de 37

10 Ingeniería de protocolos Aunque el protocolo propuesto es simple, es muy complicado descubrir el error, y no es acertado suponer que el error, que no es detectado en la fase de diseño, se encontrará más tarde o más temprano en la fase de pruebas, pues el problema sólo afecta cuando se dan dos errores consecutivos. Ya que la especificación es incompleta, cualquier implementación que se desarrolle a partir de ella sufrirá potencialmente errores durante el intercambio de datos. Este ejemplo que acabamos de ver, debería convencernos de que son indispensables una buena disciplina de diseño y herramientas de análisis efectivas. 3. Servicio y entorno Para llevar a cabo una tarea de alto nivel, tal como la transferencia de ficheros, un protocolo debe realizar una serie de funciones de más bajo nivel, tal como la sincronización y la recuperación de errores. La realización específica de un servicio depende de las suposiciones que consideremos sobre el entorno donde vamos a ejecutar el protocolo. El sentido común nos dice que si un problema es demasiado grande, debemos dividirlo en subproblemas más pequeños y fáciles de resolver, o bien que ya hayan sido resueltos antes. El software, y en particular, el software de protocolo, debe estructurarse convenientemente en niveles o capas. Las funciones más abstractas se definen e implementan en función de las capas de menor nivel de abstracción, donde cada capa se encarga de ocultar propiedades no deseables del canal de comunicación y las transforma a un medio más idealizado. Como ejemplo, supondremos que queremos implementar un protocolo de transmisión de datos que proporciona 7 bits para la codificación de cada carácter, y para realizar una detección básica de errores utiliza un bit de paridad que se añade a cada tupla de 7 bits utilizada para representar un carácter. Así pues, este protocolo suministra dos servicios: codificación y detección de errores. Podemos separar ambos servicios en dos submódulos funcionales distintos, un módulo codificador y un módulo de paridad, que son invocados secuencialmente. En el otro extremo de la línea tendremos un decodificador y un testeador de paridad. Para transmisiones full-duplex, podemos combinar de manera conveniente la función del codificador y del decodificador dentro de único módulo, llamado P2, y de forma similar, podemos combinar la función del generador y testeador de paridad dentro de un mismo módulo, llamado P1. Esto queda ilustrado en la Figura 5. Figura 5. Construir un canal virtual 10 de 37

11 Ingeniería de Protocolos El canal, representado por la línea discontinua, se envuelve en dos capas. En efecto, cada capa proporciona un servicio diferente e implementa un protocolo separado. La primera capa implementa el protocolo P1, mientras que la segunda capa implementa el protocolo P2. El formato del dato del protocolo P2 es una palabra de 7 bits, mientras que el formato del dato del protocolo P1 es una palabra de 8 bits. El protocolo P2 ni ve ni conoce nada sobre el octavo bit que añade el módulo de paridad a cada una de sus palabras de 7 bits. De lo único que debe preocuparse es que el canal por el que viajan sus palabras de 7 bits sea más confiable que el canal físico que está por debajo. El protocolo P1 suministra un canal virtual para el protocolo P2, pero es completamente transparente al protocolo P2. Las dos palabras claves son transparente y virtual. Transparente es algo que existe pero que parece que no existe, mientras que virtual es algo que parece que existe pero no existe. Para el protocolo P1, cualquier formato de datos que imponga el protocolo P2 es transparente. En cuanto a P1, es una secuencia no interpretable de datos, de los que sólo conoce su longitud. De forma similar, ni la capa del protocolo P2 ni la del protocolo P1 conocen nada sobre el formato impuesto por otras supuestas capas inferiores o superiores (P0, P3, P4...). Envoltura de nivel n-ésimo Figura 6. Envolturas de datos Como se muestra en la Figura 6, cada capa puede encerrar el dato que va a ser transmitido en una nueva envoltura de datos, formada por una cabecera y/o un pie, antes de pasarlo a la siguiente capa. No es necesario que el formato del dato original desde las capas más altas sea conservado por las capas más bajas. Es decir, el dato puede ser dividido de forma diferente, en porciones mayores o más pequeñas, siempre y cuando se restaure el formato original en el módulo del protocolo receptor. Las ventajas obtenidas son claras: - Un diseño por capas ayuda a indicar las estructura lógica del protocolo separando las tareas de más alto nivel de los detalles de las tareas de más bajo nivel. - Cuando el protocolo debe ser extendido o cambiado, es más fácil reemplazar un solo módulo que reemplazar el protocolo completo. En 1980, la ISO (International Standards Organization) reconoció las ventajas de estandarizar una jerarquía de servicios de protocolo como un modelo de referencia para los diseñadores de protocolos. Éste es el ya 11 de 37

12 Ingeniería de protocolos conocido modelo OSI (Open Systems Interconnection). Otro modelo de referencia, esta vez un estándar de facto, es el ampliamente utilizado TCP/IP (familia de protocolos de Internet). La división por niveles es un concepto importante en el diseño de protocolos, así como todo lo relacionado con ella. Desde un punto de vista abstracto, cada uno de los niveles idealiza el canal, ofreciendo un canal virtual mejorado que suministra servicios específicos a sus niveles superiores y recibe servicios de sus niveles inferiores. Esta metodología es muy potente si se usa adecuadamente, pero puede ser contraproducente si se lleva a los extremos. - Una capa define un nivel de abstracción en el protocolo, agrupando funciones que están íntimamente relacionadas y separando aquellas que son independientes entre sí. Desacoplando las capas, se pueden hacer futuros cambios en una sola capa sin que afecte al diseño de otras capas - Un interfaz constituye la frontera entre niveles de abstracción distintos. Un interfaz colocado convenientemente es pequeño y bien definido. Un interfaz mal ubicado causa una complejidad innecesaria, duplicación de código e incluso puede degradar el rendimiento del protocolo. Figura 7. División en niveles La Figura 7 ilustra los principales conceptos de una técnica de división en niveles. Todas las funciones de una misma capa (N) forman una misma entidad lógica. Dos entidades del mismo nivel se denominan entidades pares. Por convención, el límite entre dos capas adyacentes se denomina interfaz, mientras que el límite entre dos entidades pares en sistemas separados se denomina protocolo par (de nivel N). Ya que los detalles de implementación local de los interfaces de capas pueden ocultarse fácilmente del entorno, sólo los protocolos pares deben ser estándares entre sistemas distintos. La interfaz entre dos niveles diferentes se define como una colección de puntos de acceso al servicio (SAP, Service Access Point) implementados por el nivel inferior y que dan servicio al nivel superior. La información que se intercambia entre las interfaces se formatea incrementalmente en las múltiples capas en las denominadas PDUs (Protocol Data Unit).La información pasa desde la capa más alta del emisor hacia las capas 12 de 37

13 Ingeniería de Protocolos inferiores, llegando al medio físico por donde la información circula de un sistema hacia otro y llegando al receptor desde las capas inferiores hacia las superiores. Podemos reconocer, pues, dos de los cinco elementos importantes de la especificación de protocolos: - el servicio que suministra el protocolo (de la capa inferior a la superior) - las suposiciones realizadas sobre su entorno (servicios utilizados y que debe proporcionar el nivel inferior) Las peticiones de servicio se denominan primitivas abstractas de servicio (ASP, Abstract Service Primitive) y se pueden clasificar en: - Primitiva de petición (Request): la emite un usuario cuando quiere invocar un servicio suministrado por el nivel inferior. Por ejemplo, servicio de conexión o de envío de datos. - Primitiva de indicación (Indication): la emite el que suministra el servicio para indicar una petición del usuario par remoto o del propio suministrador. - Primitiva de respuesta (Response): la emite un usuario en respuesta a una petición de su entidad par. - Primitiva de confirmación (Confirm): la emite el suministrador del servicio para confirmar o completar alguna petición anterior del usuario. (Capa N-1) Figura 8. Primitivas de servicio En la Figura 8 se muestra una secuencia temporal de todos los tipos de primitivas de servicio. En este ejemplo, X es el nombre del servicio, como puede ser DATA (servicio para enviar datos), CONNECT (servicio para realizar una conexión)... En este ejemplo, se trataría de un servicio confirmado en el se utilizan todas las primitivas. También existen servicios no confirmados, que sólo utilizan primitivas request e indication. Es el diseñador quien debe decidir si un determinado servicio debe o no ser confirmado. 13 de 37

14 Ingeniería de protocolos Transmisor Usuario Receptor Usuario E-DATA.request(DATO) E-DATA.indication(DATO) Enlace Enlace F-DATA.req(SEC, DATO) F-DATA.ind(SEC,ACK) F-DATA.req(SEC, ACK) F-DATA.ind(SEC,DATO) Medio físico Figura 9. Diagrama de correlación de las primitivas 4. Vocabulario y formato de los mensajes Al igual que el resto de los elementos de la especificación de un protocolo, el vocabulario y formato de los mensajes se deben definir para cada uno de los niveles. Así, en cuanto al formato de los mensajes, a bajo nivel podemos tener protocolos orientados a bit o a carácter. En cualquiera de ellos es necesario definir una serie de patrones para la unidad de transmisión que permitan al receptor reconocer el principio y final de un mensaje. Un protocolo orientado a bit trasnmite el dato como un flujo de bits. Para que el receptor pueda reconocer dónde empieza y termina un mensaje (una trama), se define un pequeño conjunto de patrones específicos de bits (flags). Estos patrones de bits pueden ser o no parte del dato, siempre y cuando se puedan reconocer de forma fiable en el receptor del mensaje. Un ejemplo de protocolo que utiliza este formato es el protocolo HDLC (de capa 2 de OSI). En un protocolo orientado a carácter se impone una estructura mínima en el flujo de bits. Si el número de bits por carácter es fijado a n bits (normalmente 7 ó 8 bits), toda la comunicación tiene lugar en múltiplos de n bits. Estas unidades de datos se usan para codificar los datos de usuario y los datos de control. Ejemplos de códigos de control son los mensajes de inicio (STX) y fin (ETX) de un texto en ASCII. A un nivel superior, el mensaje también se estructura para reconocer las partes del mensaje propias de cada nivel. Por ejemplo, para poder implementar un sistema de detección de errores, es necesario añadir cierta redundancia a los datos, normalmente en forma de una suma de control (checksum). Si se quiere realizar un control de flujo para detectar la pérdida o desorden de los mensajes, se debe añadir un campo de secuencia. Por otro lado, si hay varios tipos de mensajes posibles, es habitual disponer de un campo que indique ese tipo. Esta información que se añade es normal que se distribuya al principio y/o al final del mensaje recibido desde el nivel superior. Por tanto, el formato de un mensaje se puede definir como: Formato={ cabecera, datos, cola } 14 de 37

15 Ingeniería de Protocolos A su vez, la cabecera y la cola pueden estar constituidas por varios campos: Cabecera={ tipo, destino, número de secuencia, longitud } Cola={ checksum, dirección de retorno } El campo tipo se usa para identificar los mensajes que forman parte del vocabulario de nuestro protocolo. Ejemplo de tipos de mensajes son los vistos anteriormente en un ejemplo: ack, nack y err. 5. Reglas de procedimiento Un aspecto importante del problema de diseño de un protocolo es que las reglas de procedimiento son interpretadas concurrentemente por una serie de procesos que interactuan. El efecto de cada nueva regla que añadimos al conjunto es mucho mayor de lo que podamos prever en un principio. Debido a esta concurrencia, el comportamiento de un protocolo no siempre es reproducible. Para conseguir mayor exactitud en el diseño necesitamos algo más que un razonamiento informal. La herramienta más popular para razonar sobre el funcionamiento de un protocolo es el diagrama temporal ilustrado en la Figura 3, sin embargo no es adecuada para situaciones relativamente complejas. Otra opción es utilizar la máquinas de estados finitos, que es la notación que usaremos en este tema para ver ejemplos de diversos protocolos. La notación para las máquinas de estados finitos se detalla en la Figura 10. Figura 10. Notación de la máquina de estados finita Se tienen una serie de estados (círculos), en función de los eventos de entrada (evento_n) y de unas condiciones (condición_n) se obtienen unas acciones de salida (accion_n) y una transición (flechas) hacia otro estado o hacia el mismo estado. 15 de 37

16 Ingeniería de protocolos 6. Diseño de protocolo estructurado El diseño de protocolos implica un amplio rango de cuestiones. Algunas de ellas se sobreentienden bastante bien, otras se están empezando a comprender ahora. El diseño de protocolos es en parte un problema de ingeniería que puede afrontarse mediante la aplicación de técnicas ya conocidas. Por ejemplo en el nivel físico se conocen perfectamente los comportamientos característicos de los distintos tipos de portadores de información, cómo de rápido se puede transmitir sobre ellos, y cuál será la tasa media de errores. Hay varias técnicas para codificar información binaria en las señales analógicas que pueden transportarse de diversas formas, y se dispone de técnicas efectivas para sincronizar el emisor y el receptor a este nivel. No hace falta reinventar y volver a validar estas técnicas para cada nuevo protocolo y, de hecho, se pueden considerar tan estándares que se tratan en otras asignaturas del área de conocimiento. A más alto nivel, nos enfrentamos con problemas de diseño de redes: encaminamiento de datos a través de redes, el adecuado dimensionamiento de las estructuras de red, la interconexión de redes a través de gateways y el desarrollo de disciplinas de alto nivel de control de congestión. Estos elementos han sido en parte solucionados en la actualidad, en concreto, ciertas técnicas de control de errores y de flujo. Sin embargo, queda por resolver de manera definitiva la forma de diseñar un conjunto de reglas adecuados para intercambiar información entre sistemas distribuidos. Las técnicas disponibles en otras disciplinas de la ingeniería imponen un conjunto de restricciones cuidadosamente escogidas al ingeniero. Estas restricciones tienen como objetivo reforzar un principio de diseño que recoge toda la historia de errores, colectivamente llamada experiencia, desde las primeras fases de diseño. En cierto sentido, se automatiza la tarea del diseño, de forma que se garantice, con una alta probabilidad, que las cosas salen como deben. Por tanto, un diseñador se acogerá a una disciplina, que en parte le limita, si a cambio obtiene un producto más fiable. Esa disciplina ya empieza a esbozarse en la Ingeniería de Protocolos. A continuación se listan algunos de sus elementos fundamentales, basados en dos pilares fundamentales: la simplicidad y la modularidad Simplicidad Un protocolo bien estructurado se puede construir a partir de un pequeño número de piezas bien diseñadas y perfectamente comprendidas. Cada parte realiza una función y la realiza bien. Para comprender el comportamiento del protocolo debería bastar con comprender el comportamiento de cada una de las piezas y la forma en que interactúan entre ellas. Los protocolos que se diseñan de esta forma son más fáciles de entender y de implementar de eficientemente. Probablemente sean más fáciles de verificar y mantener. 16 de 37

17 Ingeniería de Protocolos 6.2. Modularidad Un protocolo que realiza una función compleja puede construirse a partir de un pequeño número de piezas que interactúan de una forma bien definida y simple. Cada pieza es un protocolo ligero que puede desarrollarse, verificarse, implementarse y mantenerse de forma independiente. Las funciones ortogonales no se mezclan, sino que se diseñan como entidades independientes. Los módulos independientes no hacen suposiciones sobre el trabajo del resto, o incluso de su existencia. Por ejemplo, el control de errores y el control de flujo son funciones ortogonales. Se implementan mejor mediante módulos separados que no tengan consciencia de la existencia del otro. No realizan ninguna suposición del flujo de datos excepto de lo estrictamente necesario para realizar su función. El protocolo resultante es abierto, extensible y reorganizable sin afectar el funcionamiento del resto de las partes Protocolos bien formados Un protocolo bien formado no es: Sobre-especificado, es decir, no contiene código no ejecutable. Incompleto o infra-especificado. Por ejemplo, un protocolo incompleto puede causar recepciones imprevistas durante su ejecución. Este suceso ocurre cuando llega un mensaje que el receptor no espera o que no puede responder. Un protocolo bien formado sí es: Acotado: no sobrepasa los límites conocidos del sistema, como por ejemplo la capacidad de la cola de mensajes. Autoestabilizado: si un error transitorio ocurre, cambia el estado de un protocolo, entonces un protocolo será autoestabilizado siempre que sea capaz de volver a un estado adecuado en un número finito de transiciones y vuelve a su operación normal. De la misma forma si arranca en un estado aleatorio, será capaz de alcanzar una ejecución normal en un tiempo acotado. Autoadaptable: estos protocolos, por ejemplo, adaptan el ritmo al que envían información al ritmo que pueden soportar los enlaces existentes y el propio receptor. Un control de ritmo puede usarse para cambiar la velocidad de transmisión o el volumen de datos Robustez No es difícil construir protocolos que funcionen en condiciones normales, las situaciones inesperadas son las que suponen un desafío para ellos. Es decir, el protocolo debe estar preparado para manejar apropiadamente cada acción y cada secuencia de acciones en todas las posibles condiciones. Debe hacer el menor número posible de suposiciones sobre el entorno y evitar dependencias de determinadas características que pueden cambiar. Por ejemplo, muchos protocolos de enlace de datos que se diseñaron en los años 70 no 17 de 37

18 Ingeniería de protocolos funcionan adecuadamente si se usan en las líneas de altas velocidades de hoy (en el rango de los gigabits/segundo). Un diseño robusto evoluciona automáticamente con la tecnología sin requerir cambios importantes. Así, la mejor forma de obtener robustez no es sobre-diseñar para añadir funcionalidad para futuras y previsibles condiciones, sino un diseño mínimo que elimine suposiciones no esenciales que podrían tropezar con los cambios no previstos Consistencia Hay ciertas formas habituales en las que un protocolo puede fallar. Las más importantes son: Bloqueos: son estados en los que se detiene la evolución del protocolo, por ejemplo, a la espera de eventos que nunca se producen. Bucles infinitos: parecido al bloqueo, el protocolo evoluciona dentro de un conjunto de estados limitados, pero sin progresar en sus funciones. Terminaciones impropias: es la finalización de la ejecución de un protocolo sin satisfacer las condiciones de terminación adecuadas Las diez reglas de diseño Los principios discutidos en los puntos anteriores pueden recogerse en el siguiente decálogo: 1. Asegurarse que el protocolo está bien definido. Todos los criterios de diseño, requerimientos y restricciones deben ser enumerados antes de empezar a diseñar. 2. Definir el servicio a realizar en cada nivel de abstracción antes de decidir qué estructuras deberían utilizarse para realizar dichos servicios (el qué? va antes que el cómo?). 3. Diseñar antes la funcionalidad externa que la interna. Primero considerar la solución como una caja negra y decidir cómo va a interactuar con su entorno. Después decidir cómo se puede organizar internamente dicha caja negra. Probablemente consista en una colección de cajitas negras que se pueden refinar de la misma forma. 4. Mantener el diseño simple. Los protocolos elaborados son peores que los simple; son más difíciles de implementar y verificar y, normalmente, menos eficientes. Realmente hay muy pocos problemas realmente complejos en el diseño de protocolos. Problemas que parecen complejos suelen ser problemas simple considerados conjuntamente. Nuestro trabajo como diseñadores es identificar los problemas simples, separarlos y solucionarlos independientemente. 5. No conectar lo que es independiente. Separar los conceptos ortogonales. 6. No introducir lo que no es necesario. No restringir lo irrelevante. Un buen diseño es abierto y extensible. Un buen diseño se concentra en resolver una clase de problemas, más que una instancia concreta. 7. Antes de implementar un diseño, validarlo para comprobar que cumple los criterios de diseño. 8. Implementar el diseño, medir su rendimiento y si es necesario, optimizarlo. 18 de 37

19 Ingeniería de Protocolos 9. Comprobar que la versión optimizada final cumple los criterios de diseño. 10. Nunca saltarse las siete primeras reglas. Normalmente, la regla más violada es la Mecanismos básicos de los protocolos 7.1. Control de secuencia y control de errores El número de errores causados por las comunicaciones es típicamente varios órdenes de magnitud superior a los causados por fallos del hardware en un sistema informático. La probabilidad de que falle un bit por problemas de los circuitos internos suele estar por debajo de En una fibra óptica, un medio considerado como de los más seguros, libre de interferencias electromagnéticas, la probabilidad de error ronda el Es decir, de media, uno de cada 10 9 bits transmitidos (o procesados) es distorsionado, seis órdenes de magnitud más que el hardware de nuestro PC. De la misma forma, la tasa de errores en un cable coaxial es de Para una línea telefónica, la tasa sube hasta valores entre 10-4 y La diferencia entre tasas de y 10-4 no debe ser subestimada. A una velocidad de transmisión de 9600 bits por segundo, una tasa de error de produciría un error en un bit cada 3303 años de funcionamiento continuo. Con una tasa de 10-4 se produciría un error de un bit cada segundo en promedio. Dependiendo de las características de la línea y la red, los datos pueden ser reordenados, alterados, borrados e incluso, en líneas ruidosas, insertados. Por supuesto, estos errores son en gran medida aleatorios, por lo que no pueden ser predichos. Las causas principales de los errores son: - Distorsión lineal de los datos originales causada por limitaciones del ancho de banda del canal. - Distorsiones no lineales, causadas por eco, ruido blanco, impulsos electromagnéticos, etc. El efecto de estas distorsiones puede minimizarse hasta cierto punto aislando convenientemente los cables y usando filtros en los elementos transmisores y receptores. Sin embargo, no es posible eliminarlos totalmente. El error residual debe resolverse por software. Como se verá más adelante, tampoco se pueden eliminar completamente todos los errores. Lo único que se podrá hacer es mejorar la tasa de error residual respecto de la línea original. No obstante, hay que señalar que un esquema de control de errores debe ser acorde a las características de la línea. Si un canal sólo produce errores de inserción, de nada serviría un protocolo que protege contra eliminaciones. De la misma forma, si un canal produce errores simples con una probabilidad relativamente baja, incluso el más simple de los mecanismos de paridad puede batir en rendimiento a otros métodos más 19 de 37

20 Ingeniería de protocolos sofisticados. Finalmente, si el error de un canal es inferior a la tasa de fallos de un dispositivo periférico, la inclusión de cualquier mecanismo de control de errores simplemente degrada el rendimiento del sistema y puede incluso disminuir la fiabilidad del protocolo Redundancia Dada una tasa de errores para un medio determinado, la probabilidad de que algún bit de la información se vea alterado crece con el número de bits de dicha información. Por ello, puede parecer interesante la idea de codificar los mensajes de tal forma que se disminuya la longitud total de éste. Sin embargo, la solución viene del camino opuesto. Aumentando la longitud de los mensajes, añadiendo información redundante, podemos hacer canales más seguros. Al comprobar la consistencia del mensaje, el receptor puede comprobar la fiabilidad de la información que contiene. Aparte de detectar los errores, el receptor debe poder corregirlos. Existen dos formas de gestionar los errores: Control de errores hacia adelante: si se añade suficiente información redundante, el receptor es capaz de reconstruir un mensaje dañado. A los correspondientes códigos de transmisión se les denominada códigos correctores de errores Control de errores por realimentación: se basa en detectar los mensajes alterados y permitir su retransmisión. Son los llamados códigos detectores de errores. En el control de errores por realimentación, una petición de retransmisión puede ser un reconocimiento negativo explícito o, si la probabilidad de error es lo suficientemente baja, la ausencia de un reconocimiento positivo. En dicho caso, el receptor simplemente ignora los datos erróneos y espera a que el emisor se canse de esperar el reconocimiento y envíe de nuevo los datos. Como se ha dicho con anterioridad, el propósito de estos mecanismos es reducir la tasa de error. No todos los errores pueden ser detectados, por lo que siempre queda una tasa de error residual. Si la probabilidad de que haya un error de transmisión en un mensaje es p y el método de control de errores caza una fracción f de todos los errores, el error residual equivale a p (1-f). Si la probabilidad p es muy pequeña, un sistema de corrección de errores no es recomendable, ya que ralentiza las comunicaciones. Si, en cambio, p se acerca a 1, un sistema de retransmisión sería una mala elección, ya que posiblemente todos los mensajes, incluso los retransmitidos, serían alterados. Por supuesto que hay excepciones a estas reglas. Si p es pequeño, pero el coste de la retransmisión es alto, un sistema de corrección puede ser preferible o imprescindible. En otros muchos casos, un sistema mixto puede ser lo ideal: el receptor corrige los errores más frecuentes, y solicita la retransmisión de los mensajes alterados por los errores menos frecuentes Tipos de códigos 20 de 37

21 Ingeniería de Protocolos Hay dos tipos de códigos: Códigos de bloque: todas las palabras del código tienen la misma longitud, y la codificación de cada mensaje se puede definir estáticamente. Códigos de convolución: son aquellos en los que las palabras del código dependen del mensaje actual y un número determinado de los anteriores. El codificador cambia su estado con cada mensaje procesado. La longitud de las palabras de código suele ser constante. A su vez se pueden clasificar en: - Códigos lineales: cada combinación lineal de palabras válidas del código produce otra palabra válida. - Códigos cíclicos: cada rotación cíclica de un código válido es también otro código válido. - Códigos sistemáticos: es aquél que se forma con el propio mensaje a proteger inalterado y un grupo de bits de comprobación. En todos los casos, y esto es muy importante, las palabras del código son de mayor longitud que la información original, debido a la redundancia. Si d es el número de bits de la información y e el número de bits añadido por el código, el cociente d/(d+e) se llama razón de código. Normalmente al mejorar la calidad de un código se disminuye dicha razón. Por ejemplo, reducir la tasa de errores por un factor de con un código corrector puede requerir una tasa de código de 0'5 o menos, es decir, duplica la longitud del mensaje Códigos de paridad El sistema más sencillo de detección de errores es el control de paridad. Este código es válido para canales con una tasa de errores muy baja y en la que, además, los fallos sean aislados. A cada mensaje se le añade un único bit que se obtiene de la suma en módulo 2 de todos los bits del mensaje. La sobrecarga es mínima. Si durante la transmisión se altera un sólo bit, incluido el propio bit de paridad, el receptor es capaz de detectarlo. Si p es la probabilidad de fallo de un bit, q = 1 - p es la probabilidad de que no falle. Un mensaje con paridad de n bits tiene una probabilidad q (n+1) de llegar sin daño. La probabilidad de que alguno de los bits sea alterado es (n+1) p q n. Por tanto, el error residual será 1 - q (n+1) -(n+1) p q n. Para n = 15 y p = 10-4, esto deja un error residual en el orden de 10-6 por mensaje o de 10-7 por bit Corrección de errores Un sistema de control hacia adelante utiliza sólo una pequeña porción de los combinaciones de bits para codificar los mensajes. Los códigos se escogen de forma que se necesite un número relativamente alto de errores para convertir una palabra válida en otra. El receptor puede reconstruir el mensaje dañado asociando a éste la palabra del código más cercana (la que difiera en menor número de bits; ver Figura 11). 21 de 37

22 Ingeniería de protocolos Figura 11. Sistema de corrección de errores En general, la razón de código de un sistema corrector es menor que la de uno detector. Por tanto, sólo se suelen considerar estos mecanismos cuando la comunicación de mensajes de control entre el receptor y el emisor es difícil, como en los casos siguientes: - Un retraso de transmisión alto - Ausencia de canal de retorno - Una tasa de errores alta Un buen ejemplo del primer caso es la comunicación entre el famoso Mars Path Finder (un vehículo de reconocimiento de Marte) y el centro de control de la Tierra. Dada la distancia entre Marte y la Tierra, los mensajes podían tardar varios minutos en llegar, por lo que las órdenes al vehículo no podían ser retransmitidas. El segundo problema se da cuando hay un emisor y varios receptores, como en un sistema distribución de televisión digital Un sistema sencillo Se puede convertir nuestro sencillo código de paridad en un sistema que permita la corrección de un único bit. Cada secuencia de 7 bits se extiende con un bit de paridad que logra que el número de bits a 1 sea par. A este bit se le llama código de redundancia longitudinal (LRC; Longitudinal Redundancy Check). Al final del mensaje se añade una secuencia extra de 8 bits, en la que el bit i-ésimo es un bit de paridad par para todos los bits i-ésimos anteriores. Es lo que se denomina código de redundancia vertical (VRC, Vertical Redundancy Check). Por ejemplo, para proteger un bloque de 4 caracteres ASCII: LRC D = A = T = A = VRC de 37

23 Ingeniería de Protocolos Cuando se produce un error en un bit, es posible averiguar cuál es el incorrecto gracias a que uno de los bits de LRC indicarán la línea y uno de los de VRC indicará la columna del error. Se han usado 12 bits de comprobación para proteger una secuencia de 28 bits, lo que nos da una razón de código de 28 / ( )= 0' El método Van Lint Otra forma de corregir errores se debe a J.H. Van Lint. Supongamos que se quiere estandarizar la generación de números aleatorios. El método elegido consiste en hacer que una persona imparcial realice A tiradas de una moneda por segundo. Esta persona, además se encarga de transmitir la información por un canal con una capacidad de 2A bps con una tasa de errores de El resultado de cada tirada se puede codificar con un sólo bit, 1 para las caras y 0 para las cruces, por ejemplo. Se podría transmitir esta información directamente, pero el receptor tendría de media un error del 2% respecto del estándar. La primera idea que se propone es transmitir cada tirada dos veces. El receptor sería capaz de detectar los errores, pero no de corregirlos. La siguiente estrategia será codificar cada par de tiradas en cuatro bits, como en la tabla siguiente (C para cara y X para cruz): Resultado Código XX 0000 CX 1001 XC 0111 CC 1110 Los receptores usan una tabla diferente para descodificar: Códigos válidos Resultado XX CX XC CC El código resiste errores en un sólo bit en las tres primeros bits de cada palabra. La primera columna de la tabla de descodificación corresponde con la palabra original y las tres siguientes columnas son las palabras que se obtienen al modificar el primero, segundo y tercer bit respectivamente. Errores múltiples, o un error simple en el cuarto bit lleva a la recepción de un número aleatorio no estándar. Es decir, un código se recibe correctamente 23 de 37

24 Ingeniería de protocolos si con probabilidad q 4 no tiene errores, o con probabilidad 3 p q 3 tienen exactamente un error en alguno de los tres primeros bits: q p q 3 = 0'9788. Comenzamos con una tasa de error del 2% por bit, o del 4% en una serie de dos bits. La tasa se ha bajado hasta 1-0'9788 = 0'0212 o 2'12% para dos bits consecutivos. Como hemos usado cuatro bits para codificar dos tiradas la razón de código es de 0'5. Se desperdician 12 de las dieciséis combinaciones de un código de cuatro bits para disminuir la tasa de errores, pero todavía se pueden transmitir los códigos tan rápidos como se producen. Siguiendo este esquema, se pueden mejorar estas cifras sin aumentar la velocidad del canal ni reducir la razón de código. Por ejemplo, codificando cuatro tiradas en 8 bits, se eligen 16 codificaciones válidas de las 256 posibles Distancia de Hamming En el ejemplo anterior se puede ver que, distribuyendo adecuadamente los 16 códigos válidos entre los 256 posibles, se aumentan las posibilidades de detectar y corregir errores. Ello se debe a que la distancia entre dos códigos es mayor. Formalmente, se define distancia de Hamming como la diferencia en bits mínima entre dos palabras de un código. Si se consigue encontrar un código con una distancia de Hamming de n, entonces se pueden detectar errores de hasta n-1 bits. Incluso es posible corregir errores de hasta (n-1)/2 bits si el receptor decide interpretar cada código no válido como el válido más cercano. Si hay un mayor número de bits erróneos, el receptor fallará en la corrección (aceptará como buenos códigos inválidos), pero si la probabilidad de que esto ocurra es baja, el error residual del canal será menor. Este método se llama descodificación por el vecino más cercano. Aumentando la distancia de Hamming mediante el aumento del tamaño de los códigos, deberíamos ser capaces de mejorar la fiabilidad del código todo lo que se quisiera. Se puede decir entonces que es posible esto para cualquier canal y cualquier velocidad de transferencia? Según el teorema de Shannon, en un canal con ancho de banda limitado y con ruido blanco, sólo para velocidades de transmisión hasta determinado límite, la tasa de errores pueden hacerse arbitrariamente pequeña. Dicho límite se llama capacidad del canal y equivale a S C=B*log 2 (1+ ) bps N donde B es el ancho de banda en Hz y S/N es la relación señal ruido. Sin embargo, transmitir a velocidades cercanas a este límite es peligroso, porque no se tienen en cuenta otras fuentes de error que ya han sido citadas. 24 de 37

25 ()mc += 12 mc += 12 Ingeniería de Protocolos Un código de bloque lineal. Código de Hamming Para codificar n mensajes, se requiere un mínimo de m= log 2 n bits, redondeado al entero superior. Se pueden proteger esos m bits añadiendo c bits de comprobación, y eligiendo n códigos de los 2 (m+c) posibles de tal forma que la distancia de Hamming sea lo mayor posible. Para poder corregir todos los errores simples, se necesita una distancia de Hamming de al menos 3. Pero, cuántos bits de comprobación requiere? Para cada palabra de m+c bits, podemos obtener un total de m+c palabras que difieren de aquélla en un sólo bit. Por tanto, para cada una de los 2 m posibles mensajes se necesitan m+c+1 palabras. Es decir, el número de palabras del código debería ser (m+c+1)2 m. Como habíamos dicho con antelación, el número de palabras del código era 2 (m+c). (m+c+1)x2 m = 2 (m+c) m+c+1=2 c Para m = 8, c = 3'66 ó 4 bits de comprobación, lo que nos da una razón de código de 8/(8+4)=0'66. El código de este tipo más famoso se debe a Hamming. Los c bits de comprobación se localizan en posiciones que sean potencias de 2. Es decir, el bit i-ésimo se coloca en la posición 2 i, donde 0 i log 2 (m+c). El bit 2 i se calcula como la paridad (par o impar) de todos los bits del mensaje que contengan dicho término. Por ejemplo, el bit 7 afecta a la paridad de los bits comprobadores 1, 2 y 4 (porque 7 = 1+2+4). Si el canal altera el bit 7, afectará a la paridad de los bits comprobadores 1, 2 y 4. La suma de estos bits nos da la posición del bit erróneo. Por ejemplo, para proteger la letra D (que en ASCII es el código 68= ) tendríamos: Dato Enviado Recibido Comprobación Ráfagas Se ha comprobado que la mayor parte de las veces los errores no se producen de forma aislada. En general vienen en ráfagas y suelen ser causados por eco, picos de ruido y otras fuentes de distorsión no lineales. Así, pocos mensajes son alterados, pero los que son afectados lo son seriamente. Por ejemplo, la tasa de error de un bit aislado en una línea telefónica es de Sin embargo, la probabilidad de que un bit falle dado que lo hizo el precedente, puede ser tan alta como el 0'5. Por tanto, un método de corrección que permita corregir errores aislados puede ser de poca utilidad. Además, extender la idea del código de Hamming para un mayor número de bits no es sencillo. 25 de 37

26 Ingeniería de protocolos Otros mecanismos permiten la corrección de un mayor número de bits. Por ejemplo, el código interlineado consiste en que, suponiendo mensajes de n bits, se almacenan k de estos mensajes en una matriz de kxn bits, y se transmiten columna por columna en vez de fila por fila. En el receptor, se restaura la matriz original columna por columna y se lee por filas. De esta forma, una ráfaga de error de longitud k o menor sólo puede causar un error por cada fila como máximo, y puede ser corregido adecuadamente. Este mecanismo tiene el problema de que necesita un tráfico no interactivo. La solución puede ser el código Reed-Solomon, que se usa en la codificación digital de sonido en los discos compactos. En 1964, personal de IBM llevó a cabo un estudio que demostró que en la mayor parte de los casos, el control de errores por realimentación es superior al control hacia adelante en cuanto a aprovechamiento del canal y tasa de error residual Códigos de Redundancia Cíclica Este código, más conocido como CRC es un código sistemático. Se basa en añadir series de bits de comprobación para codificar palabras. En este caso, los bits añadidos garantizan que, en ausencia de errores de transmisión, la palabra de código más los bits de comprobación sean divisibles por un factor dado. El método de división y el factor utilizado determinan el rango de errores de transmisión que puede ser detectado. Se define el mensaje que se va a transmitir como un polinomio. Una secuencia de N bits puede ser interpretada como un polinomio de grado máximo N-1: N-1 Σb i x i i=0 donde cada b i toma el valor del bit en la posición i de la secuencia, con los bits numerados de derecha a izquierda. Por ejemplo, la palabra se define con el polinomio: x 4 +x+1 Los mensajes llegan correctos al receptor si son divisibles por un determinado polinomio llamado polinomio generador. Suponiendo que P es el polinomio que representa al mensaje que se quiere transmitir y G el polinomio generador de grado r, el resto R tiene grado menor o igual que r-1 y es definido como el resto de la siguiente operación: P x r G Este resto se añade al final del mensaje, de forma que el código transmitido (T= P x r - R) es divisible por G. El receptor puede detectar la corrección del mensaje comprobando el resto de su división por G. Si es cero, el mensaje era correcto. Un error de transmisión se puede modelar como un polinomio E que se suma al mensaje T. Sólo en el caso de que E sea divisible por G, el error quedará no detectado: T + E T E E = + = G G G G 26 de 37

27 Ingeniería de Protocolos Si el error es de una longitud inferior o igual a r (es decir, una ráfaga de r o menos bits), no será divisible por G, por lo que cualquier ráfaga de hasta r bits siempre se detecta. Esto es independiente de la posición de la ráfaga dentro del mensaje, ya que E no puede convertirse en múltiplo de G simplemente multiplicándolo por x i. Además, añadiendo determinados factores a G, es posible obtener polinomios generadores que protegen las transmisiones contra otros errores, como ráfagas de longitud mayor de r, cualquier número impar de errores, etc. Algunos polinomios importantes son: CRC-12, x 12 +x 11 +x 3 +x 2 +1; CRC-16, x 16 +x 15 +x 2 +1; CRC-CCITT, x 16 +x 12 +x Este último es capaz de detectar cualquier número impar de errores simples, todos los errores dobles, todas las ráfagas de una longitud igual o inferior a 16, el 99'997% de las ráfagas de 17 bits y el 99'998% de las ráfagas de más de 17 bits Checksum aritmético Cada método de detección de errores tiene una sobrecarga en bits que se expresa en la razón de código. Sin embargo, hay otra sobrecarga en tiempo de procesamiento asociada a la generación/comprobación de los bits de comprobación, que afecta a la velocidad de transmisión máxima. Este tiempo se puede reducir usando tablas o mediante el uso de hardware especial. En aquellas situaciones en las que el error residual no justifique la implementación de un CRC, puede ser atractivo el uso de una alternativa simple que, a pesar de ello, tenga una buena protección ante errores. El método de Fletcher (1982) requiere sólo sumas y operaciones de módulo y tiene una detección de errores excelente, aunque inferior al CRC. Por ejemplo, detecta todas las ráfagas de 1 a 14 bits, excepto las de 8. Este algoritmo se ha estandarizado como parte del protocolo estándar de transporte clase 4 de ISO. unsigned short cksum (register unsigned char *s, register int n) { register int c0=0, c1=0; do { c0 = (c0 + *s++) % 255; c1 = (c0 + c1) % 255; }while (--n>0); return (unsigned short) (c1<<8+c0); } 7.2. Control de flujo El control de flujo más simple lo único que hace es ajustar la velocidad a la que el emisor produce la información, a la velocidad que el receptor puede procesarla. Sin embargo, también hay múltiples mecanismos más elaborados para proteger la transmisión contra el borrado, la inserción, la duplicación y el desorden de los mensajes. En el caso más sencillo, el control de flujo se emplea para: asegurar que no se transmiten los datos a más velocidad de la que el receptor es capaz de procesar 27 de 37

28 Ingeniería de protocolos optimizar el uso del canal evitar la saturación del canal Protocolo simple sin control de flujo La Figura 12 ilustra un protocolo que no tiene ningún tipo de control de flujo. Se trata de un protocolo simplex. El protocolo funciona perfectamente siempre que el proceso receptor sea más rápido que el emisor. Si no se cumple esta suposición, el emisor puede desbordar la cola de entrada del receptor. Este protocolo viola una ley básica del diseño de programas concurrentes: no hacer suposiciones de la velocidad relativa de procesos concurrentes. Esta velocidad depende de demasiados factores. Además, normalmente la tarea de recibir suele ser más costosa que la de emitir: el receptor tiene que interpretar los datos, decidir qué hacer con ellos, encontrar memoria para almacenarlos y quizás reenviarlo a otro sitio. Por su parte, el emisor no tiene que decidir nada; si tiene datos los envía. En lugar de buscar memoria, la libera, proceso menos costoso normalmente. Figura 12. Máquina de estados finita de un protocolo simple sin control de flujo Figura 13. Diagrama de flujo del protocolo simple 28 de 37

29 Ingeniería de Protocolos Protocolo Xon-Xoff Existe un método sencillo ampliamente utilizado y que aún funciona hoy en día: el protocolo Xon-Xoff. Se trata de un mecanismo de sincronismo entre los procesos que no necesita una negociación previa. Sólo son necesarios dos mensajes especiales llamados Xon y Xoff. Ahora el protocolo para el emisor necesita ser duplex. Son necesarios, pues, dos estados para el emisor y otros dos para el receptor. Cuando el transmisor recibe un Xoff, pasa a un estado de espera. Sólo cuando recibe un mensaje Xon, pasa de nuevo al estado de transmisión. Figura 14. Transmisor y receptor en protocolo Xon-Xoff El receptor también posee dos estados. La variable n almacena el número de mensajes que hay en el buffer receptor y se va incrementando conforme van llegando los mensajes. Cuando llega un mensaje y el buffer no está lleno, se acepta directamente el mensaje y se decrementa la variable compartida n (Rx y procesando mensajes). Los mensajes se pasan almacenan en una cola interna. La variable n mantiene en todo momento el número de mensajes almacenados que no han sido aceptados aún. En caso de que este número supere determinado valor máx, se envían un mensaje Xoff al emisor y se siguen procesando mensajes (pero sin recibir nuevos mensajes en el buffer). Si, en cambio, cae por debajo del límite mín, se envía un mensaje Xon, para que el emisor envíe más mensajes. Evidentemente, sólo tiene sentido poner dos estados en el receptor si la operación de procesar o aceptar es una operación que lleva cierto tiempo. 29 de 37

30 Ingeniería de protocolos Figura 15. Diagrama de flujo para protocolo Xon-Xoff Sin embargo, sigue habiendo problemas. Si un mensaje Xoff se pierde o retrasa, el problema de saturación persiste. La evolución de un protocolo no debería depender de lo que tarda un mensaje en llegar al receptor. Peor aún: si se pierde un mensaje Xon, los cuatro procesos se quedan bloqueados para siempre. Los problemas que no se resuelven son: - Proteger contra la saturación de una forma más efectiva. - Proteger contra la pérdida de mensajes Protocolo de parada y espera Un método habitual para resolver el primer problema consiste en que el emisor espere explícitamente el reconocimiento de los mensajes enviados. Un ejemplo es el protocolo Parada y Espera cuyas máquinas de estados se muestran en la Figura 16. El problema de la sobrecarga desaparece, pero los procesos se siguen bloqueando si se pierde un mensaje de control o de datos. Además, el canal se desaprovecha mucho. Sea t el tiempo de propagación del canal, a el tiempo que tarda el receptor en aceptar un mensaje y p el que tarda el emisor en prepararlo. Con el protocolo de parada y espera, el emisor incurre en un retraso de 2t+a-p por cada mensaje enviado. Normalmente p<a, y t crece con la distancia entre el emisor y el receptor. Por otra parte, es interesante considerar que el mensaje de reconocimiento no es sólo una indicación de que el último mensaje llegó, sino también un crédito que el receptor extiende al emisor para transmitir el siguiente mensaje. Esta idea nos lleva a una solución a este último problema de la utilización del canal: los protocolos de ventana. 30 de 37

31 Ingeniería de Protocolos Figura 16. Transmisor y receptor para protocolo de parada y espera. Figura 17. Diagrama de flujo del protocolo de parada y espera Protocolo de parada y espera con timeout Para proteger el sistema contra la pérdida de tramas, un mecanismo muy popular es llevar la cuenta del tiempo desde que se transmitió un mensaje. Si pasado un determinado tiempo, no ha llegado un reconocimiento del receptor, se asume que el mensaje se ha perdido y se retransmite. Dicho tiempo, denominado tiempo de timeout, debe establecerse de forma que tenga en cuenta los tiempos que tarda un mensaje en ir desde el emisor al receptor y otro de reconocimiento desde el receptor al emisor. 31 de 37

32 Ingeniería de protocolos Figura 18. Transmisor y receptor para protocolo de parada y espera con timeout y errores de canal. Figura 19. Diagrama de flujo de protocolo de parada y espera con timeout Como puede observarse, se ha protegido el protocolo de la pérdida de mensajes tanto en el emisor como en el receptor (pérdida de ack). Esto nos puede llevar a un problema: si se pierde una trama, simultáneamente el emisor y el receptor deciden reenviar lo último: el emisor su trama y el receptor el ack. Cuando llega el primer ack, el emisor no puede saber si corresponde al primer mensaje o a su retransmisión. El resultado es que el emisor asocia equivocadamente cada mensaje con otro ack. 32 de 37

33 Ingeniería de Protocolos Figura 20. Error en el protocolo por la pérdida de una trama. Esta situación es un ejemplo de la clase de problemas que pueden presentarse si se permite que tanto emisor como receptor sean capaces de iniciar retransmisiones. Basta con encargar dicha tarea a uno de los procesos, normalmente al emisor, puesto que sólo él sabe con exactitud cuándo se envió cada trama. Además, deberíamos ser capaces de distinguir qué mensaje se está reconociendo con un determinado ack, incluso en protocolos con una sola trama en curso, como el de parada y espera simple. La solución pasa por numerar tanto los mensajes como los reconocimientos. De esta forma, además seremos capaces de solventar otros problemas como la duplicación o la reordenación de mensajes Protocolo de bit alternante Un ejemplo de uso correcto del timeout y de un número de secuencia de 1 bit es el protocolo de bit alternante mostrado en la Figura de 37

34 Ingeniería de protocolos Figura 21. Transmisor y receptor para protocolo de bit alternante El protocolo se define como dos máquinas de estado, y especifica el comportamiento de dos procesos A y B. Las etiquetas que acompañan a las flechas indican que hay intercambio de mensajes. Cada una de esas etiquetas está formada por dos caracteres: el primero (A, B) indica el origen del mensaje y el segundo el número de secuencia (0,1). Si una etiqueta está subrayada indica una operación de transmisión, mientras que si está sin subrayar indica una operación de recepción. Las flechas bidireccionales señalan estados en los que el receptor acepta un mensaje de entrada o el emisor busca un nuevo mensaje para transmitir. Este protocolo puede fallar cuando se produce un retraso en el envío del ack de uno de los mensajes. Observa la secuencia temporal de la Figura 22. Figura 22. Error en el protocolo de bit alternante por un retraso en el receptor 34 de 37

35 Ingeniería de Protocolos Protocolos de ventana Con este tipo de protocolos, en la fase de establecimiento de conexión, el receptor puede indicar al emisor cuánto espacio tienen en su buffer para los mensajes que lleguen. Así, el extremo que transmite puede enviar un determinado número de mensajes sin tener que recibir acuse de recibo por cada uno de ellos. Este número se denomina ventana y puede ser actualizado dinámicamente en función de la evolución del espacio libre en el buffer del extremo receptor. Veamos los fundamentos de los protocolos de ventana suponiendo que no se pierden mensajes. Cada mensaje que se recibe se reconoce con un mensaje ack en el canal de retorno. Supongamos que la ventana inicial (negociado o establecido de manera fija) es de W. Cada vez que el emisor envía un mensaje, decrementa el número de mensajes que puede recibir sin ack, y cada vez que se recibe un mensaje, el receptor incrementa ese número. El diagrama de flujo y la secuencia temporal correspondientes se ilustran en la Figura 23. Durante la transferencia el crédito actual varía entre 0 y W, dependiendo de la velocidad relativa del emisor y receptor. El emisor sólo se interrumpe cuando tiene W mensajes enviados y no ha recibido acuses de recibo para ninguno de ellos. Como se habrá intuido, este mecanismo de control de flujo optimiza el canal de comunicación en los que el tiempo de tránsito es muy alto. Sin embargo, se ha supuesto un canal ideal. En un entorno de ejecución más realista, en el que se pueden perder, insertar o reordenar mensajes, el protocolo falla. Véase un ejemplo en la Figura 24 Figura 23. (izq) Diagrama de flujo; (der) Secuencia temporal de ejemplo con un protocolo de una ventana de 4 35 de 37

36 Ingeniería de protocolos Figura 24. Fallo en el protocolo de ventanas por pérdida de mensajes En la Figura 25 se muestra una notación alternativa a la utilizada hasta ahora para las entradas y salidas en una máquina de estados finita. Esta notación puede ser útil cuando han de considerarse muchas entradas y salidas o cuando se quieren describir con más detalle. Figura 25. Máquina de estados para el transmisor en un protocolo de ventanas 36 de 37

37 Ingeniería de Protocolos Hay ciertas cuestiones que se deben tener en cuenta sobre el protocolo de ventana deslizante: - El transmisor está autorizado a enviar un número limitado de mensajes (W, con W>1) antes de recibir algún acuse de recibo - El receptor puede enviar acuses de recibo en cuanto recibe un mensaje - Hay que distinguir entre: Ventana de transmisión: incluye los mensajes enviados y pendientes de reconocer en el receptor (de tamaño variable, pero limitado a W) Ventana de recepción: incluye los números de secuencia que el receptor espera recibir (de tamaño fijo) - Se produce la situación de envío contínuo cuando se cumple que W >= 1+2a, pues en este caso el transmisor puede enviar un mensaje tras otro sin esperas, consiguiendo la máxima utilización. Donde a es: a = tiempo_de_propagación/tiempo_de_trama - Para el rango de los números de secuencia debe cumplirse que el rango de los números de secuencia sea menor o igual que la suma del tamaño de la ventana de recepción y el tamaño máximo de la ventana de transmisión, en caso contrario podrían darse duplicaciones tal como aparece en el ejemplo de la figura Figura 26. Nº sec Transmisor A Nº ack 3 A 0 3 A 1 3 A 2 3 timeout Receptor B A 3 B 0 B 1 B 2 B 3 Nº sec Nº ack Se retransmite Nº sec Nº ack A 0 A 1 A 2 A 3 B 0 B 1 B 2 B 3 Nº sec Nº ack B los acepta y piensa que son los datos de la ventana siguiente, y sin embargo, están duplicados Figura 26. Error en el protocolo de ventana si los números de secuencia no son <= k+n 8. Bibliografía Design and validation of computer protocols, Gerard J. Holzmann. Ed. Prentice-Hall, Communication Protocol Specification and Verification, Richard Lai, Ajin Jirachiefpattana. Ed. Kluwer Academic Publishers, Principles of Protocol Engineering and Conformance Testing, Behçet Sarikaya. Ed. Ellis Horwod, de 37