Sie sind auf Seite 1von 42

Ingeniería de protocolos

Tema 2. Estructura de un protocolo

Texto original: Mª del Carmen Romero (mcromero@dte.us.es)


Parcialmente modificado: Jaime Benjumea (benjumea@dte.us.es)

1
Estructura de un protocolo

1. Introducción
2. Los cinco elementos de un protocolo
3. Servicio y entorno
4. Vocabulario y formato de los mensajes
5. Reglas de procedimiento
6. Diseño de un protocolo estructurado
7. Mecanismos básicos de los protocolos
2
Introducción

A B

Acuerdos sobre:
- Inicio y final del intercambio 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
3
Introducción
Niveles de abstracción

señal eléctrica

bits

símbolos/caracteres

campos de mensaje

tramas/paquetes 4
Los cinco elementos de un protocolo

1. Servicio que proporciona el protocolo


2. Suposiciones sobre el entorno donde se ejecuta el protocolo
3. Vocabulario de los mensajes utilizados en el protocolo
4. Formato de los mensajes del vocabulario del protocolo
5. Reglas de procedimiento que controlan la consistencia del
intercambio de mensajes

5
Servicio y entorno
P1: Testeador + generador de paridad (8 bits)
P2: Codificador + decodificador (7 bits)

Canal virtual Envolturas de datos

P2 P1 P1 P2 Pn P2 P1 Po P1 P2 Pn

• Virtual: es algo que parece que existe pero, en realidad, no


existe.
• Transparente: es algo que, en realidad, existe pero que
parece que no existe.
6
Servicio y entorno
Ventajas del diseño por niveles:
- Ayuda a distinguir la estructura lógica del protocolo, al separar
tareas de alto nivel de las de bajo nivel
- Facilita la escalabilidad del protocolo

Actores del modelo de diseño:


- Un nivel o capa define un grado de abstracción de un protocolo,
agrupando funciones relacionadas y separando las independientes
- Un interfaz separa (y une) dos niveles distintos de abstracción

Nivel N+1

Nivel N A B
Protocolo par Entidad par

Nivel N-1
Primitivas Servicio
7
de servicio
Servicio y entorno
Primitivas: Suministrador
Usuario de servicio del servicio Usuario de servicio
- De petición de servicio (Capa N) (Capa N-1) (Capa N)

- De indicación de servicio X.request

- De respuesta (de entidad par) X.indication


- De confirmación (del suministrador
X.confirm X.response
del servicio)

Transmisor Receptor

Usuario Usuario

Diagrama de DL-DATA.request(DATO) DL-DATA.indication(DATO)

correlación de
primitivas Enlace Enlace

PH-DATA.req(SEC, DATO) PH-DATA.ind(SEC,DATO)


PH-DATA.ind(SEC,ACK) PH-DATA.req(SEC, ACK)

Medio físico 8
Vocabulario y formato de mensajes
- Se define para cada nivel
- Dos tipos de protocolos en cuanto formato de mensajes:
- protocolo orientado a bit
Tx datos como flujo de bits sin longitud definida (flags
de inicio y fin). Ej: HDLC
- protocolo orientado a carácter
Tx datos en bloques de n bits (o múltiplos de n)
(caracteres marcadores de inicio y fin). Ej: Carácter
STX(Start of TeXt) y ETX (End of TeXt)

STX c1 c2 c3 ... cn ETX


Character stuffing
DLE STX c1 c2 DLE DLE ... cn DLE ETX 9
Vocabulario y formato de mensajes

- Formato = { cabecera, datos, cola }


• cabecera = { tipo, destino, nº secuencia, longitud }
» tipo = { ack, nack, err }
• cola = { checksum, dirección de retorno }

10
Reglas de procedimiento
- Procesos concurrentes
- Necesitamos herramientas más formales: diagrama
temporal, máquina de estados finitas, ESTELLE...

evento0[condicion0]/accion0
evento1[condicion1]/accion1

Estado Estado
i i+1

evento2[condicion2]/accion2
11
Diseño estructurado de protocolos
1. Simplicidad
2. Modularidad
3. Protocolos bien formados
- NO sobre-especificado
- NO incompleto
- Acotado
- Autoestabilizado
- Autoadaptable
4. Robustez
- Evolución automática con la tecnología
5. Consistencia
- Bloqueos
- Bucles infinitos
- Terminaciones impropias 12
Diseño estructurado de protocolos
Las diez reglas de diseño:
1. Asegurarse de definir bien todos los aspectos del protocolo
2. Definir el servicio a realizar por cada nivel antes de elegir estructuras
3. Diseñar antes funcionalidad externa que la interna
4. Mantener el diseño simple
5. No conectar lo que es independiente
6. Obviar aquello que es innecesario
7. Validar el diseño antes de implementarlo
8. Implementar diseño, medir su rendimiento y optimizarlo
9. Comprobar que la versión final cumple los criterios de diseño
10. Nunca saltarse las 7 primeras reglas
13
Mecanismos básicos de los protocolos
1. Control de secuencia y control de errores
- Redundancia
- Tipos de códigos
- Códigos de paridad
- Corrección de errores (varios métodos)
2. 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

14
Control de secuencia y de errores
- Mayor número de errores debido a la comunicación que al hardware
P(circuitería)<10-15
P(F.O.) ≈10-9 P(coax.) ≈10 -6 P(tlf.) ≈10 -4 ó 10 -5
- Causas principales de error:
- limitaciones en el ancho de banda del canal (distorsión lineal)
- eco, ruido blanco, impulsos electromagnéticos... (no lineal)
- El efecto de esos ruidos se puede paliar hasta cierto punto con
hardware y el resto por software (no se eliminan)
- El esquema de control de error debe ser adecuado a las características
de la línea de comunicaciones:
. Si un canal sólo tiene inserciones, no sirve un protocolo que
proteja contra eliminaciones
. Si un canal produce errores simples, puede ser más adecuado
usar un protocolo más simple
. Si el error del canal es < que el de la circuitería, el mecanismo
de control sólo degrada rendimiento del sistema y disminuye 15
fiabilidad del protocolo
Control de secuencia y de errores.
Redundancia
- Añadir información redundante a los mensajes
- Dos formas de gestionar los errores:
- Control de errores hacia delante ð códigos correctores
- Control de errores por realimentación ð códigos detectores

p≡probabilidad de error en la transmisión de un mensaje


f ≡fracción de errores que capta el método de control
error residual=p·(1-f)

- Si p↓ ð no código corrector (ralentiza las comunicaciones)


Si p↑ ð no código detector (las reTx también podrían ser erróneas)

- También depende del coste: si p↓ y coste de reTx↑ ð código corrector

- Sistema mixto: el receptor corrige los errores más frecuentes y solicita


reTx de los mensajes alterados por errores menos frecuentes
16
Control de secuencia y de errores.
Tipos de códigos
• Códigos de bloque:
. palabras de código de misma longitud y codificación estática
• Códigos de convolución:
. palabras de código dependen del mensaje actual y de
anteriores, el codificador cambia su estado con cada mensaje
procesado, longitud de palabras suele ser constante

Se pueden clasificar en:


ØCódigos lineales: combinación lineal de palabras válidas
ØCódigos cíclicos: rotación cíclica de código válido
ØCódigos sistemáticos: mensaje original + bits de comprobación

Razón de código=d/(d+e)
d ≡ nº de bits de información
e ≡ nº de bits redundantes

17
Control de secuencia y de errores.
Corrección de errores

Código válido
Código alterado

• Los códigos se eligen de forma que haya varios bits de diferencia entre
dos palabras válidas
• Rxor reconstruye mensaje, asociándole la palabra de código más
cercana
• Razón de código de sistema corrector < razón de código de sistema
detector
• Se usa sistema corrector si hay:
– un retraso de transmisión alto
– ausencia de canal de retorno
18
– una tasa de errores alta
Control de secuencia y de errores.
Código corrector basado en paridad
LRC
D= 1 0 0 0 1 0 0 0
A= 1 0 0 0 0 0 1 0
Permite la corrección de 1 bit
T= 1 0 1 0 1 0 0 1
A= 1 0 0 0 0 0 1 0
VRC 0 0 1 0 0 0 0 1

LRC= Longitudinal Redundancy Check


VRC= Vertical Redundancy Check

d=28 bits
e=12 bits
Razón de código=28/(28+12)=0.7
19
Control de secuencia y de errores.
Método Van Lint
- n tiradas de una moneda por segundo.
Resultado Código - canal de 2n bps.
en transmisor

XX 0000 - tasa de errores de 2·10-2; p=0.02


q=0.98 (probabilidad no-error)
CX 1001
ð cada par de tiradas se codifica con
XC 0111 4 bits.
CC 1110 ð Z=q4+3*q3p (prob. de no-error nueva)

Códigos válidos Resultado W=1-Z=0.0212 (para


DOS tiradas).
0000 1000 0100 0010 XX
Antes tenía P=p1+p2=0.04
en receptor

1001 0001 1101 1011 CX


ü Reduce a la mitad la
0111 1111 0011 0101 XC probabilidad de error.
1110 0110 1010 1100 CC
20
El código resiste errores en 1 bit de los 3 primeros de la palabra
Control de secuencia y de errores.
Distancia de Hamming
• Distancia de Hamming: diferencia de bits mínima entre
dos palabras de un código. XOR(2 palabras de código)

• Si la distancia de Hamming de un código es n, se puede:


– Detectar errores de hasta n-1 bits
– Corregir errores de hasta (n-1)/2 bits

• ↑distancia de Hamming ð ↑fiabilidad de protocolo

21
Control de secuencia y de errores.
Código de Hamming
• Para que un código de k bits de datos y r bits
redundantes sea capaz de corregir errores simples debe
r +k
cumplir: 2 ⋅ (r + k + 1) <= 2 ⇒ r + k + 1 <= 2
k r

• Los códigos que verifican lo anterior con r mínimo se


denominan óptimos
• Ejemplo: k=7 (ASCII), r mínimo / k+r+1≤ 2r ð r=4 ð n=11
‘a’≡ 1 1 0 0 0 0 1

1 2 3 4 5 6 7 8 9 10 11
1 1 0 0 0 0 1

Los bits redundantes ocupan las posiciones potencia de 2


(1,2,4,8), el resto son los bits de datos
22
Control de secuencia y de errores.
Código de Hamming (II)
1 2 3 4 5 6 7 8 9 10 11
A B 1 C 0 0 0 D 1 0 0

Bit 3: A+B+C+D Bit 9: A+B+C+D Cada bit de datos reales,


Bit 5: A+B+C+D Bit10: A+B+C+D está “protegido” por una
Bit 6: A+B+C+D Bit11: A+B+C+D serie de bits de paridad
Bit 7: A+B+C+D dependiendo de la posición
que ocupe.

Consecuente con lo anterior,


cada bit de paridad (A-D) se A => Paridad: 1; 3; 5; 7; 11; 13...
calcula teniendo en cuenta B => Paridad: 2 a 3; 6 a 7; 10 a 11;…
esta tabla. C => Paridad: 4 a 7; 12 a 15; 20 a 23;…
D => Paridad: 8 a 15; 24 a 31;…

23
Control de secuencia y de errores.
Código de Hamming (II)

XOR

1·20 +1·21 +1·23 +0·24 = 7 ð posición del error

24
Control de secuencia y de errores.
Ráfagas
• La mayor parte de las veces los errores no se producen
de forma aislada.
• Mecanismos correctores tolerantes a ráfagas:
• k datos de n bits ð matriz k xn
- Códigos de interlineado • se Tx por columnas ð corrige ráfagas ≤ k
• CDs, DVDs, códigos de barras, comunicaciones
- Reed-Solomon inalámbricas, comunicaciones satélite, TV digital, modems
de alta velocidad

• Se ha demostrado que en la mayoría de los casos es


mejor el control por realimentación (↑aprovechamiento del
canal y ↓error residual).

25
Control de secuencia y de errores.
Código de redundancia cíclica (CRC)
• Mensajes de n bits se tratan como polinomios de grado n-1: 101 = x2 + 1.
• El código de comprobación se obtiene dividiendo el polinomio del mensaje
por un polinomio generador G => se halla el resto y se le añade al mensaje
• El mensaje recibido es correcto si el divisible por G. No se detecta el error
cuando es divisible por G.
• Ejemplos de polinomios: T=P·xr - R P·xr
– CRC-12: x12+x11+x 3+x 2+1 G
– CRC-16: x16+x 15+x2+1
– CRC-CCITT: x16+x12 +x 5+1 Detecta ráfagas ≤ r
• CRC-CCITT detecta:
– Cualquier número impar de errores simples
– Todos los errores dobles
– Todas las ráfagas de 16 o menos bits
– El 99’997% de las ráfagas de 17 bits
26
– El 99’998% de las ráfagas de 18 o más bits
Control de secuencia y de errores.
Checksum aritmético
• Método de Fletcher (1982)
• Sólo sumas y módulos, es simple, pero con buena detección de
errores Menor carga de procesamiento Menor latencia
• Inferior al CRC, detecta ráfagas de 1 a 14 bits (excepto de 8)
• Estandarizado como parte de protocolo estándar 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);
}
27
Control de flujo

• Objetivos:
– Asegurarse que no se transmiten los datos
más rápido de lo que se puede procesar.
– Optimizar el uso del canal.
– Evitar saturar el canal.
– Proteger la transmisión contra borrado,
inserción, duplicación y reordenamiento de
mensajes.

28
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
• Protocolo de ventana
29
Control de flujo. Protocolo simple sin control de flujo
Transmisor Receptor

Tx Rx

DL-DATOS.request / PH-DATOS.indication /
PH-DATOS.request DL-DATOS.indication

• OK si Rxor más rápido que Txor ð se viola el


principio “no hacer suposiciones de la velocidad
relativa de procesos concurrentes”
• Rx es más costoso que Tx
30
Control de flujo. Protocolo XON-XOFF
Transmisor NOTAS:
• X-OFF y X-ON son tramas
de control que llegan a
Esperando través de la primitiva PH-
DATOS.indication.
• Mientras espero, los DL-
DATOS.request no se
pierden, se ponen en una
FIFO.
X-ON/-
X-OFF / - • En el estado Tx, los DL-
Tx DATOS.request se obtienen
de la FIFO.

DL-DATOS.request / PH-DATOS.request
31
Control de flujo. Protocolo Xon-Xoff
Elemento_procesado [n>min] / DL-
DATOS.indication; n-- Receptor
Sólo
procesando PH-DATOS.indication [n>max]; n++ / Xoff;
(Xoff) Procesar_elemento

Elemento_procesado [n<=min] /
Xon; DL-DATOS.indication; n--
Rx y
procesando PH-DATOS.indication [n<max]; n++ /
mensajes Procesar_elemento

Elemento_procesado / DL-
DATOS.indication; n--

NOTAS:
• Procesar_elemento: Inicia el procesado del dato recibido.
• Elemento_procesado: Indica que el dato anterior ya está procesado y se puede entregar al
nivel de red.
• Si llegara algún dato mientras estado es x-off, se queda en la FIFO de
PH_DATOS.indication.
32
•MAX y MIN son los valores de highwatermark y lowwatermark respectivamente.
Control de flujo

• Protocolo Xon-Xoff, características:


– No requiere negociación previa.
– Si se pierde Xoff ð el transmisor no para.
– Si se pierde Xon ð bloqueo de los cuatro procesos.
– Los dos anteriores se pueden solucionar, pero estos de aquí
no:
• No se protege contra la saturación de forma efectiva.
• No se protege contra la pérdida de mensajes.

33
Control de flujo. Protocolo parada y espera con
timeout y errores de canal

PH-DATOS.indication
Transmisor [CRC no OK] / -
Timeout /
Recordar: PH-DATOS.request
• Existen FIFOs,
mientras espero, no
Esperando
se pierden datos.
• Los PH_DATOS.* DL-DATOS.request
llevan tanto datos PH-DATOS.indication /
como acks. [CRC OK] / - PH-DATOS.request

Tx
Receptor

PH-
PH-DATOS.indication [CRC OK] /
DATOS.indication
DL-DATOS.indication
[CRC no OK] / -
PH-DATOS.request
Rx 34
Control de flujo
• Protocolo de parada y espera con timeout
– Desaparece problema de saturación en Rxor
– Se desaprovecha el canal
– Retraso de 2Tp+Ttx,dato+Ttx,ack por cada mensaje enviado
• Tp: tiempo de propagación.
• Ttx,dato: Tiempo de transmisión del dato.
• Ttx,ack: Tiempo de transmisión del ack.
– Protege contra la pérdida de tramas
– En determinadas ocasiones, se pueden recibir
erróneamente datos duplicados aUna solución: numerar
mensajes y ack’s.

35
Control de flujo
• Protocolo de bit alternante
– Timeout + nº de secuencia de 1bit
• Problema si el ack tarda en llegar:

Transmisor Receptor
a(0)
ack de a
b(1)
timeout
retraso
ack de b
ack de b
c(0)
c(0)

36
Control de flujo
• Protocolo de ventana
– En la fase de establecimiento de conexión se negocia tamaño de la ventana (W)
– El Txor puede enviar W mensajes sin esperar acuse de recibo del Rxor
– Optimiza canal en los que el tiempo de tránsito es alto
– Control de error en ventana deslizante:
• Los reconocimientos tienen que numerarse, ACK1 significa que se recibió
correctamente la 0
• Si se pierde un mensaje y llega el siguiente:
– se rechaza: vuelta a atrás ó -se acepta: reTx selectiva
• Reconocimientos globales: ACK4 implica Rx OK de 1..3
– Ventana de Tx: mensajes enviados pendientes de ack (de tamaño variable, pero
limitada a W)
– Ventana de Rx: nºs de secuencia que Rxor espera Rx (de tamaño fijo)
– Para el rango de los nºs de secuencia debe cumplirse:
• rango(nºs secuencia)=>K+N
• donde K es el tamaño de la ventana de Rx y N el tamaño máximo de la ventana
de Tx
• en caso contrario podrían darse duplicaciones
37
Control de flujo. Protocolo de ventana con
detección de errores

Notación
v ≡ nº de mensajes pendientes de ack
N ≡ tamaño de la ventana de Tx
s ≡ nº de secuencia del último mensaje enviado
a ≡ nº de secuencia del mensaje más antiguo enviado y sin confirmar
dato[x] ≡ almacena el dato que fue enviado con nº de secuencia x
d ≡ dato que se quiere enviar
p ≡ nº de secuencia recibido en ack
M ≡ rango de números de secuencia disponible

Acciones:
pendiente[i] ≡ el mensaje con nº de sec i se apunta como enviado y pendiente de ack
pendiente[i] ≡ el mensaje con nº de sec i se apunta como confirmado
v+ ≡ se incrementa en uno el nº de mensajes pendientes de confirmación
v- ≡ se decrementa en uno el nº de mensajes pendientes de confirmación 38
Control de flujo. Protocolo de ventana con
detección de errores
1/1

2/1 Transmisor
3/2

Tx Límite
ventana

3/2
5/3 5/3

4/4
4/4

Entradas Salidas
1. DL-DATOS.request(d)[v< N-1] 1. PH-DATOS.request(d,s); v+ ; pendiente[s]; dato[s]=d; s=(s+1)%M
(se quieren enviar datos y caben más mensajes en la ventana) (envía dato con nº de sec s, incrementa el nº de mensajes
2. DL-DATOS.request(d)[ v= N-1] pendientes de confirmación, apunta el nº de sec como pendiente,
(se quieren enviar datos y se llega al límite de la ventana) almacena el dato enviado con ese nº de sec y se prepara el
3. PH-DATOS.indication(ack,p) nº de sec para el siguiente mensaje)
(llega un acuse de recibo positivo del mensaje con nº sec p) 2. para i desde a hasta p en módulo M hacer:
4. PH-DATOS.indication(-,p) no OK v-; pendiente[i]
(decrementa el nº de mensajes pendiente de confirmación en
(llega una indicación errónea) función de los que se hayan confirmado y los marca como
5 . Timeout de la trama p confirmados)
(expira el temporizador de retransmisión) 3. PH-DATOS.request(dato[p],p)
(retransmite dato con sec=p)
4. Nada

39
Control de flujo. Protocolo de ventana
Ventana de Tx: 4
Se ha llegado al
Transmisor Receptor Ventana de Rx: 1
límite de la
A B
ventana de Núm. Seq: 4+1=5
transmisión A0(n.seq=0)
A1(n.seq=1)
ACK1
A2(n.seq=2)
Hasta que no llega ACK2
A3(n.seq=3)
el ack de A0, el emisor
ACK3
no puede seguir
transmitiendo A4(n.seq=4) ACK4

A5(n.seq=0)
A6(n.seq=1)
Se “reutiliza” el número A7(n.seq=2) Recordemos que los
de secuencia ack indican el
número que espero
(y no el recibido)

40
Control de flujo. Protocolo de ventana (errores)
Transmisor Receptor
A B
A0 (nseq 0)
A1 (nseq 1)
A2 (nseq 2) B0
A3 B1
B2
A4 B3
A5
A6
timeout
A7 Se retransmite

B0
B1 W=4 (v. trans)
B2
K=1 (v. recep)
B3
A los acepta y piensa
que los datos de la ¡Núm. Seq= 4!
ventana anterior han
llegado bien 41
Control de flujo. Protocolo de ventana
Transmisor Receptor
A B
A0
A1
A2 B0
A3 B1
B2
B3
timeout
Se retransmite

A0
A1 B los acepta y piensa
B0
A2 que son los datos de la
B1 ventana siguiente , y sin
A3
B2 embargo, están duplicados
B3

42