Formato PDF - Departamento de Lenguajes y Sistemas e Ingeniería

Transcripción

INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - IMPLEMENTACIÓN DE PROTOCOLOS
INGENIERÍA DE PROTOCOLOS
DE COMUNICACIONES
(MÓDULO 1)
F. I. M.
INGENIERÍA
DE PROTOCOLOS DE COMUNICACIONES - IMPLEMENTACIÓN DE PROTOCOLOS
F. I. M.
FIM
LSIIS
TELEMÁTICA
L.S.I.I.S
L.S.I.I.S
INGENIERÍA DE PROTOCOLOS
(MÓDULO 1)
http://pegaso.ls.fi.upm.es/~lmengual/inicio_IP.html
LUIS MENGUAL GALÁN
OBJETIVOS




Describir las técnicas de descripción formal utilizadas para
especificar formalmente protocolos de comunicaciones y
presentar sus ventajas en la ingeniería de protocolos
Analizar las interfaces de programación más utilizadas en el
entorno corporativo: Sockets de Berkeley, Windows
Sockets, Sockets en Java.
Comprender las técnicas de implementación de aplicaciones
distribuidas utilizando las diferentes interfaces de
programación y el modelo cliente-servidor.
Estudiar el rendimiento de las implementaciones de software
cliente y servidor.
ÍNDICE
1. ESPECIFICACIÓN, DISEÑO Y VERIFICACIÓN DE PROTOCOLOS
1.1 Niveles de descripción de una arquitectura estructurada
1.1.1 Definición de la Arquitectura
1.1.2 Especificación de servicios
1.1.3 Especificación formal de protocolos
1.2 Desarrollo de Protocolos
1.2.1 Especificación Formal
1.2.1.1 Validación
1.2.1.2 Verificación
1.2.1.3 Análisis de Prestaciones
1.2.2 Implementación
1.2.3 Conformidad
1.3 Metodologías de Especificación
1.3.1 Lenguaje Natural
1.3.2 Grafos de Control de Comunicaciones
1.3.3 Máquinas de Estados Finitos Extendidas
1.3.4 Redes de Petri
1.3.5 SDL
1.3.6 Estelle
1.3.7 Lotos
1.3.8 Prolog
1
ÍNDICE
2. IMPLEMENTACIÓN DE PROTOCOLOS (I)
2.1 Modelo cliente-servidor
2.1.1 Terminología y conceptos
2.1.2 Comparación con otros modelos
2.1.2.1 Aplicaciones peer to peer,
2.1.2.2 Teoría de Agentes
2.2 Modelo Unix
2.2.1 Comunicación entre procesos
2.2.2 Procesos Concurrentes
2.2.3 E/S asíncronas
2.3 Interfaces de Programación de Aplicaciones (API, Aplication
Programming Interface)
2.3.1 Funcionalidad y especificación de las Interfaces de
Programación
2.3.2 Interfaces existentes
1
ÍNDICE
2. IMPLEMENTACIÓN DE PROTOCOLOS (II)
2.4 Interfaz Sockets de Berkeley
2.4.1 Algoritmos de diseño Software Cliente
2.4.1.1 Arquitectura del cliente
2.4.1.2 Tipos de clientes (TCP/UDP)
2.4.2 Implementación Software Cliente
2.4.2.1 Ejemplos clientes TCP/UDP
2.4.3 Algoritmos de diseño Software Servidor
2.4.3.1 Arquitectura del servidor
2.4.3.2 Tipos de servidores (TCP/UDP, concurrentes, iterativos)
2.4.4 Implementación Software Servidor
2.4.4.1 Servidores Iterativos no Orientados a Conexión (UDP)
2.4.4.2 Servidores Iterativos Orientados a Conexión (TCP)
2.4.4.3 Servidores Concurrentes orientados a conexión (TCP)
2.4.4.4 Servidores Concurrentes. Un solo proceso TCP
2.4.4.5 Servidores Multiprotocolo (TCP, UDP)
2.4.4.6 Servidores Multiservicio (TCP, UDP)
ÍNDICE
1
2. IMPLEMENTACIÓN DE PROTOCOLOS (III)
2.4.5 Eficiencia y gestión de la concurrencia en servidores
2.4.5.1 Elección entre un modelo iterativo y concurrente
2.4.5.2 Nivel de concurrencia
2.4.5.3 Concurrencia en función de la demanda
2.4.5.4 Coste de la concurrencia
2.4.6 Concurrencia en clientes
2.4.6.1 Ventajas de la concurrencia
2.4.6.2 Implementaciones con varios procesos
2.4.6.3 Implementación con un solo proceso
2.4.7 Procedimientos Remotos
2.4.7.1 Servicios Básicos sobre RPC
2.4.7.2 Construcción de aplicaciones
ÍNDICE
2. IMPLEMENTACIÓN DE PROTOCOLOS (IV)
2.5 Interfaz Windows Sockets
2.5.1 Comparación sockets de Berkeley
2.5.2 Desarrollo de aplicaciones
2.6 Interfaz sockets en Java
2.6.1. Introducción
2.6.2. Direcciones de Internet
2.6.3. Sockets TCP
2.6.3.1 Sockets para clientes
2.6.3.2 Sockets para servidores
2.6.3.3 Servidores multiusuario
2.6.3.4 Sockets seguros
2.6.4. Datagramas y sockets UDP
2.6.5. Sockets multicast
2.6.6. Conexiones a URLs
2.6.7. Otras alternativas (Java RMI, Java IDL)
BIBLIOGRAFÍA








“USING FORMAL DESCRIPTION TECHIQUES” An Introduction to
Estelle, Lotos and SDL. Edited by K.J. Turner. John Wiley &Sons 1993
“INTERNETWORKING WITH TCP/IP. CLIENT-SERVER
PROGRAMMING AND APLICATIONS BSD SOCKETS” VERSION
VOLUME III. D. Comer, R. Stevens. Prentice Hall. 1993
“UNIX NETWORK PROGRAMMING”. R. Stevens, Prentice Hall. 1998
“INTERNETWORKING WITH TCP/IP VOLUME III: CLIENT-SERVER
PROGRAMMING AND APPLICATIONS”. Window Sockets Version. D.
Comer, R. Stevens. Prentice Hall. 1997
NETWORK PROGRAMMING FOR MICROSOFT WINDOWS. Second
Edition. Anthony Jones, Jim Ohlund. Microsoft Press
“WINDOWS SOCKETS NETWORK PROGRAMMING”. B. Quin, D.
Shute. Addison-Wesley Publishing Company. 1995
“JAVA NETWORK PROGRAMMING”. E. R. Harold. O’Reilly 2000, 2ª
Edition
“JAVA SECURITY”. S. Oaks. O’Reilly 2001, 2ª Edition
INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - ESPECIFICACIÓN
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESPECIFICACIÓN DE
PROTOCOLOS (I)

Especificación sistemas:
– Definir un sistema dinámico de forma univoca

Especificar un protocolo de comunicaciones
consiste en:
– Especificar un algoritmo distribuido de tiempo real que se
desarrolla en un entorno compuesto por varios usuarios que
quieren comunicarse entre sí y por unas conexiones a través de
las cuales deben de comunicarse las distintas entidades del
protocolo.
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESPECIFICACIÓN Y
DISEÑO DE PROTOCOLOS (I)

La creciente utilización de sistemas distribuidos hace
cada vez más complejos los protocolos de
comunicaciones
– Esto plantea nuevas problemas de diseño detrás de los cuales, está
casi siempre la necesidad de una especificación precisa del
protocolo


Las primeras descripciones de protocolos eran
narrativas llevando fácilmente a ambigüedades
Inicialmente no se disponía de herramientas formales
de validación, verificación y comprobación de los
protocolos especificados y sus implementaciones
INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES -- ESPECIFICACIÓN
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESPECIFICACIÓN Y
DISEÑO DE PROTOCOLOS (II)

Hoy en día se entiende que una
especificación precisa debe de permitir:
– Verificar si un protocolo cumple el servicio para el que ha
sido diseñado
– Validar el funcionamiento del sistema (estados
alcanzables, no bloqueos, etc)
– Facilitar al máximo la realización del protocolo de forma
ejecutable, para la ó las máquinas en cuestión
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESPECIFICACIÓN DE
PROTOCOLOS (II)

Beneficios
– Se pueden derivar muchas implementaciones cambiando
pocas líneas en la especificación
– Se puede asegurar previamente un comportamiento
correcto del protocolo de acuerdo a las exigencias del
cliente.
– Se ahorra tiempo y dinero en la contratación de personal
encargado de implementar en lenguaje de alto nivel
(pascal, C, etc) si se dispone de una herramienta que me
permita la generación de manera automática o
semiautomática de código.
– Permite fácilmente generar un nuevo código del protocolo
adaptado a los nuevos cambios tecnológicos.
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
NIVELES DE DESCRIPCIÓN
ARQUITECTURAS DE COMUNICACIONES (I)
DEFINICIÓN DE LA ARQUITECTURA
 DEFINICIÓN DE LOS SERVICIOS
 ESPECIFICACIÓN DE LOS PROTOCOLOS
ARQUITECTURA

SERVICIOS
MECANISMOS
FUNCIONES
SERVICIOS
PROTOCOLO
MECANISMOS
FUNCIONES
NIVELES DE DESCRIPCIÓN
ARQUITECTURAS DE COMUNICACIONES (II)
APLICACIÓN
APLICACIÓN
TRANSPORTE
TRANSPORTE
ESPECIFICACIÓN
SERVICIOS
RED
ENLACE
FISICO
DEFINICIÓN ARQUITECTURA
RED
ESPECIFICACIÓN
PROTOCOLO
ENLACE
FISICO
INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES --ESPECIFICACIÓN
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
FASES DEL
DESARROLLO DE PROTOCOLOS

ESPECIFICACIÓN FORMAL
– VALIDACIÓN
» Especificación Completa, Ausencia de
Bloqueos, Ausencia de lazos improductivos,
Terminación, Todos los estados alcanzables
– VERIFICACIÓN
– ANÁLISIS DE PRESTACIONES
IMPLEMENTACIÓN
 CONFORMIDAD

METODOLOGÍAS DE
ESPECIFICACIÓN DE PROTOCOLOS




AUTÓMATAS
MÁQUINAS DE ESTADOS EXTENDIDAS
REDES DE PETRI
SDL
– CCITT Recommendation Z.100, Specification and Description
Language SDL, AP IX-35 1988

ESTELLE
– ISO/DP 9074. A formal Description technique based on an Extended
State Transition model, 1985

LOTOS
– A Formal Description Technique based on the Temporal Ordering of
Observational Behaviour. ISO 8807, 1988. Language Of Temporal Ordering
Specification

PROLOG
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
AUTÓMATAS

Un autómata es una quíntupla A = < E,S,Q,f,g > :
E : CONJUNTO FINITO DE ENTRADAS
S : CONJUNTO FINITO DE SALIDAS
Q : CONJUNTO DE ESTADOS
f:
FUNCION DE TRANSICION
g : FUNCION DE SALIDA
f : E ×Q → Q
g: E × Q → S
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
DIAGRAMA DE TRANSICIONES
(DIAGRAMA DE MOORE)
a/1
q
3
b/0
a/0
a/0
b/0
q
1
q
b/1
2
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
TABLA DE TRANSICIONES
E
E ={ a, b }
S ={ 0,1 }
Q ={ q1, q2 , q3}
Q
a
b
q
1
q /0 q /1
1
2
q
2
q /0 q /0
3
2
q
3
q /1 q /0
3
1
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROTOCOLO PARADA-ESPERA
V(S)
0
V(R)
I(0)
0
ACK1
1
V(S)
V(R)
x
I(0)
T
1
I(1)
ACK0
0
0
I(0)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
MÁQUINA DE ESTADOS EXTENDIDA:
TRAMA ACK
RECIBIDA /
ERROR
TRAMA I RECIBIDA /
MANDAR ACK
DESOCUPADO
TRAMA ACK
RECIBIDA /
PROCESO ACK
TRAMA I LISTA
PARA ENVIAR /
ENVIO TRAMA
EXPIRA T /
RETRANS.
DESOCUPADO
RECEPTOR
ESPERANDO
ACK
EMISOR
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
MÁQUINA DE ESTADOS EXTENDIDA:
EVENTO
ESTADO
ACTUAL
DESOCUPADO
(0)
ESPERANDO
ACK
(1)
EVENTO
ESTADO
ACTUAL
DESOCUPADO
(0)
EXPIRA
TEMP.
NA
0
RETRANS.
TRAMA
1
TRAMA I
LISTA
TRANS.
TRAMA
1
TRAMA ACK
RECIBIDA
ERROR
ACCION
0
NUEVO ESTADO
RETARDO
PROC. ACK
ACCION
1
0
TRAMA I
RECIBIDA
MANDAR
ACK
ACCION
0
NUEVO ESTADO
NUEVO ESTADO
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
REDES DE PETRI (I)
∏ = { p 1 , p 2 , p 3 , . . p r } Conjunto LUGARES
∑ = { t1 , t 2 , t 3 , . . t s } Conjunto TRANSICIONES
F: ∏ × ∑ → N * Función incidencia PROGRESIVA
B: ∏ × ∑ → N * Función incidencia REGRESIVA
M : ∏ → N * MARCAJE
INICIAL
LUGARES
REPRESENTACIÓN
GRAFICA
TRANSICIONES
FUNCIONES DE INCIDENCIA
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
REDES DE PETRI (II)
∏ = { p 1 , p 2 , p 3}
M 0 = { 3 ( p 1 ), 1 ( p 2 ), 0 ( p 3 ) }
∑ = { t1 , t 2 , t 3 , t 4 }
t1
.
..
p
1
.
p
2
t2
t4
t3
p
3
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
REDES DE PETRI (III)
F
p
1
p
2
p
3
t1
t2
t3
t4
1
0
0
0
0
1
0
0
B
p
1
p
2
t1
t2
t3
t4
0
0
1
0
2
1
0
0
0
2
0
0
p
0
0
1
pi → ti
1
3
ti → pi
INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES --ESPECIFICACIÓN
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
REDES DE PETRI:
T
p2
1
(ENVIO TRAMA)
p3
p1
T 2 (RECEP.ACK)
T
3
p4
(REENVIO TRAMA)
p5
p
EMISOR
1
: DESOCUPADO
p2
p
: DATOS NIVEL SUPERIOR
p3
: ESPERANDO ACK
p5
4 : ACK RECIBIDO
:TEMPORIZADOR EXPIRADO
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:


ESTELLE es una técnica de descripción
formal para la especificación de sistemas
concurrentes distribuidos
Una especificación ESTELLE está orientada a
la descripción de un conjunto de máquinas
de estado finito que se comunican entre sí y
cuyas acciones internar están definidas por
sentencias Pascal (con algunas restricciones
y extensiones)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
Elementos de la especificación

Módulos o procesos
– El comportamiento interno de un módulo está descrito
como una máquina de estados finíta extendida no
determinística
– Las transiciones se expresan en forma de sentencias
Pascal (con restricciones y extensiones)
– Cada módulo tiene un conjunto de puntos de acceso de
entrada/salida llamados puntos de interacción. Estos
puntos de interacción se utilizarán para la
comunicación entre procesos de distintos módulos
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Transiciones
– La ejecución de una acción está relacionada con el
estado de control del proceso, los valores actuales de las
variables de contexto, los mensajes recibidos y
encolados de otros procesos y la prioridad asociada a
cada transición
– Las transiciones no son determinísticas en el sentido de
que en cualquier instante dado puede haber más de una
acción que un módulo puede ejecutar
– Cuando se ejecuta una transición un módulo pasa a un
nuevo estado se actualizan ciertas variables e incluso se
pueden enviar ciertos mensajes por los puntos de
interacción definidos
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Comunicación entre procesos
– Los módulos o procesos definidos en ESTELLE se
comunican intercambiando mensajes o interacciones a
través de canales lógicos
– Un proceso puede enviar un mensaje a otro proceso a
través de un canal lógico establecido entre dos puntos
de interacción.
– Un proceso siempre puede mandar un mensaje o
interacción
– Un mensaje recibido por un proceso en un punto de
interacción se introducirá en una cola FIFO asociada
con ese punto de interacción
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Paralelismo y no Determinismo:
– La comunicación entre procesos es asíncrona.
– Los módulos operan independientemente y se
comunican asíncronamente a través de los canales.
– Cada proceso definido en un módulo seleccionará el
conjunto de transiciones o acciones listas para ser
ejecutadas.
– Aunque los procesos pueden intercambiar mensajes
entre ellos, éstos se ejecutan de manera asíncrona, de
modo que sus pasos son completamente
independientes uno de otros.
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
USUARIO_E
(UE)
USUARIO_R
(UR)
U
U
C
1
envia(datos)
recibe(datos)
U
U
RECEPTOR
(R)
EMISOR
(E)
MR
MT
ack(n)
C3
C
2
envia(n,datos)
recibe(n,datos)
C4
MR
MT
MEDIO (M)
ack(n)
IMPLEMENTACIÓNFORMAL
DE PROTOCOLOS
DE PROTOCOLOS
ESTELLE:
CHANNEL C1 (usuario, proveedor); CHANNEL C3 (usuario, proveedor);
by usuario :
by proveedor:
envia (datos:tipo_datos);
recibe (datos : tipo_datos);
CHANNEL C2 (usuario, proveedor);
by usuario :
envia (n:sec;datos tipo_datos);
by proveedor:
ack (n : sec);
CHANNEL C4 (usuario, proveedor);
by usuario:
ack (n :sec);
by proveedor:
recibe (n:sec;:datos : tipo_datos);
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
MODULE USUARIO_E;
ip U : C1(usuario);
MODULE USUARIO_R;
ip U : C3(usuario);
MODULE EMISOR;
ip U : C1(proveedor);
MT: C2(usuario);
MODULE RECEPTOR;
ip U : C3(proveedor);
MR: C4(usuario);
MODULE MEDIO;
ip MT: C2(proveedor);
MR: C4(proveedor);
BODY USUARIO_E_BODY FOR USUARIO_E; EXTERNAL;
BODY USUARIO_R_BODY FOR USUARIO_R; EXTERNAL;
BODY EMISOR_BODY FOR EMISOR; EXTERNAL;
BODY RECEPTOR_BODY FOR RECEPTOR; EXTERNAL;
BODY MEDIO_BODY FOR MEDIO; EXTERNAL;
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
INITIALIZE BEGIN
MODVAR
E : EMISOR;
R : RECEPTOR;
UE: USUARIO_E;
UR: USUARIO_R;
M: MEDIO;
INIT UE WITH USUARIO_E_BODY;
INIT E WITH EMISOR_BODY;
INIT M WITH MEDIO_BODY;
INIT UR WITH USUARIO_R_BODY;
INIT R WITH RECEPTOR_BODY;
CONNECT UE.U TO E.U;
CONNECT E.MT TO M.MT;
CONNECT UR.U TO R.U;
CONNECT R.MR TO M.MR;
END;
INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - - ESPECIFICACIÓN
IMPLEMENTACIÓNFORMAL
DE PROTOCOLOS
DE PROTOCOLOS
ESTELLE
TRANSICIONES

CONDICION DE DISPARO
–
–
–
–

ESTADO ORIGEN (FROM)
ENTRADA (WHEN)
PREDICADO (PROVIDED)
PRIORIDAD (PRIORITY)
ACCIONES
– ESTADO DESTINO (TO)
– SALIDAS (OUTPUT)

TRANSICIONES ESPONTANEAS
– NO TIENEN ENTRADA (WHEN)
– PUEDEN TENER LA CLAUSULA DELAY
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
EMISOR_BODY FOR EMISOR
STATE desocupado, esperando_ack
INITIALIZE BEGIN
STATE TO desocupado;
nsec : 0;
END
TRANS
WHEN U.envia(datos)
FROM desocupado TO esperando_ack
BEGIN
buffer :=datos;
OUTPUT MT.envia(nsec,buffer);
END
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
TRANS
WHEN MT.ack(n)
FROM esperando_ack TO desocupado
PROVIDED n=nsec+1; (MOD2)
BEGIN
nsec := nsec+1; (MOD2)
END
TRANS
FROM esperando_ack TO same
DELAY (timeout)
BEGIN
OUTPUT MT.envia(nsec,buffer);
END
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
RECEPTOR_BODY FOR RECEPTOR
INITIALIZE BEGIN
nesp=o;
END
WHEN MR.recibe(n,datos)
BEGIN
IF n<>nesp THEN BEGIN
OUTPUT MR.ack(nesp+1);
END
IF n=nesp THEN BEGIN
OUTPUT U.recibe(datos);
nesp=nesp+1;
OUTPUT MR.ack(nesp);
END
END
END
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
Asentimientos Selectivos
USER
U
DATA_INDICATION
RECEIVER
U
N
SEND_AK(ak_no)
NETWORK
DATA_INDICATION
N
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
RECEIVER_BODY FOR RECEIVER
STATE IDLE, ACK_SENT
INITIALIZE BEGIN (* initialization part *)
STATE TO IDLE
min:=1;
max:=20;
inactive_period:=60;
ak_no:=0;
END
TRANS (* transition part *)
FROM IDLE
TO IDLE
PRYORITY MEDIUM
WHEN N.DATA_INDICATION;
{T1} begin
output U. DATA_INDICATION;
ak_no:=ak_no+1;
end
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
TO ACK_SENT
PROVIDED (ak_no>0) and (ak_no<=4)
PRYORITY LOW
DELAY (min,max)
{T2} begin
output N. SEND_AK(ak_no);
end
PROVIDED (ak_no>4) and (ak_no<7)
PRYORITY high
DELAY (min)
{T3} begin
end
PROVIDED (ak_no=7)
PRYORITY high
{T4} begin
end
PROVIDED (ak_no=0)
PRYORITY low
DELAY (inactive_period)
{T5} begin
end
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
FROM AK_SENT
TO IDLE
{T6} begin
ak_no:=0;
end
end; (* transsition part *)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Inmediatamente después de la inicialización,
arranca el temporizador cláusula delay de la
transición T5
– Si pasan 60s y no llega ningún mensaje entrante se
dispara la transición T5 mandándose un ack artificial
para evitar la desconexión
– Si llega un mensaje antes de 60s se dispara la transición
T1 y se cancela el temporizador de la transición T5.
» El valor de ack_no = 1
» El estado final es IDLE
Inicio
T5
60s
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Después de llegar el primer mensaje arranca
el temporizador de la cláusula delay de la
transición t2
– Si los mensajes llegan en cantidades de 1-4 cada 20s.
ellos pueden ser reconocidos uno por uno o en bloques
de 2-4 mensajes dependiendo de la distribución de
mensajes en el tiempo
Inicio Tem. Delay T2
M1
T1
1s
20s
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
M2
M1
1s
M1
T2
20s
M2
M3
1s
T2
20s
M1
M2
M3
1s
M4
T2
20s
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:
M1
M2 M3
1s
M4
T2
20s
M1 M2 M3 M4
1s
T2
20s
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Después de llegar el quinto mensaje y no
haber sido asentidos los cuatro anteriores
– Se cancela el temporizador asociado al delay de la T2
– Arranca arranca el temporizador de la cláusula delay de
la transición T3
– Después de 1s se disparará la T3 si no se recibe el
mensaje 7
M1 M2 M3 M4
M5
T3
M1 M2 M3 M4
1s
M5
M6
1s
T3
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Después de llegar el séptimo mensaje y no
haber sido asentidos los mensaje anteriores
– Se cancela el temporizador asociado al delay de la T3
– Se dispara la T4 inmediatamente
Disparo T4
Inicio Tem.
Delay T2
M1 M2 M3 M4
Inicio Tem.
Delay T3
M5
M6
M7
1s
Cancela
Temp T3
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ESTELLE:

Conclusiones:
– Alta carga:
» Llegada de 7 mensajes en menos de 1s: Los asentimientos
son enviados en bloques de 7 mensajes
– Carga Media:
» Cuando se reciben más de cuatro mensajes en menos de
20s: Se manda un asentimiento conjunto después de un
retardo de 1s. desde el quinto mensaje.
– Esto ocurre si no se recibe antes el mensaje 7, en cuyo caso el
asentimiento es inmediato
– Carga Baja:
» Cuando solo se reciben de 1 a 4 mensajes en 20s se manda
un asentimiento al final de este tiempo (de 1, 2, 3 o 4)
– Sin tráfico
» Si no se envía ningún mensaje en el periodo de 60s se envía
un ack de mantenimiento de la línea
SDL (Specification and Description Language)
introducción





SDL : Leguaje de Especificación y Descripción
Basado en autómatas extendidos y comunicación
asíncrona de procesos
Normalizado por el CCITT: SDL-72, SDL76, ..SDL-88 /
ITU: SDL-92
Notación textual (SDL/PR) y gráfica (SDL/GR)
Aplicación: sistemas distribuidos, de tiempo real,
interactivos, protocolos de comunicaciones
– Ejemplo: Estándar IEEE 802.11

Herramientas: Telelogic Tau
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Estructura de una Especificación
System S
Block B1
Process P11
Process P12
Block B2
Process P13
Process P21
Process P22
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Estructura de un Sistema
Enviroment
System
Channel
Block
Channel
Channel
Block
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Estructura del Bloque
Signal
route
Process
Signal
route
Process
Signal
route
Channel
Channel
Block
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Proceso: Modelo Básico
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Constructores para la descripción de un Proceso
S1
START
STATE
A
B
INPUT
OUTPUT
S2
NEXSTATE
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
Proceso: Estados y Transiciones II
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SDL:
DESOCUPADO
ESPERANDO
ACK
DATOS NIVEL
SUPERIOR
TRAMA
DATOS
DESOCUPADO
T
ACK(n)
n<>nsec
n=nsec
n
SET(NOW+13,T)
ESPERANDO
ACK
TRAMA
DATOS
TRAMA
DATOS
TRAMA
ACK
SET(NOW+13,T)
DESOCUPADO
ESPERANDO
ACK
EMISOR
ESPERANDO
ACK
DESOCUPADO
RECEPTOR
TELELOGIC SDL
SDL PROTOCOLO PARADA-ESPERA
Descripción Sistema
Descripción Bloques I
Descripción Bloques II
Descripción Procesos I
Descripción Procedimientos
Descripción Procesos II
(o)
(1)
(1)
(o)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
INTRODUCCIÓN




En LOTOS Se hace una descripción dinámica
del sistema basado en una ordenación de
eventos
Los eventos ocurren en puntos de interacción
de procesos denominados puertas
Un evento corresponde a la activación de una
puerta
El proceso de modelado consiste en:
– Seleccionar los aspectos más relevantes del sistema
decidir como trasladarlos a puertas
– El comportamiento del sistema es especificado
describiendo todas las posibles secuencias de eventos que
el sistema puede ofrecer al entorno
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
REPRESENTACIÓN DE EVENTOS Y PUERTAS
estados
b
a
c
d
puertas
a: ?x1:int, ?x2:int, !(3+5), !true, ?x3:bool;
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
OPERADOR DE ELECCIÓN (CHOICE [ ])

Operador Choice [ ]:
( Net1_in? Datagrama: ip_dtgrm;
encamina(Datagrama);
.............................
)
[]
(
)
Net2_in? Datagrama: ip_dtgrm;
encamina(Datagrama);
.............................
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
SELECCIÓN DE EVENTOS Y OPERADORES DE GUARDA

Selección de Eventos:
a ? x:int [x<0];
a: ? x:int, !y [x>y]

Operadores de Guarda:
Net1_in? Datagrama: ip_dtgrm;
( ( [ruta(datagrama)=2] ->
Net2_out ! Datagrama;
.........)
[]
( [ruta(datagrama)=3] ->
Net3_out ! Datagrama;
..........)
)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
ENTRELAZADO DE PROCESOS
a1
a2
b1
b2
|||
a1
a2
b2
b1
a2
b2 a1
b2
a2
b1
a1
b1
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
SINCRONIZACIÓN PARCIAL
a
a
b
| [ a, d ] |
c
d
d
f
a
c
b
d
f
b
f
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
SINCRONIZACIÓN DE PUERTAS (I)

Las puertas tienen el mismo nombre y e es
un valor de tipo t
a?x:t

a!e
Las puertas tienen el mismo nombre y los
valores s1 y s2 coinciden
a ! s1

y
y
a ! s2
Los valores ofrecidos en la puerta son del
mismo tipo (t1=t2), pero no están definidos
a ? x : t1
y a ? y : t2
(En este caso el valor del evento que ocurrirá en el
modelo no está definido)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
SINCRONIZACIÓN DE PUERTAS (I)
Ejemplos:
a: ?x1:int, ?x2:int, !(3+5), !true, ?x3:bool
a: !7,
!9,
?y1:int, !true, ?y2:bool
a: !7,
!9,
?y1:bool, !true, ?y2:bool
a: !7, !9
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
SPECIFICACION BIT ALTERNANTE
behaviour
(
EMISOR [get, tout, send, receive ] (0)
|||
RECEPTOR [ give, send, receive] (0)
)
| [ tout, send, receive] |
LINEA [tout, send, receive]
where
process EMISOR [get, tout, send, receive ] (0) ( ........... )
process RECEPTOR [ give, send, receive] (0) ( ........... )
process LINEA [tout, send, receive] ( ........... )
endspec
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
LOTOS
receive !info ?rec:SNum
?data:BitString
send !info !seq !data
tout
rec=nesp
receive !ack !inc(seq) !empty
give !data
rec<>nesp
send !ack !inc(nesp)!empty
RECEPTOR
EMISOR
exit
RECEPTOR (inc(nesp))
send !ack !inc(nesp)!empty
send ?f:trame ?seq:SNum ?data:BitString
receive !f !seq!data
i
LINEA
tout
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
EJEMPLO ESPECIFICACIÓN
PROTOCOLO RDSI Q.931
RTC
RED DE CONMUTACION
DE PAQUETES
USUARIO
USUARIO
TELEX
RED BANDA
ANCHA
USUARIO
RDSI
USUARIO
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
RED DIGITAL
SERVICIOS INTEGRADOS
S/T
U
CENTRAL
LOCAL
RDSI
TR 1
AT
R
TERMINAL
RDSI
ACCESO BÁSICO 2B+D
TERMINAL
NO RDSI
....
S
T
U
TR 1
AT
R
TERMINAL
RDSI
....
TERMINAL
NO RDSI
.
.
.
CENTRALITA
DIGITAL
MULTISERVICIO
(NT2)
CENTRAL
LOCAL
RDSI
ACCESO PRIMARIO 30B+D
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
RED DIGITAL

MULTIPLEXACION A NIVEL FISICO:
– ACCESO BASICO
» 2B (64Kbps) + D (16Kbps)
– ACCESO PRIMARIO
» 30B (64Kbps) + D (64Kbps)

PLANO DE CONTROL:
– CANAL D

PLANO DE USUARIO:
– CANAL B Y D


El PLANO DE CONTROL estructurado en 3 niveles
(alineado con el modelo OSI)
El plano de usuario depende de las aplicaciones
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
RED DIGITAL
CONTROL DE LLAMADAS POR CANAL COMUN
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
RED DIGITAL
ARQUITECTURA DE PROTOCOLOS EN EL INTERFAZ USUARIO-RDSI
APLICACION
PRESENTACION
SESION
SEÑALIZACION
USUARIO
EXT-EXT
TRANSPORTE
RED
ENLACE
SEÑALIZACION
CONTROL(I.451)
X.25
NIVEL PAQUETE
X.25
NIVEL PAQUETE
LAP- D
FRAME-RELAY
LAP-B
NIVEL 1 (I.430, I.431)
FISICO
SEÑALIZACION
PAQUETES
CANAL D
TELEMETRIA
CONMUTACION
CIRCUITOS
LINEA
DEDICADA
CANAL B
CONMUTACION
PAQUETES
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
ARQUITECTURA DE
COMUNICACIONES RDSI
I.451/ Q.931
MENSAJE I.451 / Q.931
LAP-D
(I.441)
INTERFAZ
BASICO
(I.430)
INTERFAZ
PRIMARIO
(I.431)
CABECERA
LAPD
MENSAJE I.451 / Q.931
FIN LAPD
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
FORMATO DE LOS MENSAJES Q.931
DISCRIMINADOR PROTOCOLO

R.LL


0
0
0
0
1
LONGITUD DEL
V.R.Ll.
IDENTIFICADOR
E.I.
CONTENIDOS
E.I.
Formato E.I. tipo 1
I
VALOR DE REFERENCIA
DE LLAMADA
0
1
IDENTIFICADOR E.I.
Formato E.I. tipo 2
TIPO DE MENSAJE
0
ELEMENTOS DE INFORMACION
OBLIGATORIOS Y ADICIONALES
IDENTIFICADOR E.I.
LONGITUD E.I.
CONTENIDOS E.I.
Formato E.I. tipo 3
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
MENSAJES Q.931
MENSAJES
ESTABLECIMIENTO
ESTABLECIMIENTO, ACUSE ESTABLECIMIENTO,
LLAMADA EN CURSO, AVISO, PROGRESO, CONEXION,
ACUSE CONEXION
MENSAJES
FASE
INFORMACION
SUSPENSION, ACUSE SUSPENSION, RECHAZO SUSPENSION,
REANUDACION, ACUSE REANUDACION, RECHAZO, REANUDACION
INFORMACION USUARIO
MENSAJES
LIBERACION
DESCONEXION, LIBERACION, LIBERACION COMPLETADA
MENSAJES
DIVERSOS
INFORMACION, ESTADO, CONSULTA DE ESTADO,
NOTIFICACION, CONTROL DE LA CONGESTION
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROCEDIMIENTOS
LLAMADA Q.931
ESTABLECIMIENTO
ESTABLECIMIENTO
LLAMADA EN CURSO
AVISO
AVISO
CONEXION
CONEXION
ACUSE CONEXION
ACUSE CONEXION
DATOS
DESCONEXION
LIBERACION
DESCONEXION
LIBERACION
LIBERACION
COMPLETA
LIBERACION
COMPLETA
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
Diagrama de transición de estados
para el establecimiento de la llamada
Q.931 por Conmutación de Circuitos
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
Diagrama de transición de estados
para la finalización de la llamada
Q.931 por Conmutación de Circuitos
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
EJEMPLO ESPECIFICACIÓN PROTOCOLO
RDSI Q.931 CON SERVICIOS DE SEGURIDAD
AUTORIDAD
CERTIFICACIÓN
M. INFORMACIÓN USUARIO (Mensaje 1)
M. INFORMACIÓN USUARIO (Mensaje 2)
USUARIO A
M. ESTABLECIMIENTO (Mensaje 3)
M. AVISO (Mensaje 4)
USUARIO B
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
INTERCAMBIOS DEL PROTOCOLO DE SEGURIDAD
INCORPORADO EN EL CANAL D DE LA RDSI
1 : A → C : Re q, A, B, encrypt(K PC , encrypt( K SA , [A, N1 ]);
2 : C → A : encrypt(K SC , [A, K PA , T ]), encrypt(K SC , [B, K PB , T ]), encrypt(K PA , N2 );
3 : A → B : encrypt(K SC , [A, K PA , T ]), encrypt(K PB , encrypt( K SA , [SK, T , N3 ]);
4 : B → A : encrypt (SK , N 4 );
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
behaviour
(
ISDN_USER[isdn, user, scontrol_call,choice_random,timeout] (userA)
|||
ISDN_USER[isdn, user, scontrol_call,choice_random,timeout] (userB)
|||
CERTIFICATION_AUTHORITY[isdn, user,t imeout](guide) )
|[isdn, timeout]|
NETWORKING_SERVICE[isdn, control_isdn, timeout]
where
...........................................
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
EJEMPLO ESPECIFICACIÓN LOTOS PROTOCOLO
ISDN_USER [isdn,user,scontrol_call,choice_random,timeout]
(own_name : user_name) : noexit :=
user ! initiate ! own_name
? tpname, peer_name :
user_name;
.
SECURITY_SERVICE_PHASE_1
[isdn, user,scontrol_call,choice_random, timeout ]
(own_name, tpname, peer_name)
isdn ! setup_security_message ! own_name
? call_refd : call_reference_value
? one_setup: setup_security;
SECURITY_SERVICE_RESPOND[isdn, user]
(own_name, call_refd,one_setup)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SECURITY_SERVICE_PHASE_1 [isdn,user,scontrol_call,timeout]
(own_name, guide, peer_name : user_name): exit :=
.
timeout
isdn !release_complete !own_name
!call_refs ?one_release_complete;
exit
.
.
scontrol_call ? call_refs: -
isdn !setup !m_setup(----)
isdn !call_proc !own_name
!call_refs ?one-call_proc
.
isdn ! alerting !own_name
!call_refs ?one_alerting
.
isdn ! connect!own_name
!call_refs ?one_connect
.
i
exit
isdn ! ui ! m_ui(----)
i
.
CLEAR_USER1[isdn] (own_name, call_refs)
SECURITY_SERVICE_PHASE_2[isdn,user,scontrol_call]
(own_name, peer_name, cp) ) ) ))
M1->
isdn ! ui !own_name
!call_refs ?one_ui
.
<-M2
user ! guide_service_down; exit
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SECURITY_SERVICE_PHASE_2 [ isdn, user, scontrol_call,timeout]
(own_name, peer_name : user_name, cp: public_key) : exit :=
.
timeout
.
.
scontrol_call ? call_refs: -
isdn ! setup_security !m_setup(----)
isdn !call_proc !own_name
!call_refs ?one-call_proc
.
isdn !release_complete !own_name
!call_refs ?one_release_complete;
exit
M3->
isdn ! alerting_security !own_name
!call_refs ?one_alerting
<-M4
.
user !authentication_service_rejected !own_name ;
exit
user ! authentication _service_comptete !own_name ;
exit
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
CERTIFICATION_AUTHORITY [isdn,user,timeout]
(own_name : user_name) : exit :=
.
isdn !release_complete
!m_release_complete(---)
exit
.
isdn ! setup !own_name
? call_refd ?one_setup
isdn ! alerting !m_alerting(---)
.
isdn ! connect !m_conect(---)
.
CLEAR_USER2[isdn] (own_name, call_refs)
isdn ! ui !own_name
! call_refd ?one_ui
.
M1->
isdn ! ui !m_ui(---)
(guide_service_accepted/
guide_service_rejected)
exit
<-M2
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
SECURITY_SERVICES_RESPOND [isdn, user] (own_name : user_name,
call_refd : call_reference_value, one_setup : setup_security) : exit :=
.
isdn !release_complete
!m_release_complete(---)
exit
.
isdn ! setup_security !own_name
? call_refd ?one_setup
* setup_acepted
.
user ! authentication _service_rejected
!own_name
.
isdn ! alerting !m_alerting(---)
exit
user ! authentication _service_accepted
!own_name
.
isdn ! alerting_security !m_alerting(---)
exit
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
NETWORKING_SERVICE[isdn, scontrol_call] : noexit :=
.
isdn ! setup_security ?one_setup:
setup_security
isdn ! setup ?one_setup: setup
. .
scontrol_call ? call_refd
scontrol_call ? call_refd
.
isdn ! call_proc !source !call_refs !
m_call_proc(---)
isdn ! setup_security !destination
!call_refd !one_setup_security
.
timeout
.
isdn ! call_proc !source !call_refs !
m_call_proc(---)
timeout
.
isdn ! setup !destination !call_refd
!one_setup
.
isdn ! alerting_security ? one_alerting
[call_refd == get_cr (one_alerting)]
.
i
.
isdn ! alerting _security !source
!call_refs ! one_alerting_security
exit
(I)
isdn ! alerting ? one_alerting
[ call_refd == get_cr(one_alerting)]
1
CLEAR_1[isdn] (source, call_refs,
destination, call_refd)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
NETWORKING_SERVICE[isdn, scontrol_call] : noexit :=
1
i
.
NETWORK_SERVICE[isdn] (user)
isdn ! alerting !source !call_refs
! one_alerting
isdn ! connect ? one_connect
[call_refd == get_call_ref(one_connect)]
.
.
isdn ! connect ! source !call_refs
!one_connect
DATA_TRANSMISION[isdn] (source, call_refs, destination, call_refd)
(II)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Introducción




PROLOG es un lenguaje de programación desarrollado
para representar y utilizar el conocimiento que se tiene
sobre un determinado dominio.
Un dominio es un conjunto de objetos y el conocimiento
sobre ese dominio se representa por un conjunto de
relaciones o reglas que describen las propiedades de los
objetos y sus interacciones.
Un programa PROLOG no es más que un conjunto de
reglas que describen las propiedades e interacciones
entre los objetos.
Un programa PROLOG consta de tres elementos básicos:
• Declaración de hechos (“facts”) acerca de los objetos y sus
relaciones.
• Definición de reglas (“rules”) hechos que dependen de otros
hechos
• Preguntas (“questions”) acerca de hechos
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Hechos “facts”


Los “hechos” no es más que el conocimiento que se
tiene de los objetos y sus relaciones.
En PROLOG una colección de “hechos” que son
utilizadas para resolver un problema particular se
denomina “Base de Conocimiento”.
conoce(juan, parís).
Hecho: “Juan conoce París”
Predicado
(nombre de la relación)
Argumentos
(nombres de los objetos)
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Consultas, Objetivos





Una vez que tenemos algunos hechos, podemos formular
algunas preguntas acerca de ellos
Cuando se hace una pregunta el intérprete PROLOG
buscará si dicho hecho coincide con alguno otro
existente en su Base de Conocimiento.
Estos dos hechos coincidirán si sus predicados son los
mismos y los argumentos coinciden y están en la misma
posición.
Para el intérprete PROLOG una consulta implica satisfacer
el objetivo expresado.
Si el intérprete PROLOG encuentra un hecho que coincide
con el hecho definido en la interrogación responderá
afirmativamente.
?- conoce(juan, parís).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Variables

En PROLOG no sólo se pueden utilizar nombres para denominar
a objetos concretos sino que también se puede utilizar nombres
para denominar a objetos todavía no determinados. Los
nombres de este segundo tipo se denominan variables

Cuando PROLOG utiliza una variable, dicha variable puede estar
o no instanciada:
– Una variable está instanciada cuando hay un valor particular asociado a dicha
variable.
– Una variable no está instanciada cuando todavía no hay un valor particular
asociado a dicha variable.


PROLOG distingue las variables de los nombres de objetos
concretos debido a que las variables comienzan con una letra
mayúscula
Cuando se realiza una pregunta a un intérprete PROLOG
conteniendo una variable, éste explora todos los hechos de su
Base de Conocimiento con el fin de encontrar un objeto para el
que se pueda asociar a dicha variable.
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Variables
conoce(juan, parís).
conoce(juan, estocolmo).
conoce(juan, oslo).
?- conoce(juan, X).
X=paris;
X=estocolmo;
X=oslo;
Base de Conocimiento
Consulta
Resultado
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Conjunciones (mecanismo de Backtracking)
?-conoce(juan,X) , conoce(maria,X).
•Primer objetivo satisfecho. Se asigna “X”=oslo.
•Prolog marca el punto de la BD en el que se satisface el objetivo.
•Se intenta satisfacer el segundo objetivo para ese valor de “X”.
conoce(juan,oslo).
conoce(juan,paris).
conoce(juan,londres).
conoce(maria,paris).
?-conoce(juan,X) , conoce(maria,X).
• El segundo objetivo falla
• Se intenta re-satisfacer el primer objetivo asignando un nuevo
valor a “X” a partir del punto marcado en la exploración anterior.
conoce(juan,oslo).
conoce(juan,paris).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Conjunciones (mecanismo de Backtracking)
?-conoce(juan,X), conoce(maria,X).
Primer objetivo satisfecho de nuevo. Se asigna “X”=paris
Prolog marca el punto de la B.D. en el que se satisface el objetivo
Se intenta satisfacer el segundo objetivo para ese valor de “X”.
conoce(juan,oslo).
conoce(juan,paris).
?-conoce(juan,X), conoce(maria,X).
El segundo objetivo tiene éxito.
El intérprete Prolog informa de ello, y queda a la espera de
realizar una nueva exploración
conoce(juan,oslo).
conoce(juan,paris).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Reglas

En PROLOG se utilizan reglas cuando es
necesario expresar hechos que dependen de
uno u otros hechos.

En PROLOG una regla consta de una cabecera
y un cuerpo. La cabecera y el cuerpo están
conectadas por el símbolo “:-”.
– La cabecera de la regla define el hecho que dicha regla
intenta definir.
– El cuerpo define una conjunción de objetivos que deben de
ser satisfechos uno por uno para que la cabecera tenga
éxito.
Hecho: “X es hermana de Y si X es mujer y X e Y tienen los mismos padres”
hermana_de(X,Y):=mujer(X), padres(X,P,M), padres(Y,P,M).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Análisis de la vulnerabilidad de Protocolos de Seguridad

Se puede utilizar PROLOG para analizar la
vulnerabilidad de un protocolo de seguridad
– A partir de la definición (o especificación) de un
protocolo de seguridad se puede representar su
comportamiento con un conjunto de reglas PROLOG
– A partir del conocimiento de alguna información relativa
a los contenidos del P.S. (grabada por un intruso) y de
las reglas que definen el comportamiento del protocolo
se puede analizar su vulnerabilidad
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
C
•C y A comparte una clave Ka
•C y B comparte una clave Kb
(1)
(3)
A
1 : A → C : E K ( B );
a
{
[
(4)
2 :C → A : EK K S ,EK K S A
a
b
[
3 : A → B : EK K S A
b
4 : B → A : E K [dat ]
s
]
(2)
B
]}
* Protocolo de Needham Schroeder
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Especificación Protocolos de Seguridad (P.S.)
PROTOCOL SPECIFICATION
CONSTANTS
a,b,x,c:address;
dat,req,ok:data;
ksa,ksb,kx,ks:key;
n1,n2:int;
t1,t2:ctime.
MESSAGES
1:a->c:encrypt(KSA,B);
2:C->A:encrypt(KSA,[KS,encrypt(KSB,[KS,A])]);
3:A->b:encrypt(KSB,[KS,a]);
4:B->A:encrypt(KS,dat).
RELATIONS
1:secret_key(a,KSA:a);
2:secret_key(B,KSB:C),secret_key(A,KSA:C),sesion_key(KS:C).
RULES
secret_key(a,ksa:a,c),secret_key(b,ksb:b,c),secret_key(x,kx:x,c);
sesion_key(ks:c).
KNOWS
kx,encrypt(ksa,x).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Traducción P.S. a un conjunto de reglas Prolog
REGLAS DE DERIVACIÓN DE MENSAJES
sent([a,c,encrypt(KSA,B)],[],1):-secret_key(a,KSA,a).
derives([a,c,encrypt(KSA,B)],
[C,A,encrypt(KSA,[KS,encrypt(KSB,[KS,A])])],2,MH):secret_key(B,KSB,C),secret_key(A,KSA,C),sesion_key(KS,C).
derives([C,A,encrypt(KSA,[KS,encrypt(KSB,[KS,A])])],
[A,b,encrypt(KSB,[KS,a])],3,MH).
derives([A,b,encrypt(KSB,[KS,a])],
[B,A,encrypt(KS,dat)],4,MH).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Traducción P.S a un conjunto de reglas Prolog
REGLAS ASOCIADAS A LA EMISIÓN / RECEPCIÓN DE MENSAJES Y A LA
MODIFICACIÓN DE LOS MISMOS
sent(Ms,[Mr|H],N):- R is N-1,R>0,received(Mr,H,R),derives(Mr,Ms,N,H).
received(Mr,[Ms|PH],N):-sent(Ms,PH,N),p_modified(Mr,Ms,PH,N).
p_modified([],[],_,_).
p_modified([X|Mr],[Y|Ms],H,N):- isomorphic(X,Y),
p_knows_initially(X),
p_modified(Mr,Ms,H,N).
p_modified([Y|Mr],[Y|Ms],H,N):- p_modified(Mr,Ms,H,N).
p_knows_initially(kx).
p_knows_initially(encrypt(ksa,x)).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
REGLAS ASOCIADAS AL ESTUDIO DE LA VULNERABILIDAD
DE UN PROTOCOLO DE SEGURIDAD (I)
p_knows(X,H,0):-p_knows_initially(X).
p_knows(X,H,N):- N>0,R is N-1, p_knows(X,H,R).
p_knows(X,[M|PH],N):- N>0, sent(M,PH,N), p_gets(X,M,PH,PH,N).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
REGLAS ASOCIADAS AL ESTUDIO DE LA VULNERABILIDAD
DE UN PROTOCOLO DE SEGURIDAD (II)
p_gets(X,M,PH,H,N):-member(X,M).
p_gets(X,M,PH,H,N):-encrypt_field0(encrypt(K0,W)),
member(encrypt(K0,W),M),
p_knows_ph1(K0,PH,H,N),
member(X,W).
p_gets(X,M,PH,H,N):-encrypt_field1(encrypt(K0,[V,encrypt(K1,W)])),
member(encrypt(K0,[V,encrypt(K1,W)]),M),
member(X,W).
member(X,X).
member(X,[X|_]).
member(X,[_|Y]):-member(X,Y).
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
PROLOG:
Análisis vulnerabilidad del P.S.
?- sent(M,H,1).
M = [a,c,encrypt(ksa,b)]
H = [] ->
?- sent(M,H,2).
M = [c,a,encrypt(ksa,encrypt(kx,[ks,a]))]
H = [[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->;
M = [c,a,encrypt(ksa,encrypt(ksb,[ks,a]))]
H = [[a,c,encrypt(ksa,b)],[a,c,encrypt(ksa,b)]] ->;
?- sent(M,H,3).
M = [a,b,encrypt(kx,[ks,a])]
H = [[c,a,encrypt(ksa,encrypt(kx,[ks,a]))],[c,a,encrypt(ksa,encrypt(kx,[ks,a]) )],
[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->;
M = [a,b,encrypt(ksb,[ks,a])]
H = [[c,a,encrypt(ksa,encrypt(ksb,[ks,a]))],[c,a,encrypt(ksa,encrypt(ksb,[ks,a]))],
[a,c,encrypt(ksa,b)],[a,c,encrypt(ksa,b)]] ->;
Reconsulting ...
?- p_knows(ks,H,3).
H= [[a,b,encrypt(kx,[ks,a])],[c,a,encrypt(ksa,encrypt(kx,[ks,a]))],[c,a,
encrypt(ksa,encrypt(kx,[ks,a]))],[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
IMPLEMENTACIÓN
PROGRAM emisor
TYPE
eventos=(trama_i_lista, trama_ack_recibida, expira_tem)
estados=(desocupado, esperando_ack)
acciones=(na, trans_trama, error, retrans_trama, retardo, proc_ack)
VAR
tabla_eventos_estados=array[estados,eventos] of
record
accion: acciones
nuevoestado: estados
end
estado_actual: estados
tipo_evento: eventos
Nseq: Numsecuencia
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
IMPLEMENTACIÓN
PROCEDURE inicializar
{ Inicializa las variables de estado y los conteniods de la tabla_eventos
_estados}
PROCEDURE transmitir_trama
{Construcción de la trama (inserción de número de secuencia y datos
de nivel superior). Pone la trama en linea. Salva la trama en un buffer.
Activa el temporizador.}
PROCEDURE retransmitir_trama
{Recupera trama de buffer. Pone la trama en línea. Activa temporizador}
PROCEDURE proceso_ack
{Si ack es correcto : Borrar trama del buffer. Incrementar nº de secuencia}
PROCEDURE retardo
{Retarda un corto intervalo de tiempo}
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
IMPLEMENTACIÓN
PROCEDURE Error { Situación error}
BEGIN
Inicializar;
REPEAT esperar a que se produzca un evento
tipo_evento:= evento
WITH tabla_estados_eventos[estado_actual, tipo_evento] DO
BEGIN
CASE accion of ¨{acciones}
trans_trama: transmitir_trama
retrans_trama: retransmitir_trama
pro_ack: proceso_ack
retardo: retardo
errror: error
END
estado actual: nuevo
END
UNTIL forever
END
IMPLEMENTACIÓN
DE PROTOCOLOS
FORMAL
DE PROTOCOLOS
IMPLEMENTACIÓN
PROCEDURE receptor
VAR
nesp
BEGIN
Inicializar nesp
REPEAT esperar a una trama I
IF nseq de la trama= nesp THEN
BEGIN
incrementar nesp
mandar ack(nesp)
END
if nseq de la trama<>nesp THEN
mandar ack(nesp)
UNTIL forever
END

Formato PDF - Departamento de Lenguajes y Sistemas e Ingeniería

Transcripción

Documentos relacionados

M.S.C. AGUSTIN JAIME NUÑEZ RODRIGUEZ REDES DE

Prólogo