UNIVERSIDAD POLITECNICA

DE JUVENTINO ROSAS
PROTOCOLOS Y SERVICIOS TELEMATICOS.
Modelos de Validacin.

INGENIERIA EN TELEMATICA.
10 A ITE
OMAR DAMIAN GUTIERREZ
No. 312030443

03 Diciembre del 2015 cc

INTRODUCCION
Para especificar y verificar el conjunto de reglas de un protocolo se utiliza un
modelo de validacin, que es una visin parcial del protocolo, es decir, una visin
que se centrar en obtener un juego de reglas consistente y completo.
Se pretende modelar un protocolo lo ms simple posible para estudiar su
estructura y verificar que sea consistente y completo.
Conocer cules son los elementos que conformar un modelo de validacin nos
ayudar a tener una mejor compresin acerca de que aspectos debemos considerar
para comenzar a desarrollar un programa, el correcto uso de las sentencias, hasta
poder hacer un programa ms eficiente

CONCEPTO DE PROTOCOLO
Los protocolos son los lenguajes que se emplean en las comunicaciones entre los
dispositivos que forman las redes de ordenadores, es decir, son la base del
intercambio de informacin entre dispositivos.
Segn el modelo de referencia OSI, protocolo es aquel conjunto de reglas y
formatos que gobiernan las comunicaciones entre entidades que ejecutan funciones
a un mismo nivel en diferentes sistemas abiertos. As un protocolo es un conjunto
de normas que se usan para componer los mensajes que contienen la informacin a
transmitir.

FUNCION DE LOS PROTOCOLOS

Encapsulamiento. Es la adicin de informacin de control a los datos.
Prcticamente todos los protocolos transfieren los datos en boques (llamados PDU,
protocol data unit). Cada PDU contiene informacin de control y puede o no
contener datos.
La informacin de control se clasifica en tres categoras:

Direccin.
Cdigo de deteccin de errores.
Control de protocolos.

Fragmentacin y re ensamblado. Se denomina fragmentacin cuando hay un flujo

de PDUs de tamao acotado de un dispositivo a otro y los protocolos de niveles
inferiores requieren separar los datos en bloques de menor tamao. La
fragmentacin se lleva a cabo cuando la red de comunicacin solo acepta bloques
de un tamao mximo, para que el control de errores sea ms eficiente, ya que con
PDU pequeas se requieren retransmitir menos bits cuando una sufre un error.
Control de conexin. La transferencia orientada a conexin se requiere si las
estaciones anticipan un intercambio de datos voluminoso y/o ciertos detalles del
protocolo deben funcionar dinmicamente. Una conexin se establece entre las
entidades. Conlleva tres etapas:

Establecimiento de la conexin.
Transferencia de datos.
Terminacin de la conexin.

Entrega ordenada. Si dos entidades comunicantes estn en diferentes hosts

conectados por una red, existe el riesgo de que las PDU no lleguen a su destino en
el orden en que se enviaron, ya que pueden atravesar caminos diferentes a travs
de la red. Para evitar esto les es asignado un nmero nico de secuencia para que
puedan ser reacomodados por la unidad receptora.
Control de flujo. Es una funcin realizada por una entidad receptora para limitar la
cantidad o la tasa de datos que es enviada por una entidad transmisora. La forma
ms simple de control de flujo de datos es un procedimiento q de parada y espera,
en el que la recepcin de casa PDU debe ser confirmada antes de que la siguiente
sea enviada.
Control de Errores. Son necesarios para prevenir perdida y daos en los datos e
informacin de control. Se implementa por lo general como dos funciones
separadas: deteccin de errores y retransmisin. Para conseguir la deteccin de
errores, el emisor inserta un cdigo de deteccin de errores en la PDU transmitida,
que es una funcin de lo otros bits en la PDU. El receptor comprueba el valor del
cdigo en la PDU recibida. Si se detecta un error, el receptor descarta la PDU. En
caso de no recibir el acuse de recibo de la PDU en un tiempo razonable, el emisor
la retransmite.
Direccionamiento. Abarca cuatro etapas que son:

Nivel de direccionamiento.
Alcance de direccionamiento.
Identificacin de conexin.
Modo de direccionamiento.

Multiplexacin. Una forma de ella es soportada por mltiples conexiones en un

solo sistema. En otro contexto se refiere a la asignacin de conexiones de un nivel a
otro.
Servicios de transmisin. Dependen del sistema subyacente de transmisin.
Prioridad: Ciertos mensajes, como los de control, requieren llegar a la entidad
destino con un retardo mnimo.

Calidad del servicio: Ciertas clases de datos pueden requerir un umbral de

rendimiento mnimo o un umbral de retardo mximo. Seguridad: Los mecanismos
de seguridad, restringiendo el de acceso, pueden ser invocados.

ELEMENTOS DE UN PROTOCOLO
1.
2.
3.
4.
5.

El servicio a prestar por el protocolo.

Los supuestos sobre el entorno en el que se ejecuta el protocolo.
El vocabulario de los mensajes utilizados para implementar el protocolo.
La codificacin (formato) de cada mensaje en el vocabulario.
Las reglas de procedimiento que mantienen la coherencia de intercambios
de los mensajes.

PRINCIPIOS GENERALES DEL DISEO DE UN

PROTOCOLO
Uno de los principios es la simplicidad, como es el caso de los protocolos ligeros.
Un protocolo bien estructurado se puede construir a partir de un nmero pequeo
de piezas. Cada pieza, bien diseada y entendida, realiza una funcin y la realiza
bien. Los protocolos que estn diseados de esta manera son ms sencillos en
cuanto a entenderlos e implementarlos de manera eficiente, hacindolos ms
propensos a ser verificables y sostenibles. Un protocolo ligero es sencillo, robusto y
eficiente. El caso de los protocolos ligeros soporta directamente el argumento de
que la eficiencia y la verificabilidad no son ortogonales, sino preocupaciones
complementarias.
Otro principio es la modularidad basada en una jerarqua de funciones. Un
protocolo que realiza una funcin compleja se puede construir a partir de piezas
ms pequeas que se interactan en una forma simple y bien definida. Cada pieza
ms pequea es un protocolo ligero que se puede desarrollar, verificar,
implementar y mantener por separado. Las funciones ortogonales no se mezclan,
ya que se disean como entidades independientes. Los mdulos individuales no
hacen suposiciones acerca del trabajo de los dems, o incluso de su presencia. Por

ejemplo el control de errores y el control de flujo son funciones ortogonales. Ellas

se resuelven mejor por distintos mdulos ligeros que son completamente
conscientes de la existencia de los dems.
Un protocolo bien construido es un protocolo que:

No contiene algn cdigo desmesurado o imposible de ejecutar.

Contiene especificaciones completas. Ya que un protocolo incompleto puede
provocar recepciones no especificados durante su ejecucin. Una recepcin
no especificada se produce si llega un mensaje cuando el receptor no lo
espera recibir ni puede responder a l.
Est acotado, no puede exceder los lmites conocidos del sistema, ni
sobrepasar la limitada capacidad de las colas de los mensajes.
Ha de tener una estabilidad automtica. Si un error transitorio y arbitrario
cambia el estado del protocolo, el protocolo ha de volver siempre a un
estado deseable en un nmero finito de transiciones, y a continuacin
reanudar el funcionamiento normal. Del mismo modo, si un protocolo se
inicia en un estado arbitrario del sistema, siempre debe alcanzar uno de los
estados previstos dentro de tiempo finito.
Ha de tener la capacidad de auto-adaptarse. Por ejemplo, puede adaptar la
tasa a la cual enva los datos y la tasa a la cual el receptor puede recibirlos.
Por ejemplo un mtodo de control de la tasa se puede utilizar para cambiar
la velocidad de una transmisin de datos o su volumen.
Debe poseer robustez. Esto significa que el protocolo debe estar preparado
para desenvolverse adecuadamente en cada accin posible y con cada
posible secuencia de acciones en todas las condiciones posibles.
Debe ser consistente. Hay algunas formas en las que los protocolos pueden
fallar. Las tres ms importantes son:
Puntos muertos. Los estados en los que no se puede ejecutar el
protocolo, por ejemplo porque todos los procesos del protocolo
esperan condiciones que no se puedan cumplir.
Bucles. Las secuencias de ejecucin que se pueden repetir
indefinidamente.
Finales inadecuados. La finalizacin de la ejecucin de un protocolo
sin que se cumplan las condiciones de finalizacin adecuadas.

DIEZ REGLAS EN EL DISEO DE UN

PROTOCOLO
1. Asegurarse de que el problema est bien definido. Todos los criterios de
diseo, los requisitos y las limitaciones se deben enumerar antes del inicio
del diseo.
2. Definir el servicio que se realiza en todos los niveles de abstraccin antes de
decidir que estructuras deben usarse para realizar estos servicios.
3. Disear la funcionalidad externa antes de la funcionalidad interna. Primero
considerar la solucin como un caja negra y decidir cmo se debe
interactuar con su entorno. A continuacin decidir a como se puede
organizar la caja negra. Probablemente consta de cajas negras ms pequeas
que pueden ser refinadas de una forma similar.
4. Hacerlo sencillo. Los protocolos complejos son ms difcil de verificar su
funcionamiento que los simples. Tambin son ms difcil de implementar y
son menos eficientes. Ha de haber pocos problemas realmente complejos en
el diseo del protocolo. Los problemas que aparecen como complejos, son a
menudo varios problemas simples a la vez. El trabajo de los diseadores es
el de identificar los problemas ms simples, separarlos y luego resolverlos
de forma individual.
5. No conectar lo que es independiente. Separar las preocupaciones
ortogonales.
6. No introducir lo que no es material. No restringir lo que es irrelevante. Un
buen diseo ha de ser fcilmente ampliable. Un buen diseo resuelve una
clase de problemas en lugar de una sola instancia.
7. Antes de la implementacin de un diseo, construir un prototipo de alto
nivel y verificar que se cumplen los criterios de diseo.
8. Implementar el diseo, medir su rendimiento, y si es necesario, optimizarlo.
9. Comprobar que la implementacin final optimizada es la prevista en el
diseo de alto nivel.
10. No saltarse las reglas del 1 a la 7.

ERRORES, TIPOS, CORRECCION, BIT DE

PARIDAD
En sistemas de transmisin digital, se dice que hay un error cuando se altera un
bit, es decir, se transmite un 1 binario y se recibe un 0, o cuando se transmite un 0 y
se recibe un 1.
Existen dos tipos de errores:

Errores aislados. Corresponden a eventualidades que alteran solo un bit, sin

afectar a vecinos.
Errores en rfaga. Cuando se recibe una secuencia de bits en la que el
primero, el ltimo y cualquier nmero de bits intermedio son errneos.

CORRECCIN DE ERRORES.
Esencialmente, la correccin de errores funciona aadiendo redundancia en el
mensaje transmitido. La redundancia hace posible que el receptor deduzca cual fue
el mensaje original, incluso para ciertos niveles de la tasa de bits errneos.

BIT DE PARIDAD
Es un bit de comprobacin aadido a un conjunto de dgitos binarios para hacer la
suma de todos stos, incluido el bit de comprobacin, siempre par (paridad par) o
impar (paridad impar).

MODELOS DE VALIDACION
La validacin de un modelo se puede definir como la demostracin de su exactitud
para una aplicacin concreta. En este sentido, la exactitud es la ausencia de error
sistemtico y aleatorio: en metrologa se conocen habitualmente como fidelidad y
precisin respectivamente. Todos los modelos son, por su propia naturaleza,
representaciones incompletas del sistema del que pretenden ser modelo, pero a
pesar de esta limitacin pueden ser tiles.
La validacin de cdigos informticos se refiere a la aplicacin de frmulas
matemticas en el lenguaje informtico. Un requisito previo esencial son las buenas
prcticas de programacin (es decir, modular y plenamente documentada). Los
puntos especficos que requieren atencin son los posibles efectos de la precisin
de la mquina y los factores informticos especficos en la obtencin del modelo.
Los informes sobre errores internos del programa informtico son fuentes
importantes de informacin, as como la evaluacin del producto intermedio. Para
los modelos de relacin dosis-respuesta, es conveniente verificar los resultados de
una nueva aplicacin informtica cotejndolos con los publicados anteriormente.
Los modelos de validacin son mtodos para comprobar que la interaccin de un
protocolo es acorde a las especificaciones de diseo del protocolo. Los objeticos de
los modelos de validacin son:

Asegurar la fiabilidad y disponibilidad de los protocolos de comunicacin.

Evaluar aspectos importantes de los protocolos
Exactitud, garantizar el comportamiento esperado en una situacin
especfica.
Solidez, el protocolo debe ser capaz de trabajar correctamente en
condiciones anormales.
Reducir la complejidad (de ser posible).
Eliminar la ambigedad.
Preparar un protocolo bien estructurado

CONTROL DE FLUJO Y MODELOS DE

VALIDACION
En las comunicaciones, el control de flujo es el proceso de ajustar el movimiento de
datos desde un dispositivo a otro para asegurar que el dispositivo receptor puede
manejar todos los datos entrantes. Esto es importante cuando el dispositivo emisor
es capaz de enviar datos mucho ms rpido que el dispositivo receptor puede
procesar. Hay muchos mecanismos de control de flujo.
El control de flujo es la manera que tiene un lenguaje de programacin de provocar
que el flujo de la ejecucin avance y se ramifique en funcin de los cambios de
estado de los datos.
El control de flujo tiene como objetivos:

Asegurarse que no se transmiten los datos ms rpido de lo que se puede

procesar.
Optimizar el uso del canal.
Evitar saturar el canal.
Proteger la transmisin contra borrado, insercin, duplicacin y
reordenamiento de mensajes.

Uno de los protocolos de control de flujo ms comunes para la comunicacin se

llama xon-xoff, en este mecanismo, el dispositivo receptor enva un mensaje xoff a
el dispositivo emisor cuando su buffer est lleno, el dispositivo emisor entonces
deja de enviar datos, cuando el dispositivo receptor est listo para recibir ms
datos, enva una seal de xon.
Echo checking. En este caso adems de controlar los posibles errores, este mtodo
permite controlar el flujo, ya que si los buffers se llenan, se para el envo de ecos y
el transmisor se bloquea hasta que vuelva a recibir un eco.
X-OFF/X-ON o tambin llamado In-bound-flow-control. Este mtodo es un
complemento del mtodo anterior y consiste en que muchas veces aunque el
receptor deja de enviar ecos, el transmisor sigue enviando caracteres. En este caso
la forma de bloquear el transmisor, es enviando al receptor un carcter de control
X-OFF, que hace cesar el envo de caracteres. Para reanudar la transmisin, el
receptor enva un carcter de control X-ON al transmisor.

Out-of-band-control. Este mtodo se utiliza en las lneas de transmisin analgicas

y se le conoce como la norma V.24. Para ello se emplean los comandos RTS
(request to send) y CTS (Clear to send). Tambin en el caso de las impresiones, es
decir, entre ordenador e impresora, se utiliza este mtodo, ya que la impresora es
un dispositivo mucho mas lento que los ordenadores a los que esta asociada.
Protocolo de ventana (cont.)

Ventana de Tx: mensajes enviados pendientes de ack (de tamao variable,

pero limitada a W)
Ventana de Rx: ns de secuencia que Rxor espera Rx (de tamao fijo)
Para el rango de los ns de secuencia debe cumplirse:
rango(ns secuencia)<=K+N
donde K es el tamao de la ventana de Rx y N el tamao mximo de
la ventana de Tx en caso contrario podran darse duplicaciones

NOTACION
V = n de mensajes de ack
W = tamao de la ventana de Tx
S = n de secuencia del ltimo mensaje enviado
a = n de secuencia del mensaje ms antiguo enviado y sin confirmar
dato[x] = almacena al 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 nmeros de secuencia disponible

ACCIONES
pendiente[i] = el mensaje con el 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 mensaje pendientes de confirmacin
V- = se decrementa en uno el n de mensajes pendientes de confirmacin.

CONCLUSION
El uso de modelos de validacin es una herramienta que facilita la correcta
aplicacin de los protocolos en informtica, conocer esta informacin es til ya que
muchas veces por desconocer esto no poseemos las mejores prcticas en el
desarrollo de nuestro cdigo al programar o comunicarnos a travs de algn
lenguaje.
Es por esto que debemos tener siempre en consideracin todas reglas y modos de
estructurar correctamente nuestro programas.