ejemplos de protocolos

EJEMPLOS DE PROTOCOLOS A NIVEL DE ENLACE
Después de haber visto la teoría echaremos un vistazo a algunos de los protocolos de enlace más comúnmente utilizados en la práctica.
HDLC (High-level Data Link Control)
El nivel de enlace en la Internet
SLIP
PPP
El nivel de enlace en Frame Relay
El nivel de enlace en ATM
HDLC - High-level Data Link Control
Usando como base muchos de los conceptos y técnicas que hemos estudiado, en 1972 IBM desarrolló un protocolo de enlace denominado SDLC (Synchronous Data Link Protocol) para utilizarlo en las redes SNA. A pesar de su antigüedad SDLC es la base de la mayoría de los protocolos de enlace que se utilizan en la actualidad.
Posteriormente IBM propuso la estandarización de SDLC a ANSI e ISO; cada uno de estos organismos introdujo sus propias variantes sobre la propuesta inicial, dando así un conjunto de protocolos similares pero no idénticos. El creado por ANSI se denomina ADCCP (Advanced Data Communication Control Procedure), el de ISO se llama HDLC (High level Data Link Control); CCITT creó LAP (Link Access Procedure) y más tarde LAPB (Link Access Procedure Balanced, también llamado Link Access Procedure version B) que es un subconjunto de HDLC que se utiliza por ejemplo en X.25. Para la señalización (es decir, el establecimiento de la llamada) en RDSI la CCITT creó otro subconjunto de HDLC denominado LAPD (Link Access Procedure D-channel). Frame relay a su vez utiliza una variante de LAPD. Podemos considerar a todos estos protocolos como una familia cuyo miembro mas representativo es el HDLC.
Por su importancia vamos a comentar sus aspectos mas relevantes desde un punto de vista general, sin entrar en los detalles que los diferencian.
La estructura de la trama HDLC es como sigue:
Campo
Tamaño (bits)
Valor
Delimitador
8
01111110
Dirección
8
Variable
Control
8
Variable
Datos
>= 0
Variable
Checksum
16
Variable
Delimitador
8
01111110
La trama se delimita mediante la secuencia 01111110, y para asegurar la transparencia de datos se utiliza relleno de bits (bit stuffing), es decir, se intercala un bit a 0 cuando en la parte de datos aparece una secuencia de cinco bits a 1, procediendo de modo inverso en el lado receptor; esto asegura la no ambigüedad en la identificación del principio y final de la trama. Cuando la línea no está transmitiendo tramas útiles los equipos envían continuamente la secuencia 0111111011111101111110….
Cada trama puede tener cualquier longitud a partir de 32 bits (sin contar los delimitadores), pudiendo no ser múltiplo de 8, ya que no se presupone una estructura de bytes. Por esto se suele decir que HDLC es un protocolo orientado al bit (en contraste con los requieren que la trama sea múltiplo de 8, que se denominan orientados al byte).
El campo checksum utiliza el generador polinómico CRC-CCITT.
El campo datos, también llamado en ocasiones carga útil (payload) puede o no estar presente; puede contener cualquier información y tener cualquier longitud, si bien la eficiencia del checksum disminuye cuando la longitud aumenta.
El campo dirección solo se utiliza en líneas multipunto. Las líneas multipunto son conexiones en las que varios ordenadores comparten una misma línea física, lo cual es poco frecuente y requiere líneas especiales; en las líneas multipunto hay un ordenador que actúa de 'moderador' dando el turno de palabra a los demás (en cierto modo podemos considerarlas como precursoras de las redes broadcast). El campo dirección permite identificar a cual de todos los ordenadores accesibles en la línea va dirigida la trama.
El campo control es realmente el corazón del protocolo. Su primer bit especifica el tipo de trama que lo contiene, que puede ser de información o de supervisión. Las tramas de información son las únicas que contienen datos. En el campo control envían un número de secuencia de tres bits que se utiliza para un protocolo de ventana deslizante de tamaño máximo 7; el mecanismo utilizado puede ser de retroceso n o de retransmisión selectiva. En cada trama de información se incluye un acuse de recibo (ACK) piggybacked que ocupa tres bits en el campo control (recordemos que el ACK tiene que ser del mismo tamaño que el número de secuencia).
Las tramas de supervisión pueden ser de varios tipos:
Tipo 0: RECEIVE READY. Es el nombre que recibe en el estándar el acuse de recibo (ACK). Se utiliza cuando no hay tráfico de retorno suficiente para utilizar piggybacking.
Tipo 1: REJECT. Corresponde al acuse de recibo negativo (NAK). Solicita retransmisión de una trama, y no acepta ninguna otra entretanto. Se utiliza cuando se emplea el mecanismo de retroceso n.
Tipo 2: RECEIVE NOT READY. Indica un acuse de recibo pero solicita suspensión del envío para evitar saturar al receptor (control de flujo), cosa que puede ser necesaria si el receptor tiene poco espacio para buffers. Para que la retransmisión se reanude debe enviar un RECEIVE READY, REJECT o ciertas tramas de control.
Tipo 3: SELECTIVE REJECT. Se utiliza para solicitar retransmisión de una trama determinada cuando se emplea retransmisión selectiva. En este caso por tanto la ventana del emisor con un númerod e secuencia de tres bits no puede ser mayor de 4. Este mecanismo solo está previsto en HDLC y ADCCP, no en SDLC ni LAPB.
En HDLC y LAPB existe un tipo de trama extendida en la que los números de secuencia son de 7 bits; en este caso es posible utilizar un tamaño de ventana de hasta 127 usando la técnica de retroceso n o de 64 usando la de repetición selectiva.
El nivel de enlace en la Internet
El modelo TCP/IP dice muy poco acerca del nivel de enlace; desde hace bastante tiempo está especificado como transportar paquetes IP sobre redes locales, redes X.25, etc., pero sorprendentemente el transporte de paquetes IP sobre líneas serie (dedicadas o RTC) se ha efectuado durante mucho tiempo con protocolos particulares, y no ha sido estandarizado hasta época reciente.
SLIP - Serial Line IP
Este es el más antiguo de los dos protocolos y data de 1984. Se trata de un protocolo muy sencillo que utiliza un carácter como indicador, y caracteres de relleno en caso de que dicho carácter aparezca en la trama. Debido a su sencillez sólo se utiliza en conexiones conmutadas.
Algunas versiones recientes de SLIP llevan a cabo la compresión de la información de cabecera TCP e IP; esto se hace porque a menudo paquetes consecutivos tienen muchos campos de cabecera comunes.
SLIP no genera un CRC, y por tanto no es posible detectar tramas erróneas; cualquier error ha de ser corregido por los niveles superiores. Evidentemente esto simplifica enormemente las implementaciones pero reduce de forma apreciable el rendimiento.
Además del problema de la detección de errores SLIP tiene una serie de inconvenientes importantes que lo hacen inapropiado para cualquier utilización mínimamente seria; su uso está decayendo rápidamente en favor del PPP, mucho más avanzado.
A pesar de haberse publicado como un RFC (1055), SLIP no es un Internet Standard. Recordemos que para llegar a ser un Internet Standard el protocolo propuesto debe ser considerado interesante por el IAB (Internet Architecture Board).
PPP (Point-to-Point Protocol)
Para mejorar la situación el IETF puso en marcha un grupo de trabajo que elaborara un protocolo de enlace que pudiera llegar a ser un estándar Internet. El resultado fue un protocolo elaborado en 1990 denominado PPP, definido en los RFC 1661, 1662 y 1663.
PPP ha sido diseñado para ser muy flexible; para ello incluye un protocolo especial, denominado LCP (Link Control Protocol), que se ocupa de negociar una serie de parámetros en el momento de establecer la conexión con el sistema remoto.
La estructura de trama de PPP se basa en la de HDLC, salvo por el hecho de que se trata de un protocolo orientado a carácter, por lo que la longitud de la trama ha de ser un número entero de bytes.
Campo
Tamaño (bytes)
Valor
Delimitador
1
01111110
Dirección
1
11111111
Control
1
00000011
Protocolo
1 ó 2
Protocolo
Datos
>= 0
Variable
Checksum
2 ó 4
Variable
Delimitador
1
01111110
Dado que el protocolo es orientado a carácter, la ocurrencia del delimitador 01111110 dentro de la trama se resuelve con relleno de carácter, duplicando el carácter correspondiente.
El campo dirección no se utiliza. Siempre vale 11111111.
El campo control tiene por defecto el valor 00000011, que indica una trama no numerada. Esto significa que por defecto PPP no suministra transmisión fiable (con números de secuencia y acuse de recibo, como hemos visto para HDLC). Aunque no es lo normal, en el momento de establecer la conexión LCP puede negociar una transmisión fiable.
Salvo que se negocie una transmisión fiable los campos dirección y control contienen siempre la secuencia 1111111100000011. Dado que es inútil transferir esta información de control que siempre contiene la misma información, generalmente LCP negocia la supresión de estos dos bytes de la trama la inicio de la sesión cuando no se pide transmisión fiable.
El campo protocolo establece a que tipo de protocolo pertenece el paquete recibido de la capa de red. De esta forma PPP permite establecer una comunicación multiprotocolo, es decir puede utilizarse para transmitir paquetes pertenencientes a diferentes protocolos del nivel de red entre dos ordenadores simultáneamente. Entre las posibilidades se encuentra IP, IPX(Novell), Appletalk, DECNET, OSI y otros.
El campo datos es de una longitud variable hasta un máximo que negocia LCP al establecer la conexión; por defecto el tamaño máximo de trama es de 1500 bytes.
El campo checksum es normalmente de 2 bytes, pero puede ser de 4 si se negocia.
Igual que ocurre en la vida real, la negociación entre dos LCPs puede dar lugar a que todos los valores propuestos sean aceptados por la otra parte, o sólo algunos de ellos. El protocolo establece mecanismos que permiten a los LCPs dialogar para llegar a un consenso en caso de discrepancia.
LCP suministra mecanismos que permiten validar al ordenador que llama (mediante el uso de claves tipo usuario/password). Esto resulta especialmente útil en el caso de conexiones por RTC, por ejemplo para proveedores de servicios Internet que han de facturar a sus usuarios en función del tiempo de conexión.
Existe otro componente de PPP que es el NCP (Network Control Protocol). Este se encarga de negociar los parámetros específicos para cada protocolo utilizado. Por ejemplo, en el caso de una conexión IP desde un usuario conectado vía módem le asigna dinámicamente una dirección IP, lo cual es especialmente útil en casos en que el número de direcciones IP disponibles sea menor que el número de usuarios del servicio (aunque por supuesto el número de direcciones IP disponibles debe ser suficiente para poder asignar una diferente a cada usuario simultáneo).
PPP es un mecanismo de transporte de tramas multiprotocolo que puede utilizarse sobre medios físicos muy diversos, por ejemplo conexiones mediante módem y RTC, RDSI, líneas dedicadas, o incluso por conexiones SONET/SDH de alta velocidad (aunque esto último no es normal).



http://capus.uab.es.com

GLOSARIO