P. 1
Estructura de protocolo

Estructura de protocolo

|Views: 128|Likes:
Publicado porArmando Blanco

More info:

Published by: Armando Blanco on Apr 18, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/12/2013

pdf

text

original

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 d 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

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

• Transparente: es algo que. en realidad.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. 6 . no existe. en realidad. existe pero que parece que no existe.

Ayuda a distinguir la estructura lógica del protocolo.Un nivel o capa define un grado de abstracción de un protocolo. agrupando funciones relacionadas y separando las independientes . al separar tareas de alto nivel de las de bajo nivel .Servicio y entorno Ventajas del diseño por niveles: .Facilita la escalabilidad del protocolo Actores del modelo de diseño: .Un interfaz separa (y une) dos niveles distintos de abstracción Nivel N+1 Nivel N A Protocolo par B Entidad par Nivel N-1 Primitivas de servicio Servicio 7 .

Servicio y entorno Primitivas: . DATO) PH-DATA.ind(SEC.De confirmación (del suministrador del servicio) Transmisor Usuario X.indication(DATO) Diagrama de correlación de primitivas DL-DATA.ind(SEC.req(SEC. ACK) Medio físico 8 .De respuesta (de entidad par) .indication X.DATO) PH-DATA.request X.req(SEC.ACK) Enlace PH-DATA.De petición de servicio .response Receptor Usuario DL-DATA.request(DATO) Enlace PH-DATA.De indicación de servicio .confirm Usuario de servicio (Capa N) Suministrador del servicio (Capa N-1) Usuario de servicio (Capa N) X.

protocolo orientado a carácter Tx datos en bloques de n bits (o múltiplos de n) (caracteres marcadores de inicio y fin).protocolo orientado a bit Tx datos como flujo de bits sin longitud definida (flags de inicio y fin).Vocabulario y formato de mensajes ...Dos tipos de protocolos en cuanto formato de mensajes: . cn DLE ETX 9 .Se define para cada nivel . cn ETX Character stuffing DLE STX c1 c2 DLE DLE .. Ej: Carácter STX(Start of TeXt) y ETX (End of TeXt) STX c1 c2 c3 .. Ej: HDLC .

dirección de retorno } 10 .Vocabulario y formato de mensajes .Formato = { cabecera. longitud } » tipo = { ack. datos. destino. cola } • cabecera = { tipo. nack. err } • cola = { checksum. nº secuencia.

.Necesitamos herramientas más formales: diagrama temporal.Procesos concurrentes . ESTELLE. evento0[condicion0]/accion0 evento1[condicion1]/accion1 Estado i Estado i+1 evento2[condicion2]/accion2 11 . máquina de estados finitas.Reglas de procedimiento ..

Terminaciones impropias 12 .NO incompleto .Autoestabilizado .Bloqueos . Modularidad 3.Acotado . Robustez . Simplicidad 2.Diseño estructurado de protocolos 1.Autoadaptable 4.Bucles infinitos . Consistencia . Protocolos bien formados .NO sobre-especificado .Evolución automática con la tecnología 5.

Obviar aquello que es innecesario 7. No conectar lo que es independiente 6. Diseñar antes funcionalidad externa que la interna 4. Mantener el diseño simple 5. Nunca saltarse las 7 primeras reglas 13 .Diseño estructurado de protocolos Las diez reglas de diseño: 1. medir su rendimiento y optimizarlo 9. Implementar diseño. Definir el servicio a realizar por cada nivel antes de elegir estructuras 3. Asegurarse de definir bien todos los aspectos del protocolo 2. Validar el diseño antes de implementarlo 8. Comprobar que la versión final cumple los criterios de diseño 10.

protocolos de ventana 14 .protocolo de parada y espera .protocolo Xon-Xoff . Control de secuencia y control de errores .Corrección de errores (varios métodos) 2.Tipos de códigos . Control de flujo .protocolo de parada y espera con timeout .protocolo simple sin control de flujo .Códigos de paridad .protocolo de bit alternante .Redundancia .Mecanismos básicos de los protocolos 1.

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

Dos formas de gestionar los errores: .Si p↓ ð no código corrector (ralentiza las comunicaciones) Si p↑ ð no código detector (las reTx también podrían ser erróneas) .Control de errores hacia delante ð códigos correctores .Control de secuencia y de errores.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) .Añadir información redundante a los mensajes .Sistema mixto: el receptor corrige los errores más frecuentes y solicita reTx de los mensajes alterados por errores menos frecuentes 16 .También depende del coste: si p↓ y coste de reTx↑ ð código corrector . Redundancia .

palabras de código dependen del mensaje actual y de anteriores.Control de secuencia y de errores. palabras de código de misma longitud y codificación estática • Códigos de convolución: . el codificador cambia su estado con cada mensaje procesado. Tipos de códigos • Códigos de bloque: . 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. 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 . 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.

7 19 .Control de secuencia y de errores. Código corrector basado en paridad LRC D= A= T= A= VRC 1 0 0 0 1 0 0 1 0 0 0 0 0 1 1 0 1 0 1 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0 1 Permite la corrección de 1 bit LRC= Longitudinal Redundancy Check VRC= Vertical Redundancy Check d=28 bits e=12 bits Razón de código=28/(28+12)=0.

20 El código resiste errores en 1 bit de los 3 primeros de la palabra . p=0.02 q=0. de no-error nueva) W=1-Z=0.0212 (para DOS tiradas).98 (probabilidad no-error) ð cada par de tiradas se codifica con 4 bits.canal de 2n bps. Antes tenía P=p1+p2=0. ð Z=q4+3*q3p (prob.n tiradas de una moneda por segundo. .04 Códigos válidos en receptor Resultado 0010 1011 0101 1100 XX CX XC CC 0000 1001 0111 1110 1000 0001 1111 0110 0100 1101 0011 1010 ü Reduce a la mitad la probabilidad de error. . Método Van Lint Resultado en transmisor Código 0000 1001 0111 1110 XX CX XC CC .Control de secuencia y de errores.tasa de errores de 2·10-2.

Distancia de Hamming • Distancia de Hamming: diferencia de bits mínima entre dos palabras de un código. se puede: – Detectar errores de hasta n-1 bits – Corregir errores de hasta (n-1)/2 bits • ↑distancia de Hamming ð ↑fiabilidad de protocolo 21 . XOR(2 palabras de código) • Si la distancia de Hamming de un código es n.Control de secuencia y de errores.

4. el resto son los bits de datos 22 .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 k r +k r cumplir: 2 ⋅ (r + k + 1) <= 2 ⇒ r + k + 1 <= 2 • 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.8).2.

6 a 7. 24 a 31.. B => Paridad: 2 a 3. 13. 7.… 23 . está “protegido” por una serie de bits de paridad dependiendo de la posición que ocupe.… C => Paridad: 4 a 7. Consecuente con lo anterior. 12 a 15. 11. 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 5: A+B+C+D Bit 6: A+B+C+D Bit 7: A+B+C+D Bit 9: A+B+C+D Bit10: A+B+C+D Bit11: A+B+C+D Cada bit de datos reales. cada bit de paridad (A-D) se calcula teniendo en cuenta esta tabla. 3. 10 a 11. 20 a 23. 5.Control de secuencia y de errores.… D => Paridad: 8 a 15.. A => Paridad: 1.

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.

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

Control de secuencia y de errores. No se detecta el error cuando es divisible por G. 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. • Ejemplos de polinomios: – CRC-12: x12+x11+x 3+x 2+1 – CRC-16: x16+x 15+x2+1 – CRC-CCITT: x16+x12 +x 5+1 T=P·xr -R P·xr G 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 – El 99’998% de las ráfagas de 18 o más bits 26 .

do { c0 = (c0 + *s++) % 255. } 27 . c1=0. return (unsigned short) (c1<<8+c0). Checksum aritmético • Método de Fletcher (1982) • Sólo sumas y módulos. }while (--n>0). register int n) { register int c0=0. 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. c1 = (c0 + c1) % 255. pero con buena detección de errores Menor carga de procesamiento Menor latencia • Inferior al CRC.Control de secuencia y de errores. es simple.

28 . duplicación y reordenamiento de mensajes. inserción. – Evitar saturar el canal. – Proteger la transmisión contra borrado.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.

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 .

indication / DL-DATOS. Protocolo simple sin control de flujo Transmisor Receptor Tx Rx PH-DATOS.Control de flujo.indication DL-DATOS.request / PH-DATOS.request • 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 .

Esperando X-ON/- Tx X-OFF / - • En el estado Tx.indication.request 31 .request se obtienen de la FIFO.request no se pierden. se ponen en una FIFO.Control de flujo. los DLDATOS. DL-DATOS. Protocolo XON-XOFF Transmisor NOTAS: • X-OFF y X-ON son tramas de control que llegan a través de la primitiva PHDATOS.request / PH-DATOS. • Mientras espero. los DLDATOS.

• Elemento_procesado: Indica que el dato anterior ya está procesado y se puede entre al gar nivel de red. n-- NOTAS: • Procesar_elemento: Inicia el procesado del dato recibido. n-Sólo procesando (Xoff) Elemento_procesado [n<=min] / Xon. 32 . Protocolo Xon-Xoff Elemento_procesado [n>min] / DLDATOS.indication.Control de flujo.indication [n>max]. se queda en la FIFO de PH_DATOS. n++ / Procesar_elemento Elemento_procesado / DLDATOS.indication. • Si llegara algún dato mientras estado es x -off.indication [n<max]. n++ / Xoff.indication. Procesar_elemento Rx y procesando mensajes PH-DATOS.indication. n-- Receptor PH-DATOS. DL-DATOS. •MAX y MIN son los valores de highwatermark y lowwatermark respectivamente.

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

request Rx 34 . mientras espero.indication [CRC OK] / Timeout / PH-DATOS.Control de flujo.indication [CRC no OK] / PH-DATOS.request Tx Receptor PHDATOS. Protocolo parada y espera con timeout y errores de canal Transmisor Recordar: • Existen FIFOs. • Los PH_DATOS.indication PH-DATOS.request PH-DATOS.indication [CRC no OK] / - Esperando DL-DATOS.* llevan tanto datos como acks.indication [CRC OK] / DL-DATOS. no se pierden datos. PH-DATOS.request / PH-DATOS.

dato+Ttx. • Ttx. 35 .ack por cada mensaje enviado • Tp: tiempo de propagación.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: Tiempo de transmisión del dato. • Ttx. se pueden recibir erróneamente datos duplicados aUna solución: numerar mensajes y ack’s. – Protege contra la pérdida de tramas – En determinadas ocasiones.ack: Tiempo de transmisión del ack.

Control de flujo • Protocolo de bit alternante – Timeout + nº de secuencia de 1bit • Problema si el ack tarda en llegar: Transmisor Receptor ack de a a(0) b(1) timeout retraso ack de b ack de b c(0) c(0) 36 .

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.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. 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 – – – ..3 Ventana de Tx: mensajes enviados pendientes de ack (de tamaño variable.

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.

apunta el nº de sec como pendiente. PH-DATOS. (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. incrementa el nº de mensajes 2.request(d)[ v= N-1] pendientes de confirmación. Nada 39 . pendiente[s].request(d.request(d)[v< N-1] 1.s). dato[s]=d. para i desde a hasta p en módulo M hacer: v-. DL-DATOS.indication(-.request(dato[p]. DL-DATOS.indication(ack.Control de flujo.p) (expira el temporizador de retransmisión) (retransmite dato con sec=p) 4. v+ . s=(s+1)%M (se quieren enviar datos y caben más mensajes en la ventana) (envía dato con nº de sec s.p) nº de sec para el siguiente mensaje) (llega un acuse de recibo positivo del mensaje con nº sec p) 2. PH-DATOS. Protocolo de ventana con detección de errores 1/1 2/1 3/2 Transmisor Límite ventana Tx 5/3 4/4 3/2 5/3 4/4 Entradas Salidas 1. PH-DATOS. Timeout de la trama p confirmados) 3.p) no OK (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 . pendiente[i] 4.

seq=1) ACK4 ACK1 ACK2 ACK3 Receptor Ventana de Rx: 1 B Núm.seq=2) Recordemos que los ack indican el número que espero (y no el recibido) 40 . Protocolo de ventana Ventana de Tx: 4 Se ha llegado al límite de la ventana de transmisión Transmisor A A0(n.seq=3) A4(n.seq=4) A5(n.seq=2) A3(n.seq=0) A1(n. Seq: 4+1=5 Hasta que no llega el ack de A0.seq=1) A2(n.seq=0) A6(n.Control de flujo. el emisor no puede seguir transmitiendo Se “reutiliza” el número de secuencia A7(n.

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

Control de flujo. y sin embargo. Protocolo de ventana Transmisor A A0 A1 A2 A3 B0 B1 B2 B3 Receptor B timeout Se retransmite A0 A1 A2 A3 B0 B1 B2 B3 42 B los acepta y piensa que son los datos de la ventana siguiente . están duplicados .

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->