La Capa de Transporte Mecanismos sobre un servicio fiable

La Capa de Transporte
Mecanismos sobre un servicio fiable
abril de 2008
Mecanismos sobre un
servicio fiable
Índice
• La Capa de Transporte.
• Primitivas de servicio.
• Elementos de una Capa de Transporte.
–
–
–
–
Direccionamiento.
Multiplexación.
Control de flujo y bufereado de TPDUs.
Establecimiento y liberación de conexiones.
• Un ejemplo sencillo.
• Resumen.
abril de 2008
2
1
Mecanismos sobre un
servicio fiable
La Capa de Transporte (I)
• Esencia: La capa de transporte es responsable de completar los
servicios de la red subyacente para ofrecerlos a la capa de aplicación.
– Servicios fiables orientados a conexión
– Servicios sin conexión
– Parametrización de la Calidad de Servicio
• Importante: las aplicaciones generalmente demandarán servicios
eficientes, en particular conexiones fiables.
• Nota: dependiendo de los servicios ofertados por la capa de red la
funcionalidad a añadir puede variar considerablemente. Vamos a
considerar un servicio de red fiable.
abril de 2008
3
Mecanismos sobre un
servicio fiable
La Capa de Transporte (II)
• Cuestión: ¿Por qué una nueva capa?
abril de 2008
4
2
Mecanismos sobre un
servicio fiable
El segmento o TPDU
abril de 2008
5
Mecanismos sobre un
servicio fiable
Servicios de una capa de transporte
Primitiva
Paquete enviado
Significado
LISTEN
(ninguno)
Se bloquea hasta que un proceso intenta
la conexión
CONNECT
CONNECTION REQ.
Intenta activamente establecer una
conexión
SEND
DATA
Envía información
RECEIVE
(ninguno)
Se bloquea hasta que llega un paquete
DATA
DISCONNECT
DISCONNECTION REQ.
Este lado quiere liberar la conexión
abril de 2008
6
3
Mecanismos sobre un
servicio fiable
Diagrama de estado de manejo de una
conexión (simplificado)
abril de 2008
7
Mecanismos sobre un
servicio fiable
Elementos de un protocolo de transporte
• Observación: Los protocolos de transporte se parecen mucho a los
de la capa de enlace. Sin embargo el entorno de trabajo es tan
diferente que las soluciones adoptadas también lo son.
abril de 2008
8
4
Mecanismos sobre un
servicio fiable
Direccionamiento (I)
Hay que localizar completamente el otro extremo:
• La máquina de destino (dirección de red).
• El usuario de destino (proceso o servicio).
• La entidad de transporte (si se pueden usar varias, como TCP
o UDP).
abril de 2008
9
Mecanismos sobre un
servicio fiable
Direccionamiento (II)
• Observación: ¿Cómo podemos saber dónde está el otro extremo?
abril de 2008
10
5
Mecanismos sobre un
servicio fiable
Direccionamiento (III)
•
Podemos tener un servidor en una dirección bién conocida y que maneje una gran cantidad
de servicios.
abril de 2008
11
Mecanismos sobre un
servicio fiable
Direccionamiento (y IV)
• Pero a veces no es posible (imaginemos un proceso con
acceso especial al hardware). Hay que encontrar la
dirección.
• Solución: Utilizar un servidor de direcciones. Pero esto no
es trivial.
• También podemos tener una lista de TSAPs bien
conocidos donde sabemos que se encuentran los servicios
de destino.
abril de 2008
12
6
Mecanismos sobre un
servicio fiable
Multiplexación
• Idea 1: Si la red sólo ofrece un número limitado de CVs o el usuario no quiere
pagar demasiado, utilizar un solo CV para varias conexiones: multiplexación
hacia arriba.
• Idea 2: Si un usuario necesita mucho más ancho de banda del que proporciona un
CV de red, utilizar varios para una sola conexión de transporte: multiplexación
hacia abajo.
abril de 2008
13
Mecanismos sobre un
servicio fiable
Control de flujo y bufereado de TPDUs
Similar a lo visto en la capa de enlace, pero:
• Problema principal: a este nivel puede haber tantas conexiones que
ya no es factible tener reservados los recursos. Necesitamos un
esquema dinámico.
– Si la red ofrece un servicio NO fiable, el emisor debe (además) buferear TPDUs hasta
que sean confirmadas.
– El receptor puede decidir descartar TPDUs si no tiene espacio
– Si la red ofrece un servicio fiable, el emisor aún debe buferear las TPDUs (¿por qué?).
En general se usan mecanismos de ventana de tamaño variable.
abril de 2008
14
7
Mecanismos sobre un
servicio fiable
Establecimiento y liberación de
conexiones
Entidad de
transporte A
Active Open
SYN
Entidad de
transporte B
Entidad de
transporte A
Pasive Open
Active Open
Entidad de
transporte B
SYN
SYN
Active Open
SYN
Para liberar la conexión hay dos modelos:
• Simétrico: Un lado envía la petición y espera a que se confirme.
• Asimétrico: Un lado envía la petición y listo.
Nota: En el segundo pueden perderse datos, si es dúplex. En el primero si el servicio de red
NO es fiable veremos que es imposible de implementar.
abril de 2008
15
Mecanismos sobre un
servicio fiable
Un ejemplo (I)
abril de 2008
16
8
Mecanismos sobre un
servicio fiable
Un ejemplo
( y II)
abril de 2008
17
Mecanismos sobre un
servicio fiable
Resumen
• La Capa de Transporte debe completar la funcionalidad de la capa de red y ofrecer
servicios fiables a la capa de aplicación.
• Su presencia es necesaria sea cual sea el servicio ofertado por la capa de red, ya que se
ejecuta en la máquina de usuario y no en la subred.
• Aunque las necesidades son similares a las vistas en la capa de enlace las soluciones
no lo son.
• Los mecanismos que debe implementar sea el servicio de red fiable o no, incluyen:
– Direccionamiento completo del proceso remoto.
– Multiplexación de las conexiones de transporte sobre las de red.
– Control de flujo y bufereado de TPDUs.
– Establecimiento y liberación de conexiones.
abril de 2008
18
9
La Capa de Transporte
Mecanismos sobre un servicio no
fiable
abril de 2008
Mecanismos sobre un
servicio no fiable
Índice
• Implicaciones de un servicio de red no fiable.
–
–
–
–
Transporte ordenado y retransmisión.
Detección de duplicados.
Control de flujo.
Establecimiento y liberación de conexiones.
• Temporizadores.
• Resumen.
abril de 2008
20
10
Mecanismos sobre un
servicio no fiable
Si el servicio de red no es fiable
• La subred, además de retrasar paquetes, puede perderlos, entregarlos
fuera de secuencia o incluso entregarlos duplicados.
• Esto crea problemas en los mecanismos vistos en el tema anterior y
es necesario plantear modificaciones importantes en algunos
aspectos:
– Transporte ordenado, retransmisión y detección de duplicados.
– Control de flujo.
– Establecimiento y liberación de conexiones.
abril de 2008
21
Mecanismos sobre un
servicio no fiable
Transporte ordenado y retransmisión
• Idea: Numerar los segmentos con números consecutivos para poder ordenar
posteriormente.
• Utilizar protocolos ARQ para forzar retransmisiones de segmentos perdidos.
• Problema: esto requiere utilizar temporizadores. ¿Qué valor de temporización
debe utilizarse?
– Fijo
– Adaptativo
• Otro problema: si un temporizador expira antes de que un segmento llegue a
destino, se producirá un duplicado.
• Pregunta: ¿Puede suponerse que será detectado siempre gracias a su número de
secuencia?
abril de 2008
22
11
Mecanismos sobre un
servicio no fiable
Atacando los duplicados (I)
Entidad de
transporte A
SN(0)
SN(1)
SN(2)
SN(0)
Timeout para SN(0)
Retransmisión SN(0)
SN(3)
Se agota el rango de
números de secuencia.
Se usa de nuevo el 0.
ACK para SN(0), SN(1) y SN(2)
ACK(2)
ACK(3)
SN(0)
Entidad de
transporte B
Llega el viejo SN(0) y es aceptado.
ERROR
Se supone duplicado y se descarta
ERROR
• Solución: Restringir el tiempo de vida de un paquete en la red y utilizar un espacio
de números de secuencia “suficientemente” grande.
abril de 2008
23
Mecanismos sobre un
servicio no fiable
Atacando los duplicados (y II)
• Pero ¿y si alguna de las entidades de transporte cae? ¿dónde continuar la
numeración?
– Esperar un tiempo para la reconexión (un múltiplo del tiempo máximo de vida del
paquete). Este puede ser muy grande en algunos sistemas.
– (Tomlinson 1975 y Sunshine y Dalal 1978) Utilizar un reloj externo y asignar el número
inicial dependiendo de éste. Es necesario vigilar que la numeración no entre en la
región prohibida.
abril de 2008
24
12
Mecanismos sobre un
servicio no fiable
Control de flujo
abril de 2008
25
Mecanismos sobre un
servicio no fiable
Establecimiento de conexiones
• No sólo establecer la conexión de forma fiable, sino acordar los
números de secuencia iniciales (ISN).
• La solución es el acuerdo de tres vías (three-way handshake)
abril de 2008
26
13
Mecanismos sobre un
servicio no fiable
Liberación de la conexión (I)
El problema de los dos ejércitos
abril de 2008
27
Mecanismos sobre un
servicio no fiable
Liberación de la conexión (II)
• Si no existe una solución ¿qué hacer?
• Ser pragmáticos. Utilizar temporizaciones que detectan la mayoría de los casos
y asumir que siempre pueden existir conexiones medio-abiertas (half-open
connections).
abril de 2008
28
14
Mecanismos sobre un
servicio no fiable
Liberación de la conexión (y III)
abril de 2008
29
Mecanismos sobre un
servicio no fiable
Temporizadores
Temporizador de retransmisión
Para retransmitir un segmento no confirmado.
Temporizador de reconexión
Tiempo mínimo entre la liberación de una conexión y el
establecimiento de otra con la misma dirección de
destino.
Temporizador de ventana
Tiempo máximo entre segmentos de ventana.
Temporizador de retransmisión de
segmentos de conexión
Tiempo entre intentos de establecer una conexión
Temporizador de persistencia
Para cancelar una conexión cuando no se confirman
segmentos
Temporizador de inactividad
Para cancelar una conexión cuando no se reciben
segmentos
Temporizador de desconexión
Para cerrar la conexión en el extremo de recepción
abril de 2008
30
15
Mecanismos sobre un
servicio no fiable
Resumen
•
•
•
•
•
•
•
Cuando el servicio de red no es fiable, los mecanismos estudiados en el tema anterior deben
revisarse.
El problema principal es la necesidad de reenviar segmentos que puedan haberse perdido y
secuenciarlos correctamente si se desordenan. Esto produce segmentos duplicados que hay que
poder detectar.
Para ello es necesario utilizar temporizadores de retransmisión y cuidar la asignación de
números de secuencia (utilizando posiblemente un temporizador de reconexión).
El control de flujo mediante ventanas puede tener problemas. Establecer un temporizador de
ventana.
Los números de secuencia iniciales se establecen en la conexión, que ahora debe realizarse
mediante el acuerdo de tres vías.
Para la liberación de la conexión no hay una solución. Hay que ser pragmáticos, utilizar
temporizadores y asumir la existencia posible de conexiones medio-abiertas.
¿Queda algo? ¿Podemos recuperar una conexión en caso de caída de un host donde se dejó?
abril de 2008
31
16